WebRTC observability: rtcStats reads a WebRTC dump and tells you what went wrong on the call. AI reads the dump so you don't have to.

This repository is the open-source collection layer of rtcStats: rtcstats-js (client-side monitoring), rtcstats-server (server-side dump collection), and the dump-importer (supporting both the rtcstats and webrtc-internals formats).

The hosted analysis layer at rtcstats.com turns collected dumps into Observations, Deductions, an Experience Score, and a plain-English AI summary of what went wrong on the call. You self-host the collector and choose what to send: there is no vendor lock-in, and there is a free plan. AI agents such as Claude Code and Cursor can query analyzed sessions over the MCP server (Model Context Protocol) on the Enterprise plan.

rtcStats keeps collecting session data, storing it, and analyzing it separate. The first two are open source and run in your stack. The third is optional and yours to trigger.

• Collection is a client SDK you control. rtcstats-js runs in your client and streams a dump of what WebRTC is doing to a server you run.
• Storage runs on your infrastructure. rtcstats-server receives the stream and writes each dump to your own storage. Session data lands and lives in your stack.
• Analysis is the layer you opt into. You choose which stored dumps to send to rtcstats.com: a random sample, per-user, per-region, a single dump when one call goes bad, or none at all. rtcstats.com returns Observations, an Experience Score, and a plain-English summary of what went wrong. It is the layer above webrtc-internals, not a replacement for it.

Send what you want, keep the rest.

Start at https://rtcstats.com

A full rtcstats-based deployment consists of

• a clientside SDK (rtcstats-js) to collect the data.
• a server-side component (rtcstats-server) acting as endpoint for collecting the data generated by the clientside SDK as a dump. This is backed by both
  • backend storage, e.g. Amazon S3 or compatible APIs.
  • A database for storing metadata about the dumps and features extracted from the dumps.
  • A load balancer in front of the server that handles TLS termination. rtcstats-server does not handle TLS itself.
• a server-side component (rtcstats-features) processing the dumps and extracting the features.
• optionally, the rtcstats.com hosted service can be configured as an additional upload target so collected dumps are forwarded there for visualization and analysis. See Uploading dumps to rtcstats.com.

Since metrics gathering is not time-critical, rtcstats-server can be deployed centrally in a single location. Multiple instances writing to the same storage and database can be used to scale the metrics gathering horizontally. The scaling properties for this are CPU load, disk usage and the number of concurrent websocket connections.

Feature extraction using rtcstats-features happens "offline" and separated from the main server, as experience has shown that this process is more CPU and memory intensive than the data collection. Like rtcstats-server, any number of rtcstats-features instances can process records in a single database. Since the location does not matter and is not time-sensitive this can happen in cheap regions or during a service's off-peak hours when there is spare compute resources available.

The system architecture is shown below:

       +-----------------+
       |   rtcstats-js   |
       |  (client-side)  |
       +--------+--------+
                |
                | Data Collection
                |
       +--------v----------+
       |  rtcstats-server  | (1..N)
       +-------------------+
                |
       +--------+----------+
       |                   |
+------v-------+    +------v--------+      +------------------+
|   Database   |    |    Storage    |<-----|  Visualization   |
|  (Postgres)  |    |   (e.g. S3)   |      |  (rtcstats.com)  |
+------^-------+    +------^--------+      +------------------+
       |                   |
       |  Dump Processing  |
       +--------+----------+
                |
       +--------v----------+
       | rtcstats-features | (1..M)
       +-------------------+

To start the local example version, run

npm install
npm start --workspace=example

This will start a minimal server, open a browser window, run some WebRTC-related API calls. Once done, a RTCStats dump file can be found in the example/upload/ directory which can be imported on RTCStats or the built-in dump importer.

Running

npm test

will run linting and unit/e2e tests in all sub-packages.

Database migrations are handled using Supabase database migrations. The migration files are located in supabase/migrations.

The initial table schema is defined in 20251103140656_initial-setup.sql and looks like this:

  create table "public"."rtcstats-server" (
    "created_at" timestamp with time zone not null default now(),
    "session_start" timestamp with time zone,
    "session_end" timestamp with time zone,
    "blob_url" text,
    "features_url" text,
    "metadata" jsonb,
    "id" uuid not null default gen_random_uuid(),
    "rtcstats_user" text,
    "rtcstats_conference" text,
    "rtcstats_session" text
  );

Database migrations can be deployed using supabase db push.

Migrations named ..._READ_BEFORE_APPLYING.sql need a manual step on a database that already holds rows. Read the comment at the top of the file before applying.

Note: while using supabase, the migrations are plain SQL and can be applied without relying on supabase.

This repository contains the current version of the legacy rtcstats-js and rtcstats-server. The old versions are no longer maintained, friendly forks such as the Jitsi one exist.

We invite you to use this version. We plan on keeping it well maintained, modernized and well behaved for all WebRTC applications.