WebTransport and RTP-over-QUIC: What Might Come After WebRTC

The previous post in this series ended on a promise: WebRTC media doesn't run over QUIC today, in any browser or media server, but the real bridging work is happening at the IETF. Three efforts are worth knowing about - WebTransport, RTP-over-QUIC, and Media over QUIC - and they're not the same thing, even though they get lumped together. Here's what each one actually is, and how far along it actually is, as of this writing.

WebTransport: QUIC's streams and datagrams, handed to the browser

WebTransport is a browser API that exposes QUIC's own transport primitives - multiplexed streams and unreliable datagrams - directly to web applications, built on top of HTTP/3. It ships in Chrome and Firefox already; Safari doesn't support it yet. The spec itself is still a working draft at both the W3C and IETF, not a finished standard, so it's still capable of changing under you.

It's worth being precise about what WebTransport is not: it isn't a WebRTC replacement, and it has no concept of RTP, media codecs, jitter buffers, or echo cancellation built in. It's closer to "fetch() for QUIC streams and datagrams" than a media stack; a foundation other things can be built on, not a video-calling API by itself.

RTP-over-QUIC: today's media stack, tomorrow's transport

RTP-over-QUIC (RoQ) is an IETF draft that does something deliberately narrow: it defines how to carry ordinary RTP and RTCP packets -the same packets today's WebRTC stack already speaks- inside QUIC, using either QUIC streams or unreliable datagrams.

The appeal is continuity. RTP is what today's SFUs, browsers, and media servers already understand; RoQ doesn't ask any of that ecosystem to be reinvented. It asks for the transport underneath it to change, while the media layer on top stays familiar; picking up connection migration, pluggable congestion control, and multiplexing without head-of-line blocking along the way. It's still an active Internet-Draft, not an RFC yet, so it's real IETF work in progress, not a shipped standard.

Media over QUIC: not a wrapper, a fresh design

Media over QUIC (MoQ) takes the opposite approach. Rather than carrying RTP inside QUIC, the MoQ working group - chartered at the IETF in 2022 - is designing a new, QUIC-native media-delivery model from scratch, built around a publish/subscribe model over QUIC streams, aimed at unifying live streaming and real-time conferencing under one protocol instead of treating them as separate problems.

That's a much bigger undertaking than RoQ's, and it shows in the timeline: MoQ has reached cross-implementation interoperability testing at IETF meetings, but it's still active draft work, not a finished standard, and "not yet production-grade" is a fair description of where it stands.

What this actually means, today

None of this is a drop-in replacement for WebRTC right now. WebTransport alone doesn't speak media; RoQ and MoQ are both still IETF drafts, not RFCs. For a media server built around today's WebRTC/RTP stack adopting any of this means real integration work somewhere down the line, not a configuration flag to flip.

But the direction is legible, which is more than could be said a couple of years ago: a future transport that can either carry forward what already works (RTP's own ecosystem, via RoQ) or open the door to something built QUIC-native from the ground up (MoQ), with WebTransport as the browser-exposed foundation either one could sit on.