WebRTC is starting to gain traction, and you can tell that for one reason.

It’s not because we have trade shows dedicated to it now, or the steady increase of WebRTC-related press releases hitting the wires. It’s not because we’re seeing real-world deployments, such as the Amazon Mayday app. And it’s not even because Dialogic (News - Alert) announced at the Atlanta WebRTC Conference and Expo in June that it had more than 90 active engagements with its PowerMedia software-based media server product.

No, the main reason why we know that WebRTC is gaining traction is because the 3^rd Generation Partnership Project has taken notice. This means that WebRTC now has enough support to impact IP multimedia subsystem environments.

IMS is humming along, and 2014 looks to be the year of voice-over LTE deployments. But beyond VoLTE, what about other applications on IMS? To be fair, there are rich communication services, but most of the apps running on LTE (News - Alert) networks are over-the-top apps like WhatsApp. Carriers see WebRTC as a way to take back control of subscribers, possibly by offering OTT apps as value-added services that they provide.

With that kind of thinking in mind, the 3GPP has started to architect interoperability between IMS networks and WebRTC. This work is being documented in 3GPP’s TR23.701 report, which outlines potential modifications to the IMS architecture, including, of course, a WebRTC-to-IMS gateway, described in the group’s parlance as an eIMS-AGW. A basic use case for eIMS-AGW would be someone initiating a call from a WebRTC browser on his smartphone to either a feature phone or a smartphone. eIMS-AGW is required to ensure that the media from WebRTC, such as an Opus audio codec or a VP8/VP9 video codec, gets transcoded to an appropriate IMS codec.  Obviously, since the whole communications world isn’t yet a WebRTC world, connecting and transcoding to other than WebRTC is a big deal.

Beyond eIMS-AGW, 3GPP’s report addresses several items that will be critical to WebRTC-IMS interoperability, such as the WebRTC web server function, which is a web server that serves HTTP(s) and enables WebRTC “calls” to be launched from a URL. The study also takes a look at eP-CSCF, which is essentially an IMS policy routing engine in the form of a session border controller or IP-IP softswitch that includes WebRTC signaling. eP-CSCF also incorporates roaming, a factor that is rarely brought up in WebRTC conversations but deserves to be.

The ability to route and charge off of WebRTC information is important, but potentially controversial since future WebRTC endpoints could be SIM-less. Because WebRTC is more of a peer-to-peer play, it does not require a phone number or even a SIM. So if WebRTC takes off, the smartphones of the future may not even have phone numbers, which would bring up some interesting questions for carriers regarding roaming charges.

While the study nails it for the most part, one missing item is a WebRTC-enabled media server (let’s call that the eMRF to keep the parlance). While media servers aren’t required for basic peer-to-peer calls, they will be necessary for any kind of value-added service, be it a conference call, voice or video mail, text-to-speech, or digit detection. Additionally, if a carrier wanted to insert text to the media stream to obtain advertising revenue, a media server would be required.  

More importantly, the future of value-added services is likely not in specific voice-based or text-based services, but in web-based services that include some aspects of real-time voice or video.  A media server will be required here as well. Since carriers view WebRTC as a way to control value-added services, 3GPP needs to incorporate eMRF into its architecture.

The traction that WebRTC has obtained to date in the industry is substantial, but there is still a ways to go. To realize the full potential of WebRTC, interaction with other standards such as IMS will be crucial.

Jim Machi is vice president of product management at Dialogic