At Daitan, we have been implementing WebRTC-related projects over the past 4 years for organizations of all sizes, from startup companies to large carriers. Among the challenges and lessons learned, there is one which stands out – interoperability. Each case has it’s own unique challenges, so I thought it best to share a few examples and explain our approach.

Case Study 1: WebRTC Interop with Telecom IMS for RCS and VoLTE

First, before we get into the case study itself, let me explain the acronyms:

  • IMS stands for IP Multimedia Subsystem or IP Multimedia Core Network Subsystem (IMS), which is an architectural framework for delivering IP multimedia services in the telecom industry.
  • RCS stands for Rich Communication Services, which allows for inter-operator communication services based on IP Multimedia Subsystem (IMS).
  • VoLTE, or Voice over LTE, is a standard for high-speed wireless communication for mobile phones and data terminals. It is based on the IP Multimedia Subsystem (IMS) network.

Project Requirements

The project involved designing and implementing a WebRTC client and gateway to allow a user to register in the mobile operator’s network from the web browser and then to make and receive voice and video calls with other users in the network that were using an RCS or VoLTE client.

As mentioned in our previous blog “WebRTC – Are we there yet?” there are 5 common areas of interoperability that seem to come up time and again:

  • Signaling
  • Call Control
  • Identity Management
  • Transcoding
  • Security

Let’s take a look at how these manifested themselves in this case.

Solving Signaling, Identity Management & Call Control

Starting with Signaling – SIP is the standard protocol for signaling in the client’s IMS network. As we learned last time WebRTC does not define any particular standard for signaling so it is up to the developer to implement something.

In this case we implemented SIP in the Web client so that we had flexibility to implement the minimal session control and call control features, as well as handle the user logging into the network. However, the SIP path from the Client to the gateway must be implemented over WebSocket, whilst the SIP path from the gateway into the network must be over UCP/UDP in order to be compatible with the network.

One particular challenge in this case, which is not uncommon when making different SIP-based systems work together, was that the SIP headers implemented in the IMS network used optional, undocumented parameters that needed to be discovered. SIP is a flexible protocol, which is generally good, but can be challenging to debug if things are not documented clearly.

A SIP proxy was put in place in order to handle the conversion from Websocket to TCP/UDP as well to do the necessary mediation in the SIP protocol.

Identity Management was handled by the carrier infrastructure in this case. Since the WebRTC client was required to assume the identity of a mobile subscriber then it was necessary to register the user through the client when he first opened the app. Since SIP was already in place in the WebRTC client we could handle this in a standard way and once the user was registered in the client then the WebRTC client endpoint was able to start and receive calls.

Call Control was also relatively straight forward since we had already decided to use SIP in the client side for signaling. What remained was to implement the required call controls in the WebRTC client and provide an SDK that was simple for a web developer to use.


It is quite common (as was the case here) that the third party endpoint implemented was H.264 for video, and so we were able to take advantage of the fact that WebRTC now supports this codec.
In other cases though, and to design for future expansion to other endpoint types, the gateway was able to leverage external media servers to do the necessary transcoding. For simple proof of concept-type projects a solution such as FreeSWITCH can provide the transcoding functions but for higher demand production environments we would recommend a more scalable media server solution (and many networks already incorporate such media servers that can be leveraged).

Making it work is one thing, but making it manageable, scalable and usable requires a lot more consideration and experience.

Addressing Security Aspects

In terms of security, as explained in the previous blog, many communication networks have unencrypted media. Since WebRTC is encrypted, there is need for the gateway to decrypt it before it can be forwarded to the network. This is a relatively simple step but something that needs to be planned and designed for.

What Else?

Making it work is one thing, but making it manageable, scalable and usable requires a lot more consideration and experience. So we would advise anyone going down this path to plan ahead and design this in even if the first implementation doesn’t necessarily need it. Some things to consider would be:

Incorporating an Administration Layer to Monitor

As we architected this project, we designed an administrative layer that would help manage the other components such as the Web Portal, proxies, gateways and transcoders mentioned above. The concern became introducing multiple new points of failure that would impact scalability and risk high availability in the service. So by adding the administration layer, we could ensure quality of service through continuous monitoring and administration. And of course we enabled the solution to persist session and management data in high availability databases, in order to provide fault tolerance.

Building a Developer Portal

One special requirement in this case was a Developer’s Portal that would enable internal developers to continue to leverage the new services in different ways. For those extra components, the Web Portal and Administrative/Monitoring functions, we use the standard REST API over HTTP or HTTPS.

A simplified final architecture for the solution we implemented follows:

Case 1 - WebRTC to IMS for RCS and VoLTE client interop

Case Study 2: WebRTC Interop with Contact Center Infrastructure

In this second case study, a WebRTC-ready PaaS Communication Service Provider wanted to interop with a typical Call Center Communications infrastructure.

There are several WebRTC ready PaaS solutions available that offer great time-to-market benefits over starting from scratch, as well as offering scalability, reliability and ease of use. They deal very well with scenarios where you are building an end-to-end WebRTC service, however, in this case the need was to have WebRTC at one end, and an enterprise contact center at the other.

Multiple Interop Challenges

In this case, we experienced multiple challenges related to signal protocols, call feature access and security. Each one drove specific requirements that combined into a single solution architecture.

The first interop challenge was their proprietary signaling protocol, which needed to be converted to SIP by a gateway. WebRTC ready PaaS solutions do a great job at simplifying the developer’s life by hiding the complexity of things like registering users, making and receiving calls, call controls etc. The developer uses simple calls to the javascript SDK, but in the back end each PaaS has defined their own proprietary protocol. On the other hand, the contact center is using SIP and of course this cannot be changed.

In this case therefore, it was necessary for the gateway to convert the proprietary messages and workflows to standard SIP messages and call flows that would work with the contact center solution.

Another challenge that we found was that the WebRTC-ready PaaS solutions were not designed to work with contact centers which typically offer more in call features, handle complex call routing and bridging scenarios and IVR navigation. So for more complete interoperability it was necessary to extend PaaS proprietary protocol and SDK to handle the mandatory call features from the contact center.

The identity management challenge was also a little different in this case since the PaaS platform and contact center had different user databases and management. It was necessary therefore to provide a mapping function to avoid the need for double authentication (to the PaaS and separately to the contact center). This simplified the user experience for both the developer and the ultimate WebRTC client end user whilst still preserving access controls required by the PaaS and contact center solution.

Architecting the Total Solution

The final architecture involved the connection with a PSTN/PLMN network which is part of the call center default infrastructure, and a web server for administration. The final architecture is below:

Case 2 - WebRTC interop with Contact Center


WebRTC is gaining momentum in multiple industries, and some use cases still require interoperability with legacy systems. Challenges for WebRTC interoperability usually involve signaling, call control, transcoding, identity management and security.

While these 5 key challenges are common in all interoperability projects we have seen the exact nature of each of them is different in different scenarios; and even though commercial WebRTC gateways and SBCs with WebRTC support can help overcome some challenges, you will typically find yourself needing to build something more customized to your scenario.

Fortunately we have been able to identify and use a number of open source tools that help address these challenges and significantly reduce time-to-market. We also find that as gateways and other components are added to the infrastructure, new concerns arise, such as how to scale, monitor and manage all of them, which may involve a learning curve and careful engineering.

Overall we have to keep the user experience simple for both the WebRTC developer and the ultimate end user. This is the essence of WebRTC, which must be preserved so it’s up to us to hide the complexities of interoperability.  If you have any questions about these two case studies, or are implementing your own WebRTC solution, feel free to contact us, we’re always happy to discuss feedback and share insights.