A CANCEL request will have a To tag if the INVITE request being cancelled had a to-tag (e.g. a re-INVITE on an existing dialog). Section 9.1 of RFC 3261 states:
The Request-URI, Call-ID, To, the numeric part of CSeq, and From header fields in the CANCEL request MUST be identical to those in the request being cancelled, including tags. If the CANCEL did have a to-tag, the same to-tag is used the CANCEL response. When the CANCEL request does not have a to-tag, the to-tag in the CANCEL does not have to match a to-tag in a previous 1xx response (there may be 1xx responses from multiple UASs). Since CANCEL is hop-by-hop, any proxy in between is a UAS for the CANCEL transaction and would generate its own to-tag in its response. cheers, (-:bob ----- Original Message ----- From: "manoj mallik" <[EMAIL PROTECTED]> To: "Dong, Hwan" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Friday, October 18, 2002 7:18 PM Subject: RE: [Sip-implementors] 2 questions on toTag in 200-for-CANCEL > Hello Hawn, > pl. check the replies inline. > > Thanks, > Manoj > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:sip-implementors-admin@;cs.columbia.edu]On Behalf Of Dong, Hwan > Sent: Friday, October 18, 2002 5:40 PM > To: [EMAIL PROTECTED] > Subject: [Sip-implementors] 2 questions on toTag in 200-for-CANCEL > > > Hi, > > First, I have some doubt on the sequence of Section 3.8 of > draft-ietf-sipping-basic-call-flows-01.txt: > > User A issues a CANCEL (F9) without To tag, and receives 200-CAN response > (F10) from Proxy 1. There is no To tag in the 200-CAN. > > But there is different specification in 3261, section 9.2: > "... The UAS answers the CANCEL request itself with a 200 (OK) response. > This response is constructed following the procedures described in Section > 8.2.6 ..." > And in Section 8.2.6.2 says: > "... However, if the To header field in the request did not contain a tag, > the URI in the To header field in the response MUST equal the URI in the To > header field; additionally, the UAS MUST add a tag to the To header field in > the response..." > > It seems 3261 mandates toTag in 200-CAN. > > Manoj>> Yes, the 200-OK(CANCEL) MUST contain To tag and this MUST be same as > the To Tag in 1xx-Response to INVITE. In that Call Flow doc, it was a flaw > and I belive Alan has already confirmed that. > > Second, in section 9.2: > "the UAS answers the CANCEL request itself with a 200 (OK) response. This > response is constructed following the procedures described in Section 8.2.6 > noting that the To tag of the response to the CANCEL and the To tag in the > response to the original request SHOULD be the same. " > > So it is saying at UAS, the toTag in CANCEL should be same as that in > earlier 1xx, right? > > Manoj>> No. there should not be any To-tag in CANCEL, the above lines are > sayiong about the To tag in the Respone to the CANCEL. There must be To-tag > in 200-OK(CANCEL) and must be same as the To Tag in 1xx-Response to INVITE. > if u will refer RFC-3261, section 9.1: it says > "The following procedures are used to construct a CANCEL request. The > Request-URI, Call-ID, To, the numeric part of CSeq, and From header > fields in the CANCEL request MUST be identical to those in the > request being cancelled, including tags....." > So since intial INVITE never contains a To tag, therefore CANCEL will not > contain To Tag. > > > But how about stateful PROXY, proxy may not remember/keep the toTag in > earlier 1xx, so proxy may have to generate a new toTag for 200-CAN, which > would be different from toTag in 1xx. > > Manoj>> since it is a stateful proxy, it should remember the To tag in 1xx > and MUST use the same in 200-OK(CANCEL) > > toTag is used to identify a dialog, however. Shouldn't the toTag in one > dialog cycle be SAME? Otherwise, what is the purpose of toTag in 200-CAN? > > Manoj>> Yes, the To tag of 200-OK(CANCEL)is of course same as in 1xx. > > Thanks for your help, > Hwan > > > > _______________________________________________ > Sip-implementors mailing list > [EMAIL PROTECTED] > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > > _______________________________________________ > Sip-implementors mailing list > [EMAIL PROTECTED] > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
