Your session data shouldn't leave your VPC by default

Self-host WebRTC collection. Configure durable storage in your infrastructure. Nothing is forwarded to rtcstats.com unless you configure it.

A user reports a bad call. You need the getStats() timeline, ICE candidates, device details, and the events around the failure.

Then security asks the obvious question: where does all of that session data go?

The answer should not be "every session goes straight to somebody else's cloud."

With rtcStats, collection starts inside your infrastructure. You run rtcstats-js in the browser and rtcstats-server in your own VPC. The server receives and stores the session data before anything is sent elsewhere.

That gives you a useful control point: keep the full collection, review sensitive fields, and choose how much data rtcstats.com should analyze.

WebRTC metrics are technical, but they are not automatically harmless

Most getStats() values are technical measurements: packet counts, bitrate, jitter, round-trip time, frame rate, and codec details.

But a WebRTC session can also carry information your security team cares about:

• IP addresses in ICE candidates
• Page URLs and origins
• Device labels
• User, conference, or session identifiers added by your application

That does not mean you should stop collecting the data. Without client-side data, a call-quality investigation is mostly guesswork.

It means collection needs a boundary you control.

Put the collection boundary inside your VPC

rtcStats separates the workflow into three pieces:

1. rtcstats-js wraps RTCPeerConnection in your application and records the session timeline.
2. rtcstats-server runs inside your infrastructure and receives the data over WebSocket. When you configure S3-compatible object storage and a Postgres-compatible database, it stores dumps and metadata there.
3. rtcstats.com analyzes the sessions you send and returns visualizations, Observations, Deductions, an Experience Score, and an AI Summary.

The second step matters.

Your application does not need to stream every session directly to rtcstats.com. The open-source server sits between the client and the hosted analysis layer. Forwarding is disabled by default. You add the rtcstats.com endpoint and application token when you want hosted analysis.

So the full dataset can stay where your own access controls, storage policy, and retention rules already apply.

Decide what gets forwarded before you turn forwarding on

Hosted analysis requires the selected dump to leave your infrastructure. The control is in choosing which dumps are eligible to be sent.

For a small team, that may be the single stored dump attached to a user complaint. For a production service, randomPercentage controls the chance that each completed dump is forwarded. A value of 1.0 sends every dump. A value of 0.3 gives each dump a 30% chance of being sent, so the actual share varies. You can also keep forwarding off and upload a specific stored dump manually when you need help with it.

The pattern is simple:

• Collect inside your VPC.
• Keep the complete dataset under your control.
• Configure the forwarding probability you want, or leave forwarding off and upload one stored dump manually.
• Verify the forwarded file contains no fields you did not intend to share.

That is a much cleaner security review than starting with an always-on cloud collector and trying to work backward.

Use rtcstats-server as the privacy gateway

IP-address obfuscation is enabled by default and runs before storage and optional forwarding. But do not treat that as blanket PII removal. TURN relay addresses are kept for grouping, hostnames can remain unchanged, and the dump may still contain URLs, origins, device labels, and identifiers added by your application.

Do not put a person's name or email address into userId. Use a random identifier, or a value your own system can map back to the user when support needs it. Review the full privacy setup in How to configure rtcstats-server for privacy.

And test the setup. Inspect a stored session. Upload a test file. Confirm that the version visible in rtcstats.com contains what you expect and nothing else.

Privacy settings that nobody verifies are just configuration files.

Zero egress is a different requirement

Some environments do not allow selected sessions to leave the VPC at all.

In that case, do not pretend the normal hosted rtcstats.com workflow fits. Self-hosting rtcstats-server gives you self-hosted collection and storage. It does not, by itself, move the rtcstats.com analysis engine into your network.

That distinction belongs in the architecture discussion at the start, not in the small print at the end.

Choose the data boundary before the dashboard

WebRTC observability is easiest to trust when collection, storage, and analysis are separate choices.

Start with the part you control: run rtcstats-server in your infrastructure. Review the rtcStats architecture, configure privacy, and choose a forwarding sample. Then use rtcstats.com for the sessions you want analyzed.

Your users' full session history does not need to leave your VPC just because one call needs debugging.

Frequently asked questions

Does rtcStats send every WebRTC session to its cloud?

No. rtcstats-js sends session data to the rtcstats-server instance you run in your infrastructure. Forwarding to rtcstats.com is disabled by default. When you enable it, you can forward every dump or a random sample, or leave it off and upload a stored dump manually.

Can I self-host rtcstats-server?

Yes. rtcstats-server is open source and is designed to run inside your infrastructure. It collects WebRTC session data and writes the dumps and metadata to storage you configure before any optional forwarding to rtcstats.com.

Does self-hosting rtcstats-server also self-host the rtcStats analysis?

No. Self-hosting rtcstats-server gives you control over collection and storage. The standard rtcstats.com workflow analyzes the selected sessions you send to the hosted service. Treat a zero-egress requirement as a separate architecture discussion.