This content is part of the Essential Guide: Understand WebRTC basics to maximize deployment and adoption
Evaluate Weigh the pros and cons of technologies, products and projects you are considering.

Four main uses illustrate need for WebRTC gateways

WebRTC promises easy communication between browsers for video conferencing and voice, but the need for WebRTC gateways is clear.

Web Real-Time Communications is arguably the hottest topic in the unified communications, collaboration and contact center market these days. Its ability to allow browsers to function as softphones and video-conferencing endpoints, and its support for screen sharing opens up a wealth of possibilities for improved customer service, remote access, new applications, and broader collaboration across corporate boundaries. But a successful WebRTC implementation also means addressing security concerns, protocol translation and policy management. This is where the need for a WebRTC gateway comes in.

The idea of needing a gateway for WebRTC may seem a little odd, considering WebRTC promises easy peer-to-peer communications between any two browsers.

But digging under the hood a bit, it seems that WebRTC and Session Initiation Protocol (SIP) have many of the same characteristics, as well as many of the same gateway needs and use cases. WebRTC also has use cases unique to the technology.

Here are four main uses for WebRTC gateways.

Policy enforcement: One of the most promising WebRTC applications is to allow customers, partners and remote employees to use a Web browser to connect to corporate communications servers. An example is enabling a customer to call a contact center via a button displayed on a webpage. But allowing external entry into the network is fraught with risk. Just as organizations use session border controllers for controlling access for remote UC clients and SIP trunks, so too will they require a gateway for external WebRTC sessions. Policy enforcement may include security controls such as protocol inspections to prevent attacks, user identification and even prioritizing WebRTC traffic over non-real-time applications.

Network address translation (NAT) traversal: Like SIP, WebRTC sessions use Session Description Protocol (SDP) to enable endpoints to exchange the information necessary to set up a call. This exchange includes not only codec, encryption and other related information, but also the source IP address of the endpoint initiating the connection request. If the originating endpoint sits behind a network address translator, it will send a source address that may not be reachable by the destination browser. As in SIP, the originating browser must first determine that the IP address of its outbound session is assigned by the NAT gateway, then transmit that rather than its own IP address. WebRTC gateways supporting the ICE, STUN and TURN protocols (RFCs 5247, 5389 and 5766) can enable a browser to query a gateway to discover its external IP address before initiating a session.

Protocol translation and transcoding: This is the one area where WebRTC separates itself a bit from its SIP cousin. WebRTC standards are still somewhat limited, only supporting SIP for signaling, G.711 and Opus Codecs for voice; there is no agreed-upon codec for video as yet. WebRTC gateways can enable transcoding between disparate protocols (e.g., G.711 to G.729 or Opus to G.722, for voice, and VP8 to H.264 for video compression), as well as protocol translation between SIP and non-SIP protocols, such as Microsoft's RTAudio, H.323 or Cisco's Skinny Client Control Protocol.

Application sequencing: Those implementing WebRTC solutions for customer engagement and remote access will likely require a variety of management services, including the ability to record calls and gather call data record information. Other information might include the location of calling parties and customer information. A WebRTC gateway with either built-in application features or application developer interfaces can provide a way for organizations to meet their application management needs. As an example, a WebRTC gateway, recognizing that the call is from a customer, could fork the SIP session to a call-recording application to meet compliance requirements.

The bottom line is that those who have experience in deploying SIP will see many similarities between SIP and WebRTC. While both offer the promise of peer-to-peer communications, the reality of enterprise application, security and policy needs, coupled with the large percentage of networks that leverage network address translation, will drive requirements for WebRTC gateways to achieve implementation success. To determine which one best meets your needs, evaluate offerings from a variety of vendors.

Next Steps

Start at the beginning with our WebRTC primer

Find out how WebRTC could turn enterprise video on its head

A look at WebRTC security threats

Get real: What WebRTC applications will and won't do for the enterprise

Dig Deeper on Communication Integration with Enterprise Applications