Jitter is the variation in when voice packets arrive. A VoIP call chops your voice into small packets, sends one every 20 milliseconds, and expects them to show up on the same steady beat. When they arrive late, early, or out of order instead, that unevenness is jitter, and the person on the other end hears it as choppy words, robotic audio, or gaps.
If you run a voice agent, jitter matters twice. It degrades the caller’s audio on the way in, so your speech-to-text model hears a worse signal, and it degrades the agent’s audio on the way out, so a caller concludes your product is broken. When an agent sounds robotic on phone calls but fine in the browser, check the network before you touch the model.
This guide covers what jitter is, what causes it, how to measure it on a real call, and how to fix it, including the parts of the path a voice agent builder actually controls.
Jitter at a glance
| Metric | Comfortable | Noticeable | Unusable |
|---|---|---|---|
| Jitter | Under 30 ms | 30–50 ms | Over 50 ms |
| Packet loss | Under 1% | 1–3% | Over 3% |
| One-way latency | Under 150 ms | 150–400 ms | Over 400 ms |
These are rules of thumb, not guarantees. The 150 ms and 400 ms latency figures come from the ITU’s Recommendation G.114 on acceptable one-way delay, and the 30 ms jitter figure is the guidance you’ll find in vendor docs like Cisco’s jitter note. A good adaptive jitter buffer can mask more than 30 ms of jitter, at the price of added delay. The overall listening experience across these metrics is what a mean opinion score tries to compress into one number.
What jitter actually is
Voice over IP rides on RTP, the Real-time Transport Protocol. The sender stamps every packet with a sequence number and a timestamp (RFC 3550), so the receiver knows both the order packets were sent and the exact instant each 20 ms slice of audio should play.
Jitter is the gap between that schedule and reality. If packet 41 arrives 20 ms after packet 40, but packet 42 arrives 60 ms after packet 41, the stream has jitter. The same RFC also defines how endpoints report it: every RTP stream is paired with RTCP control messages, and the receiver periodically sends back a receiver report whose fields include the measured interarrival jitter. That’s why every serious phone system can tell you its jitter without any extra instrumentation: the protocol has been keeping score the whole time.
Two neighbors are worth separating out, because they feel similar and get fixed differently:
- Latency is how late packets arrive overall. It makes people accidentally talk over each other, but it doesn’t distort the audio itself.
- Packet loss is packets that never arrive (or arrive too late to use, which the receiver counts as lost). Loss removes slices of audio; jitter just delivers them raggedly. A burst of out-of-order packets looks like loss to the receiver, because the decoder can’t wait around for stragglers.
What jitter sounds like
On a call with rising jitter, people describe the same progression. Words start to clip at the edges. Voices turn metallic or robotic as the decoder interpolates over missing frames. Then come the gaps: half-second silences while the receiver waits for packets that arrive in a clump a moment later. At the extreme, the call drops.
Each of these is the jitter buffer doing its job and running out of room. Which raises the obvious question.
The jitter buffer, and its price
A jitter buffer is a small queue on the receiving side. Instead of playing each packet the moment it lands, the receiver holds packets briefly and releases them on an even cadence, so a packet that arrives 30 ms late still makes its slot. Typical buffers hold 30 to 50 ms of audio; adaptive ones grow and shrink with conditions, sometimes to 100 or 200 ms.
The trade is delay for smoothness. Every millisecond of buffer is a millisecond added to the round trip, and past roughly 150 ms of added delay a conversation starts to feel like a walkie-talkie exchange: each person waits, then talks, then waits. A buffer that’s too small discards late packets and you hear dropouts. A buffer that’s too big hides the jitter and hands you latency instead. There is no setting that gives you both, which is why fixing the network beats tuning the buffer.
Where the buffer lives depends on the call:
- Browser and app calls (WebRTC) include an adaptive jitter buffer and packet-loss concealment by default, as the WebRTC vs WebSocket guide covers. You rarely tune this yourself.
- SIP phones, PBXs, and session border controllers have configurable buffers, and the default is not always right for your network.
- Raw RTP integrations make you the buffer author. If you stream audio off a SIP trunk into your own stack, sizing that buffer is your job.
Where jitter comes from
Jitter is almost always a queuing problem: packets waiting different amounts of time somewhere along the path.
- Congestion. A router or switch port that fills and drains holds packets for unpredictable lengths of time. This is the classic cause, and it shows up at busy hours.
- Wi-Fi and cellular. Wireless links schedule airtime and retransmit quietly, so arrival times vary far more than on Ethernet. The caller on hotel Wi-Fi is not imagining things.
- Missing QoS. Without Quality of Service marking, voice packets queue behind bulk downloads. Marking voice traffic (typically DSCP EF) lets your routers and many carriers’ backbones prioritize it, though markings often don’t survive the public internet.
- Route changes. When traffic shifts to a different path mid-call, the new path’s timing differs from the old one’s, and the stream stutters until the buffer adapts.
- Oversized buffers. Bufferbloat is jitter’s quiet cousin: a huge queue somewhere adds a standing delay that varies with load, and it won’t show up as packet loss anywhere.
How to measure jitter
You don’t need special equipment; the call is already measuring itself.
- Read the RTCP receiver reports. The jitter field is the authoritative number for what the far end experienced. It’s expressed in the stream’s timestamp units, so on a G.711 call you divide by 8 to get milliseconds (most dashboards do the conversion for you). PBXs, SBCs, and CPaaS dashboards surface it per call.
- Capture the stream in Wireshark. Telephony → RTP → Stream Analysis reports jitter and loss per direction and lets you listen to exactly what the receiver had to work with.
- For WebRTC, open chrome://webrtc-internals during the call and watch
jitter,packetsLost, andjitterBufferDelaylive. - As a rough probe, ping the far end. A large spread between average and maximum round-trip times suggests jitter on the path. It’s an estimate, not the metric, because RTP jitter is measured in the audio stream’s own timestamp units.
Measure during real calls at your busiest hour. A quiet-Sunday measurement of a congested-Tuesday problem will tell you everything is fine.
How to fix it
Work from the segment you control outward:
- Prioritize voice on your own network. Mark RTP with DSCP EF and make sure your routers honor it. Put call traffic on wired connections before you touch anything else.
- Size the jitter buffer deliberately. Start near 30–50 ms on devices that let you set it, and prefer adaptive buffers where they’re available.
- Pick codecs that tolerate loss. On legs where you choose the codec, Opus carries in-band forward error correction (RFC 6716). On the public phone network you’ll get G.711, which has no such protection and leans entirely on the buffer.
- Shorten the path. Choose providers with points of presence near your callers. Every extra network segment is another queue that can fill.
- Accept the last mile. You cannot fix a caller’s coffee-shop Wi-Fi. What you can do is measure it, so you stop debugging your own stack for their router.
Jitter and voice agents
An agent call has more links in the chain than a person-to-person call: the caller’s phone, their carrier, your telephony provider or SIP trunk, then your agent stack, and back again. Jitter can enter on any hop, and it stacks with your model latency in the caller’s experience. A caller doesn’t hear “the network added 120 ms of buffer and then the model took 90 ms.” They hear one slow, choppy agent.
Two habits keep the network honest:
- Measure per leg. Read RTCP stats from your telephony provider, and time your speech-to-text and text-to-speech hops separately. Cartesia publishes sub-90 ms model latency for Sonic; that’s the model, and the network leg adds its own delay on top, which is exactly the delay P95 and P99 measurement exists to catch. If the model is fast and the call is still slow or garbled, you’re looking at jitter.
- Test through the real phone path. Phone audio runs at 8 kHz over G.711 μ-law or A-law, through someone else’s jitter buffer. An agent that sounds clean on your laptop can sound broken over a congested carrier route, so make test calls from real phone numbers, at busy hours, before you blame the speech model.
On the Cartesia side, Sonic returns raw μ-law or A-law at 8 kHz directly ("encoding": "pcm_mulaw", "sample_rate": 8000), so telephony audio doesn’t take an extra conversion hop, and Ink accepts the same formats for streaming speech recognition. Managed Agents answer calls on Cartesia numbers, Twilio, or your own SIP trunk and run the telephony leg for you. Agent calls cost $0.03 per minute, and the $0.014 per minute telephony add-on applies only to Cartesia-provisioned numbers. Deployment regions in the US, EU, UK, India, and Australia keep the network path short. SIP trunks connect over TLS with SRTP media, and the SIP trunking guide covers the setup.
And if your jitter turns out to be fine and the agent still sounds robotic, then you have our permission to blame the model.