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

[<[e-mail]>]

Hi Stefan,

Stefan Håkansson wrote:
>
>in terms of use case and reqs, do you see anything missing if you look at
><http://datatracker.ietf.org/doc/draft-ietf-rtcweb-use-cases-and-
>requirements/>,
>section 4.2.3?
>
>In terms of technology I thought ICE would be able to handle this.
>

I agree ICE has the mechanisms to handle it to some extent, as new candidates can be added on-the-fly, e.g. when a device gets a new IP address via a newly connected interface. I guess the minimum requirement is that the entity generationg the ICE signaling messages needs to be able to learn about the existence of the new candidates immediately, so it can generate the new ICE "offer". I'm not sure where this is supposed to happen, but if it is the JS app that sends the "offers", there is a requirement that there needs to be an event in the API indicating that the set of local candidates has changed.

Markus 


>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