Subject: [MMUSIC] Few comments on ICE-16

From: "Jean-Francois Mule" <[email-masked]>
Date: Fri, 29 Jun 2007 15:21:30 -0600

Jonathan,

  Here are a few comments.

- in 4.1.1.2., paragraph 2:
The current text puts 2 conditional MUSTs depending on the deployment
usage but does not clearly spell out what MUST be implemented and
configurable.
As you did in the first paragraph, it would be a plus to have a clear
requirement on what is RECOMMENDED for the agent to implement (SHOULD
for both STUN Allocate & Binding). 

- re: the new formula for Ta:
I understand that this came out of the ICE pacing discussion and Dan's
proposal on the TSVWG list and following discussions but nonetheless, it
adds significant complexity.
1) nit - while you point folks to read section B.1 for more details, it
is a bit opaque as presented. Adding one sentence around this formula's
goals (same bandwidth as RTP) or risks if implementers choose to
hardcode this as 20ms may help.
2) what happens when you have a media stream being offered with a codec
and different ptimes supported (e.g. G.711, ptime=10, 20)? Should an
implementation should the default ptime for the codec or the ptime that
will result in the greater sum value? 

- RTO: consider removing "/" from the formula 

- what happens if an agent receives SDP with changes in the SDP that
would have required an ICE restart but the sending agent did not change
pwg/frag (not fully compliant or buggy implementation)? Should it reject
the changes by sending an error response (which one)? or gracefully
assume a restart and proceed with an ICE restart? does this impact the
controlled/controlling role?
 This could be clarified to handle the error case - may be it is and I
missed it.

- re: IPv6, the email I sent to the v6 list on 5/24 and copied you
Jonathan on asking for their review & guidance never made it to the v6
list. I realized this today searching through the archive. I will update
it and resend - sorry about that. Given the changes though, getting more
eyeballs on the new text for dual-stack hosts will be a plus.

Jean-Francois.

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

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 29 Jun 2007 22:50:49 -0700

> -----Original Message-----
> From: Jean-Francois Mule [mailto:[email-masked]] 
> Sent: Friday, June 29, 2007 2:22 PM
> To: Jonathan Rosenberg; [email-masked]
> Subject: [MMUSIC] Few comments on ICE-16
> 
> Jonathan,
> 
>   Here are a few comments.
> 
> proposal on the TSVWG list and following discussions but 
> nonetheless, it adds significant complexity.

I don't believe it does; it merely defines a formula to calculate
Ta and RTO, rather than using hard-coded values.  The STUN state
machine stays the same, and ICE and ICE's operation do not interfere
with the STUN state machine or STUN timers due to this change.

> implementation should the default ptime for the codec or the 
> ptime that will result in the greater sum value? 

It's impossible for the offerer to send a connectivity check until
it receives the SDP answer (because until the answer arrives, it
doesn't know the IP address and UDP port to send its connectivity
checks to).  When the answer arrives, the offerer will know which
ptime to use.  The RTO and Ta formulas are calculated at the time
the answer is received (not when the offer is generated).

> - RTO: consider removing "/" from the formula 

-d