What this VoIP test measures
- Latency — 30 round trips to the nearest Cloudflare edge server, after a discarded warm-up.
- Jitter — the average change in delay from one sample to the next (the same idea as RTP interarrival jitter in RFC 3550).
- Packet loss — probes that don't return within 2 seconds.
- Download and upload — four parallel streams for 6 seconds each way, ignoring the first 1.5 seconds of ramp-up.
- MOS — estimated with a simplified E-model (ITU-T G.107).
- Calls supported — 75% of the slower direction divided by 100 kbps per G.711 call.
How to read your results
| Measurement | GOOD | FAIR | POOR | What you hear when it's bad |
|---|---|---|---|---|
| Latency (round trip to nearby server) | ≤ 100 ms | 101–200 ms | > 200 ms | Delay, people talking over each other |
| Jitter | ≤ 20 ms | 21–30 ms | > 30 ms | Choppy, robotic, "underwater" audio |
| Packet loss | 0% | ≤ 1% | > 1% | Clipped words, gaps, dropped calls |
| MOS (estimated) | ≥ 4.0 | 3.6–3.99 | < 3.6 | Overall "this call sounds bad" |
| Bufferbloat (latency increase under load) | < 30 ms | 30–99 ms | ≥ 100 ms | Calls fall apart when someone uploads or streams |
These are the pass/fail lines this site uses. They are built from ITU-T G.114 (keep one-way mouth-to-ear delay under 150 ms for most calls), the common carrier guidance of jitter under 30 ms and loss under 1%, and the E-model MOS scale. Your carrier may publish its own numbers — use theirs if they differ.
How to get a result you can trust
- Test from the spot where calls go bad — the same desk, the same Wi-Fi or Ethernet jack.
- Test at the time of day calls go bad. Problems that only happen at 10 a.m. or 3 p.m. are usually congestion.
- Run it twice: once with the office quiet, once while someone is uploading or on a video meeting.
- If you use a VPN, test with it on and off. VPNs add latency and overhead to every voice packet.
Frequently asked questions
How do I check if my network is ready for VoIP?
Run the VoIP test above from the location where the phones will be. A VoIP-ready network shows latency under 100 ms to a nearby server, jitter under 30 ms, packet loss under 1%, an estimated MOS of 4.0 or better, and enough upload bandwidth for every call you expect at the same time, at roughly 100 kbps per G.711 call.
How many VoIP calls can my internet handle?
Divide 75% of your upload speed (in kbps) by about 100 kbps per G.711 call. A 10 Mbps upload supports roughly 75 simultaneous G.711 calls by that rule. Compressed codecs like G.729 use about 31 kbps on Ethernet, so the same line carries more calls. The test above does this math for you.
Why is my VoIP call quality bad?
The most common causes are jitter and packet loss from Wi-Fi, an overloaded internet connection without QoS (bufferbloat), a bad cable or modem, SIP ALG on the router, or a problem on the internet provider's network. The test above narrows it to latency, jitter, loss or bandwidth; the Fix Problems page maps each symptom to a fix.
What is the difference between a VoIP test and a speed test?
A speed test reports maximum throughput. A VoIP test also measures how steady the connection is — latency, jitter and packet loss — because voice sends small packets every 20 ms and is ruined by late or missing packets long before a line runs out of speed.
Does a VPN affect VoIP call quality?
It can. A VPN adds encryption headers to every voice packet (roughly 50–75 extra bytes with IPsec), routes traffic through the VPN server, and can hide voice packets from QoS rules. Many businesses send phone traffic outside the VPN or use the phone system's own encryption (SRTP/TLS) instead.
What MOS score should a business phone system get?
4.0 or higher is considered good business quality; 4.3 and above is excellent. Between 3.6 and 4.0 most users notice some impairment. Below 3.6 many callers are dissatisfied. Standard G.711 calls have a practical ceiling around 4.4 on a perfect network.
Should I test VoIP on Wi-Fi or wired?
Test both. Desk phones should be on wired Ethernet whenever possible. If the wired result is good and the Wi-Fi result is poor, the fix is the wireless network (placement, channel, interference or an older access point), not the internet service.
Sources & references
- IETF RFC 3550 — RTP: A Transport Protocol for Real-Time Applications
- ITU-T G.107 — The E-model (R-factor)
- ITU-T G.114 — One-way transmission time
- IETF RFC 4594 — DiffServ service classes (EF for telephony)
- Cloudflare speed test (endpoint used by these tools)
Written by Eric · Reviewed November 2026