WebRTC and IMS

WebRTC – what a great technology! The simple technologies are the best. Thank you Google for open-sourcing it! Now the WebRTC is a part of the Mobile Web Initiative/HTML5  driven by W3C.

Some technologies that were originally defined in Mobile Web Initiative are now defined in separate specifications. The WebRTC is one of them:

Web Real-Time Communication – WebRTC is introducing real time communication as a standard web capability. In the past (just 2-5 years ago!) to create a conferencing or helpdesk solution costed a lot. Now all you need is a few pages of JavaScript (http://www.html5rocks.com/en/tutorials/webrtc/basics/#toc-tldr). In the near future we can just add some plugins in Joomla or WordPress and that will be all.

How is it possible? That’s because the most of the work was already done by developers of web browsers. Just try https://appear.in/realtimecommunication.

HTML5 ready browsers provide API to enable

  • Chat
  • Voice and Video calling
  • File sharing

as a standard content – so without plugins.

Well it’s nice, it’s working (although still in progress). WebRTC is being used by Google in their google hangout, most probably Amazon Mayday for Kindle Fire is based on WebRTC and many smaller players are following. For an enterprise business is this technology priceless. There are also some great solutions created with help of WebRTC which are focused also on other devices e.g.

Fluke Connect tm

or

Net Medical Xpress tm

 

So why we just don’t throw away all that uselessly complex stuff of IMS, VoLTE and (on the first place) RCS?

 

The thing is that WebRTC is only a technology, not a solution for all our pains.

The WebRTC is in fact standardized by two different bodies. The WebRTC itself is standardized by W3C  http://dev.w3.org/2011/webrtc/editor/webrtc.html and then there is also RTCWeb standardized by IETF http://tools.ietf.org/wg/rtcweb/.

When we would take a closer look on these standards from the Voice/Video communication perspective, we would find out that they are pretty flexible comparing to VoLTE. For example the WebRTC is supporting three types of identities: anonymous identities for ad-hoc communication (useful e.g. for e-shopping), web identities (e.g. Facebook, Amazon, Paypal accounts) and Telco Identities (MSISDN, sip/tel uri). WebRTC also doesn’t directly define what signalling protocol shall be used.

This has a reason. Each web service, each web application has its own way, how to handle its users. We need to handle customers of some eshop in a different way than doctors in a hospital who are connected to the internal communication system. A bank or an insurance company will use a different features than a police helpdesk. Not talking about all those Facebooks, Googles etc.

The WebRTC is providing web developers with features related to the user experience. However the application logic will differ system to system, solution to solution.

It doesn’t mean we have to reinvent a wheel. When we want to support a mobile communication we already have a good – access independent – framework, which can be used. Sure, the IMS. Mobility is also a thing which is not covered in the WebRTC. Mobile operator can integrate their VoLTE/VoWifi solution with the WebRTC. Users then can use along with their smartphones also a web browser and they’ll still have their public identity (mobile number, sip uri), they’ll be reachable, they can call as from the phone, they can use their addressbook, voicemail, chat history, etc. Even more it is possible to integrate their OTT accounts with their mobile account (see OAuth). Makes sense?

WebRTC - IMS

WebRTC – IMS

From the IMS point of view the WebRTC communication is the same as any other. In IMS we don’t care much what the access technology is. But sure, SBC cares and we need to add some more interfaces and functionalities there.

The WebRTC GW allows to combine the power of VoLTE with a dedicated information system (see our update). WebRTC GW (interworking function) can be either directly part of the A-SBC or can be a standalone system. In the second case it is responsible for the web authentication, WS-SIP translation and registration on behalf of the user. The advantage is that we don’t need to upgrade an existing SBC. On the other hand the manipulation with media can be more difficult/expensive than if we have one complex solution.

The reference architecture for WebRTC – IMS communication is described in 3GPP TR 23.701 and 3GPP TR 33.871.

WebRTC IMS integration

WebRTC IMS integration

or

WebRTC GW does WS-SIP

WebRTC GW does WS-SIP

 

We have several new elements and interfaces in the network:

  • WIC – WebRTC IMS Client
    • WebRTC capable browser or browser like program running web application that allows a user to access IMS services.
  • WWSF – WebRTC Web Server Function
    • web server contacted by the user either explicitly (url) or implicitly (clicking on app).
  • WAF – WebRTC Authorization Function.
    • IMS network may authenticate the WIC indirectly using a third party authentication service. The WWSF requests an authorization token from the WAF  which asserts the user’s identity. The WWSF forwards the token to the WIC which then includes it in the SIP register request for verification by the A-SBC.
    • The WAF can either authenticate the user itself as part of the token issuance process (similar to Authentication proxy used for Ut interface), or it trusts the user identity supplied by the WWSF. In the latter case the WWSF is assumed to have authenticated the user prior to sending the token request.
  • eP-CSCF P-CSCF enhanced for WebRTC
  • eIMS-AGW IMS-AGW enhanced for WebRTC

Note that the specification is not final yet.

The WebRTC control plane data is transferred over WebSocket or Http and is controlled by the WIC application running in the UE. The WIC application can implement any signalling protocol such as SIP, XMPP or RESTful HTTP or JSON over WebSocket. The selected protocol has to support SDP.

For the NAT traversal ICE shall be used.

The WebRTC user plane consists of media channels for audio and video and data channels for peer-to-peer communication of arbitrary data. The user plane is controlled by the WebRTC compliant browser and therefore much more standardized.

There is a very strong emphasis on the security so we always use secure variants of protocols (DTLS).

More about WebRTC-IMS integration can be found in the WebRTC GW post or in GSMA WebRTC to complement IP Communication Services whitepaper.

Advertisements

12 thoughts on “WebRTC and IMS

  1. Pingback: VoLTE or RCS Voice Call? | Real Time Communication

  2. Pingback: A magic box called SBC | Real Time Communication

  3. Pingback: Whatsapp Voice | Real Time Communication

  4. Pingback: Crack the NAT | Real Time Communication

  5. Pingback: WebRTC GW | Real Time Communication

  6. Pingback: Headers in User-centric networks | Real Time Communication

  7. Pingback: IMS from 10.000 feet | Real Time Communication

  8. Pingback: News: Are the Codec Wars over? | Real Time Communication

  9. Pingback: News: WebRTC – the way to go | Real Time Communication

  10. Pingback: VoLTE Illustrated: Beginners Guide | Real Time Communication

  11. Pingback: News: The World is to be All-IP | Real Time Communication

  12. Pingback: News: 2016 Summary | Real Time Communication

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s