WebRTC Browser Support: Codecs, Permissions & Tests | Callaba
More live video workflow notes and product updates.
WebRTC browser support is not a single yes-or-no cell. A browser can expose RTCPeerConnection and still fail your call because camera permission, codec negotiation, device constraints, autoplay, embedding policy or the available ICE path differs. Build a small support matrix around the workflow you ship, then rerun it against the browser releases and devices you actually allow.
Test the call as a sequence of gates
Callaba provides browser rooms; your matrix still owns client compatibility
Callaba supports browser-based WebRTC rooms, participant authorization, chat, screen sharing, recording and room or participant egress into supported outputs. The documented workflow also calls out TURN, secure WebSocket, firewall, browser permissions and participant capacity as join dependencies. It does not promise that every browser build, embedded webview, device or enterprise policy will behave identically.
| Layer | Callaba workflow | Acceptance evidence |
|---|---|---|
| Room access | Create the room and issue a participant token near join time | Authorized user enters; expired or wrong token is denied |
| Media session | Use the browser room with configured media permissions | ICE/DTLS connects and RTP counters increase |
| Client support | Run the supported browser and device matrix | Tracks render, audio is audible and controls work |
Keep browser room-control credentials on the backend. A participant token is not evidence of media compatibility, and a working desktop test is not evidence for an in-app webview. Define supported combinations from test results you can reproduce.
Begin with standards-facing feature detection
The current W3C WebRTC Recommendation defines the browser APIs for peer connections, RTP senders and receivers, data channels, ICE configuration and statistics. Check the interfaces and methods your application calls instead of parsing a user-agent string. Finding a constructor tells you only that the entry point exists.
Next, run the real operation. Create a connection, apply the intended configuration, add tracks, negotiate, collect candidates and inspect state transitions. Treat exceptions and rejected promises as structured evidence. Record exact browser and operating-system builds so you can separate a later browser regression from an application release.
Camera permission has its own state machine
The Media Capture and Streams specification integrates camera and microphone permissions, constraints and device selection. A granted permission does not guarantee getUserMedia() will succeed: a device can be busy, missing, blocked by policy or unable to satisfy required constraints.
Test the first prompt, allow, deny, dismiss, later revocation, device removal and device switching. For embeds, include the actual Permissions Policy and top-level origin. Report NotAllowedError, NotFoundError and OverconstrainedError separately rather than showing one generic “camera failed” message.
Codec support means a negotiated intersection
RFC 7742 requires WebRTC browsers to implement VP8 and H.264 Constrained Baseline video, while RFC 7874 requires Opus plus PCMA and PCMU audio. Those mandatory baselines improve interoperability, but an application can still fail through profile parameters, packetization, channel assumptions, media direction or a middlebox that changes the offer and answer.
Capture the redacted SDP on both sides. Compare offered and accepted codecs, payload types, H.264 profile-level-id, packetization mode, Opus parameters, RTP header extensions and rejected media sections. Confirm the chosen codec in getStats(); do not infer it from the first codec listed in an offer.
ICE success depends on the network path
A same-LAN test usually selects a host candidate and says little about production. Exercise server-reflexive and TURN-relayed paths on representative home, mobile, corporate and VPN networks. Track ICE gathering state, connection state, selected candidate-pair type, round-trip time, loss and bytes sent and received.
Test UDP and the allowed TURN fallback transports. A restrictive network can make the signaling page load normally while media never finds a viable candidate pair. Conversely, a connected ICE pair can carry zero useful media because negotiation or track direction is wrong.
Autoplay and rendering are separate from transport
The HTML Standard defines autoplay as a hint rather than a command that overrides user-agent policy. Call play(), handle its promise, and provide an obvious user action when playback is denied. Include audible remote media, muted previews, inline mobile video and page restoration in the test matrix.
Verify videoWidth, videoHeight, increasing decoded-frame counters and audible output through the intended device. A remote track event with a black element can be a rendering, element attachment or autoplay problem, not a failed WebRTC transport.
Example: the call connects but remote video stays paused
The room join succeeds, ICE reaches connected, inbound bytes rise and decoded frames appear in statistics, yet one mobile browser shows a static poster with no sound. The team first changes TURN configuration, even though the media path is healthy. Compare the play() promise, element muted state, user activation, inline playback attributes and audio output route on the failing device. Add a clear “Tap to start audio and video” control when automatic playback is denied. Verify motion, audible speech and the expected output device while preserving the same selected ICE pair.
Maintain a compact release matrix
- Choose combinations. List supported browser channels, OS families, devices and embedding modes.
- Exercise permissions. Cover first use, denial, revocation and switching.
- Prove negotiation. Save redacted offers, answers and selected codecs.
- Vary connectivity. Test direct and TURN-relayed paths on realistic networks.
- Confirm experience. Inspect media statistics, rendering, audio, controls and recovery.
- Repeat on change. Rerun for browser, OS, SDK, codec-policy and server releases.
WebRTC browser support FAQ
Do modern browsers support WebRTC?
Major browser engines implement the core APIs, but your specific codecs, permissions, devices, embedding and network paths still require a tested support matrix.
Should I publish a permanent browser version table?
No. Record tested versions and dates, use feature detection, and repeat acceptance tests as browser and operating-system releases change.
Why does WebRTC work on Wi-Fi but fail on a corporate network?
The corporate path may block direct candidates or required TURN transports. Inspect candidate gathering and the selected pair instead of treating signaling reachability as media reachability.
Does Callaba guarantee every browser and webview?
Callaba documents browser video-call workflows and dependencies, but no universal browser-build or embedded-webview guarantee is documented. Validate the combinations you support.