Why a Speed Test Can't Tell You If VoIP Will Work

Search "VoIP test" online and most of what you find are speed tests with a VoIP label on them. They measure your download speed, your upload speed, maybe your ping, and then tell you whether your connection is "good for VoIP." Some of them even brand themselves specifically as a "VoIP Speed Test."

They are not wrong that bandwidth matters. If you have a 256 kbps DSL line trying to carry ten simultaneous calls, you have a bandwidth problem. But that scenario is increasingly rare. Most businesses have enough raw bandwidth for voice. The problems that actually cause bad call quality live in places that speed tests do not measure and, because of how they work, cannot measure.

This is not a minor gap. Speed tests and VoIP quality measurement are fundamentally different exercises. Understanding why is the first step toward actually diagnosing call quality problems instead of chasing bandwidth numbers that were never the issue.

Speed tests use the wrong protocol

This is the most fundamental problem, and everything else flows from it.

Speed tests use TCP. VoIP uses UDP (specifically, RTP running over UDP). These two protocols behave so differently under stress that measuring one tells you almost nothing about the other.

TCP is designed for reliability. When a packet gets lost, TCP detects it and retransmits. When the network gets congested, TCP backs off its send rate to avoid making things worse. These are excellent features for loading web pages and downloading files. They are also the reason TCP cannot measure what VoIP experiences.

When a speed test runs over TCP and encounters packet loss, it retransmits the lost packets and slows down. The test completes successfully, maybe with a slightly lower throughput number. No packets are actually lost from the test's perspective because they all eventually arrive.

When a VoIP call runs over UDP and encounters packet loss, those packets are gone. There is no retransmission. The audio that was in those packets is simply missing. The listener hears a gap, a click, or a robotic artifact. The call keeps going at the same pace regardless because voice is real-time. It cannot pause and wait for a retransmit.

A connection can lose 3% of its UDP packets and a speed test will barely notice. That same 3% loss will make phone calls sound noticeably broken.

Throughput is the wrong metric

Speed tests answer the question: how much data can this connection move per second? That is a useful number for many things. It is not useful for voice.

A single VoIP call using the G.711 codec requires about 87 kbps in each direction. Using Opus, it is even less: 24 to 48 kbps depending on configuration. Ten simultaneous G.711 calls need less than 1 Mbps of bandwidth. Most business connections today deliver 50 to 500 Mbps or more.

The bandwidth question was answered years ago for most offices. The connection is big enough. What matters now is the quality of the delivery: are those small, frequent voice packets arriving consistently, on time, and intact?

A speed test that reports 200 Mbps download and 20 Mbps upload tells you the pipe is wide enough. It says nothing about whether the packets flowing through it arrive with the timing precision that voice requires.

Jitter is invisible to speed tests

Jitter is the variation in packet arrival times. VoIP sends a packet roughly every 20 milliseconds. If those packets arrive at 18ms, 22ms, 19ms, 21ms intervals, the jitter is low and audio sounds clean. If they arrive at 8ms, 45ms, 12ms, 60ms intervals, the jitter is high and audio sounds choppy or robotic.

Speed tests do not measure jitter because they do not need to. TCP traffic is reassembled in order regardless of when individual packets arrive. A web page loads the same whether its packets arrive with 2ms of jitter or 200ms of jitter. The browser waits for everything and renders the result.

Voice cannot wait. It plays back in real time. A phone's jitter buffer collects incoming packets and tries to smooth out the variation, but it can only absorb so much. When a packet arrives outside the buffer window, it is functionally lost. High jitter creates packet loss even when every packet technically arrives at its destination.

A connection with 200 Mbps throughput and 40ms of jitter will pass every speed test while making every phone call sound terrible.

Packet loss patterns matter, not just percentages

Even tests that report a packet loss number usually report it as a single percentage: "0.5% packet loss." That number alone does not tell you much about voice quality because the pattern of loss matters enormously.

Half a percent of random, evenly distributed loss is manageable. Modern codecs and packet loss concealment algorithms can mask the occasional missing packet well enough that most listeners will not notice.

Half a percent of loss concentrated in bursts is a different story. Five consecutive lost packets at 20ms each creates a 100-millisecond hole in the conversation. That is an entire syllable gone. The listener hears a hard cut in the audio, and no amount of concealment can fill a gap that large convincingly.

Speed tests have no concept of loss patterns because TCP retransmits everything. And even network monitoring tools that do measure UDP loss rarely distinguish between random and burst loss. VoIP quality depends on knowing the difference.

Buffer bloat turns good bandwidth into bad calls

Buffer bloat is a specific failure mode where routers and modems have oversized packet buffers. When the connection gets busy, instead of dropping excess packets (which TCP would detect and respond to by slowing down), the equipment queues them in a large buffer. The packets eventually get through, but they wait in line for tens or hundreds of milliseconds first.

The result is that throughput looks fine but latency spikes dramatically under load. A connection that pings at 15ms when idle might jump to 300ms or more when someone starts a large download.

Here is the irony: speed tests actively trigger buffer bloat during measurement. They saturate the connection to measure maximum throughput. The buffer fills up. The speed test reports the throughput number as a success. Meanwhile, the latency spike that occurred during that saturation is exactly what would destroy a phone call happening at the same time.

A speed test cannot warn you about buffer bloat because the speed test is the thing causing it, and the speed test only reports the metric that buffer bloat does not affect.

Latency under load vs. idle latency

Most speed tests report a "ping" or latency number. This is typically measured either before the throughput test starts (idle latency) or during it (loaded latency). Neither tells the full story for VoIP.

Idle latency tells you the best case. It is useful as a baseline, but calls do not happen in isolation. While someone is on a call, other people in the office are browsing the web, pulling files from cloud storage, uploading to SaaS apps, and generating all the other traffic that a modern office produces.

Loaded latency during a speed test tells you the worst case under full saturation, which is also not realistic. Nobody sustains 100% link utilization during normal work.

What matters for VoIP is latency during typical mixed use. A connection that shows 12ms idle and 180ms loaded might sit at 35ms during a normal workday, which is fine for voice. Or it might spike to 120ms every time someone opens a large email attachment, which is not. Speed tests do not model this middle ground.

QoS hides the real picture

Some business networks have Quality of Service policies that prioritize voice traffic on the local network. When QoS is active, voice packets skip ahead of file transfers and backups at the router's outbound queue. A speed test does not benefit from this prioritization, so it measures the unprioritized path. On a QoS-enabled network, the speed test might report worse conditions than voice actually experiences locally.

But this distinction matters less than the QoS conversation usually implies. QoS only operates on equipment you control -- your switches and your router. Once packets leave your network and enter your ISP's infrastructure, DSCP markings are almost universally stripped or ignored. Consumer and most business internet connections do not honor them. Your ISP has no reason to give your traffic priority over anyone else's unless you are paying for a dedicated SLA that specifically includes it.

This means QoS protects voice from congestion on your own LAN, but it does nothing for the internet leg of the call, which is where most VoIP quality problems actually originate. And on the LAN side, if you need QoS to keep calls clean, that is a signal that your network is congested -- QoS is treating the symptom, not the cause. For most small and medium businesses, a properly sized router and adequate bandwidth do more for call quality than QoS policy tuning ever will.

No codec context

A speed test cannot tell you how different VoIP codecs will perform on your connection because codec selection changes which network characteristics matter most.

G.711 uses uncompressed audio at a fixed 64 kbps bitrate. It produces excellent audio quality on clean connections but has no built-in resilience to packet loss. Every lost packet is a hard gap in the audio.

Opus is a modern codec that operates at variable bitrates and includes forward error correction. It can recover from moderate packet loss far better than G.711. On a connection with 1% random loss, Opus with FEC enabled might sound nearly perfect while G.711 sounds noticeably degraded.

The practical implication is that the same connection can produce very different call quality depending on which codec is in use. A VoIP-specific test can compare codec performance under your actual network conditions and show you that switching from G.711 to Opus (or vice versa) would change your experience. A speed test has no framework for this kind of analysis.

Directional asymmetry

Speed tests do measure upload and download separately, which is good. But they measure throughput in each direction, not quality.

Jitter and loss can be completely different on the upstream versus downstream path. Your router's upload queue might be congested while your download path is clean, or your ISP might have an asymmetric issue on their network that affects one direction more than the other.

In a phone call, this means you might sound fine to the other person while they sound terrible to you, or the reverse. "One-way bad audio" is a specific and common VoIP complaint that requires per-direction quality measurement to diagnose. Knowing that your upload speed is 20 Mbps and your download is 200 Mbps tells you nothing about which direction has the jitter problem.

Concurrent call capacity is not a bandwidth calculation

Some speed test results pages include a "VoIP calls supported" estimate. They take your measured bandwidth, divide by the bandwidth per call (usually assuming G.711 at ~87 kbps), and give you a number. "Your connection supports 230 simultaneous VoIP calls."

This calculation is technically correct and practically useless. Bandwidth per call is a necessary condition, not a sufficient one. The actual limit on concurrent calls is determined by how the network handles the aggregate packet flow: does jitter increase as more calls are added? Does the router's NAT table handle hundreds of concurrent UDP sessions cleanly? Does the firewall's packet inspection add latency as session count grows?

A connection with 20 Mbps upload bandwidth could theoretically carry 230 G.711 calls. In practice, the router might start dropping packets at 15 concurrent calls because its CPU cannot keep up with the NAT translations. The speed test's bandwidth-based estimate is off by an order of magnitude.

What does a real VoIP test measure?

The gaps above are not academic. They describe the specific reasons that businesses with plenty of bandwidth still have terrible call quality, and why running a speed test to diagnose the problem leads nowhere.

A test designed for voice needs to:

• Send UDP traffic matching VoIP patterns. Small packets at regular intervals, not bulk TCP transfers. This measures the actual transport path that voice uses.
• Measure jitter per packet, not averages. Per-packet timing reveals spikes and patterns that averages conceal.
• Track packet loss patterns. Random loss versus burst loss versus periodic loss. Each has different causes and different impacts on audio quality.
• Test under realistic conditions. Not idle, not saturated, but representative of actual use.
• Measure each direction independently. Upstream and downstream quality are separate problems with separate causes.
• Calculate standards-based quality scores. MOS scores derived from ITU-T G.107, not proprietary formulas. Defensible, reproducible, industry-standard.

That is the kind of test we built. Our VoIP quality test is not a speed test with a label. It is a diagnostic engine built around how voice traffic actually behaves. For how to use those measurements methodically — baseline tests, loaded tests, comparative tests, and before-and-after validation — see our VoIP quality testing methodology guide.

Wondering what jitter, packet loss, and latency actually do to your calls? Start with What Is Jitter and Why Does It Wreck Your Calls? or read the full VoIP From the Ground Up series for the complete picture.