Over the past weeks and months, I've had a number of people ask me if WebRTC is going to replace SIP. At first I didn't have a good answer -- I really didn't understand WebRTC well enough to do the comparison. But now I do, and I'm happy to share my thoughts.
Before I do weigh in on the SIP vs. WebRTC question, however, let's be sure we all have the same understanding of each. Allow me to provide a quick explanation.
WebRTC, formally known as Web Real-Time Communications, allows Web browsers and other HTTP-based applications to send and receive real-time media. For instance, WebRTC allows you to make audio or video calls from a Web page. With WebRTC, the media is sent directly and securely from your device to the recipient's device.
If you've been involved in telecommunications for a while, you might be saying, "I thought we could already do that." The answer is "Yes," but prior to WebRTC you would have needed to download an application or use a browser plug-in like Flash.
Several problems come with this pre-WebRTC approach. Downloading applications can create security issues. Also, an application that works on a Microsoft operating system may not work on an Apple or Android OS.
The same goes for plug-ins: Flash works great on both my Windows PC and iMac, but it's not supported on my iPhone or iPad. With WebRTC, the technology is native to the browser itself. There is nothing to download or install.
WebRTC is concerned with two major tasks. It needs to acquire audio and video components on your device -- for example, your PC's video camera, speakers, and microphone. It then sends that data to the far end. This requires WebRTC to know how to navigate through firewalls and understand network address translation (NAT) issues.
Finally, while WebRTC developers were initially concerned with voice and video, they are now designing the technology to support all forms of peer-to-peer data sharing.
Let's Talk Signaling
Read the previous paragraphs again and you will see that WebRTC is all about media -- signaling never comes up. But something needs to ring the far end. Something needs to answer a ringing call. Something needs to release that call when it ends.
WebRTC does not define a signaling protocol. That is not because the developers were lazy or simply forgot that you need to signal another device before you can send media to it. Signaling was left out of WebRTC for two good reasons:
1. Different applications may require/prefer different protocols. The WebRTC working group did not want to lock it down to something that may turn out to be inadequate for all its uses.
2. WebRTC runs in a Web browser, and support for signaling would require that Web pages be stateful. This becomes problematic if signaling is lost each time a page reloads.
1. Different applications may require/prefer different protocols. The WebRTC working group did not want to lock it down to something that may turn out to be inadequate for all its uses.
2. WebRTC runs in a Web browser, and support for signaling would require that Web pages be stateful. This becomes problematic if signaling is lost each time a page reloads.
Since signaling is required for call setup, WebRTC solutions must include a signaling server of some type. Again, WebRTC itself doesn't care how that server implements signaling, but it must exist somewhere in the network -- which brings us to SIP, or as it's formally known, the Session Initiation Protocol.
SIP defines signaling. In fact, that's all SIP defines. A separate protocol, the Session Description Protocol (SDP), defines media. SIP and SDP work together to create, manage, and tear down media sessions of any type.
Would you believe that WebRTC also uses SDP as part of its media setup? Like the developers of SIP, WebRTC developers saw something that worked and chose to reuse rather than reinvent.
Winner, Winner?
Let's go back to my original question: Does WebRTC replace SIP?
While the use cases for WebRTC and SIP overlap, one does not clearly replace the other. In some situations, WebRTC may even use SIP for its signaling agent. Of course, WebRTC enthusiasts might phrase that as "SIP uses WebRTC for its user interface." Regardless of your technological religious affiliation, if you look you'll find opportunities for synergy between the two.
For me, the ultimate answer to the question of one over the other comes down to this: Do you like apples more than oranges? While both are fruit, they are very different and each serves a role that the other cannot fill.
When I think about SIP, my mind visualizes enterprise SIP trunks, long carrier SIP trunks, SIP applications, SIP routing, and, yes, SIP multimedia endpoints. I can point to thousands of rock-solid implementations that use some or all aspects of SIP. However, I do not think of a Web browser as my user interface.
When I think about WebRTC, I think plug-in free, HTTP-based, multimedia endpoints. I don't think trunks, routing, or applications. That's not to diminish what WebRTC accomplishes. The applications built with WebRTC may one day force us to rethink what it means to make a telephone call. However, WebRTC won't replace the need for SIP or a SIP-like protocol. These two technologies are mostly different and somewhat the same, but both are very important.
Unlike certain political parties or nation states, SIP and WebRTC can peacefully coexist. Better yet, one can reinforce the power and importance of the other.
In other words, winner, winner, chicken dinner. We really can get along, after all.
Andrew Prokop writes about all things unified communications on his popular blog, SIP Adventures.
Follow Andrew Prokop on Twitter and LinkedIn!
