View metadata, citation and similar papers at core.ac.uk brought to you by CORE provided by Archivio della ricerca - Università degli studi di Napoli Federico II Performance analysis of the Janus WebRTC gateway Alessandro Amirante Tobia Castaldi Simon Pietro Romano Lorenzo Miniero University of Napoli Federico II Meetecho s.r.l. Computer Engineering Department Via C. Poerio 89/a, Napoli, Italy Via Claudio 21, Napoli, Italy falex, tobia, [email protected] [email protected] Abstract tion, the Session Description Protocol (SDP) [7] is mandated for This paper takes an in-depth look at the performance of the Janus all compliant WebRTC implementations. WebRTC gateway. Janus is a modular, open-source gateway allow- The above mentioned scenario is the most straightforward one, ing WebRTC clients to seamlessly interact with legacy real-time since it envisages the presence of a browser talking directly to an- communication technologies, both standard and proprietary, and other browser. Indeed, the WebRTC APIs are designed around the with each other. This is achieved by attaching technology-specific one-to-one communication scenario, which represents the easiest plugins on top of a barebones core implementing all of the func- to manage and deploy. In such a scenario, the built-in audio and tions and protocols mandated by the RTCWEB/WebRTC specifi- video engines of the browser are responsible for optimizing the de- cation suites. The paper focuses on assessing the scalability of the livery of the media streams by adapting them to match the available Janus architecture, by selecting three representative use cases, fol- bandwidth and to fit the current network conditions. There are other lowed by a detailed analysis of a real-world scenario associated situations, though, where the one-to-one approach is not at all the with multi-point audio conferencing. best option. As an example, in a WebRTC conferencing scenario Categories and Subject Descriptors H.4.3 [Communica- (or N-way call), each browser has to receive and handle the media streams generated by the other N-1 browsers, as well as deliver its tions Applications]: Computer conferencing, teleconferenc- own generated media streams to N-1 browsers. In such a case, in ing, and videoconferencing fact, the application-level topology is a mesh network. While this is Keywords WebRTC, RTCWEB, gateway, MCU, SFU, SIP, per- a quite straightforward scenario, it is nonetheless difficult to man- formance. age for a browser and at the same time calls for increased network bandwidth availability. For these reasons, video conferencing sys- 1. Introduction tems usually rely upon a star topology where each peer connects to a dedicated server that is simultaneously responsible for: Web Real-Time Communication (WebRTC) is a new standard that lets browsers communicate in real time using a peer-to-peer archi- • negotiating parameters with every other peer in the network; tecture. It is about secure, consent-based, audio/video (and data) peer-to-peer communication between HTML5 browsers. This is a • controlling conferencing resources; disruptive evolution in the web applications world, since it enables, • multiplexing (or mixing) the individual streams; for the very first time, web developers to build real-time multimedia • applications with no need for proprietary plug-ins. distributing the proper (mix of) streams to each and every peer The most general WebRTC architectural model draws its inspi- participating in the conference. ration from the so-called SIP (Session Initiation Protocol) Trape- The WebRTC API does not provide any particular mechanism to zoid [8]. In the WebRTC Trapezoid model, both browsers are run- assist the conferencing scenario. The criteria and process to iden- ning a web application, which is downloaded from a different web tify the MCU are delegated to the application. However, this is a server. Signaling messages are used to set up and terminate com- big engineering challenge because it envisages the introduction of munications. They are transported by the HTTP or WebSocket pro- a centralized infrastructure in the WebRTC peer-to-peer communi- tocol via web servers that can modify, translate, or manage them as cation model. The upside of such a challenge clearly resides in the needed. It is worth noting that the signaling between browser and consideration that being capable of establishing a PeerConnection server is not standardized in WebRTC, as it is considered to be part with a proxy server adds the additional services provided by the of the application. As to the data path, a PeerConnection allows proxy server itself to the benefits offered by WebRTC. Among such media to flow directly between browsers without any intervening additional services, we cite the possibility of letting the proxy act servers. The two web servers can communicate using a standard as a bridge towards ‘legacy’ technologies (e.g., SIP, Flash, etc.). In signaling protocol such as SIP or Jingle [5]. Otherwise, they can such a case, the proxy acts as a gateway allowing for the seamless use a proprietary signaling protocol. For what concerns negotia- interaction among WebRTC clients on one side and non WebRTC- Permission to make digital or hard copies of all or part of this work for personal or enabled devices on the other. classroom use is granted without fee provided that copies are not made or distributed The authors of this paper have recently worked on a general pur- for profit or commercial advantage and that copies bear this notice and the full citation pose WebRTC gateway called Janus [1], whose main objective is on the first page. Copyrights for components of this work owned by others than ACM to make available a highly flexible architecture for the implemen- must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a tation of scenarios like those illustrated above. We herein present fee. Request permissions from [email protected]. the results of a thorough experimental campaign aimed at assessing AWeS ’15, April 21, 2015, Bordeaux, France the performance attainable by the gateway, in a number of different Copyright 2015 ACM 978-1-4503-3477-8/15/04. $15.00 configurations under varying load conditions. http://dx.doi.org/10.1145/2749215.2749223 The paper is organized in five sections. Sec. 2 presents an overview of the Janus modular architecture, composed of a We- bRTC core and a set of configurable plugins. In Sec. 3 we delve into the details of the aforementioned experimental campaign, by focusing on some of the most interesting plugins and hence analyz- ing a real-world audio-conferencing use case. A discussion about related work in the scientific research community are provided in Sec. 4. Sec. 5 concludes the paper and summarizes the most rele- vant directions of our future work. 2. Janus The Janus WebRTC Gateway has been conceived as a general pur- pose gateway. As such, it does not provide any functionality per se other than implementing the means to set up a WebRTC media Fig. 1: Janus modular architecture communication with a browser, exchanging JSON (JavaScript Ob- ject Notation) messages with it, and relaying RTP/RTCP messages between browsers and the server-side application logic they are at- In the following subsections, we introduce the Janus plugins that tached to. Any specific feature/application needs to be implemented have been the target of the performance analysis we conducted, in server-side plugins, that browsers can then contact via the gate- which is in turn presented in Sec. 3. way to take advantage of the functionality they provide. At the time of this writing, eight different plugins have been implemented and 2.1 The videoroom plugin publicly released as part of the project: This is a plugin implementing a videoconferencing Selective For- 1. an Echo Test plugin, that simply bounces back whatever it is warding Unit (SFU) for Janus. An SFU is capable of receiving mul- sent, together with some simple application logic to control the tiple media streams and then decide which of these media streams media (i.e., enable/disable audio or video, limit the bandwidth); should be sent to which participants. The plugin implements a vir- tual conferencing room peers can join and leave at any time. This 2. a Video Call plugin, that allows two peers to interact with each room is based on a Publish/Subscribe pattern. Each peer can pub- other with media relayed through the gateway, with the same lish her/his own live audio/video feeds: each feed becomes an avail- knobs provided by the Echo Test plugin to have control over able stream in the room the other participants can attach to. This the media transfer; means that this plugin allows the realization of several different 3. a Streaming plugin, that provides means for creating on- scenarios, ranging from a simple webinar (one speaker, several lis- demand and live WebRTC streams out of local files or media teners) to a fully meshed video conference (each peer sending and provided by third-party tools (e.g., FFmpeg or GStreamer); receiving to and from all the others). 4. a SIP Gateway plugin, that allows for a simple interaction For what concerns the subscriber side, there are two different with existing SIP infrastructures, hiding most of the complexity ways to attach to a publisher’s feed: a generic ‘listener’, which can associated with them; attach to a single feed, and a more complex ‘Multiplexed listener’, which instead can attach to more feeds using the same PeerConnec- 5. an Audio Bridge plugin, that allows multiple WebRTC partic- tion. The generic ‘listener’ is the default, which means that if you ipants to join an Opus-based mixed audio room, and have the want to watch more feeds at the same time, you will need to cre- conference call recorded; ate multiple ‘listeners’ to attach to any of them.