Re: [rtcweb] Future requirement: RTC-Web apps must work through interface switching

[<[e-mail]>]

Hi Harald,

I have a few additional questions to make sure this can work.

>Section 9 of RFC 5245 is the procedure for adding more candidates during the
>call.
>It supports make-before-break:
>
>9.1.1.1.  ICE Restarts
>
>    An agent MAY restart ICE processing for an existing media stream.  An
>    ICE restart, as the name implies, will cause all previous states of
>    ICE processing to be flushed and checks to start anew.  The only
>    difference between an ICE restart and a brand new media session is
>    that, during the restart, media can continue to be sent to the
>    previously validated pair.
>

This seems to be the right mechanism. But this has to be triggered at any time when a new interface becomes available. For instance, when the device enters Wi-Fi coverage and is able to connect to the Wi-Fi network. The browser itself can clearly learn about this through some OS/platform specific APIs. So, if it is the browser who is responsible for sending the new offer, it can do it. If it is the JS application, it would need some event that it knows it should do so. 

Is it then so that the STUN connectivity checks are run for the new candidates as soon as they are added? And if we want to be able to use the new candidates immediately after the old IP/interface has become disconnected, both ends will have to keep the NAT/FW state alive for these candidates as long as they are in the latest offer?

Finally, how does the other peer (who's own connectivity has not changed) know when to start using a new candidate pair? Is it after it starts receiving packets from the other end over that candiate pair? Or is it based on some ICMP error? 

Since media is potentially end-to-end even between service providers, we will have to be careful that things work between two pairs. Including pairs that are e.g. SBC's implementing ICE.

Markus