Why does WebRTC use TURN sometimes?

Question

I've written a small WebRTC demo that streams a video file to the other peer and everything works fine (it's a real P2P connection without using the TURN server) except for this:

One client connects via a mobile network and one via wifi. When the mobile client creates the offer and kicks off the ICE candidate back-and-forth, they settle on srflx candidates and create a real P2P connection.

But when the wifi-client creates the offer, they fall back to the TURN server as a relay.

This happens in Firefox and Chromium on Ubuntu.

1. Does this behavior point to an obvious problem in my code?
2. If not, how can this be? Shouldn't the ICE protocol produce the same two candidates no matter which client is the controller?

Answer 1

NATs have two attributes influence if a connection will succeed between two WebRTC Agents. Those attributes are filtering and mapping.

---

When you send a packet to an address outside your NAT you create a mapping. A mapping is your IP:Port and people usually call it your Public IP. This is the Public IP that others can send into. A STUN server is just an echo server that responds with your mapping.

The first mapping type is an Address Independent NAT. This is the one you want. In this configuration you re-use a mapping everytime you contact an IP outside your NAT. You can give out your mapping to remote peers and they can send to you.

The second mapping type is Address Dependent. In this configuration you create a new mapping for each remote address. This means that the IP/Port you got back from the STUN server can NOT be used by other peers. In this case you may have to use a TURN server.

---

filtering controls who is allowed to send in. Some NATs allow anyone to send traffic in. Like mapping behavior this is called Address Independent. Other NATs only allow someone to send traffic in that you have attempted to contact, knows as a Address Dependent NAT.

---

Check out WebRTC for the Curious's Connecting Chapter I try to explain this in more depth. Pion also has a tool stun-nat-behavior that prints out the details of your NAT like so.

connecting to STUN server: stun.voip.blackberry.com:3478
=> NAT mapping behavior: endpoint independent
=> NAT filtering behavior: address and port dependent