henbos

The [jitterBufferDelay](https://w3c.github.io/webrtc-stats/#dom-rtcaudioreceiverstats-jitterbufferdelay) (also exists for [video](https://w3c.github.io/webrtc-stats/#dom-rtcvideoreceiverstats-jitterbufferdelay)) is the sum of "each sample [or frame] takes from the time it is received and to the time it exits the jitter buffer...

In Chrome I believe this is already implemented for audio. This issue is for implementation status of the equivalent video metrics: https://bugs.chromium.org/p/webrtc/issues/detail?id=10450

And max: Would this max for the duration of the entire call, or a "recent max"? "Recent" values are a bit iffy, but "for the duration of the entire call"...

I agree that you don't want to poll getStats() too often, I usually recommend once every second or every few seconds. jitterBufferDelay is a sum of all delays of all...

> An alternative option is to have a few light-weight polling method focusing on smaller set of values. It doesn't exist today. I am doubtful if it matches webrtc roadmap...

(This is why audioLevel was added to getSynchronizationSources().)

Submitter input needed: is max really needed, given that you can poll this every second?

OK thanks

Added the icebox label based on no activity and editors not having heard a compelling use case.

@icydragons If this is a FEC packets sent/received we can create a PR.