Closed Bug 1729364 Opened 3 years ago Closed 3 years ago

Audio remote-outbound RTP packets sent is unexpectedly zero in test_peerConnection_stats.html

Categories

(Core :: WebRTC, defect, P2)

defect

Tracking

()

RESOLVED FIXED
94 Branch
Tracking Status
firefox94 --- fixed

People

(Reporter: ng, Assigned: pehrsons)

References

Details

Attachments

(1 file)

test_peerConnection_stats.html is failing with the following error:

dom/media/webrtc/tests/mochitests/test_peerConnection_stats.html | remote-outbound-rtp.packetsSent is a sane number for a short audio test. value=0

https://treeherder.mozilla.org/jobs?repo=try&author=mfroman%40mozilla.com&selectedTaskRun=W5ZoDEjWR0aRRM3eHpBahw.3

https://treeherder.mozilla.org/logviewer?job_id=350517429&repo=try&lineNumber=59341

Summary: Audio remote-outbound RTP packets sent is unexpectedly zero in dom/media/webrtc/tests/mochitests/test_peerConnection_stats.html → Audio remote-outbound RTP packets sent is unexpectedly zero in test_peerConnection_stats.html

See pernosco for an analysis of this.

In essence:
In the test we wait for some media flow and some rtcp packets to be received, but that is not enough.
The order goes something like this (the two sides are separated):
Remote R:

  • R sends an RTCP sender report containing 0 packets sent
  • R sends an RTCP receiver report (probably containing 0 packets sent)
  • R sends RTP packets
  • R sends an RTCP sender report containing N packets sent

Local L (NB first does waitForMediaFlow, then waitForSyncedRtcp:

  • L receives an RTCP sender report containing 0 packets sent
  • L receives an RTCP receiver report
  • L receives RTP packets
  • waitForMediaFlow is satisfied by
    • local media element playing (R's side gUM)
    • remote media element playing (L's side did receive RTP)
    • inbound RTP flow (L's side did receive RTP)
    • outbound RTP flow (R's side did send RTP)
  • waitForSyncedRTCP is satisfied by
    • remoteId (filled in when we have received RTCP, and we have) and localId (always filled in) are present on all *bound-rtp
    • remote-inbound-rtp is present with an rtt (on L, because it received a receiver report)
  • Test fails because L's remote-outbound-rtp stats has 0 packetsSent
  • L receives an RTCP sender report containin N packets sent

This order seems fine to me at first glance. If anything seems peculiar it would be why R sends an RTCP SR before having sent RTP. Is there anything regulating this though?

My thought on a fix is to, after awaiting inbound and outbound RTP flow, also wait for new RR and SR reports to come in. remote-outbound could wait for an update to remoteTimestamp. remote-inbound could, well there's nothing ideal, but waiting for an update to bytesReceived might do the trick.

Assignee: nobody → apehrson
Status: NEW → ASSIGNED
Pushed by pehrsons@gmail.com:
https://hg.mozilla.org/integration/autoland/rev/d26abfa4748c
Before validating stats await *new* rtcp packets *after* media flows. r=ng,jib
Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → 94 Branch
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: