ICE Restart - connection state checking?

[Xander Dumaine]

I'm trying to work out an ICE restart flow wherein the remote side is sending new candidates with updated ufrag and pwd. On my side, I set remoteDescription, createAnswer, setLocalDescription, add the new candidates. After that, ICEConnectionState goes to gathering, new candidates are gathered, then the ICEConnectionState goes to disconnected about 5 seconds later

One red flag I see here is that I don't see ICEConnectionState go to checking after the restart. Any ideas? 

[Philipp Hancke]

looks like you're adding the same ice candidates including the old generation extension. This might lead to them being ignored so there are no valid pairs.

2016-05-19 13:31 GMT+02:00 Xander Dumaine <xander....@gmail.com>:

I'm trying to work out an ICE restart flow wherein the remote side is sending new candidates with updated ufrag and pwd. On my side, I set remoteDescription, createAnswer, setLocalDescription, add the new candidates. After that, ICEConnectionState goes to gathering, new candidates are gathered, then the ICEConnectionState goes to disconnected about 5 seconds later

One red flag I see here is that I don't see ICEConnectionState go to checking after the restart. Any ideas? 

--

---
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/78e16841-21d8-44ce-ae6c-bc5b3e87ec6c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Glenn Nethercutt]

The exact same candidates are being offered by the far end, so they are still valid in that respect. Only ufrag and pwd are being updated in this scenario. Would you expect to see generation incremented even if the same ip/port/proto triples are the same?

[Philipp Hancke]

assuming this is still using jingle semantics (generation indicates an ice restart) yes. Also note how chrome generates candidates with generation 1 and 2 in the dump.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/adc96253-49af-42a9-967a-2f73180a7be8%40googlegroups.com.

[Taylor Brandstetter]

When the first ICE restart occurs, the state doesn't go to "checking" because there's already a working connection. So this doesn't necessarily mean that connectivity checks aren't being sent for the new candidate pairs.

Could you attach a Chrome debug log (preferably in a bug report tagged with WebRTC->Network)? Seeing the STUN packets being sent/received would help get to the bottom of this.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CADxkKiLjsvRpJhPc-URvhyg%3D4fbPy3jPFUOfLkOWT8r7n_ovAg%40mail.gmail.com.

[Xander Dumaine]

Attached is a webrtc internals dump with two peer connections, and two wireshark dumps matching. It looks like the STUN binding requests for the ice candidates generated after the restart are done with the *old* ufrag. If you could help me confirm, I will open a bug. It does look like I get the same behavior in Firefox, but I need to confirm.

[Xander Dumaine]

I've created a chrome bug for this https://bugs.chromium.org/p/webrtc/issues/detail?id=5915