What Is MOQ (Media over QUIC) and Why It Matters

What is MOQ, and why is everyone in the live streaming industry talking about it? MOQ, short for Media over QUIC, is a new open standard being developed by the IETF to bring real-time, sub-second, and on-demand video into a single, modern protocol. In this blog, you will learn what MOQ is, how it works, how it differs from WebRTC, and what its development means for Red5 users and the future of live streaming.

Watch my short talk on this topic on YouTube.

What is MOQ?

What is the Media over QUIC streaming protocol?

MOQ (Media over QUIC) is a next-generation live streaming protocol being developed as an open standard by the IETF. It is designed to unify real-time streaming, sub-second latency delivery, and video on demand into a single publish-subscribe model built on top of QUIC. Most people simply refer to it as MOQ (pronounced “mock”), rather than Media over QUIC.

In practical terms, this means simpler client-server architectures, faster time to first frame, and greater flexibility in how media is encoded, delivered, and consumed. Unlike traditional approaches that rely on separate protocols for different use cases, MOQ introduces a more consistent and scalable way to handle media transport across live and on-demand workflows.

MOQ streaming deployment diagram.

From my experience, MOQ began being one of the most discussed topics across industry events since IBC 2025 that I attended with Brett Fasullo, our SVP of Global Sales, and David Engelmaier, our Solutions Architect in Amsterdam, and the RTC.On conference in Poland. Here are a few sessions about MOQ that stood out from these two events:

• Gwendal Simon, Senior Director of Technology at Synamedia, “OpenMOQ: A New Consortium to Advance MOQ” at IBC 2025. 
• Will Law, Chief Architect at Akamai, “A QUIC update on MOQ and WebTransport” at RTC.On in Kraków. 
• Ali C. Begen, Professor of Computer Science Department at Özyeğin University and the founder of the super cool MOQtail project, “Streaming Bad: Breaking Latency with MOQ” at RTC.On in Kraków. Check out his presentation on LinkedIn. 

These talks confirmed that MOQ is generating real momentum, but it’s still early. It’s experimental, evolving, and not yet widely deployed, which is perfectly fine. Every major protocol, including WebRTC, started small.

What is the MOQT standard?

But the basics to the transport foundation to MOQ, known as the MOQT standard, are pretty well set. To summarize:

• MOQ, like WebRTC, uses a connectionless publish/subscribe approach to streaming that’s incompatible with the request-response method used with traditional HTTP streaming. Whereas a one-hour video streamed over HLS or DASH entails thousands of client requests for short sections of video, with MOQ or WebRTC, once a user selects a tendered media stream from a publisher, the stream transmits in its entirety or until the user quits the stream. The primary and crucial difference between MOQ and WebRTC, which also uses QUIC, is that the initial set-up is much easier with MOQ, as are the mechanics of scaling and adjusting to cloud resource utilization with the ebb and flow of traffic. 

• As the original name implies, QUIC is fundamental. QUIC relies on UDP to send datagrams (packets consisting of headers and payloads) to destinations without reacting when packets are dropped. This sets up the traffic flow much faster than can be done with back-and-forth messaging used by TCP, and it avoids the buffering associated with retransmitting dropped packets that occurs with TCP. Moreover, because the connectionless approach used by MOQT allows multiplexing of independent concurrent transmissions of the stream within a single connection, when packets in one stream are blocked, those packets still get through. This contrasts with the blockage occurring with TCP as often lengthy flows are backed up awaiting retransmission of dropped head-of-line packets. And adding to robustness, the IETF has added forward-error-correction (FEC) extensions to MOQT that enable “erasure control” by sending redundant data that receivers can access to recover lost packets. The overall result is reliable performance at far lower latency, which can be exploited with use of multicasting in mass streaming environments.

• Augmenting ease of use by enabling compatibility with browsers, MOQ can and most often will be used with an adaptation of WebTransport, which was developed by the World Wide Web Consortium (W3C) as a web API that enables the QUIC/UDP-based HTTP/3 protocol to be used in bidirectional low-latency transport. The MOQ version of WebTransport extrapolates elements of HTTP in a thin layer that intervenes between QUIC and MOQ by acting as though it’s connecting to an HTTP/3 resource, which sets up the browser connection.

• The fundamental building blocks for enabling transmission of MOQT payloads are known as objects, i.e., packets consisting of headers and messages comprising both the streamed content going to end users and the control object payloads that direct set-up and how the stream is to be used one-way or bidirectionally. Objects are assigned linearly precise positions in sequences or groups typically bounded by I frames that make up the streamed tracks flowing over MOQT.

• Every object is associated with a specific series of groups comprising a track. Object-track ties rely on a naming system hidden behind whatever branding a streamer uses, which allows subscribers clicking on those links to join a live session at the outset or at any juncture between groups in the flow. 

• While MOQT objects convey A/V and data payloads, the encoding, encryption, framing and other mechanisms comprising the media layer are decoupled from transport, which maximizes flexibility in streamers’ use of codecs, DRM, watermarking, approaches to advertising and feature personalization, and other components of their applications. The decoupling allows CDNs to deploy MOQ as a transport service supporting all MOQ-compatible streaming formats, much as HTTP supports HLS, DASH and other formats. 

• While in this sense MOQT is just a pipe, there’s a tremendous amount of functionality built into the transport layer, including support for relay servers, track structures and transport communications security embodied in encryption mandated by the QUIC standard. And there are other mechanisms available optionally to enhance flexibility in the use of transport. Most important, there’s a lot of functional flexibility built into the relay system, including whether caching is used with relay servers, and, if it is, what the cache storage is used for.

• Relay servers are points of connection from the originating source of content at the ingestion into MOQ through to end users in arrays comprising a delivery network analogous to today’s CDNs. Each relay is a point of termination with visibility into MOQ object metadata that enables it to act simultaneously as a subscriber to tracks from upstream and as a publisher forwarding tracks downstream to other relays or end users, all without using relay processing power to look at the content. Crticially, the payload segment of the object byte string remains encrypted and untouched by relay processing. The configuration allows any given stream to be fanned out from a single source to any number of end users wherever they might be, all in accord with the rights authorization and authentications mandated by the control objects, as well as timestamp correlation across all streams in instances where synchronized reception is vital to the use case. 

• MOQT employs relays servers to support tunable latencies suited to a wide variety of use cases and levels of robustness required for each transmission. If real-time delivery is top priority, people will have to live with occasional glitches that are inevitable despite all the protections built into the protocol. But if top-of-line quality is the priority, then alternatives supported by implementation of buffering at MOQ caches might be the better option. Glass-to-glass tunable latencies with variable levels of buffering protection can range from real-time at 200-400ms to what developers call “interactive live” at 2 seconds, which might be sufficient for some interactive applications, to “conservative live” maintaining persistent HD, 4K or, eventually, 8K quality at 5 seconds.

Optionally, depending on how MOQ-ready CDNs are designed, MOQT can employ relay caches to support recording live content for short-term replay and catchup. There’s also support for bringing long-term storage into play for sending live content to VOD archives and cloud DVR platforms. 

What is the OpenMOQ Software Consortium?

Alongside the IETF standardization effort, there are several open source initiatives supporting the development of MOQ, including a C++ relay implementation and other core components of the protocol. These efforts are coordinated through the OpenMOQ Software Consortium, an organization founded by industry leaders such as Red5, Akamai, CDN77, Cisco, Synamedia, and YouTube. The consortium focuses on advancing MOQ through high-performance, production-ready open source software that can support real-world deployment at scale.

In December 2025, we officially joined the OpenMOQ Software Consortium as a Charter Member, contributing to both the technical direction and practical implementation of MOQ-based systems.

As of April 2026, the OpenMOQ has completed industry discussions, established a technical roadmap and collaboration framework, and finalized company setup, including legal structure and governance. The initiative has now moved into the core infrastructure development stage.

Eleven vendors including Ant Media, AWS, Bitmovin, Broadpeak, CacheFly, Cloudflare, Nomad Media, Oracle, Norsk, Synamedia, and Red5 demonstrated their first MOQ implementations at the NAB Show 2026 in Las Vegas. Once we are back from NAB, our team will write a summary of the event, and I will link to that blog from here in a few weeks.

Is MOQ Replacing WebRTC?

MOQ vs WebRTC

That’s the question everyone’s been asking lately, and the answer is no, or at least not for a long time. As I shared in my “MOQ vs WebRTC” blog recently, both WebRTC and MOQ can and should coexist in the live streaming space. Check out this blog for a detailed comparison table explaining the differences between these two protocols.

• WebRTC continues to work extremely well for ultra-low latency streaming directly in browsers, where sub-250 ms performance is essential. It’s mature, proven at scale, and still evolving, with lower costs and better performance as infrastructure providers like OCI continue to improve networking and egress pricing. WebRTC will continue to be a solid choice for much time into the future especially as a video chat solution.

Diagram showing how WebRTC streaming works.

• MOQ, on the other hand, is a newer, simpler protocol that’s built from the ground up for client-server use. It benefits from modular open components like WebTransport and MSE, supports faster startup times, and already has strong backing from major industry players.

Diagram showing how MOQ streaming works.

These two technologies aren’t necessarily competing, they serve different purposes. WebRTC is perfect for video chat, interactive, browser-based workflows that demand immediate responsiveness, while MOQ is designed for scalable, high-performance real-time and cached streaming and VOD scenarios where flexibility and efficiency are key. That also said, MOQ isn’t ready yet for production use cases, although I think it’s coming rather soon given the current momentum.

What This Means for Red5 Users

At Red5, we’ve always been a protocol-agnostic company. We started with RTMP in the Flash days and now support RTSP, SRT, HLS, Zixi, WHIP and WHEP, and more. We recommend the protocols that best fit our customers’ use cases and requirements. MOQ is the next step in that evolution.

We now offer early access to MOQ through the Red5 Cloud MOQ beta, giving developers and enterprises the ability to start testing real-world streaming workflows today. Instead of waiting for the specification to fully stabilize, we focused on delivering a working, end-to-end implementation that can be used with your own application at global scale. With the beta, you can experiment with using MOQ as part of your streaming stack alongside the features you already rely on, including multi-view experiences, clipping, and DVR-style playback. The goal is not to force a switch, but to give you a practical way to evaluate how MOQ can simplify your architecture and reduce the need to switch between WebRTC for live and HLS for replays. If you want to try it yourself, you can learn how to get started with the Red5 MOQ beta here.

Conclusion

MOQ has moved beyond theory and is now something you can actually see, test, and evaluate in real environments. With working demos across multiple vendors at NAB Show 2026 and early beta implementations already available, the conversation is shifting from “what is possible” to “what works in practice.” At the same time, the protocol and ecosystem are still evolving. Key areas like interoperability, monetization, and standardization are actively being developed as more companies begin building on top of MOQ.

At Red5, we are already part of that shift. Through our work with the OpenMOQ Software Consortium and the launch of the Red5 Cloud MOQ beta, we are giving developers a way to start testing MOQ in real-world applications today. This includes one of the first end-to-end, globally scalable implementations delivered in partnership with CacheFly, without the need to manage infrastructure or scaling. If you are building real-time applications, now is the right time to start experimenting with MOQ, understand where it fits, and be ready as it moves toward broader production adoption.