Jeroen, I think "to BYE or not to BYE" is really based on the policy implemented in the UAC, but that question only comes in picture if the CANCEL received a 200. When the CANCEL fetches a 200, then all that means is that the UAC wasn't quick enough to terminate a proceeding call. The call has now been accepted and CANCEL is history. The UAC MAY or MAY NOT send a BYE at this point. It is based on the policy implemented in the UAC. I agree that most UACs will send a BYE, but that is because their implementers decided to do so to mimic our experience with PSTN. The protocol did not necessitate them to do so. An implementation can let a human user make that decision. As a theoretical example, if the caller is going to get billed anyway (say for atleast 3 minutes, a typical rounding period implemented in billing applications) the caller may just as well decide to talk to the called party.
On the other hand, if the CANCEL fetches a 481, then that means the UAC made it in time. The UAS is now working on tearing down the call. No further action from the UAC is needed. The UAC will receive a 487 for the INVITE (in case, the UAS is RFC 2543 compliant UAC will need to terminate the INVITE transaction on its own after 64*T1). There is no BYE whatsoever in this scenario. The "to BYE or not to BYE" question does not arise here. So, there is a huge difference between CANCEL returning a 200 versus 481. That is why I think the race condition in draft-hasebe section 3.1.2 should continue to have a 481 response for CANCEL regardless of how we fix RFC 3261 bug # 769. Rajnish -----Original Message----- From: Jeroen van Bemmel [mailto:[EMAIL PROTECTED] Sent: Friday, May 19, 2006 10:47 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, 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-example >> s >> -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-implementor >>>>>>> s >>>>>>> >>>>>> >>>>> _______________________________________________ >>>>> 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
