How do I keep video calls stable when users switch networks

To keep video calls stable when users switch networks (for example Wi‑Fi to cellular, or one Wi‑Fi network to another), design for seamless transport migration and fast recovery. The best approach depends on whether you control the app, the signaling stack, or both.

Practical strategies

1) Use a protocol that supports network changes well

• WebRTC is usually the easiest path for browser/mobile calls.
• It can recover from IP changes using ICE restart and candidate re-checking.
• If you use custom media transport, make sure it supports:
  • connection migration
  • session resumption
  • quick re-ICE / re-keying if needed

2) Detect network change early

Listen for:

• network interface changes
• connectivity loss/restoration
• IP address changes
• RTT spikes / packet loss / bitrate collapse

On mobile:

• iOS: reachability / NWPathMonitor
• Android: ConnectivityManager callbacks
• Browser: limited direct access, so rely on WebRTC stats and ICE state

3) Trigger ICE restart on path change

When the device switches networks:

• keep the call UI alive
• do not immediately hang up
• initiate ICE restart quickly
• renegotiate if needed

For WebRTC, this usually means:

• create an offer with iceRestart: true
• exchange updated SDP via signaling
• update ICE candidates on both sides

4) Use TURN as a fallback

Direct peer-to-peer connections are often the first to break on network changes. A TURN relay can improve stability because:

• it hides changing client IPs from the peer
• it works better with restrictive NATs/firewalls
• it can provide a consistent relay path during transitions

Downside: more latency and server bandwidth cost.

5) Prefer audio continuity over video continuity

If the network switch causes a brief disruption:

• preserve audio first
• temporarily reduce or pause video
• lower bitrate and resolution immediately after reconnection
• restore video once stable

This gives a much better user experience than trying to keep full quality during a transition.

6) Implement adaptive bitrate and congestion control

Use:

• bandwidth estimation
• scalable video encoding if available
• dynamic resolution/frame-rate reduction
• keyframe requests after recovery

When network quality drops:

• reduce send bitrate quickly
• lower frame rate before dropping audio
• avoid overbuffering

7) Smooth over short outages

A network switch may cause a few seconds of interruption. You can hide this by:

• keeping the UI in “reconnecting” state
• freezing the last video frame briefly
• playing a subtle reconnect indicator
• buffering only lightly; don’t add too much latency

8) Reconnect with state preservation

When reconnecting, preserve:

• room/session ID
• participant identity
• audio mute state
• camera selection
• active speaker state
• call timers

That way the call can resume without forcing the user to rejoin manually.

9) Handle both sides of the call

If only one side switches networks:

• the other side should tolerate temporary media loss
• keep signaling alive if possible
• don’t tear down the session too aggressively

If both sides might move, rely on a server-mediated architecture rather than direct P2P.

10) Test real-world cases

Test with:

• Wi‑Fi to LTE/5G
• captive portal transitions
• weak signal to strong signal
• airplane mode toggles
• VPN on/off
• IPv4 to IPv6 transitions
• switching between access points in the same network

Use packet loss injection and latency simulation too.

---

Recommended architecture for WebRTC

If you’re building a video app today, a solid baseline is:

• WebRTC media
• signaling server
• ICE/TURN/STUN
• automatic ICE restart
• adaptive bitrate
• network-change detection
• reconnect state machine

A typical recovery flow:

1. Network change detected or ICE fails
2. Keep UI active, mark call as reconnecting
3. Restart ICE and gather fresh candidates
4. Fall back to TURN if direct path fails
5. Reduce bitrate temporarily
6. Restore media when stable

---

UX tips

• Show “Reconnecting…” instead of “Call dropped”
• Keep microphone/camera toggles where they were
• Restore video layout and active speaker after reconnect
• Avoid forcing users to rejoin unless the session is truly lost

---

If you want the most reliable result

Use:

• WebRTC
• TURN servers
• ICE restart
• aggressive adaptation to bitrate/resolution
• session persistence in signaling

If you want, I can also give you:

1. a WebRTC-specific reconnect flow,
2. sample code for ICE restart, or
3. a mobile app approach for iOS/Android network changes.