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
Statistics clock skew
The WebRTC statistics timestamps were off by more than a minute from the capture clock, usually because the device slept while the application stayed open. The timestamps were realigned using the estimated skew.
Description
Chromium computes the timestamps of the WebRTC statistics reports from a clock that is calibrated once, when the browser process starts, and then advances monotonically. On most platforms the monotonic clock does not advance while the operating system is suspended. When a device sleeps while the application stays open, all subsequent statistics timestamps lag behind the real wall clock by the total sleep duration, which can reach hours for an application left open overnight.
Left uncorrected, this moves stream timelines and connection start times hours before the actual call.
What do we do here?
For rtcstats captures, every getStats call also carries the wall-clock time recorded by the capturing client. On the first getStats call, we compare the peer-connection statistics timestamp with that wall-clock time. When they diverge by more than 60 seconds, we estimate the clock skew from that difference, realign the statistics timestamps with it, and mark this observation with the estimated skew.
Notes
- The correction preserves the relative spacing between measurements; only the absolute position on the timeline is realigned.
- The call quality itself is not affected: this observation documents a capture artifact of the device, not a media issue.
