Hi, My experience from the previous SIPit is that the "To-tag in CANCEL" is a relatively common issue (we're not talking about a single implementation here), so I think it's good that it is brought up here on the list.
Regards, Christer Holmberg Ericsson Finland Christian Stredicke wrote: > There is no To-tag in CANCEL requests. The RFC describes very well how > the CANCEL is to be constructed. Sure, the UAS adds a tag; but not the > UAC when sending CANCEL. > > In case someone uses an old version of snom 100, there was a BUG which > sent a To-tag. This has been fixed months ago. If you are using snom > 100, please update. > > Christian > -- > sip:[EMAIL PROTECTED] > > > From: "Dong, Hwan" <[EMAIL PROTECTED]> > > To: [EMAIL PROTECTED] > > Date: Fri, 18 Oct 2002 15:39:49 -0700 > > 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. > > > > > > 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? > > > > 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. > > > > 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? > > > > Thanks for your help, > > Hwan > > > > > > > > > > --__--__-- > > > > Message: 4 > > From: "manoj mallik" <[EMAIL PROTECTED]> > > To: "Dong, Hwan" <[EMAIL PROTECTED]>, > <[EMAIL PROTECTED]> > > Subject: RE: [Sip-implementors] 2 questions on toTag in 200-for-CANCEL > > Date: Fri, 18 Oct 2002 18:18:23 -0500 > > > > 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 > > > > > > --__--__-- > > > > Message: 5 > > From: "Janarthanan, Bhagatram" <[EMAIL PROTECTED]> > > To: [EMAIL PROTECTED] > > Date: Fri, 18 Oct 2002 19:49:13 -0700 > > Subject: [Sip-implementors] Qn in transaction stateful Proxy (merge) > > > > Hi , > > I have a question in transaction stateful proxy. > > > > Let us say that the network happens to be as follows in this partiular > > case > > > > > > UaC->-P1->-P2->-P5->-P6->-UaS > > | | > > | | > > |->-P3->---| > > | | > > | | > > |->-P4->---| > > > > > > An INV message from UaC goes to P1. P1 forks it and sends it to P2, P3 > and > > P4. Now, lets us say that all the three proxies P2, P3 and P4 forward > it > > to > > P5. Now, question is, when one looks at it from P5, wouldnt all the > three > > INVITE look the same. Or is it requred by P2, P3, P4 to introduce a > > branch > > parameter as they forward the request across. (Since we look only at > the > > topmost "Via" header). > > > > Thanks > > Bhagat > > > > --__--__-- > > > > Message: 6 > > From: [EMAIL PROTECTED] > > To: "Janarthanan, Bhagatram" <[EMAIL PROTECTED]> > > cc: [EMAIL PROTECTED] > > Date: Sat, 19 Oct 2002 10:41:38 +0530 > > Subject: Re: [Sip-implementors] Qn in transaction stateful Proxy > (merge) > > > > > > > > Hi, > > This kind of request merging needs to be handled by the UA and not > the > > proxy. The proxy will still forward all the requests to the UA. > > The UA processes the first such request and responds with a 482 loop > > detected > > for subsequent requests. > > You may refer to Section 8.2.2.2 Merged Requests of RFC 3261. > > > > Rgds > > Seshu > > ------------------------------- > > http://www.hssworld.com > > > > > > > > > > > > "Janarthanan, Bhagatram" <[EMAIL PROTECTED]> on > 10/19/2002 > > 09:19:13 AM > > > > To: [EMAIL PROTECTED] > > cc: (bcc: Seshashayi T/HSSBLR) > > > > Subject: [Sip-implementors] Qn in transaction stateful Proxy (merge) > > > > > > > > > > Hi , > > I have a question in transaction stateful proxy. > > > > Let us say that the network happens to be as follows in this partiular > > case > > > > > > UaC->-P1->-P2->-P5->-P6->-UaS > > | | > > | | > > |->-P3->---| > > | | > > | | > > |->-P4->---| > > > > > > An INV message from UaC goes to P1. P1 forks it and sends it to P2, P3 > and > > P4. Now, lets us say that all the three proxies P2, P3 and P4 forward > it > > to > > P5. Now, question is, when one looks at it from P5, wouldnt all the > three > > INVITE look the same. Or is it requred by P2, P3, P4 to introduce a > > branch > > parameter as they forward the request across. (Since we look only at > the > > topmost "Via" header). > > > > Thanks > > Bhagat > > _______________________________________________ > > Sip-implementors mailing list > > [EMAIL PROTECTED] > > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > > > > > > > > > > > > --__--__-- > > > > Message: 7 > > Reply-To: <[EMAIL PROTECTED]> > > From: "Badri Srinivasan S" <[EMAIL PROTECTED]> > > To: "Sip-Implementors" <[EMAIL PROTECTED]> > > Date: Sat, 19 Oct 2002 18:39:51 +0530 > > Subject: [Sip-implementors] Stateless UAS... > > > > Hi All: > > > > The RFC 3261 quotes---> > > > > "A UAS cannot be stateless unless the request processing for that > > method > > would always result > > in the same response if the requests are identical." > > > > In the case of a UAS acting in a stateless manner when it challenges > > requests ( by sending a > > 401 UnAtuhorized Rsp ), it includes a nonce value in the rsp. This > nonce > > value is generated > > using the time stamp as one of the parameters for the MD5 hash. So > when a > > ReTx of a request > > comes at such an UAS (which is acting stateless) it will generate a > > different nonce value as > > from the previous rsp. > > > > Such an UAS cannot be considered stateless according to the RFC. But > > generating the same > > nonce everytime when the ReTx comes makes the UAS vulnerable to Replay > > attacks. > > > > Is genrating a different nonce in the rsp for each ReTx of the > request, > > allowed for a Stateless UAS..? > > > > Thanks, > > Badri > > > > > > Badri Srinivasan S > > Networking Technology Labs, > > HCL Technologies, > > No.184 to 188, 190, 192 & 196 > > NSK Road ( Arcot Road ) > > Vadapalani, Chennai- - 600 026 > > > > ph: +91-44-372 8366 Extn: 1133 > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > The highest reward for a person's toil > > is NOT what he gets for it but what he > > BECOMES by it. > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > > > > > --__--__-- > > > > _______________________________________________ > > Sip-implementors mailing list > > [EMAIL PROTECTED] > > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > > > > > > End of Sip-implementors Digest > > _______________________________________________ > 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
