VoIP Call Quality Troubleshooting: Jitter, Latency and Packet Loss
VoIP call quality troubleshooting is the process of identifying why calls sound bad by measuring jitter, packet loss and latency, rather than inferring a cause from how the connection feels. The single most important thing to understand is that insufficient bandwidth is rarely the problem — and buying a bigger circuit is the most common expensive misdiagnosis in business telephony.
A voice call on the Opus codec uses roughly 50 kbps in each direction. A fifty-person office with a third of staff on calls simultaneously needs well under 1 Mbps for voice. Almost any modern business connection already has that. If your calls sound bad, something other than capacity is wrong.
What do the symptoms actually mean?
Different symptoms point at different causes. Getting the description right narrows the investigation enormously.
| Symptom | Likely cause |
|---|---|
| Choppy, words dropping out | Packet loss |
| Robotic or warbling audio | Jitter — packets arriving unevenly |
| Both parties talking over each other | High latency |
| Echo | Acoustic feedback or an analogue gateway |
| One-way audio | Firewall or NAT traversal, usually RTP blocked in one direction |
| Audio fine, call drops | Signalling or registration, not media |
“The call was bad” is not actionable. “Words dropped out roughly every ten seconds for the first two minutes” is.
What are jitter, latency and packet loss?
These three govern voice quality. Throughput barely features.
Latency is one-way delay. Below about 150 ms, conversation feels natural. Above roughly 250 ms, people start talking over each other because the natural turn-taking rhythm breaks down. Latency is largely a function of physical distance and routing — you cannot negotiate with the speed of light, though you can avoid routes that take unnecessary detours.
Jitter is variation in packet arrival time. Voice packets are sent at even intervals, typically every 20 ms, and need to be played back at those same intervals. When they arrive unevenly, a jitter buffer holds them briefly to smooth playback. If jitter exceeds what the buffer can absorb, packets arrive too late to use and are discarded — producing the robotic, warbling sound. Jitter causes more complaints than any other single factor.
Packet loss is packets that never arrive. Voice tolerates a surprising amount — around 1% is usually imperceptible because codecs conceal small gaps. Loss above roughly 3% becomes clearly audible, and loss in bursts is far worse than the same percentage spread evenly, because consecutive missing packets cannot be concealed.
Why does bandwidth get blamed so often?
Because it is the one number people have.
Everyone knows their connection speed. Almost nobody measures jitter. So when calls sound bad, the available number gets blamed and the circuit gets upgraded — which fixes nothing, because the link had ample spare capacity all along.
Worse, a bigger circuit can make things worse in one specific way: more capacity encourages more bulk traffic, and if voice is not prioritised, it now queues behind larger transfers. Our bandwidth calculator sizes the actual voice requirement so you can confirm capacity is not the issue, then stop looking there.
How do I narrow down the cause?
Scope first. It is faster than any measurement.
- One user only — their device, headset, or local network. Check Wi-Fi signal strength and whether a VPN is routing voice through a distant endpoint.
- One site — the site’s internet connection, router, or QoS configuration.
- One destination or country — a carrier route problem, not your network. Collect examples and escalate to your provider with call IDs.
- Everyone, everywhere — provider-side. Check the system status page before investigating your own network.
- Only at certain times — congestion. Correlate against backups, large uploads, or shift changes.
That last one is worth emphasising: a problem that appears at 9am and 2pm daily is almost certainly contention with something scheduled, not a fault.
Why is Wi-Fi so often the culprit?
Because it is shared, interference-prone, and invisible in most monitoring.
Wi-Fi introduces jitter in ways wired Ethernet does not: distance from the access point, physical obstructions, competing networks on the same channel, and device roaming between access points mid-call. A laptop that switches access point during a call will usually produce an audible glitch.
Always reproduce the problem on a wired connection before escalating. If it disappears on Ethernet, the investigation belongs with your wireless network, not your provider. This single test resolves a large share of reported quality issues.
What does QoS actually do?
Quality of Service marks voice packets so network equipment handles them ahead of bulk data.
Without it, a voice packet and a chunk of someone’s file upload are treated identically. When the link is busy, voice waits in the same queue — and a 200 ms queuing delay destroys a call while being completely invisible to a large file transfer.
QoS does not create capacity. It decides what gets served first when capacity is contested, which is exactly the problem voice has. Configure it on the router and on any managed switches between the phones and the edge. This fixes more call quality problems than any other single change.
When is it the provider’s fault?
It genuinely can be — particularly on specific international destinations, where the route your provider uses determines latency and loss in ways your network cannot influence.
Escalate when the problem is destination-specific, affects multiple sites, or persists on a wired connection with QoS confirmed.
Escalate with evidence: measured jitter, loss and latency figures, timestamps, affected call IDs, and the destination numbers involved. A provider can trace specific calls through their network. They cannot investigate “calls to Brazil sound bad sometimes.”
Does changing codec help?
It is a useful diagnostic even when it is not the fix.
Opus (~50 kbps) adapts to network conditions and conceals loss well. G.711 (~87 kbps) is uncompressed, so it uses more bandwidth but requires no compression processing. G.729 (~31 kbps) compresses heavily for constrained links at some quality cost.
If switching from Opus to G.711 improves things, the problem is unlikely to be bandwidth, since G.711 uses more. If G.729 improves things on a constrained link, capacity genuinely was a factor. Either result tells you something useful.
Frequently asked questions
How much bandwidth does a VoIP call need?
Roughly 50 kbps in each direction on Opus, or about 87 kbps on G.711, including protocol overhead. Size by concurrent calls rather than headcount — most offices need far less than they expect.
What is an acceptable level of jitter?
Below about 30 ms is generally fine, as jitter buffers absorb it. Above that, packets start arriving too late to play and are discarded, producing robotic audio. Consistency matters more than the average figure.
Is 1% packet loss bad for VoIP?
Around 1% is usually imperceptible because codecs conceal small gaps. Above roughly 3% becomes clearly audible. Burst loss is considerably worse than the same percentage spread evenly.
Why do calls sound fine internally but bad externally?
Internal calls may never leave your network, so they bypass the internet path entirely. Problems appearing only on external calls point at the connection, the firewall, or the carrier route.
Will upgrading my internet fix VoIP quality?
Usually not. Unless you genuinely lack capacity, upgrading addresses the wrong variable — jitter and packet loss are about packet timing and reliability, not throughput. Measure first, and configure QoS before spending money on a bigger circuit.
Salamtalk runs geo-redundant infrastructure with sub-15 ms core latency under a 99.9% uptime SLA. Size your connection with the free VoIP bandwidth calculator, or see the PBX migration guide for network preparation during a cutover.