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
