ChatLite
Start ChatLite

STUN, TURN and NAT explained simply

Published

If you have ever read a setup guide for video calls, you have met the words NAT, STUN and TURN. They sound like internal jargon, but they describe a simple problem: your device sits behind a router, and so does the device you want to call. This article explains the problem, the three tools that solve it, and what you can actually do with that knowledge.

The problem: nobody can see inside your home network

Think of a large apartment building. The building has one street address, but hundreds of flats, each with a flat number that only makes sense inside. Your router is the front desk of that building. Every device in your home has a private address, something like a flat number, that means nothing to the outside world. When a device sends a request to the internet, the router rewrites it so that it carries the building's single public address plus a number, and remembers which flat the answer belongs to. This rewriting is called Network Address Translation, or NAT. MDN describes it the same way: many devices share one public IP, each with a private address behind the router, and the router translates outgoing requests to its own public address with a unique port.

NAT is good for most things. It saves addresses and keeps stray traffic out. For a call between two browsers it is a nuisance. Browser A does not know the public address and port that the front desk assigned to it, and neither does browser B. And even if they knew, some front desks refuse to pass anything inward unless the flat inside had just sent something to that sender. MDN notes that some routers also restrict who can connect in, so that even when a public address is known, a peer may still be unable to connect.

Tool one: STUN, a mirror on the internet

STUN stands for Session Traversal Utilities for NAT. A STUN server is a small public service that does one thing: when your browser sends it a message, it answers with the address and port from which the message arrived. In the building analogy, you step outside, ask a passer-by what the front desk's address looks like, and write it down. Now you know your public address and can share it with the person you want to call.

RFC 8489, the standard that defines STUN, says its main purpose is to let an endpoint discover the public address and port that a NAT has mapped to its private address. It also notes that STUN is not a complete solution on its own; it is a building block that larger systems use. The default STUN port is 3478, and 5349 for STUN over TLS. STUN is cheap, because the server only answers a tiny question and then steps aside, and that is why many services use free public STUN servers, such as the three Google servers that ChatLite and the connectivity test on this site use.

Tool two: TURN, a courier when nothing else works

Sometimes knowing your public address is not enough, because the front desks on both sides will not let each other's packets in. This often happens with the stricter kind of NAT that picks a new public port for every destination. MDN calls it symmetric NAT and describes it as a router that only accepts connections from peers you have previously connected to. A direct path cannot be opened in that situation, however clever the browsers are.

TURN solves it with a courier. TURN stands for Traversal Using Relays around NAT. Both browsers connect outwards to a TURN server on the public internet, and the server passes packets from one to the other. RFC 8656 describes TURN as a protocol that lets a host behind a NAT use an intermediate relay server to exchange packets with other hosts. It also says the client can reach the server over UDP, TCP, TLS or DTLS. That variety matters on strict networks: a relay reached over TLS looks like ordinary web traffic, so it can work where UDP is blocked.

The price of a courier is bandwidth. Every picture and sound passes through the server, which costs the operator real money, adds a little delay, and means the media is no longer a direct path between you and the other person. That is why TURN is used only when there is no alternative, and why many free services do not offer a relay to everybody.

Tool three: ICE, the planner

Interactive Connectivity Establishment, ICE, is the process that ties these tools together. Each browser gathers a list of possible ways to be reached, called candidates, and the two browsers exchange their lists and test pairs until one works. MDN's description of the candidate types is a useful cheat sheet:

ICE tries the best candidates first and works down to the worst. The result is the shortest path that works, which is also the cheapest and fastest. Most successful calls end up as host or srflx pairs; relay is the safety net.

What this means for your calls

You can see this for yourself. The WebRTC connectivity test on this site gathers candidates in your browser and shows how many of each type it found. Seeing zero relay candidates there is normal, because the test deliberately uses only STUN.

A small glossary

About ChatLite

ChatLite uses STUN to try a direct connection between browsers and does not guarantee that a relay server is available, which is why the connectivity test on this site is useful before an important call.

References

Official documentation used to check this article. Pages are maintained by their owners and may change.

Reviewed against ChatLite's current behavior on .