First posted on TechRadar.
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.
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.
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.
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.
If you would like your WebRTC endpoints to communicate with each other (voice, video, messaging, data) in addition to being able to call the PSTN, this consideration actually brings us back to signaling. Choosing a SIP signaling platform is likely your best option here because it works well for both peer-to-peer scenarios and endpoint-to-PSTN scenarios. SIP has become the de facto standard for VoIP, and the majority of VoIP systems have integrated with the PSTN.
Lastly, while WebRTC aims to create true peer-to-peer media and data streaming once a session is established, the reality is that most devices today live behind one or more layers of NAT, and many are behind corporate firewalls. WebRTC apps use a framework called ICE to successfully overcome the complexities of real-world networking in most cases. But, there are a non-trivial number of cases where ICE cannot succeed to create true peer-to-peer media connections. In these cases, ICE relies on the availability of media relay servers (TURN servers) in the cloud, on which it can fall back to relay data between endpoints.
Conceptually, media relay servers have the simple task of relaying a stream. Media relay servers have public addresses, so they can be contacted by peers even if the peers are behind firewalls or proxies. It's important to note that media relays require reliable congestion-free Internet connectivity to effectively operate. Poorly operated media relay servers can introduce quality issues such as choppy media and disconnected sessions. Based on their bandwidth requirements, media relays can be rather costly to operate.
Tackling media relays is, like signaling, a hefty task, but it is necessary to enable WebRTC applications to perform to enterprise-level standards. You can choose to operate a media relay solution or find a hosted solution. If you are selecting a hosted signaling solution, be sure to investigate whether they handle media relaying and, if so, how they ensure QoS.
With the right approach, you can take advantage of the disruptive business opportunities WebRTC promises today.