The WebRTC world doesn’t work in quite the same way as the traditional telephony world. In the classic telecom world, vendors and operators get together, develop specs and then build products to meet those specs. If someone doesn’t follow the spec and causes an interop problem then it is on them to fix – and at least there are generally detailed guidelines on what they should do.

WebRTC is very different. While there are standards, they have been a constantly moving target and WebRTC 1.0 still isn’t ratified. The fact that the browser market is dominated by a few vendors makes the scope of interoperability easier, but it also dramatically changes the industry power dynamic vs. the much more diffuse telephony market. The web tends to build first and standardize later, based on what has gained traction. That means you need to build to the browser vendors’ roadmap first and only use the standard specs as directional guidelines.

How do you tell what the browser vendors are going to implement? Well, it isn’t easy.

You can gain some insight if you pay close attention to the message boards, but ultimately you don’t know what is going to happen until it is deployed in a pre-release branch (and rarely the general branch). If something breaks you need to hurry-up and fix it.

Releases happen all the time. Google and Firefox issue releases roughly every 6 to 8 weeks. Development pre-release branches usually happens 2 cycles ahead of general availability. Beta branches are usually one cycle ahead. That means you get 12-16 weeks to see what is coming in the relatively unstable Development branches. The Beta branches are generally much more reflective of what the general version will look like, so you have another 6-8 weeks to focus on any specific problems.

So what’s the good news?

The good news is, if you gear your development and quality assurance systems around these cycles everything generally works well. However, these timelines do not leave a lot of room for major errors. We ran into this when Chrome stopped supporting the RSA-1024 encryption algorithm in favor of ECDSA in Chrome 52.  If you have a gateway or other device in the media stream, these devices must also support ECDSA.

The Chrome team actually did a lot of pre-announcements about this change. I thought we were covered by our OpenSSL implementation (the most popular encryption stack used for Linux). We weren’t (my bad!), so we didn’t see it until it made its way into the release process.

Upgrading OpenSSL would be easy enough, but it turned out the version of OpenSSL that we needed was not compatible with our flavor of Linux. The solution – we needed to change our Linux environment. This meant going through our rigorous, but lengthy regression testing to make sure it would not break anything (and of course it did). 
Suddenly what seemed like a minor change turned into something that required a lot of coordination and planning, just to make sure WebRTC didn’t break when Chrome started to auto-update users.

Moral of the story – the browser vendors will change something and your WebRTC implementation will break, so pay attention, use the pre-release versions, and be ready to respond when something does break. Or, alternatively, defer these problems to someone else like us. In our case, fortunately we were regularly testing with the pre-release builds so we had plenty of time to implement the fix and we were able to remain transparent with our customers.