Subject: [MMUSIC] Comments on ICE version 06

From: "zuo bf" <[email-masked]>
Date: Thu, 23 Feb 2006 17:03:06 +0800

Hi,
  First thanks for the great work. Then i'd like to give out the points at
which i am not clear.

1. Should all components in a candidate are in the same realm or are derived
using a same way ?
And Does the derived transport address need to compare with every available
transport addresses ?

>From the draft and example you give, i think you mean it's same, but I got
confused here. In page14,
there is no explicit require for that, and the candidate comparison just
compare transport address with
transport address in another candidate, there is the point, as we compare
candidate in this way, why
the process for getting a peer-derived candidate different, in that process
we restrict that the derived address
doesn't equal any available transport addresses (even they have different
component id), but isn't there a
chance that two candidate have partial same transport addresses ? Consider
the scenario below :
(This is a strange scenario, but i think it could be used for demo)
                               Phy1
|--------- | R1 |--------------------------------| R2 |
|          --------                                -------
|             |                                       |
|          -------                                 -------
|          | H1 |                                | H2 |
|          -------                                 -------
|             |                                       |
|          -------                                 -------
|----------| R3 |--------------------------------| R4 |
           -------           Phy2              -------
H1 and H2 are both in two realms, and a candidate comprised of two realm
address may pass the STUN connection
check, and even more there could a route H1-->R1--->R3----->R4----->H2,  and
if this route is better than the H1--->R1-->
R2--->H2 one, and better than the H1--->R3--->R4---->H2 because of some
factor like bandwith, then the desired candidate
can be comprised of two realm addresses, in that situation there is a chance
of collision with the peer derive procedure:
More clearly, assume Phy1 is an IPv4 network, Phy2 is an IPv6 network, H1
and H2 are dual stack clients but not capable of
conversion between IPv4 and IPv6. So the initial candidate list before any
peer-derived one added could be:
candidate1: H1_IPv4_transport_addr_1 H1_IPv6_transport_addr_2
candidate2: H1_IPv4_transport_addr_1 H1_IPv4_transport_addr_2
candidate3: H1_IPv6_transport_addr_1 H1_IPv6_transport_addr_2
We know routes H1-->R1--->R3----->R4----->H2 and H1--->R3--->R4---->H2 are
good for the two component respectively, so we want a
derived candidate4:R3_IPv6_transport_addr_1 H1_IPv6_transport_addr_2, but
because H1_IPv6_transport_addr_2 already exists
in several candidates,  and this address can't trigger the add action for it
to be added to the newly created candidate.

2. De-allocation of resources

This is just a riminder, in page 39 there is

   5.  If the removed candidate was a TURN-derived candidate, the agent
       SHOULD de-allocate its transport addresses from the TURN server.

But because there is a possibility of proxy forking, so an offer/answer exchange
within a single dialog doesn't mean that the TURN-derived candidate
won't be used
by other early dialogs or so.

3. When receive an update offer, why not trust the other agent ?

Also page 39, Receiving the Offer and Sending an Answer

Why not choose the a=remote-candidate directly, unless the offer is not sent for
just promoting one candidate to active, otherwise the pair that the
offer indicate
through m/c line and a=remote-candidate Should be the most desired
one, and because of the
peer-derive process when there's symmetric NAT exist, the undesirable
candidate pair could
be valid ahead of the the desired one in the answer side, does that
mean the answer should
use that candidate only because it hasn't received the response for
the desired pair's request,
but isn't there a 100% chance for that response to come ?

4. Role of offerer and answerer ?

In page 33, there is:

   Recall that, for each candidate pair, one agent plays the role of
   offerer, and the other of answerer.  For peer-derived candidates, the
   agent that receives the STUN request and follows the processing in
   this section acts as the answerer.
If the derived pair is the desired one, and the offerer and answerer role is
reversed, which one should send the updated offer ?

Thanks for your work, and hope the tcp support will be added later, my corp
block all UDP connections. Thanks again, really great work.

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