When is ICE restart needed on iOS/Android?

[Giovanni Beri]

Hi,

I am using WebRTC M88 for iOS and Android, and I am considering implementing ICE restart.

In what situation ICE restart is applicable/needed on mobile platforms?

E.g. on iOS I could not find any condition where ICE restart is needed in order to reconnect, even such scenarios:

• A on wifi only
• A calls B
• A disconnects wifi, ICEConnectionState goes Connected->Disconnected->Failed
• A enables 4G, and media streams are re-established without the need of ICE restart

As far as I understand, ICEConnectionState == Failed means that the underlying transport is in failed state, which should be a terminal state unless ICE restart kicks in (https://w3c.github.io/webrtc-pc/#dom-rtcicetransportstate-failed). Why is WebRTC able to reconnect in this scenario? (FYI we use ICE trickling).

Note that the same scenario fails to reconnect on Android (and ICE restart would be the way to solve this case I guess).

Regards,

Giovanni

[Jonas Oreland]

Hi,

1) First is this for a p2p application or a client server application ?

2) There are more scenarios for p2p requiring ICE restart.

Example of scenarios what would need ICE restart

1. A has cell and wifi
2. A connect using wifi
3. A prunes cell connection (_can_ happen e.g due timeouts)
4. A loses wifi

Continuous gathering decreases need for ice restart, but does not eliminate it

Look at ICE restart as a catch all if everything else fails.

3) Why is WebRTC able to reconnect in this scenario? (FYI we use ICE trickling).

Looking at documentation (that you gracefully links), that sounds like a bug to me... 

- If you added an empty remote candidate, it shouldn't have entered the state failed...

- If you did not add one, it should (if i read correctly) have entered disconnected instead.

but i'm not 100% sure about that :(

/Jonas

[Giovanni Beri]

Hi Jonas, 

sorry for my late reply, I've been quite busy.

Thank you for your answer! I'll reply point by point.

1) This is for p2p application, a VoIP calling SDK

2) This is interesting, I noticed that "Ice gathering state" stays "gathering" all the time (it seems it never transitions to "complete", and this came as a surprise to me), but I never heard about "continuous gathering". I guess "continuous gathering" is the reason why ICE Restart is needed so rarely, like you said.

Can you by chance provide any documentation about continuous gathering (I googled around with no luck, I only found this message where "continuous gathering" is described as "unofficial" https://lists.w3.org/Archives/Public/public-webrtc/2018May/0079.html , but this is not an official source :) ).

3) No I did NOT add an empty remote candidate (is it supposed to work e.g. on iOS? None of my attempts seemed to achieve "end of candidates" effects, but maybe I just have to try harder). In the example I reported in my first message, ICEConnectionState first goes to "Disconnected", and finally to "Failed" after a few seconds, and according to the docs this seems expected (I may be wrong here).

My main question here is around "ICEConnectionState == Failed" being a recoverable state without ICE Restart, or not. Maybe is "continuous gathering" taking effect here as well?

Thanks a lot for you time,

/Giovanni