In last week’s blog, I explored why WebRTC could be game-changing. In this blog, I will go a bit deeper into these changes. Even for a company like Dialogic, with our software media server and software signaling stacks enabling other companies to create innovative applications, it is significant for a variety of reasons.
First of all, when we create our enabling platforms, we have to make sure we test for Android, iPhone, etc. end devices. When we demoed a mobile video conference application at 2012 CTIA, I made a big deal out of the fact that it was the first standards-based demo done on 3G, LTE and WiFi networks with standards-based SIP clients. But, if the end-device could simply get into a conference from a browser, then testing multiple devices would be significantly easier for us. It doesn’t make testing go away, but it clearly makes it simpler.
It also means that the nature of Value-Added Services (VAS) like CRBT would change over time. It doesn’t mean VAS goes away, but the services would change because what is value-added in a mobile broadband / internet world would change. And as I said in last week’s blog-with millions of Java developers capable of writing communications applications, we’re going to get some new, innovative VAS for sure!
Does this also mean that how we create communication applications today will go the way of analog phones? Let’s take a closer look at that. First of all, it will be a long, long time before all applications are WebRTC enabled, even if it does take the industry by storm. But what is “by storm” in telecom time? You could say that VoIP took the industry by storm, because in less than 15 years since its inception, we are now pretty much living in a VoIP world. But even with VoIP, border elements (like gateways) that interconnect TDM to IP networks are still being sold today, and border elements (like SBCs) that interconnect different versions of SIP are a big part of SBC functionality.
It is also important to understand that WebRTC is a Google (and supported by Mozilla, Opera) initiative e which means there likely will be organizations that might not really want Google to succeed, and so they won’t support WebRTC (at least until they have to). Therefore, we could be in a dual world for quite a while, even in the “web call” to “web call” realm. There will clearly be interconnect opportunities for a long time. What kind?
First off, as stated above, WebRTC talking to non-WebRTC will be a huge interconnect challenge to solve. Companies like Dialogic will jump in and provide solutions to close the gap and allow for seamless interoperability between WebRTC clients and the rest of the world. For instance, what if a WebRTC application needs to talk to a non-WebRTC application or device, like what I described in the 2012 CTIA demo? Media servers, SBCs and Gateways will have to do the heavy lifting to ensure the signaling and media can talk correctly back and forth. Additionally, the voice and video media codecs defined by WebRTC are currently not compliant with anything at all. For instance, VP8 is the royalty-free video codec that Google is pushing for that isn’t IMS compliant. The IMS, on the other hand, prefers H.264 that has been proven to work in wireless networks. Opus, the audio codec, was recently adopted by Skype but no one else. Therein lies the opportunity for Dialogic as transcoding and signaling translation between WebRTC and IMS will be required.