"inbound-rtp" stats sholdn't be exposed on receiver ahead of incoming packets
Categories
(Core :: WebRTC, defect, P2)
Tracking
()
Tracking | Status | |
---|---|---|
firefox98 | --- | fixed |
People
(Reporter: jib, Assigned: pehrsons)
Details
Attachments
(2 files)
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.
Reporter | ||
Comment 1•3 years ago
|
||
Byron, thoughts on whether the current behavior is intentional or not?
Reporter | ||
Comment 2•3 years ago
•
|
||
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.
Updated•3 years ago
|
Assignee | ||
Comment 3•3 years ago
|
||
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?
Reporter | ||
Comment 4•3 years ago
|
||
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.
Reporter | ||
Comment 5•3 years ago
|
||
Here's the simpler inbound-rtp fiddle showing the problem in Firefox https://jsfiddle.net/jib1/b32myw94/9/
Assignee | ||
Updated•3 years ago
|
Assignee | ||
Comment 6•3 years ago
|
||
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.
Assignee | ||
Comment 7•3 years ago
|
||
Assignee | ||
Comment 8•3 years ago
|
||
Comment 11•3 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/0e7a4bf4ff32
https://hg.mozilla.org/mozilla-central/rev/3f8323b0d44a
Assignee | ||
Updated•3 years ago
|
Description
•