Jitter is the variation in the time gaps between arriving voice packets, and it’s usually the real culprit behind choppy or robotic-sounding calls. As a practical rule, keep jitter under about 30 milliseconds and most calls will sound clear; push past that and audio starts to break up because packets stop arriving at a steady, predictable pace.
TL;DR:
- Calls remain clear if jitter stays under 30 milliseconds, but higher spikes above 50 milliseconds can cause garbled audio and missed words.
- Most jitter issues originate from network congestion, wireless interference, or device processing delays rather than bandwidth capacity alone.
- Conducting consistent jitter measurements during peak congestion times helps identify whether issues are local or ISP-related before escalating.
- Prioritizing voice traffic with proper QoS, using wired connections, and tuning jitter buffers can significantly reduce call quality problems.
- Managed cloud platforms like NextVoice handle much of the jitter management internally, easing the load on in-house IT teams.
Table of Contents
- VoIP jitter terms and how it differs from latency and packet loss
- Acceptable jitter levels and quality thresholds
- Common causes of jitter
- How to measure and test jitter in your network
- Practical mitigation and configuration fixes to reduce jitter
- Jitter buffers and the trade-offs they introduce
- How jitter affects real calls and everyday call quality
- Differences in jitter effects on various VoIP protocols
- Tools and software for continuous jitter monitoring and alerting
- Best practices for network design to minimise jitter
- The role of ISP performance and peering in jitter
- On-premises versus cloud-based jitter management
- Where operational monitoring actually earns its keep
- A hosted phone platform that carries more of the jitter workload
- Sources
- FAQ
VoIP jitter terms and how it differs from latency and packet loss
Jitter, latency and packet loss get lumped together often, but they measure different things and need different fixes.
Latency is the fixed time it takes a packet to travel from sender to receiver, expressed as a single number. Jitter is the variability in that travel time between consecutive packets, measured formally as inter-packet delay variance. Packet loss is different again: it counts packets that never arrive at all, rather than ones that arrive late or unevenly spaced.
- Latency is a constant delay, like a 100 millisecond round trip that stays roughly the same call after call.
- Jitter is the wobble around that average, where one packet arrives in 20 milliseconds and the next takes 60.
- Packet loss is a missing packet altogether, which forces the receiving device to guess or skip a slice of audio.
Codec choice and packetisation interval change how much jitter actually hurts. A codec sending small packets every 20 milliseconds is more sensitive to timing variation than one using a longer interval, because there are more opportunities for gaps to appear in the stream. Wider intervals reduce that sensitivity but add their own delay, so the trade-off has to suit the network it’s running on.
Acceptable jitter levels and quality thresholds
Most VoIP calls sound fine when jitter stays under roughly 30 milliseconds, alongside packet loss under 1% and one-way latency under about 150 milliseconds. Those three figures work together: a call can have low average jitter and still sound poor if loss or latency slips outside its own range.
Jitter under 30 milliseconds is commonly cited as the threshold below which VoIP call quality holds up. That figure comes from network testing guidance rather than a single hard cutoff, but it’s a useful benchmark for judging your own measurements.
Averages hide a lot. A connection that averages 15 milliseconds of jitter can still produce a rough patch of audio if it has occasional spikes to 80 or 100 milliseconds, because the jitter buffer has to cope with the worst moments, not the mean. This is why a single average figure from a five-minute test can look healthy while a call still drops words.
- Under 30 ms: generally clear audio with no noticeable distortion.
- 30 to 50 ms: occasional choppiness, more noticeable on longer calls or busier networks.
- Above 50 ms, or frequent spikes: robotic or garbled audio, dropped syllables, and calls that feel like a bad mobile connection.
Common causes of jitter
Jitter almost always traces back to something making packet delivery inconsistent rather than simply slow. Working through likely causes in order saves time before reaching for a fix.
- Network congestion and queuing: when a router or switch queues traffic during busy periods, voice packets sit behind other traffic and arrive at uneven intervals.
- Wireless variability: Wi-Fi interference, signal degradation and device roaming between access points all introduce inconsistent delay on the last hop to a handset or softphone.
- Router or firewall CPU spikes: a device struggling to process traffic, along with bufferbloat or a misconfigured quality of service policy, can delay packets unevenly even on a fast connection.
- Misconfigured access control lists: overly complex or poorly ordered ACLs force extra processing per packet, adding small but variable delays.
- Path changes and asymmetrical routing: when packets take different routes in each direction, or a path changes mid-call due to a routing update, timing becomes unpredictable.
- Carrier or peering problems: congestion at an interconnection point between networks can introduce jitter that no amount of local tuning will fix.
Most jitter problems sit in the first three categories, which is also why testing on your own network before calling a provider usually pays off.
How to measure and test jitter in your network
Before applying a fix, get a baseline. A handful of straightforward tests will usually tell you whether the problem sits on your local network, your wireless setup or somewhere upstream.
- Ping series test: run a continuous ping to a stable target for several minutes and record the variation between consecutive response times rather than just the average.
- Wired bandwidth test: connect a laptop directly to your modem and run a speed and latency test to rule out ISP level issues before blaming your office network.
- Two-ended RTP capture: use a packet capture tool such as Wireshark on both ends of a call to measure inter-packet arrival times and spot sequence gaps directly in the voice stream.
- Device-by-device isolation: repeat tests on different devices and switch ports to see whether the issue follows a specific machine, port or access point.
- Wired versus wireless comparison: run the same test over Ethernet and Wi-Fi from the same location to confirm whether the wireless hop is contributing.
Record the numbers each time, not just a pass or fail impression, so you can compare before and after any change.
Pro Tip: Test at the same time of day you experience the worst call quality. Jitter tied to congestion often disappears during quiet hours, which can mask the real problem if you only test when the network is idle.
A sensible escalation path runs from the handset outward: check the local device and cable, then the switch and access point, then the router and firewall, and only then the ISP or VoIP provider, since ruling out your own equipment first makes any conversation with a provider far more productive.
Practical mitigation and configuration fixes to reduce jitter
Once you know where jitter is coming from, most fixes fall into a short list of configuration changes rather than new hardware.
- Configure QoS and DSCP tagging correctly. Tagging voice traffic with DSCP EF (46) and prioritising it at the network edge is one of the most reliable fixes, because jitter is often caused by queuing and congestion rather than a lack of raw bandwidth.
- Prefer wired Ethernet to Wi-Fi where practical. A wired connection removes an entire layer of variability; where Wi-Fi is unavoidable, careful access point placement and channel planning reduce contention.
- Address bufferbloat directly. Smart queue management such as fq_codel keeps a router’s outbound queue from ballooning under load, and checking that router CPU and firmware are up-to-date prevents processing delays that masquerade as network jitter.
- Tune jitter buffers sensibly. Favour adaptive buffers where your platform supports them, and balance packetisation interval against added delay rather than defaulting to the smallest possible setting.
- Escalate with evidence. When the problem persists after local fixes, share a packet capture, a timestamped ping series and the specific times issues occurred with your VoIP provider or ISP: those logs turn a vague complaint into a fixable ticket.
Pro Tip: Simply adding more bandwidth rarely fixes jitter on its own. If the bottleneck is queuing discipline rather than capacity, a faster connection with the same misconfigured QoS policy will show the same problem.
Jitter buffers and the trade-offs they introduce
A jitter buffer holds incoming packets briefly and reorders them so audio plays back at a steady pace, smoothing over the timing variation that would otherwise cause gaps or overlaps. Fixed buffers hold a set delay regardless of conditions, while adaptive buffers shrink when the network is stable and grow only when jitter increases, which generally performs better in practice.
The trade-off is added latency. For planning purposes, a de-jitter buffer sized to absorb 50 milliseconds of variation adds roughly 25 milliseconds to average delay, since the buffer holds packets for roughly half its peak capacity on average.
| Buffer peak capacity | Approximate added mean delay |
|---|---|
| 20 ms | 10 ms |
| 50 ms | 25 ms |
| 100 ms | 50 ms |
Sizing a buffer too large to chase perfect smoothness can push mouth-to-ear delay high enough that conversation starts to feel laggy, with people talking over each other. Asterisk’s own guidance warns that an excessively large maximum buffer introduces perceptible conversational lag, so the goal is the smallest buffer that clears the jitter you actually measured, not the largest one available. WebRTC implementations face a related challenge during sudden packet bursts, where burst-aware buffer strategies can reduce dropped packets compared to default handling.
How jitter affects real calls and everyday call quality
Jitter doesn’t announce itself as a technical fault. It shows up as syllables clipped from the start of a word, a voice that briefly sounds robotic, or a call that seems to lag half a beat behind normal conversation. On a short internal call between two people in the same office, mild jitter might go unnoticed. On a longer client call, or a conference call with several participants, the same level of jitter compounds: each additional voice stream adds another chance for timing to slip, and the tolerance for choppy audio drops sharply once someone is trying to close a deal or explain something technical.
Video calls suffer differently again. Audio jitter on a video call can desynchronise voice from lip movement even when the video itself looks smooth, which feels more jarring than audio-only distortion because the mismatch is visually obvious. Calls carrying background music or hold recordings, such as those routed through an automated attendant, tend to mask mild jitter better than live conversation, since the ear is more forgiving of imperfect audio when it isn’t following speech in real time. The practical takeaway is that the same jitter measurement can produce very different user experiences depending on call type, participant count and whether video is involved.
Differences in jitter effects on various VoIP protocols
SIP, H.323 and WebRTC all carry voice over the same underlying RTP stream, but the surrounding protocol shapes how jitter gets handled and how visible it becomes to the person on the call.
SIP is the most common signalling protocol for business phone systems and leaves jitter buffering largely up to the endpoint or softphone implementation, meaning quality can vary between devices even on an identical network. H.323, older and more common in legacy enterprise video conferencing, tends to bundle more rigid timing assumptions into its call setup, which can make it less forgiving of variable delay than SIP’s more flexible negotiation. WebRTC, used heavily in browser-based calling and modern collaboration tools, includes its own adaptive jitter buffer logic, but research into WebRTC buffer behaviour has found that sudden packet bursts can overflow default handling and cause avoidable drops.
None of these protocols eliminates jitter, since jitter is a property of the network path, not the signalling layer. What differs is how much buffering intelligence sits at the endpoint and how gracefully that endpoint recovers from a burst of variable delay. For most business users, the practical implication is less about which protocol their phone system uses and more about ensuring the endpoint, whether a desk phone, softphone or browser client, has sensible jitter buffer settings rather than defaults tuned for a different network.
Tools and software for continuous jitter monitoring and alerting
Testing jitter once during a troubleshooting session tells you what happened at that moment. Continuous monitoring tells you what’s actually happening when nobody is watching, which is usually when problems occur.
Network monitoring platforms that support Voice Quality of Service metrics can track jitter, latency and packet loss over time and alert when any of them crosses a threshold you set, rather than waiting for a complaint. Packet capture tools such as Wireshark remain the standard for deep, point-in-time diagnosis of a specific call, letting you inspect RTP sequence numbers and timestamps directly. Router and switch built-in diagnostics, where available, can flag interface-level congestion or errors that correlate with reported call quality issues, which is often faster than starting with a full packet capture.
The practical setup for most small and medium businesses is a lightweight combination: ongoing threshold-based alerting on the network side, paired with the ability to pull a targeted packet capture when an alert fires or a user reports a problem. Alerting without the ability to drill into a specific incident tells you something is wrong without telling you why, and a one-off capture without ongoing monitoring means you only ever see the problem after someone has already had a bad call.
Best practices for network design to minimise jitter
Good network design reduces how often jitter becomes a problem in the first place, rather than relying entirely on buffers and QoS to paper over it after the fact.
Segmenting voice traffic onto its own VLAN keeps it separate from bulk data traffic like file transfers and backups, so a large download doesn’t compete for the same queue as an active call. Applying QoS and DSCP tagging consistently across every device in the path, not just the router, matters because a single untagged switch can undo prioritisation set everywhere else. Sizing bandwidth with real headroom for voice, rather than assuming leftover capacity will be enough, avoids the congestion that causes most queuing-related jitter. Keeping firmware current on routers, switches and access points closes a surprising number of jitter complaints, since CPU-related processing delays are often fixed in later firmware releases rather than through configuration changes. Finally, designing for redundancy, such as a secondary internet connection or failover path, protects against the sudden path changes and asymmetrical routing that introduce jitter when a primary link degrades without failing outright.
The role of ISP performance and peering in jitter
Not every jitter problem lives inside the office. Once traffic leaves the local network, it depends on the performance of the internet service provider carrying it and the quality of the connections between that provider and everyone else’s network.
Peering, the arrangement where networks exchange traffic directly rather than routing through a third party, affects how consistent that handoff is. Congestion at a peering point during busy periods can introduce jitter that no amount of local QoS configuration will resolve, because the variability is happening well outside the customer’s own equipment. This is one reason the wired bandwidth test described earlier matters: testing directly against the modem, bypassing the office network entirely, isolates whether jitter is originating locally or arriving already present in the connection.
When a wired test at the modem still shows elevated jitter, the fault most likely sits with the ISP or somewhere further upstream. At that point, the escalation path outlined earlier applies: supply the provider with timestamped test results and packet captures rather than a general description of poor call quality, since specific evidence is what allows an ISP to investigate a peering or capacity issue rather than simply reset the connection and hope it helps.
On-premises versus cloud-based jitter management
Where jitter gets managed changes significantly depending on whether a VoIP system runs on-premises or through a cloud platform, and that difference matters when deciding where to focus troubleshooting effort.
An on-premises system puts the entire burden of QoS configuration, jitter buffer tuning and monitoring on the business’s own IT team and hardware. Every fix described earlier, from DSCP tagging to firmware updates to buffer sizing, has to be implemented and maintained locally, which works well for teams with dedicated network expertise but leaves smaller businesses exposed when nobody has the time or background to keep on top of it.
A cloud-based platform shifts jitter mitigation for everything within the provider’s own network and infrastructure onto that provider, including the resilience of its cloud architecture and the consistency of its own QoS handling. What remains the customer’s responsibility is the local network: the office router, switches, Wi-Fi and internet connection, since jitter introduced there is outside any cloud provider’s control. The practical difference isn’t that cloud platforms eliminate jitter entirely, but that they remove one whole layer of complexity from the business’s side, leaving a narrower and more manageable set of things to test and fix locally.
Where operational monitoring actually earns its keep
Most jitter problems get caught late because nobody was watching until a call went badly. Alerting on jitter, latency and packet loss thresholds before anyone complains is the single highest-value habit an operations team can build, alongside a recorded baseline to compare against when something changes.
Roll out fixes in stages and test them during low-impact windows rather than pushing a QoS change live during business hours and hoping. For teams without dedicated network expertise, a managed platform that centralises QoS and monitoring across its own infrastructure removes a genuine source of risk, though it never replaces the need to test and monitor whatever sits on the local side of the connection.
— Stuart
A hosted phone platform that carries more of the jitter workload
Managing QoS, monitoring and jitter mitigation across an entire network takes ongoing attention that not every business has the staff to give. NextVoice is a cloud communications platform that handles that workload across its own infrastructure, built on a resilient cloud architecture, so the jitter-related configuration inside that provider domain isn’t left to your team alone.
- NextVoice and NextMobile give teams a scalable, hosted way to stay connected without on-premise hardware.
- AI Call Intelligence adds call recording and analysis for businesses that want deeper insight into call quality and outcomes.
- A technical audit can help pinpoint where jitter or call quality issues are actually coming from before you commit to a fix.
If your team is spending more time chasing jitter than running the business, request a technical audit or get in touch with Vadacom’s support team to talk through what a managed platform would handle for you.
Sources
- Network Jitter: How to Test, Measure, and Reduce Jitter in VoIP – DNSstuff
- ITU-T Rec. G.114 (05/2003) One-way transmission time
- Jitter buffer features and operations — Asterisk
- How to Detect and Prevent VoIP Packet Loss – PathSolutions
FAQ
What is a good jitter for VoIP?
Jitter under about 30 milliseconds is generally considered good for VoIP, alongside packet loss under 1% and one-way latency under roughly 150 milliseconds. Occasional spikes above that average can still cause noticeable audio problems even when the overall average looks fine.
How do you fix jitter?
Start by prioritising voice traffic with QoS and DSCP tagging, since jitter often comes from queuing and congestion rather than a lack of bandwidth. Preferring wired connections over Wi-Fi, addressing bufferbloat, and tuning your jitter buffer size all help once congestion is under control.
Is 2 ms jitter considered bad?
No, 2 milliseconds of jitter is well within the range considered good for VoIP, sitting far below the roughly 30 millisecond threshold commonly used to judge acceptable call quality. At that level, most listeners would not notice any audio distortion at all.
What are some common problems with VoIP?
Beyond jitter, common VoIP problems include packet loss, where dropped packets cause gaps or garbled words, and latency, where a constant delay makes conversation feel laggy. Network congestion, Wi-Fi interference and misconfigured router quality of service settings are frequent underlying causes of all three.