6 Steps to Watch a Live Stream

In Part I of our “How Live-Streaming Works” series, we covered how live-stream broadcasting works. Logically, we will move to how subscribing works for this post. For those that haven’t read Part I, you may want to check that out.

Subscribing

In order to view the live stream, the subscriber will connect to the broadcasting stream in a similar manner to how the broadcaster established a connection. However, where the broadcaster connects to an origin server, the subscriber connects to an edge server.

The subscriber makes a call to the stream manager to get an edge for a particular stream. Once the stream manager is sent the requested stream name, it will return the IP address of the best available edge.

For a mobile device running a native app, the publisher will use RTSP, which just makes a direct connection to that IP to view the stream. For browser subscribers running RTMP, the process is the same where it will connect directly to the IP.

WebRTC

However, browsers running WebRTC are much more complex. Again, this has already been covered in Part I, but we shall repeat it here.

Due to CORS restrictions, it first has to establish a WebSocket connection. Of course, for security purposes, this needs to be done over a secure WebSocket. It’s possible to subscribe using only an unsecure connection, but only if you serve your site from the same server and don’t use HTTPS. Once you implement HTTPS then everything needs to be secure. That involves proxying through the stream manager with a secure WebSocket call in order to pass through the desired IP address requested for the connection. Creating that socket requires a few steps.

On the back-end, the stream manager makes a connection over an unsecured WebSocket to the IP address of the edge which starts the signaling process. Signaling involves sending ICE candidates back and forth between a client (in this case the web browser) and the edge itself proxying through that stream manager.

Once ICE is completed, it will create a UDP channel to establish a connection. Usually, the channel is created directly with the edge itself.

The secure connection allows the client and edge to perform a DTLS to exchange keys which will be used to decode the video in order to view it.

At this point, you are receiving video over SRTP on the client and then the client is rendering it for display. Since the broadcaster has already encoded and transmitted the video, and the origin has already performed any addition transcoding/muxing, the subscribing client does not have all that overhead. Since edge servers are directly supporting only subscribing clients, they can normally handle a larger number of connections than origins.

Still confused? Want to know more? Give us a call and we can go over everything, or send a message to info@red5.net.