Subject: Questions on To tags (was Re: [Sipping] Comments on draft-ietf-sip-rfcbis-05.pdf)

From: Peter Päppinghaus <[email-masked]>
Date: Thu, 14 Feb 2002 16:35:53 +0100

Thanks for your responses, more comments inline
(note that I am now referencing bis-07).

Jonathan Rosenberg wrote:
> 
> Thanks for your comments. Responses inline.
> 
> Peter Päppinghaus wrote:

[snip]

> > 2) When does a provisional response need to have a tag added to the To
> > 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
> 
> >
> > 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.
> 
> 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
> > 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.
> 
> I see little harm in always having them established; this way, if the
> UAC wants communications back towards the UAS, it can.

For a UAC it's fine. However, I am involved in implementing a call 
stateful proxy. So what worries me is to avoid unnecessary load for a 
call stateful proxy. If there are many To tags around, a call stateful
proxy will have to maintain state for many early dialogs.

In particular, I have in mind the following situation.

Up to the bis-05 draft it was my understanding that a SIP proxy may also
act as follows: it forwards the request downstream AND generates a 
183 (Session Progress) response and sends it upstream. In this case the
proxy would not really be a communication end point for the signalling,
and in this case I feel it makes not so much sense to insert a tag into
the To header of this 183 response. This is the situation I am concerned
about, because it might happen very frequently on the signalling path.

Now the new wording (bis-07) in section 16.6 (Response Processing), 
step 6 (Choosing the best response) seems to imply that this situation 
is not supposed to occur. Quotation from lines 2811-2812 of bis-07:

"Since a proxy may not insert a tag into the To header field of a 
1xx response to a request that did not contain one, 
it cannot issue non-100 provisional responses on its own."

The explanations following immediately (lines 2812-2816), however, 
seem to revoke lines 2811-2812 in a very subtle way. 

Does this mean that a proxy, if it wants to forward the request AND 
generate a 183 response to it, has to act as a forking proxy, forward
the request to its destination AND to a "virtual UAS" within itself,
including the insertion of a new Via header with branch parameter 
into both forked requests? 
This seems like a clumsy way to allow a proxy to send a provisional 
non-100 response upstream.

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

In bis-07, section 23.3, lines 4896-4897, now in fact say:
"Similarly, two INVITEs for different calls will have different From
tags."

This really surprises me for two reasons. 

Firstly, if the From tag has to be unique across all calls, then it 
uniquely identifies a call, so what would the Call-ID be needed for?

Secondly, if the tags were to uniquely identify a request-generating
resp. a response-generating SIP entity, and the same tags were to be
used for all requests resp. responses generated by the same SIP entity,
this would give additional information (identification of requester
resp. responder across calls).

Regards, Peter P.

-- 
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, 17 Feb 2002 00:16:29 -0500

Peter Päppinghaus wrote:

> about, because it might happen very frequently on the signalling path.

Well, the problem is, there is no reason for the proxy to generate this
provisional response. It can, but I would hardly think it a common
occurrence.

> non-100 response upstream.

The specification does not mandate an implementation architecture, it
merely describes behavior. The point of this missive is to explain how a
proxy, which is a LOGICAL element which does not participate in dialogs,
would appear to issue a provisional response which establishes a dialog.
I would be shocked if anyone actually implemented it in the way
discussed above.

> uniquely identifies a call, so what would the Call-ID be needed for?

If we were able to start SIP from scratch, I would probably agree that
the Call-ID and from tag are redundant. But, we can't. So, the real
question is this - given we have a unique call-id, and that people have
been putting them in that way, and relying on their uniqueness, is there
also a need for the from tag/to tag to be unique?

There, there answer is in fact yes, but for subtle reasons. Certainly,
the to tag in a response needs to be unique. What you really, really
need is for both participants in the dialog to contribute unique
identifiers, such that the combination of the two are the dialog ID. So,
the to tag has to be unique, OK. Now, in requests in the reverse
direction that the dialog was established, the To and From field values
are reversed. This means that what was in the From in the initial
request, is now in the To, and vice a versa. This means that elements
which might like to take advantage of the fact that the to tag is
unique, really cannot, since it wouldn't be in the reverse direction
unless the from tag in the original request was also unique. And thus
the requirement for unique from tags as well.

So, simply put, the from tag is unique to provide symmetry wiht the to
tag, which must be unique.

> resp. responder across calls).

I cannot parse this sentence.

-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

---

From: Peter Päppinghaus <[email-masked]>
Date: Tue, 19 Feb 2002 09:25:51 +0100

I realize the incredible workload you are taking, and I really don't 
want to abuse your precious time. But could you help me to understand 
why I am mistaken in my inline comment below? Sorry for this.

Peter P.

Jonathan Rosenberg wrote:
> identifiers, such that the combination of the two are the dialog ID. 

According to my understanding, what you really, really need is for 
both participants in the dialog to contribute unique identifiers, 
such that the combination of the two *together with the Call-ID*  
are the dialog ID. 

And if all of the following hold:

1) the From tag uniquely identifies a UAC (unique in space and role 
   as a request-issuing entity),

2) the To tag uniquely identifies a UAS (unique in space and role 
   as a response-issuing entity),

3) the Call-ID used for the request is unique "over time", i.e. as
   a minimal requirement: the same UAC ("same" as identified by 
   the From tag) never issues another dialog-initiating request 
   with the same Call-ID value,

then the dialog ID consisting of Call-ID, From tag, and To tag,
will uniquely identify a dialog, won't it?

> So, the to tag has to be unique, OK. Now, in requests in the reverse