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

["Olle E. Johansson" <[e-mail]>]

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 
http://tools.ietf.org/html/rfc6157 - 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
   valid.)

-----

Now, I know this has been discussed widely and there are some drafts that discusses this. Dan Wing writes in
http://tools.ietf.org/html/draft-wing-dispatch-v6-migration-00

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?

/O