What is a TURN server, and when does WebRTC need one?
How STUN, TURN and ICE work together to connect WebRTC calls, why direct connections fail behind symmetric NAT and firewalls, and how to tell when you need a relay.
A TURN server is a relay on the public internet that forwards traffic between two peers who cannot reach each other directly. WebRTC apps use it as a last resort: most calls connect directly, and the ones that can’t would fail without a relay.
WebRTC tries a direct path between two people first. When one side sits behind symmetric NAT, carrier-grade NAT or a firewall that blocks UDP, that path never opens. A TURN server gives each side a public relay address and forwards the media between them — and because the media is encrypted end to end, the relay only moves packets it cannot read.
The short version
- STUN (RFC 8489) tells a device the public IP address and port its NAT assigned. That is enough to connect when both NATs are permissive.
- TURN (RFC 8656) gives a device a relay address on a server and forwards packets through it. It works when direct paths are impossible.
- ICE (RFC 8445) gathers every possible path, tests them in pairs and picks the best one that works. Relayed paths rank last, so TURN only carries traffic when nothing else connects.
Why direct connections fail
Home routers usually map an internal address to the same public port for every destination, so a STUN-discovered address works. Three situations break this:
- Symmetric NAT assigns a different public port for each destination, so the address STUN reports is useless to the other peer.
- Carrier-grade NAT on mobile networks stacks another NAT in front of the device, often symmetric.
- Firewalls in offices, hotels and schools block UDP or allow only HTTPS on port 443.
In any of these, both peers can reach a server on the internet, but not each other. A TURN server is that meeting point.
How a TURN relay works
The client authenticates to the TURN server and requests an allocation: a public IP address and port on the relay. The client shares that relay address with the other peer as an ICE candidate. Packets sent to the relay address are forwarded to the client, and the client’s packets leave from the relay address.
Because WebRTC encrypts media with DTLS-SRTP end to end, the relay forwards packets it cannot decrypt.
TURN transports and ports
| URL | Transport | When it helps |
|---|---|---|
turn:host:3478 |
UDP | Lowest latency when UDP is allowed |
turn:host:3478?transport=tcp |
TCP | UDP is blocked |
turns:host:443?transport=tcp |
TLS over TCP | Only HTTPS traffic gets through |
Offer all three. ICE tries them in order of priority and uses the first that works.
How to tell if you need TURN
- Users on corporate or hotel networks report calls stuck on “connecting”.
- Calls work on Wi-Fi but fail on some mobile carriers.
- Your ICE logs show no successful candidate pair, or only
hostandsrflxcandidates that never connect.
To check a relay, run the TURN server tester with relay-only gathering. For production, generate time-limited credentials on your server so a copied password can’t be reused.
Sizing relay traffic
Relayed traffic is billed by volume. An hour of voice uses about 25–30 MB in each direction; an hour of 720p video about 1 GB. Multiply by the share of sessions that need a relay, commonly 10–20%, and more on corporate and cellular networks. The pricing calculator turns that into a monthly price.