Stats objects creation and WebRTC objects lifecycle

[dontcallmedom]

The spec is not particularly explicit as to when a given stats starts being reported. There is a mention of "created" for MediaSourceStats and RTCRtpTransceiverStats, but none of the other objects.

I think (but haven't been able to confirm for sure) that the variation across test results for MTI stats both across browsers and within a given browser are likely bound to this. In particular, the MTI test that waits for 20s reports lots more available stats than the other tests (even once manually removed the fields that are indeed not implemented in the said browser):

• https://wpt.fyi/results/webrtc/RTCPeerConnection-mandatory-getStats.https.html
• https://wpt.fyi/results/webrtc/RTCRtpReceiver-getStats.https.html
• https://wpt.fyi/results/webrtc/RTCRtpSender-getStats.https.html
• https://wpt.fyi/results/webrtc/getstats.html
• https://wpt.fyi/results/webrtc/RTCPeerConnection-getStats.https.html

Ideally, the main WebRTC spec would either provide a spec hook for stats creation, or would explicitly say when a given stats start being available.

I'm not sure if some fields for a given stat objects only start being set after some defined event; but if so, this should probably be made more explicit or being integrated more tightly in the WebRTC objects lifecycle.

[dontcallmedom]

to give a few examples of tests results that potentially show the need for more clarity:

• when do RTCPeerConnectionStats entries appear? from the WPT tests, it looks like they only appear when data channels are set up in Firefox. I guess one could interpret the fact that peer-connection stats are "related to RTCPeerConnection objects" to mean that RTCPeerConnection is the monitored object, and thus the stat itself should be made available as soon as the object is created, but that latter rule isn't really made explicit anywhere that I could find, and the implementation discrepancy seems to show it deserves more clarity
• conversely, Firefox reports outbound-rtp stats as soon as addTrack is called, whereas Chrome seems to be doing so only if there is a peer on the other side. That one may already be explicit enough in the spec

The lifetime of all RTP monitored objects starts when the RTP stream is first used: When the first RTP packet is sent or received on the SSRC it represents, or when the first RTCP packet is sent or received that refers to the SSRC of the RTP stream.

(but then, if Chrome's interpretation is correct, the test "getStats() with no argument should return stats report containing peer-connection stats and outbound-track-stats" should be fixed to make too-early-stats reporting fail)

[henbos]

Proposal: Add a sentence for each stats object explicitly saying when it is created