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
