VoIP Quality Testing: How to Get Real Numbers Instead of 'Calls Sound Bad'

"The calls sound bad." This is where most VoIP troubleshooting starts, and it is where too many investigations stall. The user thinks the calls sound bad. IT thinks the network is fine. The ISP thinks it is the VoIP provider. The provider thinks it is the ISP. Nobody has numbers. Everybody has opinions.

The way out is measurement. Not a speed test — a VoIP quality test that measures the specific metrics voice traffic depends on. With real numbers, you can diagnose the problem, prove where it is, and verify that your fix worked.

Why speed tests fail for VoIP

A speed test answers one question: how much data can your connection move per second? It does this by opening multiple TCP connections and pouring data through them as fast as possible. The result is a throughput number in megabits per second.

VoIP does not work like this. A single phone call sends roughly 50 small UDP packets per second, each carrying 20 milliseconds of audio. The total throughput is about 85 Kbps. The speed test's 500 Mbps result is irrelevant — you could make thousands of simultaneous calls with that bandwidth.

What matters is what happens to those 50 packets per second:

• Did they all arrive? (Packet loss)
• Did they arrive on time? (Latency)
• Did they arrive at consistent intervals? (Jitter)

Speed tests do not measure any of these. They use TCP (which retransmits lost packets) over a short burst (which may not capture intermittent quality issues). A connection can pass a speed test with flying colors and be terrible for VoIP.

For more on this gap, see 500 Mbps and Your Calls Still Sound Terrible.

The metrics that matter

Jitter

The variation in the time between consecutive packet arrivals. If VoIP packets should arrive every 20 ms but actually arrive at 15 ms, 28 ms, 12 ms, 35 ms intervals, that variation is jitter.

• Under 15 ms: Excellent. Calls will be crystal clear.
• 15-30 ms: Good. The jitter buffer on the phone can compensate.
• 30-50 ms: Marginal. You may hear occasional choppiness, especially during pauses.
• Over 50 ms: Poor. Calls will sound robotic, choppy, or have gaps.

Packet loss

The percentage of packets that never arrive. VoIP uses UDP, which does not retransmit. A lost packet is a lost packet — that 20 ms of audio is gone.

• Under 0.5%: Excellent. Not perceptible.
• 0.5-1%: Good. Barely noticeable on most calls.
• 1-3%: Marginal. Audible as occasional clicks, gaps, or brief dropouts.
• Over 3%: Poor. Calls are hard to follow. Significant audio gaps.

Latency (one-way delay)

The time for a packet to travel from sender to receiver. This determines conversational delay — how long after you finish a sentence before the other person hears it.

• Under 100 ms: Excellent. Conversation feels natural.
• 100-150 ms: Good. Slightly noticeable but acceptable.
• 150-200 ms: Marginal. You start talking over each other.
• Over 200 ms: Poor. Conversation is awkward. Long pauses and interruptions.

MOS (Mean Opinion Score)

A computed score that combines jitter, packet loss, and latency into a single number representing subjective call quality. The scale runs from 1 (unusable) to 5 (perfect). In practice, VoIP calls max out around 4.4 due to codec limitations.

• 4.0-4.4: Good to excellent.
• 3.5-4.0: Acceptable. Occasional quality issues.
• 3.0-3.5: Noticeable degradation. Callers will complain.
• Below 3.0: Poor. Calls are difficult.

For a deeper dive, see MOS Scores Explained: The Number Behind Call Quality.

The testing methodology

Running a VoIP quality test once tells you what conditions are like right now. Running it systematically tells you whether your network can support voice calls reliably.

Baseline test

Run the test with the network as idle as possible. This is your best-case scenario. If the baseline shows problems, the network has a fundamental issue — bad routing, a degraded circuit, or a misconfigured device.

Run our VoIP quality test from the location and device type that will be making calls. Use a wired Ethernet connection for the baseline to eliminate Wi-Fi jitter as a variable.

Loaded test

Run the test while the network is under typical load. This is the test that reveals real-world quality. Have your team working normally — email, cloud applications, video calls, file transfers. Better yet, run the test during the time of day when call quality is worst (often mid-afternoon — see Call Quality Is Fine in the Morning But Bad in the Afternoon).

Compare the loaded test to the baseline. If quality degrades significantly under load, the network needs QoS or the connection needs more headroom.

Comparative tests

Run tests from different locations and connection types to isolate the problem:

• Wired vs. Wi-Fi from the same location — isolates wireless issues
• Inside VPN vs. outside VPN — isolates VPN-related quality problems
• Different times of day — isolates time-dependent issues like ISP congestion
• Different locations on the same network — isolates per-site issues

Each comparison eliminates variables and narrows the problem. If wired and Wi-Fi both show high jitter, the problem is upstream. If only Wi-Fi shows high jitter, the wireless link is the issue. If morning is fine and afternoon is bad, it is a congestion problem.

Before-and-after tests

The most powerful use of VoIP quality testing is validating changes. Made a network change? Implemented QoS? Upgraded the internet connection? Disabled SIP ALG?

Run a test before the change and after. The numbers tell you whether the change had an impact, and how much. This is how you prove that the $2,000 firewall upgrade or the switch to a dedicated internet connection was worth it.

Using the results

Diagnosing the problem

| Symptom | Likely metric | Investigation | |---------|--------------|---------------| | Choppy or robotic audio | High jitter (>30 ms) | Check QoS, bufferbloat, Wi-Fi | | Brief audio dropouts | Packet loss (>1%) | Check network congestion, cable quality, ISP circuit | | Talking over each other | High latency (>150 ms) | Check routing, VPN overhead, geographic distance | | Calls fine internally, bad externally | All metrics degrade on external calls | Problem is WAN connection or ISP path | | Quality worse in afternoon | Metrics degrade at specific times | Bandwidth saturation, ISP congestion |

Presenting results to others

When you need to escalate to your ISP, provider, or management, the test results are your evidence. Include:

• The numbers. Jitter, packet loss, latency, MOS for each test.
• Timestamps. When each test was run. This lets the ISP correlate with their monitoring.
• Comparison. Loaded vs. unloaded, before vs. after, wired vs. wireless.
• The acceptable thresholds. Show what the numbers should be and how far off they are.

"Our VoIP quality test at 2:30 PM showed 45 ms jitter, 2.3% packet loss, and a MOS of 3.1. The same test at 7 AM showed 8 ms jitter, 0.1% packet loss, and MOS 4.3. The degradation coincides with peak business hours" is a fundamentally different conversation than "the calls sound bad in the afternoon."

Ongoing monitoring

VoIP quality is not a one-time check. Networks change, ISP conditions change, and new devices or applications can introduce problems at any time. Consider:

• Running a test from each major location weekly
• Testing after any network change
• Testing whenever users report quality issues (capture the data while the problem is happening)

For MSPs managing multiple client sites, see Monitoring VoIP Quality Proactively for a systematic approach.

Use the bandwidth calculator alongside your test results to verify that your connection can handle your call volume. If the math says you have plenty of bandwidth but the quality test shows degradation, the problem is not capacity — it is the quality of the connection or the network between the phones and the internet.

For the pre-deployment version of this methodology, see Testing VoIP Before You Deploy: A Pre-Flight Checklist. For understanding the metrics in detail, see Latency, Jitter, and Packet Loss: The Details.