rtcstats

KO | EN

gitlite — search

#javascript #python #ai #llm #android #machine-learning #docker #macos #java #awesome #cli #awesome-list #mcp #open-source

(★ 38)

Monorepo for opensource RTCStats projects

rtcstats 최신버젼 다운로드

최종 버전 다운로드 (.zip)

// repository documentation

Was this content helpful?

★ 0 (0 ratings)

# rtcstats monorepo

> 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](https://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](https://rtcstats.com/integrations/mcp) (Model Context Protocol) on the Enterprise plan.

## Why rtcStats is built this way

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 typical RTCStats deployment
A full rtcstats-based deployment consists of
* a clientside SDK ([rtcstats-js](packages/rtcstats-js)) to collect the data.
* a server-side component ([rtcstats-server](packages/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](packages/rtcstats-features)) processing the dumps and extracting the features.
* optionally, the [rtcstats.com](https://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](packages/rtcstats-server/README.md#uploading-dumps-to-rtcstatscom).

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)
       +-------------------+
```

# End-to-end example

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.

# Building

Running
```
npm test
```
will run linting and unit/e2e tests in all sub-packages.

# Database Migrations
Database migrations are handled using [Supabase database migrations](https://supabase.com/docs/guides/deployment/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:
```sql
  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`.

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

This repository contains the current version of the legacy
[rtcstats-js](https://github.com/fippo/rtcstats) and [rtcstats-server](https://github.com/fippo/rtcstats-server).
The old versions are no longer maintained, friendly forks such as the [Jitsi one](https://github.com/jitsi/rtcstats) exist.

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

rtcstats

rtcstats 최신버젼 다운로드

오늘의 추천 프로젝트

Was this content helpful?

Recent Feedback

rtcstats

rtcstats 최신버젼 다운로드

오늘의 추천 프로젝트

Was this content helpful?

Recent Feedback

Download README