The RTCPeerConnection.getStats[1] should be unflagged as soon as everything deemed critical to support has been implemented and the spec is likely to not drastically change.
All stats objects are described here[2]. The stats objects are dictionaries and only the supported and available stats are returned at the time of calling getStats.
The launch will include most stats, with more stats being added in future releases.
For a complete implementation of getStats, see bug[3] or overview in code[4].
This bug will be updated with launch-related status and blocked on only bugs that need solving in order to launch.
[1] https://w3c.github.io/webrtc-pc/
[2] https://w3c.github.io/webrtc-stats/
[3] https://bugs.chromium.org/p/webrtc/issues/detail?id=7060
[4] https://cs.chromium.org/chromium/src/third_party/webrtc/api/stats/rtcstats_objects.h
We have implemented enough stats that exposing getStats makes sense to do now.
Here's an overview: https://docs.google.com/document/d/1Wc6a4o0PqTxIWD7LM_smA7Z0GZUTy6XOgr1qyS4M7hQ/edit?usp=sharing
With https://codereview.webrtc.org/2619353007 all recent spec changes will be implemented, and stats just need to be added, not modified.
RTCMediaStreamTrackStats has been modified to be per-attachment to the peer connection and this has been implemented. This was one of the previous blockers.
The other significant risk to have a big impact on the API is the discussion about the selector argument, which if added is an optional argument. This does not block exposing parameterless getStats.
Comment 1 by hbos@chromium.org
, Jan 26 2017