Rajnish, I don't disagree with your solutions, in fact I ended up with the same approach.
Truth is: it shouldn't matter whether the CANCEL receives a 200 or 487 response. "to BYE or not to BYE, that is the question..." - and the answer should be based solely on the INVITE response. Do you agree on this? Regards, Jeroen ----- Original Message ----- From: "Rajnish Jain" <[EMAIL PROTECTED]> To: "'Jeroen van Bemmel'" <[EMAIL PROTECTED]>; "'Paul Kyzivat'" <[EMAIL PROTECTED]>; "'Venkatesh'" <[EMAIL PROTECTED]> Cc: <[email protected]>; <[EMAIL PROTECTED]> Sent: Friday, May 19, 2006 3:49 PM Subject: RE: [Sip-implementors]Question regardingdraft-hasebe-sipping-exceptional-procedure-examples-02. > Jeroen, > > I don't think there is anything wrong with pending-termination > transactions. > This is why transaction finite state machine has multiple states. Today > the > transaction matching rule abstracts this state machine as a binary > decision > (i.e. transaction exists or does not exist). I think that assumption may > hold true anymore given things such as bug # 769. I think if we made the > transaction matching rule a bit more intelligent then we can fix bug # 769 > without causing a ripple effect. I still think CANCEL should receive a > 487. > > I wish bug # 769 had simply stated the bug instead of hinting on a > solution, > because that solution is not fully thought out. Clearly, extending the > duration of INVITE-2XX server transactions has other (undesired) > implications. So far, I've experimented two ways of fixing bug # 769: > > 1. By extending the duration of INVITE-2XX transaction but purely for the > purpose of absorbing the INVITE retransmissions. As I said before, I > excluded CANCEL from matching such transactions and maintained 2XX/ACK > retransmission logic at the TU Core. > > 2. By keeping the transaction layer intact, but by handling INVITE > retransmissions at the TU Core using half-dialog matching. Every time I > receive a new INVITE at the TU Core, I assume that bug #769 condition has > happened and I match it against all ongoing dialogs. If there is a match > and > the Cseq hasn't incremented, I call it a retransmission and handle it > accordingly. > > Both solutions have worked well for me in practice. In fact, I've put both > of them in together because solution #1 will not catch a particular race > condition (when INVITE retransmission is delayed by the network and comes > after the ACK when the transport is UDP). #2 catches this condition. > > Rajnish > > > > -----Original Message----- > From: Jeroen van Bemmel [mailto:[EMAIL PROTECTED] > Sent: Friday, May 19, 2006 9:21 AM > To: Rajnish Jain; 'Paul Kyzivat'; 'Venkatesh' > Cc: [email protected]; [EMAIL PROTECTED] > Subject: Re: [Sip-implementors]Question > regardingdraft-hasebe-sipping-exceptional-procedure-examples-02. > > Rajnish, > > It should receive a 200 because we wouldn't want transactions that are > "kind > of existing". I agree that the INVITE example I gave should not happen in > practice, but from a protocol purist perspective it is bad. > > Receiving a 200 to CANCEL does not imply that you will receive a 487 for > the > INVITE. It may be that the UAS already sent a final error response. In > such > a case, the UAC should not send a BYE; it should wait for the final error > response. > > In other words: the UAC should never base its decision to send BYE on the > CANCEL response, but always on the INVITE response. > > Regards, > > Jeroen > > > ----- Original Message ----- > From: "Rajnish Jain" <[EMAIL PROTECTED]> > To: "'Jeroen van Bemmel'" <[EMAIL PROTECTED]>; "'Paul Kyzivat'" > <[EMAIL PROTECTED]>; "'Venkatesh'" <[EMAIL PROTECTED]> > Cc: <[email protected]>; <[EMAIL PROTECTED]> > Sent: Friday, May 19, 2006 2:58 PM > Subject: RE: [Sip-implementors]Question > regardingdraft-hasebe-sipping-exceptional-procedure-examples-02. > > >> Maybe I'm missing something, but why should CANCEL receive a 200 in >> this case? >> >> If the CANCEL were to receive a 200, that would mean that the INVITE >> will soon receive a 487. Clearly, that's not possible because the >> INVITE has already generated a final response (200). On the other >> hand, if the CANCEL were to receive a 481, then the UAC will know that >> it lost the race and if it is still interested in tearing down the call >> it > should send a BYE. >> >> Any subsequent new INVITE should have a different Call-Id and From tag. >> >> Rajnish >> >> >> -----Original Message----- >> From: Jeroen van Bemmel [mailto:[EMAIL PROTECTED] >> Sent: Friday, May 19, 2006 5:49 AM >> To: Rajnish Jain; 'Paul Kyzivat'; 'Venkatesh' >> Cc: [email protected]; [EMAIL PROTECTED] >> Subject: Re: [Sip-implementors]Question >> regardingdraft-hasebe-sipping-exceptional-procedure-examples-02. >> >> 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.tx >> t >> 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
