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
