Passive complaint handling

This is the suggested approach when what you want is to systematically collect and review metrics in your WebRTC application.

Here, you make use of the rtcstats open source project, integrating rtcstats.js to your client code and setting up your own instance(s) of rtcstats-server.

Storyline

The story-line goes something like this:

1. You want to be able to troubleshoot any session of any user in your application
2. Get rtcstats-js integrated in your web client code, so it can collect WebRTC traces
3. Setup your own rtcstats-server. Be sure to setup JWT authorization and configure how to identify calls and sessions collected
4. Direct your rtcstats-js to send its data to your rtcstats-server
5. Once there's a session you want to review, find its rtcstats file in your storage and upload it to rtcstats.com
6. Also, periodically (usually every few days), remove older rtcstats files to keep your storage costs at bay

NOTE:

• All of the above can be done using open source and a free rtcstats.com account
• We offer several support plans for the open source project. If you are interested to learn more, reach out to us
• On one of our paid plans, you will also have Observations and AI summaries, which will reduce your time to get to the root cause drastically. If you are interested in trialing these features, do let us know

Reasoning

Let's review quickly what are the advantages and challenges of this approach:

Advantages

• Easily troubleshoot and debug ANY session of ANY user in your application
• No more need to go back to users asking them to generate and send webrtc-internals files
• The SQL database created here can be used for BI and monitoring purposes as well
• No need to pay us anything (unless you want to - we won't complain)

Challenges

• Requires some engineering and DevOps effort to get started

Alternative routes

Here, there are a few different ways to get this integration in place:

1. When you want to view a specific session, find it in your storage and manually upload it to rtcstats.com for viewing
2. On a Developer plan, integrate with the API, so you can manually click a button on your dashboard to automatically upload and open that session directly in rtcstats.com
3. On an Enterprise plan, show the whole session embedded in your own dashboard, without needing to switch to another browser tab

Our suggestion

For WebRTC applications in production with more than 100 sessions a month, this can be a clear win.

It gives you complete visibility into your users base and can be used to troubleshoot any issue.

If you are just starting out, it might make sense to wait a bit before plunging in for this one. And if you are already collecting partial statistics (such as bitrate and packet loss only), then our suggestion is to replace it with something more robust that collects everything in order to be able to do real root cause analysis for your WebRTC application. And yes - rtcStats is the best way to do that.

As a first step, you can store rtcstats data to the browser's IndexedDB and pass it along to rtcstats.com only when needed. Read here on how to implement that quick hack: Never miss a webrtc-internals dump file