WebRTC mistakes: Common mistakes (beginner)

WebRTC can be hacked-away with great results. Often though, this leads to sub-par experiences due to basic WebRTC mistakes.

WebRTC as a VoIP technology is the best thing ever. It “democratizes” this whole domain, taking it from the hands of experts into the hands of the masses of developers out there. Slapping a bit of code and seeing real time video is magical. And we’re now starting to add it to more and more businesses using web technology.

While this all seems easy now (and it is a lot easier than it used to be before WebRTC), there are a few mistakes that many beginners make in WebRTC. And to be honest, these mistakes are not only made by beginners. That is why I am sharing a couple of common (beginner) mistakes in WebRTC that I’ve seen for a couple of years now.

1. Using an outdated signaling server (from github)

This happens all too often. You start by wanting to build something, you search github, you pick a project, and with WebRTC – it just doesn’t work. It might for the simple scenario but it won’t handle edge cases, or scale nicely, or accomodate for the more complex thing you’re thinking about.

The truth is, that today, there’s no single, goodly, off the shelf, out of the box, readymade, pure goodness, open source, signaling server for WebRTC that you can use. Sorry.

There might be a few contenders, but I haven’t seen any specific project that everyone’s using (unlike TURN for example, where coturn definitely rulz). The sadder truth? SFUs offer better signaling than signaling servers with WebRTC (and almost always I’d suggest against using their signaling directly in front of your WebRTC client).

2. Mis-configuring NAT traversal

This should have been trivial by now, but apparently it isn’t.

A few rules of thumb to avoid these WebRTC mistakes:

1. Don’t. Rely. On. Google. Public. STUN
2. Don’t use free github STUN and TURN server lists
3. Don’t decide not to deploy TURN because your server has a public IP address
4. And then a few

This is such a basic and common mistake that I even created a free video course for it: Effectively Connecting WebRTC Sessions.

3. Testing locally

This one’s also a basic WebRTC mistake.

Locally things tend to work well. Due to different network configuration, but also due to fairy dust that I am sure you sprinkle over your local router (I know I do every morning).

Once you go to the real world with real networks, things tend to break.

Test in the real world and not on your machine using 2 tabs, or being professional, from a Chrome tab to a Firefox tab.

The real world is messy and messy isn’t healthy for naive deployments.

Need help with automating that? Look at testRTC, but don’t neglect real world testing.

4. Not using adapter.js

WebRTC is a great specification but it is rather new.

This means that:

• Different browsers are going to behave a bit differently
• Browser implementations are somewhat buggy
• Different versions of the same browser act differently

And I haven’t even started about getting WebRTC browser implementations to be spec compliant with 1.0.

This all boils down to you having to work out a strategy in your code where all that if/then directives to deal with these differences takes place.

The alternatives?

1. Whenever you find such an issue, add that if/then statement in the code directly (the most common approach, albeit not really smart in the long term)
2. Create a shim/polyfill/whatever you want to call it, where you do all these if/then thingies (great, but not easy to maintain)
3. Just use adapter.js

Guess which one I prefer?

5. Forgetting to take care of security

Two reasons for you to forget about security:

1. WebRTC is secure, so why should you do anything more about it?
2. Because your service doesn’t deal with payments or sensitive data so why bother?

Both reasons are won’t lead you to a good place. In 2019, security is coming to the front, especially with communications. You can ask Zoom about it, or go check what Google’s Project Zero did recently.

Want a good starting point? I’ve got a WebRTC security checklist for you.

You can also dive deeper and learn more about WebRTC security.

6. Assuming you can outsource it all

You can’t. Not really.

Need a design for a whitepaper? An article written? A WordPress website created? Find someone on Upwork, Fiverr or the slew of other websites out there and be done with it.

With WebRTC? Don’t even think about it.

WebRTC is ever-changing, which means that whatever you deploy today, you will need to maintain later. If you are outsourcing the work – some of it or all of it – assume this is going to be a long term relationship, and that for the most part, you may be able to outsource the development work but not the responsibility.

Going this route? Here are 6 things to ask yourself before hiring an outsourcing WebRTC vendor.

7. Diving into the code before grokking WebRTC

1. Go to github.
2. Pick a project.
3. “Install” it.
4. Run it.
5. Fix a few lines of code.
6. Assume you’re done.

No. WebRTC is much more complicated than that scenario above. There are a few different servers you’ll need to deploy and use, there’s geography sensitivity to consider, and lots of other things.

You need to understand WebRTC if you want to really use it properly. Even if all you’re doing is using a 3rd party.

Note: See also the FAQ for WebRTC beginners.

Don’t make these WebRTC mistakes!

Be sure to review these to see if there’s anything you’re doin’ wrong:

1. Using an outdated signaling server (from github)
2. Mis-configuring NAT traversal
3. Testing locally
4. Not using adapter.js
5. Forgetting to take care of security
6. Assuming you can outsource it all
7. Diving into the code before grokking WebRTC

Check out my free WebRTC Basics course, or the bigger Advanced WebRTC one.