I agree. I recognize the bug of # 769. I think that the draft should be modified to consider this problem. (However, I'm thinking about how to modify it.)
Miki Hasebe Paul Kyzivat <[EMAIL PROTECTED]> wrote: > 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
