The in-browser voice path leans on three still-maturing web platform APIs: WebTransport (media and data over QUIC), RTCRtpScriptTransform (the tap that lifts encoded Opus frames out of the browser’s codec — see WebRTC diversion), and WebCodecs (the decoder behind downlink playback). Support for all three is uneven across browsers, so this page tells you exactly where the full path runs, where it partly runs, and what to do when it does not.
This page is about the browser SDK (@telequick/sdk) running in a web page. Native SDK cores (Python, Go, Rust, Java, .NET) reach the media plane through a shared QUIC transport and already ship a QUIC-to-WebSocket fallback ladder — the browser does not have that fallback yet. That gap is the honest story below.

​
The short answer

Chromium family

Full path. Chrome, Edge, and other Chromium-based browsers (Brave, Arc, Opera) run capture, publish, subscribe, and playback end to end.

Firefox

Uplink works, downlink needs your own decoder. Capture and publish run; the bundled player relies on a Chromium-only decoder.

Safari

Not yet. The encoded-frame tap ships only in Safari Technology Preview. Use a telephony leg today, or wait for the planned fallback.

​
Support matrix

Honest as of this writing — browser support is moving quickly, so treat the version floors as a guide and feature-detect at runtime (the SDK does this for you).
CapabilityWhat it powersChromium (Chrome / Edge)FirefoxSafari
WebTransportMedia + data over QUIC on :443Yes (97+)Yes (114+)Preview only
RTCRtpScriptTransformEncoded-Opus uplink tap (in a Worker)Yes (110+)Yes (133+)Technology Preview
WebCodecs AudioDecoderBundled downlink player (Opus decode)YesPartial / noNo
MediaStreamTrackProcessorFrame-level media helpersYesNoNo
getUserMedia + loopback WebRTCMic capture + browser Opus encoderYesYesYes
Full browser SDK voice pathCapture → publish → subscribe → playYesUplink onlyNo
serverCertificateHashes (dev cert)Local-dev QUIC without a public CAYesYesNo
The last row is the one that matters for a product decision: only Chromium runs the whole loop out of the box today.

​
Why each browser lands where it does

Everything the browser SDK needs is stable in Chromium: WebTransport carries MoQT objects, RTCRtpScriptTransform runs in a Worker to lift encoded Opus off the loopback sender, and the WebCodecs AudioDecoder feeds an AudioWorklet ring buffer for playback. If you build and test in Chrome or Edge, you are on the path we exercise most.
The encoded-frame tap the uplink depends on ships only in Safari Technology Preview, and WebTransport is still behind a preview flag. Until both land in stable Safari, the browser SDK media path does not run there. Your options today: route those users over a telephony leg (SIP / PSTN) instead of in-browser media, or wait for the planned browser fallback described below.

​
What the SDK does when a capability is missing

The browser SDK feature-detects and refuses rather than degrading silently. This is deliberate: a half-working audio path is worse than a clear error you can branch on.
  • captureMicrophone(...) checks for encoded-transform support first and throws if it is absent, before it ever touches the microphone.
  • Connecting with encoded transform required will reject the session on a browser that cannot provide it.
So on Safari, or an old Firefox, a capture call fails fast. Guard it and fall back to your own path: 
import { encodedTransformSupported } from "@telequick/sdk";

if (!encodedTransformSupported()) {
  // No in-browser publish here. Offer a phone-number / SIP option,
  // or a "best experienced in Chrome" prompt, instead of a dead mic.
  showTelephonyFallback();
} else {
  await captureMicrophone(publication, { /* ... */ });
}
There is no automatic WebSocket or WebRTC fallback in the browser today. The encoded-transform Worker is the only uplink path the browser SDK ships, which is what enables frame-level end-to-end encryption (the relay only ever sees ciphertext). If encodedTransformSupported() is false, the browser cannot publish audio through the SDK — plan for that branch.

​
The fallback story (what exists, what is planned)

The stack’s standing transport rule is QUIC and MoQT first-class, with WebSocket and WebRTC as required fallbacks. Here is where each rung actually stands for browsers, told straight:
1

QUIC / WebTransport — shipped (Chromium, Firefox uplink)

The primary path. MoQT rides WebTransport on the shared :443 listener, using the moqt-16 subprotocol. This is what the matrix above measures.
2

WebSocket media fallback — native cores only, not browser yet

The native SDK cores fall back from QUIC to a WebSocket media rung when UDP is blocked or a TCP proxy sits in the way. That ladder is not wired into the browser SDK — treat browser WebSocket media as planned, not shipped.
3

WebRTC media fallback — server side exists, browser leg planned

The engine can terminate a real WebRTC leg server-side (ICE-lite with in-process DTLS-SRTP), which is how a UDP-blocked or Safari client would eventually reach the media plane. The server capability is in place; wiring it into the browser SDK as an automatic fallback is planned, not yet available.
Until the browser WebSocket and WebRTC rungs land, the practical fallback for a non-Chromium browser is a telephony leg — dial the user in, or let them dial a provisioned number — so the audio path is SIP/RTP rather than in-browser media. See Transport to telephony.

​
Local development gotchas

WebTransport and the dev-certificate flow are strict about the environment. These trip people up before any compatibility question:
  • Secure context required. Serve over HTTPS (or localhost, which browsers treat as secure). RTCRtpScriptTransform, WebTransport, and getUserMedia all refuse to run on an insecure origin.
  • Use 127.0.0.1, not ::1. The IPv6 loopback literal breaks the QUIC handshake during local testing; the IPv4 loopback works.
  • Short-lived ECDSA dev cert. For local QUIC without a public CA, pass the certificate fingerprint via serverCertificateHashes. The certificate must be ECDSA and valid for no more than 14 days — browsers reject longer-lived certs on that code path. This flow is unavailable in Safari.
  • Multi-brand SNI in production. The WebTransport listener presents per-brand certificates by SNI; connect to the tenant’s own host (<workspace-id>.webrtc.telequick.dev / relay.telequick.dev) so the right certificate is selected.

Browser audio capture

Capture and encode microphone audio, and publish it as a MoQT track.

WebRTC diversion

Borrow the browser’s Opus encoder and divert encoded frames onto QUIC.

RTCRtpScriptTransform

The Worker tap that makes the encoded-frame path — and its E2EE — possible.

WebTransport

The browser-native QUIC path for media and data.

Mobile app transport

Where native mobile clients stand today.

Transport to telephony

The SIP/PSTN fallback for browsers that can’t run the media path.