WebRTC, Electron, and You

Published in

RingCentral Developers

9 min readJun 29, 2022

Over a span of 12 years I have focused on building WebRTC-based products and platforms on a global scale. With a total of over 20 years in the IT industry, I am currently the Senior Director of Video Engineering for RingCentral. In my current role here at RingCentral I am responsible for delivering the next generation of real-time video interaction within all our products, part of the leadership team RingCentral’s in-house Video Meeting platform. Over the years I have built five different products based on WebRTC technology.

In this article I want to discuss a specific product I developed on the Electron desktop development environment that leaned heavily on WebRTC technology.

First let’s consider some context. On mobile platforms the average person has about 40 applications installed and yet only really uses about 18 of them on a regular daily basis. App development is usually done with the mobile experience in mind and the desktop environment being considered peripheral at best while often ignored entirely. The desktop environment is still a place where applications get used every day; not everything has moved to mobile just yet.

The WebRTC technology runs on all major browsers so that means that it can be used on both mobile and desktop environments so it is the ideal solution to use in a situation like this.

What if you want to leverage that web-based technology and have your mobile product working on the desktop? There are two options, PWA (Progressive Web Applications) and Electron. PWA is a quick and easy way to distribute an existing web app that is available on the mobile stores to PC or Mac. Electron, however, offers many users a more convenient and efficient approach. Major companies and applications using Electron today include Slack, Microsoft Teams, Facebook Messenger, WhatsApp, Twitch, Skype, and of course, RingCentral. With these top companies using this technology framework you can be sure that it is trustworthy and valuable.

So what is Electron?

According to its website, Electron is: “a framework for creating native applications with web technologies like JavaScript, HTML, and CSS.” It is also the “simplest” way to build a desktop browser application for Windows, Mac, and Linux. Electron combines Chromium (which comes with the WebRTC stack) and Node.js. So your overall app then is a function of Electron itself (the web browser container), your web app and any Electron or native modules you add to it.

What can go Wrong?

Because you are using Electron to encase your web application that means that your application has to support this additional “browser”. It triggers different Javascript interfaces that the developer defines, like how it might implement custom screen sharing capabilities. The native node modules expose one API to your Web App but it has different implementations for Windows or Mac. Therefore they most likely also have their own hardware specifics for connections to Graphics Processing Units (GPUs) for example. These native modules also typically work with only one given major version of Electron.

So your app when wrapped within Electron will have to be tested extensively as it interacts with these modules and APIs. An integration test app as well as end-to-end testing should be well employed before releasing anything to the world.

Upgrades can also pose a significant challenge and risk to your app, especially when trying to manage app upgrades across Electron, the web, and your native modules in between. All three mediums can be upgraded separately and have different methods of deployment. Keep in mind when working with web apps or third party distributors that you may not be able to fully control the deployment timeline, or may run into unexpected delays with one of the app’s releases. Thankfully, with careful planning, coordination, implementation, and testing paths you can mitigate many of the risks associated with app updates across multiple platforms and distributors.

Another pain point is dependency management. When things go wrong, the dependency tree can prove to be a complex onion to peel. You may need to talk to different open source communities on tools like GitHub, Slack, and Discord just to figure out where the problems are located. Keep in mind that there are only three versions of Electron supported at any given time, so be sure to check the version level you have in place and to stay current with the latest supported versions. After that initial validation you can check on your versions of Chromium and WebRTC. Chromium only supports those same three versions of Electron but it has many versions and sub-releases of its own that may have differing interactions with Electron so be sure to look in those “corners” as well. When debugging your WebRTC issues you will find that this can prove to be some of the more difficult areas to debug as it depends on the other two layers to function properly.

Understanding the Release Cycle

In addition to knowing where you might locate assistance with your debugging issues it would also help greatly to know and understand the release cycle of your tools so that you don’t spend time needlessly on release platforms that are not supported and therefore should be out of scope.

Chromium has recently moved to a release cycle of every 4 weeks, so Electron has changed its release cycle cadence from 12 weeks down to 8 weeks, essentially picking every even number release of Chromium. The advantages of having more frequent releases is that they will be smaller in scope and you will potentially gain access to their bug fixes or added features more quickly. The drawback is that the target(s) moves faster and therefore your code can become dated more rapidly.

As an example, Electron 19 has been released on May 24th and comes with Chromium 102. The supported versions are now 17 to 19 and these supported versions change rapidly so be sure that your projects are also kept up to date to make use of the latest features and to have proper support levels.

Now, let me give you a real example of bug tracking we experienced. VP8 is an excellent codec for video, but for screen sharing, in the context of business meetings, when people mostly share presentations, and expect the remote participants to see a crisp image, our research proves that H264 provides a better quality than VP8.

Among others, this issue was in our way to use H264 for screen sharing. Now, How to identify the release train of the fix in WebRTC, then Chromium, and Electron? First, you need to find the patch submission. Get the commit hash from the patch submission, or in the issue tracker if they have been linked together, you will find a comment from bugdroid. Enter the commit hash into cdash and voila. Sometimes there is a backport in the current stable release, like in this example. Just repeating the same steps will give you the minor release in cdash.

Now, where did this commit land in Electron? A quick look at major release notes will tell you which version to look at. In the current example, E11. Then you can find the release notes of all the minor releases of E11. In that case, Electron 11.0.0 already contained the fix we are looking for. Sometimes Electron also cherry-picks some Chromium patches, mostly related to security.

Best Practices

Now that you’ve mastered WebRTC bug tracking in Electron, let’s talk about best practices.

Test, Test, Test!

Test all your upgrades, tool combinations, and your backwards compatibility. Also be sure to test your performance levels and your media quality during development, regression and production. All the testing will help to make the overall product more stable and more easily debugged if that is ever needed.

Upgrade

Upgrade as fast as you can on the latest Electron stable version. Be sure to review the release notes too, which can help you be aware of any stumbling blocks that may be in front of you.

Customization

Go with a custom Electron strategy ONLY if you have the resources, development environment, and ability to do Quality Assurance testing.

Contribute back!

It is not ideal to maintain your own build for too long, so report issues early, use tools like this very handy bisect python script that lets developers find the exact version of Chromium that introduced the bug they are facing.

Report Bugs

Another point to make here is that if you find the solution or solutions to issues you are having be sure to document them well and share them back to the community so that others can learn from your experiences. This is important if you are just reporting bugs, but also important to report the solutions if you should happen to solve them yourself. You can do your reporting here:

github — for Electron
crbug.com — for Chromium.
bugs.webrtc.org — for WebRTC native code.

But before jumping on it, I highly recommend this guide to help you get your bug report to be processed in a limited number of back and forth steps with the team.

Join Beta Programs

If you have time and resources, be sure to also contribute to the advancement of these products by joining beta programs and testing new or experimental features.

One example from RingCentral: RED, an IETF RFC that describes an audio packet duplication mechanism to fight against packet loss. Jitsi supported Philipp Hencke’s contribution and we performed extensive lab testing then shared our Internal User feedback. See here. RED is now GA in Chrome 96.

You may consider building your custom Electron like we do. When you build your desktop app with Electron, you can either pick a vanilla version, and use the stack and standard APIs that are available as-it-is, or, as the entire solution is open-source, modify some part of the stack, and cherry pick the patches. What we did at RingCentral allows us to have Electron with its own desktop capturer, run native modules as audio worklets, expose a new API to run native modules to apply video effects, and filters in the WebRTC breakout box. And finally, create audio dumps to help us investigate any audio issues.

Alternate Paths

Of course, as in life, there are many approaches to reach a similar goal. All these AI-based features that are mentioned above come with a very high price on the CPU, the GPU, and Memory footprint, so you may want to consider a similar solution that Microsoft Teams recently announced. This solution allows the developer to mix native code with JavaScript code using a new feature from Windows 10. It is called WebView 2. Under the hood, WebView 2 is an instance of Microsoft Edge that comes with the OS, based on Chromium, that has the exact same release cadence. You can choose an evergreen distribution, or you can pin a particular version of Chromium.

This new approach is interesting, if like us your application is a mix of real-time communication features, and asynchronous communications. The container is not Electron anymore, it’s a native application that has access to all the framework and APIs the OS has to offer. Note that you’ll have to use the native libWebRTC, that does not include the capturing or the rendering, that’s something you would have to implement yourself. You may have an alternative that allows you to have the best for each of these worlds. This is currently only available on Windows, but MacOS is on Microsoft’s WebView2 Roadmap. In the meantime, you can use WKWebView for MacOS, if your Web App supports Safari.

The Road Ahead

For more learning on what WebRTC is all about you can check out this WebRTC training course web site: https://webrtccourse.com

As well, here is a list of additional resources that may help you in your WebRTC journey.

Web resources:

Conference resources:

Please let us know what you think by leaving your questions and comments below. To learn more about features we have make sure to visit our developer site and if you’re ever stuck make sure to go to our developer forum.

Want to stay up to date and in the know about new APIs and features? Join our Game Changer Program and earn great rewards for building your skills and learning more about RingCentral.