1137948 - signalling_unittests spends most of its time waiting for audio RTCP

Status: RESOLVED INCOMPLETE

(Core :: WebRTC: Signaling, defect, P3)

Description

[Byron Campen [:bwc]]

The webrtc.org code sends audio RTCP every 5 seconds, and since the first RTCP packet doesn't contain any receiver reports (since no RTP has been received), the first receiver report is sent about 5 seconds after the flow of media begins. This means that any test-case that wants to see a receiver report has to wait a while. This may also be making signaling_unittests vulnerable to intermittent timeouts.

We have a few things we could try doing about this:

1. We could make these timers configurable, and set them to something small when running test-cases like signaling_unittests. This would require some modification to the webrtc.org code.

2. We could attempt to prompt the webrtc.org code to send a receiver report sooner by using SetRTCPStatus when we receive our first RTP packet. This only cuts the timer in half, so it is still a long wait. Less code though. It is possible this will have benefits besides testing.

3. Cut down the number of test cases that look for RTCP drastically. I don't like this option, since we have very little testing of RTCP already.

Comment 1

[Byron Campen [:bwc]]

Attachment: Option 1: Force webrtc.org to schedule the next RTCP packet sooner when RTP starts flowing

Comment 2

[Byron Campen [:bwc]]

Comment on attachment 8570770 [details] [diff] [review]
Option 1: Force webrtc.org to schedule the next RTCP packet sooner when RTP starts flowing

Review of attachment 8570770 [details] [diff] [review]:
-----------------------------------------------------------------

Actually, this is option 2 in the description. Would like your thoughts on what our best bet is here. We could also make a small modification to make SetRTCPStatus set the timeout shorter than it does now, but that would still be a modification to the webrtc.org code, albeit a small one.

Comment 3

[Byron Campen [:bwc]]

Attachment: Part 1: Force webrtc.org to schedule the next RTCP packet sooner when RTP starts flowing

Comment 4

[Byron Campen [:bwc]]

Attachment: Part 2: (Optional) Make the RTCP interval configurable, and set it to 100ms for testing

Comment 5

[Byron Campen [:bwc]]

I've tried running signaling_unittests on CI without the patches in this bug, and the run-time of the test exceeds the 900 second limit imposed by the test runner. With these patches, I'm seeing it take around 560 on some platforms, so there seems to be a comfortable margin there.

Comment 6

[Byron Campen [:bwc]]

It seems that the first patch is not quite enough to get us under the 900 second limit on OS X. We will need either the second patch, or maybe a less-invasive patch that reduces the interval more when SetRTCPStatus is called (instead of 2500ms, make it something like 200ms for both audio and video).

Comment 7

[Byron Campen [:bwc]]

We need this fixed if we want to get the full signaling_unittest suite running on CI, but in bug 1140584 we're going to shoot for enabling a smaller subset of the test-cases to keep us under the time limit.

Comment 8

[Bulk Bug Changes for mreavy's org]

Mass change P4->P5 to align with new Mozilla triage process.

Comment 9

[Nils Ohlmeier [:drno]]

I'm guessing this is still a problem. Byron what do you think: close or keep it around for fixing?

Comment 10

[Byron Campen [:bwc]]

We haven't built signaling_unittests in quite some time, so we can close this.