Chrome stuck in ice connection state of checking

[Cong Chen]

Hi,

I want to implement a server to echo the audio from Chrome. I use libnice to implement this server, and I exchanged the sdp and candidates without any problem,  and the component state in server  was "READY", but the ice connection state in chrome was  still "checking",  no any message was received in the server. 

FYI , I do not implement the "ice trickle" in the server ,  I sent candidates with the sdp. 

[Andres Gonzalez]

HI,

I will respond here instead of my original thread about this same topic.

I have the same results you are getting.  What confuses me is that chrome stays in the "checking" state even after it appears to have selected it candidates. Using wireshark, I verified that the connectivity checks succeeded, that is, each endpoint exchanged binding requests and success responses. I also noticed that the DTLS handshake using the selected address:ports was indeed started by the chrome client.  

So my conclusion was that chrome might not be transitioning connectivity states based only on ICE processing. I still do not know for certain if that is actually true, but it appears so to me because I can proceed with the DTLS handshake even while the chrome state remains stuck in "checking."  So for me, even though this issue and confusion remains, I moved on to working on the DTLS processing/coding in my server because the chrome client was giving me enough correct responses to continue developing that functionality. 

The point I am at now, is that, I can successfully complete the DTLS handshake and both my server and the chrome client exchange the DTLS Finished messages. But the chrome client is still stuck in the "checking" state even though the DTLS handshake has completed successfully.  So again for me, even though this issue and confusion remains, I have moved on to working on the SRTP processing/coding in my server. My thinking is that perhaps the chrome client will stay in the "checking" state until it receives my first SRTP media pkt, but I obvious will not know for certain until I get my SRTP processing/coding working successfully.

So perhaps you can do as I have done, that is, assume for now that what we are observing is "normal" behavior for chrome, at least until someone who actually knows for sure tells us otherwise.

-Andres

[Taylor Brandstetter]

You're right; the RTCIceConnectionState is actually a combined ICE and DTLS state. It's unintuitive, and unfortunately has been this way for quite a while. But we hadn't changed it because applications may need to know the DTLS state.

However, a while ago, an "RTCPeerConnectionState" was added to the standard, which is meant as a combination ICE and DTLS state. So the plan is to implement RTCPeerConnectionState as specified, and then have RTCIceConnectionState only reflect the ICE transport states. Here's a bug to track this work: https://bugs.chromium.org/p/webrtc/issues/detail?id=6145

As for your issue: if you see Finished messages but are still stuck in the "checking" state, some possibilities:

1. You aren't bundling and RTCP multiplexing, and DTLS finished for one transport channel but not the others. You should be bundling and RTCP muxing though.
2. The Chrome client didn't successfully process the Finished message. Do you see "DTLS handshake complete" in the Chrome debug log?

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/e3bb9e31-b364-4a48-8153-3e8ceb78d23b%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Andres Gonzalez]

Taylor, thank you so much for clarifying that for me. I spent several frustrating days dealing with this stuck-in-checking issue when I was integrating ICE functionality using libnice in my server.  When things don't work as expected, I always assume that I am doing something wrong or do not understand the RFC well enough. So I spent hours re-reading the RFC and studying the libnice source code trying to understand what I was doing wrong.  It wasn't until I noticed that the chrome client initiated the DTLS handshake with the correct address:port that it dawned on me that my code was actually working correctly and I was overreacting to the implemented meaning of the ICE connection state.  

You are also correct regarding my current lack of using bundle and rtcp muxing. I tend to be very incremental in my coding, so I wanted to get a single traditional media stream working in one direction first before I add the complexity of bundling and rtcp muxing. I am also using GStreamer for some of my current non-WebRTC  RTP streams so that was going to further complicate my server migration to WebRTC with its use of SRTP.   So, your clarification on the dependence of multiple transport channels on the ICE connection state explains what I am observing.

Again, Taylor, thank you for all of your responses, they have been very helpful.

-Andres

[Taylor Brandstetter]

Glad I was able to help you figure it out.

If you haven't implemented RTCP multiplexing yet, you should be able to get a single stream working as long as you do the DTLS handshake for both the RTP and RTCP connections.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/8389573f-2cf5-4a31-9de3-e796f9ef1084%40googlegroups.com.