Every modality shares a single line, and none can block another.
Audio, video, text and control all ride the same line. No second socket to babysit, no glue holding separate channels together.
Each modality flows on its own lane. A stalled video frame never holds up the control message queued behind it — everything keeps moving independently.
Your users keep the audio and video pipeline their browser already ships and tests. No plugins, no downloads.
Media rides your transport instead of the default route, so you control quality and routing end to end.
You keep WebRTC's AEC/AGC/NS/Opus on the browser side — those are excellent. We divert just the encoded media frames via RTCRtpScriptTransform onto a WebTransport stream. Net effect: same audio quality, but the agent loop is now on QUIC, with the same fast-cancel barge-in path your SIP and direct-media calls use.
In our measurements, ~0.36 ms on localhost — visually undetectable. On real networks the overhead is dominated by QUIC handshake (one round trip if cold, zero with 0-RTT resumption), not transport encoding.
Safari and Firefox don't ship WebTransport yet (as of writing — see caniuse). The same SDK falls back to WebSocket-over-HTTPS using the same agent and the same barge-in code path. You lose QUIC stream independence on that one client — everything else is identical.
WebTransport is HTTP/3 over UDP/443. Most modern enterprise proxies pass it. The few that block UDP fall back to WS-over-TLS-443 automatically. We've never had a corporate-network deployment we couldn't reach.
Audio is the production-hardened path today. Video frames work end-to-end as a WebTransport stream type but we haven't shipped a tuned VP9/AV1 ingress yet. Talk to us if video is in your pilot scope.
Telequick ships every modality on the same transport.