Subject: [MMUSIC] ICE-15 WGLC Comments

From: "Kevin Johns" <[email-masked]>
Date: Thu, 19 Apr 2007 22:24:21 -0600

Jonathan,
 
Please find my comments on ICE-15 below for your consideration. I tried
to avoid nit picking, hopefully I was successful. I did not include any
editorial issues I found (spaces in the middle of words, missing closing
parenthesis, etc.) as I figure those will be caught by the editor before
publication. If you want them I will gladly forward.
 
Let me know if you have any questions.
 
Kevin

Section 2.4 (Frozen Candidate)

1st paragraph, 1st sentence at the end of the parenthetical statement -
'each of which has to work for the media stream as a whole to be work' I
think 'be' should be deleted

Section 4.2 (Lite Implementation)

Per my previous email this section is unclear as to whether a lite
implementation can include multiple candidates. Given my understanding
that it cannot, I think removing the first sentence of the last
paragraph would help clarify the section.

Section 5.7.2 Computing Pair Priority and Ordering Pairs

The formula ends with (O>A?1:0) but the text after the formula defines
it as (O-P>A-P?1:0). The formula should probably be updated to align
with the textual description.

Also, given the procedures in section 5.8 (performing periodic checks)
rely on the pair priority to determine the next pair to unfreeze are we
sure that the pair priority will results in pairs with the lower
component ID being checked first? Meaning if we have two component IDs
we want to check all the pairs for component ID 1 first before starting
any checks for component ID 2 pairs in order to get the optimizations
ICE provides by using the info learned from component ID 1 to quickly
find the best valid pair for component ID 2.

Section 5.7.4 (computing states)

2nd paragraph after step 2 indicates there are two states but three are
actually defined (running, completed, and failed).

Sections 7.1.1.1 (PRIORITY and USE-CANDIDATE) and 7.1.1.2
(ICE-CONTROLLED AND ICE-CONTROLLING)

Both sections discuss the ICE defined STUN attributes. It would be
helpful to provide a reference back to their respective sections where
they are defined (18.5)

Section 8.1.1 (Regular Nomination)

The 2nd paragraph discusses repeating the check with the USE-CANDIDATE
flag set. There is no discussion as to how the agent behaves if this
check is lost for some reason. While unlikely, it is possible that this
check could be lost in the network and would need to be retransmitted.
It might be worth while to provide some guidance on this scenario.

I read section 9.2.1.1 (detecting ICE restarts) and 9.2.2 (procedures
for full implementations) to be contradictory. 9.2.1.1 states that if
ICE is restarting for a media stream the agent MUST change the
a=ice-ufrag and a=ice-pwd attributes in the answer. However, 9.2.2
states the username fragments, password, and implementation level MUST
remain the same as previously. If an agent needs to change one of these
it MUST restart ICE for that media stream by generating an offer; ICE
cannot be restarted in an answer. I am I miss-reading these two
sub-sections? 

Section 12.1.1 (offer in INVITE)

The 2nd paragraph discusses a mechanism for ensuring reliable delivery
of a response. However, if the target of the response is an ICE-lite
implementation it will never send a stun request and the agent is forced
to keep retransmitting its response needlessly. Would it make sense to
call this out, or let it be as it will resolve once the agent sends the
200 OK?

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