WebRTC Connectivity

How to Measure Whether WebRTC Is Direct or Using TURN

Locate the selected candidate pair in getStats, classify host, srflx, prflx, and relay, and handle multiple transports, route changes, and browser differences.

Before shipping it, separate protocol facts, product promises, and operating cost. Mixing those layers produces confident but incorrect decisions. A relay candidate in the list does not mean TURN is active, and a host candidate does not prove LAN direct. The transport-selected pair—or one unambiguous nominated succeeded pair—is the evidence.

WebRTC decisions need evidence from both endpoints, negotiation versions, and the selected candidate pair. One browser callback cannot reveal glare, ICE route changes, or divergence after a peer refresh.

The parts that make the design practical

List non-negotiable invariants before selecting performance knobs. Tuning can roll out gradually; identity, permission, and terminal-state rules cannot drift at runtime.

  • Read selectedCandidatePairId from each active transport, then join it to local and remote candidate records.
  • Map candidateType, protocol, relayProtocol, and networkType into local direct, public direct, or relay.
  • Close the old interval and emit a new route event when the pair changes; one sample at connection time is insufficient.

Route telemetry needs type, protocol, duration, and coarse network context—not network identity. It should inform users and capacity planning without building a profile.

Keep false assumptions out of production

Failure and success must share one state model. An error toast that neither releases resources nor propagates a terminal state leaves dirty work for the next recovery attempt.

  • Counting any relay candidate as TURN systematically overstates relay use.
  • Ignoring multiple transports hides cases where media and data use different paths.
  • Sending full IPs, ports, and candidate strings to analytics creates unnecessary privacy risk.

What the release gate should inspect

Write the expected state trace before injecting faults. At every phase, reconcile user-visible outcome, both protocol endpoints, persistent records, and resource counts to prove the loop.

  1. Create a connection that gathers relay candidates but selects srflx; the UI must report public direct.
  2. Move direct to TURN and back through ICE restarts, verifying intervals, durations, and UI updates.
  3. Run compatibility fixtures from real Chrome, Firefox, and Safari stats and reject ambiguous inference.

Completion is not one passing path. Every terminal state reconciles, automation stays below user intent, and every operational cost has an explicit ceiling.

Put the guide to work

Open uCopy and connect two devices securely from the browser.

Start for free