Where Standards Matter for WebRTC

Standards are important, but they don’t fit everywhere. Here’s how to use them sparingly.

[Amir Zmora usually gets pissed on some of the things I write – usually when he tries fuzing things like WebRTC into the realm of existing products. Here’s what he had to say about the need for standards]

Standards build roadblocks to innovation and emergence of new technology trends simply because they require many parties to agree on things, and there are so many things they need to agree on when it comes to VoIP: signaling for connecting and managing the session, authenticating the user, securing the media, deciding what type of media (codec) to use, allocating bandwidth for the call, QoS and the list goes on.

Tsahi touched this topic in his post The Death of Signaling as we Know it. For a new WebRTC service or island created there is no real value in following the signaling standard. You just need to see what’s in it that brings value for your service and play around with it, change it, add your secret sauce to it or just forget about it all together, go for the extreme scenario of simply sending an HTTP request to the server indicating you want to start a WebRTC session and get done with it.

In WebRTC, standards have a different purpose and need. There are 2 areas where standards do matter for WebRTC:

• Browsers
• Connecting with the world as it is today

Browsers

WebRTC MUST be common among all browsers. There is a reason why WebRTC is being discussed in standard bodies. If we want a Web application to run across all browsers the following items must be common to all:

• The APIs for working the WebRTC engine, this is covered by the WebRTC working group at W3C.
• The media codecs supported, this is covered by the Rtcweb activity group at the IETF.
• The way in which the media session is established, all that media negotiation and connectivity establishment through ICE, this is also covered by the IETF Rtcweb activity group.

These get complicated as companies have conflicting interests when it comes to the codecs defined as mandatory and; Companies want to create differentiation and many view differentiation through the prism of media quality which I believe is a narrow view compared to the endless innovation opportunities waiting to be uncovered in the service realm.

The difference in the way WebRTC is being standardized these days Vs. the way in which H.323 and SIP, and to a greater extend VoLTE and RCS have and still are standardized is that WebRTC standard work is trying to standardize the bare minimum while the latter takes standardization to the extreme touching every bit and byte of the communication scenarios. Since companies and engineers can’t agree they come up with this great idea of different options for implementing the same specific feature. This in turn kills the core purpose for which the standard was created, interoperability.

Innovation comes when you create a sandbox where kids can play. In the WebRTC  world:

Sandbox = media communication APIs in the browser and rules for connecting the peers

Kids = the developers/companies creating the services on top

This leads to the second reason for standards, interoperability with existing deployments

Connecting with the world as it is today

This part seems trivial. It is a world of Gateways, and they come in different shapes and forms as I wrote on an earlier post here saying they are Trivial But Can’t Live Without Them.

But this connectivity to the world is not so simple. There are 3 types of worlds one would want to connect with (not including PSTN as connecting to it will be through connectivity with the existing PSTN Gateways):

• OTT networks, they are proprietary. Some give you a door to connect through, some don’t, but anyway the door through which WebRTC is connected with them is at the end of the day proprietary.
• UC and customer care networks, these are typically on premise type of deployments yet some have also a cloud-based option. In any case, all these vendors that provide an end-to-end solution, meaning both the server and the client/device sides of things, call their solution a standard based one but reality is that they all took the standard (typically SIP), twisted and turned it (or one may say twisted and broke it) making their solution at the end of the day proprietary. This means that the door through which the GW connects to these deployments is yet again proprietary.
• Standard solutions, these will include 2 types of products
  • Those that provide only one part of the equation, i.e. a client or some kind of server. They must be standard as they want to connect with the world, else no one will be able to use them.
  • The second one is probably a surprise to many, these are most of the video conferencing companies. They use close to 100% standard ways to connect between the clients and the servers even though most if not all of these companies have an end-to-end, client and server product portfolio. They do have some proprietary stuff, mainly in areas related to media quality (e.g. SVC, FEC, advanced codecs and profiles) and some other special features. The main 2 reasons for that are: 1) it is a small community of companies so testing with all is easier and believe me, they test vigorously for interoperability, I have been to those interop events a countless number of times, I work for one such company, Radvision, for whom standards are like bread and butter; 2) many started with just one part of the solution, a client or a server and only later completed the portfolio so they had to go for standard implementations.

The above means that connecting WebRTC with those services and products detailed in the first 2 bullets require either a WebRTC Gateway to be provided by that company (or someone else who knows/hacks the proprietary implementation) or that they provide a standard SIP interface for other standard Gateways to connect through but then not all proprietary features can be utilized. On the other hand, connecting with products and services of companies in the 3^rd bullet is simply through a standard SIP interface.

In conclusion, standards matter but only in some well defined realms. Before you go for the kind of obvious option think about your product or service goals and the ecosystem it is planned to support or be part of. You will be surprised to discover that many of the “standard” solutions are twisted standards. At the end of the day, it is a world of islands or should I say twisted standard islands. This means that in many cases a simpler and proprietary route will do the job.

–

*Opinions presented in this blog post may or may not represent the opinions of my employer.