Re: [rtcweb] ICE for dual stacks (new topic)

"Olle E. Johansson" <> Wed, 28 September 2011 19:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DACDF1F0CC2 for <>; Wed, 28 Sep 2011 12:14:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.233
X-Spam-Status: No, score=-2.233 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id eAeoIpr51gVP for <>; Wed, 28 Sep 2011 12:14:10 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id F25481F0C62 for <>; Wed, 28 Sep 2011 12:14:09 -0700 (PDT)
Received: from [] ( []) by (Postfix) with ESMTPA id 95BE0754BCE5; Wed, 28 Sep 2011 19:16:57 +0000 (UTC)
Mime-Version: 1.0 (Apple Message framework v1244.3)
Content-Type: multipart/alternative; boundary="Apple-Mail=_7A0E1CFF-6B02-4A40-AE63-C085F99148CD"
From: "Olle E. Johansson" <>
In-Reply-To: <>
Date: Wed, 28 Sep 2011 21:17:24 +0200
Message-Id: <>
References: <>
To: Harald Alvestrand <>
X-Mailer: Apple Mail (2.1244.3)
Cc: "" <>
Subject: Re: [rtcweb] ICE for dual stacks (new topic)
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, 28 Sep 2011 19:14:11 -0000

28 sep 2011 kl. 14:09 skrev Harald Alvestrand:

>> Added an explicit statement that ICE is required for both NAT and
>>   consent-to-receive.

I would like to bring IPv4/IPv6 transition to the table in the ICE discussion. Quoting - abot SIP IPv6 transition:


When following the ICE procedures, in addition to local addresses,
   user agents may need to obtain addresses from relays; for example, an
   IPv6 user agent would obtain an IPv4 address from a relay.  The relay
   would forward the traffic received on this IPv4 address to the user
   agent using IPv6.  Such user agents MAY use any mechanism to obtain
   addresses in relays, but, following the recommendations in ICE, it is
   RECOMMENDED that user agents support STUN relay usage [6] [8] for
   this purpose.

   IPv4/IPv6 user agents SHOULD gather both IPv4 and IPv6 addresses
   using the ICE procedures to generate all their offers.  This way,
   both IPv4-only and IPv6-only answerers will be able to generate a
   mutually acceptable answer that establishes a session (having used
   ICE to gather both IPv4 and IPv6 addresses in the offer reduces the
   session establishment time because all answerers will find the offer


Now, I know this has been discussed widely and there are some drafts that discusses this. Dan Wing writes in

To achieve a similar function on the media plane, SIP endpoints are
   expected to use connectivity checks [RFC5245] to ensure there is IPv6
   (or IPv4) connectivity.  ICE has an advantage over the technique
   currently used by web browser, in that ICE does not wait for a user-
   noticeable timeout before trying other addresses.  However, ICE is
   considered overkill for the problem of migrating to IPv6 because of
   the overhead of timers, interaction with existing media state
   machines, and CPU impact of SHA1 on large devices processing many
   sessions and on small devices.

My question is of course what the opinion is about this in regards to our work in rtcweb?