Someone in your office is complaining that calls keep breaking up. You run a speed test. It comes back at 300 Mbps down, 100 up, and you reply — reasonably — that the internet is fine.
You are both right. The connection really is fast, and the calls really are bad. Those two facts sit together comfortably, because a voice call does not care how fast your line is. It cares about something else entirely, and almost nothing on a speed test measures it.
A speed test answers the wrong question
A speed test measures how much data you can move in bulk over a few seconds. That is the right question for a large file transfer or a software update, where the file arrives when it arrives and nobody notices a stumble along the way.
A phone call is the opposite kind of traffic. It sends a tiny packet of audio roughly every 20 milliseconds, and every one of them has a deadline. Arrive late and the packet is useless — the moment it was meant to fill has already been played. There is no buffering to hide behind. A call is not a download; it is a live performance, and it needs the network to be consistent far more than it needs the network to be fast.
So a line that averages 300 Mbps and briefly stalls every few seconds will pass a speed test and ruin a conversation.
The four numbers that actually decide call quality
These four are worth understanding properly, because each one fails in a way people describe differently.
Packet loss is audio that never arrived. At a fraction of a percent you will not notice. Past about 2% you get the symptom everyone describes the same way: words with the middles clipped out, and a strange underwater quality. The codec is guessing at the gaps, and it is guessing badly.
Jitter is the one people miss. The packets all arrive, but unevenly — one early, one late, one bunched behind another. The phone holds a small buffer to smooth this out, and when the variation outgrows the buffer, late packets get discarded. They are thrown away by your own handset, and they sound exactly like packets that were lost in transit. This is why a connection with zero measurable loss can still produce a broken call.
Latency is delay in one direction. Below 150 milliseconds a conversation feels normal. Above it, people begin talking over each other, apologising, and leaving long pauses to be sure the other person has finished. Nobody reports this as a technical fault. They report that calls are “awkward” or that a particular customer is “hard to talk to”.
Bandwidth is on the list mainly to be dismissed. A single call needs roughly 87 Kbps with overhead. Thirty simultaneous calls need about 2.6 Mbps — a rounding error on a modern business line. If you are reaching for a bandwidth upgrade to fix call quality, you are almost certainly fixing the wrong thing.
Where calls actually break
In practice, voice problems cluster in a handful of places. None of them appear on a speed test.
SIP ALG on the router or firewall
This is the first thing to check, every time. SIP ALG is a feature intended to help voice traffic across NAT by rewriting the signalling as it passes through. On a lot of consumer and small-business routers it is enabled by default and it does the job badly — mangling headers, breaking call setup, and causing one-way audio or calls that drop at a suspiciously consistent interval. Modern phone systems handle NAT perfectly well on their own. Turn SIP ALG off and a surprising number of “mystery” faults disappear with it.
A saturated uplink with no prioritisation
Voice needs very little bandwidth, but it needs that bandwidth now. If someone starts a large cloud backup, a video call, or a system image upload, the uplink fills and voice packets wait in a queue behind data that does not care about waiting. Without Quality of Service rules that tag and prioritise voice, the call loses that argument every time.
This is also why the fault so often seems random. It is not random — it is correlated with whatever else is happening on the network, which is why it clears up by the time anyone investigates.
Wi-Fi
Wi-Fi is a shared, contended, interference-prone medium, and it is the single most common source of jitter in an office. A desk phone or softphone on a congested access point, or one roaming between access points mid-call, will produce exactly the symptoms above. Wired connections for desk phones remain the cheapest quality improvement available.
Double NAT and aggressive session timers
Where a router sits behind another router — common when a new firewall is added without retiring the ISP box — signalling has two layers of translation to survive. Combine that with short NAT timeouts on the outer device and registrations expire silently between calls. The phones look fine on the desk. Inbound calls simply do not arrive.
The last mile and peering
Sometimes the problem genuinely is the carrier: microbursts of congestion in the local loop, or a poor route between your ISP and the voice provider. This is a real cause, but it should be the last conclusion rather than the first, and it needs evidence. “The ISP says everything is fine” and “we have no data” are not the same as having checked.
Measure it, rather than guessing at it
The reason these faults persist for months is almost always that nobody is measuring the right things, so every investigation starts from scratch and ends at “it seems okay now”.
Three things change that:
- Read what the phone system already knows. A properly configured 3CX deployment records per-call quality data — MOS scores, jitter and loss per leg. That tells you whether the problem is on the handset side, the trunk side, or one particular branch, which is most of the diagnosis.
- Probe continuously, not during the complaint. Intermittent faults need a monitor running all the time against the voice path, so that when someone says “calls were bad at about half past two” there is data for half past two.
- Correlate with the rest of the network. Uplink utilisation, backup windows and large transfers, lined up against the call quality timeline. The overlap is usually obvious once both graphs exist.
What good looks like
A healthy voice setup is unremarkable: SIP ALG disabled, voice traffic tagged and prioritised, desk phones wired, a single layer of NAT, and quality data being recorded whether or not anyone is currently complaining. None of that requires a faster line, and most of it is configuration rather than hardware.
The useful shift is to stop treating call quality as a bandwidth question. Once you are looking at loss, jitter and latency instead of megabits, these faults stop being mysterious — and start being fixable.
NIILAA designs, deploys and manages business phone systems as part of our managed IT services, including 3CX as a certified partner. If calls in your organisation are breaking up and nobody can say why, get in touch — we will measure it properly before recommending anything.