Subject: [Sipping] Comments on draft-ietf-sip-rfcbis-05.pdf

From: Peter Päppinghaus <[email-masked]>
Date: Mon, 21 Jan 2002 15:11:18 +0100

Hi,

I have a few comments on the bis-05 draft of SIP. So far I have not been
following neither the Sipping nor the Sip list discussions, so please
excuse me if some of my points have been discussed already.

1) Distinction of ACK to 2xx responses from ACK to negative final
responses.

The treatment of ACK for these two cases is very different, in fact,
they ought to be regarded as different methods. Not in all places of
bis-05 is it clear, which one of these ACK versions is meant.

Section 16.5, p. 58, l. 2214-2215 states "In particular, CANCEL and ACK
requests MUST have the same branch value as the corresponding request
they cancel or acknowledge." Clearly this can be required only for ACK
to negative final responses, since ACK to 2xx does not have to follow
the same path hop-by-hop.

2) When does a provisional response need to have a tag added to the To
field by the agent generating this response?

Taking bis-05 literally, each provisional response needs to have a To
tag. It seems like an oversight, that 100 Trying has not been exempted
from this requirement. For example, in section 13.3.1.1, p. 49, it is
said only of provisional responses between 101 and 199 that they
establish early dialogs. But even this seems to lead to an unnecessary
proliferation of early dialogs. To me it seems more reasonable to
officially introduce the term of a "dialog establishing response" (see,
e.g., bis-05, section 12.1, p. 41, l. 1536) and to stipulate that dialog
establishing responses MUST have a To tag, while an intermediate proxy
generating a provisional response may decide, whether it wants this
response to be "early dialog establishing" or not.

3) I have not found anywhere in bis-05 spelled out explicitly the "scope
of uniqueness" of the tags in From and To headers inserted by a SIP
entity. As I understand it, there should be one value for tags in From
headers uniquely identifying the SIP entity when generating requests,
and this value should be the same for all requests generated by it. And
there should be one value (different from the previous one) for tags in
To headers uniquely identifying the SIP entity when generating
responses, and this value should be the same for all responses generated
by it.

4) Various minor remarks about (believed by me to be) typing errors.

- Section 6, p. 17: In the definition of (SIP) transaction, 
  l. 637 should read as follows:
  "... and the ACK for the response in the case the response was a
non-2xx. ..."

- Section 9, p. 31, l. 1167 should read:
  "Section 16 discusses proxy usage of CANCEL."

- Section 12, p. 40, l. 1525 should read:
  "This state consists of the dialog ID, a local sequence number ..."

- Section 17.2.3, p. 75, l. 2769-2770 should read:
  "ACK request matches a transaction if the Request-URI, From, Call-ID,
CSeq number (not the method), and top Via header match ..."

Regards,

Peter Päppinghaus

-- 
Dr. Peter Päppinghaus
Siemens AG            | Phone:    +49 89 - 722 40065
ICM N PG U ID A1      | Fax:      +49 89 - 722 58726
Hofmannstr. 51        | Visitors: Building 1702 / Room 530
D - 81359 München     | Email:    [email-masked]

_______________________________________________
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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 27 Jan 2002 16:28:13 -0500

Thanks for your comments. Responses inline.

Peter Päppinghaus wrote:
> they ought to be regarded as different methods.

Interestingly, whether they are or aren't different is a matter of
perspective. For a stateless proxy, they are NOT different. That has
certain robustness benefits. 

> Not in all places of

It is hard to fix without specific reference to a place you found
confusing. Please let us know.

> the same path hop-by-hop.

Right. This has been fixed.

> field by the agent generating this response?

Always. From 8.2.7:

If a request contained a To tag in the request, the To field in the
response MUST equal that of the request. However, if the To field in the
request did not contain a tag, the URI in the To field in the response
MUST 1112
equal the URI in the To field in the request. Additionally, the UAS MUST
addatag to theTo field in the 1113
response. This serves to identify the UAS that is responding, possibly
resulting in a component of a dialog 1114
ID. The same tag MUST be used for all responses to that request, both
provisional and final. Procedures for 1115
generation of tags are defined in Section 21.3. 1116

> from this requirement. 

In the case of a UA, you are right. We have added text making the use of
a tag in 100 MAY.

However, having a proxy insert tags in 100 responses isn't helpful.
INteresting, I didn't find any text in the spec that helps understand
how that 100 is generated; the server transaction section simply says
that it should generate a 100 response, but doesn't reference the UA
section for how to do that. 

I will add a reference there, indicating that the exception is that a
tag SHOULD NOT be present (as opposed to MAY), as this would create a
needless early dialog.

> For example, in section 13.3.1.1, p. 49, it is

I see little harm in always having them established; this way, if the
UAC wants communications back towards the UAS, it can.

> responses, and this value should be the same for all responses generated

The scope is broader; the from tag should be unique across all calls,
not just within the same UA. That is, two calls from the same UA would
have different from tags. I can see why that is not sufficiently clear.
I will clarify that.

>   "... and the ACK for the response in the case the response was a

Yes, this was caught early as one of the more confusing typos in bis-05.

>   "Section 16 discusses proxy usage of CANCEL."

We've found that one already too, thanks.

>   "This state consists of the dialog ID, a local sequence number ..."

Right, good point. Fixed.

> CSeq number (not the method), and top Via header match ..."

Another one we caught early on, thanks.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[email-masked]                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com