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

Issue 4237 link

Starred by 10 users

Issue metadata

Status: Assigned
Last visit > 30 days ago
NextAction: ----
OS: ----
Pri: 2
Type: Bug

Blocked on:
issue 6145

Sign in to add a comment

IceConnection state remains checking when DTLS handshake fails.

Project Member Reported by, Jan 27 2015

Issue description

What steps will reproduce the problem?
1. Open  2 tabs of on M41 mac. The iceconnection state remains checking.

What is the expected result?
Should be connected, seems to work fine on M40.

What do you see instead?

Please use labels and text to provide additional information.

Project Member

Comment 1 by, Jan 27 2015

Labels: Area-PeerConnection
Project Member

Comment 2 by, Jan 27 2015


Comment 3 by, Jan 27 2015

The behaviour can be observed in the attached webrtc-internals dump even:
Conn-audio-1-0-googWritable and Conn-audio-1-0-googReadable are true as well as googActiveConnection. Yet the only ice connection state change is to ICEConnectionStateChecking.
74.5 KB Download
Project Member

Comment 4 by, Jan 27 2015

Project Member

Comment 5 by, Jan 27 2015

Summary: IceConnection state remains checking when DTLS handshake fails. (was: IceConnection state remains checking on M41.)
Project Member

Comment 6 by, Jan 27 2015

Note: the cause of the failed handshake is fixed in BoringSSL now, so you'll want to revert this commit in chromium/src/third_party/boringssl/src if works in your checkout.
Project Member

Comment 7 by, Feb 2 2015

Project Member

Comment 8 by, Feb 2 2015

Labels: EngTriaged Mstone-44
It sounds like we need to go to the disconnected state when DTLS handshake fails, perhaps in WebRtcSession or PeerConnection, we need to listen to an event.

We should probably do that when look into having a "SignalConnecting" event on the transport code.
Project Member

Comment 9 by, May 21 2015

Unassigning bugs from Vikas
Project Member

Comment 10 by, Jan 29 2016

Labels: -Mstone-44
I can't trigger the DTLS handshake failure anymore, so as a result, I was able to successfully establish a tab-to-tab call on

I don't see any CLs linked to this bug, so I don't think it's been fixed. I'm therefore leaving this in an open state, but I am removing the milestone label since this bug hasn't been updated in quite some time.

Project Member

Comment 11 by, Nov 12 2016

Blockedon: 6145
This will be solved by implementing separate DTLS/ICE states (issue 6145).

Sign in to add a comment