Subject: [rtcweb] New version of -overview posted

From: Harald Alvestrand <[email-masked]>
Date: Wed, 28 Sep 2011 14:09:45 +0200

I've just posted version -02 of the -overview document.
I'll just paste the change log from the document here:

> A.6.  Changes from draft-ietf-rtcweb-overview -01 to -02
>
>    Added pointers to use cases, security and rtp-usage drafts (now WG
>    drafts).
>
>    Changed description of SRTP from mandatory-to-use to mandatory-to-
>    implement.
>
>    Added the "3 principles of negotiation" to the connection management
>    section.
>
>    Added an explicit statement that ICE is required for both NAT and
>    consent-to-receive.

Comments are always welcome, and version numbers are cheap!

A note on making the finding of such easy:
When I prepare a new version of a draft, I'll go back to the mailing 
list and search for subjects containing the draft name, or some subset 
of that ("overview" in this case), and dated between the previous 
version and this version.

Starting the subject line with "ISSUE:" or "CHANGE:" is also good for 
catching my attention when I'm trying to re-locate those comments.

Suggestions for changes that occur deep within a thread on other topics 
have a high chance of getting lost in this process, unfortunately.

Enjoy the reading!

                       Harald

---

From: "Olle E. Johansson" <[email-masked]>
Date: Wed, 28 Sep 2011 21:17:24 +0200

>> Added an explicit statement that ICE is required for both NAT and

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

---

From: Roman Shpount <[email-masked]>
Date: Wed, 28 Sep 2011 15:31:33 -0400

> My question is of course what the opinion is about this in regards to our
If we are mandating ICE we should use it for dual network clients. It is an
overkill if this is the only reason for doing it, but since we also doing
for NAT traversal and peer validation, this is the best solution currently
available.
_____________
Roman Shpount