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.
If you want more background, last year Victor had the opportunity to moderate a couple of interesting panels on WebRTC for IMS – you can find the slides here and here.
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.
Reference Architecture
The following diagram depicts the reference architecture adopted based on the 7 different suggestions:
Functional Elements
Let’s take a look at the main elements:
WebRTC IMS Client (WIC)
WIC is the WebRTC Javascript based application. The WIC application is downloaded from the WWSF within the operator network or a third party network. It provides application logic and WebRTC API calls to access to the communications services of the IMS. The WIC functions on any device supporting a browser (or equivalent JS execution environment for mobile apps or set-top boxes) that supports WebRTC over any internet-connected IP access network .
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.
Reference points
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:
Point | Nodes | Protocol | Description |
---|---|---|---|
W1 | WIC<=>WWSF | HTTPS | Used to download the WIC HTML and JS files from the browsers via HTTPS |
W2 | WIC<=>eP-CSCF | SIPoWS or any | Signaling mechanism used between the WIC and the network |
W3 | UE<=>eIMS-AGW | DTLS-SRTP+STUN | 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:
Point | Nodes | Protocol | Description |
---|---|---|---|
Gx | PCRF<=>PCEF | Diameter | Exchanges policy decision-related information |
Rx | eP-CSCF<=>PCRF | Diameter | Exchanges policy and charging related information |
Mw | eP-CSCF<=>I/S-CSC | SIP | Exchanges messages between the CSCF’s |
Iq | eP-CSCF<=>eIMS-AGW | H.248? | Instructs the eIMS-AGW to be ready to receive and send media traffic from the WIC |
What’s missing?
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
- WWSF to eP-CSCF communication – this mechanism is not defined but could be required in some applications to coordinate what HTTP/Javascript is sent to the user or the eP-CSCF could use the WWSF as authentication/identity server
- 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.
{“authors”, [“Antón Román”, “victor”, “chad“]}
Tim Panton says
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.
Chad Hart says
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.
Reid Stidolph says
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.
juan says
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.
http://webrtc.solaiemes.com/tadhack/
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?
Victor Pascual says
You can find an update on the architecture here: http://www.slideshare.net/victorpascual/webrtc-standards-update-jul-2014/34/