STR: Open https://jsfiddle.net/jib1/fjk3tw9e/1/ which calls `pc1.addTransceiver("video")` x 10 Expected results (subset of what Chrome produces): ``` Wait 5 seconds for rtcp packets... Have 10 sendonly transceivers pc1: 1 "candidate-pair" stats 1 "remote-candidate" stats 1 "local-candidate" stats 10 "outbound-rtp" stats pc2: 1 "candidate-pair" stats 1 "local-candidate" stats 1 "remote-candidate" stats 10 "inbound-rtp" 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.
Bug 1751532 Comment 0 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
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.
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.~
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.