The WebRTC API Compatibility Challenge

Time to put the WebRTC moving target to a stop

WebRTC is defined in 2 standard bodies, IETF and W3C. Standards are being worked on in these independent bodies to ensure interoperability and compatibility.

Interoperability is in areas such as codecs, security, connectivity… making sure that 2 peers can connect and exchange media. These things are defined by the IETF.

Compatibility or more correctly WebRTC API compatibility, are those JS APIs of WebRTC that are defined in W3C. They exist so applications will run on different implementations of the standards (WebRTC implementations), for example, on different browsers.

Back in the early days of SIP

Different from WebRTC, SIP doesn’t define APIs but rather only procedures, syntax and media requirements.

One of the biggest challenges of SIP for many years was interoperability. In the early days of SIP I worked for Radvision where we developed the implementation of the standard and sold it as an SDK. At a SIP conference of Upperside in Paris I presented a list of non-backwards compatible changes to RFC 2543 (what was later to become RFC 3261), changes that happened in intervals of weeks or few months. These changes I argued, are creating a big problem for the industry because developers need to change their implementation again and again. This will hurt interoperability.

My presentation brought up against me the leaders of the SIP standard, Jonathan Rosenberg and Henning Schulzrinne were not happy with my “complain” and Henry Sinnreich took me for a 1×1 at the hotel bar only to explain to me that such things shouldn’t be said in public. Above all, my boss at that time who was also at the conference was really not so happy as well.

Some 15 years have passed and when we look at SIP interoperability we reach 2 conclusions:

1. The protocol is mature and implementations can well interoperate when they want to
2. Products are typically built in a way that includes some proprietary functionality that doesn’t allow product of vendor A to work with product of vendor B unless they go through some certification work or place an SBC between them

Reality is that we have many product/vendor/service islands.

WebRTC is different

WebRTC is different in many ways:

• It defines APIs
• It has nothing to do with signaling meaning it is very different from SIP which is a signaling protocol. It tries to standardize only what really must be standardized
• It is embedded into browsers, not too many implementations of the standard out there anyway
• Services and products using it have no intention to interoperate with others, they are islands by definition (unless they are GWs)

This said, interoperability and API compatibility are very important if we want web applications to work regardless of the browser or WebRTC implementation they are using.

Given my work with Dan Burnett on WebRT Standards updates I learn quite often about changes to WebRTC APIs. WebRTC is not a released standard yet but it is very close to that. Different from where SIP was 15 years ago, an RFC with very few real working products, WebRTC is already in mass deployment by the leading OTT service providers and others. Changes need to be introduced as the standard evolves but backwards compatibility must be taken well into consideration else developers and users will have bad experience as applications break.

Why are interoperability and API compatibility so important?

WebRTC is embedded into browsers but it is also embedded into applications and mobile SDKs. If changes to the standard impact interoperability, native applications and browsers will have a hard time communicating if versions are not in sync.

WebRTC API compatibility is important because browsers are upgraded to newer version causing application to break if there is incompatibility of APIs between versions and vendors.

As Microsoft comes out with their support for WebRTC and since ORTC is likely to be introduced as well, interoperability and API compatibility will be a greater concern.

There are ways to avoid API changes. Not changing APIs was a religion for all the protocol stacks we developed at Radvision and we managed to go through complete redesign of SDKs while not changing APIs. In other cases, projects were cancelled because of this reason. When we did decide to change an API it was a big thing for us. All this wasn’t fun but we had no other choice, we had hundreds of customers using our products, changing the interface could mean they will go elsewhere.

Conclusion

The industry and developers can’t follow a moving target.

In many cases, it is better to add an API with extended functionality while keeping the previous one. I know what people will say: There will be too many APIs, too complicated; we must add/change this functionality…

But there should be a balance between no changes to continuous change.

WebRTC is being massively used already and standard folks should keep this in mind while introducing changes.

Time to put the WebRTC moving target to a stop.