868626 - [meta] Collect Telemetry data for WebRTC

Status: RESOLVED FIXED

(Core :: WebRTC, defect)

Description

[Randell Jesup [:jesup] (needinfo me)]

We'd like to collect a number of bits of data via telemetry about Webrtc:

Bandwidth available and variability in it
Video resolution used
Frame rate
Losses/re-transmissions
Delay
A/V sync quality
AEC quality (ERLE/ERL/etc)
ICE information
CPU use during call
# of calls
Duration of calls
User-supplied call quality metrics ala Skype

others?

Comment 1

[Gregory Maxwell]

also good to capture is jitter buffer depth statistics. E.g. how many people are getting 500ms of jitter buffer added delay.

Likewise, tracking jitter buffer drop and insert events (how much degradation do we have in just modulating the buffer depth) .

Comment 2

[Richard Barnes [:rbarnes]]

This bug appears to call for the collection of these statistics in the aggregate.  It could be much more interesting (from a scientific perspective) if these metrics could be associated with some idea of where the endpoints of the call are on the network.  For example, the endpoint IP addresses of the call, aggregated to at least /24 granularity.  Obviously, there are privacy concerns here, but I wanted to raise the question to see if there were some level of aggregation that might make this acceptable.

In a related vein, you might want to expand on "ICE information" a little, since there's likely some privacy concerns lurking in there as well.

Comment 3

[Randell Jesup [:jesup] (needinfo me)]

greg: The NetEQ jitter buffer is a fully adaptive jitter buffer, and as such doesn't have discrete grow-by-a-packet/drop-a-packet-to-shrink events.  You can measure underflows and overflows, and depth sampled at a moment and average or histogram of depth.