TURN (Traversal Using Relays around NAT)

What is TURN?

TURN (Traversal Using Relays around NAT) is a protocol that provides relay servers for WebRTC connections when direct peer-to-peer paths fail. Unlike STUN which just helps discover IP addresses, TURN actively relays all media and data between participants when NAT traversal through STUN proves impossible.

Think of TURN as the backup plan: when participants can't connect directly due to restrictive firewalls or symmetric NAT, TURN servers act as intermediaries, forwarding video, audio, and data between them. This ensures calls succeed even in the most challenging network conditions.

Standardized in RFC 5766 (updated in RFC 8656), TURN is the safety net that makes WebRTC reliable in production. While it adds latency and consumes server bandwidth, TURN's role as the fallback mechanism is essential—it's the difference between "call failed" and "call connected despite network obstacles."

Why TURN is Necessary

STUN works well for most connections (75-85%), but fails in specific scenarios:

Symmetric NAT: Creates different port mappings for each destination, making STUN-discovered addresses useless for peer connections
Both peers behind restrictive firewalls: Neither can accept incoming connections, preventing direct peer-to-peer
Corporate networks: Often employ strict security policies blocking peer-to-peer traffic entirely
Carrier-grade NAT (CGNAT): Mobile networks and some ISPs use multilayer NAT that STUN can't traverse

In these cases—roughly 15-25% of WebRTC connections—TURN is the only solution. Without TURN servers, these calls would simply fail.

How TURN Works: Step by Step

1. Connection Attempt with STUN Fails

ICE first tries direct connections using host and STUN-discovered server reflexive candidates. When all direct attempts fail (ICE connectivity checks timeout or fail), ICE moves to TURN relay candidates.

2. Client Allocates TURN Relay

The client sends an allocation request to a TURN server, providing authentication credentials (username/password). The TURN server validates credentials and allocates a relay address—a public IP and port on the TURN server dedicated to this client.

3. Relay Address Exchanged

The relay address becomes a "relay candidate" in ICE. This candidate is exchanged with the remote peer via signaling, just like STUN candidates were.

4. Connection Through TURN Relay

Both peers connect to their respective TURN servers and create permissions for the other peer's relay address. Media then flows: Client A → TURN server A → TURN server B → Client B (if both need TURN) or Client A → TURN server A → Client B (if only one needs TURN).

5. Media Relaying Begins

All video, audio, and data packets flow through the TURN server(s). The server simply forwards packets between authorized peers without inspecting or modifying content (media is still encrypted end-to-end via DTLS/SRTP).

TURN Transport Protocols

TURN supports multiple transport protocols, tried in order of preference:

TURN/UDP (Preferred)

UDP is the default for real-time media. Lower latency, no connection overhead, best for video/audio quality. Used when firewalls allow UDP traffic.

TURN/TCP (Fallback)

TCP is used when UDP is blocked. More reliable but higher latency and overhead. Some corporate networks only allow TCP traffic.

TURN/TLS (Last Resort)

TLS-encrypted TCP for the most restrictive networks. Disguises WebRTC traffic as HTTPS, bypassing deep packet inspection firewalls. Highest latency but works almost anywhere HTTPS does.

The Cost Problem

TURN is expensive compared to STUN. Here's why:

Bandwidth Consumption

TURN relays all media. A single HD video call can consume 2-4 Mbps per participant. If both participants use TURN, the server handles double that traffic (4-8 Mbps). In a 1-hour call, that's 1.8-3.6 GB of bandwidth.

With 15-25% of calls requiring TURN, bandwidth costs add up quickly. This is why TURN is typically the most expensive part of WebRTC infrastructure.

Server Resources

Each TURN relay consumes server CPU and network capacity. Servers need high bandwidth connections and must be globally distributed for low latency. Cloud providers charge for both bandwidth and compute time.

Real-World Costs

Typical costs: $0.05-$0.15 per GB of TURN traffic. For a service with 10,000 hours/month of TURN usage, expect $500-2000/month in bandwidth costs alone—far exceeding STUN server costs (nearly zero) or even SFU server costs.

Performance Impact

Added Latency

TURN adds latency because packets travel through an intermediary rather than directly between peers. Typical overhead: 50-150ms each direction depending on TURN server location. Total round-trip increase: 100-300ms.

This makes conversations feel slightly less natural but remains acceptable for most use cases. It's the price of connectivity when direct paths fail.

Quality Limitations

TURN server bandwidth can become a bottleneck. If the server's internet connection is slower than the client's, quality suffers. Proper TURN infrastructure requires high-bandwidth, low-latency connections—another cost factor.

Security Considerations

Authentication Required

TURN servers must authenticate clients to prevent abuse. Open TURN servers would be immediately exploited for bandwidth theft. Use time-limited credentials (typically valid for a few hours) generated server-side.

Media Encryption

Even though media flows through TURN servers, it remains encrypted via DTLS/SRTP. TURN servers can't decrypt the content—they just forward encrypted packets. End-to-end encryption is maintained.

2025 Best Practices

Always enable TLS for TURN signaling to prevent credential theft
Use strong authentication with short-lived tokens
Implement rate limiting to prevent abuse
Monitor bandwidth usage and set quotas per user/session
Keep server software updated to patch security vulnerabilities
Consider regional TURN servers to minimize latency

TURN Infrastructure Options

Self-Hosted TURN

Popular open-source implementations:

coturn: Most widely used, feature-rich, well-maintained
eturnal: Modern Erlang implementation, efficient and scalable

Pros: Full control, potentially cheaper at scale. Cons: Requires infrastructure management, global distribution complexity.

Managed TURN Services

Commercial providers like Twilio, Cloudflare Calls, Metered, and Xirsys offer TURN-as-a-service. Pay per GB or per minute.

Pros: No infrastructure management, global edge locations, automatic scaling. Cons: Higher per-GB costs, vendor lock-in.

Minimizing TURN Usage

Since TURN is expensive, applications try to minimize its use:

Prioritize STUN candidates: ICE tries direct connections first, only falling back to TURN when necessary
ICE restart on network change: If a participant switches from restrictive network (requiring TURN) to permissive one (STUN works), ICE restart can establish direct connection mid-call
Educate users: Inform enterprise users that corporate VPNs may force TURN usage. Disconnecting from VPN might enable direct connections

STUN vs TURN Summary

Understanding the complementary roles:

STUN: Discovery service. Helps find public IPs. No media relay. Free to operate. Works 75-85% of time. Zero added latency for connections
TURN: Relay service. Forwards all media. Expensive bandwidth costs. Required for 15-25% of connections. Adds 100-300ms latency

Both are essential: STUN for efficiency, TURN for reliability.

Why TURN Remains Critical in 2025

Despite advances in WebRTC, NAT types, and network infrastructure, TURN remains indispensable:

Enterprise networks continue using symmetric NAT and restrictive firewalls for security
Mobile carriers deploy CGNAT to conserve IPv4 addresses
Government and corporate policies mandate centralized traffic routing
IPv6 adoption, while growing, hasn't eliminated NAT

The 15-25% TURN usage rate has remained remarkably stable over the years. Every production WebRTC application must budget for TURN infrastructure—it's not optional.

The Bottom Line

TURN is WebRTC's insurance policy. It's expensive, adds latency, and only needed for a minority of connections—but that minority would otherwise have zero connectivity.

By providing relay infrastructure that works even in the most restrictive network conditions, TURN ensures WebRTC lives up to its promise of universal browser-to-browser communication. The cost is real, but the alternative—failed calls—is unacceptable for production applications.

Understanding TURN helps you budget appropriately for WebRTC infrastructure, design systems that minimize TURN usage when possible, and appreciate why those "15-25% of connections" represent the difference between a reliable service and an unreliable one.

References

TURN: Traversal Using Relays around NAT - BlogGeek.me
Turn Server for WebRTC: Complete Guide to NAT Traversal and Reliable Connectivity (2025) - VideoSDK
What is a TURN server? (Traversal Using Relays around NAT) - Metered
Introduction to WebRTC protocols - Mozilla Developer Network
TURN server - WebRTC.org