WHIP, WHEP, and Media Over QUIC are protocols that can significantly impact the efficiency, reliability, and quality of real-time communication and live streaming services. These protocols are not just buzzwords; they represent significant advancements in how we handle, deliver, and experience live media content.
WHIP (WebRTC-HTTP Ingestion Protocol) and WHEP (WebRTC-HTTP Egress Protocol) are primarily focused on standardizing the ingestion and egress of WebRTC streams using HTTP. Traditionally, the process of bringing WebRTC streams into media servers lacked standardized protocols, which led to integration challenges and interoperability issues.
Media Over QUIC is focused on optimizing the transport layer for media delivery, using the QUIC protocol to improve performance, reliability, and security.
Let’s dive into what these protocols are, why they matter now, and whether they are ‘ready for prime time’.
WHIP
WHIP offers a standardized approach to ingesting WebRTC streams into media servers. Traditionally, this process involved various proprietary protocols, making system integration complex and challenging. WHIP simplifies this by providing a uniform, HTTP-based method, facilitating easier integration of WebRTC streams with media servers.
By leveraging HTTP for ingestion, WHIP capitalizes on the existing web infrastructure. This means that the same tools and techniques used for managing web traffic can now be applied to WebRTC streams, significantly simplifying deployment and management.
Moreover, WHIP promotes interoperability by providing a standardized protocol. This allows different media servers and streaming platforms to work together more seamlessly, reducing the need for custom integration work and fostering a more flexible and cohesive live streaming ecosystem.
Having a standard protocol for ingestion of WebRTC streams is a big help for incorporating WebRTC conversations into non-browser tools and traditional broadcasting tools like OBS.
A detailed outline of the WHIP protocol is available in a draft on the IETF site.
WHEP
WHEP standardizes the method for egressing WebRTC streams from media servers to clients. Traditionally, various custom protocols were used for delivering streams to end users, but WHEP offers a consistent approach, simplifying this process.
Like WHIP, WHEP uses HTTP, making the integration of WebRTC streams with client applications more straightforward. Developers can utilize familiar web technologies to handle WebRTC streams, reducing the learning curve and accelerating development.
Furthermore, by standardizing the egress process, WHEP optimizes the performance and reliability of WebRTC streams. Using HTTP for egress allows for better management and scaling with existing web infrastructure, resulting in more efficient streaming.
A detailed outline of the WHEP protocol is available in a draft on the IETF site.
Media Over QUIC (MOQ)
The protocol at the heart of Media Over QUIC is QUIC (Quick UDP Internet Connections), developed by Google. QUIC is built on the foundation of UDP but incorporates essential features of TCP, such as connection establishment and flow control. This hybrid approach leverages the strengths of both UDP and TCP to facilitate effective media transport.
One of the primary advantages of QUIC is its ability to speed up connection establishment times, leading to quicker media delivery. QUIC also excels in variable network conditions, providing improved resilience to packet loss and network congestion.
IETF | What’s the deal with Media Over QUIC?
Are These Protocols Ready for Prime Time?
WHIP and WHEP
While WHIP and WHEP are still evolving, they are considered ready for prime time in many applications. They are being adopted by various media servers and platforms, and there is significant industry support. Major players in the WebRTC ecosystem are adopting these protocols.
WHIP and WHEP are particularly suitable for environments where ease of integration, standardization, and leveraging existing HTTP infrastructure are important. They have proven effective in diverse use cases, from live streaming to real-time communication applications.
On episode 92 of WebRTC Live, guest Sean DuBois weighed in on scaling WHIP and WHEP, commenting that it is remarkably straightforward due to their reliance on HTTP. He explains, “As far as scaling WHIP and WHEP, I find it really, really easy because it reuses HTTP where if you’re defining a new protocol, there’s all these things you don’t anticipate, or you don’t realize, and because WHIP and WHEP is using HTTP, I can reuse all of these nice things that already exist. I think that’s kind of the superpower here that I can add arbitrary HTTP headers. I can do redirects. We’ve had like 30 years now of prior art on how we scale HTTP services, that makes it super easy. It’s not a new protocol. So that’s the superpower here.”
On episode 90 of WebRTC Live, Dan Jenkins said that WHEP is behind WHIP in terms of adoption and that WHEP’s delay is mainly because of congestion, not technical problems. Dan explains the key reasons (paraphrased), “We all appreciate WebRTC, but many in the broadcast industry find it problematic due to its tendency to degrade media quality and drop packets, which isn’t ideal for broadcasting. I think the development of WHIP and WHEP involved several factors: A) They were initiated at different times. B) The focus was initially on perfecting WHIP before moving on to WHEP. C) Most importantly, there was a concern about whether tools like OBS, GStreamer, and FFmpeg would support WHIP. If these key players didn’t get behind it, the effort would have been largely futile.”
Media Over QUIC
Media Over QUIC has demonstrated significant improvements in latency, connection establishment times, and reliability. QUIC has already been adopted by major tech companies, including Google and Facebook, for various applications. And it is also the foundation of the new HTTP/3, the third major version of the Hypertext Transfer Protocol used to exchange information on the World Wide Web. The extension of QUIC to media transport through Media Over QUIC is a natural progression, and its adoption is growing in the media streaming industry.
Media Over QUIC will be ideal for applications requiring high performance, low latency, and reliable media delivery. It is particularly well-suited for large video conferences and live streaming, but in general, for many scenarios where network conditions can be variable and unpredictable.
On episode 93 of WebRTC Live in July, guest Chad Hart said that both Media over QUIC and WebRTC serve critical roles in modern communication, but WebRTC is much easier to use for standard communication needs like video calls. As paraphrased here, “I think part of the idea is that media over QUIC operates at a much lower level. While WebRTC is a relatively complex web API, it might be easier for many tasks compared to media over QUIC. Depending on the use case, replicating what we’re doing today with media over QUIC could require a significant amount of work and might not be worth the effort in the end.”
What does the future hold for WebRTC technology?
Back to episode 90, Dan Jenkins shared his thoughts (and fears) on the future of WebRTC, as paraphrased here: “My biggest concern is that WebRTC won’t disappear, but as media over QUIC, WebTransport, and WebCodec gain traction, major players like Google, Microsoft, and Cisco, who collaborated to create WebRTC, might lose interest. They have felt restricted by WebRTC and had to make compromises, but with media over QUIC, they have the opportunity to innovate without those limitations. This could lead to a shift in focus from WebRTC to media over QUIC and QUIC in general. The next two or three years will be crucial in determining the future of these technologies.”
At WebRTC.ventures, we understand that WebRTC is not a one-size-fits-all solution. Fortunately, emerging trends and technologies are bridging the gaps. As longtime experts in the field, we stay up-to-date with these advancements and can guide you in making informed decisions. Contact us to build the best real-time communication solution for your project!