Reference
How to Read Your Results
Your test produced a score and five numbers underneath it. Here is what each one is telling you, and which one to act on first.
Start with the MOS score
The large number at the top of your report is the Mean Opinion Score — a prediction, on a scale of 1 to 5, of how a room full of listeners would have rated a call over the connection we just measured. It is the one number worth quoting to someone who does not care about packets.
We calculate it with the ITU-T G.107 E-model, which is the same method carriers use. No microphone, no listening panel: your measured loss, jitter, and delay go in, and a score comes out.
| Score | Rating | What it means |
|---|---|---|
| 4.0 - 4.5 | Excellent | Nobody notices anything. This is the target for business voice. |
| 3.6 - 4.0 | Good | Occasional minor artifacts. Most people never mention it. |
| 3.1 - 3.6 | Fair | Usable internally. Customer-facing calls will generate complaints. |
| 2.6 - 3.1 | Poor | Conversation takes effort. People will avoid using the phone. |
| below 2.6 | Bad | Not viable. Something is broken rather than merely degraded. |
Two things surprise people here. The first is that nobody gets a 5 — the codec alone costs you something before the network is involved, so 4.5 is the practical ceiling. The second is that the scale is not linear. The drop from 4.0 to 3.5 is far more audible than the drop from 4.5 to 4.0. Small movements in the middle of the scale represent large movements in how the call actually feels.
The five numbers underneath
MOS tells you that something is wrong. These tell you what. A score of 3.4 caused by latency is a completely different problem — different cause, different fix, different person to call — from a 3.4 caused by loss.
Packets that never arrived. The single most damaging metric per percentage point — 1% is already worth roughly 0.3 MOS.
Network loss plus packets that arrived too late to play. This is the figure the MOS calculation actually uses.
Variation in packet arrival time. The jitter buffer absorbs it by adding delay, so jitter costs you twice.
Round trip, not one-way. Halve it before comparing against the usual 150 ms one-way guidance.
The slowest 5% of round trips. A good mean with a bad P95 means something is intermittently stalling your traffic.
Green, amber, and red above are the same cut points the report itself uses to colour each figure.
Why there are two loss figures
This trips people up, and it is the most useful thing on the page.
Network loss counts packets that never arrived. Effective loss also counts packets that arrived, but arrived too late to be played — the jitter buffer had already moved on, so they were discarded. To the person on the call there is no difference whatsoever. A packet that shows up late is a packet that was not there.
So when your effective loss is much higher than your network loss, you do not have a packet loss problem, you have a jitter problem. The network delivered everything; it just delivered it unevenly. The fix is different: chasing lost packets on a link that is not dropping any will get you nowhere. Look at QoS and at what else is sharing the link instead.
Effective loss is the number that feeds the MOS calculation, which is why your score can look worse than a clean network-loss figure seems to justify.
Loss pattern: random, bursty, or periodic
The Details tab classifies how your loss arrived, and this matters more than the percentage. Codecs conceal a single missing packet well — Opus will interpolate over a 20 ms gap and you will never hear it. What no codec can conceal is a run of consecutive losses.
- Random — isolated losses scattered through the call. The least damaging pattern, and often just the internet being the internet.
- Bursty — losses arriving in clumps. This is what produces the audible dropouts people describe as words disappearing. 1% bursty loss sounds considerably worse than 1% random loss. Usually congestion, a saturated uplink, or a struggling wireless link.
- Periodic — losses at a regular interval. The most diagnostic pattern of the three, because networks do not naturally lose packets on a schedule. Look for something on a timer: a backup job, a scan, a flapping interface, a radio scanning channels.
The R-factor breakdown
If you want to see the arithmetic rather than trust it, the Details tab shows the E-model working. It starts from a base R-factor of 93.2 and subtracts two impairments:
- Delay impairment — the cost of the round trip, the jitter buffer, and the codec's own processing time. Below roughly 177 ms of one-way delay this grows gently; past that it accelerates sharply, which is the point where people start talking over each other.
- Equipment impairment — the cost of the codec plus packet loss, together. The two are combined because a codec's tolerance for loss is a property of the codec: Opus degrades gracefully, G.729 does not.
Whatever survives is your R-factor, and that converts to MOS. The practical use of this breakdown is that it names your culprit numerically. If delay impairment is 2 and equipment impairment is 18, stop investigating latency. The MOS Explorer lets you push the same inputs around by hand to see how much each one is worth.
If you ran more than one call
A multi-call test gives you a combined result plus a per-call breakdown, and the gap between the best and worst call is the interesting part. Those calls were genuinely concurrent — each one had its own connection and its own audio stream — so they were competing for the same link exactly as real calls would.
Calls clustered tightly together mean your connection handled the load evenly. A wide spread means it did not: something is being starved under contention, and the calls that lost that fight are what your fourth simultaneous caller will experience. If the single-call test passes and the four-call test does not, you have a capacity problem rather than a quality problem.
What to do with a bad result
Read the metrics in this order, and stop at the first one that is red:
- Effective loss — the biggest lever on the score by a wide margin.
- Jitter — especially if effective loss is well above network loss.
- Latency P95 — a clean mean with an ugly P95 is an intermittent problem, and intermittent problems are the ones users complain about while tests look fine.
- Mean latency — the hardest to change, since a lot of it is just distance.
Then run the test again. One test is a snapshot, and voice problems are usually about timing: run it when the office is busy, run it at the hour when people say calls sound bad. A perfect result at 6am proves very little.
Every report has a shareable link. If you are escalating to an ISP or a VoIP provider, send that rather than a description — it carries the measurements, the loss pattern, and the timestamp, which is considerably harder to wave away than “calls sound choppy.”
What this test does not cover
Worth being straight about: we measure the path between this browser and our echo server, using a real audio stream over the same transport your calls use. That covers your local network, your ISP, and the internet path — the part where most problems live. It does not cover your handsets, your PBX configuration, your SIP trunk, or the leg between your provider and whoever you called. A clean result here narrows the search considerably. It does not end it. When the network checks out and calls still sound wrong, the next step is usually a packet capture of an actual call.
Frequently asked questions
What is a good MOS score on a VoIP test?+
4.0 or above is excellent — callers notice nothing. 3.6 to 4.0 is good. 3.1 to 3.6 is fair and customer-facing calls will draw complaints. Below 3.1 the line is a problem you need to fix. Nobody scores 5.0: the codec itself costs you a few tenths before the network touches the call, so 4.5 is the practical ceiling.
How is the MOS score calculated?+
From the ITU-T G.107 E-model, not from a listening panel. Your measured packet loss, jitter, and round-trip time are converted into an R-factor between 0 and 100, which is then mapped onto the 1.0 to 4.5 MOS scale. The report shows the whole calculation in its Details tab — the base R-factor, what delay subtracted, and what loss subtracted.
Why is my MOS low when my internet speed test is fast?+
Because MOS does not measure bandwidth. A 1 Gbps connection that delivers packets in an uneven stream will score worse than a 20 Mbps connection that delivers them steadily. Voice needs about 85 kbps per call. What it actually needs is consistency, and a speed test never measures that.
What is the difference between network loss and effective loss?+
Network loss is the packets that never arrived. Effective loss adds the packets that arrived too late for the jitter buffer to use, which are discarded and sound identical to loss. Effective loss is the number that drives your MOS. When it is much higher than network loss, your problem is jitter, not loss.
Is the latency figure one-way or round-trip?+
Round-trip (RTT), because that is what can be measured honestly from a browser. Most VoIP guidance is written about one-way delay, so halve the figure before comparing: 150 ms one-way is the usual comfort threshold, which is roughly 300 ms RTT here.
My test scored well but calls still sound bad. What now?+
A passing test covers the path between this browser and our echo server at the moment you ran it. It does not cover your handsets, your PBX, your SIP trunk, or the leg beyond your provider. Run the test again during the hours when calls sound bad — problems that come and go are usually contention, and a test at 6am will not find them.