Subject: [MMUSIC] Changes in ICE-09

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 05 Jul 2006 18:12:08 -0400

As folks probably noticed, ICE-09 did get submitted in time. Here is the 
full set of changes that went into the update:

* added new fields to candidate attribute, which indicate the type of
candidate (local, server reflexive, relayed). In the case of server
reflexive, the associated local transport address is indicated. In the
case of relayed, the associated reflexive transport address is
indicated. The latter isn't used by ICE directly, but was found to be
needed to add ICE to IMS, for QoS to work. The former however is used
as part of new optimization procedures.

* the optimizations proposed in Philip Matthews draft have been
integrated in. This is done by pruning the transport address pair
priority ordered list of redundant pairs, where redundancy is defined
as the remote addresses match, and the native ones share the same
local transport address. This needs to be combined with the idea of a
connectivity check on one transport address pair serving to validate a
different transport address pair when the addresses don't match. That
functionality was alraedy in
ice-08 but was underspecified and in the wrong section of the
document. Its been integrated into the core state machine processing,
which required another transition to be added to the machine (this
transition was specified in -08 but the diagram didn't show it as
allowed). As another part of this optimization, if a connectivity
check validates a different candidate, it also invalidates the one it
was meant to check. Such invalidation is required to maintain
symmetry.

* if a connectivity request is received, but on the 'wrong' local
transport address, it is rejected with a 430. This is needed to deal
with another corner case that was discovered - one agent is in the
network configuration in Figure 2 of ice-08, and the other is behind a
symmetric nat. This particular use case made my head explode and it
poked a couple of holes in little pieces of the ice logic

* another related problem in fully supporting figure 2 use cases was
found. The spec will now have you create a peer derived candidate if
the 'new' address is actually not new, but whats new is that it was
created by the peer sending from a different interface.

* discovered a bug in the treatment of peer derived candidates, which
would delay the full suite of connectivity checks for them until all
of the addresses in the derived candidate had been discovered. Now its
paced out smoothly which speeds things up

* changed the description of how you determine when to actually
promote a canddiate to active. The previous description was confusing
and didn't work in a corner case. The new one is simpler and always
works

* major terminology change: replace "active" with "operating" when
referring to candidates that are in use for media. This is
due to the overlap with 'active' from comedia and ice-tcp, which
refers to directionality of opening. The latter is the older term and
thus has been retained.

* changed treatment of a=remote-candidate. Its used not just for
selecting the value of m/c-line but also candidates to include in
offer/answer.

* redefined default value of Tws algorithmically as Tws = max(0, 100ms
+ RTT - N*50ms)

* defined a separate timer, Tb, for interval between connectivity
checks, and have Tb = 50ms*N where N is the numebr of media
streams. This allows for the aggregate rate of connectivity checks to
stay flat as the number of media streams increases. Also defined a
randomization factor of .7 to 1.3 applied to this interval, so that we
avoid synchronization of connectivity checks across media streams,
much like was done for RTCP.

* removed ability to change passwords arbitrarily; now it requires all
addresses being different to address 3pcc cases.

* recommend malformed RTP be sent to a peer agent when no suitable
keepalive formats are available

* clarified how other parameters of a peer derived candidate - namely
transport protocol, candidate type, and related address, are obtained
from the generating candidate

* formerly, if a candidate pair got removed due to a re-invite, and a
binding request was received for it anyway, a 430 would be sent. This
is inconsistent with normal stun processing rules elsewhere in the
specification, where a 200 OK is sent as long as the local candidate
is known. A reference is given to that section instead

* added a MUST for overall processing assocaited with learning new
candidate pairs

* compacted the call flows, updated them, fixed the bug reported in
the basic call flow example

* added text to handle corner case of when a nat reboot happens
mid-connectivity check, in which case you might actually see two
different peer derived transport addresses for the same candidate

* clarified that a=remote-candidate is included in pretty much every
subsequent offer. Clarified that it is not included in the answer.

* clarified that, when STUn is prodded to do a retransmit of a
connectivity check because of an incomign connectivity check, this is
an extra STUN request, not a rescheduling of one that is coming up
soon

* made some minor tweaks such that ICE should work even through b2bua
which modify m/c-line but not candidates. In that case media will
always go to m/c-line. This required agents to be prepared to receive
SDP where there are no candidates matching m/c-line.

* clarified that, an agent will play out media it receives unless it
knows that all potential forked recipients are ice aware

* clarified how to map a stun response to a transport address pair

* removed text which implied that peer derived candidates only come
into play with symmetric nat; Philip has shown a use case where this
is not so (ICE processing is unchanged - just the explanation of when
the peer derived candidates show up has changed)

* fixed examples which were missing the ":" after the a=candidate
attribute

* rewrote introduction to try and make it much more clear

* clarified that server reflexive and relayed candidates all need to
be derived from a single local candidate, with a matching of
components 1-1

* relaxed restriction on using ephemeral ports for local candidates

* clarified that, in the SDP itself, there is no requirement that
attribute lines for the same candidate ID appear together or in
component-id order

* updated references to SDP-new, and updated references to I-Ds which
have been published as RFC

* mentioned in introduction the importance of the symmetric RTP
property and why it needs to be there

* clarify that all components of a candidate share the same priority

* uniform usage of tid vs. transport address ID, component-id vs
component ID, etc.

* clarified that the randomness requirements on candidate ID imply a
minimum of 4 characters.

* clarified that the ice-pwd I give out is the one I use to verify
incoming requests.

* clarified that, when a connectivity check has a source IP or
xor-mapped address that doesn't match the candidate, a comparison is
done against all other candidates *of the same transport protocol for
the same media stream*.

* changed example candidate IDs to be legal (long enough)

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