Six WebRTC getStats Mistakes to Avoid

A broken monitoring dashboard is relatively easy to catch, but a dashboard showing believable but incorrect numbers is far more dangerous. WebRTC's getStats() API, which exposes detailed information about RTP streams, packet loss, jitter, candidate pairs, codecs, frame processing, round-trip time, and more, can lead to misinterpretation if its metrics are not understood correctly. Here are six mistakes to avoid when using WebRTC's getStats() for monitoring:

1. Most values are counters, not rates. Cumulative counters such as bytesReceived, packetsReceived, framesDecoded, and nackCount require comparing two observations to calculate a rate: const bitrate = ((curr.bytesReceived - prev.bytesReceived) * 8) / ((curr.timestamp - prev.timestamp) / 1000); Ensure the timestamps belong to the same stats object and the interval between measurements is not assumed to be constant.

2. The object you're measuring can change underneath you. If the selected ICE candidate pair changes due to an ICE restart, candidate-pair objects may disappear and new ones may appear. Treat a new object as a separate entity and not a continuation of the previous one. Use the stats ID to match objects: const prevStat = prevReport.get(curr.id); if (!prevStat) { return null; }

3. Calling getStats() faster does not guarantee fresher measurements. WebRTC Stats specification allows implementations to cache or throttle measurements, and applications have no control over the sampling cadence. Two reports from separate calls can have identical timestamps. Guard against divide-by-zero errors when calculating rates based on these measurements.

4. Jitter is measured in seconds. For inbound-rtp statistics, jitter is expressed in seconds, not milliseconds. Convert jitter values to milliseconds explicitly: const jitterMs = stat.jitter * 1000; Failing to do so can result in incorrect interpretation of the data.

5. packetsLost is a signed value. WebRTC defines packetsLost as a signed value following RTP's cumulative packet-loss semantics. The value can be negative, indicating that the number of received packets is greater than the number of expected packets due to duplicate packets. Do not treat a negative delta as corrupted telemetry: const lostDelta = curr.packetsLost - prev.packetsLost; Calculate interval metrics carefully, considering the signed nature of packetsLost values.