Rajnish, It should receive a 200 because we wouldn't want transactions that are "kind of existing". I agree that the INVITE example I gave should not happen in practice, but from a protocol purist perspective it is bad.
Receiving a 200 to CANCEL does not imply that you will receive a 487 for the INVITE. It may be that the UAS already sent a final error response. In such a case, the UAC should not send a BYE; it should wait for the final error response. In other words: the UAC should never base its decision to send BYE on the CANCEL response, but always on the INVITE response. Regards, Jeroen ----- Original Message ----- From: "Rajnish Jain" <[EMAIL PROTECTED]> To: "'Jeroen van Bemmel'" <[EMAIL PROTECTED]>; "'Paul Kyzivat'" <[EMAIL PROTECTED]>; "'Venkatesh'" <[EMAIL PROTECTED]> Cc: <[email protected]>; <[EMAIL PROTECTED]> Sent: Friday, May 19, 2006 2:58 PM Subject: RE: [Sip-implementors]Question regardingdraft-hasebe-sipping-exceptional-procedure-examples-02. > Maybe I'm missing something, but why should CANCEL receive a 200 in this > case? > > If the CANCEL were to receive a 200, that would mean that the INVITE will > soon receive a 487. Clearly, that's not possible because the INVITE has > already generated a final response (200). On the other hand, if the CANCEL > were to receive a 481, then the UAC will know that it lost the race and if > it is still interested in tearing down the call it should send a BYE. > > Any subsequent new INVITE should have a different Call-Id and From tag. > > Rajnish > > > -----Original Message----- > From: Jeroen van Bemmel [mailto:[EMAIL PROTECTED] > Sent: Friday, May 19, 2006 5:49 AM > To: Rajnish Jain; 'Paul Kyzivat'; 'Venkatesh' > Cc: [email protected]; [EMAIL PROTECTED] > Subject: Re: [Sip-implementors]Question > regardingdraft-hasebe-sipping-exceptional-procedure-examples-02. > > No, the CANCEL should receive a 200 OK response > > If a 481 response is returned, the sender of the CANCEL may assume that a > subsequent INVITE with the same from-tag and call-id will create a new > dialog. However, that is not the case since the terminate-pending INVITE > ServerTransaction will absorb it. In other words, sending 481 would result > in an inconsistent view on the UAS state. > > http://www.ietf.org/internet-drafts/draft-hasebe-sipping-race-examples-00.tx > t > 3.1.2 currently shows what would happen without the bugfix (i.e. 481). > With > the bugfix, the transaction would still be there, but since the UAS has > already sent a final response the CANCEL will have no effect on either the > original INVITE request or the dialog (same as without the bugfix). > > In either case (i.e. 481 or 200 response to CANCEL), the calling UAC > should > send a BYE. This would be triggered by an incoming 200 OK to INVITE and > some > local dialog flag 'canceled', and would not depend on the CANCEL response > > Regards, > > Jeroen > > PS This truely appears to be "future work", given that the draft is dated > "Aug 27th, 2006"... > > ----- Original Message ----- > From: "Rajnish Jain" <[EMAIL PROTECTED]> > To: "'Paul Kyzivat'" <[EMAIL PROTECTED]>; "'Venkatesh'" > <[EMAIL PROTECTED]> > Cc: <[email protected]>; <[EMAIL PROTECTED]> > Sent: Friday, May 19, 2006 10:11 AM > Subject: Re: [Sip-implementors]Question > regardingdraft-hasebe-sipping-exceptional-procedure-examples-02. > > >> While bug # 769 suggests that an INVITE UAS transaction shouldn't be >> destroyed on sending a 2XX, that doesn't necessarily mean that such >> transactions need to be taken into account for CANCEL-INVITE correlation. >> I >> would imagine the BCP will add a new state (say 'Pending Termination') >> in the INVITE UAS transaction state machine for transactions that have >> sent a 2XX but are still there to absorb INVITE retransmissions. For >> all other intents and purposes these transactions are terminated. >> >> The BCP can probably suggest a slight modification in the >> CANCEL-INVITE transaction matching rule. That is, INVITE UAS >> transactions in the 'Pending Termination' state MUST be excluded from >> transaction matching when a CANCEL request is received (the same >> argument can be applied for the inbound ACK message). This way the >> CANCEL in draft-hasebe-sipping-race-examples >> section >> 3.1.2 would correctly fetch a 481 and we would have also fixed bug # 769. >> >> Rajnish >> >> >> -----Original Message----- >> From: [EMAIL PROTECTED] >> [mailto:[EMAIL PROTECTED] On Behalf Of Paul >> Kyzivat >> Sent: Thursday, May 18, 2006 6:42 PM >> To: Venkatesh >> Cc: [email protected]; [EMAIL PROTECTED] >> Subject: Re: [Sip-implementors]Question >> regardingdraft-hasebe-sipping-exceptional-procedure-examples-02. >> >> Because this is a bug where the fix hasn't been formally fixed, I >> don't think it is safe to assume *either* that it has been fixed or it > hasn't. >> So I think a BCP should allow both, with an explanation. >> >> Paul >> >> Venkatesh wrote: >>> I am not sure if that is a reasonable argument. This behavior has >>> been acknowledged as a bug in the RFC 3261. The bug detailes what the >>> fix for the same is going to be. I assume that this change in >>> behavior will make it into a RFC sometime in future. Not sure an >>> example draft that contradicts this behavior is a good idea. >>> >>> For this specific scenario under consideration the far end is going >>> to get a 200 OK for the CANCEL (instead of a 481 response). It is >>> still going to have to complete the INVITE transaction and tear down >>> the call >> with a BYE. >>> >>> Venkatesh >>> >>> >>> On 5/18/06, Frank Shearar <[EMAIL PROTECTED]> wrote: >>>> Sure, I agree that there's an open bug. Nonetheless, if you write a >>>> stack to fix the bug, then your stack isn't quite RFC 3261 compliant >>>> anymore. UACs that expect you to follow the RFC will then be >>>> surprised. (Caveat: I've not thought through what cases might lead >>>> to unexpected behaviour.) >>>> >>>> frank >>>> >>>> ----- Original Message ----- >>>> From: "Venkatesh" <[EMAIL PROTECTED]> >>>> To: "Frank Shearar" <[EMAIL PROTECTED]> >>>> Cc: <[email protected]> >>>> Sent: Thursday, May 18, 2006 4:26 PM >>>> Subject: Re: [Sip-implementors] Question >>>> regardingdraft-hasebe-sipping-exceptional-procedure-examples-02. >>>> >>>> >>>> I meant the UAS is not supposed to terminate the INVITE transaction >>>> on sending a 200 OK response for the INVITE. >>>> >>>> On 5/18/06, Venkatesh <[EMAIL PROTECTED]> wrote: >>>>> Please refer to the bug I referred to in my previous email that is >>>>> open against RFC 3261. It clearly indicates that the UAS is not >>>>> supposed to terminate the INVITE transaction on sending a 200 OK >>>>> response for the response. If this were indeed to be the case, the >>>>> UAS will still find >>>> the >>>>> INVITE transaction and that is my point. >>>>> >>>>> Venkatesh >>>>> >>>>> >>>>> On 5/18/06, Frank Shearar <[EMAIL PROTECTED]> wrote: >>>>>> "Venkatesh" <[EMAIL PROTECTED]> wrote: >>>>>> >>>>>> >>>>>>> Section 2.1 of this draft illustrates a scenario where by a >>>>>>> CANCEL >>>> and >>>>>> a >>>>>> 200 >>>>>>> OK for the INVITE cross the wire. The draft suggests rejecting >>>>>>> the >>>>>> CANCEL >>>>>>> with a 481 final response. I am not sure this is correct behavior. >>>> The >>>>>> UAS >>>>>>> must send a 200 OK for the CANCEL request (as it would find the >>>> INVITE >>>>>>> transaction). INVITE transacations are not supposed to be >>>>>>> destroyed >>>>>> when a >>>>>>> 200 OK response for the INVITE is sent by the UAS. I believe >>>>>>> there >>>> is >>>>>> a >>>>>> bug >>>>>>> open against RFC 3261 for the same ( >>>>>>> http://bugs.sipit.net/show_bug.cgi?id=769) >>>>>> RFC section 9.2 says regarding a UAS processing a CANCEL request >>>>>> >>>>>> If the UAS did not find a matching transaction for the CANCEL >>>>>> according to the procedure above, it SHOULD respond to the CANCEL >>>>>> with a 481 (Call Leg/Transaction Does Not Exist). >>>>>> >>>>>> In Hasebe et al's draft(*), Bob's 200 OK terminates his INVITE >>>>>> transaction. >>>>>> As a result, when Alice's CANCEL arrives, Bob cannot match the >>>>>> CANCEL against a transaction, so must return a 481. >>>>>> >>>>>> (*) The draft's name has changed to >>>> draft-hasebe-sipping-race-examples, >>>>>> and >>>>>> in the new draft this scenario is in section 3.1.2. >>>>>> >>>>>> frank >>>>>> >>>>>> _______________________________________________ >>>>>> Sip-implementors mailing list >>>>>> [email protected] >>>>>> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors >>>>>> >>>>> >>>> _______________________________________________ >>>> Sip-implementors mailing list >>>> [email protected] >>>> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors >>>> >>> _______________________________________________ >>> Sip-implementors mailing list >>> [email protected] >>> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors >>> >> _______________________________________________ >> Sip-implementors mailing list >> [email protected] >> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors >> >> _______________________________________________ >> Sip-implementors mailing list >> [email protected] >> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
