Subject: [MMUSIC] Re: Further comments on ICE-15

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 12 Jun 2007 16:28:17 -0400

Elwell, John wrote:

> 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...."

good point. changed to:

<t hangText="Candidate:"> A transport address that is a potential
point of contact for receipt of media. Candidates also have properties
- their type (server reflexive, relayed or host), priority,
foundation, and base.
</t>

> 
> "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.
> 

It works fine though; they'll be a re-invite to fix-up once a pair is 
selected. Its really no different than one agent including a net10 
default and the other a public default. There won't be connectivity. I 
don't want to add normative requirements if it doesn't actually make a 
difference in behavior of the protocol (and it doesnt)

> "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?

That wouldn't work as defined. The mechanism was designed for RTP/RTCP 
and also looking out for things like layered codecs where you can use a 
subset. It works there too. If in the future it doesn't work for some 
new thing, we'll extend as needed.

> 
> "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.

yeah, many folks pointed this one out. fixed.

> 
> "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.

ok. though this state is not really needed per se, I added.

> 
> "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.

fixed

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

this is covered elsewhere in the spec

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

fixed

> 
> "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?

added  asentence and a reference to the section on 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.

actually I was able to mathematically prove that if each side provided 
candidates with unique priority (which is a MUST) and one side is 
controller and the other controlled (true with extremely high priority 
due to conflict resolution procedures), the pair priority is always 
unique. So I removed the 'in most cases'.

> 
> "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.

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?

I suppose. You need the stun check in either case. With this at least 
your random number is already an integer. If I use ice-pwd we'd have to 
specify how to convert to an integer.

> 
> "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 offerer is supposed to do a restart. This is described in Section 
12.5. WIth restarts media continues to flow.

> 
> "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.

Thats really true in general for O/A, and applies to everything in the 
spec. For example if I send an offer to add a candidate, and the offer 
is rejected, we continue with what we had before.

I added a sentencve to 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?

This is now clarified.

> 
> "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?

Wow! SOmeone is reading the IAB considerations section. Amazing.

I'll mention.

> 
> "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.

Exactly. I mentioned.

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