New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 16 users
Status: Assigned
Owner:
Cc:
Components:
NextAction: ----
OS: All
Pri: 3
Type: Bug



Sign in to add a comment
Transition to ICECompleted is flaky
Project Member Reported by bemasc@webrtc.org, Mar 8 2014 Back to list
In tests, the transition to ICE Connection State == Completed seems to be flaky, especially in tests on Mac OS / iOS, even when all "known" race conditions are fixed.

See also  issue 2993  (test failure) and https://webrtc-codereview.appspot.com/9609004/ (deflake by ignoring ICECompleted)
 
Comment 1 by fischman@webrtc.org, May 27 2014
Cc: wuchengli@chromium.org
 Issue 3403  has been merged into this issue.
Comment 2 by fischman@webrtc.org, May 27 2014
Labels: OS-All Area-PeerConnection Breaks-Bot
@bemasc: in dup  issue 3403  there's a linux repro (in case that's easier for you to use than osx/ios).  Do you think you can get to this soon?
Project Member Comment 3 by henrik.lundin@webrtc.org, Jun 2 2014
Issue 3432 has been merged into this issue.
Project Member Comment 4 by henrik.lundin@webrtc.org, Jun 2 2014
Labels: -Pri-2 Pri-1
FTR example bot to observe the flake on is http://build.chromium.org/p/client.webrtc/builders/Linux64%20Release%20%5Blarge%20tests%5D?numbuilds=200

When the flake hits the test's stderr ends with:
PCTest:offerer still waiting at
    org.webrtc.PeerConnectionTest.doTest(PeerConnectionTest.java:670)
    for: [expectedIceConnectionChanges: 1]


Project Member Comment 6 by wuchengli@chromium.org, Jun 3 2014
Cc: -wuchengli@chromium.org
Project Member Comment 7 by bugdroid1@chromium.org, Jun 3 2014
The following revision refers to this bug:
  http://code.google.com/p/webrtc/source/detail?r=6315

------------------------------------------------------------------
r6315 | fischman@webrtc.org | 2014-06-03T16:38:08.513442Z

Changed paths:
   M http://code.google.com/p/webrtc/source/diff?path=/trunk/talk/app/webrtc/javatests/src/org/webrtc/PeerConnectionTest.java&spec=svn6315&r_previous=6314&r=6315&format=side

PeerConnection(java): disable wait for flaky ICEConnection.COMPLETED.

This should be reverted when COMPLETED is delivered reliably.

BUG=3021
TESTED=without this patch the test fails in Debug mode after a handful of runs.  With this patch 100 runs passed in a row on my desktop.
R=henrike@webrtc.org

Review URL: https://webrtc-codereview.appspot.com/13569004
-----------------------------------------------------------------
Project Member Comment 8 by juberti@webrtc.org, Jun 6 2014
Ben, do we understand why this transition is flaky? Please update this bug with the current state.
Comment 9 by bemasc@google.com, Jun 6 2014
No, there's currently no theory for why this is a problem, but we've seen flakiness on a lot of different tests related to this ICE state now.  Many of them were cured, or almost cured (...) by lengthening timeouts.
I seem to be able to reproduce this issue. I compared logs of successful and unsuccessful connection, in the unsuccessful case I only see "Transport: audio allocation complete" but don't see the same print for the video allocation. I hope this might help to pinpoint the problem
This bug is not related to unsuccessful connections.  It refers specifically to unit test failures in which the connection succeeds, and reaches the "connected" state, but never reports "completed" to indicate that no further changes are expected.
That's my case, but there is no audio or video, so I consider it an unsuccessful call. The call itself seems connected, and I can disconnect and try again. One more input I have, is it only happens when iOS device receive the call (tried from both browser and Android device), but always works when iOS initiate the call.
Project Member Comment 13 by pthatcher@webrtc.org, Oct 16 2014
Labels: Mstone-41 EngTriaged
Owner: guoweis@webrtc.org
Guowei,  here's another bug for you :).  It may help you expand you knowledge of the network area.  
Project Member Comment 14 by guoweis@webrtc.org, Dec 13 2014
can someone still be able to repro this? I have found out couple cases where completed will just not fired. For example, if you have more than 2 networks and both of them have connectivity to the peer. I remedied the problem a bit when the 2 networks belong to 2 different ip family (ipv4 and ipv6).

Could you point me about how to repro this?
Cc: -fischman@webrtc.org
Project Member Comment 16 by pthatcher@webrtc.org, Jan 7 2015
Labels: -Mstone-41 Mstone-42
Project Member Comment 17 by pthatcher@webrtc.org, Feb 19 2015
Labels: -Mstone-42 Mstone-44
This looks like it's not hitting m42.  Update it if I'm wrong.
Project Member Comment 18 by juberti@webrtc.org, Jan 27 2016
Cc: deadbeef@webrtc.org pthatcher@webrtc.org
Has this issue been resolved? Saw a similar bug in the M49 release notes.
Project Member Comment 19 by deadbeef@webrtc.org, Jan 27 2016
Cc: guoweis@webrtc.org
Owner: deadbeef@webrtc.org
I'll take ownership from Guo-wei for this one and see if I can reproduce it.

Guo-wei: Is there anything you learned about this issue that isn't mentioned in a comment above? I don't think the "two networks" will be an issue any more, since completed is now defined as "one connection per network" in P2PTransportChannel.
Project Member Comment 20 by deadbeef@webrtc.org, Jan 28 2016
Labels: -Mstone-44
Removing milestone, since fixing this isn't a Q1 OKR.
Project Member Comment 21 by pthatcher@webrtc.org, Nov 8 2016
Labels: Pri-3
Sign in to add a comment