WebRTC jitter: causes and how to diagnose it
Why WebRTC calls get jittery, which getStats metrics to read, and how to tell a network problem from a jitter buffer problem.
One of the most common complaints of VoIP and WebRTC users is choppy audio and audio that keeps warbling in and out.
In WebRTC, the way to troubleshoot such issues is to open up webrtc-internals, either directly in the web browser or after downloading it from the browser, and start looking for jitter values. What we're going to do here is explain what jitter is in a WebRTC call, what actually causes it, which getStats() metrics are useful when troubleshooting jitter issues, and how to tell other network problems apart from a jitter buffer related problem.
What jitter actually is
Jitter is the variation in packet arrival time. Your encoder sends RTP packets on a steady clock, but the network delivers them unevenly: some arrive early, some late, some bunched together. That variance is jitter, and it is separate from latency. A call can have low latency and still be jittery if the packets arrive in a ragged rhythm.
WebRTC hides jitter with a jitter buffer: it holds incoming packets for a few milliseconds so it can play them out at a steady pace. When jitter is low, the buffer stays small and playout is smooth. When jitter spikes, the buffer either grows (adding delay) or runs dry (causing gaps you hear as choppy or robotic audio).
Two getStats() metrics measure this directly:
inbound-rtp.jitter: the raw packet-arrival variance, in seconds, as reported by RTP.inbound-rtp.jitterBufferDelaydivided byjitterBufferEmittedCount: the average time each sample spent waiting in the buffer, which is the delay jitter is actually costing you.
The remote end's view of jitter on your outbound stream comes back over RTCP as remote-inbound-rtp.jitter, so you can see the jitter the other side is experiencing on what you send.
What causes it
In rough order of how often it is the culprit:
- Network congestion on the last mile. Shared Wi-Fi, a saturated uplink, or a congested cellular cell delivers packets in bursts. This is the most common cause.
- Wi-Fi interference and roaming. Moving between access points, or contention on a busy 2.4GHz channel, produces short jitter spikes that line up with the user walking around.
- CPU starvation on either end. If the sending or receiving device is pegged, packets get processed late, which looks like jitter even when the network is clean.
- A router or path that reorders or buffers packets (bufferbloat). Deep queues add variable delay that shows up as jitter downstream.
- TURN relay overhead. When media goes through a TURN relay, the extra hop can add variance, especially if the relay itself is loaded.
- VPNs and tunnels that batch or re-shape traffic.
How to diagnose it
Read the numbers before you guess. Healthy audio jitter is usually a few milliseconds; sustained double-digit jitter is where users start to notice.
| Metric | Healthy | Trouble |
|---|---|---|
jitter (audio) |
under ~30ms | sustained over ~30ms, or spiking |
jitterBufferDelay / jitterBufferEmittedCount |
stable, low tens of ms | climbing, or swinging up and down |
packetsLost alongside jitter |
near zero | rising together with jitter |
The correlation is what matters:
- Jitter high, packet loss near zero: the network is delivering everything, just unevenly. Look at the last mile, Wi-Fi, and bufferbloat.
- Jitter high and packet loss high together: the path is genuinely congested or lossy. Treat it as a network capacity problem, not a buffer tuning problem.
- Jitter fine but audio still choppy: the jitter buffer may be running dry for another reason. Check the concealment metrics (
concealedSamples,concealmentEvents) and see the choppy audio hub. - jitterBufferDelay climbing steadily: the buffer is growing to absorb variance, which trades choppiness for latency. On a two-way call that added delay is its own problem.
Do this correlation across time, not on a single snapshot. Jitter that spikes for ten seconds and recovers points at a transient (a roam, a background download); jitter that sits high for the whole call points at a saturated path.
How rtcStats surfaces it
Doing that correlation by hand in webrtc-internals means scrolling thousands of metrics and lining up timelines yourself. rtcStats reads the dump for you: it flags the jitter spike as an Observation, ties it to what was happening on the packet-loss and buffer lines at the same moment as a Deduction (network variance versus a buffer running dry), and reflects the impact in the Experience Score so you can see how much the jitter actually hurt the call. The AI Summary gives you the one-paragraph version to paste into your bug thread.
Related
Upload a webrtc-internals or rtcstats dump and rtcStats tells you whether the jitter was the network or the buffer, free.
Was this page helpful?
