IceConnectionState failed. How can I restart the IceConnectionProcess?

[giuseppe pes]

Hi guys, 

I am encountering a really annoying issue. When I connect to a peer over Internet using only a STUN server, sometime, the IceConnectionState of one peer is Failed, whereas the status of the IceConnectionState of the other peer remains in checking. As a result the connection between the peers is not started. If the peer with the status failed reloads the page,  the connection restarts successfully.  I guess, the problem is not the absence of  a TURN server, as most of the time it works. 

Tested using Chrome in both peers ( v 33 ) .

- First question. How can I restart the IceConnection? This may be a good work around for this problem. 

- Is it a problem if a set the ICECandidates before receiving an answer or an offer? This may occur during renegoziation.

[Benjamin Schwartz]

Yes, currently Chromium only reports IceConnectionState as Failed on the Offerer side.  (This is still an unresolved issue in the specification at the W3C.)

You can restart the ice connection by creating a new offer with peerConnection.createOffer(successCallback, failureCallback, {mandatory: {IceRestart: true}}), and configuring your successCallback to do a complete negotiation (setLocalDescription, send offer over the signaling channel, etc.).

I'm not sure about all possible orderings of addCandidate and set*Description, but it should be OK to call addCandidate before or after setRemoteDescription, and if you're calling it at the wrong time, you should get an error or failure callback in javascript.

--

---
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.
For more options, visit https://groups.google.com/d/optout.

[giuseppe pes]

Thanks a lot for your quick reply. 

I'm not sure about all possible orderings of addCandidate and set*Description, but it should be OK to call addCandidate before or after setRemoteDescription, and if you're calling it at the wrong time, you should get an error or failure callback in javascript.

Yes, I am randomly getting errors when I am setting either the local descriptor of the remote descriptor during session renegotiation. 

Precisely, I am seeing the following errors : 

Peer that made a offer        : Failed to push down transport description. Failed to set local identity.  

Peer that received the offer : Failed to update Session State : ERROR_CONTENT. 

It appears that I am not the only one seeing this issue : 

- https://github.com/rtc-io/rtc/issues/13

- https://github.com/rtc-io/rtc-quickconnect/issues/6

and it seems that ordering the messages ( i.e. Offer/Answer before ICE candidates ) solves the problem. Any thoughts?  

   

--

---
You received this message because you are subscribed to a topic in the Google Groups "discuss-webrtc" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/discuss-webrtc/2swo-3nXhPE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to discuss-webrt...@googlegroups.com.

[Benjamin Schwartz]

It sounds like you've solved the problem!