Subject: [Sipping] Re: Questions and comments on draft-rosenberg-sipping-ice-00

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 07 Jul 2003 15:54:41 -0400

Better late than never for a reply, I guess....

Thanks a lot for sending some comments and questions. Replies inline.

Francois Audet wrote:

> Hi Jonathan,
> 
> Better late than never I guess. I have a few questions/comments on
> draft-rosenberg-sipping-ice-00.html.
> 
> - Section 2 (the overview) says that the UAC should attempt to derive
>   IP addresses with STUN, TURN, RSIP and VPN servers and place all of
>   these addresses in the offer SDP. Sections 3, 5.1 and 5.4 confirm this
>   procedure. In the case of STUN, it means a dedicated STUN server as
>   opposed to the peer-to-peer UA STUN server used at call setup. However,
>   section 12.3 may lead the reader to believe that a dedicated STUN
>   server) is "simply not used" and that instead the peer-to-peer UA STUN
>   servers are sufficient. The wording should be re-done to clarify that
>   what is not used is the NAT classification process (the derivation of
>   the IP address using a dedicated STUN server is indeed used). At least,
>   I think this is what 12.3 is saying.

Yes, I agree this is confusing. I was able to submit a revised version 
of ICE in time for the deadlines. I updated this text to clarify.

  If there was an example 9.3,
>   similar to 9.2 but where B calls A, I assume that B would include both
>   LTA2 and PDTA2 in the offer, and that PDTA2 would be marked as
>   derived. Is this correct?

Yes.

> Since the 2 examples of section 9 do NOT have
>   a STUN-derived address for the calling party, it is even more confusing.

The examples in -00 were not so good. THe big thing that I did in this 
rev of ICE is basically incorporate the scenarios of 
draft-ietf-sipping-nat-scenarios, to show how ICE would work in 
residential, enterprise, and centrex configurations. There are several 
cases now which show peer derived transport addresses.

> 
> - Section 7.2 says that the derived-attribute refer to transport addresses
>   "learned from the entity to whom the SDP is being sent (referred to
>   as the peer)".

Right.

>   This is the same issues as the previous one. I don't think
>   this is correct. It is the transport address learned from the STUN
>   query: in the initial offer, that address is NOT learned from the
>   "peer" but from the dedicated STUN server. Correct?

No. The STUN address in the initial offer is indeed learned from the 
dedicated STUN server. However, it would not use the derived 
attribute, because the intent is indeed to cover only STUN addresses 
derived from a peer.

>  In the answer or in
>   a second round of offer (in an UPDATE), then is is indeed learned from
>   the peer. Is this correct?

Yes.

> 
> - In examples 9.1 and 9.2, A only has one address, a local IPv4 address.
>   The qvalue is set to 1.0 in the offer in both examples. According to
>   the rules 5.3, shouldn't the qvalue in the offer been set to 0.8
>   instead?

The q-values were just suggested. I removed any suggested values from 
the spec in the rev. Q-values, by their nature, are ordinal, and thats 
the behavior I want. Suggesting values may make people think they are 
cardinal with well defined values, which is both misleading and may 
result in subtle interop problems.

> 
> - In example 9.1, can't we skip the whole peer-to-peer STUN query since
>   both A and B know that no NATs are involved from their previous STUN
>   query to the dedicated STUN servers? I mean, when B receives A's
>   offer, it sees only one address (non-derived), and it knows that
>   itself has only a non-derived IP address.

You could, but in the case where there happened to be some kind of 
topology issue preventing the media from flowing, you might want to 
verify that before proceeding with the call.

> 
> - In a few places (including the abstract), it is claimed that ICE is less
>   brittle than STUN. This may be a little misleading since ICE itselfs
>   uses the STUN protocol. It should be clarified (as per my earlier point),
>   that what is meant by "STUN" in this context is that traditional STUN 
> only
>   is more brittle than ICE.
> 
> 
> Typos:
> - Section 2, third paragraph, first sentence. Replace "realsm" with
>   "realms".

fixed.

> 
> - In section 9.2, in the paragraph right before the description of the 
>   UPDATE content, replace "has no offered" with "has not offered".

That whole section is gone now.

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP