Subject: [MMUSIC] ICE Lite support in ICE

From: "Kevin Johns" <[email-masked]>
Date: Mon, 19 Mar 2007 12:51:32 -0600

Jonathan, 
 
I know you requested that ICE not be nit-picked, but the ICE lite text
is rather new and probably has not received as much review. Given the
direction to complete ICE with ICE lite requirements I did a quick check
to make sure things were clear (my previous reads did not look at it
from an ICE lite perspective). A technical question:

In the case of ICE-lite to ICE-lite both would be controlled and updates
would never happen and are not necessary, but the text in section 10.1.2
prohibits an ice lite implementation from sending media till it has a
valid list. I don't think a valid list would ever be created in this
situation?

Please take these editorial comments as you desire...
 
Section 5, the intro does not discuss ICE Lite and its applicability
(although it is implied) making it more explicit would help.
 
Section 5.6 should indicate the reference to section 4.3 is for both
full and lite implementations

Section 9.1.3 does not seem necessary given the same text is covered in
the general procedures or I am missing something? 
 
Kevin Johns

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 26 Mar 2007 10:04:54 -0400

inline.

> valid list. I don't think a valid list would ever be created in this

WHen both are ice-lite, ICE is abandoned completely for this session. 
This was indicated by the fairly opaque text here:

5.1.  Verifying ICE Support

    The answerer will proceed with the ICE procedures defined in this
    specification if the following are all true:

    o  For each media stream, the default destination for at least one
       component of the media stream appears in a candidate attribute.
       For example, in the case of RTP, the IP address and port in the c
       and m line, respectively, appears in a candidate attribute, or the
       value in the rtcp attribute appears in a candidate attribute.

    o  The offer omitted an a=ice-lite attribute or the answerer is a
       full implementation.

ANd in particular the second bullet. I've added a sentence to that 
second bullet which says:

In other words, if both agents are lite
implementations, the agent does not proceed with ICE.

> (although it is implied) making it more explicit would help.

changed to:

<t>
When an agent receives an initial offer, it will check if the offeror
supports sufficient ICE functionality to proceed (i.e., if both
offeror and answerer are lite implementations, ICE cannot proceed),
determine its own role, gather candidates, prioritize them, choose
default candidates, encode and send an answer, and for full
implementations, form the check lists and begin connectivity checks.
</t>

> full and lite implementations

done

> the general procedures or I am missing something? 

The general procedures cover restarts, adding and removing a stream. 
THis section covers the case for lite implementations when an updated 
offer is sent for an existing media stream.

-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