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.
This is the second in a series of articles from Brent Kelly 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. 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.
Integration with SIP-Based Infrastructure
Interoperability with SIP infrastructure will usually require some type of a session border controller to decrypt the WebRTC control and media flows, and it may also be necessary for transcoding between WebRTC codecs and the codecs found in enterprise phones and video units.
When a gateway is involved, the WebRTC voice and video peer connections are between the browser and the border controller (see Figure 1).
Figure 1. Integrating WebRTC with the Enterprise Communications System
Integration with the PSTN
There are several different ways in which WebRTC can connect to the PSTN. In the figure below, the PBX could be connected to the PSTN, which is the most likely scenario in the enterprise. Alternatively, the WebRTC-to-SIP gateway could connect directly to a carrier, which in turn has a gateway to the PSTN. The WebRTC-to-SIP gateway function could reside in a session border controller (SBC), or it could be a separate enterprise network element (see Figure 2).
Figure 2. Integrating WebRTC with the PSTN
Conclusion
While some WebRTC-enabled sites will function well as a communications island, others will wish to federate with other WebRTC domains and with the SIP, PSTN, and mobile worlds. This is clearly possible as illustrated in the figures above.
When designing WebRTC into a Web site, it will be important to decide how WebRTC clients will integrate with these other domains. Using a signaling protocol like SIP or Jingle when implementing WebRTC will make it easier to interoperate between WebRTC domains and enterprise and public communications domains.
This article is an excerpt from Dr. Kelly's recently published report titled, "Ten Things CIOs Should Know About WebRTC."
