One of the more common questions I’ve gotten over the last year or so has been now that WebRTC is available in major browsers, isn’t SIP going to go away?
Firstly, it’s important to differentiate between the common usages of SIP:
Access Layer (between SIP endpoints like softphones and desk phones)
Internal Network (within a service provider’s network)
Interconnects / Federation (between service providers)
As WebRTC is really aimed at the access layer, let’s rephrase this question to: Is WebRTC going to replace SIP at the access layer?
What is SIP?
Before trying to answer this surprisingly complex question, let’s define what SIP is for the sake of this discussion: SIP is a signalling protocol which defines a mechanism for setting up offer/answer sessions – phone calls – using SDP (along with some other stuff, but let’s ignore that for now). It’s mostly transport agnostic, defining UDP, TCP, and TLS based transports in the main protocol specification (see RFC 3261) and runs over SCTP (see RFC 4168) and even some attempts at DTLS (see draft-jennings-sip-dtls-05).
What is WebRTC?
The Problem with SIP
So at this point we have a browser with a media API (and offer/answer semantics), and the potential for creating a bidirectional socket to a server. But it’s missing a critical part to making/receiving voice/video calls: the protocol – the messages – sent between the server and the WebRTC enabled client.
SIP came about – as is the case with most standardized protocols – out of a need to let different entities implement various parts of a system and have a common and well defined mechanism for them to communicate with each other. The protocol allows any SIP-enabled device to work with a service provider that supports SIP (well, almost…that’s the idea anyway) because they both speak and understand the same protocol. They know what each message means and how that maps to what’s happening with a phone call. Without that, you wouldn’t be able to take a Polycom, Cisco, Yealink, Panasonic, or any other SIP-compatible phone and make it work with the Jive Cloud platform unless the phone manufacturer had implemented whatever proprietary protocol we invented – or Jive had implemented the manufacturer’s proprietary protocol they had invented.
It is important to note that this is because Jive’s code runs on Jive’s servers, and Polycom’s code runs on Polycom’s phones. Jive doesn’t have any way to run code we write on Polycom phones, and Polycom doesn’t on Jive’s Platform. The same is true with any generic VoIP (SIP) applications on your laptop, desktop, or mobile phone.
There are many times we have wished we could have! Every vendor does things slightly differently, and we’re really at the mercy of the phone vendor when we discover bugs in how they implement SIP. It often involves multiple months of waiting for a new version of the firmware, which we then have to deploy out to customers after extensive testing. It’s not a quick turnaround.
Additionally, there are many features we’d love to offer customers which we can’t because the phone simply doesn’t support them. We can’t make a phone from vendor X do custom phone feature Y unless there is a defined protocol mechanism for doing it. Some vendors implement some custom functionality and protocols (or extensions to SIP), but that means the feature is only available to customers who purchased that specific phone model/version. In short, Jive can only innovate to a certain point without requiring vendor specific enhancements. Sadly, there are no strong business drivers for the phone vendors to implement hundreds of small features for a single service provider.
The Advantage of WebRTC
Today, SIP is commonly used as the protocol run over websockets and the offers/answers fed into the WebRTC API to negotiate audio/video streams. This is mostly because phone providers already have a publically accessible, scalable, secure, and reliable SIP infrastructure – so adding another transport layer (websockets) on the top is pretty simple. Also, there are a number of open source SIP libraries available, making deploying a SIP-enabled WebRTC client quick and easy.
So, is SIP Going Away?
Over the longer term, will people carry on using SIP as the signalling protocol over websockets when doing WebRTC? Who knows, and frankly, it’s a totally irrelevant question when it comes to a customer interacting with their service provider’s web client.
The service provider (like Jive) writes the code that runs on the client and the server, so what protocol they use ultimately makes no difference. I’m sure some will use SIP, and some will use their own protocols, especially in more traditional telcos where they don’t do any internal development and instead outsource everything to the likes of Ericsson, Cisco, Alcatel Lucent, Nokia Networks, Acme Packet, etc. I believe there will continue to be strong drivers from the telcos to use a standard protocol so there isn’t a vendor lock in.
To enable innovation, Service Providers will continue to offer basic SIP signalling. Without it, it won’t be possible to take a third-party voice/video application and start using it with your service provider – as each service provider would need custom support added into the application. Without the standardized protocol like SIP, you wouldn’t be able to take an off-the-shelf product like a door entry phone and make it work with something that isn’t written by the same vendor as the phone itself.
It would be nice to think in a few years, after we’ve had more experience with deploying WebRTC that some better alternatives will come around and be as commonly implemented as SIP. I would welcome the change, as it will enable us to use off the shelf servers and client libraries to take care of many of the complexities of asynchronous communications protocols. But we’re years away from that so far, and we’ve already got SIP.
I also don’t see too many uses cases right now where there needs to be third party integration from one web app to another to interact with different networks/federations. There is going to be a lot of work to do here to allow such federation/integration.
So, back to the question: is SIP going away between code running in web browsers and the service provider’s network? Perhaps, because each provider can do their own thing without regard to anyone else. SIP is a beast, and there are only a handful of great software engineers in the world that truly understand its subtleties (some of them work at Jive, and – if you’re interested – take a look at http://jive.com/careers/). But for now, I think SIP is here to stay.