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

[Harald Alvestrand <[e-mail]>]

On 10/03/2011 04:40 PM, [e-mail] wrote:
> Hi Harald,
>
> Well, things may already be better than what I expected :)
>
>> The control channel needs to be reconnected too, of course, but we're not so
>> much in a hurry over that one.
> So you're not signaling anything at the point of the switch, but you have set two alternatives beforehand? In the mobile use case, the available interfaces come and go, so we can't offer all alternate candidates upfront. However, if we can keep the "old" interface up for a while after the "new" one appears, we can add the new candidate at that point.
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 would be the so called make-before-break switch. The worst case is that we loose the old interface at the same time as new one comes available, so the new alternative can only be sent over the new interface AFTER the signaling has been reconnected. This would be break-before-make. If the underlying OS can handle multi-homing, we should in most cases only need the make-before-break type of switching. However, as we know, a device can run out of Wi-Fi coverate quite abruptly and it is not always clear that the cellular connectivity is fully up at that point.
>
> I don't know all nuances of ICE by heart, but is it so that the alternate candidates can be added in an offer at any point? In that case we should be able to cover most cases quite well.
>
> Markus
>
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On Behalf
>> Of ext Harald Alvestrand
>> Sent: 03 October, 2011 17:03
>> To: [e-mail]
>> Subject: Re: [rtcweb] Future requirement: RTC-Web apps must work through
>> interface switching
>>
>> The media channels in Google's ICE-based offerings (Google Talk Video,
>> Google Voice and Hangouts) all are able to survive an interface change by
>> utilizing the alternate candidate mechanisms in ICE.
>>
>> Try this experiment:
>> - Make sure your laptop has a working wireless connection
>> - Connect your laptop to wired Ethernet
>> - Set up a Google Talk Video call with someone
>> - Yank out the Ethernet cord
>>
>> If all goes well, you should see exactly how much of a break this causes to the
>> call in practice.
>> (If the call disconnects, please file a bug - I'm sure there are cases we don't
>> handle well.)
>>
>> The control channel needs to be reconnected too, of course, but we're not so
>> much in a hurry over that one.
>>
>>                     Harald
>>
>>
>> On 10/03/2011 01:58 PM, [e-mail] wrote:
>>> Hi all,
>>>
>>> There is one important requirement, which may not be critical today, but will
>> most likely be in the future.
>>> We can assume RTC-Web to be supported in devices like tablets, pads or
>> smartphones, that people carry around. We can also assume that when such
>> devices are carried around, their point of attachement to the Internet will
>> change, even so that the type of access network will change, typically
>> between something like HSPA/LTE and Wi-Fi. Today this will always mean a
>> change of IP address as well. In the future we may have technologies such as
>> (Proxy)Mobile IP in use that will provide IP address preservation, but we can't
>> really count on that.
>>> How does this relate to RTC-Web? Interface switching usually happens
>>> at the discretion of the OS or some kind of connection manager. The
>>> browser or the web application environment has no control over it. At
>>> best it, or the JS application running within, can get some kind of
>>> signal of such event happening. For TCP-based client-server things
>>> (HTTP, Websocket) it is possible to react to this by re-establishing
>>> the lost TCP connections and state on top of them. This is indeed what
>>> many (native) apps are able to do today. There can be some smarter
>>> ways in the pipeline as well, such as multipath TCP, which would make
>>> the process of "transitioning" a TCP connection from one interface/IP
>>> to another potentially transparent to the application. But with
>>> peer-to-peer and interactive real-time, things get more complicated.
>>> It may of course be that the switching happens due to a sudden loss of
>>> coverage and is so slow, that voice or video calls are broken anyway.
>>> However, in many cases th
>> e
>>>    old interface can be up while the new one is being established, and in
>> principle the total loss of connectivity can be avoided. In such scenarios it
>> would be realistically possible to update the ongoing real-time sessions to a
>> new IP address and port, if there were some kind of end-to-end or server-
>> assisted mechanism for it. Even a cut of 1-2 seconds would not be as bad as a
>> total loss of the session.
>>> What does this mean in terms of requirements?
>>> - The first-order requirement is that the browser and/or the JS app,
>> whoever needs to act, has to be able to get events of interface switching in
>> the same way as native apps can. If it were only the browser who was
>> required to get them, we could set standards aside, and declare that the
>> browser does this as any other app. But if it is the JS app that needs to do
>> something, then we may need something new as a JS API. I have no clue at
>> the moment if the JS apps can learn about this kind of events. And this is
>> clearly not a RTC-Web specific requirement, but a generic one. I do know that
>> browsers or HTTP libraries can re-send requests etc. based on IP address
>> change, but I don't know what a JS Websocket client can do, if anything.
>>> - The second requirement is that the media related APIs and transport
>> protocols (RTP) have to be flexible enough, that they can at least be extended
>> to work so that they do not assume that the session is forever bound to a
>> certain IP address/port in either end. How this affects the system depends on
>> what is actually standardized, for instance if the SDP offer/answer model is
>> included or not. But on the generic level it could be something like this:
>>> 	- If the browser/JS app receives signaling/offer from its peer that
>> peer's RTP/UDP IP address/port has changed, it has to be able to set these
>> through the media API and re-run STUN checks or whatever is required at that
>> point. This has to be work so that the media session can be otherwise
>> continued, after the process is completed.
>>> 	- If the browser/JS app receives an event that its own IP address/port
>> has changed (or is about to change), it has to be able to re-initialize the
>> RTP/UDP accordingly, re-establish its "signaling connection and state" with its
>> webserver, notify the peer about the change, and re-run STUN checks etc. as
>> needed.
>>> This sounds quite complicated so it may be that we don't want to add this as
>> a Day 1 requirement for RTC-Web. But I believe we should try to design the
>> APIs and protocols in such a way that this kind of thing can be added later on.
>> There could be other ways too, like MPRTP
>> (http://datatracker.ietf.org/doc/draft-singh-avtcore-mprtp/), we could look
>> at.
>>> I suppose the less we standardize about the signaling and offer/answer, the
>> easier it might be to support these kinds of things as add-on. But whatever we
>> standardize, please keep the interface and IP address change in mind. The
>> outcome could be that we declare that transport (MPTCP, MPRTP) has to deal
>> with it, but eventually I think this will have to work one way or the other.
>>> Regards,
>>> 	Markus
>>> _______________________________________________
>>> rtcweb mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>>
>>
>> _______________________________________________
>> rtcweb mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/rtcweb