Call quality test
Published
Find out whether your current connection is steady enough for a call. Press the button and the page sends 30 tiny requests to this site, times each answer in your browser and judges the result for voice, video and screen sharing. It does not test bandwidth.
- Round trip (median)
- —
- Fastest – slowest
- —
- Jitter
- —
- Missed replies
- —
Is it good enough for…
The test starts only when you press the button. It sends 30 tiny requests to this site's server and times the answers in your browser. The ChatLite application stores neither the results nor your address and writes no log line about these requests, and the web server's access log is switched off for this one address. Nothing else is sent.
What the test measures
The page sends 30 very small requests to this site, one after another with a short pause, and measures in your browser how long each answer takes. A first request opens the connection and is not counted. From the 30 timings it works out three numbers.
- Round-trip time (RTT): how long a message takes to go to the server and come back. The page shows the median, the fastest and the slowest. Low is better.
- Jitter: how much the round-trip time changes from one request to the next, averaged. A connection can be fast on average and still jumpy, and jumpy connections make voice stutter.
- Missed replies: how many requests got no answer within one and a half seconds. This is the closest honest figure to packet loss that a web page can measure.
How the verdicts are decided
Each use has three limits for each number. Staying within the first limit is judged good, staying within the second is usable with limits, and anything above is likely poor. The worst of the three numbers decides the verdict, and the verdict names which numbers held it back. These values are general rules of thumb that are widely used for interactive audio and video, not figures from a standard that this page can quote, so treat the verdicts as a guide, not a guarantee.
- Voice calls: round trip up to 150 ms is good and up to 300 ms usable; jitter up to 30 ms good and 50 ms usable; missed replies up to 1 percent good and 3 percent usable.
- Video calls: round trip up to 150 ms good and 250 ms usable; jitter up to 20 ms good and 40 ms usable; missed replies up to 1 percent good and 2 percent usable. Video is stricter because a frozen or blocky picture is more noticeable.
- Screen sharing: round trip up to 250 ms good and 400 ms usable; jitter up to 40 ms good and 80 ms usable; missed replies up to 2 percent good and 5 percent usable. A shared screen changes slowly and tolerates delay better than a conversation does.
What the test cannot tell you
- It measures the path between you and this site's server, not the path to the person you will call. A call between two people can take a shorter or a longer route.
- It does not measure bandwidth, that is, how many megabits per second you can move. Bandwidth tests send large amounts of data and would put a load on this server, so none is offered. A connection can have low delay and still be too slow for high-definition video.
- Requests travel over TCP, which resends lost packets. Real packet loss therefore appears here as extra delay or as a missed reply, not as a loss figure of its own. Calls use a different transport that does not wait for resends, so they can behave worse than this test suggests on a very lossy network.
- Ten seconds is a snapshot. Wi-Fi, other people on the network and the time of day change the picture, so run the test more than once.
How to read the numbers and improve them
High round-trip time
Distance and routing add delay that you cannot remove, but a VPN, a proxy, a congested Wi-Fi channel or a busy mobile network add much more. Try a cable instead of Wi-Fi, move closer to the router, or switch networks.
High jitter
Jitter usually comes from sharing the connection. A download, a cloud backup or a video stream in the same home makes the delay swing. Pause them and run the test again. Wi-Fi interference from neighbours causes the same effect.
Missed replies
More than one or two missed replies means the connection drops traffic. Check signal strength, restart the router, and try a different network. If every request is missed, the connection may be down or a firewall may block this site.
Good numbers but a bad call
The problem may be the other person's network, the calling service, or your camera. Use the WebRTC connectivity test to see whether direct connections are likely, and the camera and microphone test for devices.
Browser support
The test needs only the fetch feature and a high-resolution timer, which every current browser has, on computers and phones. Timings in browsers can be rounded for privacy, so very small differences are not meaningful. This statement comes from documentation, not from tests on every device.
Privacy: what the server sees
When you press the button your browser sends 30 plain requests to this site, with no cookies and no data about you in them. The ChatLite application answers with a constant tiny reply. It does not store the requests or your result, and it writes no log line for them. In ChatLite's web server configuration the access log is switched off for this one address, so the web server does not record these requests either. (Any web server or network between you and this site can in principle keep its own records; this page can only describe how ChatLite itself is set up.) To protect itself from abuse the application counts requests per network address in memory for one minute and refuses more than it allows; that counter is never written to disk. The results are calculated and shown only in your browser. If you press Copy summary, the text contains the numbers but no address.
Frequently asked questions
Does this test my internet speed?
No. It measures delay, jitter and missed replies, which matter for calls. It deliberately does not measure bandwidth, because that would load the server.
Is anything stored about my test?
No. The ChatLite application stores neither the results nor your address and writes no log about the test, and the web server's access log is switched off for the test's address. It only counts requests per address in memory for a minute to prevent abuse.
Why are the limits not from a standard?
They are common rules of thumb for interactive audio and video. The page says so instead of presenting them as official figures.
Why does the test say usable but my calls are fine?
The verdict is cautious. Many calling services adapt to delay and cope with more than a rule of thumb suggests.
Why can I only run it a few times a minute?
To stop abuse the server limits the number of requests per address. A normal run uses about a third of the allowance.
References
Official documentation used to check this article. Pages are maintained by their owners and may change.
Reviewed against ChatLite's current behavior on .