Has WebRTC Proven That No One Cares About Communications Service Interoperability?

Continued from page 1. 

While this sounds very egalitarian, it opens up an enormous interoperability challenges. The telco regulatory bodies try to standardize interactions between components and networks. In theory,  as long as everyone in the massive ecosystem follows the specs, everything should interoperate. The reality is that this never happens. Technology has a bad habit of growing too complex to standardize everything. For example, vendors interpret the specs differently and take liberties with ambiguities to differentiate. This results in lengthy specification development timelines as every detail needs to be spelled out and agreed upon. Furthermore, consider constant interoperability challenges between vendors with competing interests that take even more time to resolve. Finally, these standards often act as an impediment to anyone trying to seriously innovate to make something better for fear it may hurt interoperability.

The Web Way

In the Web world, there isn’t much out-of-the box interoperability beyond the browser by design. That is not to say all browsers implement the same technologies and there are no cross-browser challenges. There are many, but the Web’s model is fundamentally simpler than what the telcos are trying to achieve.


Web communications have been almost completely between provider (i.e. your website or back-end app infrastructure) and the end-user’s browser (or mobile app). So far, there has been no need to address the complexities of user to user communications across domains (similar to what the telcos have had to deal with). For example, Facebook users who chose to communicate via Messenger (which, as said before, is enabled by WebRTC), only do so with other Facebook users. Currently, Facebook Messenger does not interoperate with other WebRTC-based communications networks (like Google Hangouts).

Early on, WebRTC’s designers faced a key decision - do they standardize the signaling interaction between the server and browser, and potentially between servers from different domains? Or, do they let the market decide how they want do that? Should Facebook have to talk to Google users the same way Verizon subscribers need to talk to AT&T?

The WebRTC standards community chose to exclude signaling from the specification. This massively minimized the scope of what they had to focus on while avoiding inevitable arguments that would slow standardization and adoption. The lack of end-to-end signaling does not preclude provider-to-provider interoperability. But it doesn’t require it either. While there are some interesting federation/end-to-end-interoperability signaling projects for WebRTC, use of these is has so far been insignificant. For their part, the vendors and service providers like Facebook and Google that support WebRTC have decided end-to-end interoperability is not important.

Facebook uses one signaling method. Snapchat uses another. So if a Snapchat user wants to video call with a Facebook user they just go to messenger.com or take a minute to download the app (in addition to setting up a Facebook account if they don’t already have one). AT&T, however, doesn’t make Verizon subscribers setup accounts on its network in order  to complete  a call to AT&T subscribers. So, why doesn’t Web calling work like this? Well, Facebook and Snapchat businesses are based on having an account so they can track what you do and for advertising purposes. They have no incentive to share your data or make it easier for you to use someone else’s service.

This shouldn’t be much of a surprise. Skype did the same thing more than a decade ago when VoIP was first introduced. Rather than comply with the then current-day standards and join the traditional VoIP community, they took their own approach and only added interoperability (Skype-in and Skype-out to phone network users) as an option. If you wanted to talk to someone on Skype you needed to download the Skype app and create an account. In exchange you got free calling and video communications. The result: about 3 billion calls every day as last reported by Microsoft.

For better or worse, we seem to be ok with this new model. We have accepted it for our phone suppliers and apps. In return for setting up multiple accounts we get a lot of innovation and choice. The interoperable phone network is not going away anytime soon, but it does grow less and less important every day as we communication via other apps. I am sure there will be some backlash against this model and efforts to make communications interoperable again, but for now we’re too busy trying out the latest communications app to care.

Be sure to read the next WebRTC article: Microsoft Commits to Real-Time Communications with WebRTC 1.0 API Release

 

Comments (1)

Byron-Jones

VoLTE and WebRTC are fundamentally different use cases, and it's odd to compare them in terms of uptake.  VoLTE requires changes to core mobile telephony infrastructure, which explains its slower rollout.  They are both great technologies, but it doesn't make sense to compare them as competitors, when they are in completely different market segments.