When to perform ICE restarts?

[Nithyesh Sankar]

I have been learning about WebRTC for sometime now. Recently I came across the concept of ICE restarts. As I understand it, the application can send an updated offer(with iceRestart set to true) to generate new ICE credentials and candidates and establish a new connection. I have couple of questions regarding this.

1) Should the ICE restart be initiated after ICE Disconnected state or ICE Failed state?

2) Should the updated offer be sent only by the peer that performed the initial offer? Or can it be sent by either peer? Also if one peer loses Internet connectivity, do both peers receive the same ICE connection state change notification simultaneously?

Thanks.

[Taylor Brandstetter]

1. Chrome reaches the Failed state after 15 seconds, though according to the standard it should be 30 seconds (after consent expires). Either way, this is too long for a user to wait, so the disconnected state is a better trigger.
2. The updated offer can be sent by either peer. Though of course, you need to avoid the situation where both sides are in the "have-local-offer" state (since "rollback" is not supported). If both peers are Chrome, they should receive the state change notification at roughly the same time, assuming it's a "real" disconnection and not just bad luck.

--

---
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-webrtc+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/f14cb3c6-45c1-49f3-9ca5-0382b44355bb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Nils Ohlmeier]

On May 10, 2017, at 00:34, Nithyesh Sankar <klas...@gmail.com> wrote:

I have been learning about WebRTC for sometime now. Recently I came across the concept of ICE restarts. As I understand it, the application can send an updated offer(with iceRestart set to true) to generate new ICE credentials and candidates and establish a new connection. I have couple of questions regarding this.

1) Should the ICE restart be initiated after ICE Disconnected state or ICE Failed state?

Firefox switches to Failed only after 30 seconds. But Disconnected is a very volatile state, as it mean a single UDP got dropped. See https://blog.mozilla.org/webrtc/ice-disconnected-not/ for more details.

I would recommend to come with other criteria additionally to the Disconnected state, which influence to decide when to trigger an ICE restart.

2) Should the updated offer be sent only by the peer that performed the initial offer? Or can it be sent by either peer? Also if one peer loses Internet connectivity, do both peers receive the same ICE connection state change notification simultaneously?

Either side can request an ICE restart. And Firefox supports rollbacks. So you should be able to handle scenarios where both sides initiated an ICE restart at the same time, by rolling back one side.

Best

  Nils Ohlmeier

[Nithyesh Sankar]

Taylor and Nils,
 
Thank you for your inputs. 
Since I am just experimenting, I performed ICE restarts on the failed state on the peer that initiated the connection the first time. I ran this test several times to check the connection recovery behavior and it worked properly most of the times. There was this one instance where the flow was as follows
 
Peer A                                Peer B
ICE CONNECTION FAILED             
SENT ICE RESTART OFFER(1)
ICE CONNECTION CONNECTED         
ICE CONNECTION FAILED                 RECEIVED OFFER(1)
SENT ICE RESTART OFFER(2)             SEND ANSWER(1)
RECEIVED ANSWER(1)                    RECEIVED OFFER(2)
SIGNALLING STATE-STABLE
RECEIVED ANSWER(2) <---- At this point, I got an error about being in an invalid state.
 
I do'nt remember the exact flow on Peer B. Unfortunately I didn't save the logs for this case and have been trying to recreate it.
Is this the scenario where I would try to do an ICE rollback and set the remote description? Also could you please point me towards some reference about ICE rollbacks or sample code?

[Nils Ohlmeier]

On May 17, 2017, at 06:55, Nithyesh Sankar <klas...@gmail.com> wrote:

Since I am just experimenting, I performed ICE restarts on the failed state on the peer that initiated the connection the first time. I ran this test several times to check the connection recovery behavior and it worked properly most of the times. There was this one instance where the flow was as follows
 
Peer A                                Peer B
ICE CONNECTION FAILED             
SENT ICE RESTART OFFER(1)
ICE CONNECTION CONNECTED         
ICE CONNECTION FAILED                 RECEIVED OFFER(1)
SENT ICE RESTART OFFER(2)             SEND ANSWER(1)
RECEIVED ANSWER(1)                    RECEIVED OFFER(2)
SIGNALLING STATE-STABLE
RECEIVED ANSWER(2) <---- At this point, I got an error about being in an invalid state.

Well you are simply not allowed to set an Answer in the stable state, as the stable state means there is no pending offer.

The reason is that probably the Answer 1 got applied to Offer 2, as offer and answers don’t contain any indicators which answer belongs to which offer.

 

I do'nt remember the exact flow on Peer B. Unfortunately I didn't save the logs for this case and have been trying to recreate it.
Is this the scenario where I would try to do an ICE rollback and set the remote description? Also could you please point me towards some reference about ICE rollbacks or sample code?

No. A rollback would typically be used in case A and B both switch to Failed and therefore both generate new ICE restart offers. Then the offers cross on the wire. And when one of the peers receive the others side offer it realizes that now two offers are in flight. So now it can roll back it’s own offer and instead set the remote offer.

Best

  Nils Ohlmeier

[Nithyesh Sankar]

On Thursday, 18 May 2017 12:13:25 UTC+5:30, Nils Ohlmeier wrote:

I do'nt remember the exact flow on Peer B. Unfortunately I didn't save the logs for this case and have been trying to recreate it.
Is this the scenario where I would try to do an ICE rollback and set the remote description? Also could you please point me towards some reference about ICE rollbacks or sample code?

No. A rollback would typically be used in case A and B both switch to Failed and therefore both generate new ICE restart offers. Then the offers cross on the wire. And when one of the peers receive the others side offer it realizes that now two offers are in flight. So now it can roll back it’s own offer and instead set the remote offer.

So roll back is performed automatically by the PeerConnection? Or do we have to enable it using some config value?

[Nils Ohlmeier]

You will have to call setLocalDescription or setRemoteDescription with a type of ‘rollback’ and an empty SDP.

https://developer.mozilla.org/en-US/docs/Web/API/RTCSessionDescription

Best

  Nils Ohlmeier

[Nithyesh Sankar]

Thank you.