WebRTC Integration with Enterprise and Public Communications Infrastructure
Some WebRTC-enabled sites will likely need to connect with enterprise communications systems and to the PSTN. Here we discuss architectures for how this can be done.
Editor's Note: This is the second in a series of articles from Brent Kelly (KelCor and Constellation Research) offering a primer on WebRTC; Part One can be found here.
Because the barriers to entry are small, we are likely to see numerous websites that are "WebRTC-enabled". As a consequence, there will be thousands, and perhaps millions of websites, that become WebRTC islands in which communications is only between those users with browsers connected to the same Web server. However, some WebRTC-enabled sites will likely want to connect WebRTC clients to enterprise communications systems and to the public switched telephone network (PSTN). In this post we discuss architectures for how this can be done.
The Need for Border Controllers
Organizations that deploy WebRTC and wish to integrate with existing communications systems should expect to deploy border controllers. A border controller is a device that sits between the WebRTC world and a) another WebRTC domain, b) SIP communications infrastructure, or c) the PSTN. As Jim Donovan of Acme Packet noted, border controllers may provide a number of capabilities including:
1. Signaling gateway--The WebRTC draft standard does specify that signaling must occur when establishing a communication session; however, it does not specify what kind of signaling or the parameters in the signaling protocol used. Each web developer can use what they want for signaling connections and call parameters.
If a WebRTC application does not use SIP signaling, then there must be some type of translation between how the WebRTC application establishes and controls a communications session and how the SIP or PSTN world does communications. Even if the WebRTC application uses SIP, there are so many different "SIP-compliant" implementations that a signaling gateway may still be required.
2. Media gateway--WebRTC may not use the same voice and video codecs as are found in an enterprise or public communications system. If this is the case, then media transcoding will be required to enable communications between these disparate systems.
3. Flash gateway--It may be necessary to support Flash for some time until it is fully displaced by WebRTC. A Flash gateway will assure that browsers that are not yet WebRTC-enabled can still be used in an "always works" service offering .
4. Security and compliance--WebRTC uses cryptography to provide security, by encrypting both the control data and the media. A border controller may be required to decrypt WebRTC control and media flows before they can be integrated with another WebRTC domain or the SIP/PSTN world.
5. NAT and firewall traversal--Most browsers reside behind both firewalls and network address translation (NAT) devices. These devices tend to block real-time voice and video.
WebRTC uses a protocol called ICE (Interactive Connectivity Establishment) for traversing NATs and firewalls. ICE in turn relies on STUN (Session Traversal Utilities for NAT) and TURN (Traversal Using Relay NAT) protocols and servers. A WebRTC deployment will probably need to establish STUN and TURN servers to provide higher likelihood that voice and video packets will traverse the network boundary. As an alternative, for securely allowing WebRTC voice and video traffic to traverse NATs and firewalls, an organization can place a WebRTC-compliant session border controller in the DMZ (Demilitarized Zone); in this model, the SBC handles the ICE/STUN/TURN dialogs for NAT traversal.
Session border controllers can be purchased that handle only one, some, or all of these border traversal issues. Several session border control companies make WebRTC-compliant border elements, including Acme Packet, Genband, Sansay, Mavenir and others. At least one PBX vendor has plans to integrate WebRTC into the PBX fabric so that no SBC is required.
Next Page: Integration with SIP Infrastructure and PSTN