MOQ vs WebRTC has become one of the most talked-about topics in the live streaming space over the past few months.I’ll share a more detailed blog about this new live streaming technology soon, but first, I’d like to address the latest buzz happening around it. In this blog, I will share the latest industry discussions comparing WebRTC and MOQ, along with my perspective as the co-founder and CEO of Red5, and you will learn why these two protocols aren’t competitors and can coexist in 2025.
Industry Buzz
Cloudflare published a blog post about MOQ in August, describing it as the ultimate solution to all of today’s real-time media transmission challenges. Most of its focus was on comparing MOQ to WebRTC and pointing out everything they could think of that’s bad about WebRTC.
Philipp Hancke from WebRTCHacks responded with an article titled “Is Everyone Switching to MoQ from WebRTC?.” In his post, Philipp explains that Cloudflare’s piece misrepresents WebRTC by suggesting it is purely a peer-to-peer protocol, overlooking the fact that most real-world deployments (like Red5) rely on server-based SFU architectures. He highlights that WebRTC remains stable, widely used, and proven at scale, while MOQ is still experimental, with limited adoption and inconsistent usage data in Chrome metrics.
Where I think Phillip took a wrong turn was spending a huge amount of time comparing usage numbers of MOQ and WebRTC. This part seemed really misleading to me. Of course MOQ is a very new and emerging protocol, and WebRTC has been around for over a decade and is well established. So, of course the usage of MOQ is tiny with lots of fits and starts, and yes, WebRTC is much larger and steady.
I think the goals of MOQ are exciting, and I’m happy to see it succeed.
Sean DuBois also chimed in and shared his perspective on LinkedIn, sparking some interesting conversations.
I agree with Sean that CloudFlare needlessly bashed WebRTC, and much of what they described as its shortcomings were misleading at best, and in some cases flat out wrong. That said, trying to position MOQ as not relevant, claiming that no one is switching to MOQ based on usage statistics we have today is equally misleading.
MOQ vs WebRTC
| Criteria | WebRTC | MOQ (Media over QUIC) |
|---|---|---|
| Architecture | Peer-to-peer with optional SFU/MCU components; complex to scale | Client-server model designed for scalable distribution from the start |
| Setup Speed | Slower setup due to DTLS, ICE, and SDP negotiation | Faster time-to-first-frame thanks to simplified connection setup via QUIC and WebTransport |
| Latency | Sub-250 ms achievable (e.g., Red5 Pro and Red5 Cloud) | Ultra-low latency potential; expected similar or slightly faster performance than WebRTC once fully implemented |
| Scalability | Scales with optimized infrastructure (e.g., Red5’s XDN), but challenging to implement efficiently | Natively scalable via QUIC transport and CDN-friendly design |
| Cost Efficiency | Becoming more affordable with lower egress costs on modern cloud infrastructure (e.g., OCI) | Expected to reduce distribution costs further with CDN integration and QUIC efficiency |
| Media Capabilities | Real-time interactive video, audio, and data streaming; VOD or DVR-style scrubbing requires additional implementation | Supports live and VOD streaming, DVR-style scrubbing, and advanced media track management |
| Standardization | Mature IETF standard; supported by all major browsers | Draft-level IETF development as a next-generation open standard |
| Ecosystem & Adoption | Widely adopted in real-time communication and streaming; extensive tooling and SDKs available | Backed by major players (Red5, Cloudflare, Akamai, Cisco, Google/YouTube, Meta); growing rapidly |
| Compatibility | Supported natively in all major browsers and devices | Built on open web standards (QUIC, WebTransport, WebCodecs) for cross-platform support |
| Security | DTLS and SRTP encryption; strong but adds setup overhead | Security handled natively by QUIC with a simpler connection process; TLS 1.3 is built in from the start |
| Network Protocol | Built on UDP via mature and proven RTP/RTCP standards | Built directly on QUIC (UDP-based), removing RTP overhead |
| Reliability & Congestion Control | Mature congestion control and packet retransmission (NACK, FEC, TWCC) | QUIC-based reliability with simplified retransmission and flow control mechanisms |
| Use Cases | Real-time communications, live events, gaming, surveillance, and auctions | Future-ready replacement for scalable live streaming, VOD, and content delivery |
| Maturity Level | Production-ready and battle-tested | Emerging technology in active development |
| Integration with Red5 | Fully supported today in Red5 Pro and Red5 Cloud | Planned support; under active evaluation for future releases |
WebRTC:
- Already a mature IETF standard
- Existing proven solutions from Red5, Google, Amazon, Dolby, Cloudflare, Twilo, Vonage, Agora, and many more; as well as being the original basis for Zoom.
- It employs decades-old and very mature IETF standards such as RTP, SRTP, RTSP, TLS, and SCTP.
- Works well today in browsers where latency needs to be really low (250ms or less in Red5’s case).
- It can scale, although companies like ours have spent many years getting it right, and it wasn’t easy.
- WebRTC is becoming more and more affordable. Pricing continues to drop with major players like Oracle cloud infrastructure providing very low egress charges and great networking. Red5 Cloud is built on OCI, for example.
- WISH has been developed as a pair of specifications via IETF to simplify WebRTC via WHIP (publish) and WHEP (subscribe) technology closer to how HTTP works on the web.
MOQ:
- Is a simpler solution built with client server architecture from the beginning.
- The client-side is more broken up into manageable open standard components (WebTransport, MSE, etc.)
- MOQ has faster setup (time to first frame) due to not having the DTLS, ICE, etc. overhead.
- Very big companies are already behind it: Cloudflare, Akamai, Cisco, Youtube (Google), Meta, etc.
- It’s being developed as an open standard by the IETF.
- MOQ does video on demand, DVR style scrubbing, and handles media tracks in a nice way. By contrast, we at Red5 had to switch back and forth between HLS and WebRTC to accomplish this feature set. Does it work? Yes, but it’s a lot of overhead to maintain to get it done.
- The distribution costs only get lower over time, but with larger CDNs involved, cost reductions will likely be faster.
Future of MOQ and WebRTC
In my opinion, MOQ and WebRTC will co-exist for quite some time. Will you typically use the two technologies together at the same time? More than likely not. Most use cases in live real-time video streaming I believe will be run on MOQ in the future. But we’re far from that in 2025.
Conclusion
In short, WebRTC remains the best choice for ultra-low latency browser-based streaming, while MOQ introduces a simpler, scalable approach built on QUIC for future real-time and hybrid use cases. Together, they represent the next stage in live streaming technology, and Red5 will support both by the end of 2025.
MOQ might be today’s “flavor-of-the-month”, but things evolve, and down the road, there will be a new flavor. Then the argument between MOQ and the newer protocol will be similar to what’s being argued here between MOQ and WebRTC.
Top comments (0)