A comparative study of RTC applications

Abstract

Real-Time Communication (RTC) applications have become ubiquitous and are nowadays fundamental for people to communicate with friends and relatives, as well as for enterprises to allow remote working and save travel costs. Countless competing platforms differ in the ease of use, features they implement, supported user equipment and targeted audience (consumer of business). However, there is no standard protocol or interoperability mechanism. This picture complicates the traffic management, making it hard to isolate RTC traffic for prioritization or obstruction. Moreover, undocumented operation could result in the traffic being blocked at firewalls or middleboxes.In this paper, we analyze 13 popular RTC applications, from widespread consumer apps, like Skype and Whatsapp, to business platforms dedicated to enterprises -Microsoft Teams and Webex Teams. We collect packet traces under different conditions and illustrate similarities and differences in their use of the network. We find that most applications employ the wellknown RTP protocol, but we observe a few cases of different (and even undocumented) approaches. The majority of applications allow peer-to-peer communication during calls with only two participants. Six of them send redundant data for Forward Error Correction or encode the user video at different bitrates. In addition, we notice that many of them are easy to identify by looking at the destination servers or the domain names resolved via DNS. The packet traces we collected, along with the metadata we extract, are made available to the community.

Measuring the Performance and Network Utilization of Popular Video Conferencing Applications

“…Investigating this asymmetry further, we discovered an interesting phenomenon: We found that Zoom uses a relay server instead of direct communication. Additionally, related work by Nistico et al [21] suggests that Zoom uses Forward Error Correction (FEC) for error recovery. This is further supported by a related patent from Zoom itself, which talks about a methodology to generate FEC data at the server [17].…”

“…Specifically, the network utilization with constrained downstream throughput (< 0.8 Mbps) is only 39-70% (Figure 1b), while it is more than 90% in the case of a constrained uplink (Figure 1a). Upon further exploration, we discovered that Meet also uses a relay server, as well as simulcast, wherein the sender (C2) transmits multiple copies of the video to the server, each at a different quality level [21]. The server then relays one of the quality streams to C1 depending on the inferred available capacity of the server-C1 link.…”

“…Closest to our work is work by Jansen et al [14] and Nistico et. al [21]. Jansen et al evaluate WebRTC performance using their custom VCA under controlled network conditions [14].…”

“…Even between tested VCAs using WebRTC, namely Meet and Teams-Chrome, we find significant performance differences, likely due to different design parameters (e.g., codecs, default bitrates). Nistico et al [21] consider a wider range of recent VCAs, focusing on their design differences including protocols and architecture. Our work provides a complimentary performance analysis for a subset of the VCAs studied by them.…”

A Network Analysis on Cloud Gaming: Stadia, GeForce Now and PSNow

“…Leveraging these data, we show which protocols that each application adopts for streaming multimedia content, the volume of traffic that they generate, and the servers and domains that they contact (for brevity, we use, throughout the paper, the term domain referring to the fully qualified domain name). We show that Stadia and GeForce Now adopt the standard real-time protocol (RTP) for streaming [3], largely adopted by real-time communication applications [4], while PS Now uses an undocumented protocol or encapsulation mechanism. Stadia and GeForce Now transmit video up to 45 Mbit/s, while PS Now does not exceed 13 Mbit/s.…”