1. Who needs server-side WebRTC?
As we all know, WebRTC is a peer-to-peer technology that implements a communication channel between two browsers for transferring audio, video and any other data with low latency. The technology is completely free, and if your application needs to establish communication in browsers for two remote participants, then you can add the appropriate javascript code to the web pages and the problem is solved. Browsers will communicate directly, no server is required.
Server-side WebRTC enters the scene when it is necessary that there are more than two participants, and data from one participant is transmitted to several other participants at once.
In this case, one of the participants can be the server, which will establish one-on-one communication with the first participant, receive data from him, then establish communication, also in
one-on-one mode with other participants and send them this data. Those. the server holds many peer-to-peer communication channels and simply copies data to all these channels. In WebRTC terminology, such a server serves as a Selective Forwarding Unit (SFU).
However, group communication is not only possible with the SFU. You may ask why everyone can’t send data to everyone, without any server, and you’ll be absolutely right. This is called MESH - communication.
There are two key points here:
- In the MESH scheme, each participant sends and receives N-1 data streams, where N is the group size. Those. upload speed requirements for each participant in the MESH scheme increase with the growth of the group. Whereas in the SFU scheme, each participant always sends only one stream. Not every participant has a network connection speed that can handle sending N-1 streams.
- , MESH - . , , - . MESH , , VP8/VP9/H264 4 . WebRTC – , . , (PeerConnection). , 720p 30% , . .
Because of these two key points, the MESH scheme becomes poorly implemented with an increasing number of participants and the SFU scheme has to be used.
So, with a large number of communication participants, a server (SFU) is required.
Let's give examples of such applications where a server is needed:
- Video conferences with many participants (everyone's beloved Zoom uses the WebRTC server, like all similar services).
- Live video surveillance, when video is sent from one camera to multiple viewers and recording devices. Security systems, monitoring.
- Interactive systems such as: online auctions, educational and other web applications where low audio / video latency is required.
2. If you still need server-side WebRTC, what can you use in 2020?
Cloud service or on your own?
Here, at first, the usual IT arguments in favor of one or the other: the cloud will provide and save IT costs for servers, configuration, scalability. But on your own, if everything works out (there is no guarantee), it will be much cheaper. After all, you need to pay monthly for a cloud service.
Now for the arguments specific to the applications described above. If you have a global, huge audience, in different countries and regions, then on your own it will be difficult for you to put everything together. For example, a cloud service is suitable for a Sotheby's auction. But if you have 2-3 company branches in different cities, 200-500 users, and you need to organize a webinar / conference / training, etc. for them, then you can rent several servers yourself on AWS or similar hosting platforms, install there software WebRTC server, and everything will work out. Servers can even be in your company, if the speed of the Internet connection allows. Well, for all solutions of a smaller scale, everything can be done on your own.
At the moment, two cloud WebRTC services are well known and tested: Millicast and Phenix... Both have global coverage, good connectivity between servers on different continents (do you need it?) And indeed video latency (latency) at half a second or less.
Now let's talk about “on our own”.
You will need the WebRTC server software here. There are 3 ways to get such a server.
- Make it yourself using an open API. The most famous of these is the Google c ++ WebRTC API . You can also use the GStreamer API . An interesting implementation in Go: Pion WebRTC . You will need skilled c ++ programmers and a lot of patience and time to debug. I wrote in detail about the difficulties of this approach in my previous article .
- . Ant Media Server, Kurento, Janus, Jitsi. , , , . github , . , , , . , c++ . . , .
- . , , . Red5 Pro, Flashphoner Unreal Media Server.
WebRTC .
This is the most problematic topic. Suppose your company is releasing a software product in which you need to implement a WebRTC server. Let it be a video recording and surveillance system for airport terminals, railway stations, transport hubs. Or medical equipment with existing accompanying software for broadcasting and recording video from endoscopes, which needs to be expanded before broadcasting this video to a browser. Or a flight simulation system, in which it is necessary to implement the possibility of visualization in a browser and / or interaction with a remote user. We are constantly faced with similar requirements. Your existing system has many limitations. Internet access may not be available. No clouds. You cannot open ports on the server. Windows only or Linux only. Sometimes even only a certain version of Windows, because the existing product is sharpened for it. WebRTC server,what is added to such a system must be adjusted to all these restrictions.
Here, you may have no choice but to take an open source server like Ant Media Server or Janus and change it. This is the situation on Linux. For Windows, Unreal Media Server is suitable - this is software written and optimized only for Windows OS.
WebRTC server is very resource-intensive
Keep this in mind when planning your resources. The reasons for such resource-intensiveness are described by me in a previous article , but the conclusion is that scalability is achieved by a very strong processor or by adding physical servers.
Here is a diagram of tests performed with Unreal Media Server v13.0 on AWS EC2 m4.2xlarge instance: Intel Xeon 8 cores CPU E5-2686 v4 @ 2.30 GHz, 32 Gb RAM, Windows Server 2016.
As you can see from the diagram, with 1000 simultaneous web players for this IP camera , the processor load is 5% with the RTMP protocol, and 75% with the WebRTC protocol, i.e. WebRTC is more than 10 times more resource-intensive than RTMP.