Subject: [MMUSIC] ICE-13 has arrived!

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 16 Jan 2007 14:23:32 -0500

Sorry for the delay in doing this. This was supposed to be done weeks 
ago. Here you have, finally, ICE-13:

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

I've submitted it and it should appear in the archives shortly. The 
draft includes everything we agreed to at the meeting. The only thing 
not there are the comments from the reviews posted to the list by Jason 
and Jean-Francois, which are all minor and which I'll address with the 
rest of the WGLC comments.

Here are the specific changes:

* changed keepalives to be sent only when there is no other traffic,
   and changed the format from a Binding Request to Binding
   Indication. Note that no message integrity is used for these
   indications. Added a section to the design motivations appendix on
   why indications are used instead of requests. Spec says you MUST
   still be prepared to receive and process a Binding Request.

* cleanly separated lite and full implementation requirements in the text

* updated terminology section with new terms - full lite
   implementations. Modes are now controlling and controlled, and refer
   to only a subset of the overall processing of an agent - who selects
   the final candidates and sends the re-invite

* changed the appendix on full/lite. Now, this is a discussion
   of the applicability of a full vs. lite implementation. The
   section emphasizes that lite is a stepping stone to a full
   implementation.

* renamed a=ice-passive to a=ice-lite

* added a=ice-mismatch attribute. Per agreement at the last meeting,
   this is used when an answerer receives an offer whose m/c-line did
   not have a matching candidate attribute.

* added requirement that a controlling agent talking to a lite
   implementation has to do a second check with the USE-CANDIDATE flag
   once a first without the flag succeeds. THis is what allows us to
   eliminate triggered checks for lite implementations.

* clarified usage guidelines for the STUN reliable 1xx hack. SHOULD
   use PRACK if available. Only works for certain provisional responses
   (answers that start ICE). Retransmits cease on 2xx. Lack of Binding
   Request doesnt terminate session. Answer in 2xx alone allowed but
   not recommended.

* added reference to ICE option and media feature tag spec. SHOULD
   support it.

* Added maximum of 100 connectivity checks as a SHOULD requirement,
   updated math in the document based on new STUN timers

* Added section on SBC and ALG considerations. Interactions with ALG
   are described. TLS is recommended. Note that ICE doesnt try to fix
   broken ALG or work around SBC.

* Added a new section on extensibility considerations, on how
   interoperability is addressed with new variations in the ICE
   algorithm. Added a new ice-options attribute that is like SIP's
   Supported header field. No IANA registry. Discuss the importance of
   sending a separate connectivity check with the USE-CANDIDATE flag in
   achieving interoperability between different protocol versions. ALso
   the importance of triggered checks.

* mentioned other offer/answer exchanges with sip, notably 18x/PRACK
   and 200/ACK. Recommend the former.

* added USE-CANDIDATE attribute to call flows

* clarified that an agent can send the USE-CANDIDATE flag after a
   check has succesfully completed, or before

* changed STUN to newly agreed acronym - Session Traversal Utilities
   for NAT

* Requirement strength on the candidate prioritization algorithm is
   SHOULD, not  MUST

* corrected bug which was still claiming that bidirectional media is
   not sent once a candidate is selected by ICE

* if an offerer restarts by changing the username/password, the
   answerer has to change them too

-- 
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: <[email-masked]>
Date: Thu, 18 Jan 2007 14:37:52 +0200

Hi,

The draft-ietf-mmusic-ice-13.txt specifies the foundation of a candiate
as follows:

"Foundation: Each candidate has a foundation, which is an identifier
that is distinct for two candidates that have different types, different
interface IP addresses for their base, and different IP addresses for
their STUN servers.  Two candidates have the same foundation when they
are of the same type, their bases have the same IP address, and, for
server reflexive or relayed candidates, they come from the same STUN
server.  Foundations are used to correlate candidates, so that when one
candidate is found to be valid, candidates sharing the same foundation
can be tested next, as they are likely to also be valid."

This is otherwise ok, but how come the requirement about having the same
STUN server IP address for server reflexive and/or relayed clients?
If these are from different network interfaces or if they are otherwise
obtained from different networks, that's of course understandable. But
if not, then is there any reason why the candidates should be acquired
from exactly the same server?

The concern is, that this forces the STUN (or TURN) candidates to be
acquired from the same server (if we want to get the same foundation).
This breaks the possible load balancing enabled by multiple STUN servers
listed with DNS (SRV/A/AAAA). Also this forces the candidate gathering
to be done in serial. Otherwise we could get candidates from different
STUN servers.

--
Tomi Kohonen
Nokia Corporation