← Back to Knowledge Base

WebRTC Metrics

A comprehensive overview of WebRTC statistics, derived calculations, extracted features, and observable signals, to better understand call quality, connectivity, and user experience in rtcStats

Back
On this page6 sections
connectionmetadatanegotiationtiming

Connection session metadata (feature)

Last updated Applies tortcstats-serverrtcstats.com

Per-connection shape and negotiation health: lifetime, event counts, negotiation rounds, signaling latency, and clock skew.

Description

Connection-level features, extracted per RTCPeerConnection into features_connection.

These features describe the overall shape of a single connection and the health of its negotiation:

  • startTime - timestamp of the first trace event for this peerconnection.
  • duration - the peerconnection lifetime in milliseconds (first event to last).
  • closed - whether pc.close() was called.
  • numberOfEvents - total number of trace events recorded.
  • numberOfEventsNotGetStats - event count excluding the periodic getStats polls, a rough measure of real API activity.
  • numberOfNegotiations - number of times signaling state returned to stable, one per completed negotiation.
  • pendingNegotiationAtEnd - whether the connection ended mid-negotiation (never returned to stable).
  • signalingDelay - milliseconds for the first offer/answer round-trip.
  • clockSkew - millisecond skew between the first getStats call time and the peerconnection stats timestamp.

Extracted by the open-source rtcstats-features package into your own database.

Why it matters

signalingDelay is your setup-latency signal before media even starts: a slow first offer/answer round-trip is time the user waits before anything connects, and it usually points at your signaling server or the network path to it, not at WebRTC. closed = false marks abandoned connections that were never torn down cleanly, which skews any aggregate that assumes a full lifecycle. A high numberOfNegotiations or pendingNegotiationAtEnd = true flags renegotiation churn (track changes, ICE restarts) that often correlates with instability. clockSkew is a data-quality guard: large skew means timestamps from that endpoint need care before you trust cross-metric timing.

Typical values

  • signalingDelay under ~200 ms on a healthy signaling path; hundreds of milliseconds and up is worth investigating.
  • numberOfNegotiations of 1 for a simple call; higher for calls that add or remove tracks.
  • clockSkew near zero; large values (seconds) indicate an endpoint clock problem.

SQL example

Signaling-delay percentiles and the share of abandoned connections:

SELECT
  PERCENTILE_CONT(0.50) WITHIN GROUP (ORDER BY connection.signaling_delay) AS p50_signaling_ms,
  PERCENTILE_CONT(0.90) WITHIN GROUP (ORDER BY connection.signaling_delay) AS p90_signaling_ms,
  COUNT(*) FILTER (WHERE connection.closed = false) AS abandoned,
  COUNT(*) AS total
FROM features_connection AS connection;

See also