What are STUN and TURN in Computer Networking?

Session Traversal Utilities for NAT (STUN) is a lightweight protocol that operates as a tool for other protocols that need to handle NAT traversal. It enables users that are behind a NAT to connect to a single peer.

Traversal Using Relays around NAT (TURN) is a protocol used by multimedia applications to traverse a network address translator (NAT). It also supports a connection of a user behind a NAT to a single peer. However, it is used when STUN is not effective.

If you’re not a computer networking expert, this description raises more questions than answers, so let’s do a deep dive into what all this means.

But first, interested in learning more about latency in networks? Check out our white paper: A Case of High Latency: Hairpinning or Distance.

What brought about the need for STUN and TURN?

The Internet started out as a DARPA project and advanced quickly into a global essential. As it expanded, the 232 address space for IPv4 was simply not going to be enough to address the dramatic growth.

Several strategies were created to deal with this very problem and delay the IPv4 address exhaustion. Notably, Network Address Translation (NAT) enables an entire private network to lie behind one Internet-routable IP address, conserving IP addresses. Endpoints behind the NAT are only able to see their own local IP addresses, which are inaccessible to endpoints outside of the local network.

While this was a helpful addition for quelling IPv4 address exhaustion, it raised a separate issue. Since NATs hide the endpoints IP address from the rest of the world behind the private network IP address, how can you set up a direct, peer-to-peer connection between endpoints?

This is where two important factors come into play: STUN and TURN.

So what does STUN do?

To set up direct, peer-to-peer communication between two endpoints, where one is behind a NAT, you need a STUN or TURN server. Let’s start with the STUN.

As we mentioned, an endpoint behind a NAT is assigned a local address by a DHCP server. Because the address is not routable, other endpoints outside of the local network cannot connect to the endpoint with this local IP address. When this happens, the local endpoint can request its routable public IP address from a STUN server. By using Interactive Connectivity Establishment Procedures (ICE), the endpoints can attempt to establish a connection using this public IP address. Upon successful connection, media is able to travel directly between users without an intermediary: peer-to-peer. After this is established, the STUN server is no longer needed or used in this communication.

This is all well and good, but there is a separate instance STUN servers cannot cover: symmetric NATs which are often used in strict enterprise firewalls. In a symmetric NAT, mapping is done by the source and the destination IP addresses. This means that the address observed by the STUN server will be rejected by the firewall if a different node were to try to use it. Symmetric NATs render STUN servers ineffective.

This is where a TURN server becomes essential.

So what does TURN do?

An endpoint behind a symmetric NAT that wants to communicate with another endpoint can use a TURN server as intermediary. This TURN server is located on the public Internet and the TURN client is the endpoint behind the NAT. The TURN server acts as a relay between client endpoints. It may can accept media from an endpoint and forward it to the other endpoint.

Keep in mind, this means that TURN communication requires the continual use of the TURN server for the duration of the session — there is no direct peer-to-peer connection. This means you’ll need more server resources (CPU and bandwidth) than with STUN, which leaves after communication is established. Because of this, ICE mandates that STUN be used by default, and TURN be used as a last resort when STUN can’t be.

What should you watch out for when scaling TURN?

When scaling TURN, think about hairpinning before you go too far. Hairpinning is the result of endpoints in close proximity, while the TURN server is very far away. For example, if your endpoints are both located in California, but your TURN server is located in India, you’ll have hairpinning. It would be much more effective to have the TURN server located in California, or at least somewhere on the same continent. Hairpinning increases the round-trip time (RTT) in your application, which affects user experiences. It’s an important thing to consider, especially once you start scaling.

How Important is TURN, really?

At callstats.io, we process a billion WebRTC data points per month. Given this load, we are able to identify trends and generalizations across WebRTC applications, which are presented regularly in our WebRTC Metrics Reports.

We have identified that, on average, 30% of the peer-to-peer conferences connect via a TURN server. Without the TURN server, these users would not be able to communicate with each other. This is a huge percentage of the market, which makes it critical for WebRTC developers to have a good understanding of TURN.

Look out for our follow up posts delving deeper into TURN and NATs.

Originally published at www.callstats.io.