How to Tell If a VoIP Test Is Actually Testing VoIP

Search for a VoIP test and you will get a page of results that mostly measure the same thing. Download speed. Upload speed. A ping figure. Then a verdict: your connection is excellent for VoIP.

Run three of them and you may notice the numbers agree suspiciously well, and that all three finish before you have finished reading the page. That agreement is not corroboration. It is a family resemblance.

This is not really an accusation of dishonesty. The tools mostly do what they say — they test your connection speed, and they are frequently right that your connection is fast. The gap is between what they measure and what determines whether your calls sound bad, and that gap is where every unresolved call quality complaint lives. Why a throughput test cannot measure voice covers the mechanism in full. This post is the practical companion: how to look at any tool claiming to test VoIP and work out, in about a minute, whether it is doing so.

Nine tells

None of these require knowing anything about how a tool is built. They are all visible from the outside, while you use it.

1. The headline number is in megabits

A single voice call needs roughly 85 kbps. Not megabits — kilobits. Ten simultaneous calls fit inside 1 Mbps.

If a tool's primary output is "247 Mbps down, 23 Mbps up," it is answering a question that was settled for most businesses a decade ago. The number is not wrong. It is just not about voice. A connection three thousand times wider than a call requires can still deliver calls badly, and the megabit figure will never tell you that.

2. Everything else stalls while it runs

Watch what happens to the rest of your connection during the test. If a video call stutters, if a download pauses, if the office notices — the test is saturating your line. That is how throughput measurement works: fill the pipe, see how much fits.

A voice test has no reason to do this. Voice is a trickle. A tool that floods your connection to measure it is measuring capacity, and it is also, briefly, causing the exact congestion that ruins calls. Which brings its own irony: the conditions it creates are conditions it does not report on.

3. It is over in seconds

Voice quality problems are rarely constant. They arrive when the office fills up, when a backup kicks off, when a neighbour on the same segment starts streaming. The complaint is almost never "every call is bad" — it is "calls are bad in the afternoon."

A five-second sample cannot characterise a problem like that. It cannot even see it. Any tool that returns a verdict faster than you can read the page has looked at a slice of time far too thin to say anything about how your calls behave.

4. It tells you how many calls you can make, and it never placed one

"Your connection supports 230 simultaneous calls."

This is arithmetic: measured bandwidth divided by bandwidth per call. It is also one of the least reliable numbers in the category, because concurrency rarely fails for bandwidth reasons. It fails because a router's session table fills, because a firewall's inspection cost climbs with session count, because something in the path degrades as simultaneous streams multiply. A connection rated for 230 calls by division can start dropping audio at fifteen.

The distinction worth insisting on: did the tool place concurrent calls, or did it divide? Concurrent call capacity is a measurement, not a calculation, and the two answers can differ by an order of magnitude.

5. Packet loss is one number with no pattern

Suppose a tool reports 0.5% loss. That figure is compatible with two very different situations.

Scattered evenly, half a percent is close to inaudible — modern codecs conceal isolated gaps well. Arriving in clumps, the same half a percent takes out whole syllables, and no codec conceals a 100-millisecond hole. Same percentage, entirely different call.

A tool that reports a loss figure without telling you how the loss arrived has given you a number you cannot act on. Worse, it has given you a number that looks reassuring in the one case where it should not.

6. Jitter looks like it came from a ping

Some tools report jitter, which is a good sign until you consider what they measured it on. Variation between a handful of echo probes is not the same measurement as variation across a stream of small packets sent at voice cadence for minutes at a time.

The tell is usually resolution and stability. A jitter figure that barely moves between runs, or that arrives alongside a ping in the same breath, is likely derived from those probes. Jitter is about the consistency of a continuous flow, and you cannot characterise a flow you never sent.

7. No codec is ever mentioned

The same connection produces different call quality depending on the codec in use. One is intolerant of loss; another conceals it well; another trades bandwidth for resilience. This is not a detail — it can be the difference between complaints and silence on an unchanged network.

A tool that never mentions which codec its verdict applies to is telling you it does not model that, which means its verdict cannot be specific to your deployment.

8. The score has no standard behind it

Quality scores out of 100. Five stars. A letter grade. A green tick.

Ask what the number is derived from. Voice quality has a published standard — the ITU-T G.107 E-model, which turns loss, delay, and jitter into an R-factor and then a MOS score on a 1-to-5 scale. It is what carriers use, and its virtue is that it means the same thing to you, to your provider, and to your ISP.

A proprietary score means whatever its author decided. It may be perfectly sensible. It is also unfalsifiable, and it will not survive contact with a provider's support desk, which is usually the moment you need it most.

9. It says the same thing at 3am as it does at 3pm

This is the test of the tests, and it costs you nothing.

Run the tool when the office is empty. Run it again at the worst hour of the worst day. If the verdict does not move, one of two things is true: your connection genuinely does not vary, or the tool cannot see variation. The second is far more common, and a tool blind to variation is blind to the single most common shape of a real VoIP problem.

Why the label sticks

Worth being fair about why this is so widespread, because it is not a conspiracy.

Measuring throughput is easy. Fill the pipe, time it, divide. It works from any browser, finishes fast, needs no infrastructure beyond a big file and a server, and produces a satisfying number.

Measuring voice quality is not easy. It means sending traffic that behaves like voice rather than like a download, watching it for minutes rather than seconds, caring about the arrival time of individual packets rather than their total volume, and interpreting the result against a standard. It is more work, it takes longer, and the output is less immediately gratifying than a big number with an upward arrow.

So the label drifts to the easy thing. "VoIP test" is what people search for; a throughput test is what is cheap to build. Nobody has to be acting in bad faith for the result to be a category full of tools that cannot answer the question being asked of them.

What to demand instead

Judge any voice test on what it hands you, not on how it describes itself:

• A score with a published standard behind it. G.107, stated plainly. If a tool will not tell you what its score is derived from, treat the score as decoration.
• Loss pattern, not just a loss percentage. Random, bursty, or periodic. The pattern is the part that points at a cause.
• A sustained run. Minutes, not seconds, so intermittent problems have a chance to appear.
• Real concurrency, if it claims concurrency at all. Calls placed, not bandwidth divided.
• Something you can send to someone else. A shareable, timestamped result is materially harder for a provider to dismiss than "calls sound choppy."
• Honesty about what it cannot see. Any browser-based test measures a path. A tool that implies it has inspected your handsets, your PBX, and your carrier's network is overselling, and the overselling tells you something about the rest of its claims.

Where ours stands

Ours is free, needs no account, asks for no microphone, and runs in a browser tab.

It places between one and four genuinely concurrent calls — separate calls running at the same time, competing for your connection the way real calls do, not one call's numbers multiplied. You choose 60 seconds, 2 minutes, or 3 minutes, so you can watch a connection for long enough to catch it misbehaving. It scores with the ITU-T G.107 E-model, the same standard a carrier would use, and shows the working rather than just the verdict. It classifies your loss as random, bursty, or periodic. On multi-call runs it breaks out each call individually, so you can see whether your connection degrades under load or holds steady. Every result gets a shareable link you can drop into a support ticket, and a guide to reading the numbers so the report is useful to someone who does not do this for a living.

How it does that is not something we are going to write up, and you should be mildly suspicious of any tool in this category that does — method is the only durable difference between a real voice test and a throughput test with a voice label on it.

What we will do is be straight about the limits. Our test measures the path between your browser and our servers. That covers your local network, your equipment, your ISP, and the internet leg — which is where the large majority of call quality problems actually live. It does not cover your handsets, your PBX configuration, your SIP trunk, or the leg between your provider and the person you called. A clean result narrows the search considerably. It does not end it, and we would rather say so than let you find out later.

The one-minute version

Open whatever tool you are evaluating and ask three questions.

Is the biggest number on the screen measured in megabits? Did it finish before you could read the page? And if you run it again tonight, will it say anything different?

Three yeses means you have a speed test. It may be a very good speed test. It is not going to tell you why your calls sound bad.

For the underlying reasons a throughput measurement cannot capture voice quality, see Why a Speed Test Can't Tell You If VoIP Will Work. For using test results methodically rather than one-off, see the VoIP quality testing methodology guide.