WebRTC, QUIC, and the new shape of real-time signaling
I run engineering for Sonoma, which is Ington's voice, video, and real-time signaling group. This is my first post here, so let me start with the thing I say to every new hire on their first day: real-time media is not a video problem. It's a networking problem wearing a video costume. Once you internalize that, a lot of the noise in this industry starts to make sense, including the noise about WebRTC's supposed decline and QUIC's supposed takeover.
The short version is that neither of those things is quite true, and the interesting story is what's happening in between.
What WebRTC actually gave us, and what it cost
WebRTC won the real-time web for a good reason. Around 2011 it took a pile of hard problems, echo cancellation, jitter buffers, NAT traversal, congestion control, encrypted transport, and packaged them into something you could drop into a browser. No plugin, no native client. That's a genuinely big deal, and it's why your video calls, your telehealth visits, and a decent chunk of live customer support all still ride on it today.
But WebRTC carries the design assumptions of its era. It was built peer-to-peer first, with the browser as the star of the show. Its transport is a stack of acronyms, ICE, STUN, TURN, DTLS, SRTP, that were each reasonable on their own and collectively turned "connect two people" into a negotiation with more edge cases than anyone enjoys debugging at 2 a.m. And the signaling? WebRTC famously doesn't define it. You bring your own. That was meant as flexibility. In practice it meant every team reinvented the same fragile websocket dance, and interoperability suffered for a decade.
The peer-to-peer model also quietly stopped matching reality. Almost nobody connects two browsers directly anymore. We route media through servers, SFUs and MCUs, because that's how you do recording, moderation, transcription, and scale. So we've spent years running a peer-to-peer protocol through a client-server architecture and paying for the mismatch in complexity.
QUIC changes the floor you're standing on
QUIC is the transport that HTTP/3 rides on, and it's a real standard now, RFC 9000, with HTTP/3 as RFC 9114. If you've loaded a Google or Cloudflare property lately, you've already used it. What makes it matter for real-time media isn't any single feature, it's the combination.
QUIC gives you streams that don't head-of-line block each other, so one lost packet doesn't stall everything behind it. It folds the transport and encryption handshakes together, so connections start faster, and it supports zero round-trip resumption for clients you've seen before. It rides on UDP but brings its own reliability and congestion control, tuned in userspace where you can actually iterate on it. And it survives network changes, so a phone moving from wifi to cellular keeps its connection instead of dropping it.
Put plainly: QUIC gives you most of what WebRTC's transport layer was hand-rolling, but as a maintained, general-purpose standard that the whole web is investing in. That's the part that should get an infrastructure team's attention. You stop maintaining a snowflake and start standing on a road everyone else is paving.
WebTransport is the bridge, not the replacement
Here's where signaling gets interesting. The piece that connects QUIC to the browser is WebTransport, an API that hands you QUIC's streams and datagrams directly from JavaScript. Think of it as the websocket you always wanted: multiple independent streams, unreliable datagrams when you want them, all over one migration-friendly connection.
The reason this matters right now, in 2026 and not two years ago, is coverage. WebTransport has been in Chromium browsers and Firefox for a while, and as of Safari and iOS 26.4 this spring, it's effectively everywhere that matters. That's the unlock. A browser transport isn't useful to a product team until it runs on the phone in your customer's pocket, and now it does.
So the emerging pattern isn't "rip out WebRTC." It's "move signaling and bulk media onto QUIC and WebTransport, and keep WebRTC where its specific strengths still win." Two working groups at the IETF have basically agreed on this in public: WHIP, the standardized ingest signaling that finally fixed WebRTC's bring-your-own-signaling problem, and Media over QUIC are both converging on WebTransport as the common carrier in the browser.
Media over QUIC, and why we're paying attention
Media over QUIC, or MoQ, is the one to watch. It's a publish-subscribe media transport built to run over QUIC or WebTransport, and its whole premise is the thing WebRTC never did cleanly: deliver low-latency media to a very large audience through relays, instead of negotiating a mesh of peers.
It's still a draft, and I want to be honest about that rather than sell you vaporware. The IETF transport draft has been moving through monthly revisions and sat around revision 17 to 18 in the first half of this year, heading toward last call. But it's past the toy stage. At NAB this April, roughly a dozen vendors, including Cloudflare, AWS, and Oracle, showed interoperable MoQ implementations talking to each other. Cloudflare has MoQ relays running on its edge across hundreds of cities. Reported comparisons put QUIC-based delivery at meaningfully lower latency and much faster connection startup than WebRTC at scale, though I'd treat any single benchmark as directional rather than gospel until you've measured it on your own traffic.
The claim that matters is architectural: MoQ aims to match WebRTC's sub-second latency while scaling to hundreds of thousands of concurrent viewers, because it's built server-out through relays instead of peer-to-peer. If that holds up in production, and it's starting to, it changes what you can build.
Where this lands for live AI and esports
This is the part I actually care about, because it's what Sonoma builds for.
Two categories are pulling hardest on real-time infrastructure right now. The first is live AI. A voice agent that listens, reasons, and talks back is a real-time media pipeline with a language model bolted into the middle, and every millisecond of transport latency you shave is a millisecond the model gets to think without the conversation feeling broken. QUIC's faster handshakes and stream multiplexing matter here in a way they never did for a one-way video feed, because the loop is tight and two-way and unforgiving.
The second is esports and interactive live events. When the outcome on screen is tied to something time-sensitive underneath it, in-play betting, real-time auctions, live commerce, a viewer who's two seconds behind isn't watching the same event as everyone else. WebRTC can hit that latency but strains at audience scale. Old-school HTTP streaming scales beautifully but runs seconds behind. MoQ over QUIC is the first credible attempt to refuse that tradeoff, and the teams who get it right early will own the latency-sensitive use cases before the field crowds in.
What we're actually doing about it
I'll be straight about where we sit, because pretending you've finished migrating when you haven't just burns trust with the people who have to maintain the thing.
The honest state of the art in 2026 is hybrid, and ours is too. WHIP or SRT for ingest, WebRTC where genuine two-way interactivity is the whole point, and MoQ over QUIC for low-latency delivery when the audience gets large. Anyone who tells you they've collapsed all of that into one protocol today is either running a demo or selling you something.
What's changed is the direction of travel. For years, "real-time signaling" meant WebRTC and a websocket you'd stapled to the side. Now it means a QUIC connection carrying your signaling, your media, and your session state over one migration-friendly pipe, with WebRTC as a specialist you call in for specific jobs rather than the foundation everything sits on. That's a healthier shape. It puts real-time media on the same road as the rest of the modern web instead of off in its own corner with its own rules.
We're building toward that road at Sonoma, deliberately and without ripping out what works. If you're wrestling with the same tradeoffs, I'd like to hear how you're thinking about them. This is a good problem to be working on right now.
Jasmine Hooper leads engineering for Sonoma Communications, The Ington Group's real-time voice, video, and signaling infrastructure team.