rtcStats architecture

Understanding the architecture of rtcStats is key to successfully integrating it into your application's tracing and observability workflow. The platform is designed with a privacy-first, modular approach, allowing you to collect, process, and visualize WebRTC data without exposing sensitive user information.

You can get quite far with our open source and freemium offering without incurring any ongoing costs.

The architecture consists of three primary layers: Collection, Mediation, and Analysis.

The three-layer flow

rtcStats consists of 3 layers, each in charge of a different piece of your WebRTC observability workflow:

1. The Collection Layer (rtcstats.js): Our open-source library SDK, rtcstats.js, wraps the standard WebRTC RTCPeerConnection. It periodically calls getStats() as well as internal events (like state changes or track additions)

   • Key Function: Intercepts and collect raw WebRTC metrics and traces in real-time
   • Payload: Generates a series of JSON "dumps" containing the trace data collected locally, to be sent to the mediation layer

2. The Mediation Layer (rtcstats-server): This is the "buffer" between your application and the rtcStats analysis engine. It is an open source project geared towards maintain your data sovereignty. You host your own instances of rtcstats-server as part of your infrastructure

   • Anonymization: The server can be configured to strip or mask sensitive data (like IP addresses, URLs or usernames) before it leaves your infrastructure
   • Feature extraction: The server extracts call-related features, storing them in an OLAP SQL database for easy querying

3. The Analysis Layer (rtcstats.com): Handles the deep analysis of WebRTC metrics through its Observations, as well as a powerful visualization engine for efficient troubleshooting and debugging

   • Visualization: The results are rendered into the interactive dashboard with quick and efficient root cause analysis as its prime goal
   • Inference Engine: This is where Observations and Deductions happen. The system analyzes metrics and trace events, figuring root causes and issues
   • AI Driven: An innovative AI model reviews the results and offers its analysis and summaries based on our best practices
   • Collaboration: Offers collaborative capabilities such as commenting and public sharing of results

rtcStats flow diagram

Below is a high-level representation of how data moves from a user's device to a shareable report:

TBD - IMAGE

TBD - EXPLAIN IMAGE

Key architectural benefits

We've built rtcstats with scale and real world use in mind. The following have been baked into every aspect of our service:

• Reduces your workload: Getting from hours down to minutes for debugging and troubleshooting WebRTC issues and figuring out root causes

• Low Overhead: The collection SDK library is designed to be “non-blocking” and lean, ensuring that monitoring your WebRTC sessions doesn't actually degrade the performance of the call itself or take up much processing (CPU and network use are kept to the minimum)

• Privacy by design: By using a self-hosted mediation server, rtcStats never has to see PII (Personally Identifiable Information) unless you explicitly allow it. You control and own your data, deciding if, what and when to share it

• Scalability: The architecture supports everything from individual manual uploads to high-volume platforms processing millions of concurrent sessions. It scales horizontally with common DevOps tooling