Article Preview
TopIntroduction
Popularity of mobile technologies such as smartphones and tablets has encouraged competition amongst the video conferencing system researchers and developers to enhance the Real-Time Communication (RTC) technology as well as to implement various applications based on RTC. Accessibility and mobility of multimedia and video conferencing applications has also motivated the creation of browser-to-browser video conferencing technologies that can compete with the current standalone video conferencing applications (Alonso, Geiger, & Jorda, 2004; Xu et al., 2012). In 2012, Web Real-Time Communication (WebRTC) was proposed with the aim to implement RTC into web browsers, enabling audiovisual calls between two or more end users with no need to install third party plug-ins or specific applications. Real-Time Communication on the Web (RTCWeb) is an open source project of the Internet Engineering Task Force (IETF) and the World Wide Web Consortium (W3C) team that aims to standardize protocols and infrastructures for WebRTC (2016). Web developers can add WebRTC features to their browsers using standard Hyper Text Markup Language (HTML5) with simple Javascript APIs (Johnston & Burnett, 2014). Therefore, it allows any web browser running on any operating system and any device to connect seamlessly with any other web browser running on any operating system and any device via the internet and communicate in real-time, as long as both web browsers support WebRTC. WebRTC is open source, and it is currently implemented in three browsers: Google Chrome, Firefox, and Opera (WebRTC, 2016).
Like any other RTC application, WebRTC has to deal with the quality from two different perspectives – user and network. From the user’s perspective, services such audio-video streams have to be provided with less packet loss and delays, along with a high incoming rate and quality. From the network perspective, WebRTC has to have a mechanism that can deal with bottleneck problems and congestion to produce acceptable performance during a video session. Therefore, the IETF and W3C working groups proposed a congestion control mechanism, called Google Congestion Control (GCC) algorithm, for WebRTC to satisfy the quality requirements for real-time applications (Lundin et al. 2015). GCC has two main controllers: Receiver-side controller and Sender-side controller, as shown in Figure 1 (De Cicco, Carlucci, & Mascolo 2013a; Carlucci, De Cicco, & Mascolo, 2014; De Cicco, Carlucci, & Mascolo, 2013b). The Receiver-side controller computes the next expected receiving rate Ar. It is composed of five main components: Arrival-time filter (estimates the queuing time variation T), Remote rate region (computes the threshold γ), Overuse detector (produces appropriate signal, overuse/underuse/normal, based on T and γ), Remote rate controller (estimates the next expected receiving rate Ar), and Receiver Estimated Max Bitrate (REMB) message processing unit (notifies sender with the next expected receiving rate). The Sender-side controller consists of two main components: TCP-Friendly Rate Control (TFRC) bandwidth estimation, and Sending Rate Controller. According to De Cicco, Carlucci, and Mascolo (2013b), sender-side controller is a loss-based congestion control algorithm which computes the target sending bitrate As.
Figure 1. GCC Receiver-side and Sender-side components