The call broke up.
The link was 12% busy.
Voice and video are the least forgiving traffic on the network. They tolerate almost no jitter and no loss, and they are the first thing to break when something is subtly wrong.
Call quality is destroyed by jitter and packet loss, not by a shortage of bandwidth. A voice stream needs well under 100 kbps but needs its packets to arrive evenly. As rules of thumb, keep one-way latency under 150 ms, jitter under 30 ms and loss under 1%; beyond those, quality degrades quickly. This is why calls fail on links with plenty of headroom — a microburst, a queue that is not prioritising correctly, or a Wi-Fi roam breaks the timing without touching the capacity.
Five causes, none of them bandwidth.
Jitter — packets arriving unevenly
The jitter buffer at the far end absorbs a certain amount of variation and then gives up. Beyond that, packets arrive too late to be played and are discarded, which sounds exactly like loss to the listener.
Look for: inter-arrival variation on the stream itself. An average latency figure will not show it.
QoS configured but not applied
A marking set at the edge and cleared somewhere in the path — a trust boundary, a service provider handoff, a tunnel — means voice queues with everything else exactly when it matters.
Look for: the DSCP marking on the packets at each hop, not the QoS policy in the configuration.
A microburst on the path
A backup job or a replication window fills a buffer for 40 milliseconds. That is invisible to a utilisation graph, and it is several voice packets.
Look for: interface discards during the call window, and what else was transferring at that moment.
Wireless roaming
A client moving between access points loses a beat. If the roam is slow, or the client clings to a distant radio, the gap lands in the middle of a sentence.
Look for: whether the problem follows the person rather than the location. That points to the client and the radio, not the core.
The far side of the internet
With a hosted platform, half the path is not yours. That does not make it undiagnosable — it makes the evidence at your edge the thing that determines whose problem it is.
Look for: quality measured at your own boundary. Clean at the edge and poor at the far end is a supplier conversation, and a short one when you have a recording.
Four steps to the cause.
- 1
Measure jitter and loss on the stream, not the link
Link statistics average across all traffic. A voice stream has its own arrival pattern, and that is the only thing that predicts what the call sounded like.
- 2
Verify the marking survives the whole path
Check the DSCP value at each point rather than the policy in the configuration. Markings are cleared at trust boundaries far more often than anyone expects.
- 3
Line the bad call up against everything else
Take the exact timestamp of the complaint and look at what else was crossing that path. Scheduled transfers show up here with striking regularity.
- 4
Establish whether it is the path or the endpoint
Compare the same user on wired and wireless, and compare two users at different sites. Two comparisons usually eliminate most of the possibilities.
Quality collapsing on a quiet link.
Drag the timeline. Nothing about the link's utilisation explains what the user heard — which is the normal shape of a call-quality incident.
Net-Monitor has learned what this part of your network normally does at this time of day. Traffic is comfortable, the wire is clean, and nobody needs to be told anything.
- Link utilisation
- 39%
- Response time
- 24ms
- Sniffer packet errors
- 0.2%
- Risk score
- 2/100
Utilisation is comfortable and the wire is clean.
Why calls are hard to investigate afterwards
- Complaints arrive late. "This morning's call was terrible" is reported in the afternoon. Without a recording there is nothing left to examine.
- Quality is per-stream. Aggregate link statistics cannot reconstruct what one call experienced. The packets of that call can.
- It is often a supplier question. Evidence at your own boundary is what makes that conversation short.
Short answers.
What jitter is acceptable for VoIP?
Under about 30 ms is comfortable for most codecs and jitter buffers; between 30 and 50 ms quality becomes audibly variable; beyond that calls break up. These are rules of thumb — the buffer configuration at the endpoints shifts the exact numbers, and a codec with more aggressive concealment tolerates more before anyone notices.
What is MOS and can it be measured?
MOS is a 1-to-5 quality score originally produced by human listeners. Monitoring tools estimate it from latency, jitter, loss and the codec in use. It is useful as a single number to trend and to alert on, but the underlying measurements are what tell you the cause — a MOS score on its own says something was bad, not why.
Will more bandwidth improve call quality?
Usually not. Voice needs very little bandwidth and a great deal of consistency. Unless the link is genuinely saturated, the causes are timing-related — bursts, queueing, markings that were cleared, wireless roaming — and none of those are fixed by a bigger pipe.
Our calls are hosted. Is any of this still our problem?
The part of the path you own certainly is, and it is where most problems originate. Measuring quality at your own boundary tells you whether the degradation happened before or after that point, which is the only thing that makes the supplier conversation productive.
Calls that break up and nobody can say why?
We will look at the packets of a real bad call and show you where the timing went.