When considering which tool to use for your real-time streaming platform, WebRTC is one of the hot concepts brought into the forefront. While WebRTC has been around since 2011 and has since been successful at being used in many scenarios, optimizing WebRTC for live generated content, such as in the broadcasting industry, as opposed to pre-existing files is where things get more complex. WHIP and WHEP are two new standards designed to assist in ingesting and egressing this media into WebRTC instead of having to rely on using older standards like RTMP to do that.

In this post, we will focus on WHIP, or WebRTC-HTTP ingestion protocol, an IETF protocol developed to let us use WebRTC to ingest content into our platforms over these old protocols.

Why WHIP?

For those of you who are overwhelmed with the official IETF document, WHIP (sometimes known as WISH) is an open standard that you can use right now for your WebRTC based ingestion. You can use it today with open source software such as GStreamer or OBS (fork) as a way to publish your content with WebRTC.

A benefit to using WebRTC based content is it’s extremely low latency and security with end-to-end encryption. However, initial versions of WebRTC based streaming were associated with poor quality and limited viewer numbers. WHIP solves this by removing the translation layers needed to use WebRTC before that cause many of the previously mentioned flaws, giving us all of the benefits of WebRTC without the downsides. WHIP provides a standard signaling protocol for WebRTC to make it easy to support and integrate into software and hardware.

WHIP provides support for important standards, such as HTTP POST based requests for SDP O/A, HTTP redirections for load balancing, and authentication and authorization done by the Auth HTTP header and Bearer Tokens.

Think of this like a train station. Without any rail signalers, the trains will behave sporadically, causing potential slowdowns if too many trains are on the same track, tracks that are unused, and possible crashes and collisions. With a signaler, the trains will be directed more orderly, optimizing the system to keep things moving quickly and efficiently. WHIP acts as this signaler, handling things like creating or deleting endpoints if needed and performing operations like Trickle ICE.

How Does Dolby.io fit in?
As mentioned before, WHIP is an open standard. Dolby.io supports WHIP not only by providing integrations, but also by leading the definition and research into the standard. Our researchers have developed this standard, and our engineers have implemented it into our Streaming Platform, as well as having worked directly with software and hardware partners to integrate this standard directly into their platforms, such as FlowCaster and Osprey for both software and hardware encoding.

We believe WHIP is the future of WebRTC ingestion, and we want to support the development and community around it. As a standard is nothing without wide adoption. We encourage you to try our WHIP today with one of the priorly mentioned integrations for your next streaming project and let us know your experience. We’d love to hear your thoughts on our Twitter or LinkedIn. Or try out our sample app using Node, and leave some feedback on GitHub.

Stay tuned for Part 2 where we will talk about the other end of the process, WHEP, or WebRTC-HTTP egress protocol, and see how WebRTC will define the future of all streaming and broadcasting communications.