← 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 page7 sections
connectionicedtlstiming

Connection setup time (feature)

Last updated Applies tortcstats-serverrtcstats.com

Connection-level features measuring how long a connection took to establish: iceConnectionTime for the ICE checks, connectionTime for the DTLS handshake that follows.

Description

Connection-level features, extracted per RTCPeerConnection into features_connection.

These features measure how long the connection took to come up, split into its two consecutive phases:

  • iceConnectionTime - milliseconds for the ICE connectivity checks to find a path (iceConnectionState from checking to connected).
  • connectionTime - milliseconds for the DTLS handshake that secures that path (connectionState from connecting to connected).

Two booleans say whether each phase completed at all, and explain a missing duration:

  • iceConnected - whether iceConnectionState reached connected at least once.
  • connected - whether connectionState reached connected at least once.

Added together, iceConnectionTime and connectionTime are the setup cost the user waits through after signaling: finding a path, then securing it.

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

Why it matters

"How long does it take to get a call connected" is the setup number everyone asks for, and these two fields answer it while also saying where the time went. A slow iceConnectionTime is a connectivity problem: candidates arriving late, checks timing out against a strict NAT or firewall, or a fallback to TURN. A slow connectionTime on top of a fast iceConnectionTime is a handshake problem instead, on a path that had already been found.

Tracked over time, both are deployment-quality gauges: a jump after a release, in one region, or on one client version points at a regression. Split by selected candidate pair and the relay premium becomes visible, since a relayed path usually costs more ICE time than a direct one. Split by ICE-lite peer and you can compare peer-to-peer setup against connections to your media servers, which normally connect faster.

The booleans matter as much as the durations. A duration is only meaningful when its phase completed, so iceConnected = false or connected = false marks connections that never established: a failure to count separately, not a slow setup to average in.

Typical values

  • Good: iceConnectionTime under ~500 ms, connectionTime under ~500 ms.
  • Concerning: iceConnectionTime above ~1000 ms, or connectionTime between 500 and 2000 ms, where users start to feel the wait.
  • Bad: connectionTime above 2000 ms, or iceConnected = false / connected = false, where the phase never completed.
  • Either duration can be NULL: filter on the matching boolean before averaging.

SQL example

Setup-time percentiles over the last 14 days, for connections that established, split into the ICE and DTLS phases:

SELECT
  PERCENTILE_CONT(0.50) WITHIN GROUP (ORDER BY connection.ice_connection_time) AS p50_ice_ms,
  PERCENTILE_CONT(0.90) WITHIN GROUP (ORDER BY connection.ice_connection_time) AS p90_ice_ms,
  PERCENTILE_CONT(0.50) WITHIN GROUP (ORDER BY connection.connection_time)     AS p50_dtls_ms,
  PERCENTILE_CONT(0.90) WITHIN GROUP (ORDER BY connection.connection_time)     AS p90_dtls_ms,
  COUNT(*) AS connections
FROM "rtcstats-server" AS server
JOIN features_metadata   AS metadata   ON metadata.dump_id   = server.id
JOIN features_connection AS connection ON connection.dump_id = metadata.id
WHERE server.created_at >= NOW() - INTERVAL '14 days'
  AND connection.connected -- only connections that reached 'connected'
  AND connection.ice_connection_time IS NOT NULL
  AND connection.connection_time IS NOT NULL;

The join down from "rtcstats-server" is what makes created_at available (see the master join). Group by DATE_TRUNC('day', server.created_at) to turn the same query into a setup-time trend across those two weeks.

  • DTLS and SRTP - what the connectionTime handshake negotiated: role, DTLS version, SRTP cipher.
  • Configured ICE servers - the STUN/TURN configuration the ICE checks had to work with.
  • Selected candidate pair - the path ICE ended up choosing, and the main explanation for a slow iceConnectionTime.
  • ICE-lite peer - whether the far side was a media server, which changes what a normal setup time looks like.
  • Offer and answer timing - the signaling cost that precedes both phases.
  • ICE warmup - ICE connected only after a restart, which inflates iceConnectionTime.
  • Connection warmup - the connection failed before establishing, which inflates connectionTime.
  • Connection failed - it never established at all.

See also