Video-conference Communication Platform Based on WebRTC Online meetings Jelena Caiko Antons Patlins Institute of Electrical Engineering and Electronics, Institute of Electrical Engineering and Electronics, FEEE Riga Technical University FEEE Riga Technical University Riga, Latvia Riga, Latvia [email protected] [email protected] Arapov Nurlan Vladimir Protsenko LLP Granit LLP Granit Almaty, Kazakhstan Almaty, Kazakhstan [email protected] [email protected] Abstract— nowadays, due to the pandemic, many During the coronavirus (COVID-19) pandemic, many organizations have switched to remote work via video people work and hold meetings online. Many users have opted conferencing, but the complexity of organizing video for free video conferencing solutions like Zoom. conferencing arises due to the limited number of participants at the same time, as well as the need for large and fully equipped Experts criticize Zoom for weak privacy and continue to conference rooms. This may not be a problem for a large find vulnerabilities: connecting to someone else's enterprise, but for a small and medium-sized business, accessing conversations, transferring data from an iOS application to video conferencing facilities either requires extremely high rents Facebook, lack of end-to-end encryption, the ability to steal or is completely impossible. The goal of this article is to design Windows account password and gain full access to macOS. and implement an open source video conferencing prototype Jitsi that solves the meeting challenges. However, such services turned out to be susceptible to various vulnerabilities, for example, "zumba bombing". This is Keywords— video conferencing, VoIP, Jitsi, WebRTC, video, when an outsider connects to a web conference and interrupts audio communication. the meeting. Thus, it is still better to use a more secure and private video conferencing solution. The work of video communication in education, with distance learning via the I. INTRODUCTION Internet, has its own characteristics [17], [18]. The Video-based teleconferencing is a form of teleconferencing impossibility of the presenters to directly control the quality of done through mediums that support video and audio the channel's work among the listeners requires constant communication. It is a live video connection between people in monitoring and feedback on the quality of the video, problems separate locations for the purpose of communication or with [19], [20]. The created platform allows training in interaction [1]. videoconference mode [21], [2], [3]. Thus, it became necessary Videoconferencing - communication through electronic to find solutions to create a program that allows video communication, allowing you to hold business meetings, conferencing with data protection. seminars, conferences. This kind of communication saves time In our project we use Jitsi, which provides the necessary and money, which is relevant. software to create your own video conferencing service that Video conferencing has latency requirements of less than a can be deployed using a virtual server. second. Therefore, protocols must be able to support Jitsi is an open source program that allows you to secure negotiation of bit rates, codecs, broadcast methods. audio / video calls and conferences, streaming and desktop In browsers, the minimum latency is provided only by sharing, instant messaging, file transfer and many others. To Flash-based protocols, RTMP / RTSP, WebRTC and SDLP, use it, you do not need to register an account, and the program and only the latter two can work without plugins. In addition, itself works in a browser. WebRTC supports the P2P (peer-to peer) data transfer mode The need to use Jitsi is the ability to mix audio and make through intermediate TURN servers or directly within the same conference calls. That is how our conference functions were network, which theoretically makes it possible to dispense with first implemented. transcoding servers, save bandwidth of communication channels and unload central servers. II. AUDIO CONFERENCING Unfortunately, things are not so simple on the server side. Jitsi Meet, a full video conferencing application that The reason is that mixing video content requires huge includes a web, Android, and iOS clients. We operate Jitsi processing resources. Meet for communications of small groups 2-10 people. When mixing video content, you need to decode all We started with conferences, where small teams could get incoming frames (one for each participant), zoom out each of together and have discussions. We used and tested different them, create composite images, and then re-encode them. A SIP [5] and XMPP [6] servers. For the first implementation we typical non-HD image stream takes 25 frames per second and used Jitsi to be capable of mixing audio and hosting conference 25 downscaling, 25 compositions and 25 encodings. calls. Based on the above data, there is a problem with the audio Any user can "register" with one of these gateways, quality, which manifests itself in the fact that an echo will providing the information necessary to log on to the network, occur during audio broadcasting, and all users will see exactly and can communicate with network users as if they were users the same video stream with their own reflection. This situation of the network. This means that any client that fully supports is resolved by using separate mixes for each participant, XMPP can be used to access any network for which gateways although this exponentially increases the load in conferences exist, without any additional code in the client and without with mixed content. requiring the client to have direct Internet access (Fig.1). Today, video conferencing clients also send the same streams: video from a desktop or a webcam, but compared to the situation described above, instead of receiving one stream in return, they directly receive everyone else's packages the way they were sent. One of the technologies that allows the use of a simplified server is layer-by-layer video encoding on the terminal (Fig.2). Each layer increases the image resolution, so when transmitting video to another terminal, the server does not need to recode anything - it is enough to select so many layers so that the resolution matches the characteristics of this terminal and the communication channel with it. Fig. 2. Layer-by-layer video encoding on the terminal The terminal can also prepare full-fledged video streams Fig. 1. Ad hoc audio conferencing with Jitsi with different resolutions (for example, CIF, SD, HD ) (Fig.3). In this case, the server's task also boils down to selecting the The gateway implementation is specific to the XMPP required stream to be sent to another terminal. With these server and is subject to instability due to the closed nature of arrangements, the MCU server becomes, in effect, a video commercial IM services. stream router. When developing video conferencing, we created a convenient user interface that allows you to display the full list of video conference participants, and the ability for all participants to access audio activity. Extended RTP and XMPP were used to implement such options [7], [8], [9]. III. VIDEO CONFERENCING After implementing audio in Jitsi, we used video streams to implement video, allowing participants to see each other during calls and exchange slides or screens using Jitsi desktop sharing features. Using Jitsi makes it easy to mix audio and video on the client side. Fig. 3. Video Streaming Router The number of potential video conferencing terminals has gateway to broadcast video streams to video conference increased thanks to the development of WebRTC technology, participants) (Fig.5). which allows you to participate in video conferencing sessions from a browser without the need to install any additional We did the tests on Jitsi Meet on a dedicated server. The software or download a plug-in. server had all the services for Jitsi Meet: web server (nginx), XMPP server (prosody) and Jitsi Videobridge. It is especially important that the video conferencing server maintains effective quality of service (QoS) mechanisms, During testing, we found out the problem with the Jitsi including traffic prioritization, and the ability to operate on Videobridge, which is overloaded to send a large enough packet loss channels. amount of traffic. Using browsers to fill enough conferences will likely require hundreds or even thousands of computers. It is desirable that the server supports technology that allows to compensate for packet loss: up to 1% of packets To solve this problem, a full star topology was used to without noticeable degradation and up to 5% of packets create a conference. With this topology, inbound traffic from without critical degradation of image quality. With a further any endpoint is propagated to all other endpoints connected to deterioration in quality and / or a decrease in the bandwidth of Jitsi Videobridge. In this configuration, we have streams A * the communication channel, the most critical streams should be (A-1) leaving the video bridge (and arriving A-1). supported, primarily those that carry audio information. Even if the video disappears, voice can always convey the necessary information, so support for voice communication is the most critical. We are taking a more efficient approach. Instead of receiving packets from a single stream, they were sent directly as they were sent. Having received individual streams, user agents can display them in any way they want or their select users. The quality is better because video streams are encoded only once. There is no additional encoding, scaling, or decoding, resulting in stable latency. Mostly, video relaying requires hundreds of times less Fig.5. Conference call with Jitsi resources than mixing (Fig.4). If done correctly, the operation Jitsi Videobridge - is a component of the XMPP server, it can even be implemented in routers and more importantly. allows you to organize multi-user video communication. Its difference from expensive dedicated hardware video bridges is that it does not mix video channels into a composite video stream, but only relays the received video channels to all participants in the call.