1
1 Comment

MOQ vs WebRTC: Why Both Protocols Can And Should Exist In Live Streaming Space In 2025

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

MOQ vs WebRTC protocol comparison table

MOQ vs WebRTC comparison table

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\.

What This Means for Red5 Users

If you’ve not already guessed, we at Red5 are already adding the MOQ protocol to both Red5 Cloud and Red5 Pro, with a release set by the end of 2025\. We started with RTMP in the Flash days and now support RTSP, SRT, HLS, Zixi, and more. We recommend the protocols that best fit our customers’ use cases and requirements. MOQ is the next step in that evolution.

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.

on December 12, 2025
  1. 1

    Interesting comparison — WebRTC and MOQ are often framed as alternatives, but in practice they serve different bottlenecks. WebRTC’s strength is in real-time bidirectional media + NAT traversal and large-mesh optimizations (with SFU/MCU patterns), whereas MOQ’s value tends to be in efficient multicast distribution with minimal state for large audiences.

    For many dev use cases, the choice isn’t just latency vs throughput — it’s predictability under load, peer count, transport cost, and failure handling.

    Curious — in your view, which operational signal most clearly distinguishes when WebRTC is the right fit vs when MOQ shines (e.g., peer count thresholds, server cost per stream, or end-to-end latency under load)? That usually tells engineers where to draw the line.