ICE restart for Internet Re-connection / Switching the WIFI Network

[Ajay Choudary]

With recent chrome updates, ice session getting disconnected if there is no data for 30 seconds and ice state is changed to 'failed'.

Previously it used to work even after 10 min's. Still Firefox is behaving the same way.

Chrome is continuously sending STUN binding requests throughout the session, but not in Firefox.
Is STUN refreshes are mandatory ?

Is there any option to increase ICE connection timeout for time being? 

Is ICE Restart API will work in both chrome & Firefox ?

Do we need to re-initialize DTLS session after ICE restart, or it will use the existing key?

How to handle network fluctuations/changes in chrome/firefox/native_clients for the following cases ?

i) Internet is restored in < 1min (from the same router/ip).

ii)Internet is restored in (10-30) min's (from the same router/ip).

iii)Internet is restored from different router/wifi network, here we need to generate new candidates.

Note: In all the above cases remote peer in WebRTC Gateway (Asterisk/Janus).

Thanks,

Ajay

 

[Christoffer Jansson]

Hi,

Before looking into this further, could you list what version it did work in and when it stopped working?

Thanks

/Chris

[Christoffer Jansson]

Also, take a look at the answer to this post, it might shed some light on this.

/Chris

[Christoffer Jansson]

Philipp Hancke pointed out that he filed a bug for this a while back.

[Ajay Choudary]

Hi Chris,

It was worked in chrome-34 to 44, i haven't tested in 45. And observed the issue from chrome-46.

The post & bug are similar to my issue.

How to handle these cases ? 

-Ajay

[Peter Thatcher]

As pointed out, this is the same thing as discussed here: https://groups.google.com/forum/#!topic/discuss-webrtc/CRHffPWGpg4

On Saturday, January 2, 2016 at 1:30:30 AM UTC-8, Ajay Choudary wrote:

With recent chrome updates, ice session getting disconnected if there is no data for 30 seconds and ice state is changed to 'failed'.

Previously it used to work even after 10 min's. Still Firefox is behaving the same way.

The previous "keep sending STUN binding requests for more than 10 minutes even if no responses come back" behavior Chrome had was non-standard behavior caused by a bug in our code.  I'd be very surprised if Firefox also had that behavior. Are you sure it does? 

 

Chrome is continuously sending STUN binding requests throughout the session, but not in Firefox.

Is STUN refreshes are mandatory ?

We plan to reduce the STUN binding request frequency. However,  "constent freshness" requires that STUN binding requests be sent at least every 30 seconds.  See here:

https://tools.ietf.org/html/draft-ietf-rtcweb-stun-consent-freshness-16

 

Is there any option to increase ICE connection timeout for time being? 

Consent freshness requires that once consent is lost (for example, after no STUN binding requests for 30 seconds), an ICE restart be used to restart ICE.  So, we can't make a timeout any longer than 30 seconds.  

Additionally, if the network stack receives no traffic for 30 seconds, how can it differentiate between that and a broken connection?  And if the client is behind a NAT, it's likely that the NAT binding will have been lost after 30 seconds anyway.  

Is ICE Restart API will work in both chrome & Firefox ?

It's part of the spec, and I believe both browsers support it. It's a basic part of ICE.

 

Do we need to re-initialize DTLS session after ICE restart, or it will use the existing key?

No.  DTLS doesn't need to be reinitialized.

 

How to handle network fluctuations/changes in chrome/firefox/native_clients for the following cases ?

i) Internet is restored in < 1min (from the same router/ip).

ii)Internet is restored in (10-30) min's (from the same router/ip).

iii)Internet is restored from different router/wifi network, here we need to generate new candidates.

Currently, all of those require an ICE restart.  Anything over 30 seconds requires an ICE restart, as specified in the standard.  The only time you don't need an ICE restart (currently) is if ICE recovers on its own in under 30 seconds.  But for most realtime applications, as soon as the ICE state goes to "failed", or there's a network change event (for native apps), you'll want to issue an ICE restart immediately.  You probably want to get re-connected as soon as possible. 

 

Note: In all the above cases remote peer in WebRTC Gateway (Asterisk/Janus).

That should make ICE restarts easy and quick.

Thanks,

Ajay

 

[Ajay Choudary]

Hi Peter,

Thanks for the detailed explanation.

Final conclusion is if there is no response/traffic for 30 sec's, ice is getting disconnected.

But this limit is very low it should be 120-300 secs, if we lost the network (my opinion)

But in real time call-center features (conferenceHold/remoteHold/supervising etc), we intentionally put the channel in suspended state i.e no read/write on socket for data(RTP/STUN).

In SIP signalling we use RE-INVITE's to check peer connectivity, if RTP timeout (5 min's) happens.

If there is no response for that re-invite then only we hangup that call. Its good have a peerConnection callback to handle this kind of cases before making it failed.

-Ajay

 

[Peter Thatcher]

On Mon, Jan 4, 2016 at 11:06 AM, Ajay Choudary <aja...@gmail.com> wrote:

Hi Peter,

Thanks for the detailed explanation.

Final conclusion is if there is no response/traffic for 30 sec's, ice is getting disconnected.

​It's always gone to a disconnected after (less than) 30 seconds; that behavior hasn't changed.  It's just a question of whether the client will continue to send STUN binding requests indefinitely or not.  Previously, it was.  Now it's not.​

​

 

But this limit is very low it should be 120-300 secs, if we lost the network (my opinion)

​30 seconds was chosen as part of the "consent freshness" standard at https://tools.ietf.org/html/draft-ietf-rtcweb-stun-consent-freshness-16.  If you'd like to argue for a longer time​ time, the IETF RTCWEB Working Group is the right forum for that discussion.

 

But in real time call-center features (conferenceHold/remoteHold/supervising etc), we intentionally put the channel in suspended state i.e no read/write on socket for data(RTP/STUN).

​I can understand not sending RTP, but why would you stop sending STUN binding responses (if not requests)?  That's the only way the client is going to know there's still connectivity and consent. 

 

In SIP signalling we use RE-INVITE's to check peer connectivity, if RTP timeout (5 min's) happens.

​Doing an ICE restart when the ICE connection state goes to disconnected or failed state is very similar.​

 

If there is no response for that re-invite then only we hangup that call.

​Similarly, if you don't get back to an ICE connected state after an ICE restart, it's probably time to hangup the call.​

 

Its good have a peerConnection callback to handle this kind of cases before making it failed.

What callback are you looking for?  An RTP timeout?

By the way, t

he PeerConnection will typically go to a "disconnected" state before the "failed" state.  ​

​

​So there is a "callbacK" that happens before "failed".​

 

-Ajay

 

--

---
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/jUFmTalowfU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to discuss-webrt...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/a97798b8-a161-4706-bb81-b2b6df2b5660%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.