WebRTC Connection State Changes and Disconnections

This article explores how WebRTC manages real-time connectivity under volatile network conditions, detailing the internal mechanisms that handle temporary drops and abrupt peer disconnections. We will examine the transition of ICE connection states, the role of STUN keepalives in detecting failures, and how WebRTC uses ICE restarts to automatically recover broken sessions without interrupting the user experience.

The ICE State Machine and Connection Health

WebRTC monitors connection health through two primary state machines: RTCPeerConnection.iceConnectionState and RTCPeerConnection.connectionState. These states reflect the underlying viability of the network path between two peers.

When network quality degrades or a packet-loss spike occurs, the Interactive Connectivity Establishment (ICE) agent detects the disruption. If the connection is interrupted, the iceConnectionState transitions from connected to disconnected. This disconnected state is a temporary warning indicating that the path is broken, but the browser has not yet given up. If the disruption persists beyond a timeout threshold (typically around 10 to 30 seconds, depending on the browser’s implementation), the state transitions to failed.

Because WebRTC is peer-to-peer, it cannot rely on a central server to know if a peer is still active. To detect sudden disconnections—such as a user closing their laptop or entering a tunnel—WebRTC relies on STUN Consent Freshness (defined in RFC 7675).

Once a connection is established, the peers do not remain silent; they continuously exchange STUN binding requests and responses as keepalive signals.

If DTLS (Datagram Transport Layer Security) packets also fail to receive acknowledgments, the underlying cryptographic association will time out, pushing the overall connectionState to failed.

Handling Temporary Interruptions via ICE Restart

When a connection enters the disconnected state due to a temporary issue—such as a mobile user transitioning from Wi-Fi to a 4G/5G cellular network—WebRTC attempts to recover the connection without tearing down the call. This is accomplished through an ICE Restart.

During an ICE Restart: 1. The application or browser triggers a renegotiation. 2. The ICE agent generates a new set of local credentials (ice-ufrag and ice-pwd) and gathers new network candidates. 3. These new candidates are exchanged via the external signaling channel. 4. The peers perform a fresh round of ICE connectivity checks on the new paths. 5. If successful, the connection seamlessly transitions back to connected over the new network path, minimizing media interruption.

Managing Sudden and Ungraceful Disconnections

In a graceful disconnection, a peer sends an RTCP BYE packet and closes the signaling socket. However, in an ungraceful disconnection (e.g., immediate network loss or application crash), no such teardown signal can be sent.

WebRTC handles sudden disconnections through a combination of the following steps:

  1. Keepalive Timeout: The STUN consent checks fail to get a response.
  2. State Change Event: The browser fires the oniceconnectionstatechange and onconnectionstatechange events, moving the status to disconnected and eventually failed.
  3. Application-Level Cleanup: Because WebRTC does not automatically close the RTCPeerConnection when states fail, the application must listen to these state changes. Once the failed state is reached, the application should programmatically call peerConnection.close(), release local media tracks, and update the user interface to reflect the disconnected state.