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

Status: RESOLVED FIXED

(Core :: WebRTC, defect, P2)

Description

[Nico Grunbaum [:ng, @chew:mozilla.org]]

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

Comment 1

[Andreas Pehrson [:pehrsons]]

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.

Comment 2

[Andreas Pehrson [:pehrsons]]

Attachment: Bug 1729364 - Before validating stats await *new* rtcp packets *after* media flows. r?jib!, r?ng!

Comment 3

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/d26abfa4748c
Before validating stats await *new* rtcp packets *after* media flows. r=ng,jib

Comment 4

[Cristina Cozmuta (:CrissCozmuta)]

https://hg.mozilla.org/mozilla-central/rev/d26abfa4748c