On-prem WebRTC analysis: the answer used to be no

You know the security requirements in your company: No session data leaves the network. Not a sample. Not a redacted dump. Nothing.

Until August, that fact ended the conversation with us.

You could already self-host with our open source: Run rtcstats-js in your app, run rtcstats-server in your own VPC, and keep every dump inside your infrastructure. The part you could not self-host was the analysis. Getting an Experience Score meant sending a dump to rtcstats.com, which is a big NO for some companies.

That answer changed in August 2026, when rtcstats-enrichment shipped in v1.9. Enrichment is what I call the brain of rtcStats.

What runs inside your network now

rtcstats-enrichment is a REST service you run yourself - it holds the brain of the rtcStats analysis capabilities. Hand it a WebRTC dump file and it returns the enrichment as clean JSON: a scores object carrying the Experience Score out of 100 plus audio, video, and connectivity scores, per-severity observation counts, and the Observations flattened into SQL-friendly rows you can write straight into your own tables. No session is stored. It runs the same engine that rtcstats.com runs, and it returns the same payload shape as the hosted POST /v1.0/enrich endpoint, so a parser written against one works unchanged against the other. Point your rtcstats-server at it, or call it directly from your own pipeline.

One thing to know: the collection layer is MIT licensed. The enrichment engine is proprietary and available through our self-hosted Enterprise Edition.

Volume: the unit stops being the file

Hosted analysis is metered per session. One file, one credit. That model fits troubleshooting well, because troubleshooting is bursty: quiet weeks, then six dumps in an afternoon after a customer escalation.

Fleet-scale WebRTC monitoring and observability is a different beast. With the self-hosted enrichment engine, you can enrich every WebRTC session and see deployment-wide trends in how users experience your service. The license is sized by a declared sessions-per-day band rather than by individual files.

The analysis boundary, after the collection boundary

I argued that your session data should not leave your VPC by default. That post was about collection: rtcstats-server inside your perimeter, forwarding off by default, storage and retention under your own policy.

This is the other half of the same argument. IP obfuscation is on by default and runs before storage and forwarding. But once the analysis runs on your side too, the whole question shrinks. Your users' session data stays under the access controls, audit logging, and retention rules you already run, for every session, including the ones you analyze.

Shrinking your exposure surface

Ownership asks who holds the data. Exposure surface asks how many systems can reach it at all, which is a different review and often a different reviewer in regulated enterprises.

Every outbound integration is an endpoint in the egress allowlist, a vendor in the third-party register, and a line in the next questionnaire. When the enrichment engine runs locally, rtcStats analysis no longer requires session dumps to cross that boundary. That is a smaller answer to give a security team than any reassurance about how an external service handles the data it receives.

The per-session decision goes away

That previous post? Also asked you to decide which dumps are eligible to leave and be analyzed. Set randomPercentage to the share you are comfortable forwarding. Verify that the forwarded file contains no field you did not intend to share. That is a reasonable design when a boundary has to be crossed, and it is real recurring work: a judgment call that gets revisited every time your app adds a field, a new region comes online, or legal asks a question.

On-prem enrichment deletes the chore. There is no forwarding decision to make because nothing is forwarded. You stop budgeting which sessions are worth spending an approval on and enrich all of them, which is also how you get scores and Observations on the calls nobody thought to investigate. The output lands as rows beside the features rtcstats-server already extracts, in a database your team can already query, join, and put on a dashboard.

That gives you a bird's-eye view of trends across the deployment without sending a dump to rtcstats.com or sharing one with anyone else.

Why this matters now

More of the teams I talk to are in governed industries where a data-processing question has to be answered before a tool gets evaluated. More of them run deployments large enough that per-session metering becomes the wrong unit. And more of them arrive with data sovereignty already written into the requirements they were handed, rather than as a preference they are weighing. Those conversations used to end with me saying that we could not help beyond the open source collection piece. Well... now we can 😎

I tried it against an rtcstats-server deployment we run ourselves, with rtcstats-enrichment beside it. In one quick coding session with Claude, I built my own WebRTC NOC dashboard. Here is what I got:

A WebRTC NOC dashboard showing deployment-wide Experience Score, media quality, and connection-path trends.

Most of what you see comes from the enriched output. I focused on turning it into a useful single-glance view of deployment health. We can help you deploy this in your own infrastructure.

Start with the endpoint

You do not have to deploy anything to see whether the output is worth it.

Send a dump to POST /v1.0/enrich on the hosted API and read what comes back: scores, observationsCount by severity, the flat observations records, and the user-agent data. The endpoint is Bearer-authenticated and available on the paid plans. The session is never stored, and it costs one credit. rtcstats-server can store the returned scores and Observations directly in its SQL tables.

The engine runs on-premise under an annual license, entirely self-managed. The open source page has the shape of it, and the numbers come out of a conversation, so talk to us.

The collector was always yours. Now the brain can run on your side of the wall too.

Frequently asked questions

Can I run the rtcStats analysis engine in my own infrastructure?

Yes, since v1.9. rtcstats-enrichment is a REST service you run yourself. It takes a WebRTC dump and returns the Experience Score, the audio, video and connectivity scores, and the Observations as JSON. No session is stored and no dump leaves your network.

Is rtcstats-enrichment open source?

No. The collection layer, rtcstats-js and rtcstats-server, is MIT licensed. The enrichment engine is licensed separately, it is not in the GitHub trees, and it runs on-premise under an annual license that is entirely self-managed.

Why run enrichment on-premise rather than using the hosted analysis?

Three reasons come up: volume, ownership, and exposure surface. Hosted analysis is metered per session, so at fleet scale the constraint becomes credits. On-premise, throughput is bounded by your own hardware rather than by per-file credits, the session data stays under your own access controls, and no system outside your network needs to reach it.

Can I try the enrichment before deploying anything?

Yes, if you are on a paid plan. Send a dump to POST /v1.0/enrich on the rtcStats API and you get the same payload shape the on-premise server returns. The session is never stored, and it costs one credit per successful response.