Media, Signalling and Breaking the OTT Islands

My post summarizing some of the Telco presentations at WebRTC 2014 received a comment from Josh, one of our blog’s loyal readers,who pointed out the market need for breaking the OTT islands.

On the topic of transcoding in your piece. Can you tell me how hard it is to transcode or not and can being a strong transcoder bring a high barrier to entry OTT VoIP network to market? I believe Audiocodes is one of the few players that can transcode brilliantly. For example: I believe you can allow for Whatsapp users to talk to Viber or Line to communicate with Skype. Now that is a service that would knock the socks off the market. Can you give me some color on this thought process?”

My reply to Josh was:

“Great comment that deserves a post as an answer rather than just a reply in the comments section”

So here it comes…

I would like to break down the comment into 3 topics:

  • OTT Islands
  • Media
  • Signaling

OTT Islands

This boils down to the following: do these service providers/OTTs want their services to interconnect?

Imagine you couldn’t call your friends’ home or mobile phones just because you are using service provider A and he is using service provider B. That’s not something we can accept.

In the Telco world, interoperability is king.

One of the reasons excuses Telcos use to justify their slow progress on RCS and VoLTE is the need for specifications to stop changing. They invest endless efforts and money to assure interoperability, that you can call anyone and that you can take your mobile to any country with a compatible network and just use it as a roaming user.

Using the same thinking process, some wait with WebRTC as even WebRTC1.0 is not really finalized and now we have ORTC and WebRTC 1.1 in the plans.

In the OTT world, interoperability contradicts the basic DNA of the company. They build islands and protect them. They typically don’t want you to be able to call someone who is not on their network unless you do it using some “out” service based on PSTN and are charged accordingly.


There are rare cases where OTT players open up for others to interconnect between them. I was fortunate enough to be involved in such an initiative in my previous life. We provided a server that connected between two very big OTT players. Initiative came from them as they were battling an even larger OTT service provider and concluded they would be better off teaming up on this.

This interconnect was requested by them, hosted by them and available only for them. To the best of my knowledge, this interconnect wasn’t that successful. The reason might be that the interconnect was only for a limited set of capabilities. Doing full interconnect – user management, presence, voice, video, chat and advanced communication features – is hard and not always desired by the OTT as it eliminates the reason for a user to join their network, as he can access it from his current one, so why bother installing another app.

WebRTC is an interesting beast in this context. On one hand it is being adopted by traditional telecom vendors and service providers but on the other hand it was built for the web and has some OTT symptoms.

WebRTC deployments have strong client server coupling and connectivity to other networks is done through a GW, similar to the way it will be done in the case of OTT.

Assuming an OTT does want to open his service for interconnection, there are two big items he will need to make sure are open. Signalling and media.


Signalling in this context includes all communication between the client and the server that is not media (media preferably goes directly between the clients).

Finding users, adding them as contacts, publishing presence information and receiving such information, initiating sessions (chat, voice, video) and activating advanced features. All of these functions require signalling.

OTTs don’t wait for standards to be ratified. On the contrary, signalling is the area where they differentiate, where they add their unique competitive edge. While some base their signalling on standard protocols such as SIP, there are always layers on top that make it different from the standard.

Hacking OTT signalling is sometimes possible, the problem is that OTT service providers may change parts of their signalling or add capabilities as they add more features. Moreover, if they don’t want you to GW them to other networks, they can block you.


Media is a completely different animal. While some OTT service providers view voice quality as one of their strong points (Viber played on HD voice high quality in their early days), generally speaking, voice and video codecs used by these service providers are industry common codecs.  Skype, for example, developed the Silk codec for their internal use but later on opened it for everyone to use and today Silk is a popular codec. Opus, the mandatory codec for WebRTC, incorporates both Silk and CELT.

Viber does claim to use some internal codec but since most of these OTT players (Viber among them) provide PSTN connectivity, they have the capability to transcode the media used in their island to G.711, thus, to any codec.

Relating to the comment Josh made: While there are many transcoding solutions available, especially when voice traffic goes over the open internet, as in the OTT case, quality issues may arise. Given over 20 years of experience and technology developed at AudioCodes our products include quality enhancement capabilities that compensate impairments and network behaviour differences such as jitter and delay.

Why this is important?

While people see value in interconnection between OTT players or even having multi-OTT applications, OTT service providers typically view this in contradiction with their interest. They want users to use their service so they can monetize them.

WebRTC in the eyes of Technology and Marketing in Telecom

What Telcos Had to Say at WebRTC 2014

At the very end of 2014, I was at the WebRTC 2014 conference in Europe. I already provided a summary of the important things discussed at the conference and talked about the challenges of running WebRTC on mobile devices which was one of the topics I presented at the event.

In this post, I want to provide a few highlights of what Telcos presented with regards to their activities in WebRTC on the first day of the conference.

How do Telcos grasp WebRTC?

The answer to this question depends on who you ask. Sebastian from Slovak Telecom presented this topic nicely by showing how technology and marketing people view it in the telephony context –  connecting from IMS and billed as telephony.

WebRTC in the eyes of Technology and Marketing in Telecom

Dr. Joachim Stegmann from Deutsche Telekom presented the different views inside his company in one slide which nicely demonstrated the fact that WebRTC, as a technology, can serve multiple needs. It can extend existing networks and services on the one hand while creating new opportunities in the Web and Telco OTT fronts on the other. One hand doesn’t contradict the other and each will typically be handled by different groups inside the Telco organization.

WebRTC Business Opportunities in 4 segments

Taking a closer look at the 4 key areas Joachim presented:

Connecting Telcos and the Web – This is pretty much the IMS integration view that allows Telcos to launch new services that utilize both IMS and WebRTC. I can see the value but I view it more as a GW type of approach and would put the focus on the services that can be launched on the WebRTC side and less on how they connect to IMS.

Enterprise communication – This is a B2B type of service, and based on what Joachim discussed, it reduces the complexity we experience many times in enterprise video conferencing and collaboration. I agree that WebRTC can make these services better, easier to launch and easier to use. But there are many WebRTC-based collaboration services available today, many of them not too successful as they just took what was possible before with a plug-in and did it with WebRTC. The successful services (not all WebRTC based) provide a more comprehensive offering. I refer to Microsoft Lync that provides an enterprise telephony and collaboration solution or Slack that integrates nicely with many Web services in order to provide a compelling solution.

Service providers need to more than just adopt WebRTC in order to win here.

WebRTC will change customer service – This is B2C communication, in the form of some sort of Contact Center 2.0. Amazon has raised the bar on customer service but that has nothing to do with WebRTC, rather it has to do with state of mind. Integrating a video chat client into a tablet can be done without WebRTC, the hard part is providing the service not the technology. Given Contact Center overload, and in many cases, desire to move B2C to other channels such as chat and forums, the video service is relevant only to specific target audiences in specific segments (hint: $ value of the user being served).

Cloud-based MVNO and Telco OTT – This topic is broader than just WebRTC; it relates to the challenges Telcos are facing in their competition with OTT players. The solution is not technical as the same technology is available to all. The challenge is in agility and capacity to innovate in the service and business model. In these type of services there is a need for asymmetric business models rather than the traditional per-minute/subscription models.

Congestion issues

Staphane Tuffin from Orange Labs, presented congestion issues and why best effort service is not enough. He talked about managed VoIP and why it doesn’t apply for Web Communication service providers. Stephane proposed a solution for WebRTC network admission, identifying WebRTC traffic and ensuring QoS.

Telecom API

As part of the telecom API trend and launch of WebRTC API platforms by service providers, Maurizio De Paola from Telecom Italia presented the company’s EasyAPI, giving Web developers access to the Telecom Italia network. Maurizio showed a few examples of how services can combine users from Telecom Italia’s IMS network with non-Telecom Italia subscribers.

EasyAPI WebRTC Integration with Telecom Italia Network


This is nicely aligned with what AT&T announced in their developer summit a short while before CES. A Developer API platform adds the ability to extend user’s mobile identity to the browser.

WebRTC client side

Telecom OTT is a hot topic, John Neystadt from Telefonica presented TU Go, the Telefonica OTT service that runs on different devices and browsers. John presented the reasons for launching TU Go, primarily to allow Telefonica’s 26 operators to offer their subscribers a way to extend the usage of their phone number to other devices.

There were many technical points to consider such as authentication, signalling and transport (decided on a JSON-based proprietary protocol over WebSockets) and how to GW TU Go into their network (they built their own GW for that purpose). Transcoding was, of course, a big topic as Opus is CPU intensive.


While last year, service providers were talking mainly about trials and architectures that combine WebRTC with IMS, this year the main discussion was about real services and issues service providers encounter. That in itself is another milestone in the maturity of WebRTC.