A WebRTC TURN server relays media traffic between two peers when a direct connection cannot be established between them, typically because a restrictive network configuration blocks the direct path entirely. TURN stands for Traversal Using Relays around NAT, and it exists specifically to handle the connection scenarios where WebRTC's preferred, more efficient connection methods fail.
This guide covers what a TURN server actually does, how it differs from STUN, exactly when WebRTC falls back to using one, the real bandwidth cost of running one, and how to decide between self-hosting and a managed TURN service.
What Is a TURN Server?
A TURN server is a relay server that forwards media traffic between two WebRTC peers when a direct connection between them cannot be established, functioning as the connection method of last resort within WebRTC's ICE framework.
A TURN server is a relay server that sits between two WebRTC peers and forwards their media traffic when a direct connection between them is not possible. Rather than the two devices exchanging audio and video data directly, both send their traffic to the TURN server, which forwards it to the other party.
This relay function matters specifically because many real-world network configurations prevent a direct connection between two devices entirely. Restrictive firewalls, certain types of network address translation, and corporate network policies can all block the direct connection paths WebRTC prefers, making a relay the only viable path for the call to succeed at all.
TURN is defined formally in IETF RFC 8656, the current specification governing how this relay mechanism operates within the broader WebRTC connectivity framework.
How Does a TURN Server Work?
A TURN server works by allocating a relay address for a WebRTC client and forwarding media traffic between both peers through that relay address, activated specifically after WebRTC's ICE negotiation process determines a direct connection cannot be established.
A TURN server works through a specific allocation and relay process that activates only when direct connectivity has already failed.
Allocation. A WebRTC client requests an allocation from the TURN server, receiving a relay address the server will use to forward traffic on that client's behalf.
Permission establishment. The TURN server establishes permissions determining which remote peer is allowed to send traffic through that specific relay allocation, a security measure preventing the relay from being used by unauthorized parties.
Relay forwarding. Once both peers have completed this process, the TURN server forwards media packets between them, with each peer sending its traffic to the server rather than directly to the other party.
This entire mechanism only activates after WebRTC's ICE negotiation process has already attempted and failed at establishing a more direct connection, which is the specific trigger condition covered in more detail further in this guide.
STUN vs TURN: What's the Difference?
STUN and TURN solve different problems within WebRTC's connectivity framework. STUN helps a device discover its public-facing IP address and port to attempt a direct connection. TURN relays the actual media traffic when a direct connection, even with STUN's help, cannot be established at all.
STUN vs TURN is a common point of confusion, and the distinction matters directly for understanding WebRTC infrastructure correctly.
STUN, Session Traversal Utilities for NAT, defined in IETF RFC 5389, helps a device discover its own public-facing IP address and port as seen from outside its local network. This information allows two peers to attempt a direct connection to each other's actual, externally visible address, even though each device sits behind its own network address translation.
TURN goes further, relaying the actual media traffic itself when even a STUN-assisted direct connection attempt fails. TURN does not just help discover an address; it becomes an active intermediary carrying every packet of the call.
The practical distinction: STUN is a lightweight, one-time address discovery exchange. TURN is an ongoing relay service carrying the full media stream for the duration of the call, which is also why TURN carries meaningfully higher operational and bandwidth cost than STUN.
Why You Need a TURN Server for WebRTC
A TURN server is necessary for WebRTC because a meaningful share of real-world network configurations, particularly symmetric NAT and restrictive corporate firewalls, prevent a direct peer-to-peer connection entirely, and without a TURN fallback, those connections fail outright rather than degrading gracefully.
Without a TURN server, a meaningful share of real-world WebRTC connection attempts fail completely, not just perform worse.
Symmetric NAT is a specific type of network address translation where the mapping between an internal and external address changes depending on the destination, which defeats the address discovery STUN provides and prevents a direct connection from forming at all.
Restrictive corporate firewalls frequently block the kind of peer-to-peer traffic WebRTC's direct connection attempts rely on, a common condition for any application expecting to be used from business network environments.
Mobile and carrier-grade NAT configurations, increasingly common on mobile networks, can similarly prevent the direct connectivity STUN-assisted connections depend on.
Any production WebRTC application expecting to serve users across a realistic range of network environments needs TURN as a fallback, not an optional enhancement, since the alternative to a successful TURN relay in these scenarios is a failed call entirely.
When Does WebRTC Actually Use a TURN Server?
WebRTC uses a TURN server only as a last resort, after ICE negotiation has already attempted a direct host-to-host connection and a STUN-assisted connection, both of which are tried first because they offer lower latency and do not require relaying traffic through an intermediate server.
WebRTC does not default to TURN for every call. ICE negotiation follows a specific priority order, attempting more efficient connection types first.
Host candidates are attempted first, a direct connection using each device's local network address, viable only when both devices happen to be on the same local network.
Server reflexive candidates, discovered through STUN, are attempted next, allowing a direct connection using each device's public-facing address as discovered through the STUN exchange.
Relay candidates, provided by a TURN server, are used only when neither of the first two approaches succeeds, making TURN genuinely the connection method of last resort within this priority order.
This sequencing matters because each step up this list introduces additional latency and, for TURN specifically, ongoing relay cost. A connection that succeeds at the host or server reflexive stage never touches the TURN server at all, which is why TURN usage in a production deployment typically represents a meaningful minority of total calls, not every single one.
TURN Server Costs and Bandwidth Considerations
Running a TURN server carries a real, ongoing bandwidth cost, since it relays the full media stream for every call that falls back to it, unlike STUN's lightweight, one-time address discovery exchange, making TURN usage rate and bandwidth planning a genuine cost consideration for production WebRTC deployments.
TURN's relay function means it carries a materially different cost profile than STUN, and this is worth planning for directly rather than discovering unexpectedly after deployment.
Every call that falls back to the TURN relay sends its full media stream through the TURN server's bandwidth, for the entire duration of that call. A deployment with a higher share of calls falling back to TURN, due to a user base concentrated in restrictive network environments, will carry meaningfully higher bandwidth costs than one where most calls succeed through direct or STUN-assisted connections.
Estimating TURN usage rate ahead of deployment, based on the expected network environments of the actual user base, rather than assuming a low, generic fallback rate, produces a more accurate cost projection for production planning.
Self-Hosted vs Managed TURN Servers
Self-hosting a TURN server using open-source software such as coturn offers full infrastructure control at the cost of operational responsibility, including capacity planning and maintenance, while a managed TURN service trades that control for reduced operational overhead.
Choosing between self-hosting and a managed TURN service comes down to a familiar tradeoff between control and operational burden.
Self-hosted TURN servers, commonly deployed using the open-source coturn software, give a team full control over configuration, geographic placement, and capacity, at the cost of owning the ongoing operational responsibility: monitoring, scaling, and maintaining that infrastructure directly.
Managed TURN services handle that operational burden on the customer's behalf, typically offering global relay presence without requiring the customer to deploy and maintain servers in every relevant region themselves, at the cost of less direct control over the underlying infrastructure.
A team with existing infrastructure operations capacity and specific geographic or configuration requirements may reasonably self-host. A team without dedicated infrastructure operations capacity, or one needing broad global relay presence quickly, is typically better served by a managed service.
TURN Server Security Considerations
TURN server security depends heavily on proper credential management, since exposed or long-lived TURN credentials create a persistent exposure risk, covered in more depth in our broader guide to WebRTC security, which identifies this as one of the most common WebRTC security misconfigurations in practice.
TURN credential security deserves specific attention, since it is one of the most common WebRTC security misconfigurations covered in our broader guide to WebRTC security, encryption, SRTP, and DTLS.
Credentials embedded directly in client-side code, or never rotated on a defined schedule, create a persistent exposure risk, since a leaked credential remains valid indefinitely rather than expiring. Short-lived, scoped TURN credentials, rotated regularly, limit the exposure window if a credential is ever compromised, a meaningfully stronger practice than static, long-lived alternatives.
Enterprise Use Cases: TURN Server Deployment by Context
TURN server deployment priorities differ by context. Global distributed teams, enterprise networks with strict firewalls, and telehealth platforms each weigh geographic relay coverage and reliability differently based on their specific operational requirements.
Global Distributed Teams
Problem: Teams distributed across many countries experience varied network conditions, and a TURN deployment concentrated in one geographic region adds latency for calls relayed from distant locations.
Solution: Deploying TURN relay presence across multiple geographic regions, matched to where the team actually operates from, reduces the added relay distance for calls that do fall back to TURN.
Outcome: Calls relayed through TURN experience lower added latency, since the relay point sits geographically closer to the actual participants rather than routing through a single distant region.
Enterprise Networks with Strict Firewalls
Problem: Enterprise customers often connect from corporate networks with restrictive firewall policies specifically designed to block the kind of peer-to-peer traffic WebRTC's direct connection attempts rely on.
Solution: Ensuring reliable TURN fallback, including testing against common corporate firewall configurations directly, confirms calls succeed for this specific, high-value user segment rather than failing silently.
Outcome: Enterprise users on restrictive corporate networks experience reliable call connectivity through TURN relay, rather than the application failing specifically for this segment of the user base.
Telehealth Platforms
Problem: Telehealth platforms need highly reliable call connectivity, since a failed connection directly affects a patient's ability to access care, making TURN fallback reliability a clinical, not just technical, consideration.
Solution: Deploying TURN infrastructure with sufficient capacity and redundancy specifically to avoid relay-related call failures, treating TURN reliability with the same seriousness as any other clinical system dependency.
Outcome: Patients experience consistent call connectivity regardless of their specific network environment, supporting reliable access to care rather than risking a failed connection at a clinically significant moment.
Decision Tree: Do You Need to Self-Host or Use a Managed TURN Service?
RTC LEAGUE TURN Server Deployment Framework v1.0
A four-step framework for deploying TURN server infrastructure for a production WebRTC application, covering usage rate estimation, geographic placement planning, credential security configuration, and capacity monitoring, in the order they should be addressed.
Deploying TURN infrastructure without this sequence typically produces either underprovisioned capacity or an avoidable security gap discovered only after launch. The RTC LEAGUE TURN Server Deployment Framework v1.0 orders the process correctly.
Step 1: Estimate expected TURN usage rate. Project the share of calls likely to fall back to TURN based on the expected network environments of the actual user base, rather than assuming a generic, low fallback rate.
Step 2: Plan geographic relay placement. Deploy TURN capacity in the regions matching where actual users and calls originate, reducing added latency for calls that do fall back to relay.
Step 3: Configure short-lived, scoped credentials. Implement credential rotation on a defined schedule rather than static, long-lived credentials embedded in client code.
Step 4: Monitor capacity and usage rate on an ongoing basis. Track actual TURN usage against the initial estimate, adjusting capacity planning as real usage data becomes available rather than relying solely on the pre-launch projection.
Outcome: Completing this sequence produces a TURN deployment sized and secured appropriately for actual production conditions, rather than one based on an untested assumption about usage rate or credential security.
RTC LEAGUE's Approach to TURN Infrastructure
RTC LEAGUE deploys TURN infrastructure as an integrated part of its WebRTC and AI voice platform builds, with usage estimation, geographic placement, and credential security addressed explicitly as part of the deployment process rather than left as a separate, disconnected infrastructure decision.
RTC LEAGUE treats TURN infrastructure as a core part of any WebRTC or AI voice platform deployment, not an afterthought addressed only if connectivity issues surface after launch. Usage rate estimation, geographic placement, and credential security practices covered throughout this guide are addressed explicitly during the build process.
This reflects the same underlying principle covered across our broader WebRTC infrastructure guides: the areas outside WebRTC's own mandatory guarantees, including TURN deployment and credential management, require deliberate planning rather than an assumption that default configuration is sufficient for production use.
Conclusion and Recommendation
A WebRTC TURN server relays media traffic when a direct peer-to-peer connection cannot be established, serving as the connection method of last resort after direct and STUN-assisted attempts fail. It is not required for every call, but without it, a meaningful share of real-world connections, particularly from corporate networks and symmetric NAT configurations, fail entirely rather than degrading gracefully.
Running a TURN server carries a real bandwidth cost proportional to how many calls actually fall back to relay, which makes usage rate estimation a genuine production planning consideration, not an afterthought. Credential security deserves the same deliberate attention as any other WebRTC infrastructure component, since exposed or static TURN credentials remain a common, avoidable vulnerability.
The clearest recommendation: deploy TURN as a required fallback for any production WebRTC application, estimate usage rate based on your actual user base's network conditions, plan geographic placement accordingly, and implement short-lived, rotated credentials rather than static ones.
-(1).jpg)
.jpg)