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:
- HTML Working Group – HTML Canvas 2D Context
- Web Apps WG – Web Messaging, Web Workers, Web Storage, WebSocket API, Server-Sent Events
- IETF HyBi WG – WebSocket Protocol
- WebRTC WG – WebRTC
- W3C Web Media Text Tracks CG – WebVTT
HTML5 ready browsers provide API to enable
- 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.
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?
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.
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.