0

I am using ICE/STUN in the context of WEBRTC.

I understand why STUN does not work with symmetric NAT. The answer to that question is here: why STUN doesn't work with symmetric NAT?

I am asking a different question. There seems to be an assumption that if one of the agents has symmetric NAT we must use TURN. But if the other agents is not behind any NAT, it seems to me we don't need STUN or TURN at all. It will just work. Is this correct?

So if I am trying to communicate between a node behind a Symmetric NAT to a node not behind any NAT, shouldn't it just work? The outgoing packet from the NATed client should open the NAT mapping such that packets coming back from the destination to the source port should be mapped and get to the right place. No?

GroovyDotCom
  • 111
  • 2
  • Unfortunately, questions about protocols above OSI layer-4, e.g. WebRTC, are explicitly off-topic here. Also, clients/servers are application-layer (off-topic) concepts. Networking protocols at or below OSI layer-4 do not have clients or servers. There are application-layer protocols that require the real IP address assigned to the device is in the data packets, so that breaks with NAPT, and needs help to work with NAPT. – Ron Maupin Apr 19 '21 at 13:44
  • @RonMaupin -- Okay. So any upper layer protocol that sends local ip addresses or port numbers as part of its protocol would break if the peer did not have a way to map these to the NAT translated address. But if the upper layer is not behind a NAT and just works on a UDP receive/respond basis, all should be well. Yes? – GroovyDotCom Apr 19 '21 at 13:55
  • 1
    You should read and understand RFC 5766, Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN). It explains the circumstances that require some form of help. – Ron Maupin Apr 19 '21 at 14:34

0 Answers0