Subject: Tag in 200 OK response for CANCEL

From: Sudipto Mukherjee <[email-masked]>
Date: Wed, 01 Mar 2000 17:01:09 -0500

I need a clarification about adding of tag in the To header of
200 OK response for CANCEL and BYE -

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

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

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

Thanks
- Sudipto

---

From: [email-masked]
Date: Thu, 2 Mar 2000 14:26:14 +0530

Hi,
Im a little confused here.
my understaning was that a UA receiving a message with more than one Via or
a mcast address in it MUST add a tag.
Even if say, A sent an INVITE to B thru some proxy P which forked, B now
gets the INVITE and puts a tag in its 200 OK since there are now 2 Vias. A
gets the 200 OK with the tag that B inserted. however A did not know of the
Tag when it sent it  .
However, this tagged response is the matching response for a request which
A sent which was not tagged by itself.
So isnt this scenario same as the case for subsequent requests with
messages sent without a tag ?

Now are we saying that the above specification of inserting tags by UAs
holds true only for the first transaction of a call leg and not any more ?

Regds
Arjun

--
Arjun Roychowdhury @ Hughes Software Systems

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

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