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

ICE-lite peer (feature)

Connection-level feature recording whether the remote peer is an ICE-lite implementation, the practical way to tell peer-to-peer connections from connections to a media server.

Description

Connection-level feature, extracted per RTCPeerConnection into features_connection.

  • usingIceLite - whether the remote peer announced itself as an ICE-lite implementation in its SDP (a=ice-lite).

An ICE-lite implementation, defined in RFC 8445 section 2.7, does not run connectivity checks of its own: it sits on a public address, offers only host candidates, and answers the checks the other side sends. That is exactly how media servers are deployed, so in practice this field is a topology marker.

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

Why it matters

Mixed traffic makes aggregate numbers meaningless: a browser-to-browser call and a browser-to-SFU call have different setup costs, different candidate types, and different quality profiles, and averaging them together hides both. usingIceLite is the cheapest way to split those two populations, because ICE-lite is fairly common on the server side and is signalled explicitly.

Group any other feature by usingIceLite and you get the client-server cohort next to the peer-to-peer cohort: setup time, relay share, bitrates, freezes. It is also a deployment check on your own infrastructure. If your SFU is supposed to run ICE-lite, a population of usingIceLite = false connections that you expected to reach it means clients are landing somewhere else, or that the server is running full ICE.

The reverse inference is weaker: a server is not required to be ICE-lite, so usingIceLite = false does not prove the connection was peer-to-peer. Confirm with the selected candidate pair remote address when the distinction matters.

Typical values

  • true - the far side is a media server, gateway, or other lite implementation.
  • false - a full ICE peer: another browser, or a server that runs full ICE.

SQL example

Setup time and relay share, peer-to-peer cohort against the ICE-lite (server) cohort:

SELECT
  connection.using_ice_lite,
  COUNT(*) AS connections,
  PERCENTILE_CONT(0.50) WITHIN GROUP (ORDER BY connection.ice_connection_time) AS p50_ice_ms,
  AVG(
    CASE WHEN connection.first_candidate_pair_local_type = 'relay' THEN 1 ELSE 0 END -- 'host', 'srflx' or 'relay'
  ) AS relay_share
FROM features_connection AS connection
WHERE connection.ice_connected -- only connections that found a path
GROUP BY connection.using_ice_lite;

Related features

See also