Open Bug 1160680 Opened 9 years ago Updated 2 years ago

signaling_unittests is unreliable on tests that involve restarting ICE checks

Categories

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

defect

Tracking

()

Tracking Status
firefox40 --- affected

People

(Reporter: bwc, Unassigned)

References

(Blocks 1 open bug)

Details

I'm seeing somewhat frequent timeouts while waiting for RTP/RTCP in signaling_unittests because it is not waiting for ICE to complete before proceeding with the test. This is because the test-code spin waits on the ice connection state, which is already in completed before renegotiation happens.

Unfortunately there isn't a trivial fix here, since it is impossible to actually tell from the callbacks whether things really are still connected, or they aren't but checking hasn't started yet because no remote candidates have been received.

There are spec issues here too: when renegotiation causes a situation where ICE will need to go back to checking, but checking has not started yet because there are no remote candidates, what state should we be in? (new? connected? Something else?) Also, there is the question of when the transition to checking should happen; should it be set prior to the success callback for setting the answer? If so, we will need to do some refactoring.
I should also point out that settling the spec questions here might let us simplify our mochitests somewhat (right now, in every mochitest that does something that causes ICE to go back to checking, we have to flip an iceCheckingRestartExpected bool, which is a bit fiddly).
Blocks: webrtc_spec
backlog: --- → webRTC+
Rank: 35
Priority: -- → P3
Mass change P3->P4 to align with new Mozilla triage process.
Priority: P3 → P4
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.