DeviceTriage
Troubleshooting guide

WebRTC connection failed in the browser

Separate a missing browser engine from media permissions, firewall policy, VPN routing, TURN relay, and service-specific failures.

Run private WebRTC test

Common symptoms

  • A call remains on connecting or disconnects immediately
  • Camera and microphone work but participants cannot connect
  • Calls work on one network or browser but not another

Possible causes

  • Restricted embedded or outdated browser context
  • Camera or microphone permission and device-selection problem
  • VPN, firewall, proxy, enterprise policy, or UDP filtering
  • TURN relay, signaling service, account, or application outage

How to diagnose it

  1. Run the local WebRTC Test to verify the core peer-connection engine
  2. Test camera and microphone separately before blaming the network
  3. Compare another current full browser and, where allowed, another network
  4. Check the calling service's status and diagnostic page for relay or signaling errors

Solutions to try

  1. Open the call in a supported full browser over HTTPS
  2. Grant only required site permissions and select the intended devices
  3. Temporarily compare without a VPN or restrictive extension when policy allows
  4. Ask an administrator to review the service's documented WebRTC and TURN requirements
  5. Report repeatable failures with browser, OS, network, and timestamp details

The first 10-minute diagnosis

  1. Run the local WebRTC Test to verify the browser's core peer engine without media or discovery servers.
  2. Test camera and microphone separately so a permission failure is not mistaken for network failure.
  3. Compare a full current browser, private or extension-limited session, and the service status page.
  4. Where policy allows, compare one other network before changing firewall rules.

Decision path by result

Local WebRTC test failsPrioritize browser version, embedded context, extension, enterprise policy, and engine support.
Local test passes but calls fail everywhereInvestigate media permission, account, service status, signaling, firewall, and TURN relay access.
Calls fail on one networkReview VPN, proxy, UDP filtering, firewall, captive portal, and administrator policy.
Calls fail for one serviceUse that service's status and diagnostic information before changing the whole device.

Platform-specific checks

Home networks

Compare VPN off, another browser, and another network before resetting the router. Real calls may require TURN when direct paths fail.

Managed networks

Do not bypass policy. Give administrators the service's documented domains, ports, protocols, timestamp, and reproducible symptoms.

Mobile and embedded browsers

Open the link in the full system browser. App webviews, data saver, background limits, and mobile routing can change WebRTC behavior.

What not to do first

  • Do not open broad firewall ranges without the service's official requirements.
  • Do not treat a camera permission denial as proof of network failure.
  • Do not publish ICE candidates, logs, account IDs, or private meeting links in public support posts.

When to move beyond a browser test

  • Contact the service when failures are account- or service-specific and its status page does not explain them.
  • Contact the network administrator with controlled comparisons when only the managed network fails.

Last technical review: 2026-09-03

Frequently asked questions

Does this WebRTC test contact a STUN or TURN server?

No. It uses an empty ICE-server list and a same-page data channel. This protects privacy but does not test real NAT traversal or relay access.

Can a local pass prove my video call will work?

No. Real calls add media devices, codecs, remote signaling, NAT traversal, relays, firewall rules, bandwidth, and service logic.