Why does the WebRTC Test pass but my call still fails?

The browser APIs may work while the specific app still fails because of account policy, provider TURN servers, codec negotiation, or a blocked network route. Test on a mobile hotspot and check the app's network requirements.

Does WebRTC require HTTPS?

Camera and microphone access require a secure context in modern browsers. If an old meeting link starts with http://, try the https:// version or ask the site owner to fix it.

Which ports should IT open for WebRTC?

Use the meeting provider's current network documentation. Common examples include Google Meet UDP 3478 and 19302-19309, and Teams UDP 3478-3481 plus TCP 80/443, but Zoom and other products publish their own tables.

Is it safe to disable WebRTC leak protection?

It is reasonable while joining a trusted call if that blocker is breaking WebRTC. Turn the privacy feature back on after the call if you rely on it.

WebRTC Not Working? Fix Camera, Mic, Network, and Codec Issues

Direct answer

WebRTC is not one setting. Browser calls fail when one layer breaks: secure page access, browser permission, OS privacy permission, the selected camera/mic/speaker, UDP/STUN/TURN connectivity, codec support, or GPU/media stability. Start with WebRTC Test, fix the failing layer, then rerun the same test before changing anything else.

If camera or microphone lines fail, fix permissions and device selection first. If devices pass but the call connects with no audio/video, freezes, or falls back, suspect VPN, firewall, TURN, or codec negotiation. If the same call works on a mobile hotspot, the browser is probably fine and the network path needs attention.

Reviewed June 29, 2026. This guide uses a reproducible diagnostic workflow: run the local WebRTC test, change one layer, retest, compare another profile/network only when the failing signal points there.

Match the failing signal

WebRTC Test result or symptom	Most likely cause	Do this first	Confirm with
Camera blocked or no preview	Browser site permission, OS privacy setting, or another app owns the camera	Allow camera in browser and OS, then close camera apps	Preview appears in WebRTC Test
Mic allowed but meter is flat	Wrong microphone, muted headset, OS input level, or exclusive capture	Pick the right mic and check OS input level	Meter moves while speaking
Speakers silent but others hear you	Wrong output device or Bluetooth headset profile	Pick speakers in the call app and OS sound settings	Two-way test call
Devices pass but call has no media	UDP, STUN, TURN, VPN, proxy, or firewall block	Test on mobile hotspot; disable WebRTC leak blockers	Hotspot works or connectivity turns green
Call connects then freezes	Packet loss, bandwidth shaping, GPU decode/compositing issue	Try wired/hotspot, update browser/GPU driver	Stable preview and call
"Codec not supported"	Missing H.264, VP8, VP9, or browser-specific media support	Run Codec Support	Required codec shows supported
Works in app but not browser	Browser permission/network path differs from desktop app	Fix browser permissions and WebRTC network path	Browser call succeeds

Figure callout: For IT escalation, capture the WebRTC Test result before and after a mobile hotspot test. A red connectivity/ICE result on office Wi-Fi next to a green hotspot result is more useful than a generic Meet, Zoom, or Teams error banner.

Fix 1: Confirm the page can request camera and microphone

Modern browsers restrict camera and microphone APIs to secure contexts. If the meeting or test URL starts with http://, switch to https:// if available. Old intranet links and bookmarked webinar URLs are common causes.

Then use the browser's permission controls:

Chrome/Edge: click the lock or tune icon in the address bar, set Camera and Microphone to Allow, then reload. For the full list, open Settings > Privacy and security > Site settings > Camera/Microphone.
Firefox: click the permission icon in the address bar to clear a block, or open Settings > Privacy & Security > Permissions and edit Camera/Microphone.
Safari: use Safari > Settings > Websites > Camera/Microphone for site-level access, then check macOS privacy settings if the browser never prompts.

Permission is stored per origin. https://meet.example.com and https://app.example.com can have different camera/mic states.

Fix 2: Grant OS-level camera and microphone access

The browser can say "Allow" while the operating system still blocks capture.

Windows 11: open Settings > Privacy & security > Camera and Microphone. Allow device access and let desktop apps use the device. Confirm your browser is not blocked by work or school policy.
macOS: open System Settings > Privacy & Security > Camera and Microphone, enable the browser, then quit and reopen it.
Linux: check the desktop privacy panel, PipeWire/PulseAudio device list, and browser sandbox permissions if you use Flatpak or Snap builds.
iPhone/iPad: browser camera/mic access is controlled from iOS app privacy settings. Test Safari if a third-party iOS browser behaves differently.

Run WebRTC Test again. If the preview and mic meter work, capture is fixed.

Fix 3: Pick the right input and output devices

WebRTC often selects the wrong device when a laptop, monitor, dock, webcam, and Bluetooth headset are all connected.

In the meeting app, choose the intended Camera, Microphone, and Speakers.
In Chrome/Edge, set default devices at chrome://settings/content/camera and chrome://settings/content/microphone or the matching edge:// pages.
In the OS sound settings, make the same microphone and speakers the default input/output.
Unplug unused webcams, capture cards, docks, and headsets while testing.

Bluetooth headsets deserve a separate check. Some switch into a low-quality hands-free profile when the microphone is active. If audio becomes distorted or output disappears, test with wired earbuds or the laptop speakers/mic.

Fix 4: Close apps that already own the camera or microphone

Some camera drivers and virtual camera tools do not share cleanly between apps.

Quit Zoom desktop, Teams desktop, Discord desktop, FaceTime, OBS, camera vendor apps, and browser tabs already using the device.
On Windows, check Task Manager for background meeting apps.
On macOS, use the menu bar camera/microphone indicators and quit the owning app.
If a virtual camera is selected, switch to the physical webcam and retest.

If this fixes the test, reopen apps one at a time until you find the conflict.

Fix 5: Remove WebRTC blockers, VPN leak protection, and strict privacy rules

Privacy extensions and VPN browser add-ons can intentionally block WebRTC to prevent IP exposure. That can also break legitimate calls.

Test in this order:

Disable extensions with names like WebRTC Control, WebRTC Leak Shield, script blockers, or strict anti-fingerprinting tools.
Turn off VPN settings labeled block WebRTC, prevent WebRTC leak, or local network protection while joining the call.
Try a fresh browser profile with no extensions.
Run Browser Privacy Check after the call if you need to restore the privacy posture.

Do not permanently weaken privacy settings for every site. Allowlist the trusted meeting site or toggle the blocker only during calls.

Fix 6: Isolate network, firewall, STUN, and TURN problems

WebRTC uses ICE to find a route between peers. That route may involve STUN to discover public addresses and TURN to relay media when direct paths are blocked. If camera and mic pass but the call has no media, the network is the suspect.

Diagram showing WebRTC ICE connection paths through direct peer routing, STUN discovery, and TURN relay

Caption: ICE tries to find the best media path first, then falls back to relay paths when NAT, VPN, or firewall rules block a direct connection.

Fast isolation:

Join the same call on a mobile hotspot.
If hotspot works but office/home Wi-Fi fails, the browser and devices are probably fine.
Disable VPN and proxy inspection for one test.
Try a wired network if Wi-Fi has packet loss or aggressive roaming.

Provider-specific examples to send IT:

Service	Useful network note
Google Meet	Google documents outbound UDP `3478` and `19302-19309` for audio/video, plus `443` for web/auth traffic.
Microsoft Teams	Microsoft documents UDP `3478-3481` for media optimization and notes that VPNs often hurt real-time media.
Zoom	Zoom maintains product-specific firewall tables; use the current Zoom support page instead of copying generic forum port lists.

If your company uses SSL inspection, data-loss-prevention agents, or a security proxy, ask IT to test a bypass for the meeting provider's real-time media domains. WebRTC media is already encrypted; forcing it through a proxy path often causes freezes or one-way media.

Fix 7: Check codecs when the app connects but media fails

Permissions can be perfect and the network can be open, but negotiation can still fail if the browser cannot encode or decode the required format.

Run Codec Support and check:

H.264: common in enterprise meeting, webinar, and hardware-room setups.
VP8/VP9: common WebRTC browser codecs.
AV1: increasingly available, but not required for many calls.

If a service specifically complains about H.264, use Fix H.264 Not Supported. If every codec line looks normal, return to network and app-specific account policy.

Fix 8: Stabilize glitchy video

If the call works for a few seconds and then shows green blocks, frozen frames, or tab crashes, test the media/GPU path.

Update the browser.
Update GPU and camera drivers.
Toggle browser graphics acceleration only after updating drivers.
Rerun WebRTC Test and keep the preview open for at least a minute.
If acceleration-off is stable but CPU usage spikes, use it as a temporary workaround and revisit the driver or GPU path with hardware acceleration troubleshooting.

Fix 9: Use developer diagnostics only when needed

For normal calls, the WebRTC Test and a hotspot comparison are enough. For stubborn cases:

Chrome/Edge: open chrome://webrtc-internals or edge://webrtc-internals before joining the call, reproduce the issue, then export logs for the app vendor or IT.
Firefox: open about:webrtc and reproduce the issue.
Developers: inspect RTCPeerConnection state changes, ICE candidate types, selected candidate pair, packet loss, jitter, and codec negotiation. A failed getUserMedia() points to permission/device; failed ICE points to network/TURN; failed decode points to codec or GPU/media stack.

Do not send raw diagnostics publicly. They can include device names, local network details, and meeting metadata.

Verify before reopening the ticket

Use this final sequence:

Run WebRTC Test until camera, microphone, and connectivity signals pass.
Run Video Call Readiness for the broader browser baseline.
Run Codec Support if the app mentions codecs or H.264.
Join a real call and confirm two-way audio, video, and screen sharing if the workflow needs it.
If multiple browser features are failing, follow Browser Testing Hub instead of debugging WebRTC in isolation.

For support, attach the failing test state, browser version from Browser Test, network tested (office Wi-Fi, home Wi-Fi, hotspot, VPN), and whether a fresh profile changed the result.