Subject: [MMUSIC] ICE-tcp-03 is here

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 06 Mar 2007 23:15:47 -0500

Until it appears in the archives:
http://www.jdrosen.net/papers/draft-ietf-mmusic-ice-tcp-03.txt

Unlike the more mature core ice spec, this document underwent major 
changes. CHanges are:

* note that ice-tcp only works with full implementations of ICE, since
   it uses multiple candidates for a media stream

* removed TLS; ICE is about layer 3/4 stuff. If you want to negotiate
   whether to use TLS on a TCP connection, then use SDP capability
   negotiation, not ICE. Ekr hinted at this issue several ietf meetings
   ago, it has finally sunk into my head that he is right.

* if you have a UDP default and a TCP candidate but intend to use TLS
   for it, you have to include the RFC 4572 tls parameters
   (fingerprint), and in the initial offer, as you normally
   would. These parameters are effectively a signal to use TLS
   on those connections. Since fingerprint is now included in the
   initial offer, if ICE selects the tcp/tls candidate it can be used
   immediately for media. You used to have to wait for the updated
   offer to get the fingerprint, causing clipping of packets.

* spec used to previously have you allocate a relayed TCP candidate from all
   passive and s-o bases; this is not necessary - you only need it from
   one or the other, though you do need a server reflexive from
   all. Fixed this, reducing number of required candidates

* comedia (RFC 4145) is now used strictly as a fallback mechanism in
   an initial INVITE for dealing with non-ICE peers. This vastly
   simplifies the interactions between ICE and comedia. Now, there are
   none since ICE itself uses nothing from comedia, not even holdconn
   (which was previously requried for subsequent O/A exchanges). This
   addresses concerns raised that the relationship between the two was
   not clear.

* A regular selection algorithm MUST be used when there are tcp
   candidates. Long story why, a note is included to explain.

* ICE restarts are now used as the vehicle to signal desire to tear
   down a connection; note that the teardown won't occur until a new
   pair gets selected. Indeed if the same pair gets reselected the
   existing connection is reused. This allows for ICE restarts to occur
   to while maintaining perfect continuity of media over a connection
   should a better choice not be validated

* connection management clearer now. SPec is clear that you can close
   a connection yourself if you really want, and ICE will get it
   reopened without redoing signaling. Exact procedures for repair are
   specified, including an ICE restart if it can't be reopened (likely
   a common case)

An important thing to note is that I was able to make all of these 
changes without needing to change anything back in core ice. Thats also 
good; it means that things are well enough in ice itself that extensions 
like tcp can now proceed without us fearing that we need to hold the 
core spec for them.

There are a few open issues which I will post on.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic