TURN vs STUN Servers: What They Do and How to Size Them for WebRTC

Overview

The short version is simple: STUN helps a client discover how it appears on the public internet, while TURN relays traffic when direct peer-to-peer paths do not work. In many WebRTC deployments, STUN is lightweight and inexpensive, and TURN is the heavier component that carries real media when restrictive networks, firewalls, or NAT behavior block direct connectivity.

That difference matters because TURN is often where costs and capacity planning become real. A STUN request is usually brief. A TURN session may forward audio, video, and data for the full length of a meeting. If your users often connect from mobile networks, enterprise Wi-Fi, hotel networks, schools, or locked-down office environments, relay usage can rise quickly.

It also helps to separate signaling from traversal. Your signaling service gets peers into the same session and exchanges session descriptions and ICE candidates. STUN and TURN participate later, during ICE gathering and connectivity checks, helping the endpoints determine the best path for media. That path may be direct, server-reflexive, or relayed.

For teams evaluating a WebRTC platform or building their own media stack, the practical question is not whether TURN or STUN is “better.” They solve different problems:

• STUN is for discovery. It tells a client its public-facing address and port as seen from outside the local network.
• TURN is for relay. It gives the client a server-side address and forwards traffic through that server when direct routes fail.

In a healthy setup, you want direct paths whenever possible because they reduce relay costs and often lower infrastructure load. But you also want reliable TURN coverage because failed calls are more expensive than relayed calls. The right design balances quality, reliability, and relay budget.

If you are new to the surrounding protocol choices, it may help to read WebRTC vs RTMP vs SRT vs HLS: Which Streaming Protocol Should You Use? and SIP vs WebRTC: When to Use Each for Voice and Video Communications alongside this guide.

How to compare options

The most useful way to compare TURN vs STUN is to compare what they demand from your infrastructure, your users, and your budget. This section gives you a planning lens you can reuse when your traffic patterns change.

1. Compare them by role in the connection path

STUN supports candidate discovery and helps establish whether a direct path is possible. TURN steps in when a direct path is not viable. This means STUN improves the odds of a direct connection, but TURN protects the session when those odds are poor.

For planning, that means:

• STUN affects connection setup and discovery.
• TURN affects media transport, bandwidth consumption, and session durability.

2. Compare them by resource intensity

A STUN server usually handles small request and response exchanges. A TURN server may carry the full media stream. That changes almost everything operationally: CPU expectations, network throughput, egress planning, regional placement, and monitoring priorities.

When people ask whether they need “a WebRTC TURN server,” what they usually mean is: How much relay capacity do we need when direct paths fail? That is a bandwidth and concurrency question more than a feature checklist question.

3. Compare them by failure impact

If STUN underperforms, clients may still connect through TURN in some cases, though setup quality can degrade. If TURN capacity runs out or is badly placed, users behind restrictive networks may not connect at all, or their media quality may collapse. So TURN tends to be the reliability backstop.

For user-facing products, this makes TURN a first-class production dependency rather than a minor accessory.

4. Compare them by security and access control

Both services should be configured carefully, but TURN deserves extra attention because it can relay significant traffic. In practice, teams often focus on:

• Short-lived credentials
• Authenticated access
• TLS or secure transport where needed
• Rate limiting and abuse controls
• Restricted port and protocol policies aligned to your application

If you already use token-based access in a video API platform or real-time communication API, keep credential issuance for TURN aligned with the same security model. This is less about complexity and more about reducing loose ends in production.

5. Compare them by geography

TURN placement matters because every relayed packet travels through the relay. If the relay is far from both participants, latency rises and quality may suffer. STUN also benefits from sensible regional placement, but TURN usually has the larger user impact because it stays in the media path.

As a planning rule, think in terms of user clusters rather than global averages. A relay region that works well for creators in one country may perform poorly for viewers, guests, or hosts elsewhere.

6. Compare them by relay ratio

Your most important planning metric is often the relay ratio: the share of sessions or participants that end up using TURN. This ratio is not fixed. It can change with device mix, network environment, enterprise adoption, product features, and geography.

A consumer app on mostly home broadband may see a lower relay ratio than an enterprise tool used in offices with strict firewalls. A creator interview product that invites external guests may see highly variable relay usage because guest network quality is unpredictable.

That is why relay sizing for WebRTC should begin with measured assumptions, not ideal network diagrams.

Feature-by-feature breakdown

Here is the practical breakdown of what STUN and TURN actually do, and what that means for system design.

STUN server explained

STUN helps a client learn its server-reflexive address: the public IP and port mapping that a remote party may use to reach it. In the ICE process, that information becomes one of several candidate types that peers can test.

What STUN is good for

• Supporting NAT traversal WebRTC flows where direct connectivity is possible
• Reducing relay dependence when network conditions are favorable
• Keeping infrastructure costs lower than always-relayed designs

What STUN does not do

• It does not guarantee connectivity through restrictive NATs or firewalls
• It does not carry media once a relayed path is required
• It does not replace TURN in enterprise or hostile network conditions

Operational profile

STUN is generally lighter to operate. The main concerns are availability, regional responsiveness, and integration into ICE gathering. It should still be monitored, but it rarely becomes your dominant media cost center.

WebRTC TURN server explained

TURN allocates a relay address on the server and forwards traffic between peers when direct candidates fail. In effect, the TURN server becomes an intermediary transport path.

What TURN is good for

• Making connections work behind strict NATs and firewalls
• Improving session reliability across difficult network environments
• Supporting products where connection success matters more than minimizing relay cost

What TURN changes operationally

• Bandwidth scales with media traffic, not just setup requests
• Regional deployment becomes more important
• Egress and capacity planning become central
• Authentication, abuse prevention, and observability matter more

What TURN does not solve by itself

• Poor encoding choices
• Unstable last-mile networks
• Application-level congestion mistakes
• Broader video streaming infrastructure issues outside the relay path

How to size TURN capacity

This is the part many teams need most. You do not need a perfect forecast, but you do need a model that is conservative enough to protect reliability.

Start with five variables:

1. Peak concurrent participants: not daily users, but users active at the same time.
2. Average media bitrate per participant: estimate separate audio, video, and screen share patterns if needed.
3. Relay ratio: the percentage of participants or sessions likely to use TURN.
4. Traffic direction assumptions: whether you are modeling per participant uplink, downlink, or both through the relay.
5. Headroom factor: spare capacity for bursts, uneven distribution, and operational safety.

A simple planning model looks like this:

Estimated relay throughput = peak concurrent relayed participants × average effective bitrate through TURN × safety headroom

For example, if you expect 1,000 concurrent participants, assume 30% relay usage, and estimate an effective relayed media load of 1 Mbps per participant, your baseline is 300 Mbps before headroom. If you apply a 2x safety factor for bursts and uncertainty, you would plan closer to 600 Mbps usable capacity across the relevant region or cluster.

This is intentionally simple. In production, you may need to separate:

• Audio-only sessions vs video sessions
• 1:1 calls vs group calls
• Camera video vs screen share
• Mobile-heavy traffic vs desktop-heavy traffic
• Regional traffic patterns and time-of-day peaks

If your architecture uses SFUs for multiparty media, TURN sizing still matters for the client-to-edge portion where restrictive networks force relay. TURN does not disappear just because your media topology is not pure peer-to-peer.

Common sizing mistakes

Using average traffic instead of peak concurrency. Relay infrastructure is stressed by simultaneous sessions, not monthly totals.

Ignoring regional skew. A global total can hide a local bottleneck. One region may be overloaded while another sits idle.

Assuming home-network relay ratios for enterprise traffic. Business users often connect from networks with tighter controls. If your live streaming platform for business targets corporate teams, model a higher relay share unless your own data says otherwise.

Forgetting TLS and transport overhead. Your measured media bitrate is not always the full network cost.

Leaving no failure margin. Real systems need room for retries, traffic surges, and sudden changes in user mix.

What to monitor

Good TURN planning improves when paired with clear observability. Useful metrics typically include:

• Relay usage rate over time
• Concurrent allocations
• Ingress and egress throughput
• Allocation failures and auth failures
• Candidate pair success rates
• Connection setup time
• Packet loss, jitter, and round-trip trends on relayed sessions
• Regional saturation and failover behavior

These metrics belong in the same operational conversation as your broader stream reliability metrics and low latency streaming solution design. For adjacent planning, see Live Streaming Latency Explained: Typical Benchmarks by Protocol and Platform and Scaling Live Events: An Operational Checklist for High-Traffic Streams.

Best fit by scenario

The right balance between STUN and TURN depends on who your users are and where they connect from. These scenarios help make the tradeoffs concrete.

Scenario 1: Consumer video chat on mostly home networks

In this case, STUN may carry more of the load because direct connectivity is often more available than in locked-down enterprise environments. You still need TURN for reliability, but relay ratios may be moderate enough that a well-sized regional footprint keeps costs manageable.

Best fit: Strong STUN coverage, full TURN fallback, careful measurement of relay ratio by geography and device type.

Scenario 2: Enterprise meetings and internal collaboration

Office networks, VPNs, and security policies often make direct paths harder. Here, a WebRTC platform that treats TURN as core infrastructure is usually a better fit than one that assumes direct peer paths will dominate.

Best fit: Conservative TURN capacity planning, enterprise-friendly transport support, short-lived credentials, and rigorous monitoring.

If your team is comparing broader communications products, UCaaS vs CPaaS vs CCaaS: Differences, Use Cases, and Selection Criteria can help frame where relay infrastructure fits into a larger unified communications platform decision.

Scenario 3: Creator interviews, remote guests, and live contribution feeds

This scenario is unpredictable. Guests may join from cafés, hotels, backstage Wi-Fi, or corporate networks. Relay usage can jump without warning, especially when events attract participants from many locations.

Best fit: Assume higher variability, maintain extra relay headroom during scheduled events, and test onboarding flows from restrictive networks before launch.

Scenario 4: Education, coaching, and browser-based virtual sessions

Schools, campuses, and institutional networks can have unusual restrictions. Session quality also matters because classes or consultations are harder to reschedule than casual chats.

Best fit: Reliability-first TURN planning, region-aware deployment, and clear fallbacks for low-bandwidth participants.

Scenario 5: Hybrid streaming products with interactive segments

Some products combine one-to-many streaming with smaller WebRTC interaction windows for guests, hosts, or audience participation. In these cases, TURN load may be concentrated on a small but business-critical set of users.

Best fit: Size TURN for the interactive layer rather than the broadcast audience, and keep the relay fleet operationally separate from your CDN-centric video streaming infrastructure if that simplifies scaling and incident response.

For related vendor research, see Best WebRTC Platforms for Live Video Apps: Features, Pricing, and Tradeoffs and Streaming CDN Comparison: How to Evaluate Latency, Cost, Coverage, and Failover.

When to revisit

TURN and STUN planning is not a one-time setup task. It should be revisited whenever the inputs behind relay usage change. The goal is simple: keep connection success high without carrying unnecessary relay cost or operational risk.

Revisit your assumptions when:

• Your audience shifts toward enterprise, education, or institutional users
• You expand into new regions
• You add higher-resolution video or more frequent screen sharing
• You launch scheduled live sessions, events, or classrooms with peak concurrency
• Your WebRTC platform, hosting model, or network policy changes
• You notice rising setup failures, longer ICE times, or increased relay dependence
• Pricing, feature support, or deployment options change in your provider stack
• You introduce new products that mix real-time communication API features with broader cloud streaming platform workflows

A practical review process can be lightweight:

1. Measure current relay ratio by region, network type, and session type.
2. Compare peak relayed concurrency against available headroom.
3. Review candidate pair success rates and failed connection patterns.
4. Re-estimate effective bitrate assumptions for current product behavior.
5. Test from restrictive networks, not only ideal lab conditions.
6. Update regional placement if user clusters have moved.
7. Check auth, credential expiry, and abuse controls.

If you are evaluating whether to self-manage or rely on a vendor, treat TURN as part of your reliability budget, not just your bandwidth budget. The cheapest apparent option may become expensive if relay failures hurt sessions, support load, or creator trust.

As an action step, keep a small worksheet for each quarter: peak concurrent participants, percent relayed, average relayed bitrate, busiest region, current headroom, and top connection failure cause. That single page will tell you when your original TURN vs STUN assumptions no longer match reality.

The core takeaway is straightforward: STUN helps you avoid unnecessary relay; TURN ensures users can still connect when direct paths fail. For most production WebRTC systems, success depends on both. Plan STUN for reach, plan TURN for reliability, and revisit relay sizing whenever your audience, traffic profile, or network mix changes.