Re: [rtcweb] Future requirement: RTC-Web apps must work through interface switching
Stefan Håkansson <stefan.lk.hakansson@ericsson.com> Thu, 06 October 2011 13:45 UTC
Return-Path: <stefan.lk.hakansson@ericsson.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BD8221F8B4A for <rtcweb@ietfa.amsl.com>; Thu, 6 Oct 2011 06:45:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.327
X-Spam-Level:
X-Spam-Status: No, score=-6.327 tagged_above=-999 required=5 tests=[AWL=-0.028, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0GXqzxHxRBdl for <rtcweb@ietfa.amsl.com>; Thu, 6 Oct 2011 06:45:28 -0700 (PDT)
Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id BAFCC21F8B3E for <rtcweb@ietf.org>; Thu, 6 Oct 2011 06:45:27 -0700 (PDT)
X-AuditID: c1b4fb39-b7bfdae000005125-ba-4e8db1b5824a
Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 28.77.20773.5B1BD8E4; Thu, 6 Oct 2011 15:48:37 +0200 (CEST)
Received: from [127.0.0.1] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.137.0; Thu, 6 Oct 2011 15:48:22 +0200
Message-ID: <4E8DB1A5.1000800@ericsson.com>
Date: Thu, 06 Oct 2011 15:48:21 +0200
From: Stefan Håkansson <stefan.lk.hakansson@ericsson.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.23) Gecko/20110922 Lightning/1.0b2 Thunderbird/3.1.15
MIME-Version: 1.0
To: "Markus.Isomaki@nokia.com" <Markus.Isomaki@nokia.com>
References: <E44893DD4E290745BB608EB23FDDB7620D3782@008-AM1MPN1-043.mgdnok.nokia.com> <4E89AD52.5000402@ericsson.com> <E44893DD4E290745BB608EB23FDDB7620D5D62@008-AM1MPN1-043.mgdnok.nokia.com>
In-Reply-To: <E44893DD4E290745BB608EB23FDDB7620D5D62@008-AM1MPN1-043.mgdnok.nokia.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: AAAAAA==
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Future requirement: RTC-Web apps must work through interface switching
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Oct 2011 13:45:29 -0000
On 10/06/2011 03:04 PM, Markus.Isomaki@nokia.com wrote: > 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. I agree. For the time being, the requirement is on a higher level - and quite badly phrased (I'm to blame): "It MUST be possible to move from one network interface to another one" I think it can be better put, and later when the model is decided it can be broken down (e.g to an event in the API). Stefan > > Markus > > >> On 10/03/2011 01:58 PM, Markus.Isomaki@nokia.com 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 rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >> >> >> _______________________________________________ rtcweb mailing >> list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
- Re: [rtcweb] Future requirement: RTC-Web apps mus… Iñaki Baz Castillo
- Re: [rtcweb] Future requirement: RTC-Web apps mus… Olle E. Johansson
- [rtcweb] Future requirement: RTC-Web apps must wo… Markus.Isomaki
- Re: [rtcweb] Future requirement: RTC-Web apps mus… Olle E. Johansson
- Re: [rtcweb] Future requirement: RTC-Web apps mus… Iñaki Baz Castillo
- Re: [rtcweb] Future requirement: RTC-Web apps mus… Iñaki Baz Castillo
- Re: [rtcweb] Future requirement: RTC-Web apps mus… Stefan Håkansson
- Re: [rtcweb] Future requirement: RTC-Web apps mus… Randell Jesup
- Re: [rtcweb] Future requirement: RTC-Web apps mus… Harald Alvestrand
- Re: [rtcweb] Future requirement: RTC-Web apps mus… Markus.Isomaki
- Re: [rtcweb] Future requirement: RTC-Web apps mus… Harald Alvestrand
- Re: [rtcweb] Future requirement: RTC-Web apps mus… Markus.Isomaki
- Re: [rtcweb] Future requirement: RTC-Web apps mus… Markus.Isomaki
- Re: [rtcweb] Future requirement: RTC-Web apps mus… Magnus Westerlund
- Re: [rtcweb] Future requirement: RTC-Web apps mus… Markus.Isomaki
- Re: [rtcweb] Future requirement: RTC-Web apps mus… Markus.Isomaki
- Re: [rtcweb] Future requirement: RTC-Web apps mus… Stefan Håkansson
- Re: [rtcweb] Future requirement: RTC-Web apps mus… DRAGE, Keith (Keith)