STR: Open https://jsfiddle.net/jib1/fjk3tw9e/1/ which calls pc1.addTransceiver("video") x 10

Expected results (based on spec. Chrome produces both 10 "inbound-rtp" and 10 "outbound-rtp"):

Wait 5 seconds for rtcp packets...
Have 10 sendonly transceivers

pc1:
1 "candidate-pair" stats
1 "remote-candidate" stats
1 "local-candidate" stats

pc2:
1 "candidate-pair" stats
1 "local-candidate" stats
1 "remote-candidate" stats

Actual results:

Wait 5 seconds for rtcp packets...
Have 10 sendonly transceivers

pc1:
2 "candidate-pair" stats
2 "local-candidate" stats
3 "remote-candidate" stats

pc2:
1 "candidate-pair" stats
2 "local-candidate" stats
2 "remote-candidate" stats
10 "inbound-rtp" stats

Firefox produces "inbound-rtp" on pc2 but no "outbound-rtp" stats on pc1.

The spec isn't super-clear here, but the overall direction the spec has taken is toward untangling the rtp pipes from the media sent through them. So while I could see some reason for the existing behavior (sender.track is null so nothing to report), the asymmetry on the other end seems to require the opposite rationale (no packets received yet, so let's report that). The former requires local action by JS while the latter doesn't, is perhaps one answer. At the same time I could see people expecting symmetry here.

Reporting this as a bug here. Happy to take it to the spec if we're confident about this being on purpose. See comment 2.

Byron, thoughts on whether the current behavior is intentional or not?

I found the answer 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."

So based on this, we should remove "inbound-rtp" stats in this state, not add "outbound-rtp" as I originally suggested. I'll update the subject, edit the expectations in the OP, and file bugs on the other vendors.

So if no media is flowing, could RTCP packets still flow? If so, can you be certain whether your fiddle is working or not in Chrome?

I've filed crbug 1291019 with a simpler fiddle that reproduces without establishing a connection.

I've also filed a tracking issue on WPT https://github.com/w3c/webrtc-stats/issues/619.

Here's the simpler inbound-rtp fiddle showing the problem in Firefox https://jsfiddle.net/jib1/b32myw94/9/

It's quite easy fixing the creation lifetime boundary of RTP monitored objects.

However:

RTP monitored objects are not deleted.

will require some refactoring, as this means rtp stats should remain available beyond pc.close(). But that's for another bug.

https://hg.mozilla.org/mozilla-central/rev/0e7a4bf4ff32
https://hg.mozilla.org/mozilla-central/rev/3f8323b0d44a