I read some documents about WebRTC nat traversal. I see that if one of the peers is behind a symmetric NAT, then a TURN server has to be used.
I am wondering why shouldn't protocol allow traversal when at least one of the clients has public IP or asymmetric NAT?
From what I'm reading, the problem is establishing the connection between one peer and the peer with symmetric NAT. Then can't client behind symmetric nat connect to the other client? If sharing same UDP stream for bi-directional media is not possible/allowed, then why not the peer behind symmetric NAT create 2 or more connections, as many as needed for all media streams?
Best Answer
The problem with WebRTC is not that packets reach or not to their destinations but that if no traversal methods are used, data in payloads of IP packets are not correct. SDP data, for example, have fields that include IP addresses and ports that are only valid in a local context, that's to say, in the LAN behind the NAT. NAT devices are able to change IP headers but, in general, they cannot change the payloads of application protocols
That's why WebRTC supports NAT traversal methods through standard protocols (STUN, TURN and ICE in top of them). You have mentioned symmetric NAT. When you use that type of NAT, STUN does not work, and you should have a TURN server.