Less is more in WebRTC monitoring

There are 100s of metrics and events in WebRTC. All of them are important. Some more than others. Some aren't important just up to the point where they make a difference between wasting a week on a user complaint to figuring and solving the problem in a couple of minutes.

Like anything else in our modern age, the amount of information hammering us when it is time to troubleshoot a WebRTC issue is overwhelming - and that's even for experienced WebRTC engineers.

In many ways, this has been our north star when it comes to deciding how to design and build rtcStats and where to put our combined weight.

The result is something that I have started calling the "less is more" concept of WebRTC (you can watch here), and it just dawned on me that it equally applies to WebRTC monitoring and what we're doing in rtcStats.

Overwhelming with webrtc-internals

webrtc-internals is akin to assembly language. As close as you can get to a machine that a human can still barely read, assuming he is proficient enough. It takes time and effort to use it, and… you'd rather not use it if you've got alternatives.

The thing is, with webrtc-internals and enough time, you are likely to be able to figure out over 85% of the complaints and issues raised. I've already listed the limitations of webrtc-internals in the past. The big one for me this time is just the amount of metrics one needs to sift through to figure out what's going on.

Taking this approach, of having anything and everything spread out for the support person or engineer who needs to debug things is kinda cruel. Not something I'd like to do to friends 😉

Underwhelming with bitrate, latency and packet loss

The other end of the same scale is to only collect what you need. But what do you need?

We've often seen applications collect the bare minimum - bitrate, latency and packet loss. Maybe also jitter. It gives you some of the top metrics, but it lacks in so many ways.

There are so many potential problems where these metrics tell you nothing. And then there are times that these metrics say that something is wrong, but figuring out what's wrong requires a whole other set of metrics. And for elusive problems you will regret that you did not collect them in the first place.

If this is all you collect, you might as well collect nothing at all…

Not because collecting nothing is better. But because if you don't collect, you're more likely to go for our middleground approach (since you have nothing at all).

The elusive middleground

Here's the approach we're taking with rtcstats.

Collect everything. Well… not everything. Most of everything - we do make sure to NOT collect useless large data like certificates in WebRTC stats. And we compress the data that gets sent over the wire and stored. But other than that? We collect everything.

Why? Because you never really know when you're likely to need those extra metric values.

The other thing is, that you still need to be able to look at all these metrics quickly. And better if you can figure out things like bitrate, latency and packet loss real quickly.

So… collect it all, and then have the most common metrics there are your fingertips as a first priority.

Less is more: collect everything BUT focus on the interesting

We've taken things a step further with rtcStats. What we do for our premium plans is handle Observations as well.

We don't only collect everything, enable showing everything and have the most common metrics at your fingertips.

We also analyze the actual metrics for best practices and anomalies, raising them to the top so you can figure out what's going on faster and with a lot less analysis than you ever would need otherwise.

You see? We try to have you do less to get more done. And the way we do it, is by doing a lot more for you. Confused? So are we 🤣

-

If you don't have an account on rtcStats yet, then open one now and start looking at your WebRTC stats properly.

And if you've already seen what we can do and want to check out the Observations, then contact us so we can set you up with a demo or an evaluation period.