Last week, we attended the WebRTC World Conference and Expo in Miami. We were excited to be a Gold Sponsor for the Expo, and we were thrilled to be a part of the bustling dialogue of the event. It was a great experience, an opportunity to meet developers using OnSIP developer accounts and SIP.js in their applications, and also a chance to discuss, at length, new and controversial topics in WebRTC.
My favorite session of #webrtcexpo was the last - an informal convo abt SIP + telco mindset. W/ @onsip @matrixdotorg @NetSapiens #SIPjs
— William Mitchell (@wakamoleguy) May 14, 2015
Between CTO John Riordan's keynote and my three scheduled talks, it was already a busy agenda. One of my favorite sessions, though, turned out to be one of the last. The description was pointed, asking if SIP is a boon to WebRTC, or if it is instead holding us back from achieving the full potential of real time communications on the Web. Here's the full description:
WebRTC Signaling - Are we SIPping the wrong Kool-Aid
This open and interactive session will focus on whether SIP is a valuable interoperability capability of WebRTC or a major challenge and issue. Have we missed the point of enabling web with Interactive communications. The web is more than phones and the browser supports a host of opportunities. The lessons of Skype is that we can gateway without having to restrict ourselves, to phone numbers, telephone sets and legacy networks.
At OnSIP, we are obviously proponents of using SIP in just about everything we do. For us, this prompt was especially goading, so how exactly did this become my favorite session of the entire Expo?
An Informal, Informed Discussion About Signaling
Some hold that a JSON-based protocol would benefit WebRTC.
The agenda didn't list a particular moderator or speaker for the session. When nobody stood up to run it, after a few minutes the audience just began asking each other questions and discussing the topic at hand. There was a mixed crowd attending the event.
SIP proponents (myself included) asked HTTP/JSON purists challenging questions about interoperation and federation, and rebuttals came back regarding the weight of SIP as a protocol and its close association with an older telco mindset. Many people joined the discussion, and just about every possible opinion was represented. I think the overall group can be summarized into four camps:
- Those coming from the telco world, who shifted years ago from a non-SIP VoIP platform to SIP. These people are committed to SIP as the protocol, and the primary interest is adding WebRTC to existing platforms and providing interoperation.
- Those like us at OnSIP, who approach SIP a little differently. We think of SIP not as a legacy protocol for placing phone calls, but as the standard for initiating sessions of any type (voice, video, data). Those in this camp tend to use SIP a little differently than your average Joe.
- Matthew Hodgson from Matrix.org. Matrix.org is attempting to create a standard, open alternative to SIP as a signaling protocol. While Matthew and I share a lot of viewpoints in terms of federation, the importance of standards, and interoperability, the Matrix approach is pushing an HTTP and JSON protocol with some very different ideas.
- Lastly, there is the camp of custom signaling. The philosophy here is that WebRTC allows web developers to spin up a simple JSON protocol very quickly, and using that freedom will generate more interesting use cases than the benefits of a standard protocol.
Despite such disparity and a lack of a moderator, there was a lot of agreement (mixed in with a fair amount of disagreement). No fights broke out, and everything remained relatively civil. So much was covered that I can't possibly recount it all. Here are a few highlights:
Does SIP limit you to a 1-to-1 call model?
When you use SIP to inter-operate with traditional VoIP or PSTN applications, it may limit you to a 1-to-1 call model. In that application, though, that's probably okay. But isn't that more the platform, which happens to use SIP, imposing the restrictions, rather than SIP itself? This was a crucial point of discussion.
In a specific sense, a group or chat room may be a better abstraction for signaling than a single 1-to-1 connection. Protocols like Matrix are better suited to this than SIP. And yet, WebRTC itself offers RTCPeerConnection, a 1-to-1 stream of media, as its building block. Group conferences are always either a mesh combination of multiple sessions, or a combination of connections to a single media server. SIP can initiate these connections directly, with a higher level application determining what it means for that to be a group chat.
Is SIP too heavy or exotic for the Web?
HTTP is built into browsers, and JSON is very lightweight for parsing. SIP was created with HTTP in mind. The header format and method names are modeled after HTTP requests and responses. WebRTC mandates SDP, and everybody in the session agreed that SDP is difficult to work with. While SDP is necessary for interop with other VoIP platforms, it would be nice to use something more legible to both browsers and humans.
SDP is, however, the standard that we currently have. If and when a specification like ORTC does away with SDP, any signaling protocol out there, whether SIP, XMPP, or even Matrix, has the ability to substitute a different content type in place of SDP. SIP.js actually does this already in its unit tests, with a simple "Rock-Paper-Scissors" replacement for SDP.
As a comparison, early JavaScript SIP stacks were not very easy to use. SIP may not be a hard to use protocol so much as it has suffered from hard to use APIs.
Is SIP holding back WebRTC?
While SIP is commonly used with technologies that may be restrictive, like traditional VoIP networks and ugly SDP, SIP itself is not to blame. But there are many equally valid signaling choices, and each is better at doing different things.
SIP shines when it comes to interoperability, session initiation, and advanced session control. XMPP was designed for presence, messaging, and subscriptions to data streams. Matrix has built in history and eventually consistent state shared amongst nodes. Custom protocols are fast and simple to spin up, but may not have the advanced control you would find from more mature options. Developers, in the end, must weigh their options and make the choice that is best for them and their application.
A Great Discussion to Close A Great Event
The back and forth during this discussion made this a great session. Afterwards, a few people shared the sentiment, and so I hope that this really did provide a lot of insight into the world of signaling with WebRTC. My thanks go out to the Matrix.org and NetSapiens teams for keeping the conversation going. And of course, I'm always happy to continue the conversation. Tweet @OnSIP or myself (@wakamoleguy), or catch up with us on the SIP.js Mailing List.