stuck in ice connection state of checking

[Andres Gonzalez]

Hi,

I have been working on a C++ server app that uses the libnice library for all of the Ice processing. I think I have it working correctly in that candidates are gathered and a pair is selected. However, the chrome client never progresses past the Ice Connection State of "checking"

Both the chrome client and the libnice server are on the same local network. The offer/answer exchange is successful.  The offer was "a=setup:actpass" and the server answer sent "a=setup:passive" 

The server libnice routines gather the local candidates correctly and receive the remote candidates from the chrome client correctly, . Wireshark shows that the chrome client sent the STUN messages with USE-CANDIDATE and the libnice callback "new-selected-pair" fired and I got the correct pair of local addresses.  The libnice candidate state for both connection ids is "ready".  So it appears that Ice processing on the server is complete.

The chrome client gathers its local candidates correctly and receives its remote candidates from the server correctly. All error routines are logged and no errors occur.   The chrome client signaling state is "stable" and the ice connection state is "checking" but I do not see any evidence that the chrome client is now attempting the DTLS handshake.

Question: is there something I need to call in the libnice API that would tell the chrome client to start the DTLS handshake?   The libnice documentation seems to imply that there is nothing else I need to call (the doc says that it does not hand off any of the STUN message that it should handle). But since the whole connection is now stalled it appears I have forgotten something because the chrome client does not start the DTLS handshake.

Question: is there something I need to call in the chrome client to start the DTLS handshake?  All of the example js code I have studied appears to indicate that the initiation of the DTLS handshake is all handled under the covers without explicit PeerConnection API calls.

Thanks,

-Andres

[Taylor Brandstetter]

Chrome won't start the DTLS handshake until it receives a STUN binding response, indicating that a candidate pair is usable. Do you see one sent by libnice in Wireshark?

If that's not the issue, I can't think of anything else off the top of my head. But a Chrome debug log would probably help get to the bottom of it.

--

---
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/6faa5c1b-69b1-4c6b-baa1-6bfd441eb8d9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Andres Gonzalez]

Thanks for your reply Taylor. 

The chrome client is in the controlling role and sent a STUN binding request to the libnice server, and the libnice server replied back to the chrome client with a Binding Success Response and the XOR-MAPPED-ADDRESS address. But I do not see any STUN binding requests sent from the libnice server to the chrome client. So it appears I have not used the libnice API correctly.

[Taylor Brandstetter]

Hmm. Even if Chrome doesn't receive a binding request, a response should be enough for it to start DTLS. Assuming it really chose the client (active) DTLS role as intended.

--

---
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/9d38da13-08b8-441d-97a5-fd98ae4c00bc%40googlegroups.com.

[Cong Chen]

Hi Andres,

I met the same problem as your, have you solve the problem yet?