WHIP Endpoint Library now supporting an origin and edge SFU topology
Our open source WHIP Endpoint library from version 1.0 now supports a configuration of multiple WebRTC media servers in an SFU topology where you have an origin media server and one or many edge media servers in the edges. In this blog post we will walk you through this SFU-topology setup based on new and existing standards to achieve a standardized WebRTC based one-to-many (broadcast) video distribution.
First, a short recap of what WHIP is. WebRTC HTTP Ingestion Protocol (WHIP) is a standard based on HTTP for how WebRTC signaling between a producer and a consumer is handled. A protocol to handshake and exchange the SDP between these two peers. This standard makes it possible to have a standardized way of ingesting video over WebRTC to a media server or (in this case) a topology of media servers.
Similar, on the egress and playback side a standard is necessary for the SDP handshake and here we have today two standard proposals: WebRTC HTTP Playback Protocol (WHPP) and WebRTC HTTP Egress Protocol (WHEP). Both quite similar but have some differences and there are discussions on how this could potentially be aligned. Nevertheless, in this blog post we will be using WHPP as the playback protocol and the set of components and libraries around it that exists at the time of writing this post.
The principle in this setup is that we will be using one WebRTC media server as the “origin” which in turn will relay and forward all the media to other WebRTC media servers acting as “edges”. The players will establish a connection with these edge media servers and where media will be streamed from. This topology makes it possible to scale up to a larger number of viewers. In this example we will be using the Symphony Media Bridge open-source media server as origin and edge servers.
Origin and Single Edge
We can start with a simpler setup where we have one origin and one single edge as the diagram below shows.
Based on the whip-endpoint NPM library we will setup a WHIP endpoint that can be reached on port 8000.
First, we create an endpoint server object where we specify port, hostname and that we will be using the SFU broadcaster plugin. Currently this SFU broadcaster plugin supports Symphony Media Bridge, but other media servers could be added later if requested. Then we specify the management API url to the SFU. This is necessary to control the media server and setup the necessary resources. Lastly, we register a client where we specify the egress endpoint and the management API url for the edge SFU.
On the egress side we are using the wrtc-egress NPM library that we have setup with this code.
Once the above code is running you point your WHIP client to the URL http://my-whip-origin:8000/api/v2/whip/sfu-broadcaster?channelId=mychannel and, in this case, your WHPP player to http://my-egress-endpoint:8001/whpp/channel/mychannel
If you don’t have a WHIP client at hand you can use the web client we have online at https://web.whip.eyevinn.technology/
Origin and Multiple Edges
For a setup with one origin and multiple edges as illustrated below you need to slightly modify your WHIP endpoint service.
In addition to setting up additional media servers and egress endpoints we just need to add an additional broadcaster client.
As shown by this example there are building blocks that are open source available that you can use to build a scalable WebRTC based broadcast distribution with a standardized way of ingesting and consuming media. At the moment these blocks support a specific media server and the egress endpoint only WHPP, however if you want help in extending the WHIP endpoint library to support other media servers or want WHEP added to the egress endpoint just drop an email to us at firstname.lastname@example.org. Or you can do it yourself and contribute back to these projects. It’s open source!
On this subject: