The first post we published on webrtcHacks was ‘A Hitchhiker’s Guide to WebRTC standardization’ (July 2013) where we gave some initial insight on activities in the 3GPP around WebRTC and IMS. Since then the situation has certainly evolved (well, probably not as fast as some would have expected). Since we regularly receive emails asking about the status/progress on WebRTC standardization within the 3GPP, we spent some time with our friend Antón Román, CTO at Quobis and author of the popular post ‘Anatomy of a WebRTC SDP’ to summarize the current status of the ‘WebRTC access to IMS’ effort.
Why add WebRTC to IMS
As discussed in several blogs, many traditional telecom operators have something to say when it comes to WebRTC. Some are exploring how to become Identity Providers. Others are willing to expose part of their infrastructure to third parties via developer API exposure and QoS supported TURN-as-a-Service. Many are launching multiple OTT strategies that involve WebRTC in one way or another. Nearly ALL major telcos playing with this technology are exploring ways to provide WebRTC-based access to the existing legacy infrastructure/services they already have in place. Their existing real-time communications infrastructure is or will be IMS based in most cases.
IMS folks have been trying to open up the network to Internet for years. The massive popularity of OTT services is putting even more pressure on them to do this effectively. The concept of APIs that third parties can use to interact with IMS services has long been envisioned as the magic potion to open IMS to the same levels of innovation that occurs on the Internet. To date, these IMS API exposure efforts have not been very popular and have yet to generate significant income. WebRTC can bring a breath of fresh air to IMS by enabling the infrastructure to deliver services directly from almost any device that has a browser. In other words, WebRTC allows operators to definitively untie their services from physical devices. Given this, the 3rd Generation Partnership Project (3GPP) started the technical definition of a solution for a WebRTC client to access to IMS networks through the Internet.
WebRTC Access to IMS?
There is an ongoing effort at the 3GPP named ‘WebRTC Access to IMS’ with 3GPP TR 23.701 as its main architectural output to date. The TR 23.701 work in progress is targeting release 12. This document contains a study on the potential modifications of the IMS architecture in order to enable WebRTC-based clients to access IMS. A number of architectures have been proposed over the past few months – several companies have proposed a total of seven architectural proposals/solutions. Recently a starting reference architecture was selected (for reference, this can be found in Annex A and it’s meant to be incorporated as part of TS 23.228 Rel-12). While the architectural work is the main focus of this article, it’s worth mentioning there is also ongoing effort in other areas like security (see 3GPP TR 33.871 Study on Security for WebRTC IMS Client access to IMS’ for an example).
The main goal for this effort it to define how can WebRTC clients have access to IMS through mediation functions for signaling and media – i.e. WebRTC IMS Gateway functions (see here for Lorenzo Miniero’s post on WebRTC gateways). The specification covers not only for audio and video but also protocols like MSRP, BFCP and T.140. It’s worth mentioning that during the initial stages of this effort, it was discussed whether to cover only the access portion (UNI) or also the interconnection (NNI) – it was decided to focus only on UNI for a number of reasons including regulatory ones.
If you’re following this blog, you may already know that WebRTC does not define any signaling. According to the discussions, it seems that SIP over WebSockets (Victor‘s RFC 7118) is the preferred approach in this architecture. However, other signaling options are also allowed in this release, such as a REST based interface, JSON over WebSocket or any other HTTP-based mechanism.
Also related to this, the preferred model to transport complementary protocols like MSRP, BFCP and T.140 is the WebRTC DataChannel. DataChannel certainly provides a number of benefits, especially when dealing with real-time media and/or peer-to-peer scenarios. However some see the DataChannel as an overkill for non real-time data (like MSRP or BFCP) in Client-to-Gateway controlled environments. Because of this, simpler and more pragmatic approaches like MSRP over WebSockets and BFCP over WebSockets are also allowed (in fact few weeks ago the IETF BFCPbis WG agreed to move forward with this document — you can see our presentation here). You can experiment with DataChannel and WebSockets using this demo. Another approach is to make the WeRTC gateway itself a MSRP/BFCP endpoint – from the core perspective – and to just expose a REST API or JSON interface towards the WebRTC-based endpoint.
The following diagram depicts the reference architecture adopted based on the 7 different suggestions:
Let’s take a look at the main elements:
WebRTC IMS Client (WIC)
User Equipment (UE)
The UE is the device or application used by the subscriber to interact with the IMS core to make and receive calls, send receive IM, presence status, etc. Thanks to WebRTC technology, the UE can be a Web application (WIC in IMS terminology) running on a browser with WebRTC capabilities.
WebRTC Web Server Function (WWSF)
The WebRTC Web Server Function can be located within the operator network or within a third party network. It is the first element contacted by the user and and from where the Web client (WIC) is downloaded.
When it comes to commercial implementations, this can be a very simple and limited Web Server, either running independently or as part of a gateway infrastructure which is simply hosting the WIC. Alternatively it can implement advanced functions or be integrating with other elements deployed in the core network. Some of these options include:
- Identity providers for managing web-based identity
- HSS for synchronisation/mapping of Web and IMS identities
- Application Servers for integration with API-based services,
- Authentication servers for controlling access.
- Active Directory for synchronization of contact lists,
- OSS and BSS integration for end-to-end network management and element control
Some refer to the WWSF as the WebRTC Application Controller (WAC).
P-CSCF enhanced for WebRTC (eP-CSCF )
For those familiar with IMS, the P-CSCF is a well-known element. The P-CSCF is the entry point of the SIP requests in the IMS system from the UE . To support the WebRTC client the 3GPP proposes to add the capacity to receive SIP over Websocket (SIPoWS) as defined in RFC 7118 to the P-CSCF. SIPoWS is the only mechanism that is explicitly mentioned, but the specification does leave the door open to other signaling alternatives, such as JSONoWS. In short, this function is the signaling gateway which adapts whatever signaling is used on the WebRTC-side to standard IMS-SIP towards the core.
IMS Access GateWay enhanced for WebRTC (eIMS-AGW)
Similar to the signaling gateway, the eIMS-AGW is a standard IMS-AGW which supports WebRTC media as defined by the IETF. This is essentially the WebRTC media gateway function that must preform several adaptations:
- DTLS-SRTP – DTLS on the media-plane is used in WebRTC exchange the keys that will be used to encrypt the SRTP flows in while SDES used in IMS exchanges the keys on the signaling plane if encryption is used
- DataChannel – relay DataChannel data and potentially convert MSRP or BFCP to the DataChannel or relay this data via other web-oriented means (more on this below)
- Audio/video transcoding – only VP8 codec for video is supported today so it is necessary to translate to H.264 which is the codec supported by the IMS UEs with video capabilities
- RTCP Multiplexing – WebRTC supports multiplex of both audio/video and RTP/RTCP over the same RTP session and port, this is not supported in IMS so is necessary to perform the demultiplexing
In addition to providing WebRTC-complaint support toward the UE, the eIMS-AGW must also support negotiating ICE candidates including STUN and TURN.
Data-flows and the DataChannel
When MSRP is requested, this element can either behave as:
- MSRP B2BUA if DataChannels or WebSockets are used or
- MSRP agent if signaling-plane models are used – e.g. REST API being translated into MSRP.
Similarly the same applies to BFCP, where the eIMs-AGW performs transport level interworking between BFCP over DataChannels and WebSockets to other BFCP transport options supported by IMS (most of the implementations are based on TCP but UDP-based transport will be part of the soon-to-be published new version for the RFC).
IP Connectivity Access Network (IP-CAN)
The IP Connectivity Access Network is simple the IP network used to reach the IMS core from the UE. It can be LTE for mobile devices (note this is not VoLTE) but also DSL and Wireless LAN/WiFi.
Policy and Charging Rules Function (PCRF) and Policy and Charging Enforcement Function (PCEF)
The PCRF (Policy and Charging Rules Function) is the element of the IMS architecture which supports policy and charging control decisions based on session and media-related information obtained from the P-CSCF. The PCRF speaks Diameter with other element, the PCEF (Policy and Charging Enforcement Function) which performs a DPI (Deep Packet Inspection, an analysis the traffic) and decides based on the rules whether the traffic is allowed or not. Since WebRTC media runs encrypted and could even be multiplexed over ports 80/443, DPI might be tricky.
H/V-PCRF in the diagram refers to Home PCRF and Visited PCRF in the case of a roaming subscriber.
Network Address Translation (NAT)
The WebRTC Client (WIC in WebRTC terminology) will be normally behind a NAT element so a NAT box has been included in the diagram. ICE is the protocol implemented by WebRTC to enable two-way SRTP flows behind NAT so the media gateway used to exchange media flows with the IMS core must support it.
In IMS terminology a reference point defines the communication between two different entities in the architecture. The most important element which is defined in a reference point is the protocol that will be used. In the reference architecture, 7 interfaces are referenced. Three of them are WebRTC specific:
|Used to download the WIC HTML and JS files from the browsers via HTTPS
|SIPoWS or any
|Signaling mechanism used between the WIC and the network
|Corresponds to the group of protocols defined defined by the IETF RTCWEB for media transport
SIPoWS (RFC7118) is the protocol described by the 3GPP for W2 in the document as it is an extension of Gm – the reference point between existing UE’s and the P-CSCF which uses SIP. However the specification is open to the use of different protocols (e.g. JSONoWS protocols and REST APIs)
The other four interfaces mentioned were already present in earlier IMS releases:
|Exchanges policy decision-related information
|Exchanges policy and charging related information
|Exchanges messages between the CSCF’s
|Instructs the eIMS-AGW to be ready to receive and send media traffic from the WIC
Many items are explicitly defined for further study in the specification or are omitted:
- Media multiplexing – running several audio/video streams on the same address:port is not allowed in this release
- QoS control methods for a WebRTC session – QoS is supported, but doing this on an internet connection is challenging to impossible
- User identification authentication – this is called out for future study
- Trickle-ICE – called out for future study (see here for Emil Ivov’s post on Trickle-ICE)
- Decomposing the eP-CSCF – many vendors are implementing WebRTC gateway products independent of their P-CSCF elements and the standards may evolve to reflect that
- TURN – there is no explicit mention of TURN support anywhere in the specification although it was part of some of the solution recommendations that went into the specification (STUN is mentioned)
- Guest access for non-subscribers – this is not covered or identified as a use case
Commercial Implementation Observations
When it comes to commercial implementations, from what we are seeing in the field there are infrastructure providers which are implementing the signaling and media gateway as a standalone product (monolithic/composed approach). Others are are implementing it as independent components in decomposed approach with separate signaling (eP-CSCF) and media elements (eIMS-AGW). Others are simply implementing it as yet another feature of existing elements like an Access SBCs – in the past they provided access to H.323 and SIP-based networks, so here WebRTC is yet another access framework. The Iq reference point for connecting the eP-CSCF to the eIMS-AGW is defined as H.248, but in practice many vendors appear to be reusing existing communications mechanism to accomplish this which may not be H.248.
In future posts we will explain how registration, call setup and other procedures work, assessing areas like user identity and security. In the meantime, please leave a comment with any question you might have.