WebRTC Connection Tester
Find out why browser video calls will not connect — before blaming the app.
How this test works
Every browser-based call — Meet, Teams, Discord, Slack huddles — connects the same way: it gathers candidate addresses, asks a STUN server what the outside world sees, then tries paths until one carries media. A call stuck on "connecting" failed at one of those steps, and knowing which one narrows the cause enormously. This page runs three checks. It builds two peer connections inside the page and connects them to each other, which needs no network at all and so isolates the browser from everything else. It asks two STUN servers on different addresses what your external address and port are. And it compares the two answers: if the port differs between servers, your router is mapping each destination separately, which is the arrangement usually called a symmetric NAT and the most common reason a direct peer-to-peer path cannot be built. That last check is the one a single-server test can never make, because one server has nothing to be compared against.
What the results mean
- Local peer connection
- Two connections created inside this page, joined to each other. No network is involved, so a failure here is the browser itself — a privacy extension, a hardened profile, or a policy that disables WebRTC. This is the one failure that changing networks will not fix.
- STUN servers answered
- How many of the two public servers replied. Reaching one is how a call learns the address the internet sees for you. Neither replying means UDP to port 3478 is being dropped, which is normal on corporate and campus networks and fatal to direct calling.
- Port mapping
- Consistent means both servers saw the same external port, so your router keeps one mapping open regardless of destination and direct call paths can be built. Changes per destination is symmetric NAT: the address one side learns is not the address the other must send to, so the call needs a relay to work at all.
- Local candidates
- Addresses inside your own network. Browsers have replaced these with random .local names since 2018 as a privacy measure. Seeing them hidden is expected and is no obstacle to calling.
Common problems and fixes
- Everything passes here but calls still fail
- Your side can build paths, so look at the other end or the platform. Test the same call from a phone on mobile data: if it works there, the problem is the other network or the service, not your setup.
- The local peer connection fails
- A privacy extension is the usual cause. Anything advertising protection against WebRTC leaks works by breaking WebRTC, and that breaks every browser call along with it. Disable extensions for this page and re-test before looking anywhere else.
- No STUN server answers on a work or campus network
- UDP to port 3478 is blocked deliberately there, and there is no fix from your side. Calls will only work if the platform relays them, which most commercial ones do. It is worth reporting to whoever runs the network, because relayed calls are noticeably worse.
- Port mapping changes per destination
- On your own router, enable UPnP or NAT-PMP, or look for a strict-NAT note in its status page — consoles report the same condition as NAT Type 3. On a mobile hotspot or carrier-grade NAT there is nothing to change, and relayed calls are the expected outcome.
Frequently asked questions
What is a symmetric NAT and why does it break calls?
A router normally opens one external port for your connection and reuses it for everyone you talk to, so a peer told "reach me at this port" can. A symmetric NAT opens a different port per destination, so the address your caller was given is not the address that will reach you. The call then needs a relay in the middle, and where the platform does not provide one it simply never connects.
Why does it use two STUN servers?
Because the port-mapping question can only be answered by comparison. One server tells you your external address; two servers on different addresses tell you whether that address stays the same depending on who is asking. Most one-click WebRTC pages use a single server and therefore cannot report the finding that most often explains a failed call.
Does a VPN affect the result?
Frequently. Several VPNs carry UDP poorly or not at all, which leaves web browsing perfectly fine while breaking call setup entirely. If the result is worse than expected, run it once with the VPN off — that comparison is usually conclusive.
Is my address being logged?
No. The addresses appear on screen while you look at them and are not sent anywhere or stored. The exportable summary records only the shape of the result — whether the loopback worked, how many servers answered, what kind of mapping was seen — and never the addresses themselves.