Open
Bug 1160680
Opened 10 years ago
Updated 2 years ago
signaling_unittests is unreliable on tests that involve restarting ICE checks
Categories
(Core :: WebRTC: Signaling, defect, P4)
Core
WebRTC: Signaling
Tracking
()
NEW
Tracking | Status | |
---|---|---|
firefox40 | --- | affected |
backlog | webrtc/webaudio+ |
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.
Reporter | ||
Comment 1•10 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).
Updated•9 years ago
|
Comment 2•7 years ago
|
||
Mass change P3->P4 to align with new Mozilla triage process.
Priority: P3 → P4
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•