7.2 Browser Reliance and Changes

When you talk about RTE on browsers, that’s going to be WebRTC. As we’ve seen before, WebRTC stands for web real-time communications, the standard specification that allows us to run live voice and video sessions within a browser without installing anything. Today, WebRTC is available across all modern browsers, from Chrome to Firefox, Edge to Safari. If you wanted a bit more details, this is the kind of support that we have today. Chrome, Firefox and edge are available across all operating systems in addition to Windows, Mac OS, Linux, and Android. iOS support for these browsers with WebRTC is coming soon. That requires Apple to enable something within their platform, which [we’ve] just did, which is WebRTC supporting WebView.  

From there, it’s a matter of these browsers to include WebRTC. Internet Explorer is not going to support WebRTC—the browser itself is just too old Safari on both Mac and iOS support iOS support WebRTC. If you’re going to build a native application, then you can support WebRTC everywhere…it’s up to you. In a way an RTE platform assume the use of applications where they need to rise.  

Out of these browsers, the easiest one to support is Chrome hands down. It has the highest market share, the best debugging tools, and the support there is quite good for purchasing. The hardest to support is Safari. It has bugs that haven’t been fixed for quite some time. Some of them are almost blocking the ability to use WebRTC in certain use cases in these browsers, especially on mobile. 

Now, here’s the main challenge: the browser release cadence. If you look at the last year or two and try to estimate the average time it takes between one version release to another of these browsers: Chrome comes out every 49 days, Firefox 43 days, Safari every six months and Edge is unknown. When browsers update, WebRTC changes its behavior from version to version. There are two reasons for that.  

The first one is up until now, January 2021, WebRTC wasn’t a standard specification, it was a draft. The draft changed over time and was modified based on what the standardization organizations wanted or thought to do. Browser vendors implemented that specification but in its draft form, and then they had to move and catch up with the changes that were made. So, between releases, we’ve seen the creation of certain API’s changes, changes in behaviors of other APIs, and new API’s being introduced. This approach is going to continue for the next year or so at least.  

The second reason are the changes that are happening within browsers. These might affect security aspects and patches that are being made, or just optimizations that are done. They can cause can cause problems to your application, depending on your exact use case. This means that there are a lot of things that you need to focus on when you are maintaining your RTE platform and using browsers.  

First of all, you need to handle automation of testing. Okay, you’re going to need to run these tests, ad hoc, when new browsers come out. You should work against the better releases of these browsers. Use Chrome, Canary and Dev build and betas. Also go use a technology preview from Safari, just to make sure that your application is ready and that the browser will be updated and upgraded, because that happens automatically to your user base without you having any control of that.  

Now the last important thing to do is design for quick back-end and native updates. If a bug comes through, because of a change in behavior or change in one of these browsers, you might require to change your application which is easier. But you might also need to change the code in your back-end media servers. If you need to do that, you need to be able to redeploy the servers while there’s your services running without a lot of time to plan and prepare for that. So be ready for these types of challenges.  

So, what do we do? We see that browsers are great. They give you a lot of support, and they give you more footprint, and also make devices reachable for you. It also evels the playing field for the vendors because now we’ve got a media engine available that is running for everyone. The challenge, however, is that this loss of control is going to affect the client side. It’s going to affect how your servers are being implemented. So, you need to test and verify and validate over time, all the time. Thank you.