Introducing rtcStats Observations: The WebRTC agent that sees issues before you do

WebRTC is great. At least when it works. When it doesn't, it can get quite messy - especially if you are the one in charge of figuring out and resolving the issues. This disrupts administrators, support and engineering, who now need to help users.

Your best friend here up until not long ago was webrtc-internals. Lucky for you, we've made it better. And now? We're taking it a notch further with the introduction of Observations into Developer and Enterprise plans.

3 core principles of Observations

Observations are meant to be your WebRTC agent - a set of best practices that end up seeing issues before you do - saving you expensive time so you can focus on the things that matter most - assisting your users and improving your application.

We've designed Observations to be focused on raising your awareness to behaviors and… observations… that contribute to actionability. Observations are rooted in these core principles:

• Actionable - Observations include the severity, surfacing issues that require your attention and prioritizing them based on their severity and time of occurrence. Before diving into the details of the WebRTC session, you will already know what it is you are looking for
• Specific - Observations are specific. They pin point on a behavior at a time, making them easier to trace and figure out. We're in the process of exposing our knowledge base full of insightful information on each Observation
• Time saving - Your time is important. Our efforts are focused on reducing the cognitive load associated with analyzing metrics and logs. The Observations we are introducing are "obvious" for a WebRTC expert who would be looking for them specifically. rtcStats looks for ALL Observations ALL the time across ALL rtcstats and webrtc-internals files

Proactive by design: What's in an Observation?

In rtcStats, an Observation is a rule that is based on WebRTC metrics and log events collected. This can be about certain aspects of a session (this was taken over TCP and not UDP), certain poor coding (too many iceServers configured), poor behavior (too many reconnections of the session) or just things going awry. If you look at the data for yourself, you'll see it, but who wants to spend that time if you can just get that Observation without all the searching?

An Observation also comes with an explanation, severity, timestamp and reference:

• The explanation is there to make it easy for you to figure out what it means
• Severity is there to guide you as to the importance of the Observation - some are informational while others indicate serious problems
• We timestamp the Observation when it occurred, making it easier to trace further when needed
• With the reference we enable deep linking directly to the metrics or events related to the Observation - again, to make it easier to trace further

Today, we already have 40+ Observations with more added with each release (at the time of writing, there are around 100 planned Observations already). We focus on things that our customers are interested in, so if you can't find the Observation to something and you think we should be figuring it out for you in rtcStats - just let us know.

When you open an internals file inside rtcstats.com, the first thing you'll see beyond some calculated averages of the session are the Observations found. From there, figuring out what's wrong is a breeze.

Get started today

The free version of rtcstats.com is great. We're investing heavily in it and making it the best troubleshooting visualizer on the market.

If what you're looking for is to save hours of analysis more, then the paid plans of rtcstats.com and the Observations feature they enable is what you are likely going to need.

Interested in learning more? Maybe even get an evaluation of the Developer plan so you can feel for yourself how much more you can save with rtcstats? Contact us and we'll get you settled with a demo and an eval.