Who writes this
I'm Eric. I've spent 45 years in electronics repair and telecom — benches full of radios and test gear first, then phone systems, circuits and the networks that carry them today. I've crawled through enough phone closets to know that most "bad phone" calls come down to a handful of causes, and that a customer with the right numbers in hand gets a faster, cheaper fix.
This site puts those numbers in your hands. Every answer here is written the way I'd explain it on a service call: what the measurement is, what good looks like, what usually causes a bad result, and what to try first.
Who answers the phone
Technical help comes from Infotel Systems, a Richmond, Virginia provider of VoIP phone systems, IP networks, IT services and network cabling, local to Richmond for about 35 years. Infotel built its own edge data center in 2000 and holds Virginia DCJS, Class A contractor and master electrician licenses (listed at the bottom of infotelsystems.com). Infotel also publishes StatusLights.com, TestCall.com, ComcastRepair.com and FixCallerID.com.
Call 804-222-8009 or use the contact form.
Methodology
| Test | How it measures | Server |
|---|---|---|
| Latency, jitter, loss | Repeated zero-byte HTTPS requests after a discarded warm-up; browser Resource Timing used where available; timeouts counted as loss | Cloudflare edge (fallback: Google) |
| Download / upload | Four parallel streams; first 1.5 s of ramp-up excluded | speed.cloudflare.com |
| Bufferbloat | Median latency while saturating each direction minus idle average | speed.cloudflare.com |
| MOS / R-factor | Simplified ITU-T G.107 E-model | Calculated in your browser |
| Public IP | HTTPS lookup | api.ipify.org |
| UDP / NAT | WebRTC ICE gathering against STUN | Google and Cloudflare STUN |
| DNS / SRV | DNS over HTTPS (JSON) | Cloudflare 1.1.1.1 (fallback: Google) |
| Microphone / speakers | Web Audio API, MediaRecorder | None — local only |
Known limits
- Browsers can't send ICMP pings or raw UDP voice packets, so latency and loss are measured with HTTPS. Results are a close proxy, not a carrier-grade measurement.
- The test server is the nearest internet edge, not your VoIP provider. Real call paths are longer.
- Gigabit and faster connections often measure low in a browser.
- MOS is an estimate from a simplified model, not a listening test.
Editorial policy
Facts on this site are tied to published standards (ITU-T, IETF RFCs, FCC) wherever one exists. Where the industry has no single official number — signal-strength grades, for example — the page says so and gives the common ranges. No advertising, no paid placements.
Frequently asked questions
Who runs Call Quality Test?
The site is written by Eric, a telecom technician with 45 years in electronics repair and business telecom. Technical help and service are provided by Infotel Systems of Richmond, Virginia, reachable at 804-222-8009.
How accurate are browser-based VoIP tests?
They are accurate for spotting local and internet provider problems such as Wi-Fi jitter, bufferbloat and packet loss. They measure to the nearest internet edge server using HTTPS rather than to your VoIP carrier using UDP, so they don't replace carrier-side monitoring or command-line tools like mtr.
What data do these tests collect?
Tests run in your browser and contact only the public test servers listed in the methodology table. Your latest results are stored in your own browser so they can pre-fill the contact form. Nothing is sent to Infotel Systems unless you submit the form.
Sources & references
- ITU-T G.114 — One-way transmission time
- ITU-T G.107 — The E-model (R-factor)
- IETF RFC 3550 — RTP: A Transport Protocol for Real-Time Applications
- IETF RFC 8489 — STUN
- Cloudflare speed test (endpoint used by these tools)
Written by Eric · Reviewed November 2026