WebRTC Infrastructure at Scale

WebRTC enables peer-to-peer communication between browsers and devices without plugins or third-party software. But its promise of direct connection belies significant infrastructure complexity. This paper examines the three pillars of WebRTC infrastructure at scale: signaling architecture, NAT traversal strategies, and TURN fallback design. We present latency benchmarks from production systems, document common failure modes, and provide architectural patterns drawn from the development of Relay, a WebRTC signaling and relay infrastructure built by CODECX.

Signaling architecture, NAT traversal, TURN fallback, and lessons from building Relay.

1. Introduction

WebRTC is often described as peer-to-peer technology. The description is accurate only at the media layer. Before two peers can exchange audio, video, or data, they must discover each other, negotiate capabilities, and traverse network address translators - all of which require server infrastructure.

The signaling server, the STUN infrastructure, and the TURN relay network are not peripheral to WebRTC. They are WebRTC. This paper treats them as first-class architectural concerns.

block-beta
    columns 3
    block:S["Signaling"]
        columns 1
        S1["SDP exchange"]
        S2["ICE relay"]
        S3["Session state"]
    end
    block:N["NAT Traversal"]
        columns 1
        N1["ICE candidates"]
        N2["STUN servers"]
        N3["Connectivity checks"]
    end
    block:T["TURN Fallback"]
        columns 1
        T1["Media relay"]
        T2["Last resort"]
        T3["Bandwidth costs"]
    end
    S --> N --> T

2. The Three Pillars

2.1 Signaling

Signaling is the coordination layer. Two peers that have never met must agree on session parameters before any data flows. The signaling server relays offers, answers, and ICE candidates between peers.

What signaling does:

• Exchanges Session Description Protocol (SDP) offers and answers
• Relays Interactive Connectivity Establishment (ICE) candidates
• Manages session state (connecting, connected, disconnected, failed)
• Coordinates reconnection when networks change

What signaling does not do:

• It does not carry media. After signaling completes, media flows peer-to-peer or through TURN.
• It does not enforce authorization (that is the application layer’s responsibility).

Architectural choices:

2.2 NAT Traversal

Network Address Translation (NAT) allows multiple devices on a private network to share a single public IP address. It is ubiquitous. It is also the primary obstacle to peer-to-peer connectivity.

The problem: A peer behind a NAT does not know its public IP address. Even if it did, incoming connections from unknown addresses are typically blocked.

The solution: ICE (Interactive Connectivity Establishment) gathers candidates - potential connection paths - and tests them in priority order.

Candidate types:

ICE tests candidates in parallel. It selects the lowest-latency path that succeeds. In most cases, this is a server reflexive candidate. In difficult network conditions, it falls back to TURN.

stateDiagram-v2
    state "ICE Connection Lifecycle" as ICE
    [*] --> Gathering
    Gathering --> Testing : Candidates collected
    Testing --> Connected : Direct P2P path found
    Testing --> Fallback : NAT blocks direct
    Fallback --> Connected : TURN relay established
    Connected --> Disconnected : Network change or timeout
    Disconnected --> Gathering : ICE restart
    Connected --> [*] : Session ended
    Disconnected --> [*] : Reconnect failed

STUN infrastructure requirements:

• Low latency (under 50ms response time)
• Geographic distribution (closest STUN server to each peer)
• High availability (STUN failure means ICE fails for peers behind NAT)

flowchart TD
    A["Peer A wants to connect"] --> B["Gather candidates"]
    B --> C["Host candidate<br/>192.168.1.5"]
    B --> D["SRFLX candidate<br/>via STUN: 203.0.113.42"]
    B --> E["Relay candidate<br/>via TURN: relay.turn.io"]
    C --> F["Test candidates"]
    D --> F
    E --> F
    F --> G{"Which works?"}
    G -->|Lowest latency| H["Direct P2P
80% of sessions"]
    G -->|NAT blocks direct| I["TURN relay
20% of sessions"]

2.3 TURN Fallback

Traversal Using Relays around NAT (TURN) is the last resort. When direct connection fails - due to symmetric NATs, firewall policies, or network restrictions - media flows through a TURN server.

The cost of TURN:

• Bandwidth: Every byte of media passes through the server
• Latency: Adds one network hop between peers
• Server load: Scales linearly with concurrent connections
• Financial cost: Bandwidth is expensive

Designing TURN infrastructure:

Relay’s TURN architecture:

Relay deploys TURN servers in five geographic regions. When a peer connects, Relay selects the two closest TURN servers (one per peer). If peers are in the same region, they share a TURN server. If they are in different regions, media relays through the optimal path - either direct TURN-to-TURN or through an internal backbone.

3. Latency Benchmarks

timeline
    title Connection Establishment Phases
    Signaling : SDP offer/answer exchange
              : 45ms median
    ICE Gathering : Collect host, SRFLX, relay candidates
                  : 80ms median
    Connectivity Checks : Test candidates in priority order
                        : Select lowest-latency path
    TURN Fallback : 20% of sessions need relay
                  : Adds 25ms median latency
    Reconnection : Network change triggers restart
                 : 320ms median recovery

Benchmarks from Relay’s production deployment, measured across 50,000 sessions:

4. Common Failure Modes

4.1 The Signaling Bottleneck

Symptom: Peers cannot connect. Signaling timeouts.

Cause: Single signaling server overloaded. WebSocket connections queued.

Fix: Stateless signaling with pub/sub. Multiple signaling servers behind a load balancer. Redis as the pub/sub backbone.

4.2 The STUN Failure Cascade

Symptom: 80% of connections succeed, 20% fail. Failures correlate with specific ISPs.

Cause: STUN server unreachable from certain networks. ICE falls back to TURN for all users on those networks, overloading TURN.

Fix: Deploy STUN servers in ISP-local data centers or use a distributed STUN service. Monitor STUN reachability by network.

4.3 The TURN Cost Spiral

Symptom: TURN bandwidth costs grow faster than user growth.

Cause: Increasing reliance on TURN. More users on restrictive networks. No incentive to optimize.

Fix: Monitor TURN usage percentage. Target under 10% of total sessions. Investigate networks with high TURN reliance. Deploy additional STUN infrastructure in underserved regions.

5. Architectural Patterns

Pattern 1: Stateless Signaling

Signaling servers store no session state. State lives in Redis with a TTL. Any signaling server can handle any message. If a server fails, sessions are unaffected. New servers can join the cluster without rebalancing.

Pattern 2: ICE Candidate Prefetching

When a peer first connects, begin ICE candidate gathering immediately, before the remote peer is known. Cache candidates with a short TTL. When the remote peer is identified, candidates are ready. This reduces connection establishment by 30-50ms.

Pattern 3: TURN Capacity Planning

TURN capacity is measured in bandwidth, not connections. One TURN server handling 1,000 low-bandwidth data channels is different from one handling 100 high-definition video streams. Capacity planning must be per-protocol and per-use-case. Relay allocates TURN capacity by expected bandwidth consumption, not connection count.

6. Lessons from Building Relay

1. Signaling is the easy part. NAT traversal and TURN are where complexity and cost accumulate.

2. STUN is underinvested. Most WebRTC deployments run a single STUN server and accept the TURN fallback cost. Deploying multiple STUN servers in ISP-local networks pays for itself in reduced TURN bandwidth.

3. Monitor TURN percentage obsessively. It is the single metric that correlates with both user experience and infrastructure cost. A rising TURN percentage demands investigation.

4. ICE is slow at P99. Even with optimized infrastructure, 1% of connections take over 900ms. Applications must handle this gracefully - show connection progress, allow cancellation, and never block the UI on ICE completion.

5. The network changes. A peer on Wi-Fi moves to cellular. A VPN connects. A firewall updates. WebRTC infrastructure must handle reconnection without user intervention. Stateless signaling and ICE restart are the tools.

7. Conclusion

WebRTC enables peer-to-peer communication, but the infrastructure that makes it work is server-side, distributed, and complex. Signaling must be stateless and scalable. STUN must be distributed and monitored. TURN must be provisioned for bandwidth, not connections. The three pillars are interdependent - weakness in one cascades to the others.

Relay is the result of applying these patterns in production. The architecture is documented. The code is open source. The lessons are shared here so that others building WebRTC infrastructure can start from a known foundation rather than discovering these patterns through failure.

References

1. IETF. RFC 8835: WebRTC Transports. 2021.
2. IETF. RFC 8656: TURN Protocol. 2020.
3. IETF. RFC 8445: ICE Protocol. 2018.
4. CODECX Engineering. Why We Chose WebRTC Over WebSockets for Relay. CODECX Journal, 2026.
5. TELOSIS Research. Self-Hosting Is Not a Feature - It Is Infrastructure. TELOSIS-RP-2026-001, 2026.

TELOSIS Research. (2026). WebRTC Infrastructure at Scale. TELOSIS-RP-2026-003.

TELOSIS Research. "WebRTC Infrastructure at Scale." TELOSIS-RP-2026-003, 2026.

@techreport{telosis_rp_2026_003,
  author = {TELOSIS Research},
  title = {WebRTC Infrastructure at Scale},
  number = {TELOSIS-RP-2026-003},
  year = {2026}
}