WebRTC establishes peer-to-peer connections between web browsers. To do that, it uses a set of techniques known as Interactive Connectivity Establishment or ICE. ICE allows clients behind certain types of routers that perform Network Address Translation, or NAT, to establish direct connections. (See the WebRTC glossary entry for a good introduction.) One of the first problems is for a client to find what its public IP address is. To do so, the client asks a STUN server for its IP address.

NATs are boxes (physical or virtual) that connect our local private networks to the public internet. They do so by translating the internal IP addresses we use to public ones. They work differently from one another, which ends up requiring WebRTC to rely on both STUN and TURN in order to connect calls. For background on these, check out some of our past posts on this topic like this one and this one.

While watching the “NAT Traversal” lesson of Tsahi Levent-Levi’s WebRTC Architecture course  I (re)learned the definition of a symmetric NAT from this slide:

If you ask two different STUN servers for your public IP address a symmetric NAT will give you the same IP address (hopefully) but different ports. We need a TURN server to get out of this mess as in general, symmetric NATs don’t allow the establishment of a direct connection.

 

A couple years ago I discussed some techniques for improving connectivity rates during a Tokbox talk (video and slides). Tsahi’s talk made me wonder if one could also test for the symmetric NAT scenario where you get a different port returned for each STUN binding?

After some tests I verified that yes, yes we can.

The first step is to ask two STUN servers for our IP address by passing it the following configuration:

We create a data channel to make the peer connection only generate a single local candidate.

Then we look at the onicecandidate  event and parse any candidates we get (using a helper function from my SDP module). If the candidate is of type srflx  we note both the port  –  the port after translation by the NAT device – and the relatedPort  – the port before translation.

Last but not least we call createOffer and setLocalDescription to start gathering:

Once we’re done gathering candidates we get an icecandidate  event with event.candidate  not being set. We then look at the candidates we got. There are only 3 options:

1. If we only got a single candidate, the browser did not want to bother us with the response from the second STUN server as it contained the same port. Which means we are not behind a symmetric NAT.
2. If we got two candidates with the same relatedPort  and different ports then we are behind a symmetric NAT.
3. And if we did not get a srflx  candidate at all UDP is blocked. This means we need a TURN/TCP or TURN/TLS server (like this one).

How do you test it? The personal hotspot on the iPhone is doing symmetric NAT which helps a lot.  Test it online in this fiddle:

Does the knowledge that we’re behind a symmetric NAT help us? Probably not much. We can now build a NAT type detector. I am not sure if this has much practical use since WebRTC’s ICE mechanism is designed to find a connection without you worrying about the details, but who knows. Nonetheless, it is a fun hack that will help you understand the mysteries of NAT traversal in WebRTC.

{“author”: “Philipp Hancke“}

 

Want to keep up on our latest posts? Please click here to subscribe to our mailing list if you have not already. We only email post updates. You can also follow us on twitter at @webrtcHacks for blog updates.