Subject: [MMUSIC] Further comments on ICE-15

From: "Elwell, John" <[email-masked]>
Date: Wed, 11 Apr 2007 14:46:02 +0100

Jonathan,

Yet more comments from myself and a colleague. Apologies if any have already
been discussed.

"Candidate:  A transport address that is to be tested by ICE
      procedures in order to determine its suitability for usage for
      receipt of media."

A candidate will not necessarily be tested, because it may not be compatible
(e.g., an IPv6 candidate will not be acceptable to an IPv4-only endpoint) or
because aggressive mode has already found a suitable candidate-pair. Perhaps
it should say "A transport address that requires testing by ICE
procedures in order...."

"The process for selecting default candidates at the answerer is
   identical to the process followed by the offerer, as described in
   Section 4.1.3 for full implementations and Section 4.2 for lite
   implementations."
I would suggest that each default candidate of the answerer MUST be
compatible with the corresponding default candidate of the offerer.
Otherwise it may happen, that the default candidates of the offerer are v4
addresses and the default candidates of the answerer v6 ones.  That makes
little sense.

"If this happens, the number of
   components for that media stream is effectively reduced, and
   considered to be equal to the minimum across both agents of the
   maximum component ID provided by each agent across all components for
   the media stream."
Maybe this works for RTP/RTCP, but is it sufficiently general? What if for
some reason in future there are 3 components for a media stream and that R
has included candidates for all components (1,2,3) but L includes candidates
only for 1 and 3?

"The check list itself is associated with a state, which captures the
   state of ICE checks for that media stream.  There are two states:"
In fact three states are listed.

"This state is equal to Running while checks are in
   progress.  The state is Completed when all checks have been
   completed."
There should be a corresponding statement for Failed.

"Once the agent has computed the check lists as described in
   Section 5.7, it sets a timer for each active check list."
In fact, there will only be one active check list at this stage.

"The first
   timer for each active check list fires immediately"
There will only be one active check list initially.

"5.8.  Performing Periodic Checks"  
Should it be mentioned somewhere in this section when a frozen check list
should become active?

"(as defined in [12],"
Closing bracket missing.

"If the check list is frozen, and there is at least one pair in
          the check list whose foundation matches a pair in the valid
          list under consideration, the state of all pairs in the check
          list whose foundation matches a pair in the valid list under
          consideration are set to Waiting."
Do we need to say anything about starting the timer for periodic checks?

"This flag
   indicates that this valid pair should be used for media if it is the
   highest priority one amongst those whose nominated flag is set."
Since the formula for computing priorities produces unique priorities only
"in most cases", we should have some statement here about how to deal with
equal priorities.

"In
   cases where multiple STUN requests are received before the answer,
   this may cause several triggered notifications to all be sent at the
   same time,"
Incomplete sentence. Or maybe the comma should be a period.

"In unusual cases it is possible for both agents to mistakenly believe
   they are controlled or controlling.  To deal with such cases, at the
   time an agent determines its role, it MUST select a random number,
   called the tie-breaker, uniformly distributed between 0 and (2**64) -
   1 (that is, a 64 bit positive integer)."
Notwithstanding the comment I made in a separate email about the need for a
tie-breaker, if we really do need a tie-breaker why can't the ice-pwd be
used instead, because that has a similar amount of randomness?

"9.1.1.1.  ICE Restarts"
If an endpoint receives a SIP re-INVITE without an SDP offer, and as a
result has to send an SDP offer in a SIP 2xx response, should this be
treated as an ICE restart or a new session. It could be as a result of a
3PCC transfer, so effectively it would need to be a new session, but the
endpoint has no way of knowing that. So it would have to treat it as a new
session to be safe. This then means that existing media cannot continue to
flow, which would be a disadvantage if it isn't really a new session. We
should make some statement about this situation. Furthermore, if the peer
rejects the offer, what should happen?

"The only
   difference between an ICE restart and a brand new media session is
   that, during the restart, media can continue to be sent to the
   previously validated pair."
Presumably with a restart, if the offer gets rejected, existing media will
still continue. Furthermore existing period connectivity checking will
continue using the old password. Should clarify.

"In that case, when
      receiving an offer or answer containing an FQDN in an a=candidate
      attribute, the FQDN is looked up in the DNS using an A or AAAA
      record, and the resulting IP address is used for the remainder of
      ICE processing."
What if the DNS look-up yields both an IPv4 and an IPv6 address?

"Consequently, ICE serves to repair the brittleness introduced in
   other UNSAF mechanisms, and does not introduce any additional
   brittleness into the system."
Probably true, but isn't it worth mentioning the performance impact, i.e.,
potentially longer call set-up time?

"A full implementation will reduce call setup times."
Why would a full implementation reduce call set up times compared to lite?
Some explanation would be appropriate. The only reason I can think of is the
fact that lite prevents use of aggressive mode.

John

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