The 3rd Generation Partnership Project (3GPP), the uniting body of telecom standard development organizations, has taken notice of WebRTC. And that means WebRTC is becoming enough of a pain – I’m sorry, I mean it has enough support – that they now need to address it. Why is this happening?
Well, IMS is trucking along, and we’re starting to see more VoLTE services. But beyond VoLTE, what about other applications on the IP multimedia subsystem (IMS)? To be fair, there are rich communication services (RCS), but most of the programs running on LTE networks have been over-the-top (OTT) apps such as WhatsApp. Carriers see WebRTC as a potential way to control subscribers again, and maybe take some of the OTT apps as value-added services market away from OTT providers. I wrote about this “less is better than zero” strategy earlier this month.
As such, the 3GPP is studying and starting to construct interoperability between IMS networks and WebRTC via a study called TR23.701. This study outlines potential modifications to the IMS architecture, and an obvious first necessary item is a WebRTC-to-IMS gateway, the eIMS-AGW, which I have written about on this blog before. Carriers require such a gateway to make sure the media from WebRTC (for instance, an Opus audio codec or a VP8/VP9 video codec) gets transcoded to an appropriate IMS codec.
Though that’s important, something missing from the study was a WebRTC-enabled media server, which I’ll call the eMRF, or the e-media resource function. There will be many peer-to-peer WebRTC calls that will not involve a media server, but for any kind of value-added service, there will need to be a media server involved. And since carriers view WebRTC as a way to control value-added services, I am surprised there is no mention of an MRF in this study.
Despite that oversight, there were other interesting items in the study, like the WebRTC web server (WWSF) and the eP-CSCF. The WWSF is a web server that serves HTTP(s), and given that WebRTC “calls” can be launched from a URL, adding this kind of network node makes sense. The eP-CSCF, which is essentially an IMS policy routing engine in the form of an SBC or IP-to IP softswitch, includes WebRTC signaling and roaming.
The ability to route and charge off of WebRTC info is important and potentially controversial because WebRTC endpoints could be SIM-less. There really isn’t a phone number or even a SIM associated with a WebRTC call as it’s more of a peer-to-peer play, though it could be URL-based calling.
I’ve added these elements into my IMS diagrams since it will be important to finalize WebRTC interactions with IMS. I also added a WebRTC item to the application server box, as there will likely need to be WebRTC media interactions there, too.