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.
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.