LEARN MORE ABOUT DESKROLL

What WebRTC Is

WebRTC is an API that provides native plugin-free support for microphones, web cameras and data streams through a P2P connection between two clients. Two most popular web browsers, Google Chrome and Mozilla Firefox, support most of WebRTC features. WebRTC is still under development, the drafts of the standard have been published by W3C.

The initial release was announced and made open source by Google in 2011. W3C and IETF started developing the standards. As of today, there are two drafts thereof published on GitHub. The first part is about real-time communication between browsers, and second draft is about media capture and streams. Nowadays WebRTC is widely supported by different applications such as Google Chrome, Mozilla Firefox, inluding the mobile versions. There are a plenty of libraries and applications that provide easy methods for using WebRTC. Because it is still under development, current support of applications is not final and could change in the future. Most of the current features of WebRTC are ready for use and won't change too much. At least, for users there is nothing to worry about.

To secure WebRTC connection between peers, the data needs to be encrypted with DTLS. DTLS is a transport layer protocol that uses TLS to encrypt data, securing the data transfers. It also protects the data from being read on the server side. So, while the server establishes connection between users, it still cannot access their private information. WebRTC specifies DTLS use as mandatory. The benefits of WebRTC are as follows:

DeskRoll uses WebRTC to provide faster data rate between users without any additional plugins. Everything that user needs to do is use the latest version of Mozilla Firefox, Google Chrome (recommended), Opera (Blink-based). Let us see how DeskRoll leverages the benefits of WebRTC in a bit more detail. There are two different ways to send data from one device to another:

  1. A client sends data to the server; then the server sends data to another client. The benefit of such model is that it should work in any browser without WebRTC support. Still, we need support for video & audio capture, so it will not work without WebRTC support. Another aspect of this model is speed. Obviously, if you send data via an intermediary server, it takes more time to arrive to destination, as compared to sending it directly. The server could have low performance, or it could have little available bandwidth, it could get stuck at some point without responding to the clients. It could be anything. So, it's important for the service provider to maintain maximum uptime for the clients.

    Direct Connection

  2. The second model envisages using WebRTC to connect clients directly. The benefit you achieve here is the speed. Without the server, the data is sent directly and the speed depends only on the Internet connection between the peers. The downside of this model is that you still need a server for establishing the connection between peers. WebRTC provides a full stack of protocols to resolve such issues, including those intended to resove NAT problems. To be fair, we need to admit that such setup could still have problems with server downtime. You will not be able to establish a connection between peers when the server is not responding. Still, if the connection was established, and the server goes down, the service will continue working.

    Connection through Server

So, which implementation is better? Obviously, the second option is preferrable, so we would recommend using a web browser which supports WebRTC.

As WebRTC is a new technolgy, and it is still under development, it will take some time until it is ubiquitous. The current status of WebRTC is a "non-stable version" and further updates may create some inconveniences for developers. Of course, WebRTC may sometimes fail to provide the same stability and functions as similar implementations in native desktop application. However, it's no doubt the future of the web.

Some parts of WebRTC are already used by major vendors. For example, Microsoft announced that Skype will support WebRTC. In November 2014 company announced web version of its service. It's available only by invinations. Some sources reported that it's still needed a plugin download, so it shows that companies can't use WebRTC in productins because standart is not final.

Then, it's Deskroll of course. Albeit, it relies upon its time-tested technologies (still used in SkyFex) where WebRTC may fail.

Then, of course, the main purpose of WebRTC is to provide plugin-free support for video&audio calls. That is why many WebRTC-based solutions used in commercial products are from this niche.