Venkatesh, Okay. I agree with you 100%. I went and reread the following paragraphs from section 9.2 in RFC 3261. I agree that sending a 200 for the CANCEL is probably the best thing to do if bug # 769 is going to resolved that way.
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). If the transaction for the original request still exists, the behavior of the UAS on receiving a CANCEL request depends on whether it has already sent a final response for the original request. If it has, the CANCEL request has no effect on the processing of the original request, no effect on any session state, and no effect on the responses generated for the original request. If the UAS has not issued a final response for the original request, its behavior depends on the method of the original request. If the original request was an INVITE, the UAS SHOULD immediately respond to the INVITE with a 487 (Request Terminated). A CANCEL request has no impact on the processing of transactions with any other method defined in this specification. Regardless of the method of the original request, as long as the CANCEL matched an existing transaction, the UAS answers the CANCEL request itself with a 200 (OK) response. This response is constructed following the procedures described in Section 8.2.6 noting that the To tag of the response to the CANCEL and the To tag in the response to the original request SHOULD be the same. The response to CANCEL is passed to the server transaction for transmission. Thanks, Rajnish ________________________________ From: Venkatesh [mailto:[EMAIL PROTECTED] Sent: Friday, May 19, 2006 1:07 PM To: Rajnish Jain Cc: Jeroen van Bemmel; Paul Kyzivat; [email protected]; [EMAIL PROTECTED] Subject: Re: [Sip-implementors]Question regardingdraft-hasebe-sipping-exceptional-procedure-examples-02. Rajnish: Your reasoning below is flawed. CANCEL is a hop to hop request. A 2xx response to a CANCEL only indicates that the next hop has seen your request. It knows about the transaction you want to CANCEL and has accepted the request to CANCEL the previous transaction. It doesn't mean that the UAS (called party) has seen the CANCEL request and accepted to process the request. Thus attempting to deduce anything about the pending INVITE transaction using response to CANCEL is totally flawed. You have to wait for the final response to the INVITE transaction to decide what to do with it. Having said that, the only purpose CANCEL response serves is to let the UAC know if the transction identified in the CANCEL is a transaction that the next hop knows. A 2xx response indicates that the transaction identifiers in the CANCEL request match an previous transaction and the request will be processed by the *next* hop. A 481 response indicates that the transaction identifiers are invalid and will not be processed by your *next* hop. Beyond that there is no significance for this response. It says nothing about the final called party (meaning B's UAS in case where A calls B). Given the above, for the scenario under consideration a 2xx response for the CANCEL makes sense as the INVITE transaction would still be *alive* if the changes proposed in bug 769 is incorporated. Thanks Venkatesh On 5/19/06, Rajnish Jain <[EMAIL PROTECTED]> wrote: A couple of typos in my previous email (481 and 200 mentioned incorrectly). Corrected them below ... 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 481. When the CANCEL fetches a 481, 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 200, 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] <mailto:[EMAIL PROTECTED]> > To: "'Jeroen van Bemmel'" <[EMAIL PROTECTED]>; "'Paul Kyzivat'" <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> >; "'Venkatesh'" <[EMAIL PROTECTED]> Cc: <[email protected]>; < [EMAIL PROTECTED] <mailto:[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] <mailto:[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] <mailto:[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] <mailto:[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] <mailto:[EMAIL PROTECTED]> ] On Behalf Of Paul >>> Kyzivat >>> Sent: Thursday, May 18, 2006 6:42 PM >>> To: Venkatesh >>> Cc: [email protected] <mailto:[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] <mailto:[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] <mailto:[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
