WebRTC conference calls. What could possibly go wrong?

Conference calls were always complex. WebRTC might have made joining them simpler, but it does come with its own set of headaches.

I’ve been in the industry for the last 20 years or so (a dinosaur by now). I had my share of conference calls that I joined or scheduled. As humans, we tend to remember the bad things that happened. The outliers. There are many of those with conferencing.

When I saw this Dilbert strip the other day, it resonated well with the “Supporting WebRTC” course I’ve been working on these past few months:

One of the things I am dabbling with now in the course are media quality issues. This was spot on. So of course I had to share it on Twitter, which immediately got a colleague to remind me of this great Avengers mock video conference:

https://www.youtube.com/watch?v=6PjW6c6o3i4

The funny thing is that this still occurs today, even if people will let you believe networks are better and these problems no longer exist. They do. Unless you are Zoom - Zoom always works. At least until it doesn’t…

What can possibly go wrong?

This one was just published today, so couldn’t resist…

A modern WebRTC service today will have a few potential failure points:

1. The cloud vendor’s infrastructure
2. Your own infrastructure
3. The user’s network
4. The user’s browser
5. The user’s device

Let’s try to break these down a bit

1. The cloud verndor’s infrastructure

Here’s a secret. AWS breaks from time to time. So does Azure and Google and Digital Ocean and practically everyone else.

Some of these failures are large and public ones. A lot more are smaller and silent ones that aren’t even reported in the main status pages of these cloud vendors. We see that in testRTC - as I am writing these words, we are struggling with a network or resource issue with one of the cloud vendors that we are using, which affects one of our services (thankfully, we’re still running for most of our customers).

Your service might be unreachable or experiencing bad media quality because of the cloud vendor you are using. Fortunately, most cases, these are issues that don’t last long. Unfortunately, these issues are out of your control.

2. Your own infrastructure

This one is obvious but sometimes neglected. What you run in your backend and how the client devices are configured to use it has a profound effect on the quality of experience for your users.

I’ve seen anything from poor ICE servers configuration, through bad scaling decisions to machines that just need a reboot.

WebRTC has a lot of moving parts. You need to take good care and attention to them.

3. The user’s network

Now we head towards the things that you have no control over… and primarily that is the user’s network.

You. don’t. have. control. over. what. network. your. customer. Uses.

He might be over a poor 3G connection (yes, we still have those). Or just be too far from the closest WiFi hotspot he is connected through. Or any other set of stupid issues.

In enterprises, problems can easily include restrictive firewall configurations or use of an HTTP proxy or a VPN.

Then there’s the congestion on the user’s network based on what OTHER people are doing on it.

Here, what you’ll need to do is to be able to understand the issue and explain it to the user to help him in squeezing more out of the network he is using.

4. The user’s browser

Here’s another challenging one.

The first one is a bit obvious - modern browsers automatically upgrade. This means you will end up with a new browser running your app one day without Apple, Google, Microsoft or Mozilla calling you to ask if you agree to that. And yes - these upgrades may well change behavior for customers and affect media quality.

Then there’s the opposite one - in enterprise environments, IT administrators sometimes lock browser versions and don’t let them upgrade automatically.

The biggest challenge we’re now facing though are Google experiments, like the one conducted with mDNS in WebRTC. Google is conducting experiments in Chrome on live users sporadically. You have no control over these and no indication where and how they are conducted. The whole purpose of this is to surface issues. Problem is, you won’t know if it breaks things for you until someone complains (or unless you monitor your deployment closely).

5. The user’s device

The device the user uses affects quality. Obviously.

Tried recently to use an iPhone 4 with a WebRTC service? :-)

The CPU, memory, software and other processes your user has on the device will affect quality. Add to that the fact that certain devices and peripherals behave differently and have their own known (or unknown) issues with WebRTC, and you get another minor headache to deal with.

The things we can control in our WebRTC conference calls

Here’s where we started - a modern WebRTC service today will have a few potential failure points:

1. The cloud vendor’s infrastructure
2. Your own infrastructure
3. The user’s network
4. The user’s browser
5. The user’s device

In WebRTC calls, you can control your own infrastructure. And you can build it to work around many cloud vendor’s infrastructure issues.

You can try to add logic that deals with the user’s device.

You can probably deal with many of the user’s browser issues by more testing and running their unstable and developer preview releases.

The things we can’t control in our WebRTC conference calls

The main thing you can’t control is the user’s network.

What you can do here is to provide better support, assisting your users in finding out the issues that plague their network and suggesting what they can do about it.

Two things you will be needing to get that done: tooling and knowledge

The tooling side I’ll probably touch in a future article. The knowledge part is something I have a solution for.

How can you better serve your customer?

In the last few months I’ve been working on the creation of a new “Supporting WebRTC” course. This course is geared towards support people who get complaints from users about their service and they need to understand how to help them out.

The course started through conversations with support teams in widely known providers of WebRTC services, which turned into a suggested agenda that later turned into a real course.

There are already close to 6 hours of content split into 33 lessons, with more to be added in the next month or so.

I’ve decided to open up registration to the course to everyone and not limit it to the limited pre-launch users I’ve shared it with. I feel it is the right time and that the content there is rock solid.

If you want to improve your knowledge or your support team’s knowledge of WebRTC, with a focus on getting them making your users happy and using your service, then check out my course.

Register to the Supporting WebRTC course