WebRTC Connectivity

WebRTC Consent Freshness: Knowing When the Peer Is No Longer There

Separate ICE consent freshness from application heartbeats across expired NAT mappings, frozen pages, one-way blackholes, and peer exit so data is not sent to an invalid destination.

The dangerous implementation is not one that never works. It is one that works in a demo and loses its boundaries under real networks and real data volume. ICE consent checks whether the remote still permits traffic on the selected pair; an application heartbeat checks feature liveness. Loss of consent stops transport, while a missed app heartbeat may be a frozen main thread.

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.

Engineering boundaries and tradeoffs

Start from facts the data and protocol can guarantee, then decide what the interface may promise. Each rule below needs an owner, a bound, and a compatibility policy rather than an oral convention from one review.

  • Combine PeerConnection state, recent data activity, and application heartbeat into layered health.
  • Propagate explicit peer departure immediately instead of waiting for consent timeout to clean feature tasks.
  • After one-way recovery, revalidate session version and identity so delayed data cannot revive a task.

Connection health is not one boolean. Consent, signaling reachability, app heartbeat, and feature sessions need separate states to stop invalid traffic without punishing a temporarily frozen page.

How it fails in production

Prioritize faults that silently preserve false facts: the interface looks recovered while a queue, permission, or counter has diverged. The defect often appears only on the next action.

  • The app treats an open signaling WebSocket as peer health while the selected pair is a one-way blackhole.
  • A background heartbeat pause revokes device trust, confusing browser throttling with malicious departure.
  • The sender keeps encoding a screen for hours after the viewer disappears, wasting CPU and bandwidth.

Turn testing into a closed loop

Observe both endpoints, persisted records, and operational signals during verification. One button state or one successful response cannot prove the complete loop.

  1. Drop inbound, outbound, and bidirectional UDP separately and observe transport and app liveness convergence.
  2. Freeze and resume the viewer tab, ensuring trust remains while viewer counts eventually reconcile.
  3. Test explicit leave, power loss, and NAT expiry for cleanup deadlines and user-facing states.

The result must be correct, recoverable, and explainable. If any part depends on refreshing the page or an engineer guessing, the protocol loop remains incomplete.

Put the guide to work

Open uCopy and connect two devices securely from the browser.

Start for free