TL;DR: TURN is a relay server that carries video between two people when they cannot connect directly. STUN only helps them find each other and costs almost nothing. TURN carries the actual media, which makes it the expensive part of running video infrastructure. Estimates of how many calls need it range from around 15 percent to 50 percent depending on your users.
TURN is the part of video infrastructure that quietly determines your bandwidth bill, and most teams meet it for the first time in a cost review.
It is also the reason some video calls fail on corporate networks while working perfectly at home. Understanding it takes about five minutes and saves a lot of confusion later.
TURN stands for Traversal Using Relays around NAT. It is a server that relays audio and video between two participants when a direct connection between them is blocked, usually by a firewall or a restrictive corporate network. Without TURN, those calls simply fail.
WebRTC always prefers a direct path between two devices, because direct is faster and free. When network conditions make that impossible, media has to travel through a middleman instead. TURN is that middleman.
The important consequence is that TURN handles real media, not just connection setup. Every byte of video in a relayed call passes through your server twice, once in and once out.
What is the difference between STUN and TURN?
STUN only tells a device its own public address so two peers can attempt a direct connection. It carries no media and is cheap to run. TURN relays the media itself when that direct attempt fails, which makes it expensive in bandwidth and adds latency.
| STUN | TURN | |
|---|---|---|
| Carries media | No | Yes |
| Bandwidth cost | Negligible | Substantial |
| Adds latency | No | Yes |
| Used when | A direct path exists | Direct is blocked |
A useful way to remember it: STUN is a map, TURN is a courier. One tells you the route. The other carries the parcel and charges you for it.
How many calls actually need TURN?
Published estimates vary widely, from roughly 15 percent of sessions up to 50 percent, because it depends entirely on your users. Consumer users on home broadband rarely need relay. Enterprise users behind strict corporate firewalls need it far more often, which matters if you sell to enterprises.
One widely cited estimate holds that around 85 percent of the time STUN alone is enough, with anywhere between zero and 50 percent of sessions going via relay depending on the user base. Other analyses put the relay share nearer 30 percent of connections.
The spread is the point. You cannot plan capacity from an industry average, because your relay rate is a property of who your users are and what networks they sit behind.
The bandwidth arithmetic is unforgiving. A 720p call pushes roughly 2 to 3 Mbps through the relay, so 1,000 concurrent calls with 40 percent hitting relay works out around 800 to 1,200 Mbps of sustained bandwidth you are paying for.
Do you need to think about TURN at all?
Only if you are building on raw WebRTC or self-hosting. If you use a hosted video API, the provider runs the relay network and absorbs the bandwidth, so TURN becomes their operational problem rather than a line item on your infrastructure bill.
This is one of the clearest practical differences between building and buying. Teams that build must deploy relay servers in multiple regions, monitor them, and pay for every relayed byte. Teams that use a hosted platform never configure one.
It is also the cost that self-hosting evaluations most often miss, because it does not appear at all in a prototype tested on one office network. Our guide to open-source trade-offs covers the wider version of that problem.
Frequently Asked Questions
TURN stands for Traversal Using Relays around NAT. It is a server that relays audio and video between two participants when a direct connection is blocked, usually by a firewall or restrictive corporate network. Without a TURN server available, those calls fail to connect.
STUN only tells a device its own public address so two peers can attempt a direct connection, carrying no media and costing almost nothing. TURN relays the media itself when the direct attempt fails, which consumes real bandwidth and adds latency to the call.
Published estimates range from roughly 15 percent to 50 percent of sessions, because the figure depends on your user base. Consumer users on home broadband rarely need relay, while enterprise users behind strict corporate firewalls need it considerably more often.
Because it carries the actual media rather than just connection details. A 720p call pushes roughly 2 to 3 Mbps through the relay, in and out, so a few hundred concurrent relayed calls translates into hundreds of Mbps of sustained bandwidth that you pay for continuously.
No. Hosted video providers operate their own relay networks and absorb the bandwidth cost as part of the service. You only need to deploy, monitor, and pay for TURN infrastructure if you are building on raw WebRTC or self-hosting an open-source platform.
Related guides
- Start with the complete video conferencing API guide
- See what else WebRTC leaves out
- Learn what an SFU does for group calls
- Weigh the full cost of self-hosting
Rather not operate relay infrastructure?
A hosted meeting API removes TURN, media servers, and bandwidth planning from your roadmap entirely. We will show you what the integration looks like against your requirements.
