Need a suggestion on how to handle network change

[Hemrajsinh Gharia]

Hi Guys,

We have a WebRTC audio commentary app where listeners stay connected for a longer period of time. On the call initialization, ICE candidates are exchanged and connectivity gets established and streaming works perfectly fine. But let's say, after an hour or two, if there is any change in the network, then there the streaming is not working. For e.g., I am connected to wifi and listening but in between disconnect from wifi and connect to mobile tethering. In that case, my status is connected but I am not receiving any audio. Probably connectivity established through wifi related ICE is no more valid.

So how to handle such scenarios smartly to make sure streaming works uninterrupted throughout the day?

Thanks,

Hemraj  

[Hemrajsinh Gharia]

To me, it looks like the one way (which seems the only way to me) is to put a network disconnection checker and on disconnection and reconnection, re-initiate the peer connection and share ICE candidate again.

Please suggest if there is a better way or event in the WebRTC engine.

Thanks

[Taylor Brandstetter]

This can be addressed by setting continual_gathering_policy to GATHER_CONTINUALLY. With this mode, ICE gathering never technically ends, so peers can produce new ICE candidates without doing another round of negotiation.

The caveat is that you should also signal candidate removals, to tell the other side that network interfaces are going away. Otherwise you'll end up with an ever growing list of candidates as time goes on.

You can also watch the ICE state and perform an "ICE restart", which would be the traditional/standardized method. Though this will be less responsive, and requires another round of offer/answer.

--

---
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/681b2917-33c1-4c2d-a747-735cc044df01o%40googlegroups.com.

[Dubois, Sean]

This will only work between two Google WebRTC implementations unfortunately

 

I really would love to see ICE Renominations be standardized. I see so many devs that don’t handle ICE disconnecting/failing, would be great to make things a little less sharp for them 😊

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CAK35n0aZHmF-NXbdwwquZB_Ey6t9BrWWYVfTm1%2BH7vdZFUuYeA%40mail.gmail.com.

[Hemrajsinh Gharia]

Thanks Taylor for the suggestion. 

Dubios, could not understand the GoogleebRTC part, "This will only work between two Google WebRTC implementations unfortunately". Could you elaborate more on this?

Thanks

On Friday, 17 July 2020 05:59:51 UTC+5:30, Dubois, Sean wrote:

This will only work between two Google WebRTC implementations unfortunately

 

I really would love to see ICE Renominations be standardized. I see so many devs that don’t handle ICE disconnecting/failing, would be great to make things a little less sharp for them 😊

 

From: 'Taylor Brandstetter' via discuss-webrtc <discuss...@googlegroups.com>
Reply-To: <discuss...@googlegroups.com>
Date: Thursday, July 16, 2020 at 15:48
To: discuss-webrtc <discuss...@googlegroups.com>
Subject: Re: [discuss-webrtc] Re: Need a suggestion on how to handle network change

 

This can be addressed by setting continual_gathering_policy to GATHER_CONTINUALLY. With this mode, ICE gathering never technically ends, so peers can produce new ICE candidates without doing another round of negotiation.

 

The caveat is that you should also signal candidate removals, to tell the other side that network interfaces are going away. Otherwise you'll end up with an ever growing list of candidates as time goes on.

 

You can also watch the ICE state and perform an "ICE restart", which would be the traditional/standardized method. Though this will be less responsive, and requires another round of offer/answer.

 

On Thu, Jul 16, 2020 at 8:32 AM Hemrajsinh Gharia <gharia...@gmail.com> wrote:

To me, it looks like the one way (which seems the only way to me) is to put a network disconnection checker and on disconnection and reconnection, re-initiate the peer connection and share ICE candidate again.

 

Please suggest if there is a better way or event in the WebRTC engine.

 

Thanks

On Thursday, 16 July 2020 18:39:31 UTC+5:30, Hemrajsinh Gharia wrote:

Hi Guys,

 

We have a WebRTC audio commentary app where listeners stay connected for a longer period of time. On the call initialization, ICE candidates are exchanged and connectivity gets established and streaming works perfectly fine. But let's say, after an hour or two, if there is any change in the network, then there the streaming is not working. For e.g., I am connected to wifi and listening but in between disconnect from wifi and connect to mobile tethering. In that case, my status is connected but I am not receiving any audio. Probably connectivity established through wifi related ICE is no more valid.

 

So how to handle such scenarios smartly to make sure streaming works uninterrupted throughout the day?

 

Thanks,

Hemraj  

--

---
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...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/681b2917-33c1-4c2d-a747-735cc044df01o%40googlegroups.com.

--

---
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...@googlegroups.com.

[Dubois, Sean]

Changing the selected candidate pair isn’t valid IETF ICE behavior, it was submitted but never standardized https://tools.ietf.org/html/draft-thatcher-ice-renomination-00

 

AFAIK only one WebRTC implementation implements it. In libnice it is behind a flag, but Janus/GStreamer (two big users I know of) don’t have it enabled.

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/0fa28e5e-ab25-486e-b678-625168473722o%40googlegroups.com.

[Lorenzo Miniero]

Il giorno venerdì 17 luglio 2020 04:55:07 UTC+2, Dubois, Sean ha scritto:

Changing the selected candidate pair isn’t valid IETF ICE behavior, it was submitted but never standardized https://tools.ietf.org/html/draft-thatcher-ice-renomination-00

 

AFAIK only one WebRTC implementation implements it. In libnice it is behind a flag, but Janus/GStreamer (two big users I know of) don’t have it enabled.

I wasn't aware libnice supported it. Seems quite easy to enable, so I'll add a flag for it.

Lorenzo 

[Hemrajsinh Gharia]

Thanks Lorenzo. So we send the completed signal in the case of Janus when ICE gathering is done. I assume there will be another signal if you enable that flag in libnice, a signal to indicate discard old candidates and get ready to receive new ones

[Sean DuBois]

This makes my day, thanks for the positive/quick response Lorenzo :D
Janus just keeps getting better and better...

I haven't found any of the IETF/W3C conversations around this, so no
idea what could be the downsides. If everyone agrees this is 'good' I am
happy to go do the work on other community owned Open Source projects as
well!

> --
>
> ---
> 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/f202c404-8edb-4086-b784-3508250010eeo%40googlegroups.com.

[Lorenzo Miniero]

Looks like there's no way to enable that feature in Chrome, though? At the moment, apparently this only works if you build your own libwebrtc version with that variable value changed, so not sure it's usable.

Lorenzo

> To unsubscribe from this group and stop receiving emails from it, send an email to discuss...@googlegroups.com.

[Taylor Brandstetter]

That's correct, chromium doesn't allow access to any of the unstandardized ICE extensions (unless you count signaling "network-id" and "network-cost" with ICE candidates). Sorry for not clarifying that earlier.

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/d8f58274-0963-4c8d-ac85-b52a123948eco%40googlegroups.com.

[Hemrajsinh Gharia]

Okay. So coming back to the original query, until we have some standard and browser support in place, what is the best practice to handle network change from browser/js side?

Thanks

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/d8f58274-0963-4c8d-ac85-b52a123948eco%40googlegroups.com.

[Philipp Hancke]

The standard actually gives an answer to that: https://w3c.github.io/webrtc-pc/#dom-rtcofferoptions-icerestart

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/90ac2257-3cd9-4834-bff1-a9380b82b008o%40googlegroups.com.