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

Magnus Westerlund <> Wed, 05 October 2011 12:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4893221F8CC0 for <>; Wed, 5 Oct 2011 05:06:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -106.484
X-Spam-Status: No, score=-106.484 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id UuNy1VYGoaIX for <>; Wed, 5 Oct 2011 05:06:49 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 1CEA921F8CBF for <>; Wed, 5 Oct 2011 05:06:48 -0700 (PDT)
X-AuditID: c1b4fb3d-b7b1aae000001146-ce-4e8c652d76ba
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 31.46.04422.D256C8E4; Wed, 5 Oct 2011 16:09:52 +0200 (CEST)
Received: from [] ( by ( with Microsoft SMTP Server id; Wed, 5 Oct 2011 14:09:25 +0200
Message-ID: <>
Date: Wed, 05 Oct 2011 14:09:22 +0200
From: Magnus Westerlund <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.3.2
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: AAAAAA==
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: Wed, 05 Oct 2011 12:06:50 -0000

(as individual)

I would like to comment on two things around this with ICE restarts and
what I believe Google Voice Talk does and its relation to the ICE spec.

First of all I understand this being based on that the candidates are
kept alive after the initial nomination so they are always ready. This
is clearly allowed, but will definitely fail if the other part doesn't
keep its ICE candidates alive, and do note that these might include TURN
relay candidates also. Thus this practice is not without some resource
consumption, even if it is only a STUN request every 15 seconds.

Secondly, I understand that the alternative candidates are used without
signaling to the other peer that the ICE connectivity checks and later
nomination happens. This will not work for candidate pairs where the
peer not having interface change happen to it is behind a middlebox with
a address dependent filtering rule, i.e. practically all, unless the
candidate pair hasn't be initially verified to work and kept alive
without nomination due to lower priority for the whole call. Otherwise,
this only works when both sides tries to use their candidates due to ICE
restart signaling message or that the other peer also suspects path
breakage and initiates an ICE restart implicitly based on lack of
feedback and media traffic from peer.

When it comes to handling interface changes in general. I do believe
that we will need to support a signaled ICE restart. If not, the webapp
can anyway emulate this at a higher resource consumption and likely
longer media disruption by opening new peer connections.



On 2011-10-03 16:51, Harald Alvestrand wrote:
> On 10/03/2011 04:40 PM, wrote:
>> Hi Harald,
>> Well, things may already be better than what I expected :)
>>> The control channel needs to be reconnected too, of course, but
>>> we're not so much in a hurry over that one.
>> So you're not signaling anything at the point of the switch, but
>> you have set two alternatives beforehand? In the mobile use case,
>> the available interfaces come and go, so we can't offer all
>> alternate candidates upfront. However, if we can keep the "old"
>> interface up for a while after the "new" one appears, we can add
>> the new candidate at that point.
> Section 9 of RFC 5245 is the procedure for adding more candidates
> during the call. 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 would be the so called make-before-break switch. The worst
>> case is that we loose the old interface at the same time as new one
>> comes available, so the new alternative can only be sent over the
>> new interface AFTER the signaling has been reconnected. This would
>> be break-before-make. If the underlying OS can handle multi-homing,
>> we should in most cases only need the make-before-break type of
>> switching. However, as we know, a device can run out of Wi-Fi
>> coverate quite abruptly and it is not always clear that the
>> cellular connectivity is fully up at that point.
>> I don't know all nuances of ICE by heart, but is it so that the
>> alternate candidates can be added in an offer at any point? In that
>> case we should be able to cover most cases quite well.
>> Markus
>>> -----Original Message----- From:
>>> [] On Behalf Of ext Harald
>>> Alvestrand Sent: 03 October, 2011 17:03 To: 
>>> Subject: Re: [rtcweb] Future requirement: RTC-Web apps must work
>>> through interface switching
>>> 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.


Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVM
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: