WHIP & WHPP for WebRTC based broadcast streaming
At Streaming Tech Sweden in June 2022 we presented our proof-of-concept and the work we do in the area of WebRTC based broadcast streaming. The purpose of this proof-of-concept was to explore whether it was possible for a WebRTC based distribution in a standardized way. In a similar way how it works for HTTP based streaming where RTMP is the main protocol for ingesting to the distribution network and HTTP based streaming protocols such as HLS and MPEG-DASH for the consumption of the stream.
For consumption and playback we developed and proposed a standard similar to WHIP but for playback that we named WebRTC HTTP Playback Protocol, or WHPP for short, and presented at the Streaming Tech Sweden conference in June. We believe that by having a standard ingest protocol and consumption protocol we can separate the distribution part from the producing and consumption part. This allows vendors in the distribution field to focus on the infrastructure and scaling, and vendors on the consumption side can focus on everything around the end-user device and user experience.
The playback client initiates the session by sending a POST request to the server endpoint. The server responds with an SDP offer. The intent of this protocol (and WHIP) is to make session setup as simple as possible with a single SDP exchange over HTTP. All media streams have to be announced in the SDP and only the server knows which media streams will be sent. Therefore the server is always the one sending the SDP offer, and the playback client the one sending the SDP answer.
Our current implementation that uses an MCU developed in Node JS in the middle does not scale that well, so the next step in our proof-of-concept is to explore how we can build a more scalable infrastructure with WHIP for ingest and WHPP for playback. Instead of using an MCU we replace it with a Selective Forwarding Unit (SFU). In our proof-of-concept we are using Symphony Media Bridge as SFU which is available under the Apache 2.0 open source license.
When a WHIP client initiates a session using WHIP our WHIP endpoint initiates and allocates necessary resources in the SFU. In the SDP answer that is sent back to the WHIP client everything is included to setup a SRTP audio/video stream from the client device to the SFU. And similar when a WHPP player wants to consume a video stream the WHPP endpoint includes in the SDP offer to the player the information needed to establish an audio / video stream from the SFU to the player device.
On the playback side we developed a WebRTC based player library that is designed to be media server independent. Independent in the way that you can add adapters (plugins) for various types of WebRTC media servers for the SDP transportation. We have added an adapter that uses WHPP as protocol and our WHPP endpoint to establish a connection with the SFU network in this case. As part of this proof-of-concept we included this library in our HTML5 web player to add support for WebRTC based playback with WHPP.
Summary and next steps
All software developed in the scope of this proof-of-concept is available as open source and the next step is to take this WHIP/SFU/WHPP concept and run on a real distribution infrastructure. A WebRTC based CDN with a standard interface in and a standard interface out.