Open Bug 868626 (webrtc-telemetry) Opened 7 years ago Updated 6 years ago

[meta] Collect Telemetry data for WebRTC


(Core :: WebRTC, defect)

Other Branch
Not set




(Reporter: jesup, Unassigned)



(Keywords: meta, Whiteboard: [WebRTC],[blocking-webrtc-])

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

Depends on: 874175
No longer depends on: 874175
Depends on: 874175
Depends on: 874670
Alias: webrtc-telemetry
Blocks: 875035
Depends on: 875097
Depends on: 875556
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) .
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.
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.
Depends on: 1020164
You need to log in before you can comment on or make changes to this bug.