Subject: [MMUSIC] updated ICE spec

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 09 Mar 2006 00:16:46 -0500

Folks,

I submitted an update to the ICE specification. Until it appears in the 
archives, you can pick up a copy at:

http://www.jdrosen.net/papers/draft-ietf-mmusic-ice-07.txt

The changes are stuff that was agreed on at the last meeting, plus a few 
minor bugs reported since last meeting, plus some changes implied by the 
STUN/TURN unification, mostly terminology changes.

I'm hopeful that we can go to WGLC with this version. There aren't any 
issues with ICE per se I'm aware of. The main thing right now is its 
dependency on STUN and TURN which have both had substantial rewrites 
this round due to their unification. But, they are both looking much 
better for it (IMHO).

The specific changes are as follows:

* changed connectivity preconditions to an informative reference

* fixed up intro so it doesn't talk generically about multimedia protocols;
it focuses on offer/answer

* major terminology change based on new stun/turn drafts. Rather than
"stun-derived" its "server reflexive" and turn-derived is
"relayed". This is because TURN now provides BOTH types of addresses
with a single query, and also because TURN is now just a STUN
extension.

* the section on gathering addresses had recommended discarding
redundant ones. Changed the definition of redundant so that BOTH the
candidate and its associated local transport addresses need to be
identical to be redundant. This catches a corner case of a multi-homed
client in multi-layer private nets (yuck). It also somewhat
complicates the formation of the candidate pair ordered lists. The
procedures there say that you should take the candidate pair
corresponding to the active one, and promote it to the top of the
check list. Now, more than one candidates can match the active one. As
such, the draft recommends picking one.

* STUN username randomness reduced to 24 bits (this is actually
sufficient to avoid collisions)

* STUN password now in a separate a=ice-pwd attribute at the session
level, shared across all candidates. Reduces the amount of randomness
and overhead in the SDP. Password is 128 bits random, username just 24.

* updated references to 3489bis.

* changed terminology from 'symmetric', 'full-cone', etc. to the
terminology in the behave UDP specs and referenced them

* included diagram showing the race condition that motivated the
a=remote-candidate attribute

* sending media to a candidate pair before its promotion to active is
now possible. This also allows early media to work with ICE, and for it to
be sent over the highest priority candidate (once validated), without
need for UPDATE. It works without prack too, but requires you to
retransmit the 18x until receipt of a stun request. However, you will
only get ONE WAY media until that candidate pair is promoted to active
in a subsequent offer.

* new early media treatment required a subtle but very important
change in the way peer-derived candidates work. Recall that each agent
has a role in a candidate - the offerer or answerer. Those roles
dictate who sends an offer to promote that candidate to active. It the
case of peer-derived candidates, it used to be that the agent which
sent the stun request was offerer. This would preclude peer derived
candidates learned from a UAS from being used with early media. To fix
that, the role is now inherited from the generating candidate.

* The new early media mechanism requires that a candidate be prepared
to receive media and stun packets on a candidate. There is no way to
signal that you disallow this. This was a feature that existed
previously; you could, through signaling, be explicit about whether
you were prepared for media on a candidate (by including it in the
m/c-line).

* changed slightly the rules about what constitutes a valid username
in an incoming stun request, since you only respond to valid
ones. Change is to deal with a race condition.

* when in the testing state (where the agent has sent a binding request but
not gotten a response), and it receives a binding request, it 
retransmits its
own binding request. This is to deal with the case where one agent is
behind a symmetric nat.

* added a simpler example

* added discussion on jitter buffer re-adaptation - triggered on
receipt of marker bit or change in source IP

Thanks,
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