Live-streaming is simple. All you do is push a button and it publishes a stream and then you push another button to subscribe. Done. Easy, right?
The reality is much more complicated. There are all sorts of requests and connections being made. The broadcaster needs an IP address to publish to and the subscriber needs to know that same address in order to view the stream. Provisions are made for multiple connections, bad connections, secure connections; not to mention the transfer of data.
In the strictest of scientific terms, a whole lot of stuff is going on back there.
Let's just start from the top.
Upon initiation, a request is made to the stream manager. This request seeks to pair a unique stream id (called
streamName ) with an origin. The origin is what will ultimately allow the stream to be published.
The stream manager will look through its list of available origins and pick the one that is least used, or best for the intended region. It will return the IP address of that specific origin.
At this point, the process can differ depending upon the broadcasting device.
For a mobile device running a native app, the publisher will use RTSP, which just makes a direct connection to that IP and starts streaming. For browser publishers running RTMP, the process is the same where it will connect directly to the IP and start streaming.
##WebRTC However, browsers running WebRTC are much more complex. Due to CORS restrictions, it first has to establish a websocket connection. Of course, for security purposes, this has to be done over a secure websocket. 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 unsecure websocket to the IP address of the origin which starts the signaling process. Signaling involves sending ICE candidates back and forth between a client (in this case the web browser) and the origin itself proxying through that stream manager.
Once it establishes a way to connect over ICE, it will create a UDP channel to establish a connection. Usually, the channel is created directly with the origin itself. The secure connection allows the client and origin to perform a DTLS to exchange keys.
The key will then be used to encrypt the video and send it over SRTP. In this way, it is a direct connection between the origin and publisher client. Accordingly, the video will start streaming to that origin which will in turn relay that video to edges so the subscriber clients can start connecting to that stream.
Now that the connection has been made, the video file can be streamed over that connection. This involves another process involving video and audio capture, protocol encoding and server-side processing. This blog post outlines that in more detail.
Obviously, publishing is only half the story. Be on the lookout for Part II: Subscribing.