WebRTC Gateways – Trivial But Can’t Live Without Them

Gateways are necessary in a WebRTC world.

I read Tsahi’s post about those WebRTC GWs and even provided a comment for it, frankly, I agree with every word, I mean, guys, can’t you find a less trivial, more innovative approach to WebRTC. So your CEO came to you (VP Products/Marketing/Innovation/Strategy/CTO…plug-in the title) and said, “With all this hype around WebRTC we have no story to tell, what am I going to tell our investors and customers? That we are behind the curve!? By the end of this week I want a plan how we jump on that WebRTC wagon whatever that is.”

But then I tried to put myself in this VP X’s place and think. Let’s assume for a moment I work for a company that does:

• PBXs
• SBCs
• Media GWs
• Contact Centers
• Conference Bridges

Would I be doing my job if I wouldn’t add an interface for WebRTC?

By this I want to say that WebRTC GWs are not evil, actually, you can’t do without them. Why? Because that other world they connect to is not going away anytime soon. And if you want WebRTC to be mainstream it MUST connect to the world of communications as it is today.

BUT, the question to my view is not if you provide a WebRTC interface or not, everyone will have it, even the followers and the laggards. The question is, what do you need to do in order to stay relevant, leverage on WebRTC and bring new and innovative services to your customers.

WebRTC is a game changer for many vendors (most of them not realizing it yet) not only because it allows any Web developer to provide communication in a website; it is a game changer because it changes vendors’ product and customer strategy, sometimes forcing the vendor to move to a coopetition mode where he on one hand continues to sell to his traditional customers but on the other hand starts to provide service and to some extent even compete with them.

New WebRTC based services are introduced quite frequently these days, the most interesting ones coming from small startups and a few other innovative companies such as Mozilla which I reviewed in my post covering WebRTC activities at MWC 2013.

The harder challenge lies in the hands of the infrastructure vendors. For startup companies building a communications service WebRTC falls like ripe fruit into their hands, many such examples can be found on the interviews Tsahi posts on this blog. Mozila is all about the Web so WebRTC is a natural move for them.

For the traditional service providers swallowing the WebRTC frog is a bit of a harder task, similar to OTT services, WebRTC changes their revenue model and business model.

Infrastructure vendors on the other hand have a much bigger frog to swallow than anyone else because in order for them to leap from the trivial option of a WebRTC GW, they need to provide a complete service platforms and basically either provide it as a platform for others to host or preferably host the platform themselves and provide the ability for their customers to easily built the service on top (think of an infrastructure vendor becoming a Twilio or a Voxeo). The latter, being against their nature and Go-To-Market, is what to my view makes them settle for a GW option only.

With that, let’s take a closer look at those WebRTC GWs only to find out it is not a one size fits all product. Given the fact that WebRTC does a few things differently and since communication means vary we have different types of GWs, some of which include:

• Media GW – Translate OPUS to G.7XY/AMR/… and VP8 to H.26X. Also need to take care of bridging between the ways media channels and FW/NAT traversal are handled
• Signaling GW – Translate the unknown and not mandatory signaling of WebRTC to SIP/Jingle/H.323/your own proprietary stuff
• Signaling GW type 2 – Connect that WebRTC traffic with IMS and take care of all those special requirements for Authentication and Resource Reservation for Quality of Service (QoS)
• PSTN GW – Provide PSTN termination for WebRTC, think about someone calling you from your website to your mobile phone number

In summary, this blog post had only one purpose, to say to those providing WebRTC interface – “keep on that important work BUT don’t stop at the GW level”.

* Opinions presented in this blog post may or may not represent the opinions of the company I work for.