Subject: Re: Tag in 200 OK response for CANCEL

From: [email-masked]
Date: Thu, 2 Mar 2000 09:46:43 +0530

sm> A UAS receives a CANCEL request for a pending INVITE transaction.
sm>  If the "To" header in the INVITE and the subsequent CANCEL did
sm> *not* have a tag in the To header, does the UAS add a tag in
sm> the "To" header of the 200 OK response for the CANCEL?

Yes, I think it should as this CANCEL might have been forked some where in
between.Also, this would serve as a match mechanism for the UAS for future
forked requests it received.

sm> Sec 6.38 To, of the SIP specs says -
sm> The "tag" must be added for all definitive responses for all methods
sm> and MAY be added for informational responses for a UAS or RS."

sm> Also, does a UAC receiving a BYE (Called Party Release) need to add
sm> a tag in the "To" header of the 200 OK response ? The From header
sm> in BYE has a tag but there is *no* tag in the To header.

Yes, again I think it should. A "tag" in the From field is used if multiple
callers use the same From address. This has nothing to do with forking of
messages by proxies as such.

Regds
Arjun

--
Arjun Roychowdhury @ Hughes Software Systems

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 02 Mar 2000 00:34:54 -0500

> forked requests it received.

No, I disagree. Tags are for the purpose of allowing the UAC to
disambiguate responses to a forked request. CANCEL is unlike other
requests in that its responses are absorbed at each hop. Thus, even if
the UAS inserted a tag into the 200 OK to CANCEL, this tag would never
be seen by any entity besides the previous hop - probably a proxy. Note
also that a UAC will never receive more than a single 200 OK to a
CANCEL, so the tag for disambiguation is useless.

> messages by proxies as such.

I disagree here as well. The local and remote addresses (obtained from
the To and From fields, including the tags) that identify the call leg
are established upon call setup, and remain fixed for the duration of
the call leg. Adding a tag in a subsequent request (BYE or re-INVITE) is
going to alter this identifier and likely cause one side or the other to
not be able to match requests or responses to a particular call leg.

-Jonathan R.
-- 
Jonathan D. Rosenberg                       200 Executive Drive
Chief Scientist                             Suite 120 
dynamicsoft                                 West Orange, NJ 07052
[email-masked]                     FAX:   (732) 741-4778
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com

---

From: Shail Bhatnagar <[email-masked]>
Date: Thu, 02 Mar 2000 13:19:23 -0500

Then the following lines should be deleted/appropriately modified in the spec :

"The "tag" is added for all definitive responses for all methods, and MAY be
added for informational responses from a UAS or redirect server."

Thanks,
Shail

Jonathan Rosenberg wrote:

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 02 Mar 2000 13:54:33 -0500

This clearer?

A UAS or redirect server {\MUST} add a ``\header{tag}'' parameter for
all final responses for all transactions within a call leg. All such
parameters have the same value within the same call leg. These
servers {\MAY} add the \header{tag} for informational responses during
the initial {\INVITE} transaction, but {\MUST} add a tag to
informational responses for all subsequent transactions.

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs