Troubleshooting · 9 min read

Why a video call won't connect, and how to fix it

Camera permissions, https, NAT, symmetric NAT on mobile data, firewalls and VPNs — the real reasons browser calls fail, in the order worth checking them.

A browser call that never connects is frustrating precisely because there's nothing to see. No error, no ringing, just a spinner that goes nowhere.

Almost always it's one of six things. They're listed here roughly in the order worth checking — cheapest and most common first.

1. The other person isn't actually there

A direct call is not a phone call. There is no server holding a room open and no way to make a device ring. Both people have to have the page open at the same time.

If you sent a link an hour ago and nobody opened it, nothing is wrong — there is simply nothing on the other end to connect to. Agree on a time, then open the link.

2. Camera or microphone permission is blocked

If a browser has been told “no” once, it often remembers, and later attempts fail silently with no prompt at all.

• Chrome / Edge: click the icon at the left of the address bar → Site settings → set Camera and Microphone to Allow, then reload.
• Safari: Safari menu → Settings for This Website → set Camera and Microphone to Allow.
• Firefox: click the padlock → Connection settings → clear the blocked permission.
• macOS, all browsers: System Settings → Privacy & Security → Camera, and confirm the browser itself is allowed. A browser denied at the OS level cannot grant a site access no matter what the site asks for.

Also worth knowing: another app holding the camera — a conferencing client left running in the background — can stop the browser getting it on some systems.

3. The page isn't on a secure connection

Browsers only expose cameras and microphones to pages served over https (or localhost). On plain http the request fails immediately. If you're testing something you built, this is usually the answer.

4. NAT — and why two phones on mobile data often fail

This is the interesting one, and the cause of most failures that survive the first three checks.

Your device almost certainly doesn't have its own public address. Your router does, and it shares it among everything in the house using network address translation. To receive a direct connection, a hole has to be punched through that translation, which is what ICE and STUN are for.

It usually works. It fails in one specific case. A symmetric NAT assigns a different external port for every destination you talk to. So the address a device learns from a STUN server is useless for talking to anyone else — by the time the other peer tries it, the mapping is gone. When both sides are behind symmetric NAT, there is no direct route to find.

Mobile carriers are the classic case. Most run carrier-grade NAT, frequently symmetric. Two phones both on mobile data, on different networks, is close to a worst case — and no amount of retrying will help.

The fix that actually works: move one side onto Wi-Fi. It only takes one side to have a workable mapping.

5. A firewall is blocking UDP

WebRTC media prefers UDP. Plenty of corporate and university networks block outbound UDP except to approved destinations, and some guest Wi-Fi does too.

Symptoms are distinctive: the call connects briefly and dies, or the connection state goes straight to failed after several seconds of trying. If it works on your phone's hotspot but not on the office network, this is why. It is generally not something you can fix from the browser — it needs the network's TURN-over-TCP escape hatch, or a different network.

6. A VPN is in the way

VPNs interact badly with peer-to-peer connections. Some block UDP outright, some present an address that isn't reachable, some route the two peers through wildly different exits. If a call fails and a VPN is running, turn it off and try again — it's a thirty-second test that resolves a surprising share of cases.

Why a TURN server would fix most of this — and what it costs

Every failure in sections 4 to 6 has the same remedy: a TURN relay, which both sides connect out to, and which forwards packets between them. Outbound connections almost always succeed, so TURN rescues nearly every hostile network.

It isn't free. TURN carries the full bitrate of the call, so it costs real bandwidth per minute, and it means media passes through a server — though, as encryption explained sets out, one that cannot read it.

ClearChat doesn't run one. That's a deliberate trade — no relay to fund, and no server in the media path — and the honest cost is that some pairs of networks simply cannot be connected. If a call fails for you after the checks above, that's most likely what happened.

Finding out exactly what failed

In a Chromium browser, open chrome://webrtc-internals in a second tab, then start the call. Look for:

• No srflx candidates. STUN isn't reachable — something is blocking it.
• Candidates on both sides but no succeeded pair. The classic NAT/firewall failure from sections 4 and 5.
• connectionState reaching failed. Every candidate pair was tried and none worked.

Firefox has the same thing at about:webrtc.

The short version

1. Make sure you're both on the page at the same time.
2. Check camera and microphone permissions, in the browser and in the OS.
3. Turn off any VPN.
4. Get at least one side onto Wi-Fi rather than mobile data.
5. If you're on a corporate network, try a phone hotspot to confirm it's the network.

← All guides · Start a call