Test Your VoIP Line Quality
Measures round-trip latency and jitter from this browser to our edge, then estimates a Mean Opinion Score with the ITU-T E-model. Nothing is installed and nothing is uploaded.
Ready.
A browser cannot see packet loss, so this is yours to set. Leaving it at none is an assumption, and it is the assumption that makes the score its most flattering. If your softphone or PBX reports loss, put that figure here.
Estimated MOS
--
--
Median round trip
--
Jitter
--
Rating factor
--
What this VoIP tester measures
Pressing the button sends a short series of small requests to a file on this site and times each one. Two figures come out of that series. The first is the round trip: how long a request takes to reach our edge and come back. The second is jitter, the variation between consecutive round trips, computed with the smoothing filter defined in the RTP specification rather than as a plain standard deviation -- which matters, because the smoothed figure is the one your phone reports and sizes its buffer from.
The first few requests are thrown away before timing starts. A cold connection pays for name resolution and two handshakes, none of which recurs during a call, and timing that would blame your line for a cost it does not carry.
What it cannot measure, and why that matters
Packet loss. Web requests ride on TCP, which resends anything that goes missing without telling the page. A path dropping packets therefore looks slow here and never looks lossy. Voice rides on RTP, which does not resend -- a lost packet is simply a gap in the audio. Any browser tool that shows you a packet loss percentage from ordinary web requests is showing you a number it did not measure. This one asks you for it instead.
Your carrier's path. The result describes the route from this browser to our edge. That is a fair stand-in for a route to a hosted dialler in a similar place, and it is not your SIP trunk. Run it from the network your agents sit on, at the hour they work, and run it more than once.
Which direction is slow. One-way delay is taken as half the round trip. Real internet paths are asymmetric and the slow half may be the one that carries your agent's voice. It is the weakest assumption in the chain and it is printed beside the result rather than buried here.
How the MOS estimate is derived
Mean Opinion Score comes from listening tests, and nobody convenes a listening panel per call. The industry estimates it instead with the ITU-T E-model, which builds a transmission rating factor by subtracting impairments from a base score and then maps that rating onto the opinion scale. This tool charges the model for the measured delay, for a de-jitter buffer sized above the measured jitter, for a fixed codec allowance, and for whatever loss you set. It assumes the G.711 codec and that loss arrives independently rather than in bursts. Bursty loss is worse than independent loss at the same rate, so that assumption also errs towards a kinder score.
The arithmetic is not hidden. It lives in
src/lib/voip-mos.ts in the repository that builds this site, every
constant is named and explained, and its behaviour is pinned by tests written
against the published formula rather than against its own output.
If the result is poor
Work in this order, and re-run the test after each change so you know which one moved the number. Move the agent off Wi-Fi onto a cable. Give voice traffic priority on the switch and the router. Find out what else shares the uplink -- backups, screen recording and video meetings are the usual culprits in a call centre. Only then start suspecting the carrier, and when you do, bring readings taken at the hour the problem happens rather than at the hour you thought to look.
If the dialler itself is the suspect rather than the network, our free VICIdial audit looks at the configuration side, and the blog covers the settings that most often turn a healthy line into complaints about audio.
VoIP testing questions
Can a browser measure VoIP packet loss?
No, and any browser tool that prints a packet loss percentage from ordinary web requests is printing something it did not measure. Web requests travel over TCP, which quietly resends anything that goes missing, so a lossy path shows up as a slower reply and never as a loss figure. Real calls travel over RTP, which does not resend. That is why this tool measures round-trip time and its variation, and asks you to supply loss rather than inventing it.
What is a MOS score?
Mean Opinion Score is the average rating listeners give call audio in a controlled listening test, on a scale that runs from bad to excellent. Nobody runs a listening panel per call, so the industry estimates it from network conditions using the ITU-T E-model, which is what this tool does. The result is an estimate produced by a model, not a measured opinion.
Why does a perfect connection not score at the top of the scale?
The E-model starts from a base rating for a clean line and subtracts impairments. That base, mapped onto the opinion scale, sits below the top of it -- the codec itself costs something. A VoIP tool that reports a perfect score is reporting a bug in its own arithmetic.
What does this test actually connect to?
A small file on this website. The result describes the path from your browser to our edge, which is a reasonable stand-in for a path to a hosted dialler or SIP trunk in a similar location, and is not the same as a path to your own carrier. Run it from the network your agents actually sit on, not from your phone on a different connection.
My score is poor. What do I check first?
Wired before wireless, then quality of service, then the uplink. Wi-Fi is the single most common cause of jitter in a call centre; a switch with no voice priority is the second; an uplink shared with backups and video calls is the third. Fix them in that order, re-run this test after each change, and keep the readings.