Bridging the gap between WebRTC, VoIP and phones
The WebRTC protocol has shown great promise for integrating telephony capabilities into modern enterprise applications. But challenges remain.
The WebRTC protocol promises to make it easier for enterprise developers to roll out applications that bridge call centers as well as voice notification and public switched telephone network (PSTN) services. Additionally, the WebRTC project provides browsers and mobile applications with real-time communications capabilities via simple APIs, and is a great choice for implementing the call center side of the apps. WebRTC is essentially a set of JavaScript APIs baked into browsers that let developers build applications in order to enable users to make browser-to-browser calls without external plug-ins.
"It's undeniable that the WebRTC protocol is disrupting the Voice over IP (VoIP) industry and redefining what communicating means," said Sacha Nacar, developer community manager at Voxbone, which sells local phone numbers around the world that link to SIP) endpoints. WebRTC enables secure real-time communications applications in the browser without requiring any plug-in or fancy equipment on the client side. In significant ways, WebRTC and SIP overlap in function. But to more fully understand the issue, developers need to consider other important parts of the communications process like signaling or being able to connect a wide range of devices.
Different languages on the back end
The main problem has been that WebRTC, VoIP and PSTNs speak different languages on the back end. VoIP and voice chat applications use SIP while PSTN defaults to Signaling System 7 (SS7). But no standard has been established for WebRTC, which makes it challenging to create call center applications that work seamlessly with mobile apps supporting voice, chat and regular phone calls.
SIP is used by VoIP applications to handle signaling and multimedia sessions and provides a framework for controlling signaling. SIP and WebRTC can be used independently when the application is implemented entirely inside or outside of the browser. But when browser applications need to connect to existing phone services, WebRTC needs a way to understand if the browser is running when someone answers or hangs up the phone.
WebRTC signaling is a work in progress
"WebRTC is a work in progress and no protocol is specified for signaling at the moment," Nacar said. This leaves room for experimentation. Some view this as a gap and others as an opportunity.
There are different ways of implementing WebRTC signaling. The basic method is to implement SIP over WebSockets because it is already a standard in VoIP. This makes it convenient in terms of the semantics of the VoIP industry. But SIP was not built with WebRTC in mind. "You need custom stacks and custom gateways, and this brings some hindrance with using SIP and signaling for WebRTC," Nacar explained.
Some carriers are making signaling available with WebSockets, and making open source versions available, such as Java API for SIP Signaling ( JSIP) in order to make SIP more accessible to Web applications. Other options include XMPP/Jingle and the WebRTC DataChannel -- the latter of which uses Stream Control Transmission Protocol (SCTP) for out-of-order delivery and to retransmit configurations.
Other WebRTC challenges abound
WebRTC standardization is not just about signaling. It is also about other features, like the choice of video codec. The two main ones currently being used are VP8/VP9 and H.264. One of the main considerations standards bodies are making involves licensing issues associated with these underlying video codecs.
Another challenge is that WebRTC needs more universal browser acceptance. It is currently supported on Chrome, Internet Explorer and Firefox; but not on Apple's Safari. This could eventually present a problem in bridging WebRTC applications to Macs and iPhones; but at present, the process is not sufficiently straightforward to arrange WebRTC calls while running Safari.
Still another limitation of WebRTC is support for identity management. Many security applications leverage two-factor authentication that uses one's phone number to secure access. This is based on the International Telecommunications Union's (ITU) E.164 recommendation that defines the numbering plan for worldwide telephone networks. This could potentially break down traditional security paradigms that assume phone numbers are relatively static and tied to one individual.
"Our identity is fragmented on the Web," Nacar added. For example, someone might have a Facebook profile for various applications, but email addresses or phone numbers for others. So the future might feature a combination of identities, rather than just one, to manage these applications.
Bridging the IPv4 gap
WebRTC signaling could also be problematic when the communication has to traverse separate Internet Protocol version 4 (IPv4) networks that are tied together with Network Address Translation, said Vincent Puglia, developer advocate at Dialogic. In response, a variety of frameworks have been created to help bridge the gap, including Session Traversal Utilities for NAT (STUN) and Traversal Using Relay NAT (TURN).
A STUN server provides NAT traversal as part of the Interactive Connectivity Establishment protocol, and a TURN server relays media when a direct connection cannot be established. "Almost every WebRTC deployment should have a TURN server," Puglia asserted. Good open source examples include RFC-5766-turn-server and Coturn.
But in the end, Nacar believes that both SIP and WebRTC are valuable. For example, leading companies like Twilio are bringing SIP and WebRTC technologies together. "Maybe both can live together to create better contextual applications," Nacar suggested.
Where is WebRTC headed?
Using WebRTC in mobile apps
