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
connectiongeolocationgeoipregionrelay

Geolocation (feature)

Last updated Applies tortcstats-serverrtcstats.com

Connection-level features annotating the geographic location of the local, peer, and relay endpoints of the selected candidate pair.

Description

Connection-level features, extracted per RTCPeerConnection into features_connection, plus a session-level rollup in features_metadata.

When your rtcstats-server is configured for geolocation, it annotates the endpoints of the selected candidate pair with geographic data:

  • rtcstatsLocationContinent / …Country / …City - the local endpoint.
  • rtcstatsPeerLocationContinent / …Country / …City - the remote endpoint.
  • rtcstatsRelayLocationContinent / …Country / …City - any locally-gathered relay candidate.

A session-level country/continent also lands in features_metadata (location_country, location_continent), which is the convenient grain for splitting session metrics by region.

These annotations come from the open-source rtcstats-features extraction combined with your GeoIP setup.

Why it matters

Geolocation is what turns every other feature into a regional metric. Relay rate by country, connection time by continent, freeze rate by region: all of it depends on these fields. It also lets you verify that traffic is being served from the right place: a relay in a distant continent from both peers is latency you can design away. Because location is derived on your own server from candidate addresses, no client-side geolocation permission is involved.

Common values

  • Continent/country/city strings; NULL when GeoIP is not configured or an address can't be resolved.
  • Relay location fields are only populated when a relay candidate was gathered.

SQL example

Sessions and relay rate by user country (session-level rollup), across connections that found a path:

SELECT
  metadata.location_country,
  COUNT(*) FILTER (
    WHERE connection.first_candidate_pair_local_type = 'relay' -- 'host', 'srflx' or 'relay'
       OR connection.first_candidate_pair_remote_type = 'relay'
  ) AS relayed,
  COUNT(*) AS total
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 connection.ice_connected -- only connections that found a path
GROUP BY metadata.location_country
ORDER BY total DESC;