Connecting a WebRTC session is an orchestrated effort done with the assistance of multiple WebRTC servers. The NAT traversal servers in WebRTC are in charge of making sure the media gets properly connected. These servers are STUN and TURN.
When connecting a session between two browsers (peer-to-peer) in WebRTC, there are 3 different alternatives that might happen.
Connecting WebRTC over a local network
If both devices are on the local network, then there’s no special effort needed to be done to get them connected to each other. If one device has the local IP address of the other device, then they can communicate with each other directly.
Most of the time and for most use cases, this is NOT going to be the case.
Connecting directly, over the internet, with public IP addresses
When the devices aren’t inside the same local network, then the way to reach each other can only be done through public IP addresses. Since our devices don’t know their public IP addresses, they need to ask for it first.
This is where STUN comes in. It enables the devices to ask a STUN server “what is my public IP address?”
Assuming all is well, and there are no other blocking factors, then the public IP address is enough to get the devices to connect to each other. Common lore indicates that around 80% of all connections can be resolved by either using the local IP address or by use of STUN and public IP addresses.
Connecting WebRTC by using TURN to relay the media
Knowing the public IP address is great, but it might not be enough.
There are multiple reasons for this, one of them being that the NAT and firewall devices in use are not allowing such direct traffic to take place. In such cases, we route the data through an intermediary public server called TURN.
References:
WebRTC TURN: Why you NEED it and when you DON’T need it
https://bloggeek.me/webrtc-turn
What are STUN and TURN servers and why do we need them in WebRTC
