What Is MOQ (Media over QUIC) and Why It Matters
Skip to content
MOQ Beta<br>Now Open For Developers
Learn More
explore
Resources
Resources
more
More
legal
Legal
support
Support
Industries
Solutions
Government & Surveillance
Live Events
Broadcast
Gaming
Sports
Truetime Solutions™
Truetime Solutions™
Meetings<br>Host real-time meetings, collaborate live, and broadcast anywhere.
Products
Licensed
Open source
Comparisons
Demo
Resources
Resources
Support
Technology
Protocols
Codecs
Partners
Partners
Cloud & CDN
Hardware
Software
Resellers & Integrators
Red5 Pro
Red5 Cloud
Red5 Pro
Red5 Cloud
Table of Contents
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...