Skip to content

Annex: WebRTC direct P2P connection rates without TURN (mobile ↔ home NAT)

Report date: 2026-03-31

Executive summary

Published figures specifically for the use case “one mobile handset on a cellular network (often behind CGNAT) ↔ one endpoint behind a home router (residential NAT)” are rare: most sources report either (a) global “all networks” percentages (without a mobile↔home split), or (b) adjacent scenarios (home↔home, mobile↔mobile, or generic P2P). Among the primary sources identified here, global “without TURN relay” estimates cluster around ~78% to ~85% direct (hence ~15% to ~22% needing a relay): ~85% per Twilio (product statement), and 22% of conferences requiring a TURN relay (i.e. 78% without TURN) in aggregated callstats.io statistics published on webrtcHacks (2015–2016 period, “billions of minutes”).

For the mobile↔home scenario, those global figures must be adjusted for two documented realities: (1) near-ubiquity of CGN in cellular networks (a large IMC 2016 study suggests >90% of cellular ASes deploy CGN), and (2) strong dependence on NAT/firewall behavior (notably “symmetric” / endpoint-dependent mapping) as described in ICE/STUN/TURN standards. A reasonable direct ICE/STUN rate for cellular mobile ↔ home is therefore a wide band:

Case Direct (approx.) Relayed (approx.) Assumptions / rationale
Best ~90–95% ~5–10% Favorable networks, IPv6/UDP OK, ICE-friendly NATs; permissive mapping/filtering; no policies forcing TURN; stable radio.
Typical ~75–85% ~15–25% Mixed carriers, mixed home NATs, CGN common; aligned with published global ratios (78–85%) with a plausible penalty from cellular CGN prevalence.
Worst ~55–70% ~30–45% Restrictive CGN/NAT, fragile UDP, aggressive timeouts, home double NAT; “in the wild” non-WebRTC hole-punching ~70% ± 7.1% (IPFS/libp2p); operations feedback sometimes >30% traffic via TURN.

For capacity planning, if traffic is mostly mobile↔home, a prudent starting point is to dimension relay bandwidth for ~25–35% of sessions under load (then refine with telemetry), with a worst-case guard up to ~45–50% depending on operator markets/segments and radio conditions. The highest-value metrics to instrument are those that tie ICE topology (selected pair: direct vs relay) to media quality (RTT, jitter, loss, frames) via the standardized getStats API.

Key definitions and scenario scope

ICE, STUN, TURN (one sentence each)

  • ICE (Interactive Connectivity Establishment): NAT traversal orchestration for UDP-based communication—candidate gathering, connectivity checks—built on STUN and TURN.
  • STUN (Session Traversal Utilities for NAT): Lets an endpoint learn its address/port as seen after NAT translation; also used for connectivity tests and keeping bindings alive.
  • TURN (Traversal Using Relays around NAT): Relay protocol; when direct communication cannot work in some situations, the endpoint obtains an allocation on a relay and sends/receives via that relay.

Relevant NAT types

Taxonomies such as full-cone / restricted / port-restricted / symmetric are common in informal descriptions; in standards, behavior is usually described in terms of mapping and filtering (e.g. endpoint-independent vs endpoint-dependent) for UDP. For ICE, the key intuition:

  • Permissive NAT (endpoint-independent mapping/filtering) makes STUN-based hole punching easier.
  • Stricter NAT (often equated with symmetric / endpoint-dependent mapping) raises the chance of direct failure, so TURN is needed more often—that is exactly why TURN exists: relay when direct is impossible in certain situations.

CGNAT / CGN and mobile↔home “double NAT”

  • CGN (Carrier-Grade NAT): Large-scale subscriber NAT in an ISP network, often on top of residential NAT, which can stack translation layers (double NAT) and change inbound/outbound connectivity properties. IETF work defines minimal requirements for CGN and reserves IPv4 prefix 100.64.0.0/10 for “shared” addressing around CGN.
  • Empirically, an IMC 2016 study estimates CGN penetration at 17–18% of “eyeball ASes”, and reports that CGN is ubiquitous in cellular networks: >90% of cellular ASes are estimated to deploy CGN.

Scope of this report (“mobile ↔ home NAT”)

Here, “mobile” means primarily a 4G/5G smartphone (often behind carrier CGN) and “home” an endpoint behind residential NAT (CPE). If the phone is on home Wi‑Fi, the situation is closer to home↔home (often more favorable).

How studies define “success” (and why numbers differ)

Three levels of “success” that are often conflated

  1. ICE control-plane success (connectivity checks / ICE state)
    ICE runs connectivity checks between candidate pairs (host/srflx/relay) and nominates a winning pair, typically surfacing as connected/completed in the API. The ICE specification describes this NAT traversal mechanism and its dependence on STUN/TURN.

  2. Actual media path (selected candidate pair)
    Even with ICE “connected”, implementations may switch paths (ICE restart, network change, relay-only policy, etc.). A more robust measure is the selected candidate pair and types (direct vs relay) via getStats; W3C webrtc-stats defines the relevant stats dictionaries (including RTCIceCandidatePairStats) and notes deprecation of some fields such as networkType for privacy.

  3. Real A/V quality (QoE) after setup
    “Direct” sessions can still be poor (unstable radio, buffering, loss); a nearby TURN POP can sometimes improve stability at the cost of bandwidth/latency. RTT, jitter, packetsLost, frame metrics are what WebRTC analytics platforms aggregate beyond ICE setup (e.g. callstats).

Major methodological differences (and bias)

Kind of source Typical shape Bias / caveat
Product (e.g. TURN vendor) “STUN-only suffices” or “% on TURN” Often no published sample size, period, or segmentation (mobile vs home vs enterprise).
Multi-client observability (WebRTC analytics) Browser getStats / webrtc-internals, huge volumes Mixed topologies (P2P, multiparty, gateways), variable TURN/TCP policies, non-representative product mix.
Academic home↔home Clean but small N, limited geography May not document exact STUN/TURN usage.
Non-WebRTC P2P Hole-punching “in the wild” Useful bound/intuition, not ICE/WebRTC-specific nor mobile↔home.
Operator / network (CGN) Not an ICE direct rate Key explanatory factor for mobile↔home (CGN prevalence).

Main gap in “WebRTC implementer” public material

In the primary sources surveyed for this report, there was no recent, numeric publication directly segmented “mobile↔home NAT” from the implementer blogs/notes checked (Google, Mozilla, Janus, Pion, Agora). The most usable public material for a “without TURN” percentage is (a) a TURN vendor (Twilio), (b) aggregated analytics (callstats), plus (c) academic work on adjacent scenarios and (d) operator-side CGN measurement.

Comparative source table (mobile↔home or closest scenario)

Source (type) Date Size / dataset Geography Method & success definition % “without TURN” (mobile↔home or proxy) Confidence & limits
Twilio — “Network Traversal” (STUN/TURN vendor) Undated (page reviewed 2026-03-31) Not published Not specified Product statement: STUN first, connectivity test, TURN for symmetric NAT / “other issues” ~85% direct (STUN-only), “all networks” Medium–low: clear figure; sample/period/segmentation not published.
webrtcHacks / callstats — “The Big Churn” 2016-04-08 (data 2015-01 → 2016-02) “Billions of minutes”, 100+ clients Not specified; browsers incl. Chrome Android Session instrumentation: “never set up” failures; NAT/firewall attribution; “need TURN relay” ~78% without TURN (22% “need TURN”) Medium: huge volume; old (2015–2016); heterogeneous topologies/products.
AINTEC 2021 — WebRTC P2P measurement tool (academic) 2021-12 10 nodes, 90 P2P links; 77/90 measured Japan Success = ability to establish P2P WebRTC to measure RTT in a mesh ~85.6% links established (home↔home) Medium–low: useful adjacent scenario; small N; STUN/TURN not detailed.
discuss-webrtc — industry anecdote 2018-06-21 Not published Not specified “% traffic via TURN” by use case; “large vendors” Implicit ~70–80% direct typical; “often ~20% TURN”, sometimes >30% Low: useful bound; not audited or segmented.
IMC 2016 — CGN study 2016 Vantage points >60% eyeball AS; 75-operator survey Global (AS) CGN detection/measurement; cellular focus N/A (not an ICE rate) High for “CGN very common on cellular”; indirect for “without TURN”.
arXiv 2025 — P2P NAT traversal (non-WebRTC) 2025-10-31 4.4M attempts; 85k networks; 167 countries Global Hole-punching stage (DCUtR) success in production P2P 70% ± 7.1% (hole-punching stage; proxy for “direct possible”) Medium: huge dataset; protocol/population ≠ WebRTC; success conditional on other stages.
W3C — webrtc-stats 2025-09-25 N/A N/A Defines getStats objects including candidates/pairs; networkType deprecation N/A High for what to measure; not a P2P success rate.
Jitsi — “P2P4121” blog 2017-07-17 N/A Not specified Strategy: try direct 1-to-1; fallback to bridge if NAT does not permit N/A (no %) Medium: concrete strategy; no public metrics.

Synthetic estimate for mobile ↔ home NAT and capacity planning

Quantitative “best / typical / worst” (with assumptions)

Empirical anchors (global, not mobile↔home-segmented):

  • ~85% direct (STUN-only) per Twilio.
  • ~78% direct implied from callstats (22% “need TURN relay”).

Mobile↔home adjustment: On cellular, CGN is documented as nearly universal at AS scale. TURN exists precisely when direct communication cannot work; stricter NAT/firewalls (common in carrier/enterprise environments) increase relay use.

Without a public metric that isolates mobile↔home, the rigorous approach is to publish a range and state assumptions explicitly (as in the table in the executive summary).

Mermaid: direct vs TURN decision flow in ICE

Connectivity checks and using TURN when direct fails in some situations are central to ICE/STUN/TURN definitions.

flowchart TD
  A[Call start] --> B[ICE candidate gathering]
  B --> B1[Host candidates]
  B --> B2[Server-reflexive via STUN]
  B --> B3[Relay via TURN (pre-allocated or on demand)]
  B --> C[SDP / candidate exchange]
  C --> D[ICE connectivity checks]
  D --> E{Winning pair nominated?}
  E -->|Yes| F{Selected candidate pair type}
  F -->|host/srflx| G[Direct media path (no TURN)]
  F -->|relay| H[Media path relayed via TURN]
  E -->|No| I[Setup failure / fallback / retry (ICE restart, TURN/TCP, etc.)]

Capacity planning: what relay bandwidth to budget?

A TURN relay carries traffic both ways for each relayed session, which can explode cost. TURN is explicitly an endpoint-controlled relay.

Rule of thumb (1-to-1 P2P audio/video): If p% of calls are relayed, server-side throughput is roughly proportional to p, but a relayed session’s server bitrate is approximately the sum of A→B and B→A (so with symmetric bitrates, about 2× one-way bitrate).

Initial budget (mobile↔home): Assume typical p = 20–25% TURN → plan 25–35% relay capacity (conservative), then tune after 2–4 weeks of real telemetry (see monitoring below). Compatible with 15–22% relay anchors and heavy cellular CGN.

“Anti-surprise” peak: Stress-test planning where p reaches 40–45% (worst-case band).

TURN ports/protocols (connectivity & firewalls): TURN supports UDP/TCP/TLS-over-TCP/DTLS-over-UDP; default ports 3478 (UDP/TCP) and 5349 (TLS/DTLS). Example vendor documentation (Twilio) mentions 443/TCP (TURN TLS), 3478 TCP/UDP, 5349 TCP, and an ephemeral UDP relay port range 10000–60000.

Instrumentation and monitoring recommendations

Goal: measure your real mobile↔home rate unambiguously

Published numbers are useful bounds; your product will depend on carrier mix, country, Wi‑Fi vs cellular share, ICE policies (relay-only vs all), and ICE restart UX. Instrument both ICE topology and media quality via getStats, aligned with the W3C spec.

Minimum metrics (per call, per participant)

Network & device context (outside getStats, especially on mobile)

  • Access type: cellular vs Wi‑Fi (and 3G/4G/5G if the OS exposes it).
  • Operator identifiers (MCC/MNC), roaming yes/no (native mobile).
  • Timestamp, region, OS/app version, device model.
  • Network change events (handover, Wi‑Fi↔cellular)—sessions often degrade or drop when the interface changes.

ICE setup (event timeline)

  • Durations: iceGathering start→complete, iceConnectionState / connectionState transitions.
  • Candidate counts: host, srflx, relay (if available); time to srflx (STUN RTT) and TURN allocation.
  • Failure reason where possible: check timeouts, no validated pair, “STUN blocked”, “TURN allocation failed”, etc.

Selected topology (KPI #1 for “without TURN”)

Via RTCIceCandidatePairStats / candidate stats:

  • Selected pair: selectedCandidatePairId (or implementation equivalent), state, nominated.
  • Candidate types: localCandidateType / remoteCandidateType (host / srflx / relay).
  • TURN in use if local or remote type is relay.

Media health (audio and video separately)
Compute over windows (e.g. 1–5 s) and percentiles (p50/p95):

  • RTT (roundTripTime / currentRoundTripTime as applicable), jitter, packetsLost, send/recv bitrate, retransmissions/NACK, frame rate, freeze/PLI/FIR if available.
  • Setup to first media: time from “call” action to first rendered video frame / first decoded audio packet.

Privacy / browser limits
networkType in stats is deprecated for privacy; prefer OS-level cellular vs Wi‑Fi on native apps, or indirect signals/heuristics on the web.

KPI Definition
Direct rate (no TURN) % of calls where the selected pair uses no relay candidate.
TURN-required % of calls where no non-relay pair succeeds (distinct from “TURN offered but not chosen”).
TURN-forced (policy) % relayed despite successful non-relay pairs (config/bug drift)—compare to field reports of “bugs forcing TURN on all traffic”.
Setup failure rate & setup time (p50/p90/p99) Historical benchmark: callstats ~12% “never set up” (2015–2016), largely NAT/firewall; some conferences need TCP. Rebaseline with 2026+ data.
Quality by topology Direct vs relay: RTT/jitter/loss/freeze—to decide if earlier TURN sometimes improves QoE at bandwidth cost.

Primary source URLs

IETF / standards

Industry & analytics

Research

Implementation & measurement