New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 3021 link

Starred by 19 users

Issue metadata

Status: Assigned
Owner:
Last visit > 30 days ago
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

Issue description

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
This issue has been around for quite some time, and can be easily reproduced. Chrome M67 would never conclude its ICE state machine when in controlled role. 

Steps:
* Setup a call using https://webrtc.github.io/samples/src/content/peerconnection/pc1/ can be used to 
* Check iceconnectionstatechange for both controlled and controlling party

Sign in to add a comment