There is no denying that WebRTC is taking the industry by storm. The Chrome browser alone has recorded over 2bn active WebRTC users, 1bn WebRTC audio/video minutes per week, and 1 Petabyte of DataChannel traffic per week (0.1% of the entire web traffic).
In short, using the technology in VoIP applications can grant impressive results, at least what these stats claim. However, it is also true that many businesses fail to achieve desired results when they implement WebRTC practically. Recently someone had shared how a WebRTC project that was expected to complete in 60 hours was stretched over the course of a few weeks.
The Internet is full of such WebRTC failure scenarios. Chances are that you might have even encountered some of them in your office, and the main reason for them are some mistakes that many of us make while working on the technology. While most of these WebRTC pitfalls are beginner level, even experts make them from time to time. This is the reason why we are here with this blog in which we will share 7 such common WebRTC pitfalls that should be avoided at any cost. Let’s begin:
Pitfall 1: Failing to Configure STUN/TURN Correctly
Misconfiguring NAT traversal servers (STUN/TURN) is one of those WebRTC pitfalls that even the most experienced businesses tend to make. Just a few days back I was reading about how someone tried running their WebRTC application by hosting their signalling and web servers on HostGator without STUN/TURN servers and failed miserably.
Truth is that except some rare scenarios, STUN server is a must for running WebRTC applications. You will also need TURN servers if you want sessions to connect.
Apart from this:
- Don’t rely on free STUN servers and not use Free TURN servers. There is a reason there are none of them out there. You can’t even find good code on Github that has TURN figured out because there is none.
- If you are lucky enough to find a free TURN server with user/password credentials, please don’t use them. Otherwise, someone else may end up footing the bill for you which is not ethical.
Also, the other person will shut you out of the server the moment he/she will find out.
- Don’t force all the sessions via TURN unless you know what you are doing.
- Remember than TURN has no added security.
- Protect your TURN server with temporary/ephemeral passwords.
Pitfall 2: Choosing Wrong Signalling Framework
Most of the times, businesses tend to look for popular GitHub signalling projects while trying to implement a signalling project for WebRTC – and this is where they go wrong.
While you find lots of free signalling projects on GitHub, most of them are not well maintained. Some were even updated years ago. So, using them is not wise at all.
There are also others which are regularly updated like Muaz Khan’s code snippets. However, they are just code snippets, and expecting them to be commercial grade & stable products will be a mistake.
So, be careful and avoiding choosing wrong signalling frameworks. In case, you are using an open-source project:
- Make sure it was updated recently.
- It should be popular.
- You must be able to understand its code or maintain it on your own if needed.
- There should be someone you can rely on in the times of trouble.
In simple words, don’t take the selection process lightly and choose your signalling server wisely. It will help you in the long run.
Pitfall 3: Testing the WebRTC Application Locally
A common approach among developers is to test the WebRTC application on the local environment. Things tend to work well locally because the devices are connected with the same server and have almost the same IP address. There is not even a firewall that may stop devices from connecting.
However, things tend to break when you enter the real world with real networks. Devices are connected on different servers, have different IP addresses, and encounter firewalls that may prevent your devices from connecting. Establishing a secure WebRTC connection amidst so many challenges will be the real test for your WebRTC application.
So, instead of testing your WebRTC applications on local environment, run them in real world and see how they respond. Don’t fall for the trap of testing on your machine using 2 browser tabs or just two different browsers. Things will get mess in the real world, otherwise.
Pitfall 4: Not Using adapter.js
Since WebRTC is a new technology, it may behave a bit differently on different browsers. Even not just browsers but on different versions of browser as well.
This means unless you have a code strategy in place, WebRTC might turn out to be a nightmare. Fixing issues separately for each browser update would be difficult.
This is the reason why you should use adapter.js. It will act as a glue for binding your code to different browser implementations of WebRTC so that when the new WebRTC updates are released, you don’t have to make changes everywhere.
Pitfall 5: Not Considering Security
Here’s what most businesses think when the topic of implementing security in WebRTC is brought onboard:
- Is it necessary? WebRTC is already secure.
- Nah! We are using payment integrations or sensitive data in our app. So, why bother?
This is where you can go wrong. Remember what happened with Zoom the last year? You can also read this blog by Google Project Zero in which they have listed down various issues they found WebRTC.
WebRTC is secure but also needs protective measures from your end. Relying on the WebRTC security alone or ignoring it will do you no good.
So, pay attention to WebRTC security and take all necessary measures from your end.
Pitfall 6: Planning Short-term
Here’s what business commonly do when they are looking forward to having a WebRTC app:
They look for an outsourcing vendor, write a nice requirements doc, pay the person, get something designed, and they are done.
But then what if the browser gets updated? You will have to contact the vendor to update the entire application once again, and the browser updates happen quite often.
So, it’s important to plan things long-term while developing WebRTC applications. Here’s what you do:
- Use a WebRTC API platform. It would cost less money. There will be maintenance work, but not that much.
- Develop the WebRTC application in house. In case, you are thinking about outsourcing, choose a partner you can rely on for long time.
Remember that the WebRTC code rots much faster. After a couple of days when the new browser update will be released, it needs to be modified. Unless you have a long-term approach, managing the WebRTC applications will be a nightmare.
Pitfall 7: Implementing WebRTC without Understanding it
Assumption is the mother of all mistakes, and WebRTC is no exception. Since the technology is relatively new and most of the online information about it is inaccurate and full of assumptions, there are higher chances that you may misunderstand it and take decisions that may not go in your favour. When we plan on using WebRTC without understanding it, chances of making falling into WebRTC pitfalls and failing miserably are higher.
So, if you plan on using WebRTC, make sure you first understand everything about it. You need to understand everything like what servers you need for deploying WebRTC, how the signalling mechanisms are built into it, and how the media process and sent over different networks.
By avoiding these WebRTC pitfalls, you can make sure you can benefit the most from the technology. However, saying so is easier said than done. When you will develop a WebRTC app, you will make mistakes and you will need guidance from someone who has expertise in the technology. Having more than 8 years of experience in the technology and having built projects like EasyWebinar, we can help.
