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

<> Tue, 04 October 2011 10:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2FDD521F8C72 for <>; Tue, 4 Oct 2011 03:08:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.724
X-Spam-Status: No, score=-2.724 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id q6aJwrRz3wj2 for <>; Tue, 4 Oct 2011 03:08:22 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 6004C21F8C4E for <>; Tue, 4 Oct 2011 03:08:21 -0700 (PDT)
Received: from ( []) by (Switch-3.4.4/Switch-3.4.3) with ESMTP id p94AB5OD024600; Tue, 4 Oct 2011 13:11:24 +0300
Received: from ([]) by over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 4 Oct 2011 13:11:01 +0300
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Tue, 4 Oct 2011 12:11:00 +0200
Received: from ([]) by ([]) with mapi id 14.01.0339.002; Tue, 4 Oct 2011 12:11:00 +0200
Thread-Topic: [rtcweb] Future requirement: RTC-Web apps must work through interface switching
Thread-Index: AcyBw8LOCbj0Q27JT3eGKgpYq050bwAAKV6AAAUGtUD//+VQgP/+nwAg
Date: Tue, 04 Oct 2011 10:10:59 +0000
Message-ID: <>
References: <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 04 Oct 2011 10:11:01.0459 (UTC) FILETIME=[EB267230:01CC827D]
X-Nokia-AV: Clean
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: Tue, 04 Oct 2011 10:08:23 -0000

Hi Harald,

I have a few additional questions to make sure this can work.

>Section 9 of RFC 5245 is the procedure for adding more candidates during the
>It supports make-before-break:
>  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 seems to be the right mechanism. But this has to be triggered at any time when a new interface becomes available. For instance, when the device enters Wi-Fi coverage and is able to connect to the Wi-Fi network. The browser itself can clearly learn about this through some OS/platform specific APIs. So, if it is the browser who is responsible for sending the new offer, it can do it. If it is the JS application, it would need some event that it knows it should do so. 

Is it then so that the STUN connectivity checks are run for the new candidates as soon as they are added? And if we want to be able to use the new candidates immediately after the old IP/interface has become disconnected, both ends will have to keep the NAT/FW state alive for these candidates as long as they are in the latest offer?

Finally, how does the other peer (who's own connectivity has not changed) know when to start using a new candidate pair? Is it after it starts receiving packets from the other end over that candiate pair? Or is it based on some ICMP error? 

Since media is potentially end-to-end even between service providers, we will have to be careful that things work between two pairs. Including pairs that are e.g. SBC's implementing ICE.