Why does the test pass but my call still fails?

Some apps also require TURN servers and specific network routes. If you’re on a corporate network, the app may fail due to firewall rules even when the browser APIs work.

What’s the fastest way to isolate network vs permissions?

If camera/mic lines fail, it’s permissions or devices. If device lines pass but connectivity fails, test on a mobile hotspot; that isolates the network layer quickly.

Do I need H.264 for video calls?

Not always. Many services use VP8/VP9/AV1, but some enterprise setups require H.264. Use the Codec Test if a service explicitly mentions H.264.

WebRTC troubleshooting checklist for Meet, Teams, and Zoom (Run the WebRTC Test)

Start with the WebRTC Test (don’t skip)

Open the WebRTC Test and keep it open while you troubleshoot. It separates “WebRTC is blocked” into specific layers you can fix:

Camera permission and camera preview
Microphone permission and input meter
Basic connectivity signals
High-level codec support signals

When you change something, re-run the test. That keeps you from doing five fixes and not knowing which one mattered.

Quick decision tree (match the failing line)

Use this as a fast mapping between symptom and fix.

| WebRTC Test failure / symptom | Most likely cause | What to do next | Verify | | --- | --- | --- | --- | | Camera blocked / no preview | Site or OS permission, another app owns camera | Fix permissions, close other apps | WebRTC Test shows camera allowed + preview | | Mic allowed but meter stays flat | Wrong device selected, OS muted, exclusive capture | Pick correct mic, unmute, close other apps | Meter moves in WebRTC Test | | Devices pass but calls connect with no audio/video | Network blocks UDP/STUN/TURN, VPN “block WebRTC” feature | Test on hotspot, adjust VPN settings, involve IT | Connectivity line turns green; call works on hotspot | | Video works but freezes / green blocks | GPU decode/compositing path unstable | Update GPU driver; test acceleration toggle | Stable preview and stable call | | App says “codec not supported” | Missing H.264/VP8/VP9 on that browser/OS | Run Codec Test; fix missing codec | Codec Test shows required codec support |

If you don’t know which line matters, run the readiness check: Is My Browser Ready for Video Calls?.

Fix layer 1: Site permission (the most common blocker)

If the browser prompt never appears or you previously clicked “Block”:

Use the lock icon in the address bar for the meeting site.
Set Camera and Microphone to Allow.
Reload the page and re-run the WebRTC Test.

If you’re testing multiple call apps (Meet + Teams + Discord), do this per site. Permission state is stored per origin.

Fix layer 2: OS permission and device selection

Even with browser permission, the OS can block capture.

Checklist:

Confirm OS privacy toggles allow camera/mic for your browser.
Pick the intended devices inside the meeting app.
Unplug unused USB devices to simplify the list.
Close apps that own devices (Zoom desktop, Teams desktop, Discord desktop, OBS).

Then re-run the WebRTC Test. If the preview and meters are alive, capture is working.

Fix layer 3: Network path (UDP/STUN/TURN and corporate firewalls)

If camera and mic pass but calls fail, the network is the next suspect.

Do this in order:

Test the same call on a mobile hotspot (fast isolation).
If it works on hotspot but not on Wi‑Fi, your Wi‑Fi path is blocking real-time traffic.
If you’re on a VPN, disable any setting labeled “block WebRTC” or “prevent WebRTC leak” and retry.

If you’re on a corporate network, the fix is usually policy-based:

IT needs to allow the meeting provider’s TURN servers and real-time ports.
If IT needs proof, send them a screenshot of your WebRTC Test failure plus the fact that hotspot works.

Fix layer 4: Codec compatibility

Some services negotiate a codec your browser can’t decode.

Run the Codec Test and look for:

H.264 (common in enterprise)
VP8/VP9 (common in WebRTC)

If a service explicitly mentions H.264 and it’s missing, use the targeted fix guide: Fix H.264 Not Supported.

Fix layer 5: Stability issues (glitchy video, freezes, or flicker)

If the call connects but video is unstable:

Update GPU drivers first.
Then test toggling browser hardware acceleration to isolate the path.
If stability improves with acceleration off, keep it off temporarily and re-enable after a driver update.

Re-run the WebRTC Test and confirm the preview is stable for at least a minute.

Verify the fix (the only part that matters)

When you think it’s fixed:

Re-run the WebRTC Test until camera + mic + connectivity lines are green.
Join a real call and confirm two-way audio and video.
If it fails only on one site but tests look fine, the problem is likely app-side or account-side; try a fresh browser profile and test again.