A TURN server (Traversal Using Relays around NAT) is a relay that forwards real-time audio and video between two peers when direct peer-to-peer connection is blocked by NATs or firewalls. Unlike STUN, which only helps peers discover their public addresses, TURN actively relays every media packet, guaranteeing connectivity in restrictive networks. VideoSDK handles this infrastructure automatically, so your video calls connect reliably without you operating TURN servers yourself. See the VideoSDK quickstart docs to get started.
Every developer who builds real-time video or audio calling eventually hits the same wall: the app works perfectly in testing, then a user on a corporate network or hotel Wi-Fi simply cannot connect. The call fails not because of your code, but because the network itself refuses to let media packets travel directly between two devices. That wall is where the question "what is a turn server" stops being academic and becomes the difference between a product that works for 92% of users and one that works for everyone.
This guide explains what a TURN server is, how it fits into WebRTC's connection machinery, when you need one versus a STUN server, and how teams deploy and maintain TURN infrastructure in 2026. By the end, you will understand the full relay architecture and be able to choose the right TURN strategy for your application.
What Is a TURN Server?
A TURN server is defined as a network relay, standardized in RFC 5766, that receives media packets from one peer and forwards them to the other when direct peer-to-peer transport is impossible. TURN stands for Traversal Using Relays around NAT, and the name describes the mechanism precisely: when Network Address Translation (NAT) or a firewall blocks the direct path, traffic routes around the obstruction through a server with a publicly reachable address.
In WebRTC and other real-time protocols, TURN is the connectivity method of last resort. Before any media flows, the connecting peers first try to talk directly using their local addresses, then attempt NAT hole-punching with STUN. Only when both of those approaches fail does the session fall back to TURN, sending every audio and video packet through the relay.
VideoSDK provides this capability as part of its managed real-time communication infrastructure. When you build with the VideoSDK video calling SDK, TURN and STUN traversal are handled by the platform's cloud, so restrictive networks do not translate into failed calls for your users.
How TURN Works: The Relay Concept
The simplest way to understand a TURN server is a roadblock analogy. Imagine two people who want to meet, but a closed road sits between their neighborhoods. A STUN server is like a signpost that tells each person their exact street address so they can try alternate routes. A TURN server is a mutual friend's house: both people travel there, and messages pass through it in both directions.
Technically, each client opens a persistent connection called an allocation to the TURN server. The server assigns the client a relayed address, and the remote peer sends its media to that address. The server then forwards packets to the client over the allocation. Media never travels directly between peers; the relay is the path.
Why Do You Need a TURN Server?
Roughly 8 to 10 percent of real-world WebRTC sessions cannot establish a direct peer-to-peer path, and in enterprise environments that percentage climbs significantly. A TURN server exists to guarantee connectivity for exactly those sessions.
The most common failure scenario is symmetric NAT. In this NAT type, the router assigns a different public port for every destination the client contacts. Because the port observed by the outside world changes depending on where packets are sent, hole-punching techniques that work with other NAT types fail here. Corporate firewalls add a second failure mode: many block all UDP traffic outright or only permit connections initiated from inside the network.
The benefits of deploying TURN are substantial:
- Connection success approaching 100 percent, because the relay's public address is reachable from any network that allows outbound internet traffic.
- Media reliability, since the relay path is stable and does not depend on hole-punching timing.
- Preserved security, because TURN relays encrypted media without decrypting it. In WebRTC, the payload is encrypted end to end with DTLS-SRTP, so the TURN server forwards ciphertext it cannot read.
The trade-offs are equally real. A TURN server consumes bandwidth for every relayed session, often the single largest infrastructure cost in a self-hosted WebRTC deployment. Relaying adds latency, typically adding the round trip to the server on every packet. And operating your own TURN infrastructure means patching, monitoring, and capacity planning. This is why many teams conclude that a managed platform like VideoSDK, which includes traversal infrastructure, is more economical than self-hosting relays at scale.
TURN vs. STUN: Quick Comparison
The distinction between STUN and TURN confuses many developers, so the comparison deserves its own table. STUN (Session Traversal Utilities for NAT, RFC 5389) helps a client discover its public IP and port. TURN goes further and relays the actual media.
| Dimension | STUN Server | TURN Server |
|---|---|---|
| Primary role | Discovers public address | Relays all media packets |
| Bandwidth on server | Negligible | High, proportional to media traffic |
| Connection success rate | Fails on symmetric NAT and strict firewalls | Succeeds wherever outbound traffic is allowed |
| Latency impact | None | Adds relay round-trip time |
| Typical usage | First-line NAT discovery | Fallback for blocked connections |
| Cost profile | Very cheap to run | Expensive at scale due to bandwidth |
In practice, every serious WebRTC deployment configures both. STUN handles the easy majority of sessions; a TURN server rescues the hard minority.
The Technical Backbone: ICE, Candidates, and Allocation
TURN never operates alone. It is one tool inside ICE, the Interactive Connectivity Establishment framework that WebRTC uses to find a working path between two peers. Understanding ICE explains why TURN is described as the last resort.
ICE works by gathering candidates, which are possible addresses a peer can be reached at. There are three kinds:
- Host candidates are the device's local network addresses, useful only when both peers sit on the same LAN.
- Server-reflexive candidates are the public addresses a STUN server reports back to the client, enabling NAT hole-punching.
- Relayed candidates are the addresses a TURN server allocates on the client's behalf, reachable from anywhere.
ICE then tests candidate pairs in priority order, cheapest first. Local host-to-host paths are tried first, then STUN-assisted paths, and only if every direct option fails does ICE settle on the TURN relay path. This priority ordering is why most sessions never touch the TURN server at all, keeping bandwidth costs manageable.
The TURN allocation process itself follows a request-response cycle. The client authenticates to the server using the long-term credential mechanism, a challenge-response scheme where the server issues a nonce and realm and the client proves knowledge of a shared secret. Once authenticated, the client requests an allocation, the server reserves relay ports in its relay port range and returns a relayed address plus a lifetime value. The client keeps the allocation alive by refreshing it periodically, and permissions are installed so the server only forwards traffic from approved remote peers.
Setting Up Your Own TURN Server
When you do need your own relay, the standard choice is coturn, the open-source TURN and STUN implementation used across the industry. It supports both protocols, TLS transport, and the long-term credential mechanism out of the box.
Before installation, verify your prerequisites. The server needs a machine with a public IP address, ideally a virtual private server in a region close to your users, since relay latency directly affects call quality. You also need control over the firewall, because TURN uses several port ranges.
The setup follows four phases:
- Preparation. Provision a server with a public IP and decide your authentication realm, which is a namespace that groups your credentials, typically your domain name.
- Installation. Install coturn from your operating system's package repository or build it from the official source on GitHub.
- Configuration. Define the listening addresses, the external public IP the server advertises, the relay IP used for allocating relayed addresses, your user credentials, and enable the long-term credential mechanism so unauthenticated allocations are rejected.
- Firewall rules. Open the primary TURN ports, 3478 for UDP and TCP and 5349 for TURN over TLS, plus the relay port range 49152 through 65535, which is where the server allocates relayed addresses for each session.
Security deserves emphasis. Always run TURN over TLS on port 5349 so credentials and signaling are encrypted in transit. Use the long-term credential mechanism rather than anonymous access, and generate strong per-application secrets. Restrict the relay port range to what you actually need, and consider IP allowlisting if your deployment serves a known set of application servers.
Common Configuration Options
The most important coturn settings map directly to the concepts above. The listening IP and listening port define where the server accepts connections, typically 3478. The external IP tells the server what public address to advertise when it sits behind cloud NAT, common on AWS and Google Cloud. The relay IP specifies which address relayed allocations bind to. The user setting registers username and secret pairs for authentication. The realm defines the authentication namespace, and enabling the long-term credential mechanism activates the challenge-response flow described earlier.
Using Public TURN Services
Running your own relay is not the only option. Managed TURN providers, including Cloudflare Calls, Metered.ca, and Azure Communication Services, offer TURN as a service with global relay points and usage-based pricing.
Free public TURN servers exist and are useful for development and testing, but they come with hard bandwidth caps, no uptime guarantees, and shared capacity, which makes them unsuitable for production. Premium services add dedicated capacity, geographic distribution to minimize relay latency, monitoring dashboards, and support.
The decision usually comes down to scale. At small scale, a managed TURN service removes operational burden entirely. At large scale, self-hosted coturn on cloud instances in your primary regions can be cheaper, at the cost of owning monitoring and capacity planning. Many teams instead choose a real-time communication platform like VideoSDK, where TURN infrastructure, media routing, and network-adaptive streaming are all included, eliminating the self-hosting question altogether.
Monitoring and Maintaining a TURN Server
A TURN server in production is a bandwidth-hungry, business-critical component, and it needs observability. The metrics that matter most are relay bandwidth, which drives both cost and capacity planning; allocation failure rate, which spikes when credentials expire or the relay port range is exhausted; and relay latency, which degrades call quality when a server becomes overloaded or is poorly placed geographically.
Log analysis reveals patterns that dashboards miss, such as a single user group whose sessions always fall back to TURN, indicating a corporate network that deserves a dedicated relay closer to those users. Health checks should verify that the service responds on both the primary and TLS ports and that allocations succeed end to end.
Scaling a TURN deployment is horizontal: add relay instances in the regions where your users concentrate and let clients connect to the nearest one. Because each allocation is independent, no shared state is required between relay servers, which makes this scaling model simple. The one resource to watch is the relay port range per instance, since each active allocation consumes ports from it.
Definitions Glossary
TURN server: A relay server, standardized in RFC 5766, that forwards real-time media between peers when direct connection is blocked by NAT or firewalls. VideoSDK's cloud includes TURN traversal so calls connect even on restrictive networks.
STUN server: A lightweight helper, defined in RFC 5389, that tells a client its public IP address and port so peers can attempt direct connection. It relays no media and fails on symmetric NAT.
NAT traversal: The set of techniques, including STUN discovery and TURN relaying, used to establish connectivity between devices behind Network Address Translation routers.
ICE (Interactive Connectivity Establishment): The WebRTC framework that gathers host, STUN, and TURN candidates and tests them in priority order to find the first working media path between two peers.
TURN allocation: A session a client opens with a TURN server, authenticated via the long-term credential mechanism, through which the server relays media on the client's behalf.
Relayed candidate: The public address a TURN server assigns to a client during allocation, usable by any remote peer regardless of the client's network restrictions.
Key Takeaways
- A TURN server is a media relay that guarantees WebRTC connectivity when direct peer-to-peer paths are blocked by symmetric NAT or strict firewalls, covering the roughly 8 to 10 percent of sessions that STUN cannot.
- STUN discovers public addresses while TURN relays actual media, so production deployments always configure both, with TURN as the expensive but reliable fallback.
- ICE gathers host, STUN, and TURN candidates and tests them cheapest first, which is why most sessions never touch the relay and bandwidth costs stay manageable.
- Self-hosting with coturn requires a public IP, open ports 3478, 5349, and the 49152 to 65535 relay range, TLS, and long-term credential authentication.
- Managed platforms like VideoSDK include TURN traversal, media routing, and network-adaptive streaming as part of the video calling SDK, removing the operational burden of running relays yourself.
Conclusion
Understanding what a TURN server is means understanding the last line of defense for real-time communication: a standardized relay that carries encrypted media around NATs and firewalls when every direct path fails. Evaluate your application's network environment, estimate how many sessions will need relaying, and choose between self-hosted coturn, a managed TURN service, or a full RTC platform that handles traversal for you. If you want reliable video calls without operating relay infrastructure, start with the VideoSDK quickstart or create a free account at app.videosdk.live. What are you building with real-time communication? Drop a comment, I'd love to hear what kind of TURN and NAT traversal challenges your use case faces.
Free $20 Balance for AI Voice Agents & Video Calls
FAQ