Monday 3 December 2012

WebRTC Conference and Expo 2012: Mapping SIP to WebRTC - a misunderstanding?

I was fortunate enough to attend the first WebRTC Conference and Expo in San Francisco last month.  This fascinating conference demonstrated the growing hype and interest around WebRTC.

One of the things I observed at the conference was a lot of discussion about "WebRTC obsoleting SIP" and "mapping SIP to WebRTC", both topics that seemed to indicate a misunderstanding of both SIP and WebRTC amongst those discussing them.

SIP and WebRTC are very different protocols (in fact WebRTC is a set of protocols).  SIP relates to the signalling plane and WebRTC to the media plane.  This means that SIP and WebRTC are complementary protocols not competing protocols.

There was a lot of discussion about WebRTC's ability to establish media sessions without signalling or server infrastructure - this is not possible.  When you use the PeerConnection API in a browser you get and provide SDP which needs to be exchanged by the peers to establish the media connection.  How can the peers exchange this SDP without signalling or server infrastructure?

It is clear that some signalling and server infrastructure is required for WebRTC, and this can take one of three obvious forms:
  • Proprietary HTTP/REST signalling
  • XMPP/Jingle over WebSocket
  • SIP over WebSocket
Each of these has advantages and disadvantages.  HTTP/REST signalling is very simple but as HTTP is a transaction (not a session protocol) dialog state must be maintained within the network - this could easily result in resiliency and scaling issues, or complex server infrastructure that replicates dialogs between servers.  XMPP/Jingle is a session protocol, but like HTTP/REST it is lacking in terms of support for common regulatory and privacy features[1].  SIP in many ways is the ideal protocol - the hint is in the name, "Session Initiation Protocol" - as well established extensions (such as outbound) provide resilience and scaling, while regulatory and privacy issues have long been catered for.

Some people indicated that they believed that the use of SIP with WebRTC would be limited due to its complexity and the unwillingness of web-developers to use it.  However, I am not entirely convinced by this argument.  A web-developer is unlikely to want to implement any of the signalling necessary for his WebRTC application, but he will make use of any good libraries that are available.  I believe that SIP will be extensively used in WebRTC applications as long as a good enough set of libraries are available so that web-developers do not need to deal with it directly.

[1] A lot of web-developers ignore regulatory and privacy requirements simply because the large OTT companies have not had to do anything yet.  "Yet" is the operative word here - regulations and privacy are important and cannot be ignored indefinitely.  Using a protocol like SIP for the signalling future proofs web apps and services.  With a good SDK using SIP for the signalling is no harder than using anything else.


  1. Peter,

    My assumption is that regulation is going to affect no more than 20% of the interactions in the future.
    As voice and video calling is relegated from a service into a feature by WebRTC, it will be easy to see a lot of use cases where these interactions need no regulation - think of a dating site/community that decides to use WebRTC for calling - do you need the same set of regulations than AT&T undergoes?

    SIP might have its place with WebRTC, but it is going to be a minor one.

    1. Hi Tsahi,

      I am afraid that a no more than 20% assumption is a little optimistic. Just take a look at something like the "Draft Communications Data Bill" here in the UK. This legislation will require additional data collection and retention of user activity by Internet service providers and mobile phone services, recording contact information for each user's webmail, voice calls, social media, internet gaming, and mobile phone contacts and store them for 12 months (retention of email and telephone contact data for this time is already required). This is expected to be enacted as law in 2014.

      This legislation as stands may place regulatory requirements on the new services WebRTC enables, and if not will doubtless be amended in the future to do so. There are many, many, parts of the world that are more aggressively monitored than the UK.

      As for SIP's place with WebRTC, as I mentioned above there are other reasons for using SIP relating to resilience and scaling. All of these things are possible with other protocols, but a lot of work has been done in these areas with SIP and why re-invent the wheel?

      I just don't buy the complexity argument against SIP because, not only is basic SIP not that complex, but developers will use libraries anyway. I suspect SIP will be used more than people think, and because it is handled in libraries, more than people realise.


    2. I forgot to add. I do agree that SIP will ultimately be used in a minority of WebRTC session establishments. However, I do expect this to be a significant minority in terms of size and importance.

      Most WebRTC use cases are going to be trivial applications, but even here I believe the use of libraries will mean that SIP is used more than one would expect.

      Where SIP will win out will be with the more complex (and to my mind more interesting) applications. Any service that needs (or might need in the future) things like parallel and serial forking of sessions, session hold and transfer, CDR-style data (so that service providers can monitor their service operation), rating (for premium services), and so on will benefit from a protocol like SIP.

  2. This comment has been removed by the author.

  3. Hi Peter

    Using SIP with WebRTC is a valid solution, but primarily for the use case where you need to integrate with a (regulated) SIP network, or where you want to replicate the kind of functionality that SIP signalling supports.

    WebRTC however is capable of enabling much more than that. That's what is so exciting about it.
    Yes absolutely it does need some kind of 'session' management associated signalling.
    But it doesn't have to be SIP.
    It doesn't have to be XMPP/Jingle or REST either.
    WebRTC application developers have the option of using an existing signalling protocol with WebRTC if it fits their needs, or they have a blank slate to develop their own, which best suites their needs.

    Sure we can label that as a proprietary protocol with all the negative connotations that has.
    Or we can see it as fertile ground for nurturing innovative uses of WebRTC which break the mould of real-time telecommunications services as we have been conditioned to think about them to date.
    And yes, these will be islands of communication, initially at least.

    If the services enabled by these proprietary protocols are successful, they will eventually become de facto standards, and may enter a more formal standardisation process.
    If they are not successful, then we as a community have not wasted the time and effort in speculatively defining (I would say constraining) the way WebRTC can be used.

    Regulation & privacy are interesting points. Whilst I accept the need for them in some situations, if all future communication services are to be subject to regulation and privacy requirements, we might as well shut the public Internet down right now, and go back to using BBS style technologies… as that is surely going to be the end result.

  4. I believe, all voice-video protocols, operators, carriers, services should have common peering one day (and should follow quality standards)

  5. I want to thank you for writing this article.This is great Article for me. It also more very informative & awesome. I expect more articles from you in future.
    Awesome information. Great Contribution to blog. I
    expect more articles from you in future. Keep it up!