Jitter is not packet loss
Voice is sent as a steady stream of small packets — with 20 ms packetisation, one every 20 milliseconds, fifty per second. The receiver needs to play them out at exactly that steady rate to reproduce natural speech.
Networks do not deliver packets on a metronome. Queuing, varying routes and competing traffic mean packets arrive unevenly: one after 18 ms, the next after 31 ms, the next after 12 ms. That variation in arrival timing is jitter.
The distinction from packet loss matters. With loss, data is genuinely gone. With jitter, every packet arrives — just at the wrong moment. Played out as they land, the result is stuttering, choppy, robotic audio, even though nothing was actually lost.
What the buffer does
A jitter buffer fixes this by deliberately introducing delay. Instead of playing each packet the instant it arrives, the receiver holds a small reserve — say 60 ms — and plays from that reserve at a steady rate. Packets arriving early wait their turn; packets arriving late still make it in time, because the buffer has bought them a margin.
The trade-off is direct and unavoidable: a jitter buffer converts timing variation into latency. A bigger buffer absorbs more jitter and adds more delay. This is the entire tuning problem.
Too small, and packets arriving late miss their playout slot. The buffer discards them, and a discarded packet sounds exactly like a lost one — which is why systems with heavy jitter report loss-like symptoms while the network shows no actual loss.
Too large, and the audio is smooth but the conversation degrades. Past roughly 150 ms of one-way delay, people begin talking over each other. You can buffer your way to perfectly clean audio in a conversation nobody wants to have.
Fixed vs adaptive
A fixed buffer holds a constant amount of audio regardless of conditions. It is predictable and cheap, and it is the right choice when jitter is stable — a dedicated circuit, or calls confined to a well-managed LAN. Its weakness is that it must be sized for the worst case, so you pay that latency permanently even when the network is behaving.
An adaptive buffer measures observed jitter continuously and resizes itself, growing when the network deteriorates and shrinking when it settles. On the public internet, where conditions change constantly, this is almost always what you want: low latency when things are good, resilience when they are not.
The cost of adaptation is that resizing is not free — the buffer has to stretch or compress audio to change depth, which can produce brief artefacts during a large adjustment.
Configuring it in Asterisk
Asterisk's jitter buffer is configured in jitterbuffer.conf and applies on channels where it is enabled:
[default]
jbenable = yes
jbimpl = adaptive
jbmaxsize = 200
jbresyncthreshold = 1000
jbtargetextra = 40Taking those in turn: jbenable switches buffering on. jbimpl selects the implementation — fixed or adaptive. jbmaxsize caps the buffer in milliseconds, bounding worst-case added latency. jbresyncthreshold sets how far timestamps may drift before the buffer resynchronises, which prevents a single glitch from permanently confusing it. jbtargetextra adds a safety margin above the measured requirement, trading a little latency for fewer late discards.
An important architectural point: Asterisk only buffers where it is actually handling the media. If a call is bridged natively and the RTP flows directly between the endpoints, Asterisk never sees the packets and cannot buffer them — the phones' own buffers do that work. So if you enable buffering and observe no change, check whether direct media is in play.
Diagnosing jitter problems
Start by confirming jitter is really the cause. RTCP carries jitter statistics, and Asterisk surfaces them per channel — check them during a bad call rather than after.
Watch the live RTP stream:
asterisk -rvvv
rtp set debug onThe pattern to recognise: reported packet loss near zero while audio sounds broken, plus a rising jitter figure. That combination means packets are arriving but too erratically to be played smoothly, and the buffer is discarding the stragglers.
Then fix the cause rather than only the symptom. Persistent jitter usually traces to congestion on a link you control — most often a saturated upload. Prioritising voice traffic with QoS on your own gateway addresses the source; buffer tuning only makes the consequences less audible. Buffering is a mitigation, not a cure.
Frequently asked questions
What causes jitter in VoIP?
Uneven packet delivery, almost always from congestion — a saturated link where voice packets queue behind bulk traffic. Wi-Fi and variable-latency paths also contribute.
How much jitter is acceptable?
Under about 30 ms is comfortable for most deployments and is absorbed by a modest buffer. Beyond that you need a larger buffer, which costs latency, and the underlying congestion is worth fixing instead.
Should I use a fixed or adaptive jitter buffer?
Adaptive for anything crossing the public internet, where conditions vary. Fixed is reasonable on a stable, controlled network where predictability matters more than optimisation.
Why does my call have no packet loss but still sounds choppy?
That is the classic jitter signature. The packets are arriving, but too late for their playout slot, so the jitter buffer discards them. The network reports no loss because nothing was actually lost in transit.