Latency
Round-trip delay. Above about 300 ms round trip, people start talking over each other because the gap exceeds what conversation tolerates.
Measures latency, jitter and loss, then estimates what a call would sound like. Uses the same measurement nodes as the speed test and takes about a minute.
A mean opinion score is properly what a panel of listeners said about recorded speech. Nothing in a browser can produce one. What the ITU-T E-model does is estimate what that panel would have said from the network conditions — so the figure here is labelled an estimate, its three inputs sit next to it, and the limits of each are stated.
Round-trip delay. Above about 300 ms round trip, people start talking over each other because the gap exceeds what conversation tolerates.
Variation in arrival time. The receiver must buffer roughly twice the jitter to play audio smoothly, and that wait counts against the caller exactly as delay does.
Missing packets. Concealment hides a single gap well and six in a row badly, so bursty loss sounds far worse than the same percentage spread out.
The figure that matters in an office: what happens to all three when somebody starts a large upload.
It is not bandwidth. A G.711 call needs about 87 kbps in each direction including headers, so even a modest connection has room for a dozen. Businesses with gigabit links have terrible calls, and the reason is almost never capacity.
It is latency under load. When a link fills, packets queue, and on consumer equipment that queue can be hundreds of milliseconds deep. Voice packets sit in it behind a file upload. The call does not drop — it degrades into people talking over each other, exactly while someone in the office is sending something large. That is why this test measures latency during a transfer as well as when idle, and shows both estimates.
The fix for that is traffic shaping — giving voice priority, or simply running the link at ninety percent of its capacity so the queue never builds. It is a configuration change on the router, not a bigger connection, and buying more bandwidth frequently makes no difference at all.
On the loss figure specifically: a browser cannot watch a media stream, so what this counts is HTTP probes that failed to come back in time. That catches a connection dropping traffic, and it is not the same as RTP loss on a call — a probe can be late rather than lost, and short bursts between probes are invisible. Treat a zero as “nothing obvious” rather than proof, and treat anything above one percent as worth investigating properly.
Above 4.0 is good and above 4.3 is as good as the codec allows. Below 3.6 people will notice; below 3.1 the line is not usable for business calls. Note the scale tops out at 4.5 in this model, not 5 — any tool showing you 5.0 is not using the model it claims to.
Almost certainly latency under load. When the link fills, packets queue, and voice waits behind whatever else is being sent. This test measures latency during a transfer as well as idle for exactly that reason — if the idle estimate is good and the loaded one is poor, the answer is traffic shaping on the router, not a bigger connection.
The test calculates it from the measured bandwidth and your chosen codec, holding back a fifth as reserve. Treat it as a ceiling rather than a promise: it assumes the line is otherwise idle, and a connection that can carry ten calls arithmetically will still ruin all ten if its latency rises under load.
Not in the sense a call experiences. A browser cannot observe a media stream, so this counts HTTP probes that did not return within their timeout — which detects a connection dropping traffic but is not RTP loss. It is also assumed to be non-bursty, which is the optimistic assumption; bursty loss sounds considerably worse.
No. It tests your connection to our measurement nodes, which is a reasonable proxy for a general internet path and is not the path to your provider. For that, the SIP connectivity test checks what your provider's domain publishes and whether its servers answer.