One of the remarkable attributes of the WebRTC standards is that they explicitly decline to specify any signaling mechanism beyond the SDP format for media negotiation. This may well be the world’s first major communications innovation that doesn’t come with heavy doses of complicated new signaling requirements! So what does this new lightness and freedom from imposed complexity mean for the WebRTC development community?
Signaling is all the additional (meta) messaging and information that surrounds a media or information exchange in order to identify and authenticate participants, establish connections between all the parties/devices, agree on media capabilities, manage and control changes during sessions, and wrap things up. Traditional signaling, such as SS7 - the backbone of public telephone networks - were very heavy and only a very small number of developer “priests” ever really understood or interfaced with SS7. With the evolution to VoIP the communications industry continued to define very comprehensive, and therefore heavy, signaling standards, such as the H.323 family, that may have been understood by a few thousand more developers but which kept most communications application development largely within the hands of hard-core telecommunications organizations.
The greatest force for lightness has always come from the Internet IP community, IETF and now W3C, who reuse and build on other IP capabilities to make new standards as simple as reasonably possible and accessible to millions of Internet and Web developers. SIP is a great example of IETF success with lightness, arriving with supposedly “just six message types” and building on URIs, HTPP styles, peer-to-peer models and existing many-media standards. This disruptive lightness surprised many traditional vendors yet SIP has now taken over the market and every telecommunications vendor now supports SIP (albeit some in strange ways).
So now we get to WebRTC and the signaling requirements become almost invisibly light. Or to spin that: it’s now up to you to decide how to signal and connect users and devices together in the simplest way for your application! There is a temptation here to reintroduce all the heaviness of existing signaling approaches – many vendors are talking about adding SIP, XMPP/Jingle, and of course IMS integration for carriers. I am sure I will get some flak for saying this, but SIP today has become quite complicated so that the major vendors need lots of developers to keep up with compatibility, multi-vendor integration, gateways and features. While there are certainly WebRTC+SIP use cases, and accessible libraries for Web developers like jsSIP, the question for most HTML5 and WebRTC application developers should be whether all this extra “traditional” signaling is really needed for their particular application?
The secret in maintaining “lightness” is to remember the WebRTC triangle and trapezoid models (see Alan’s and Dan’s book, recently discussed by Carl Ford). Triangles are lighter than trapezoids! In the trapezoid case you have separate services on the back-end that now need to talk to each other which means some agreement about external signaling. To keep it light you need to “re-triangle the trapezoid” as much as possible – see Figure 1.
For today’s Web developers there is now immense “cloud power” easily available from the ecosystem of social platforms, developer frameworks, and open source tools, allowing all kinds of alternative distributed application coordination. So here are three starting suggestions on when and how to stay light:
1. Single Service Model
There are many great WebRTC use cases where people meet on one particular website, or more broadly a single distributed “service,” as you see in most current demos. The idea of WebRTC Portals is that this should be a common pattern where others come to a person’s or organization’s “destination page” that is specifically designed to deliver the desired communications experience. There is no need for external signaling when everyone can “meet me” in one place. This is also the model that conferencing services use, from WebEx and GoToMeeting through Uberconference to the latest Blue Jeans, Vidtel and Vidyo video conferencing services. The portal challenge here is that each of these services currently has its own “portal” that is separate from all my other modes of communication – but I want them integrated.
Major social Web destinations, like LinkedIn, Facebook, Twitter and Google+ and enterprise destinations like Chatter and Jive, have the potential to become major communication portals. They are already personalized destinations, they have solid identity models in wide use, and they have back-end global scaling and distributed messaging/event logic that they may be able to use for internal WebRTC signaling. Everyone else in the market should expect to “eventually” see these vendors embedding WebRTC and richer collaboration capabilities directly, and prepare appropriately.
2. OTT to Major Service Model
If, unfortunately, you are not already one of the major social services like LinkedIn or Twitter, you may still be able to leverage them over-the-top (OTT) and borrow their identity space, destination portals and possibly core messaging capabilities. Twelephone is good example that sits on top of Twitter using Twitter handles to establish people’s identity and providing an associated page, or shortly an embeddable widget, to directly communicate using WebRTC.
In this hybrid model, the identity and authentication part of the signaling is provided by Twitter while Twelephone’s back-end cloud services support session management along with presence, chat and, yes, even SIP integration! All the major WebRTC developer toolkit vendors (see the long list here) are providing widgets and interfaces today and are likely to deliver tools for integrated portals and embedded tools within social and enterprise destination sites. If you adopt these tools for your application then you will be leveraging their particular cloud coordination and signaling capabilities – they will become the simplifying peak of your WebRTC triangle.
3. Publish/Subscribe Model
Unfortunately, most existing social sites do not provide very rich developer-accessible real-time messaging capabilities to support fast signaling. But you can obtain this from the cloud ecosystem without having to build it yourself. At WebRTC Expo in Atlanta, PubNub (see demo here) showed how its fast general purpose publish and subscribe network can be used as a “light” global signaling layer for WebRTC applications. Publish and subscribe is a very powerful application design pattern that enables all kinds of highly distributed users and devices to be quickly connected together by just subscribing on appropriate channels. Channels can be about topics, events, games, sports, whatever – so this is a more general “addressing” approach than simply having explicit lists of people to call. The message streams can be used for exchanging WebRTC setup and change information as well as for many other innovative real-time application capabilities. Once again, a reliable external distributed service is being used to “re-triangle the trapezoid” for you so you don’t need extra cloud services but can focus on your user experience and application capabilities.
Now if there is legacy communication integration involved, then you will have a “forced trapezoid,” someone will have to signal from the WebRTC part over to the legacy systems and, yes, this is likely to involve SIP or even heavier protocols. But in most cases the legacy vendors themselves or the many Session Border Controller (SBC) and gateway vendors or cloud services like Twilio will be providing this. The average HTML5 Web developer should not expect to be implementing legacy telecommunications integration themselves! Which means, as discussed here, that WebRTC developers should be focused on how light they can make their own signaling by borrowing as much as possible from other social environments and from WebRTC and publish/subscribe cloud services.
Edited by
Alisen Downey
