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