WebRTC Connectivity

ICE Restart or Full Reconnect: Choosing the Right WebRTC Recovery

Compare ICE restart with rebuilding a PeerConnection across network changes, media negotiation, DataChannel state, and isolation from stale sessions.

Before shipping it, separate protocol facts, product promises, and operating cost. Mixing those layers produces confident but incorrect decisions. An ICE restart keeps the existing PeerConnection and track relationships while replacing ICE credentials. Reuse becomes dangerous after closure, broken negotiation state, or an expired application identity.

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

Write the following choices as reviewable rules instead of scattering them across callbacks and UI conditions. Explicit rules make scaling, compatibility, and diagnosis less dependent on guesswork.

  • Classify path failure versus session failure from connection state, ICE state, and the selected candidate pair.
  • Give every restart a negotiation version so answers, candidates, and timeouts can mutate only that version.
  • Reconcile DataChannels and feature tasks separately; transport recovery does not automatically resume every task.

A maintainable policy attempts a version-fenced ICE restart while the session object remains healthy, then creates a new session when negotiation or identity boundaries are broken.

Keep false assumptions out of production

Boundaries turn hidden assumptions into incidents. Weak networks, refresh, concurrency, and capacity need combined coverage because retries can hide each one in isolation.

  • Both peers restart at once, creating an offer collision followed by a stale answer that overwrites the healthy path.
  • Code keeps restarting an object in a closed or terminal failed state, leaving the UI in endless recovery.
  • An online event starts another restart after the user explicitly stopped reconnecting.

What the release gate should inspect

Do not stop verification when the final action succeeds. Count side effects, measure wait time, inspect privacy, and prove the next run begins from a clean baseline.

  1. Measure recovery time and the final candidate pair across Wi-Fi-to-cellular, VPN changes, and router reconnects.
  2. Make both peers detect failure at the same instant and verify that only one negotiation version survives.
  3. Close and stop during restart, then verify timers, candidates, and automatic wakeups are fenced off.

The release bar is clear: users understand the current state, failures stop or recover, resources stay bounded, and operators can identify the phase from minimum necessary evidence.

Put the guide to work

Open uCopy and connect two devices securely from the browser.

Start for free