Subject: [MMUSIC] ICE-16 now posted

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 12 Jun 2007 22:26:32 -0400

ICE-16 is now available:
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-ice-16.txt

This revision incorporates comments received during WGLC. Besides many 
editorial changes, here are the substantive ones:

* changed pair priority formula to be based on controlling/controlled
   roles rather than offerer/answerer. This allows pair prioritization
   to get fixed when there is a role conflict

* clarified that a 300 error response is not permitted for
   connectivity checks

* added upper bounds to the number of characters in the foundation,
   component-ID, priority, password and ufrag components of the
   grammar.

* spreading out of the start timers for check lists is RECOMMENDED, to
   avoid synchronized checks across streams

* previously, if there was at least one candidate matching a default
   in an offer, we'd proceed with ICE. Now, there must be a candidate
   for all defaults.

* aligned rules for verifying ICE support between offerer and answerer

* added section on when you can free candidates after ICE has
   concluded. It is done immediately for lite implementations, and
   three seconds after ICE has concluded for full. Interactions with
   forking are mentioned.

* Major change: ICE lite now allows for multiple v6 candidates and a
   single v4 candidate for each component. This came at the cost of
   some increase in complexity of the spec and procedures for lite
   implementations. In particular, ICE now proceeds when both agents
   are lite. Lite implementations now need to perform role selection,
   and when controlling, send an updated offer. They need to maintain a
   basic state for each media stream (RUnning or Completed). Role
   reversal is described based on usage of SIP signaling to resolve the
   conflicts. Lite implementations must send and process the
   remote-candidates attribute, though this processing is much simpler
   than the full case (where its a big pain in fact) and only needed
   for dual-stack (v4 only can ignore). Guidance added in
   the appendix that says you SHOULD still do a full implementation
   even if all you care about is ANAT replacement.

* Major change: congestion control mechanism added. THis is done by
   adjusting Ta and RTO based on a formula that takes into account the
   media bandwidth. Also, triggered checks are now scheduled rather
   than being sent immediately; basically there is a priority queue
   where every Ta you send a triggered check fi there is one, else an
   'ordinary' check. Ordinary check is the new name for periodic check
   since these are not so periodic anymore.

* If a transaction is in progress when a triggered check is to be
   sent, it is cancelled and a new transaction is scheduled
   (previously, there was an adjustment to the retransmits for the
   existing transction). Cancellation implies retransmissions cease and
   the tranasction doesn't fail on timeout, but you still wait for a
   response if there is one

* clarified that NONCE is not used with ICE

* added an informational appendix on when the conflict resolution
   procedures are needed and why

* clarified that when a FQDN is used in the candidate attribute, you
   look up AAAA first then A, and pick a single IP

* for 'poor mans RFC3262', if the offerer is lite, you won't get a
   STUN Binding request to terminate 18x retransmits. For this case,
   the spec now mandates no more than four retransmits of the
   18x. Another reason to implement full.

* inclusion of FINGERPRINT is MUST: motivation for this captured in
   rfc3489bis

* ICMP support is a MAY

I believe this is now ready for another WGLC.

-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

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 14 Jun 2007 07:37:15 +0100

Jonathan,

Is it correct that lite implementations are required to initiate
keep-alives? This seems to be indicated by the statement in section 10
"All endpoints MUST send keepalives for each media session.  These
   keepalives serve the purpose of keeping NAT bindings alive for the
   media session."
However, it seems unnecessary.

John

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]] 
> Sent: 13 June 2007 03:27
> To: IETF MMUSIC WG
> Subject: [MMUSIC] ICE-16 now posted
> 
> ICE-16 is now available:

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 14 Jun 2007 10:28:08 -0400

I think its good practice regardless of NAT traversal. In this case the 
endpoint doesn't need to send STUN; it can use any of the mechanisms 
mentioned there.

-Jonathan R.

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 18 Jun 2007 15:23:00 +0100

It says:
"ICE endpoints allow for
   STUN-based keepalives for UDP streams, and as such, STUN keepalives
   MUST be used when an agent is communicating with a peer that supports
   ICE."
So this statement and the statement I quoted previously seem to say that
a lite implementation MUST send STUN keepalives - it cannot choose
different mechanisms.

John

> Sent: 14 June 2007 15:28
> To: Elwell, John
> Cc: IETF MMUSIC WG
> Subject: Re: [MMUSIC] ICE-16 now posted
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 19 Jun 2007 17:58:52 -0400

OK, this text needs to be clarified. If an agent is ICE-lite it doesn't 
need to send STUN in general, including keepalives.

-Jonathan R.

Elwell, John wrote:

>>>keep-alives? This seems to be indicated by the statement in 
>>
>>section 10
>>
>>>   keepalives serve the purpose of keeping NAT bindings 
>>
>>alive for the
>>
>>>   media session."
>>>>* changed pair priority formula to be based on 
>>
>>controlling/controlled
>>
>>>>  roles rather than offerer/answerer. This allows pair 
>>
>>prioritization
>>
>>>>* spreading out of the start timers for check lists is 
>>
>>RECOMMENDED, to
>>
>>>>  in an offer, we'd proceed with ICE. Now, there must be a 
>>
>>candidate
>>
>>>>  for all defaults.
>>>>
>>>>* aligned rules for verifying ICE support between offerer 
>>
>>and answerer
>>
>>>>  are lite. Lite implementations now need to perform role 
>>
>>selection,
>>
>>>>  remote-candidates attribute, though this processing is 
>>
>>much simpler
>>
>>>>  adjusting Ta and RTO based on a formula that takes into 
>>
>>account the
>>
>>>>  where every Ta you send a triggered check fi there is 
>>
>>one, else an
>>
>>>>  'ordinary' check. Ordinary check is the new name for 
>>
>>periodic check
>>