WebRTC doesn’t need SIP. SIP needs WebRTC.
I think it would be fair to say that WebRTC doesn’t really need SIP. You can use SIP if you tweeWebRTC – just pick it up as a signaling protocol choice – one of many.
We can probably split a WebRTC deployment into 3 parts:
- The browser side – this is where WebRTC resides. JavaScript code, mingled in with HTML5 and CSS to create the user interaction itself. There’s a need for a signaling protocol here.
- The web backend – this is where the interaction with the web page of WebRTC happens. I am not talking about the serving of HTML itself, but more of the WebRTC interaction – what a lot of developers do today with Node.js for example.
- The VoIP backend – where media gets processed, and to some extent signaling.
My own view?
- Browser side should be proprietary or XMPP. SIP should be used there only for those who are VoIP’ers and wish to connect it to their existing SIP network as an additional way of access.
- VoIP backend should probably use SIP for the complex use cases. In the future, probably 2-3 years down the road, this will also switch to a WebRTC/REST combination as the infrastructure access, but for now it should be SIP.
–
There were no SIP signaling solutions in JavaScript a year ago, and why should there be? There was no point in doing that. But now there are a few.
SIP started adding WebSockets support only after the introduction of WebRTC.
But then, companies are using other solutions than SIP on the browser side – just check out some of my interviews. AddLive and TenHands went proprietary for signaling. Drum uses Jingle on the browser and then translates it to SIP for their backend.
And why is that? People use the tool that is best suitable for them: either because this is what they already know, or that what made sense.
interesting response; Justin on SIP’s relevance to #WebRTC-SIP dev cycle has been in years whereas cadence of web is weeks,days, even hours
— trentjohnsen (@trentjohnsen) November 27, 2012
The tweet above makes a lot of sense to me: SIP and WebRTC have a different vibe to them. As more web developers adopt WebRTC (as opposed to VoIP developers who are the majority still), we will see less use of SIP as the signaling protocol and a lot more proprietary solutions for it.
Interesting post, thanks.
One obvious advantage of using SIP on the browser side when connecting to PSTN is that it requires a centralized server to to convert the proprietary signaling coming from the browser to SIP.
The disadvantage relates to the complexity of SIP which may affect browser performance on one end, and may still require an SBC for SIP normalization and security on the service provider side.
BTW, I saw a company called Plivo who creates an open source Java Script SIP library.
Avi,
Plivo is an telepgony API provider as far as I can tell and an interesting one. They are in the process of adding WebRTC into their offering, but I am not sure if it will support SIP or not.
They do support WebRTC by now. Their SDK uses JsSIP for signaling and WebRTC for media where available, falling back to flash otherwise.
That being the case, they should probably update their website to reflect it 😉
Why XMPP and not SIP? Some may say the complexity can be high, but OTOH, Jingle uses an XML based SDP whereas SIP uses a plaintext one, so one can just take the SDP out of a PeerConnection and put it on a SIP packet, no conversion needed.
Moreover there are already a few JS SIP stacks out there so there is nothing new to be done, and WebSocket as a transport for SIP will be an RFC pretty soon apparently.
Saghul,
Never said no to XMPP. I know little about its signaling and complexities, so I am not one to judge it.
I assume it is simpler than SIP, but more complex than my own thought out proprietary protocol for my own special use case.
My gut feeling is that SIP will be used for those interesting in PSTN connectivity the most. XMPP will be used for those in need for text chat as well as voice anad video calling and proprietary will be the most commonly used option for a lot of niche use cases.
It all rather depends on whether you’re catering to folks wanting to extend their existing SIP-based infrastructure out to the Web, or whether you’re serving developers who want to quickly extend their web apps to add voice+video.
Of course, those wanting the best of both worlds will support both SIP and a REST-based interface. Whichever is chosen, it’s important for vendors to provide a nice, simple JavaScript API to allow developers to create or receive calls using phone numbers, SIP URIs, login names or whatever other form of identity that may be convenient, and certainly without having to get down into the weeds of using SDP.
I think identity management is an important piece of the puzzle. But that’s a whole ‘nother story.