VoLTE/Rich communications

Decoding WebRTC's Promise & Challenges

WebRTC will be available -- that is, downloaded and installed -- on over 4 billion devices within the next three years, according to the International Telecommunication Union (ITU)'s projections.

What this means is that all of the complex voice, video, and data handling for communication between two devices over the Net are likely to become mere elevator music for developers -- ever present, but largely unnoticed and hardly a nuisance.

All of the arcane knowledge that previously had been guarded by the few will be part of the common infrastructure. There will be no need to understand and deal with echo-cancellation, backlighting, rotation distortion, frame stabilization, or any of the other myriad challenges posed by real-time communication. Much like building web pages, developers will only need to issue a few high-level commands, and voila -- the communication channel will be established.

There are, however, some potential bumps along this idyllic road to ubiquitous IP communication. WebRTC does indeed make the underlying call handling much simpler, and mundane uses are fairly simple to realize. A web page, for example, can easily open a voice or video session to a specific server. But for more complicated scenarios, challenges set in.

Signaling, for example, is one of the major issues that may come up for developers looking to create a full-featured communication package based on WebRTC. Call sessions are established on two plains -- the media and the signaling. Media handling and all that surrounds the transmission of the actual real-time content, such as voice or video packets, is precisely what WebRTC does so well.

Signaling, on the other hand, is left somewhat vague and undetermined in WebRTC, yet it is a crucial part of the total picture. Signaling deals with call setup and teardown, with registration of a user, and with discovering the called party. Since the late 90s, the protocol of choice for signaling over IP has been the Session Initiation Protocol, or SIP. SIP uses globally unique identifiers (think email address or phone number) to route calls and has a set handshaking process for notifying, accepting, rejecting, and modifying calls, etc.

All of this signaling is outside the purview of WebRTC, and different solutions are being kicked around in order to provide the advanced signaling that robust communication services require. One can find SIP stacks written in JavaScript that can be embedded into a web page offering basic SIP functionality to supplement the WebRTC component. Another option is to implement the most basic signaling functionality (e.g., make call, receive call) between the web page/browser and the host/server, typically in REST/SOAP/JSON over a WebSocket connection. The server then takes care of all the more advanced signaling functionality, acting as a WebRTC to SIP converter.

There are a number of companies already taking this route and offering these types of conversion servers. Each uses its own API flavor on the browser-facing side, but adheres to the SIP standard on the network.

It is still the early days for WebRTC, and it remains to be seen whether one method of choice for signaling will emerge. Until then, developers will have to make due without hard and fast standards. Besides, as famous late night talk show host, David Letterman, once quipped, "Traffic signals in New York are just rough guidelines."

— Baruch Sterman, PhD, VP Technology Research, Vonage

COMMENTS Add Comment
tjohnsen570 9/11/2013 | 10:52:22 AM
Re: IETF role? No, neither the IETF or W3 are specifying signalling. Open Peer, conceived at IETF 80 in Prague, provides purpose built signalling for WebRTC. Good overview by Chief Architect here: http://www.youtube.com/watch?v=XR5p8eudSSk Technical spec and Github fork available here: http://openpeer.org/ 
Lawrence Byrd 8/30/2013 | 2:05:27 PM
Re: WebRTC and Signaling There will be interfaces betwen WebRTC and the old world - every major SBC vendor is looking at what and how to do this and they will come out with appropriate features. Cloud providers like Tokbox, Twilio and others will, over time not necesarily today, also make it very easy for random web developers to just tap into older networks. The point is that the average web developer does NOT have to worry about all this and in most cases also does not have to worry about old heavy signaling standards like SIP or worse. They can keep it lighter.
Telco 8/30/2013 | 1:57:38 PM
Re: WebRTC and Signaling I like your perspective and have had people express the concept that "we are growing without you" to some major CCS database vendors.  The interesting perspective is WebRTC does not have to solve integration into carrier "Private Internets".  WebRTC is and could gain enough traction without the obstacles of some environments that are not so progressive. 
Lawrence Byrd 8/30/2013 | 1:44:18 PM
Re: IETF role? So given my previous comment, my answer to DOShea on IETF is: I hope not and right now this seems to remain the case.
Lawrence Byrd 8/30/2013 | 1:40:36 PM
WebRTC and Signaling While I completely agree that WebRTC is putting a rich set of open real-time communications codecs and functionality into the hands of tens of millions of web/mobile/cloud developers I disagree that the absence of a signalling definition is some big obstacle. As I argue in a piece over at WebRTC World (here), this "Unbearable Lightness of WebRTC Signaling" is, in fact, a massive benefit creating all kinds of choices for open web developers, and many of these choices will be much simpler than SIP or traditional signaling. While there are certainly SIP+WebRTC use cases and providers like Vonage may have to think hard about how their internal signaling interlocks with WebRTC, for many many developers this just won't be an issue. They will use whatever the simplest cloud-based approaches work for them. And indeed this will be one of the drivers of new WebRTC-enabled innovation - NOT being tied to the past :)!
Telco 8/30/2013 | 12:55:01 PM
Re: IETF role? Timely article and responses as I had doubts about my solutions.  These are the issues I am wrestling with.  WebRTC has plenty of custom app support and a homogenized solution effort forming in ATIS.  Then there is the hand-off to SIP enabled communications where I really get stuck finding an authorative guidance.  I have been looking to the SoSBC vendors to mediate this in a package and I am sure they are working on a package for this difficult issue.  The idea we absorb a proprietary solution could not be more pronounced whereby IE enabled platforms are hosted application based.  The consumer OTT vs Carrier Supported voice links to devices develop a solution while SoSBC enabled network operators adopt another solution for hosted Voice Apps.  Kind of like the DTMF/MF or the AIN is to CCS, SS7, IS54/Sigtran or even SIP Forum "Trunking" vs SIP NOC deployments.
mcgrathnr 8/30/2013 | 12:16:15 PM
Re: IETF role? @DOShea, Yes signalling was discussed in depth at the last webRTC conferece in Atlanta recently, and indeed there was a panel on this very subject. The summary is that our friends at google would rather let the signalling selection be up to the developer rather than mandate "thou shalt use SIP". I understand why they are doing this, and it some respects it makes sense to let the technology behind your websites video chat be your own - you dont need SIP competent developers to launch a very cool solution for a concierge service. If you want a solution that MUST interwork with voip/volte/standards then ok, go build the "next skype" with SIP as your signalling protocol. its up to you. Remember WebRTC is really about playing with everyone, its a web technology that allows you to put voice and video natively into a website, any website - as long as you dont want to use iExplorer ;-) 
DOShea 8/30/2013 | 11:44:49 AM
IETF role? So, is this signalling challenge something the IETF is tackling, via one of the working groups?
Sarah Thomas 8/30/2013 | 11:33:20 AM
SIP versus WebRTC? Thanks for the post, Baruch! It's good to get a reality check on the WebRTC hype. Signaling is a big issue with a lot of apps, so it makes sense it extends to WebRTC as well. I've often heard WebRTC pitted against SIP, that it would eliminate the need for SIP. Do you see that happening, or is one still dependent on the other to help with the signaling issue?
Sign In