signaling_unittests is unreliable on tests that involve restarting ICE checks

NEW
Unassigned

Status

()

Core
WebRTC: Signaling
P4
normal
Rank:
35
3 years ago
7 months ago

People

(Reporter: bwc, Unassigned)

Tracking

(Blocks: 1 bug)

Trunk
Points:
---

Firefox Tracking Flags

(firefox40 affected)

Details

(Reporter)

Description

3 years ago
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.
(Reporter)

Comment 1

3 years ago
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: 1165687
backlog: --- → webRTC+
Rank: 35
Priority: -- → P3
Mass change P3->P4 to align with new Mozilla triage process.
Priority: P3 → P4
You need to log in before you can comment on or make changes to this bug.