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 8 users

Issue metadata

Status: Assigned
Owner:
Last visit > 30 days ago
Cc:
Components:
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 vikasmarwaha@webrtc.org, Jan 27 2015 Back to list

Issue description

What steps will reproduce the problem?
1. Open  2 tabs of https://meet.jit.si/ on M41 mac. The iceconnection state remains checking.
2.
3.

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 vikasmarwaha@webrtc.org, Jan 27 2015

Labels: Area-PeerConnection
Project Member

Comment 2 by vikasmarwaha@webrtc.org, Jan 27 2015

Cc: jiayl@webrtc.org

Comment 3 by fi...@andyet.net, 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.
fail.json
74.5 KB Download
Project Member

Comment 4 by jiayl@webrtc.org, Jan 27 2015

Cc: pthatcher@webrtc.org
Project Member

Comment 5 by vikasmarwaha@webrtc.org, Jan 27 2015

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

Comment 6 by davidben@webrtc.org, 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 meet.jit.si works in your checkout.

https://boringssl.googlesource.com/boringssl/+/6ae7f072e3b220b17ca5182226de882d10080f50
Project Member

Comment 7 by juberti@webrtc.org, Feb 2 2015

Cc: juberti@webrtc.org
Project Member

Comment 8 by pthatcher@webrtc.org, 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 juberti@webrtc.org, May 21 2015

Owner: pthatcher@webrtc.org
Unassigning bugs from Vikas
Project Member

Comment 10 by tnakamura@webrtc.org, 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 https://meet.jit.si/

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 deadbeef@webrtc.org, Nov 12 2016

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

Sign in to add a comment