Free Call Quality Testing with voiptest.com

We are launching something we have wanted for years and could never find: an honest, free, browser-based way to prove whether a network can carry a phone call. It is live now at voiptest.com, it takes sixty seconds, and it does not ask you to create an account, install an app, or hand over a microphone permission.

This post explains what it measures, how it measures it, what it deliberately refuses to claim, and why a phone company decided to give the whole thing away.

The argument nobody can win

Every provider in this industry knows the call. A customer says the audio was choppy on Tuesday afternoon. You check the platform: no alarms, no registration failures, no carrier incidents. You ask about the network. The customer asks their internet provider. The internet provider runs a speed test, sees 400 Mbps down, and closes the ticket. Nobody is lying, nobody has evidence, and the customer is still on a bad call.

That standoff has a specific cause. Voice quality is decided by things that no ordinary consumer network test looks at, and the one test everybody reaches for was built to answer a completely different question. So the conversation ends up as three parties with three opinions and zero shared numbers.

We got tired of it. Not philosophically tired: operationally tired. We were spending real hours on disputes that a two-minute measurement should have settled.

Why a speed test cannot answer the question

A speed test measures bulk throughput. It opens several TCP connections, pushes as much data as it can, and reports the peak. That is a genuinely useful number if you are downloading a large file. It is close to irrelevant for voice.

A voice call is the opposite kind of traffic. It is a small, constant-rate stream of UDP packets, roughly fifty per second, each carrying about twenty milliseconds of audio. It never bursts. It never backs off. It uses a fraction of the bandwidth a video stream uses. What it cannot tolerate is timing: packets that arrive late, packets that arrive out of order, packets that arrive in clumps after a pause, packets that never arrive at all.

A connection can pass a speed test with a perfect score and still deliver unusable calls, because the impairments that ruin a call do not reduce throughput in any way a throughput test would notice. Conversely, a modest connection with clean timing carries voice beautifully. Bandwidth and call quality are related, but they are not the same measurement, and treating one as a proxy for the other is how these tickets stall.

The same goes for a ping. Round-trip latency to a random server tells you one number about one path at one instant. It says nothing about jitter under load, nothing about whether loss arrives in bursts or scattered singles, and nothing about what happens when four people on the same office uplink are all on calls at once.

What we built instead: a real voice stream, from the browser

The core idea behind voiptest.com is simple to state and was not simple to build: instead of approximating a call, put an actual voice stream on the connection and score what a listener would have heard.

When you start a test, the browser generates a reference audio signal internally and sends it as a real media track to our echo server. It goes out encoded by the browser's own Opus encoder, in real RTP packets over UDP, at twenty millisecond framing, at the same packet rate and roughly the same packet sizes as a live call. The server echoes it back and logs what it received. Alongside the audio, a lightweight secondary channel carries per-packet sequence numbers and timestamps, which is what makes it possible to track the fate of individual packets rather than reading a summary counter at the end.

Two consequences of that design are worth calling out.

The audio is synthetic, so nothing is captured. There is no microphone prompt, because there is no microphone. Nothing you say is recorded, transmitted, or stored, because the tool never listens. The signal is generated in software, which also makes it repeatable: every run starts from the same reference, so two runs are comparable.

The transport is real, so the numbers mean something. This matters more than it sounds. It would have been far easier to send data over a reliable channel and infer voice behaviour from it, but reliable transports have congestion control that quietly backs off exactly when the network gets interesting. It would then under-report loss precisely during the congestion a voice test exists to characterise. Real media traffic on the real path does not flatter the network, which is the entire point.

There is nothing to install, no browser extension, no client software, and no server for you to stand up. You open a page and press start.

The numbers, and what each one is actually telling you

A test that produced one green checkmark would be useless in a dispute. The report is built so that each figure can be defended on its own.

MOS, calculated the way the standard says

Mean Opinion Score is the industry's shorthand for "how good did that sound", on a scale of roughly 1 to 4.5. Ours is computed with the ITU-T G.107 E-model, the same standards-based calculation carriers and monitoring vendors use, rather than a house formula nobody can check. The report also breaks out the contributing factors, so you can see whether the score was pulled down by loss, by jitter, or by latency. A bare score tells you that you have a problem. The factor breakdown tells you which problem you have.

Three packet fates, not two

This is the distinction that changes how people read the results. Most tools sort packets into arrived and lost. In a voice call there is a third category that matters just as much: packets that arrived, but arrived after the moment they needed to be played. To the network they were delivered successfully. To the listener they were silence.

So the report separates network loss (what the network genuinely dropped) from effective loss (network loss plus the late arrivals, which is what the listener actually lost). Effective loss is the figure that feeds the quality score, because it is the one that describes the experience. Reporting only network loss is how a connection with severe jitter gets a clean bill of health.

Jitter, including the spikes

Jitter is the variation in packet arrival timing, reported as an RFC 3550 one-way figure. The mean matters, but the maximum matters more for diagnosis, because a single large spike is what empties a jitter buffer and produces the audible glitch a user complains about. An average smooths that spike into nothing. The report keeps both, and it keeps a per-packet timing record rather than only a smoothed running estimate, specifically so the transient stays visible.

Loss patterns, not just loss percentages

Two percent loss scattered evenly across a call is mildly annoying. Two percent loss arriving as one solid quarter-second gap is a dropped word and a "sorry, can you repeat that". The report classifies the loss pattern as random, bursty, or periodic, because those three shapes point at three different causes: general congestion, a saturated link or a duplex mismatch, and something running on a timer.

A buffer trade-off curve, not a single buffer number

Every phone and softphone holds incoming audio briefly before playing it, to absorb jitter. Make that buffer bigger and you lose fewer late packets but add delay to the conversation. Make it smaller and you get a snappier call with more dropouts. Rather than assert one right answer, the report replays your own measurement at several buffer depths and shows the curve, so you can see where your connection sits on that trade-off.

The raw data, and the methodology

Every run includes a raw data view with the full result set, an explanation of how each number was derived, and CSV and JSON downloads. If you are going to hand a result to a carrier, an internet provider, or a client, you should be able to hand over the workings too.

Four calls at once, not one call multiplied by four

A single test call passing is good news about a single test call. Most real complaints are about what happens when the office is busy, and "busy" is where connections fall over: an uplink that handles one stream cleanly can fall apart when four streams contend for it.

The free test runs up to four simultaneous calls, and they are genuinely simultaneous. Each one is its own connection, its own negotiation, and its own media stream, so four calls means four independent streams competing for your uplink the way four real phones would. It is a measurement of contention, not an extrapolation from one path multiplied by four.

The report shows the combined result and a per-call breakdown, because when three calls score well and the fourth collapses, that asymmetry is the finding. It is usually the moment a customer stops asking whether their internet is fast enough and starts asking how many calls it can actually carry at once. If you want to work out the theoretical answer for a given codec and call volume first, the bandwidth calculator covers that side.

What "free" actually means here

We want to be precise about this, because "free tier" usually means "the useful part is behind a wall".

• No account, no email address, no sign-in. Open the page, press start.
• One to four simultaneous calls, at your choice of sixty seconds, two minutes, or three minutes. The longer runs are free too, and they are the ones that catch intermittent problems a quick check walks straight past.
• The full report: quality score with factor breakdown, loss and lateness, jitter distribution, latency, loss pattern classification, the buffer curve, the per-call breakdown, and the raw data.
• CSV and JSON export of the run.
• A shareable report link that anyone can open without an account, which stays alive for thirty days and extends every time somebody views it.
• Sensible rate limiting so the shared echo capacity survives contact with the public internet.

Creating a free account adds saved test history, which is what you want if you are tracking a connection over weeks rather than settling one argument today. Paid plans are on the roadmap and are not built yet, so there is nothing to buy and nothing to cancel. When they do arrive, they will differentiate on measurement fidelity, on scale beyond the free ceiling, and on the things that surround a test such as history, trends, scheduling and export. The free test itself is intended to stay a real test.

What the test deliberately does not tell you

This section exists on purpose, and it is the part of the product we are most attached to.

The report will not tell you how many concurrent calls your connection can support. That number would be trivial to print and it would look authoritative, but the honest answer depends on what else shares the link, how the uplink is shaped, and what happens at the far end, none of which a browser can see. So the bandwidth figure describes the traffic this test itself generated, says exactly that, and stops there rather than dressing up a guess as a capacity verdict.

A few other boundaries worth stating plainly:

• It measures the path between your browser and our echo server, which is the path your calls take across your local network and your internet connection. It is not a measurement of your provider's internal platform or of a specific carrier route to a specific destination.
• It is not a speed test, and it should not be quoted as one.
• A background tab can corrupt a run. Browsers throttle work in tabs you are not looking at, which distorts timing measurement. When we detect that, the run is flagged and the report replaces the verdict with a warning rather than quietly reporting bad numbers as good ones.

The rule we hold ourselves to is straightforward: where a measurement cannot be made honestly, we leave the number out rather than print it with a caveat underneath. A diagnostic tool that overstates its reach is worse than no tool, because somebody will make a purchasing decision on it.

The rest of the toolkit

The quality test is the front door, but the platform is broader, because a real diagnosis is rarely one test. A quality test says whether the path is healthy. A packet capture says what the signalling actually did. A call flow says what the caller experienced.

Free, with an account:

• PCAP Analyzer: upload a capture from Wireshark, tcpdump or tshark. It extracts the RTP streams, maps the SIP dialogs, and computes per-stream quality scores, burst and gap loss, and codec detection, then flags the usual suspects such as one-way audio, codec mismatches and NAT traversal failures. Multiple captures can be compared side by side.
• SIP Call Stories: upload a capture, pick a call, and read what happened in plain English. Outcome and timing, the decisive SIP response code with troubleshooting steps, what the codec negotiation settled on, who hung up, the full message ladder, and per-endpoint registration health. It is computed directly from the packets, with no AI in the loop, so it says the same thing twice.
• Call Flow Designer: a drag-and-drop builder for auto-attendants, queues, ring groups and time conditions, with automatic extension allocation, generated plain-English narratives for every path through the tree, and print, Markdown and JSON export. Built for the conversation where a customer needs to approve a call flow before anybody configures it.

Open, no account at all:

• Carrier Lookup: carrier, line type, porting status and location for a number.
• SIP Response Codes: a searchable reference with plain-English explanations, troubleshooting steps and annotated example messages.
• Bandwidth Calculator: per-call and total bandwidth by codec, call volume and protocol overhead.
• MOS Score Explorer: an interactive sandbox showing how codec choice sets the quality ceiling and how loss, latency and jitter erode it.

There is also a reference library of more than 125 published articles covering call quality, SIP, codecs, network design and troubleshooting, plus a machine-readable navigation layer so AI assistants can find and cite the right page. If somebody asks an assistant why their calls are choppy, we would rather the answer came from a page that actually explains it.

How to use this in a real support conversation

The workflow we use ourselves, and the one we would suggest to any provider or MSP:

1. Run it from the machine that has the problem, on the network that has the problem, ideally at the time of day the problem happens. A test from a healthy office proves nothing about a struggling branch.
2. Run three minutes, not sixty seconds, when the complaint is intermittent. Short runs miss exactly the events people are complaining about.
3. Run it with four calls if the complaint is "it is fine in the morning and terrible at two o'clock". Contention shows up under contention.
4. Share the link, not a screenshot. The report link opens for anyone, includes the methodology and the raw data, and cannot be cropped to flatter whoever sent it.
5. Run it again after the fix. A before and after pair is the most persuasive artefact in this entire business, and it is the thing that turns "we think that helped" into a closed ticket.

If the quality test comes back clean and calls are still failing, the problem is usually signalling rather than transport, and that is where a packet capture and the call story tool take over. Our own guide to SIP trunking is a reasonable starting point for the vocabulary, and VoIP security covers the cases where the network is fine and something else is interfering.

Who we built it for

Three groups, with three different needs.

Businesses and IT generalists who need to know whether their connection is the problem, in language they can act on. You should not need to read an RFC to find out why your calls sound bad. The report leads with a verdict and a recommendation, and puts the standards underneath it for anyone who wants them.

VoIP providers who need something to send a customer instead of an argument. "Run this and send me the link" is a much better support reply than "our platform shows no issues", and it takes the conversation somewhere in a way that assertions do not.

MSPs and consultants who need defensible, client-deliverable evidence when a call-quality dispute has three parties and no data. Standards-based scoring, published methodology and exportable raw data are what make a result survive a meeting.

Why a phone company gives this away

The obvious question. voiptest.com is built and operated by Telnamix, and Telnamix sells hosted phone systems and SIP trunking. So why build a tool that can tell someone their network is fine and their provider is the problem, including when that provider is us?

Because that is the only version worth building. A diagnostic tool that quietly favours its owner is not a diagnostic tool, it is marketing with a progress bar, and everyone in this industry can smell it. The measurement uses published standards, the methodology ships with every report, and the raw data is exportable precisely so that the result does not depend on trusting us. If a test says the network is clean and the calls are still bad, we would rather that be visible than hidden, including on our own service.

The commercial logic is not complicated either. We spend less time on disputes when both sides can see the same numbers. Deployments go better when the network was tested before the phones arrived rather than after the complaints started. And a business that has been helped by a free tool is a reasonable business to talk to later. Test results are not influenced by any commercial relationship, and voiptest.com operates as an independent diagnostic platform.

There is also a simpler reason. We built it because we wanted it, could not buy it, and had the engineers to make it.

What is next

The roadmap we are working through, stated as work in progress rather than promises:

• Higher-fidelity measurement for signed-in users, using a per-packet transport path that removes some of the estimation the current path has to do.
• History and trends, so a connection can be watched over time instead of sampled once.
• Scheduled recurring tests, for the "prove it stayed fixed" problem.
• PDF export of reports, for the people who still live in attachments.
• Test servers in more locations, so the measured path is closer to the path a given customer's calls actually take.
• A continuous monitoring appliance, currently in alpha with hardware in the field. This one is genuinely early and we will talk about it properly when it is ready.

Try it

Go to voiptest.com and run a test. It costs nothing, asks for nothing, and takes a minute. If your calls have been bad and nobody can tell you why, you will have a shareable, standards-based answer before you finish your coffee.

If the answer turns out to be that your phone system, rather than your network, is the thing holding you back, talk to us. And if you want the background reading first, start with what VoIP actually is and work forward from there.