Introduction

What is ObserveRTC?

ObserveRTC is an open-source toolkit for monitoring WebRTC applications. It is a set of libraries, not a service you sign up for: you include what you need, keep your data, and build the parts that are specific to your product.

The problem it solves is narrow and real. RTCPeerConnection.getStats() gives you a flat map of monotonically increasing counters joined by string ids. Almost every question you actually want to ask — what is the bitrate right now? is this video frozen? is the CPU the bottleneck or the network? is the whole room affected or one person? — requires differencing those counters, normalising browser differences, applying hysteresis so you do not alert on one bad tick, and then correlating across participants.

That is the work these libraries do.

What you get

Metrics, not counters

Per-interval bitrates, packet rates, RTT, jitter, loss, frame rates and their volatility — computed for you, on a navigable object graph.

Verdicts, not thresholds

Detectors with on/off hysteresis that raise an issue when a condition starts and resolve it when it ends, with a duration attached.

Correlation across participants

Server-side detection that separates 'one person's Wi-Fi' from 'this room is broken' from 'our infrastructure is in trouble'.

A versioned schema

One typed contract shared by every component, generated into TypeScript, protobuf and documentation from a single Avro source.

Why ObserveRTC

  • Open source. No hidden magic and no secret sauce — you can read exactly why a detector fired.
  • You own the data. It runs in your browser code and on your servers. Nothing is sent anywhere you did not send it.
  • Modular. Take the client library alone for in-call UX. Add the observer when you need cross-participant answers. Replace any piece with your own — they agree on a schema, not on an implementation.
  • Honest about its boundaries. It does not ship a database, a dashboard or an alert router, because you already have opinions about those. It gives you events and a live model.

What it is good for

Support triageA user says the call was bad at 3 pm. Issues carry a start, an end and a duration — you answer what was wrong, not guess from averages.
In-call UXShow a real warning at the moment congestion is detected and take it down when it resolves.
Adaptive behaviourPause screen share on sustained congestion, lower the encoding on CPU limitation, prompt a device check on a dry outbound track — in the client, before the user complains.
Release regressionTag samples with your build version and compare issue rates and score distributions between releases.
Infrastructure incidentsThe same symptom across independent calls implicates the servers, because those clients share nothing else.
Deployment validationProve that simulcast adapts per receiver, that track correlation is wired, and that you are on the codec you think you negotiated.

Who it is for

  • Application developers debugging real WebRTC problems in production.
  • Product owners who want quality trends they can act on rather than a vendor’s opaque score.
  • Operations teams who need to know quickly whether an incident is one user, one room, or the fleet.

Getting started

Next steps

Architecture

How the pieces fit together and where the client/server line is drawn.

Libraries

What each package does, and which ones you need.

Schema

The shared contract, and what changed in each version.