There exist two main functions of WebRTC operation on the server side in the field of streaming video: publishing and playing. In the case of publishing, the video stream is captured from the web camera and moves from the browser to the server. In the case of playing, the stream moves in the opposite direction, from the server to the browser, is decoded and played in the browser’s HTML5 <video> element on the device’s screen.
RTSP is a simple signaling protocol which they cannot replace with anything for many years already, and it has to be admitted that they don't try really hard.
For example, we have an IP camera that supports RTSP. Anyone who has ever tested the traffic with a Sharkwire cable will tell you that first there comes DESCRIBE, then PLAY, and then the traffic begins to pour directly via RTP or wrapped in the TCP channel for instance.
In the first part, we have deployed a simple dynamic CDN for broadcasting WebRTC streams to two continents and have proved on the example of a countdown timer that the latency in this type of CDN is actually low.
In the second part, we have incorporated dedicated servers into the CDN for performing the task of transcoding in order to provide good broadcast quality to our viewers based on the devices they use and the channel quality. In this manner, all published streams in our CDN are available to all the viewers.
Now, assume that a company is starting to introduce its monetization strategy where a number of streams should be available for free and the rest on a subscription basis. Or, for example, webinars for in-house staff training are broadcasted simultaneously, but each subsidiary has a separate stream, and disclosing the sales techniques used in Southeast Asia to the managers from CIS countries is undesirable.
In the first part we have deployed a simple dynamic CDN for broadcasting WebRTC streams to two continents and have proved on the example of a countdown timer that the latency in this kind of CDN is actually low.
However, besides low latency, it is important to provide good broadcast quality to users. After all, this is what they are paying for. In real life the channels between Edge servers and users can differ in bandwidth capacity and quality. For example, we are publishing a 720p stream at 2 Mbps, the user is playing it on an Android phone using 3G connection in an unstable signal reception area and the 360p maximum resolution that provides smooth picture at 400 Mbps is 360p.
Having analyzed earlier the capacity of standard server configurations in Digital Ocean in terms of WebRTC streaming, we have noticed that one server can cover up to 2000 viewers. In real life, cases when one server is insufficient are not uncommon.
Assume gambling amateurs in Germany are watching real-time horse races in Australia. Given that horse races are not only a sports game but also imply big gains on condition that field bets are made at the right time, the video has to be delivered with lowest possible latency.
Another example: A global corporation, one of FCMG market leaders with subsidiaries in Europe, Russia and Southeast Asia, is organizing sales manager training webinars with live streaming from the headquarters in the Mediterranean. The viewers must be able to see and hear the presenter in real time.
