Most Free VoIP Tests Don't Test VoIP

Search for "VoIP test" and run the top results. Watch what actually happens during each one — the network tab in your browser's developer tools is enough. In most cases you will find that no voice-shaped traffic ever flows. The page is a marketing asset wrapped around a much simpler measurement: a speed test, a loop of timed web requests, or a port reachability check, presented with a score and a call to action.

That's not an accusation of bad faith. Most of these tools are honest about their mechanics if you read carefully — the caveats are in the fine print, the "advisory" labels are there. But the category as a whole has trained people to believe they've tested their voice quality when what they've tested is something else. This post is a field guide: what's actually behind the tests you'll find, why the differences matter, and the questions that reveal which kind you're looking at.

The four things sold as a VoIP test

The rebadged speed test. Download streams, upload streams, a ping, and a verdict like "your connection is VoIP ready." Throughput is the one metric voice barely needs — a G.711 call uses roughly 87 Kbps per direction, so a connection with 500 Mbps of headroom can still sound terrible if its timing is inconsistent. A speed test measures how much data moves. Voice quality depends on how consistently small packets arrive, which bulk TCP transfers cannot tell you.

The HTTP timer. This one looks more like a diagnostic: it reports latency, jitter, sometimes packet loss. But the traffic behind the numbers is a loop of web requests. "Latency" is the round trip of an HTTP exchange, including server processing and browser overhead. "Jitter" is the variance of that loop — and application-path variance routinely measures tens to hundreds of milliseconds on a network whose actual packet-level jitter is under five. "Packet loss" is the giveaway: check the sample count. A test that reports loss across ten or twenty probes can only detect a catastrophically broken network. One percent loss — the level that's already audible on a call — is statistically invisible in a ten-sample window. You need thousands of packets in the denominator before a loss percentage means anything, which is what a real media stream provides and a probe loop does not.

The reachability check. The most sophisticated of the three: it gathers connectivity candidates, probes UDP paths, sometimes attempts relay allocations against SIP-style and RTP-style ports, and reports firewall readiness or a SIP ALG signal. To be clear, this is genuinely useful — a blocked UDP path or a misbehaving SIP ALG will absolutely break a deployment, and knowing before install day beats discovering it after. But a reachability check is a firewall test, not a quality test. It answers "can packets get through?" and says nothing about what happens to them on the way: no jitter under sustained load, no loss rate, no timing distribution. And the SIP ALG part deserves particular skepticism, which gets its own section below.

The real media-path test. The rare kind: the test establishes an actual media session and sends a continuous stream with voice codec encoding, real packet sizing, and real pacing — the same traffic shape as a phone call — then measures every packet. Jitter means the interarrival variation of paced voice packets. Loss has thousands of packets in the denominator. Latency is the round trip of the media path itself. This is the only category whose numbers describe what a call will experience, because it's the only category that sends what a call sends.

Why browser SIP ALG "detection" is inference, not detection

SIP ALG is a firewall feature that rewrites SIP signaling as it crosses NAT, and it breaks things constantly — registration loops, one-way audio, dropped calls. A test that could reliably flag it would be valuable. The problem is what a browser is physically able to observe.

Detecting an ALG means catching it rewriting packets: send SIP-shaped payloads through the firewall, compare what arrives against what was sent, and diff the mangled headers. A browser cannot do this. It has no raw UDP sockets, so it cannot emit actual SIP traffic on port 5060. The media streams it can send are encrypted end to end, so an ALG can neither read nor rewrite them — which also means the test can't observe interference that isn't there to observe. What's left is indirect evidence: UDP toward a SIP-style port fails while other UDP paths succeed, which is consistent with an ALG or a port-specific firewall rule, and equally consistent with several other things.

So when a browser test reports a SIP ALG result, it is reporting an inference from port reachability, whatever the label says. The honest phrasing is "the SIP port looks filtered — verify with a handset," and some tools do hedge exactly that way once you read past the headline. A definitive answer requires a device that actually speaks SIP on the network in question: a handset or softphone, registered against the real service.

Five questions that reveal what a test measures

1. What traffic flows? Open the developer tools and watch. Bulk transfers mean a speed test. A burst of small web requests means an HTTP timer. A short flurry of connectivity checks and nothing else means a reachability check. A sustained stream of small, evenly spaced packets for the duration of the test means voice-shaped media actually flowed.

2. What's the loss denominator? If the report says loss was measured "across N samples," N tells you everything. Ten samples can detect an outage. Detecting the 0.5-1% loss that degrades real calls takes thousands of packets.

3. What does "jitter" mean here? Ask whether the number is the variance of timed requests or the interarrival variation of paced media packets. The two can differ by an order of magnitude on the same network, and the estimator behind the number changes what it can see.

4. Is the score a standard or an invention? A MOS computed with the ITU-T G.107 E-model is a published, criticizable method — you can explore exactly how each impairment moves it. A proprietary "readiness score" is a number whose meaning lives in marketing copy. Invented scores usually exist because the underlying data couldn't support a standard one.

5. What do you pay, and when? A test that gates the run behind an email address is telling you what it's for. That's a lead-capture form with a diagnostic attached. There are legitimate reasons a business collects emails — but "before any measurement begins" is a choice, and it's not a measurement choice.

Where our test stands, including its limits

Our free test is in the fourth category: it establishes real media sessions and streams codec-encoded audio with real packet sizing and pacing — up to four genuinely concurrent simulated calls, so multi-call runs measure actual contention rather than extrapolating from one. Every packet is timed, loss is counted against the full stream, and the result is a MOS computed with the ITU-T G.107 E-model alongside the packet-level metrics it derives from. No email address, no account, and the report is a link you can share.

The limits are worth stating just as plainly, because the argument of this post cuts both ways. A browser test measures the path between your device and our servers — a real path carrying real voice-shaped traffic, but not literally your provider's path, and results reflect the device and network you run it from. It is not a speed test and won't tell you your line rate. And nothing running in a browser can conclusively detect SIP ALG, ours included — that verdict belongs to a handset. A test that's honest about the boundary between what it measured and what it inferred is the whole point; it's the standard we're holding the category to, so it's the standard we hold ourselves to.

The next time a page offers to test your VoIP in sixty seconds, take it up on the offer — with the network tab open. What flows during those sixty seconds is what got tested. Make sure it looks like a phone call.