Create your WebRTC development environment

Developing a WebRTC applications requires more than just GIT, Studio Code and Chrome. This article highlights some of the requirements.

Having a WebRTC development environment

Did you know that it costs about €2000 to be well-equipped to develop WebRTC applications?

Developing Web applications is usually a pleasure: Without spending too much time and money, it is not so complicated for having a development environment including a server that updates the application on changes as well as launches the non-regression tests automatically.

When speaking about WebRTC, that environment is still recommended but is not enough. Real-time communication comes with devices and users and so you need to prepare and organize your desk to use more materials…

This article tries to summarize what is the Minimum Viable WebRTC Development Environment.

A need for devices

You can’t develop a WebRTC application without having at least access to a microphone and a camera. Hopefully, these accessories are now very common today and every laptop are equipped with a camera. But this is not enough, you need to have at least an external camera (USB) and an external headset or speaker. These external devices help you to understand what happens in that case.

The complexity comes when you want to offer an easy way that detects and adapts to the devices when they are plugged, unplugged or when the user switches to on or off a bluetooth device.

It could cost around €250 to have the minimal equipment in term of devices.

Having different kind of devices is recommended to develop a WebRTC application. This helps you to understand how your application reacts to these kinds of materials. Capturing and managing these behaviors improves the user experience of your application.

A need for computers

Often, when developing a WebRTC application, you simulate different users on the same PC by opening two or more different browsers. This can be complicated because you have a lot of browser’s windows opened including the one used to debug. And these browsers share the same devices if you don’t have different…

Having the possibility to test on several computers with different cameras, microphones and speakers is not a luxury. You gain a lot of times and avoid becoming crazy…

Even if the OS has very few impact on your Web application, it can be good to mix several Operating Systems when developing. For example, you can have your Windows or Mac computer for developing and a fresh ChromeOS laptop to use as a second test user.

Hopefully, there is no need to have extra power for running WebRTC Web application.

Count around €500 to have a secondary laptop.

Computer such as ChromeOS can be a good choice for testing without investing so much money. Alternatively, any ‘Office‘ computers is enough where you can install any Linux distribution.

A need for mobile/tablet devices

Your Web application runs on mobile or tablet ? In that case, you need to have some mobile or tablet devices to check how it’s look like on these platforms.

Using Chrome to simulate a mobile or a tablet is not enough. This will only give you a feedback for your UI and UX generally speaking.

It is important to test on both IOS and Android because at this time of writing, only Safari is compliant with WebRTC on IOS and on Android, depending on the device, the default browser is not Chrome and so some surprise could be seen.

A first part of the complexity on mobile comes with some flagship models which have several cameras. If the wrong camera is selected, the render can be a bit complicated due to the ratio or format used. In general, which means for any kinds of mobile devices, be careful when asking media constraints.

Note: If you tested both IOS and Android platforms, you should not discover additional issues when on tablet event if now there is a different OS on IPad.

A second part of the problem is due to the way applications are handled in background. Don’t forget that your websocket should be disconnected to avoid consuming too much battery and data. So be sure to handled correctly these cases. For example, it is not possible to receive incoming calls when your Web application is on background on IOS.

A third problem comes when you mix desktop and mobiles because of the media quality used. Sending multiple 4K streams to a web application running on a mobile is not good. Your device will heat and consume a lot of data…

And don’t forget to have a SIM card to test all topologies with your mobile devices…

Count at least €600 with refurbished devices to be able to test both Android and IOS platforms.

Having some mobile or tablet devices is not a luxury if you need to support these platforms. It will help you to improve the user experience of these nomad users.

A need for an additional screen

In addition, you will need to use some real-time tools such as WebRTC-Internals from Chrome or Wireshark for analyzing what happens into the WebRTC stack.

This implies to have at least 2 screens to be able to have all the windows in front including at least 2 times your application for 2 users + Web debugger, your editor and a window for debugging the WebRTC part. Without taking into account all the other applications you use.

Count around €400 for the additional screen.

A need for RAMs and Docker components

In case you need to integrate with a media server and if you don’t have access to a development platform, perhaps you need to install your media server on your development machine. In that case and to avoid having to install that media server from zero, you can rely on a Docker container of your media server.

A lot of Docker containers exist for the majority of media servers. It’s an easy way to do some tests locally and most of the time, the configuration of the Docker image is not complicated (A file to configure or some environment variables to set).

But, this leads to the fact that you need a lot of RAM on your computer. 8GO is not enough is you want to run a Docker container additionally to your existing development environment. You don’t really need to have additional disk space for your docker containers. But your disk is already full, you will need to buy a new one.

Count €150 for a bundle RAM + SSD.

A need for a large desk

In order to put all the materials listed, you will need perhaps to invest in a real desk. You can’t develop WebRTC application using the dining table :-) You need to have your cozy place where you can access your phones, your cameras without having each time to put them away in a drawer.

To be honest, having a large desk (at least 160cm / 63‘ wide) is the minimum to be correctly installed.

Count €200 for a good quality desk

A need for several IP

The best way to simulate several network topologies is to use a VPN for one of your computer. By having it isolated from your other computer, it gives you the opportunity to test different networks.

A lot of VPN offers exist, some are free but bandwidth, speed and features may be limited. As you are testing WebRTC, the best is to take a paid offer.

Count less than €5 per month for using for example TunnelBear.

A need for several browsers

You can develop your WebRTC application in any compatible browsers of your choice. This is not mandatory to stick to a specific browser. But be careful, to check the behavior on the other browsers. It’s like adding CSS to your website. You need examining how it looks like on all browsers to be sure of the result. Do the same with WebRTC to prevent from a bad surprise.

Each time you develop a feature or use a WebRTC API, do a sanity check on all browsers your application supports. Sometimes it is better for one browser and less for another. Frequent checks will help you to progress step by step in the right direction. So install all the major browsers in your computer to be able to perform these tests.

Do not only test on browser that works. Trying different browsers such as the legacy Edge browser on Windows or the QQ Browser on Windows or Mac, lets you develop the case when the browser used is not compliant with WebRTC. This is perhaps a case you need to manage. On Mac OS, it becomes difficult to find a browser that is not compliant, hopefully QQ Browser, a chinese browser made by Tencent, is still not compliant at this time. Just to find a way to switch the language of the browser in english to facilitate the use.

Don’t forget that sometimes, the user can’t migrate to the browser he wants. Some corporate policies block the upgrade of the browser and so you can have your users that have a commonly used browser but with an LTS version. Some differences in term of behaviors could appear.

In the opposite, consider the possibility to evaluate your WebRTC application at least on a Beta version of the browser. This is something that helps you to be more confident. Don’t forget, browsers update them self each month or each two months and so the environment of your application changes at the same pace.

If you stick with the latest WebRTC API, you need to install at least a Beta version of each browser. For Chrome, you can install the Chrome for developers version that is updated every week and that contains the most recent development already merged. The same is provided by Firefox with the Firefox Developer Edition. For Safari, you can download the Safari Technology Preview to have access to an early version.

The need in term of browsers can be summarized like that:

Without using special LTS version, you can have up to 10 browsers installed in your development computer. Other browsers exist but are less used or reused the same engine as one of the major listed above such as Brave or Opera which used Chromium.

A need to access different network topologies

Testing several browsers at the same time on your PC is a first level of integration in which you simulate a local or a ‘no constrained‘ network. But one of the complexities of using WebRTC is to be able to establish a route between the participants. For testing these use cases, you need to test several network topologies like by mixing a mobile in 4G and your laptop/desktop and to connect several PC in two different networks.

I think this is not an easy part if you are working as a remote worker from home… If you’re are connected to the corporate network of your company, this should help you to test several networks or with some network equipments that can block the media flow. From home, you need some IT skills to configure several networks with your router or to block some ports.

Depending on the users targeted by your application, you will have to support more or less complex network topologies. If you are not able to test complex cases, what is interesting to check is at least that your TURN server works as it should. You can force using relay candidates only and check that your communication is correctly established. For the other cases, you will perhaps need to rely on some users who can’t establish an audio or video call with your application to grab logs from all the equipments to understand where is the issue.

A need for a network limiter

In many cases, you develop and test with the same network conditions. You are in a stable network. And often, you have a very good network condition. For example, you don’t move when you code :-). But in the ‘real life‘, you can be certain that your users move when in a call, take a lift or have suddenly a very limited bandwidth.

Hopefully, the codecs used for transmitting the voice and the video are very good and can adapt themselves to the changing network conditions. For example, WebRTC is able to downgrade the video quality and framerate to keep the minimal viable voice quality. This will keep the conversation possible even in bad network conditions.

But sometimes, when there are too many packets lost or when they are a high latency causing timeouts, the communication is cut and your application have to deal with by listening your signaling events and the WebRTC events.

Some tools exist to simulate bad network conditions such as the Network Link Conditioner on MacOS, Clumsy on Windows and the tc command on Linux. These are free. Some others not. I didn’t succeed to configure the Chrome developer tools network throttling profiles for the media part…

The network condition is something you have to keep in mind when developing your application to adapt your user interface depending on what happens. Concretely, WebRTC provides events that your application needs to catch in order to react. Don’t forget to test these cases too or at least manage the connection lost case by turned off your Wifi…

A need for tools and libraries

Back to the development part, when developing WebRTC, it is important to understand what is happening in real time with your application. For that, some tools can be used such as Wireshark to visualize the packets exchanged or the chrome://webrtc-internals tool that shows the constraints used, the connection and all the stats during the call in real-time. This is a precious help to control and check what happened specially when there is an issue.

Additionally, some JavaScript libraries can be used to help you to deal with the WebRTC complexity such as adapter.js that closes the gap between the browsers behaviors.

Mastering tools and using some great WebRTC libraries could really help you when building complex use cases. But these libraries need to be updated regularly in order to keep the right compatibility with the browsers. Avoid old and no more maintained libraries.

Conclusion

As you can see, developing WebRTC needs some preparation. Even if it is a Web application, you need to be equipped.

And that MVWDE (Minimum Viable WebRTC Development Environment) has a cost. If you summarize, the minimal investment, you can ask your boss for about €2000. A nice equipment price!!!

But, believe me, this is not a luxury when you will have to debug some critical issues coming from your customers :-)