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
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.