I just returned from the WebRTC Conference and Expo and SIP (Session Initiation Protocol) was a topic of conversation right from the first developer session: "Deploying WebRTC Successfully - The Big Issues." The conversations continued across the tradeshow floor and on to chats in the hallways. For a conference about WebRTC, I was suprised at the prevalence of SIP. For more information about the expo click here. But first, a little about SIP and WebRTC. SIP (Session Initiation Protocol) is a protocol for the signaling of audio and video calls. SIP formalizes a telephone call metaphor with messages that describe major events in the life of a call: INVITE (call), TRYING (ringing), BYE (hangup). A sub-standard that is employed by SIP is SDP (Session Description Protocol). SDP encodes the properties of a communication endpoint on the internet. It describes its IP address and the port the media server is listening on. It describes the codec the endpoint can use and it describes other servers that the endpoint uses to establish connectivity (it's ICE candidates, the STUN and TURN servers). In summary: SIP is a protocol that uses SDP descriptions to describe its multimedia endpoints. The WebRTC standards adopted SDP but specifically not the SIP protocol itself. SIP is typically transported over UDP packets or via TCP in a connection-oriented mode. With the exception of WebRTC media, browsers do not communicate via UDP. And going forward, the W3C has settled on one connection-oriented protocol for browsers and that is WebSockets. (See http://www.html5rocks.com/en/tutorials/websockets/basics/] As a note, there are a number of implementations of SIP over WebSockets. (See for example JSSIP.) At that first developer session, one of the attendees stated that he thought the absence of SIP from WebRTC was specifically to enable web developers to go beyond the protocols of the old phone network. One speaker suggested use a pub-sub service like PubNub to establish sessions. Prior to the conference, I felt that web-oriented technologies would be used for signaling with WebRTC. However, I heard a lot of good cases during my three days there for SIP. These cases were, for the most part, regarding interoperability with legacy equipment and the non-web world. Additionally, there may be issues of scaling the signaling plane that SIP technology has already encountered that the real-time web has not yet addressed. I think that over the next year we will continue to hear about SIP from people with a telecom industry background but will not hear so much about it from the folks coming from the web developer world. These two communities are interacting in new ways to deliver WebRTC experiences. Time will tell if SIP is behind WebRTC experiences of the future, or if platforms presenting WebRTC experiences use something else entirely.

If you enjoyed reading this post, you will love all the other content shared in our developer community!