Contrary to the article, Skype didn't previously use supernodes for traffic between NATed clients. They were just used for NAT hole punching and then the traffic was direct between the clients.
It is possible that after receiving a wiretap request Skype will route your calls differently. But they could have rolled this out by just upgrading the supernode code and keeping supernodes distributed.
It seems far more likely that they made this change for stability/reliability. Particularly after the Skype network crashes that have happened in the past.
Well, you need a 3rd machine to route traffic between two machines if both are behind NAT^. It was my understanding that supernodes were (also) used for this.
^Unless you can predict the translated source port
No hole punching method will work for all combinations of firewall at each end of the intended communications channel. If connecting the clients directly in either direction after the initial negotiation fails then Skype (and tools like it) will instead send the data via a 3rd host (which sits in the middle and acts as a bridge between the two TCP streams).
If they get a wiretap order and your client can normally achieve a direct connection with a particular user, they could just emulate connection failure and the clients would revert to using the proxy without informing the user (after all, they are designed to do that for the sake of resilience of the user experience). You can probably see where the traffic is going, the client may even tell you without you having to dig far, but you won't know if you are going via the middle-man server(s) because of a general network issue that is stopping a direct connection being possible or if it is because of a wire-tap.
Doesn't contradict the parent post. For hole punching you need to know the source (host+port) your peer sends traffic from. If the source port is randomised (or already used by someone for udp if nat prevents sharing), hole punching will fail.
If you're natted, the source port seen by supernode doesn't have to be the same as the one seen by others. Someone on your network may be talking to the same supernode already, so the conflict has to be resolved by some remapping in the nat.
No. I don't know why you're not listening to what he's saying. I can tell you, from currently writing code that does STUN negotiation, unless you have two peers behind full-cone NAT (which is rather rare actually), you do not need to know what the port mapping/translation is.
I have a sideband connection to a server, and I tell it to route my negotiation packets to my peer's sideband connection. I literally never even touch a UDP port or connection, and the library I uses establishes a connection using STUN(-light). And from having read the source, it doesn't explicitly determine or set the mapping (using uPNP) either.
In my work with VoIP that situation was pretty much the default assumption. I agree that it's only the double NATed situation that's hard to handle, but stay by my opinion that sometimes it's just impossible to resolve without a middle man. But it depends on many things - clients, routes, number of people in local network using the same application, etc. Sometimes you just have to fall back to proxying everything.
It is possible that after receiving a wiretap request Skype will route your calls differently. But they could have rolled this out by just upgrading the supernode code and keeping supernodes distributed.
It seems far more likely that they made this change for stability/reliability. Particularly after the Skype network crashes that have happened in the past.