Subject: [MMUSIC] Summary of agreed ICE changes from first ICE call

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 13 Sep 2006 14:30:35 -0400

I wrote in my notes a summary of comments for concrete changes (mostly 
minor) on the ICE-10 spec that were discussed on the first ICE call a 
little over a week ago. I also merged these with actions from Rohans 
notes. Here they are:

* Folks were OK with the spec not discussing multiple STUN servers. 
However, they wanted to make sure that the mechanisms in the 
specification would continue to work fine if multiple ones were used. I 
agreed to make sure that this was the case; I had tried to do that but 
it requires another pass. In particular the discussion on foundations is 
not correct on this.

* Slide 9 in my slideset shows a graphical representation of the 
priority space resulting from the prioritization formula. There were 
comments that this was very useful in understanding the motivations 
behind the formula. Rohan agreed to ascify this picture and then I'll 
add it to the design motivations section. Similarly with the way frozen 
states work.

* There was a lot of discussion on the desire to allow the offerer to 
send media once the checks complete, not just the answerer. We debated 
whether previous versions of ICE allowed this (I didnt think so), but 
there was consensus nonetheless to add this back (see:
http://www1.ietf.org/mail-archive/web/mmusic/current/msg04595.html with 
the proposed fix)

* there was general confusion on the purpose of the related information 
field for relayed candidates. The motivation based on packetcable was 
not understood by several readers. There were also concerns raised that 
this would break topology hiding, which is one of the reasons people use 
relays to begin with. I agreed to (1) motivate this more, (2) mention 
that you can omit the related information if you want. Its not used by 
ICE processing.

* some errors in the spec on the values of the priorities were poitned 
out (namely the highest priority values should be 9999 not 9990). This 
will change anyway if we agree to my alternate formulation for the 
priority formula.

* There was a desire to avoid floating point for the priority values. My 
proposed change in open issue #3 today resolves this.

* One reader was confused about whether, when the check list is being 
computed, updating the local candidate with its base was done just for 
the check list or for that candiadte generally. The answer is just for 
the check list and I will clarify that.

* there needs to be normative text somewhere that says that component 
IDs have to start at one for any type of media stream. Currently there 
is only text for RTP/RTCP.

* it needs to be clarified that ICE is done when there is a candidate 
pair in the valid list for each component of each media stream; the 
number of components here is the reduced one in the case where the 
offerer and answerer didn't use the same number

* need to clarify that you need two candidates for RTP if RTP is run on 
different ports than RTCP; see recent draft on muxing RTP and RTCP, 
whicih would work very well with ICE and speed it up even further.

* There was some confusion on 'media level keepalives', in that these 
include ICE checks, which isn't obvious from the term. Need to clarify.

* some concerns were raised that these generic ALGs which rewrite 
private addresses would rewrite the SDP also. That is, they don't just 
target binary values (which motivated the XOR-MAPPED-ADDRESS in 
rfc3489bis), they also target ASCII. This would cause candidates to be 
rewritten, and break ICE. It was suggested to change the representation 
of candidates in the a=candidate line by using an exclamation point 
instead of a period in IP addresses. That is:

10!0!1!1 instead of 10.0.1.1

of course, this cannot be done for the m/c-line. We need to discuss this 
more; I'll send a separate note on it.

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