WebRTC Broadcast

WebRTC is fun! I recently gave a quick session on WebRTC at Bangalore Ruby User Group (BRUG). Following are the slides of my presentation.

For demo I had recently created a demo application in elixir using the phoenix framework because it makes dealing with websockets really easy. That is used for creating the custom signaling service that is required to facilitate such a broadcast. The source code is available at dhruvasagar/webrtc-broadcast

In a nutshell for the purpose of a demo, what I essentially do is that each Host(1) (1)Who accesses the home page at / sends out a stream-ready event notifying that it’s stream is ready to be shared and that is then communicated to all other hosts. This then lets them initiate the basic WebRTC signaling that’s required for them to know about each others' audio / video capabilities by means of the offer / answer mechanism. Once that is complete, they finally receive each others’ streams and that is then added onto their views dynamically.

For listeners(2) (2)Who simply receive the streams, and are not required to share their streams, access the site at /radio , they initiate the process by sending out a stream-request event, which the signaling server then passes forward to all hosts. Once the hosts receive the stream-request event they follow that by initiating the WebRTC signaling process for communicating their streams with the listeners(3) (3)by means of offer / answer . Once the communication is established the listeners then receive the streams of all the hosts and add those dynamically to their view.

I wanted to demonstrate that once you understand the process of facilitating an offer / answer to establish the initial connection between two peers using RTCPeerConnection, rest of signaling can then be customised as per situation to facilitate any kind of complex multi peer-peer communication.

NOTE: In this demo, a broadcast implies that each host shares his stream directly with each listener. So as the number of listeners (or hosts) grow, the number of peer connections required also grows rapidly. From the perspective of achieving a scalable broadcast service (peer-peer), it may instead be better to utilise each listener to also act as a proxy host, allowing for him to be able to share the stream of other hosts to other listeners, reducing the overhead on the hosts and also reducing their bandwidth requirements.