What are STUN and TURN servers and why do we need them in WebRTC

A brief about WebRTC

WebRTC is an open-source project that lets you add real-time communication abilities to your applications running on a browser or a mobile device. It establishes a “peer-to-peer” connection to communicate between two parties

You can read more about WebRTC on MDN or Wikipedia

An important thing to highlight here is that WebRTC puts great emphasis on peer-to-peer connections. The advantages of peer-to-peer connection are performance, which is very critical when talking about real-time communications.

What is worth mentioning is that before the peer-to-peer connection can be established, the discovery of the peer and media negotiation must take place for the peers to locate each other. This process is called signaling and is done via a different centralized server. The signaling channel is different from the direct peer-to-peer data channel. This channel is open throughout the session and is only used for sharing signaling metadata.

Peer-to-Peer connection

The idea of a peer-to-peer connection is that two parties wanting to talk connect directly to each other over the internet. They do not have to go through an application server to communicate. This enables communication to take place over the shortest path between one party and the other.
To connect, both parties should also know the public IP address of each other since that is how any resource is identified on the internet. For us to understand public IP addressed, let’s first try to understand how the internet works.

A brief about how the internet works

The internet is a giant web of smaller networks connected to each other. Any machine connected to the internet is part of one of these smaller sub-networks. Every resource on the internet has a unique address that identifies where the machine is. This is what is called the IP address.

Because of the total number of IPv4 addressed available, almost every consumer device will be a part of a private network (generally run by your ISP) and the IP address assigned to your device will be a private IP address. This private IP address is understood by other devices inside the same private network. Whenever you want to talk to another machine that is not part of the private network you are in, the ISP gateway router will assign a public IP for this communication. The router will then map your private IP to this public IP that is used for this communication. All this is done with the help of a protocol called NAT.

NAT or Network Address Translation is a method of mapping an IP address space into another by modifying network address information in the IP header of packets while they are in transit across a traffic routing device — Wikipedia

You can read more in detail about NAT here

Because of the NAT, firewall, and compliance network policies, the process of reaching the other peer becomes complex. WebRTC uses ICE to overcome this complexity.

ICE (Interactive Connectivity Establishment)

ICE is a technique used to find the available paths on the internet to connect two devices so that they can talk to each other directly. There can be more than one path to reach the other peer and these paths are called “candidates”. ICE internally relies on STUN and TURN servers to find different candidates.

STUN (Session Traversal Utilities for NAT)

Imagine peer A wants to connect to peer B.
Since peer A and peer B could both be part of different private networks or behind different firewalls, they need to know their public IP addresses so that they can share the same with the other peer. This is needed for them to connect directly.
A peer does not know its public IP address since that is handled by NAT and is beyond the knowledge of the peer.
This is where the STUN server comes into the picture.

STUN servers are simply lightweight servers running on the public internet which return the IP address of the requester’s device as part of the response body.

• Peer A wants to know its public IP address so that it can share the information with others
• Peer A connects to the STUN server and asks — “What is my public IP address”
• STUN servers can know the IP address of peer A as it will be part of the IP packet header
• STUN server sends back this public IP address as a response back to peer A

That’s it. That's all that a STUN server does

TURN (Traversal Using Relay NAT)

There are times when one of the peers is behind a symmetric NAT or a firewall that has strict policies to block traffic from unknown IP addresses.
Imagine

• Peer A wants to connect to peer B
• Peer A has access to peer B (thanks to signaling and registry)
• Peer A tries to connect o peer B directly
• This connection is dropped by the NAT/firewall since it detects traffic from an unknown IP source

This is where TURN servers come into the picture.

TURN servers can be thought of as a proxy. The traffic from peer A to peer B travels via the TURN server instead of going to peer B directly.

Since TURN servers cause an additional hop to be added, they add additional latency in the data between peer A and peer B.
TURN servers are used less frequently since WebRTC will try to first establish a direct connection and then fall back to this route if that fails.

NOTE: ICE uses STUN and TURN servers to generate all the candidates.

Hope this article helps you understand why STUN and TURN servers are needed.

Thanks for reading and if you have any ideas, I’d love to talk about them