WebRTC Metrics
A comprehensive overview of WebRTC statistics, derived calculations, extracted features, and observable signals, to better understand call quality, connectivity, and user experience in rtcStats
Brief connectivity interruption
The active connection path briefly stalled and then recovered on its own.
Description
Once an ICE connection is established, the two peers keep probing the active candidate pair. WebRTC sends STUN connectivity checks and periodic STUN consent requests, and it expects a STUN response back for each. As long as responses keep coming, the path is considered alive.
A Brief connectivity interruption happens when those outgoing checks stop being answered for a few seconds and then start being answered again. The path stalled and recovered on its own, without ever reaching the ICE disconnected or failed state. Media may have paused or degraded for the duration of the stall, but the call continued.
This is a lighter signal than a dropped connection: it captures the sub-disconnection glitches that a longer outage report would miss. Common causes are a short Wi-Fi or cellular glitch, a brief network handover, or a momentary congestion spike somewhere on the active route.
The connectivity-check counters live on the candidate pair and only say that outgoing checks were not answered in time. They cannot prove which side of the path dropped the traffic, so we describe this as an interruption along the active path rather than blaming the local or the remote network.
What do we do here?
We look at the active (selected) candidate pair of each peer connection and read its per-sample STUN counters: requestsSent, consentRequestsSent, and responsesReceived. We only start watching once the pair has answered at least one check, so the ICE establishment phase is excluded.
We walk each span where responsesReceived stays completely flat (no response arrived). For each sample in that span we compute the check-send rate, the number of connectivity plus consent checks sent divided by the real seconds elapsed since the previous sample, and mark the interval bad when that rate exceeds 3 checks per second. Normalizing by real elapsed time keeps a slow sampling cadence from looking like a burst.
A flat span fires an episode when it contains at least 3 bad intervals, it recovers (responses resume afterward in the capture), and the whole flat span is 15 seconds or shorter. Bad intervals are counted anywhere within the span, not strictly back to back, so a brief dip in the retry rate does not reset the count. Spans that never recover, or that run longer than 15 seconds, are left to the disconnection observations. We reset the analysis whenever the selected pair changes or the sampling gap is implausible. When at least one span qualifies, we mark an observation reporting when it first happened (the start of the flat span), how many episodes occurred, and their total stalled duration.
after its first answered check"] --> B{"responsesReceived flat
in this interval?"} B -->|"Yes"| C["Extend the flat span"] C --> D{"requestsSent + consentRequestsSent
rate over 3 per second?"} D -->|"Yes"| E["Mark a bad interval"] D -->|"No"| B E --> B B -->|"No: a response arrived"| F{"Span had 3+ bad intervals
and lasted 15 s or less?"} F -->|"Yes"| G["Fire: brief connectivity interruption
(onset, episode count, total stalled time)"] F -->|"No"| H["Discard: too weak,
or a real outage for the disconnection rules"]
