← 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
connectionmetadatanegotiationtiming

Connection session metadata (feature)

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;

Related features

See also