Subject: [MMUSIC] ICE-12 now available

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 25 Oct 2006 17:03:43 -0400

Folks,

ICE-12 is now available. Until it appears in the archives, you can pick 
it up at:

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

Changes include:

* Bad news - the main new features on future-proofing of selection
   algorithms, allowing restarts, a gateway mode, and media
   transmission have added 5 more pages compared to -11. ICE is gaining
   weight again :(

* changed Ta default from 50ms to 20ms

* added notion of two modes in ICE - full and passive-only. The latter
   is for things like PSTN gateways. Added an informative annex which
   summarizes ice processing for passive only devices; normative text
   is sprinkled throughout the document as needed. THis was actually a
   really big change, and required touching text nearly everywhere. Not
   a lot of real normative procedural changes, but it was a lot of work
   to make it clear what a passive-only agent has to do, vs. full.

* introduced notion of passive and controlling roles for a session,
   and added rules for role determination. The rules are obvious when
   one side is passive-only. When both are full, the agent which sent
   the offer that started ICE processing is the controlling agent. This
   keeps the role fixed while ICE runs, even if offers and answers are
   exchanged for other reasons. However it allows an ICE restart to
   retrigger role selection.

* when two passive only agents call each other, ICE is aborted
   completely, as if neither side supported it. This is somewhat
   different than what was discussed on our conference calls, where we
   hoped an agent could at least respond to checks. Turned out that
   required specifying a hybrid mode anyway (which we didn't want to
   do). This is simpler. If we want to end up with ICE for calls
   between two gateways to prevent voice hammer, the gateways just need
   to implement full mode.

* added notion of states for connectivity checks, which can either be
   running or completed.

* added the USE-CANDIDATE STUN attribute. This is included by the
   controlling agent to select the candidate pair that gets used. Added
   rules for how agents mark candidate pairs in the valid list as
   "selected" when they were validated by a check containing this
   attribute, or by a check in the reverse direction of a check
   containing this attribute.

* defined new algorithm for concluding ICE. Passive agents continue
   checks for a component of a media stream until they see the
   USE-CANDIDATE flag, and then they stop. This allows the controlling
   agent to decide how long to let checks run for, and which pair gets
   used. A basic default algorithm is provided for controlling agents
   to set the USE-CANDIDATE flag: include it in every check (it works
   and basically produces the same algorithm as ICE-11 used).

* once ICE concludes, an updated offer is sent by the controlling
   agent ONLY if the selected candidate pairs differ from the ones in
   the m/c-line. This has the nice side effect of eliminating extra SIP
   signaling in "good" un-natted networks. Indeed, the extra
   offer/answer is no longer present in the example in the Examples
   section.

* rules for subsequent offers now explicitly talk about adding media
   streams and how ICE processing is restarted (using a change in
   username/password). Handling of 0.0.0.0 is
   described, as is recommendations for call hold. ICE restarts allow
   for graceful transition of media; you continue to use the old
   selected candidates until the ICE checks complete, at which point
   you switch over to the new.

* Media transmission rules: you always send to the selected candidates
   in the Valid list (based on the STUN signaling). If these conflict
   with m/c-line, ignore m/c-line. This differs from what we discussed
   in the calls; separate note pending on that. Keepalives similarly go
   to wherever media is being sent. This is different from -11 which
   had a somewhat convoluted algorithm for triggering keepalives like
   they were a regular ICE check. With ICE states this wasn't necesary
   and changing that eliminated the need for the extra offer/answer
   exchange.

* did NOT add the mechanism we discussed for "inserted"
   candidates. COnsequently, if an offer shows up and the m/c-line
   doesn't match a candidate ICE is aborted, like -11. This inserted
   mechanism was not going to work once I got into details; separate
   note pending on that too

* removed open issue regarding removal of peer derived candidates; you
   can't remove any candidates without restarting ICE in fact. With an
   ICE restart this removes peer derived candidates too, so now there
   is a way to remove peer derived candidates.

* ICE role changes are permitted if ICE restarts for all media streams

* point out that ICE makes no recommendations on what to do if a
   keepalive fails; however, do call out that restarting ICE blindly is
   a bad idea

* clarified that b=0 and a=inactive still count is in-use media
   streams for which ICE processing is done.

* ICE now works with flow III of RFC 3725 (3pcc) and this is noted. I
   spent a lot of time agonizing over 3pcc flows and making them
   maximally interoperable with ICE; there are one or two seemingly
   bizarre rules on ICE restarting based on these use cases (for
   example, a call starts out with no ICE support, but a reinvite
   introduces a media stream with candidates - this is called out)

* moved some of the formal definitions of the connectivity check usage
   into a later section in the ICE spec, so that the normative text
   flows more smoothly

* added recommendation that DSCP markings in ICE match the media
   streams

* noted that usage of STUN for reliability of 1xx doesnt change rules
   on offer/answer exchanges

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