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

[Harald Alvestrand <[e-mail]>]

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 the
>   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
>