5 comments on “The IMS approach to WebRTC

  1. I’m afraid this article typifies the problem that the telcos have. Not a word about the user benefits of combining webRTC with IMS (see The wrong side of history ). That may be because there are very few sensible webRTC/IMS use cases.

    Even if it were desirable to link webRTC with IMS, SIPoWS is absolutely the wrong way to do it. Embedding a full SIP agent into a browser has 2 huge problems – firstly you risk exposing the fragile IMS core to any random SIP messages that Jo-random-Javascript-Hacker feels like crafting up. Think of the fun she can have with reverse billing of 800 numbers or prison phones. You’ll need an utterly paranoid SBC protecting the IMS. The flip side is also true, you are exposing the browser based SIP stack to 15 years of accumulated edge cases, it will need to cope with all the PSTN fun like early media, PRACKs a variety of messages and implement all the magic incantations that make SIP (mostly) work.

    The sad thing is that the tighter you integrate webRTC to IMS (or other PSTN legacy) the less valuable they both become. You put telephony in an environment where nobody dreams of paying by the minute. You also eliminate (or at least hugely complicate) the main benefit of webRTC – using the rich context of web site to make it easier and quicker for the user to achieve their goal.

    • I was just looking at the 3GPP IMS TS 23.228 Annex U specs again. It is interesting to see the amount of coverage the spec (section U.1.1.3) gives to the brand new WebRTC elements vs. the “enhanced” ones:
      Elements Words
      WIC 98
      WWSF 158
      eP-CSCF 306
      eIMS-GW 210

      The “e” items get 66% of the attention. The new items get 33%

      One could speculate that is because new items are easy or because they old items are what really matter to the 3GPP. Either way, this seems odd to me vs. how the rest of the industry is treating the client-side aspects.

    • Hi Tim. I tend to agree with you on the telcos overly standadizing things that probably don’t need it, and the challenges that SIPoWS + IMS introduces. Personally I feel there is still some amount of value that could be provided by IMS+WebRTC. For instance in an RTC service whereby my primary access (via a mobile phone) gives me things like access to a global directory, seamless and reliable mobility, trusted security, built-in connection to emergency services, and reliable reach-ability…but having a secondary access (via WebRTC) available where I could forgo some of the properties of the service (seamless mobility, emergency services, reliability) for the sake of convenience and ease-of-use. As you say, no one would ever want to pay (directly) for the WebRTC session, but might keep the overall subscription if it were provided.

      I think the problem facing telcos is coming to grips with the diminished value of just being able to “make a call”. With the diverse ways people will communicate in a world of WebRTC, this means there are fewer use cases needing something like IMS. They can continue to provide value to certain RTC sessions, but they must understand that not every call needs the telco (as it was in their hay day). The difference between a session needing all the heavy device and network integration, vs. just a web server and a browser widget, depends on the context the user is in, and their reason for wanting the session.

  2. I think it is dangerous trying to tight too much WebRTC with IMS as it would be delaying whatever telco attempt to use WebRTC anytime soon.
    UNI is the approach, and when we talk about IMS we talk about VoIP, the same consideration works from VoIP servers.

    As more independent could be the Voice with the WebRTC-GW exposure as better to boost the ecosystem.

    As example, we built a WebRTC exposure for Nexmo VoIP lines (for TadHack event) without any integration with Nexmo server.


    The same can be done with whatever VoIP provider or telco IMS based voice lines. Why we need to wait to new standards, wait for IMS implementation, upgrade? to be late once again?

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.