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

Stefan Håkansson <> Thu, 06 October 2011 13:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0BD8221F8B4A for <>; Thu, 6 Oct 2011 06:45:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.327
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0GXqzxHxRBdl for <>; Thu, 6 Oct 2011 06:45:28 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id BAFCC21F8B3E for <>; Thu, 6 Oct 2011 06:45:27 -0700 (PDT)
X-AuditID: c1b4fb39-b7bfdae000005125-ba-4e8db1b5824a
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 28.77.20773.5B1BD8E4; Thu, 6 Oct 2011 15:48:37 +0200 (CEST)
Received: from [] ( by ( with Microsoft SMTP Server id; Thu, 6 Oct 2011 15:48:22 +0200
Message-ID: <>
Date: Thu, 06 Oct 2011 15:48:21 +0200
From: Stefan Håkansson <>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20110922 Lightning/1.0b2 Thunderbird/3.1.15
MIME-Version: 1.0
To: "" <>
References: <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: AAAAAA==
Cc: "" <>
Subject: Re: [rtcweb] Future requirement: RTC-Web apps must work through interface switching
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 06 Oct 2011 13:45:29 -0000

On 10/06/2011 03:04 PM, wrote:
> Hi Stefan,
> Stefan Håkansson wrote:
>> in terms of use case and reqs, do you see anything missing if you
>> look at
>> <
>> 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).


> Markus
>> On 10/03/2011 01:58 PM, 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
>> (, 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 mailing
>> list