As we have written in previous articles, WebRTC is a communication platform and set of APIs drafted by W3C that is embedded into the common Web Browsers we use every day to browse the Internet. The intention is to add real time communication capability into the browser via simple JavaScript APIs. This is a great opportunity for innovation; it will have a major impact on the communication industry allowing many web developers to begin to more easily embed real time communications into their applications and web sites.

Rather than replacing traditional telephony or video conferencing in the short term, WebRTC will fuel the development of a whole new generation of web based communication applications and features that will be added to many of the internet and business products and services we use today on the internet and in business.

On the consumer/client side, we will be able simply to open a real time audio/video and data sharing session directly in our browser. For the web developer this will be fairly easy to achieve by using the WebRTC API’s and JavaScript.

This simplicity for the developer and in the end user experience is great for new services that will run with WebRTC end-to-end, but a large problem remains to be addressed for enterprise and service providers as they are forced by their users and competition to offer new WebRTC functionality through web clients and make it work seamlessly with the communication infrastructure and processes in which they have already invested.

WebRTC Interoperability

WebRTC takes care of media channels very well, but what it does not do is to provide or specify any signaling protocol or mechanism to do that. Instead it is left to the application developers to choose whatever protocol they want to send and to receive control messages among the peers for controlling features of the call. Luckily there is no shortage of signaling options that WebRTC applications could use: we could use an HTTP request mechanism or a more elaborate protocol like XMPP or SIP implemented in JavaScript.

Application developers also need to think about potential compatibility issues in the media stream. To interoperate with WebRTC the legacy endpoints would need to support some of the required WebRTC features, such as VP8 codec, SRTP/SRTCP for media transport, and Interactive Connectivity Establishment (ICE) for transport address negotiation. They would also need to consider the Session Description Protocol (SDP) that carries the required parameters for the call. WebRTC uses SDP but requires and implements some additions to the protocol so some form of mediation will be required.

To achieve the required interoperability, the legacy endpoints would need to be modified in order to be compatible with WebRTC, or some form of gateway solutions will need to be in place to manage the necessary protocol, signaling and media conversions.

The following is one example of how basic interoperability could be achieved.

WebRTC to PSTN Interoperability

Let’s take as an example the scenario where a WebRTC client is used to make a call to a PSTN landline.

To make a connection to the PSTN the WebRTC application would need to deal with differences in address (number) resolution, signaling, media conversion, etc. Many of these problems have already been solved in telecom systems, so we would recommend using some of the existing telecom solutions and components like SIP Servers, Session Border Controllers, and Media Gateways that already contain much of the necessary intelligence, protocols and infrastructure for interoperability with PSTN.

In our simplified example we’ll assume the WebRTC client will be talking to a SIP Gateway in the network and consider what is necessary.

In the WebRTC side we need to consider that in order to create a media session the WebRTC client application will need to obtain:

  • Local connection information: IPs and Ports that could be used to receive the audio and video
  • Remote connection information: IPs and Ports that could be used to send the audio and video
  • The list of media codecs

Fortunately this part of the problem has already been addressed in WebRTC where this functionality is provided through ICE and the use of SDP (Session Description Protocol).

In order to talk to a SIP Gateway in the network, the WebRTC client must also support SIP. As we mentioned earlier WebRTC does not specify or implement signaling, and SIP is not supported natively in the browsers. There are, however, JavaScript libraries available to implement this, including a free JavaScript library “jsSip”. At this point the developer begins to delve into the depths of telecom protocols and will need to have a good background in SIP (and it’s challenges) in order to establish and control calls.

The following is a possible flow for the scenario that is being discussed:

  • The WebRTC client creates a connection with the SIP Gateway and registers itself. Note that the SIP Server should be modified to support WebSocket, otherwise another component (such as webrtc2sip gateway) will be needed to convert WebSocket to UDP or TCP.
  • In order to make a call to a PSTN number, the WebRTC client sends a SIP INVITE request to the SIP Server. This INVITE carries the SDP local session (created earlier) containing the supported media codecs, and the ordered list of the IP and Port to be used for media transport that were established through ICE.
  • The SIP Server allocates a session in the Media Gateway and sends the response to the client with the remote SDP.
  • At this point the WebRTC client has all the information needed to establish a media connection between the client and the Media Gateway; it is just a matter of calling a couple of JavaScript functions to send and receive the media packages.
  • The SIP Server also starts signaling with the PSTN, and as soon as the call is answered, a full duplex audio channel is established between the WebRTC client and the PSTN peer.


WebRTC provides great opportunity for extending many products, services and websites by allowing web developers to easily add real time communication features, but in order to realize the benefit the more challenging area of interoperability with legacy systems needs to be addressed. We can expect to get some help from off the shelf components, and we are already seeing SBCs being extended to offer support for WebRTC. In the future we may see companies coming to market with other off-the-shelf components like WebRTC to SIP gateways, which will further simplify the problem.

In our many years of experience we have found interoperability to be a continuous challenge, which in the end may put a nail in the coffin of many exciting new potential WebRTC based services. The good news is that interoperability in telecom is nothing new, and the problems and potential solutions are well understood.

If you would like to learn more, please feel free to take advantage of one of our free consultation so we can begin to help you plan your WebRTC strategy and its approach to interoperability.

Download the white paper “WebRTC and IMS in the Cloud“.