Monday, August 31, 2015

Commandeering WebRTC from the telco industry

Why is it that every time some really compelling Internet based technology comes along related to real-time communications, the telco industry ends up turning it into something so complicated that the average web developer is repelled by it? For example:
  • Session Initiation Protocol (SIP): SIP started out looking very similar to HTTP. Simple, elegant and powerful. It now consist of so many RFCs that the average web developer doesn't want to have anything to do with it. 
  • IP Multimedia Subsystem (IMS): IMS is the basis for Voice over LTE (VoLTE). Somehow this thing evolved out of the early days of Voip, mostly because of the need to replace the legacy, circuit-switched SS7 network with something digital. 
The complexity of IMS is staggering. What's even scarier is that enterprise telephony networks have become so complicated that companies are being convinced to deploy IMS core networks as a way to get control over the huge rats nest of PBXs and networking equipment that showed up after years of acquisitions. All this with the additional promise that these new IMS cores will also handle their future, over the top, WebRTC based applications. Yikes!

Part of the problem here is that the telco industry has an enormous set of legacy services and infrastructure that are primarily subscriber driven. By subscriber driven, I'm referring to an infrastructure built around users who have signed up with a service provider and are paying that provider for a set of calling services (call forwarding, call blocking, etc.). When your primary source of revenue for years relied on the basic need to connect subscribers together using telephone numbers, building up an infrastructure to support making money from this through value added services made sense. The problem is that the world has changed. If you don't think so ask your teenage daughter the last time she called one of her friends (instead of one of her uncool parents) on her cell phone. In my case the answer was never.

The world is now data driven. The companies that get this will win. The rest will die a slow death. Enterprises are heavily investing now in Systems of Engagement which bring their mission critical data (aka gold in 21st century) closer to their clients. For real-time communications, especially WebRTC, data means context.

Repeat this over and over to yourself: The future of real-time communications will be driven by context instead of subscriber based services. 

This is especially true in the workplace. Think about it. How often do you call someone at work to discuss something that would not be enhanced with contextual data? Again, for me the answer is almost never. Whether its a design I'm working on, a planning meeting, whatever. There is nearly always some data element that provides the subtext for the real-time interaction. In many cases the ability to quickly connect with the parties that are interested in that data is way more valuable to me than a list of phone numbers. Never mind the fact that people's association with the context continuously changes over time.

When you start looking at WebRTC through a contextual lens, the world of real-time communications has a very different feel. In this brave new world, web based security models like oAuth and LTPA make more sense than Diameter and Home Subscriber Servers (IMS lingo for you telco outsiders), Simple yet extremely powerful and scalable pub/sub messaging protocols like MQTT replace heavyweight signaling protocols like SIP and the list goes on.

Don't get me wrong. There will always be a need to federate using standards like SIP and IMS if you want to communicate using, lets say, a more traditional means. I'm just making the point that if you really want to be an innovator in this space and, more importantly, you want to meet the future demands of your web and mobile based users, don't be fooled by the telco industry into thinking there is only one way to do it.

There was a very good reason the creators of WebRTC didn't include call signaling with the standard. They didn't want to stifle creativity and limit the technology. If you work for a web and/or mobile based company (which if you're reading this is highly likely), and you're starting to think about how you want to take advantage of WebRTC, my suggestion is to look at technologies that enable a data centric approach and never look back. Your users will thank you and so will the developers who are building your systems of engagement.