VoIP Echo Test (WebRTC)
A real WebRTC echo test against Cloudflare's edge. You'll hear your own voice with the round-trip delay your network introduces — exactly what your SIP/VoIP traffic would experience. Plus live jitter, packet loss, RTT, and an estimated MOS score.
Use headphones. Without them you'll hear yourself echo into your own mic and create a feedback loop. Your speakers will hate you.
This test asks for microphone access when you click Start. Audio is sent through Cloudflare's media servers and reflected back — nothing is recorded or stored. Stop the test to release the mic immediately.
What this test actually does
Your browser opens a real WebRTC peer connection to Cloudflare's Realtime SFU edge. It publishes one audio track (your microphone) and subscribes to that same track from the SFU — so anything you say is reflected back. The audio path uses real UDP with the Opus codec, the same codec used by 3CX softphones, Zoom, Teams, and most SIP providers in 2026.
Why this is closer to a real VoIP call than a generic speed test
- Real UDP, not HTTP: Speed tests use TCP/HTTP and tell you nothing about UDP behavior. VoIP is UDP. This test exercises the actual transport your phone calls use.
- Real-time encoding: Audio is encoded with Opus (or G.722, depending on what your browser negotiates), packetized, and shipped at 50 packets/second. Same packet rate as RTP at 20ms intervals.
- Real NAT traversal: The connection establishes via STUN, fails over to TURN if your network blocks direct UDP. If WebRTC fails, your VoIP probably will too.
- Real jitter and loss measurement: Numbers above come from
RTCPeerConnection.getStats()— the same RTCP-derived data Wireshark would show on a SIP call.
How to interpret the numbers
Round-trip delay (RTT)
One-way latency × 2. Anything under 100 ms is good for VoIP. 100–200 ms is borderline noticeable but workable. Above 250 ms callers start talking over each other ("over here", "no you go", silence).
Jitter
Variance in packet arrival times. This is the #1 killer of VoIP quality. A connection with 80 ms latency and 2 ms jitter sounds great. A connection with 30 ms latency and 50 ms jitter sounds choppy. Under 10 ms is excellent. 20–30 ms is the threshold where users start complaining. Above 40 ms, your jitter buffer is fighting a losing battle.
Packet loss
VoIP can recover from very small losses with codec concealment. Under 1% you won't notice. 1–3% causes occasional clicks and dropouts. Above 3% words start disappearing entirely. Above 5% the call is unusable.
MOS score
Mean Opinion Score on a 1-5 scale. Calculated using the ITU-T G.107 E-model from latency, jitter, and packet loss. Industry conventions: 4.3+ excellent, 4.0–4.3 good, 3.6–4.0 fair, 3.1–3.6 poor, below 3.1 unusable. A landline traditionally scores ~4.3, a cell call ~4.0, Skype on a good day ~4.2.
Common problems this test reveals
- WiFi-induced jitter: Run the test on WiFi, then on Ethernet. If WiFi shows 30+ ms jitter and Ethernet shows under 10, your VoIP problems are wireless. Add an access point or run a cable.
- Bufferbloat: Latency low when idle, but jumps during file transfers. Configure SQM/cake on your router.
- ISP-side congestion: Latency creeps up at certain times of day even on Ethernet. Document it and call your ISP.
- Asymmetric routing or BGP weirdness: Very high RTT (300+ ms) for a US-to-US connection means your traffic is going through somewhere unexpected. Check your VPN or default route.
- Restricted-cone NAT or firewall blocking: If the test fails to connect entirely, your network blocks UDP or has overly aggressive NAT. SIP calls with media flowing through this network will have one-way audio.
Audio runs through Cloudflare's Realtime SFU service over encrypted SRTP. Nothing is recorded. The SFU just forwards packets — your mic input bounces through Cloudflare and back to your speakers, then is discarded. We don't store, log, or transcribe anything. When you click Stop, the connection closes and the mic is released. Closing the tab does the same thing.
This test exercises WebRTC's negotiated UDP ports (typically high ephemeral ranges), which is a strong signal but not identical to your SIP provider's specific port range. For example, 3CX uses 5060/5061 for SIP and 5000–6000 for RTP media. If WebRTC works here but your 3CX calls don't, the problem is likely a firewall rule specific to those ports. Use the PBX reachability tester below to verify those specific ports.
What VoIP quality actually depends on
Voice quality on a VoIP connection depends on three network characteristics that are separate from raw bandwidth: latency, jitter, and packet loss. A connection with tons of bandwidth but bad values on any of these three sounds terrible for voice calls. A connection with modest bandwidth but excellent latency, jitter, and loss numbers sounds fine.
This is why "just get faster internet" is often the wrong advice for VoIP quality problems. If your speed test shows 500 Mbps but calls sound garbled, the bandwidth isn't the bottleneck. What's happening under the hood is more likely a queue-management problem, a wireless interference issue, or an ISP-level congestion event that doesn't show up in bandwidth measurements.
The three numbers, in detail
Latency (one-way delay)
How long it takes a packet to travel from sender to receiver. For voice quality, one-way delay is what matters — the round trip is twice that. Under 150ms one-way is considered fine for voice. 150-300ms is noticeable but tolerable. Over 400ms is uncomfortable and creates the awkward "wait, no you go" overlap in conversations.
Latency is mostly determined by geographic distance and network path. Nothing you can do at your end changes the fundamental speed of light. What you can affect: whether your traffic takes an efficient path (avoid VPNs that route through distant countries), whether your local network adds delay (WiFi can add 10-30ms; wired doesn't), and whether your ISP has good peering to the destination.
Jitter
Variation in packet arrival times. If packets always arrive 40ms after being sent, that's zero jitter. If some arrive after 20ms and others after 80ms, that's 30ms of jitter (the standard deviation of arrival times).
Voice quality tolerates a small amount of jitter through jitter buffers — a receiving endpoint holds packets briefly and plays them at the expected pace, smoothing out arrival variation. Buffers work up to a point; excessive jitter overflows the buffer, either delaying playback (adding latency) or dropping packets that arrive too late.
Under 20ms of jitter is essentially unnoticeable. 20-50ms is manageable. Over 50ms is a real problem for voice quality.
Packet loss
How many packets never arrive at all. Voice codecs can handle a small amount of loss (1-2% is usually fine because concealment algorithms can smooth over gaps). More than that starts producing audible artifacts — clipped syllables, robotic sounds, or brief silences.
Loss over 3% makes calls sound bad. Over 5% they sound broken. Loss can happen at any hop along the path — WiFi radio errors, congested router queues, ISP oversubscription, or destination-side issues.
What this tool actually measures
The test sends a sequence of small UDP-like packets (simulated over the browser's available transport) to Cloudflare's edge and measures how long they take to arrive, the variation in their arrival times, and how many go missing. This mimics what SIP media traffic (RTP) does during a real voice call, and produces comparable numbers.
The results give you a snapshot of your connection's suitability for VoIP right now. Running the test at different times of day (peak evening hours vs quiet mornings) reveals whether your ISP has congestion patterns you should know about.
Common VoIP quality problems and their signatures
WiFi issues
Test over WiFi shows moderate loss and high jitter. Test over wired shows clean numbers. This is a WiFi problem — interference, signal strength, or channel congestion. Fix at the WiFi layer (better router placement, less-crowded channel, wired connection for the phone).
ISP congestion during peak hours
Test shows fine numbers during the day, gets worse in the evening. The ISP is oversubscribed and can't keep up with peak demand. Not usually fixable except by switching ISPs or complaining loudly.
Bufferbloat
Test shows high loaded latency even though idle latency and bandwidth are fine. When any other traffic is happening (a download, a big file upload), voice quality tanks. Fixable with proper Queue Management (SQM, fq_codel) at the router — modern routers often have this as a checkbox in QoS settings.
Overloaded router
Test shows loss even when nothing else is happening on the network. Consumer routers with weak CPUs can drop packets under moderate load. Fix: better router (any modern mid-range unit handles gigabit line rate fine).
Firewall or NAT problems
Test itself is fine but real VoIP calls have quality issues. The path this test measures is HTTPS to Cloudflare; the path real VoIP uses is UDP RTP to a SIP provider, which might be filtered or NAT-mangled by intermediate gear. Different failure mode; requires debugging at the actual VoIP protocol level.
How I use this in real VoIP admin work
Pre-deployment site survey
Before deploying VoIP for a customer, run the test at their location to confirm the network can support voice quality. If numbers are bad at the site survey, address them before installing phones rather than after complaints start.
Troubleshooting customer complaints
Customer reports "the phones sound bad." Running the test shows whether the network is the cause or something else (bad codec configuration, PBX issue, SIP trunk provider problem). Rules out the network as a variable.
Comparing quality across sites
Multiple sites, some with worse quality than others. Running the test at each reveals which sites have network issues to address versus which sites need investigation elsewhere.
Testing after network changes
After enabling QoS, changing routers, switching ISPs, or configuring VLANs specifically for voice traffic, run the test to verify the change had the expected effect on voice-relevant metrics.
The codec question
Different voice codecs use different amounts of bandwidth and handle packet loss differently. Common codecs I deal with:
- G.711 (ulaw/alaw): uncompressed 64 kbps voice. Best quality, works well with jitter and loss, but bandwidth-heavy. Default for most enterprise deployments.
- G.729: compressed 8 kbps voice. Popular for bandwidth-constrained links but licensed (patents expired in 2017, but implementations still often paid).
- Opus: modern codec, variable bitrate typically 20-40 kbps for voice. Excellent quality per bit, handles packet loss well, no patent concerns. Increasingly the choice for new deployments.
If your network has quality issues, sometimes switching to a codec that handles adversity better (Opus over G.711) buys you real improvement without changing the underlying network.
Related tools
The Speed Test measures raw bandwidth, which is different from what VoIP quality depends on. Both tests together give a comprehensive picture. The Bandwidth Calculator helps estimate how many concurrent calls a given bandwidth can support (rule of thumb: G.711 needs about 100 kbps per call including headers, Opus about half that, G.729 about a quarter).
For CGNAT-related VoIP issues (some SIP configurations have trouble behind carrier-grade NAT), the CGNAT Detection tool tells you if your ISP has put you behind CGNAT.
PBX / server port reachability
Check whether a public IP or hostname is reachable on a specific TCP port from outside your customer's network. Cloudflare's edge is the vantage point — same as a customer trying to reach the service. Useful for diagnosing NAT misconfiguration, missing port forwards, ISP filtering, and "the PBX works locally but not from outside" complaints.
- TCP only. Most VoIP traffic (RTP audio, RTCP, plain SIP/UDP) runs on UDP, which Cloudflare Workers can't test from a browser-side tool. For UDP, run
nc -uvz host portfrom a Linux box on a different network, or check inbound flows withtcpdump -i any -n udp port 5060on the PBX. - Cloudflare's vantage point only. A successful check tells you the port is reachable from Cloudflare's edge. A specific customer's ISP could still be filtering — particularly common with cellular carriers and budget broadband.
- No private IPs. The tester refuses RFC1918 / loopback / link-local addresses. It's checking from the public internet, so private addresses are meaningless from that vantage point.
- Not a port scanner. Tests one port at a time. Don't try to use it as nmap; rate limits will kick in.