Implementing real-time voice, video, chat, and data flow in web applications used to be hard. It required building or licensing and maintaining sophisticated audio and video plugins. Web Real-Time Communications (WebRTC) is here to change that.
Currently being standardized by the W3C, WebRTC is an API created by Google that enables RTC within web browsers without plugins or downloads. The API implements all the complicated infrastructure to allow browsers to establish direct peer-to-peer connections with each other for voice, video, chat, file sharing, and generalized data sharing.
The availability of the API dramatically reduces the cost, difficulty, and time to deploy RTC on the web. For that reason, WebRTC is considered to be a truly innovative technology. Business opportunities that did not exist yesterday are suddenly here today because of WebRTC.
While there is disruption, there is also some hype. Developing with WebRTC can be as simple as adding a few lines of JavaScript to any web page, but there are some realities to consider in real world deployments.
Deploying WebRTC in the real world: challenges and tips
Challenge: Not all web browsers and platforms currently support the WebRTC API.
Chrome, Firefox, and Opera browsers all support WebRTC on desktop and Android devices right out of the box. For other browsers and mobile operating systems, today, there are third party plugins and libraries that can be installed to enable RTC functionality.
Some may feel this defeats the purpose of WebRTC, but if you'd like your application to be supported by all major browsers, you'll need to consider a plugin for now. As WebRTC API definition moves through the standardization process, native support is expected to become more ubiquitous in web browsers, mobile devices, appliances, and other systems.
Challenge: A signaling mechanism, intentionally not defined by WebRTC, is required to allow peers to exchange messages
WebRTC cannot create peer-to-peer connections without some sort of server in the middle that provides a signaling channel by which peers can exchange the information needed to set up a connection. Technically, the signaling channel could be any sort of channel— email, post, or carrier pigeon. The reality is that, for all but toy and demo applications; signaling is hard and much harder than it might appear at first consideration.
From a practical standpoint, the choices boil down to whether to leverage a proprietary signaling platform or an open, standards-based (SIP or XMPP) signaling platform, as well as whether to utilize a licensed platform or hosted platform-as-a-service. Organizations should make these decisions based on many factors, including: functionally, performance, scale, cost, and other business considerations.
Perhaps the best drivers for an organization to decide on a closed proprietary signaling platform are functionality and performance. Closed applications that do not require interoperation outside an island of WebRTC may be best served by a proprietary "walled garden" signaling solution, especially applications that are heavily focused on a particular use case. There may be a proprietary solution that hones in on and optimizes a single function. A good example of such a use case is publish-subscribe, wherein a solidly fitting, proprietary signaling provider is PubNub.
On the other hand, vendor lock-in is potentially a downside with proprietary solutions. Proprietary solutions, cloud based or not, required the use of proprietary libraries and SDKs, which make it difficult to migrate an application utilizing one platform to another. Organizations that have long-term cost and increasing functional needs on the mind may be best suited for an open, standards-based platform.
Challenge: WebRTC does not interoperate with existing systems, including the Public Switched Telephone Network (PSTN)
As there are billions of people using the PSTN, it's not unlikely that an organization will want to build a WebRTC application that sends calls to and from it. If you are building an application that simply will send calls to and from the PSTN, you can accomplish this using a voice application platform such as Twilio or Tropo. A more flexible solution, however, is to consider your choice of signaling layer.
