Most video calls never touch a TURN server. The ones that need one cannot happen without it.
What is a TURN server? It is a relay on the public internet that carries a call's media when the two ends cannot reach each other directly. The client asks it for a relayed address, every packet of the call flows through it, and it forwards them on. The protocol is defined in RFC 8656, and it is built to be the last resort: WebRTC tries every direct path first and falls back to TURN only when none of them works.
The usual follow-up, "you need TURN for users behind NAT", was written for calls that go peer to peer. Most video products now send media through a server instead, and that changes when a call actually needs a relay.
What is a TURN server, exactly?
A TURN server does one job: it gives a client an address on the public internet that it can use as its own, and forwards whatever arrives there.
The client starts with an Allocate request. The server answers with a relayed transport address, an IP and port on the server that now belongs to that client. The client then grants permission for specific peers to send to it, and the server forwards traffic both ways. Permissions expire after five minutes unless refreshed, and the allocation itself after ten. For a steady media stream, the client can bind a channel, which shrinks the per-packet header to four bytes.
TURN can run over UDP, TCP, TLS or DTLS. The defaults are port 3478, and 5349 for the encrypted versions, though production deployments usually also listen on 443 because almost nothing blocks it.
That is the whole protocol. What makes it expensive, and easy to confuse with its sibling, is what it carries.
What is a TURN server versus a STUN server?
The two get named together because ICE uses both, but they do opposite amounts of work:
STUN | TURN | |
|---|---|---|
What it does | Tells a client its public address | Relays the media itself |
Media through the server? | No | Every byte, both directions |
Cost to run | Almost nothing | Bandwidth on every relayed stream |
When ICE uses it | Almost always, to discover addresses | Only when nothing direct works |
Because TURN carries everything, it is the one part of connectivity that shows up on a bill, and what that relay costs once it carries real traffic is a line most self-hosting models leave out.
Which raises the real question: how does a call decide it needs one?
Where TURN sits in ICE
WebRTC does not choose a path up front. ICE gathers every address a client could be reached on, called candidates, and tests pairs of them until one works.
There are three kinds of candidate that matter here. A host candidate is the device's own address. A server-reflexive candidate is the public address STUN discovered. A relay candidate is the address a TURN server allocated. RFC 8445 recommends ranking them by type: 126 for host, 100 for server-reflexive, and 0 for relay.
Zero is deliberate. A relay pair only wins when every higher-ranked pair has failed its connectivity checks. So "this call needed TURN" has a precise meaning: no direct path survived testing. The question is what makes direct paths fail, and the answer depends on what is at the other end.
When a peer-to-peer call needs TURN
When two clients connect directly, two different things can kill the direct path.
The first is NAT behaviour. If both sides sit behind NAT that assigns a new external port for every destination, which carrier-grade NAT on mobile networks commonly does, neither side can learn the other's address and the call must relay. The mechanics are in why a call connects on Wi-Fi but not on 4G.
The second is network policy: corporate firewalls that block outbound UDP, close ports, or force everything through a proxy.
The only substantial public measurement of how often this happens comes from callstats.io, reported on webrtcHacks: across billions of minutes from January 2015 to February 2016, 22% of conferences needed some kind of TURN relay, and 9% needed TCP. That is a decade old, and it was measured when far more calls ran peer to peer. Keep that second fact in mind, because it is about to matter.
When does an SFU call need a TURN server?
Most products no longer connect clients to each other. Each client sends media to a selective forwarding unit on a server, and the server forwards it on. That moves one end of every connection somewhere very different from a home router.
The NAT problem mostly disappears. An SFU sits on a public address with nothing to discover. RFC 8445 even defines a reduced mode for exactly this kind of endpoint, ICE lite, in which lite agents "only use host candidates". When one side of a connection is a fixed public address, the client sends first, the server replies to wherever that packet came from, and the path is established. A client behind the worst carrier-grade NAT can still reach it, because the server is always the predictable side. The pairing that forces relay in a peer-to-peer call, two unpredictable NATs facing each other, never happens.
Network policy does not disappear. If a firewall blocks outbound UDP, the client cannot reach the SFU's UDP port any more than a peer's. Many SFUs answer this without a relay by accepting ICE over TCP directly; LiveKit's documentation, for example, describes a TCP port "used when the client could not connect via UDP (e.g. VPN, corporate firewalls)". The media still goes straight to the server.
What is left is the strictest tier: networks that only allow TLS on 443, force traffic through an HTTP proxy, or permit outbound connections only to approved hostnames. That is where TURN over TLS on 443 earns its place, and the fallback ladder that gets through corporate firewalls walks each rung.
Network the client is on | Peer-to-peer call | Call through an SFU on a public address |
|---|---|---|
Home or office NAT | Direct, after hole punching | Direct to the SFU |
Carrier-grade NAT on both sides | TURN required | Direct to the SFU |
Outbound UDP blocked, TCP allowed | TURN over TCP or TLS | ICE over TCP to the SFU, where supported; otherwise TURN |
Only TLS on 443, proxy or hostname allowlist | TURN over TLS on 443 | TURN over TLS on 443 |
Read down the right-hand column and the pattern is clear. With an SFU, the reason for TURN shifts from NAT to policy, and policy problems concentrate on enterprise networks.
What that does to the relay share
This is reasoning from how the protocols behave, not a measurement, and it should be read that way. But it has a practical consequence: the 22% figure is a ceiling for an SFU-based product, not an estimate. Some of that 22% was NAT pairs that an SFU removes entirely.
Nobody has published an SFU-era equivalent, so the honest number is your own. Every session already records which candidate pair it selected and whether that pair is a relay, and collecting getStats evidence in production covers how to capture it across real users rather than guessing.
Two other things shift the share in practice. Enterprise-heavy products see more relaying than consumer ones, because that is where the restrictive policies sit. And a product that does not support ICE over TCP pushes every UDP-blocked user onto TURN, which raises the share without any change in the networks.
So do you still need to run TURN?
Almost certainly yes, just not for the reason most guides give. If any of your users join from corporate networks, some of them will be on a network where TLS on 443 is the only way out, and without a relay their calls do not start at all.
What changes is the sizing and the order of fallbacks. With an SFU, put direct UDP first, ICE over TCP second, and TURN over TLS on 443 last. Expect the relay to carry a minority of sessions concentrated in enterprise accounts, size it from your measured share rather than an inherited percentage, and remember that a relayed viewer still costs a second copy of every stream they receive.
The Bottom Line
A TURN server is a relay that carries a call's media when no direct path works, and ICE ranks it last on purpose. For peer-to-peer calls, NAT and firewalls both force it. For calls through an SFU on a public address, NAT mostly stops being a reason and network policy becomes the main one, which makes the old one-in-five figure a ceiling rather than a forecast. Keep TURN, size it from your own data, and give ICE over TCP a chance to go first.
What's Next
TURN is one line on a larger bill. For how relay traffic adds up alongside minutes, egress, recording and storage, see what your video bill actually adds up to.
Frequently Asked Questions
What is a TURN server used for?
A TURN server relays the audio and video of a WebRTC call when the two ends cannot connect directly. The client gets a relayed address on the server, and every packet passes through it. WebRTC uses it only after every direct path has failed.
What is the difference between STUN and TURN?
STUN tells a client what its public address looks like from outside, so a direct connection can be attempted; no media passes through it. TURN carries the media itself when a direct connection is impossible. STUN costs almost nothing to run; TURN costs bandwidth on every relayed stream.
Do I need a TURN server if I use an SFU?
Usually yes, but for fewer users. An SFU on a public address removes most NAT-related failures, because the client can always reach it directly. Users on networks that block UDP or allow only TLS on 443 still need a relay. Samvyo, based on SFU architecture, keeps TURN on infrastructure you control alongside the media path, so you choose where relays sit and can see how often they are used.
What percentage of WebRTC calls use TURN?
The only substantial public dataset, from callstats.io between January 2015 and February 2016, found 22% of conferences needed a relay. It was measured when many more calls ran peer to peer, so for an SFU-based product treat it as an upper bound and measure your own share.
What port does a TURN server use?
The defaults are 3478 for UDP and TCP, and 5349 for TURN over TLS or DTLS. Production deployments usually also offer TURN over TLS on 443, because it gets through firewalls that block everything else.
How can I tell if a call is using a TURN server?
Check the selected candidate pair in the call's WebRTC statistics: if its local or remote candidate type is "relay", the media is going through TURN. Collecting this across all sessions gives you your real relay share, which is the number to size TURN capacity on. Platforms that run TURN on your own infrastructure, such as Samvyo, also let you see relay traffic directly at the server.
