Hacker Newsnew | comments | show | ask | jobs | submit login

That's where the third party supernode comes in; the sending peer tells the supernode which source port it is using to send to the non-supernode.



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.

-----


You then retry with an alternate supernode.

-----


Unless your NAT is randomising ports by default. Then you will always get the wrong answer.

-----


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.

-----


>stay by my opinion that sometimes it's just impossible to resolve without a middle man

Right, that's why TURN is part of ICE.

-----




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: