In the previous article, we discussed WebRTC and the new standard developed to help us ingest data with it, known as WHIP. However, for data that is ingested, that same data will likely need to be egressed, or distributed at some point. Bring in WebRTC-HTTP egress protocol, or WHEP. Abstractly, the ingestion is the part that covers the uploading of data to a server, and the egress handles the downloading to an end user. The benefits we gained from WHIP, such as the low latency and end-to-end encryption apply here as well: WHEP enables WebRTC communication on the other end of the content delivery pipeline; WHEP assists with serving content to the viewer.
In this post, we will take a look at WHEP, an IETF protocol developed to let us use WebRTC to egress content to other destinations as a way to modernize content delivery over the web from previous standards.
Why is WHEP useful?
As mentioned above, WHIP only solves half of the equation when working with WebRTC-based content delivery. While you could read the official IETF documentation, we will summarize it more simply here. WHEP aims to solve the distribution aspect of WebRTC-based content, See the below diagram for a visual aid of how this works together using Dolby.io Real Time Streaming APIs as an example:
The benefit of having WHEP supplement the egress of broadcast WebRTC infrastructure is similar to the benefits of WHIP, namely the standardization. The same way WHIP allows broadcasters to focus on their infrastructure and the scaling of it without needing to worry about logistics, WHEP allows the distributors to focus on end-user experience, as they know exactly how the data will be received and handled. The end goal is optimization of time and resources across all parties with standardization.
WHIP and WHEP do for real-time video what RTMP did for flash video or what SRT does for transport streams. It standardizes the way (protocol) that the media servers speak to each other, like a language, so that any WHIP encoder can talk to any WHIP server and any WHEP service can talk to any WHEP player, without any other setup. Using the WHIP/WHEP URL should simply work no matter which environment is being used.
There are many situations where a standard protocol for streaming media consumption over WebRTC would be helpful. Some options or examples include:
- Interoperability between WebRTC services, media servers, publishers, and players
- Playing WebRTC streams on TVs and other smart devices that do not support custom JavaScript scripts
- Creating modular, reusable software for media players
- Integrating with DASH, a current popular standard for adaptive bitrate streaming
Where it differs from just being “the WHIP spec but in reverse” is in the specifics of the protocol. While for the most part it does behave the same as WHIP, using HTTP requests with Bearer Tokens for authentication, it is more flexible with SDP communication. WHEP allows for an SDP offer to be delivered immediately in the same HTTP request, or to send a POST request with intent to receive an offer back. This offers more flexibility depending on use case and environment, which can be learned more about in the white paper provided above. RTSP, an older standard used in the industry, does not support this model for example.
Dolby.io + WHEP
Dolby.io is a leader in the definition and research of WHEP, which is an open standard. Like WHIP, our researchers have developed this standard, offer support for it into our Streaming Platform, and are working directly with software and hardware partners to integrate WHEP directly into their ecosystems. To learn more, see this Kranky Geek recording of Dolby.io Senior Director of Engineering Sergio Garcia Murillo, the head researcher working on developing WHIP and WHEP:
We believe WHEP is the future of WebRTC egress, and we want to support the community and projects around it. WHEP is only useful if it gains wide adoption. We encourage you to try out WHEP for your next streaming project and let us know your experience. One way to do this is with our sample app using Node, our sample using Video.js, or using another community implementation such as this one by Lorenzo Miniero. We’d love to hear your thoughts on our Twitter or LinkedIn.
