What Causes Jitter in VoIP Calls and How to Trace It

What causes jitter on a call is variation in packet delivery timing, and the dominant cause is queueing at congested routers. Serialization behind large packets, route changes, and uneven output from the sending application all add to it. This guide traces each cause to the layer where you can fix it.

What causes jitter inside the network

Three mechanisms account for most network side delay variation, and they are the jitter causes worth learning to tell apart, because each one is fixed somewhere different.

Queueing under contention. A packet that arrives at a router while the output queue is busy waits. How long it waits depends on what else is in that queue at that instant, which varies packet by packet. This is the default cause and the reason jitter tracks load.

Serialization behind large packets. This one is quantified in the standards. ITU-T Recommendation Y.1541 sets network performance objectives for IP networks, and the note attached to its delay variation objective states the value "is dependent on the capacity of inter-network links," and that smaller variations are possible when all capacities are higher than the primary rate, T1 or E1, or when competing packet information fields are smaller than 1500 bytes. In plain terms: a 1500 byte file transfer packet ahead of your 20 ms audio frame on a slow link delays it by a fixed serialization time, and whether that happens is a coin flip per packet. Narrow links and large competing packets are a cause, not just a condition.

Route changes. Delay variation over longer intervals often reflects the path changing rather than the queues filling. Work from Roma Tre University, published as From BGP to RTT and Beyond: Matching BGP Routing Changes and Network Delay Variations with an Eye on Traceroute Paths, sets out a methodology for deciding whether latency fluctuations measured by a probe depend on interdomain routing changes, using publicly accessible BGP route collectors inside the same network. The authors validate it against data published by the RIPE NCC and show examples of correlation between the two. The practical lesson is that a step change in delay variation with no matching change in traffic is worth checking against routing history rather than blamed on congestion.

Access technology sits underneath all three. A wireless station waits for a clear channel before each frame and retransmits frames that collide, so the same audio packet can leave the access point at a different offset every time. Shared last mile links behave the same way under load. That is why the same agent can look clean on a wired test and poor in production, and why a complaint that lands only for some callers is a pattern worth taking literally.

The cause that is not in the network at all

This is the one most explanations of the topic omit, and it matters more for voice AI than for traditional telephony.

RFC 3550, which defines RTP, notes that because the jitter calculation is based on the RTP timestamp, which marks the instant the first data in the packet was sampled, any variation in the delay between that sampling instant and the time the packet is actually transmitted will affect the resulting jitter figure. It gives the specific trigger: "Such a variation in delay would occur for audio packets of varying duration."

The specification then concedes the measurement consequence directly. That variation in delay until transmission "does reduce the accuracy of the jitter calculation as a measure of the behavior of the network by itself," though it is appropriate to include because the receiver buffer has to absorb it anyway.

For an AI voice agent this is a live risk rather than a footnote. A synthesis stage that emits audio in uneven chunks, a garbage collection pause, or a scheduler delay between generating a frame and putting it on the wire all show up in RTCP as interarrival jitter. The number rises, the network is blameless, and an infrastructure team can spend a week on a problem that lives in the agent process.

RFC 3550 offers a discriminator, with a limit attached. The sender side component is roughly constant, so it subtracts out when you use jitter comparatively, and a change in the network component can then be observed against it. The specification adds the caveat: that only holds unless the change is relatively small, and a change that small it judges likely to be inconsequential.

What causes jitter depends on which jitter you mean

One ambiguity is worth clearing up, because it explains why search results on this term scatter.

RFC 3393 records that "jitter" commonly has two meanings. The first is the variation of a signal with respect to some clock signal, the sense used for synchronous signals and circuit emulation, which has a companion metric called wander. The second is the variation of a metric such as delay with respect to a reference metric such as average or minimum delay. One is timing error in a synchronous signal, the other is queueing.

The IETF position is worth noting: RFC 3393 says it will avoid the term wherever possible and use delay variation instead, as the more precise description. The metric it defines is IP Packet Delay Variation, or IPDV, based on the difference in one way delay between selected packets in a stream. This guide uses that second sense throughout, the one that degrades a phone call.

The definition that makes delay variation measurable

Before you can attribute a cause you need to know what the number on your dashboard is counting.

RFC 3550 specifies interarrival jitter as the mean deviation, meaning the smoothed absolute value, of the difference in packet spacing at the receiver compared to the sender for a pair of packets. For packets i and j, with S the sender timestamp and R the arrival time in the same units, that difference is:

D(i,j) = (Rj - Ri) - (Sj - Si)

The reported value is a running smoothed estimate, updated on every packet:

J(i) = J(i-1) + (|D(i-1,i)| - J(i-1))/16

Two things follow from that formula. The gain of one sixteenth makes it a lagging estimator. RFC 3550 describes the algorithm as the optimal first order estimator, and credits that gain parameter specifically with giving a good noise reduction ratio while maintaining a reasonable rate of convergence. And RFC 3550 requires that the calculation conform to this formula so that monitors can compare reports from different implementations, which is the only reason a jitter figure from one vendor's tooling means anything next to another's.

The specification is also blunt about the limits of its own metric. The interarrival jitter field, it says, "is only a snapshot of the jitter at the time of a report and is not intended to be taken quantitatively." It is built for comparison across reports over time or across receivers in one network, not for a single reading you can hold up as a verdict.

Why a 50 ms jitter target is not what it appears to be

Thresholds circulate for this metric with no provenance attached. The figure that does have provenance is more specific, and more limited, than the way it is usually quoted.

Y.1541 sets a delay variation objective of 50 ms. Three qualifications travel with that number and are load bearing:

So the 50 ms objective is a 99.9th percentile bound, it is binding only for the two Table 1 classes intended for conversational traffic, and Y.1541 itself says telephony evaluations need an interval of the order of 10 to 20 seconds at typical rates of 50 to 100 packets per second. It suggests a one minute evaluation interval and requires that the interval be recorded alongside the observed value.

The unspecified classes deserve a plain reading. Where Y.1541 marks a parameter "U", it states that performance for that parameter "may, at times, be arbitrarily poor." A path that is not engineered to a conversational class carries no delay variation guarantee at all.

The practical consequence is that a mean jitter figure with no percentile, no interval, and no class attached cannot be compared to this objective, or to another vendor's number. Most quoted thresholds are of that kind.

How delay variation becomes something a caller can hear

Delay variation does not degrade audio by itself. A de-jitter buffer at the receiver holds arriving packets and releases them on a steady clock, converting variable arrival into uniform playout. Audio breaks when the buffer is the wrong size, and both directions of wrong cost something.

Too shallow and late packets miss their playout slot and are discarded, which is heard as clipped words or dropouts. Too deep and every packet waits longer than it needs to, spending the conversational latency budget on insurance. Y.1541 makes the sizing dependency explicit when it warns that using lower quantile values "will result in under-estimates of de-jitter buffer size," with effective packet loss exceeding the loss objective as a result.

For a voice agent the tradeoff is sharper than for a human call, because the latency budget is already committed to recognition, the language model, and synthesis. Buffer depth bought to smooth delay variation comes straight out of that budget, which is why jitter and perceived responsiveness cannot be tuned independently.

There is one more reason to watch the metric even when audio sounds fine. RFC 3550 observes that packet loss tracks persistent congestion while the jitter measure tracks transient congestion, and that jitter "may indicate congestion before it leads to packet loss." Rising delay variation on a clean call is an early warning, which is the strongest argument for monitoring it continuously rather than sampling it during incidents.

How to reduce jitter, and what each fix costs

Every fix here buys stability with something. The cost is stated because a recommendation without one is not actionable.

1. Give voice its own queue. Y.1541 pairs its classes 0 and 1, the real time jitter sensitive classes it names for VoIP, with the same node mechanism: a separate queue with preferential servicing, plus traffic grooming. The routing treatment differs between them, and usefully so. Table 2 pairs class 0 with constrained routing and distance, while class 1 is explicitly allowed less constrained routing and distances. Cost: the marking has to be honoured at every hop, which means it belongs in the provider contract, not just in your router config. Across the public internet it usually is not.
2. Raise link capacity, or shrink the packets competing with voice. This follows directly from Y.1541's Note 3 on inter-network link capacity: smaller variations are possible when capacities exceed the primary rate, or when competing packet information fields are under 1500 bytes. Cost: bandwidth, or per link configuration and added header overhead if you fragment large packets instead.
3. Put the agent's media path on wired access. Removes the contention and retransmission behaviour that makes wireless variable. Cost: low on your side, and nothing at all on the caller's side, which you do not control. This fixes half the path.
4. Size the de-jitter buffer from the quantile, not the mean. Y.1541 warns that lower quantile values produce under-estimates of buffer size and effective loss above the loss objective. Cost: every millisecond of depth lands in the conversational budget, so this trades responsiveness for intelligibility.
5. Fix the sender before touching the network. Steady packet durations remove the component RFC 3550 says reduces the metric's accuracy as a measure of the network. Cost: engineering time inside the agent process, which is usually cheaper than the week spent chasing a network problem that was never there.

Cekura tests a release candidate against the same scenario set before it ships, which is where a regression in that fifth item surfaces as a scored audio defect rather than as a network ticket after release.

How to diagnose what causes jitter on one specific call

Attribution is a process of elimination across layers, in this order.

1. Establish which metric you are reading. Confirm it is RTP interarrival jitter computed per RFC 3550, and record the interval and percentile. A mean over an unknown window is not evidence. Cekura's monitoring guidance is to alert on a sustained pattern across several samples rather than on a single spike, which is the discipline RFC 3550 asks for when it describes the field as a basis for comparison across reports rather than a standalone reading.
2. Separate sender from network. Compare delay variation measured at the sending host against the value reported by the receiver. A gap that persists across network conditions points at variable packet duration or scheduling in your own pipeline.
3. Correlate with load. Delay variation that rises and falls with concurrent call volume is queueing. Cekura runs concurrent call load deliberately for this reason, because a stack that is clean on a single call often is not at scale.
4. Check the path. A step change with no load change is a routing or access change. Compare against routing history before assuming congestion.
5. Score the audio, not just the packets. Cekura scores clarity from the audio channel rather than the transcript, which is the only way to catch degradation that leaves the words intact. Our voice audio quality monitoring covers what that captures on live traffic.

Cekura runs that scoring both in pre-release testing and against live calls, so a buffer or codec change that trades audio integrity for responsiveness is caught before release and still tracked afterwards. The full voice AI latency guide works through where the rest of the budget goes.

Cekura keeps failed connections visible in its published voice agent benchmarks rather than dropping them from results, and reports no connect calls separately under infrastructure reliability across the seven platform configurations tested. That methodology choice matters for this topic: network layer problems can surface as calls that never connected cleanly, and a benchmark that discards them reports a reliability figure that survived its own worst cases. Cekura publishes no jitter specific figure, and we will not quote one we have not measured.

For the measurement side of this work, our VoIP call quality testing guide covers how to run the tests that produce these numbers.

Frequently asked questions about jitter

What is jitter?

Jitter is the variation in delay across a stream of packets. RFC 3550 measures it as the smoothed mean deviation of the difference in packet spacing at the receiver compared to the sender, and RFC 3393 prefers the term delay variation, because jitter also names timing error in synchronous signals. Latency is how long a packet takes; jitter is how much that time varies from packet to packet.

What causes jitter on a VoIP call?

Variable queueing delay at routers under contention is the usual cause, followed by serialization behind large competing packets on narrow links and by path changes. A fourth cause sits in the sending application: audio packets of varying duration change the measured value without any network involvement.

Is 30 ms of jitter acceptable?

The question cannot be answered without the statistic behind it. The 50 ms objective in ITU-T Y.1541 is an upper bound on the 99.9th percentile of delay above the path minimum, and in Table 1 it applies only to classes 0 and 1; the provisional classes 6 and 7 carry the same 50 ms at a stricter quantile that need not be met until revised. A 30 ms mean and a 30 ms 99.9th percentile describe very different calls, and neither is comparable to a threshold quoted with no interval or class attached.

Can jitter exist without packet loss?

Yes, and that combination is diagnostically useful. RFC 3550 notes that packet loss tracks persistent congestion while jitter tracks transient congestion, and that jitter may indicate congestion before it causes loss. Delay variation rising on a call with no loss is an early warning rather than a contradiction.

Does a bigger jitter buffer fix jitter?

It hides delay variation at the cost of latency, and only up to a point. A deeper buffer discards fewer late packets but adds delay to every packet, which for a voice agent comes out of a turn to turn budget that is already tight. Y.1541 warns that underestimating the quantile leads to undersized de-jitter buffers and effective loss above the loss objective.

Why does my monitoring show jitter when the network looks healthy?

Most often because the metric is including your own sender. RFC 3550 states that variation in delay between the sampling instant and transmission affects the calculated value, and that this reduces its accuracy as a measure of the network by itself. Uneven synthesis output or scheduling delay inside an agent produces exactly this pattern. Cekura scores the delivered audio alongside the packet metrics, which is one more signal for telling the two apart.