Abstract

Due to the recent shift toward cloud based computing, some of the world's leading standardization bodies have combined forces to provide guidelines and standards for native implementation of RealTime Communication (RTC) in the browsers. The World Wide Web Consortium (W3C) works on WebRTC APIs [1], while the Internet Engineering Task Force (IETF) is concerned with underlying standards [2]. Their efforts led to the development of WebRTC project by Google, Mozilla and Opera, which is an open framework that allows browsers to be RTC ready [3]. In this paper, we examine WebRTC from a Quality of Service (QoS) perspective, focusing on Mouth-to-Ear (M2E) delays under various application configurations.

Highlights

  • Voice over IP (VoIP) uses IP based networks in order to transmit digitized voice between two or more endpoints in real-time

  • The results firstly showed that baseline delays for WebRTC in presence of minimal network delay and jitter resulted in delays very close to or greater than those defined in ITU-T Rec

  • This is of significant concern for QoS/QoE as network delay can introduce 10-100 ms baseline increase of delay with jitter adding further due to jitter buffer behaviour

Read more

Summary

Introduction

VoIP uses IP based networks (either public or private) in order to transmit digitized voice between two or more endpoints in real-time. The development of VoIP has eased the cost constraints of long-distance communications as well as completely revolutionized the way we think about real-time communications (RTC). Modern day RTC provide a rich variety of functions including, but not limited to multi-point voice calls, video conversations or data and screen sharing. The WebRTC project by Google, Mozilla and Opera is an open framework that allows browsers to be RTC ready. With only just a few lines of JavaScript code, developers can set-up a Video or Voice over IP (VoIP) sessions. Baseline M2E delays are measured using standard WebRTC settings (i.e. Opus Codec with 20 ms packet size and 48000 sampling rate). Once the baseline delays are established, the impact of various Opus settings – namely packet size and encoding rate as well as other WebRTC provided codecs is examined

Objectives
Results
Conclusion

Talk to us

Join us for a 30 min session where you can share your feedback and ask us any queries you have

Schedule a call

Disclaimer: All third-party content on this website/platform is and will remain the property of their respective owners and is provided on "as is" basis without any warranties, express or implied. Use of third-party content does not indicate any affiliation, sponsorship with or endorsement by them. Any references to third-party content is to identify the corresponding services and shall be considered fair use under The CopyrightLaw.