Paul, This is a useful draft but is written around race conditions from Dialog State Machine (DSM) perspective. It talks about bug #769 and speaks to the behavior of TU if the bug is fixed or not but does not talk about the bug fix itself, which is the bug in Transaction State machine (TSM).
Is the fix for #769 in TSM described/discussed somewhere? Short of that is my explanation below on the right lines? That is enter "Finished" (or "Moratorium"), (I actually like "Quiescent state" term) when 2xx is sent and start a new timer. (Timer L) Perhaps the only question that is still unanswered is who retransmits the 2xx response in the "Moratorium" (or Finished/Quiescent) state. TU or Server Txn? (Now) I think it should be TU. The Server Txn should just pass the request to the TU as that would maintain the independence of transaction from TUs. The TU should retransmit the 2xx response and (perhaps) reset the 2xx retransmission timer back to T1 and overall timeout back to 64*T1 on receipt of INVITE retransmission. The timer in the "Moratorium state" (or "Finished"/"Quiescent" as I called it) say Timer L should be set to T4. When this timer expires then the Txn transitions to Terminated state and is destroyed. The 2xx retransmissions may continue up to 64*T1 time *after* the last INVITE (or its retransmission) was received. Is this the right fix? How have others fixed it? Thanks Nasir Discuss SIP Servlets at http://groups.google.com/group/sipservlets/ -----Original Message----- From: Paul Kyzivat [mailto:[EMAIL PROTECTED] Sent: Friday, May 25, 2007 12:07 PM To: Nasir Khan Cc: [email protected] Subject: Re: [Sip-implementors] Invite Server Transaction Bug 769 Nasir, The following should help you: http://www.ietf.org/internet-drafts/draft-ietf-sipping-race-examples-01. txt Paul Nasir Khan wrote: > With respect to the bug > > > > http://bugs.sipit.net/show_bug.cgi?id=769 > > > > <snip> > > > > The current text in 3261 instructs a UAS to destroy an INVITE > transaction the > > instant it sends a 200. > > > > This has the unintended consequence that any retransmissions of the > INVITE > > request that arrive after that destruction will be treated as a new > request. > > > > This interacts both with endpoints and proxies (the deletion of the > server > > transaction combined with stateless forwarding of responses without > matching > > transactions provided forwarding of multiple 200s to forked INVITES). > > > > The fix will involve having the server transaction continue to exist > long > > enough to drain any retransmissions of the INVITE and related changes to > > the UAS handling of retransmitting the 200s, and proxies handling > multiple > > 200s/stray responses. > > > > </snip> > > > > Is the fix defined somewhere? > > > > Would the fix just be creating a new state say "Finished" that is > entered when a 2xx response is sent and starts a new timer (Timer L > perhaps?) which similar to Timer I is set to T4 for unreliable > transports? > > > > Also if INVITE is retransmission is received in "Finished" state then > would the Transaction re-send last response (2xx) or hand over the > request to TU? I think it should re-send the last 2xx. > > > > ACK of course would not hit this transaction as it is an ACK for 2xx, > but the Finished->Terminated transition should happen only on Timer (L > ?) expiry. > > > > Can someone please comment on this? > > > > Also in the bug report there is a mention of "and related changes to > > the UAS handling of retransmitting the 200s, and proxies handling > multiple > > 200s/stray responses." > > > > Are these separate bugs? Is there any explanation of what is intended > here? > > > > Thanks > > Nasir > > > > Discuss SIP Servlets at http://groups.google.com/group/sipservlets/ > <http://groups.google.com/group/sipservlets/> > > > > > Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. > _______________________________________________ > Sip-implementors mailing list > [email protected] > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
