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
