I recently returned from my annual pilgrimage to Enterprise Connect, where WebRTC was one of the hottest discussion topics since Session Initiation Protocol (SIP) trunking became popular several years ago. I have seen enterprise and contact center real-time communications evolve from time-division multiplexing (TDM), to proprietary IP methods, and now to SIP. Is WebRTC just another step in this evolution or something more?
Enterprises have always faced a wide range of challenges associated with connecting, securing, and controlling IP-based real-time communications. These challenges are going to get even more interesting with the advent of WebRTC.
In its most basic form, WebRTC is a media framework that focuses on adding voice and video (among other capabilities) to the web browser. Not only will there be flows where all parties are using WebRTC, but the new WebRTC apps must also work well with the installed base of SIP elements.
When thinking about the challenge of making a new communications method like WebRTC work seamlessly with more established methods of today's SIP-based enterprise UC and contact center deployments, it becomes clear that a gateway function is needed. There are three primary categories of critical WebRTC gateway features that are needed to address this challenge:
* Signaling gateway
* Media gateway
* Security and compliance
Signaling gateway: These features are important because WebRTC does not specify any type of signaling protocol. Without a signaling protocol, a number of challenges arise, including reachability and authentication. The standards bodies working on WebRTC decided to let WebRTC app developers choose their own signaling protocol, as a means of letting the market decide what worked best. This seems like a good idea, but it also means that a WebRTC signaling gateway function is needed in the network to convert the signaling method used for the WebRTC app to the signaling method used in the enterprise or contact center (which will generally be SIP). This function will definitely be needed if the WebRTC app uses a protocol other than SIP, but as we've seen with SIP Trunking, even if the two ends of the communications both use SIP, that's no guarantee that they'll use the same SIP implementation and be interoperable.
Media gateway: These features are important because WebRTC uses encryption and NAT traversal methods that are generally not compatible with today's enterprise or contact center environments. The WebRTC media gateway function ensures that a voice or video flow from a WebRTC app can work with the existing SIP-based enterprise and contact center elements. A WebRTC media gateway may also be used to address voice and video codec incompatibilities between WebRTC apps and SIP-based elements.
Security and compliance: The security and compliance challenges addressed by a WebRTC gateway are multi-faceted. First, a WebRTC gateway will help ensure that the WebRTC flows traversing network borders have the same type of high security that is available for SIP-based communication flows. Second, a WebRTC gateway ensures that WebRTC apps can be authenticated and authorized to access network resources in the same manner as other enterprise and contact center apps. Finally, a WebRTC gateway should also help ensure compliance with regulatory requirements in the area of call recording and privacy.
A broad set of WebRTC gateway features will be needed to successfully deploy WebRTC into existing enterprise UC and contact center environments. As revolutionary as WebRTC may be, this exciting new technology must integrate seamlessly with the investments that enterprises and contact centers have made in SIP over the past decade.
