Understood -- I think I can fairly easily update the sipXtapi unit tests to cover these cases. The delayed BYE will be a little tricky, but should be doable.
On Thursday, August 17, 2006, 2:36:44 PM, Andy Spitzer wrote: > Woof! > On Thu, 17 Aug 2006 13:55:47 -0400, Bob Andreasen <[EMAIL PROTECTED]> > wrote: >> Have you verified that the call has been completely dropped and >> deleted afterwards? Not just sending the BYE? > Nope. I just verified that the 200 OK was now getting futher than it did > before, and that doing so caused sipXtapi to send an ACK, then a BYE. I > did nothing to verify the internal correctness of the other layers. I was > hoping those of you who understand this better would help in that regard. >> My fear is/was that, we are going to processing the invite response, >> change state in the SipConnection and then the dropIfDead function >> within CpPeerCall would never match and we will never free up the >> call. > I am not qualified to comment on this at all. I find the whole thing > rather opaque, and am appealing to you and the community to help find the > "right" thing to do. My current problem is that after calling > sipxCallDestroy(), the sipXtapi side and the far end being called may end > up disagreeing on the call state. The sipXtapi side thinks the call is > destroyed, and the far end thinks the call was answered. >> I don't understand the what is detecting the race and then whacking >> the call. Is that your application or call processing? > The application is "whacking" the call by calling sipxCallDestroy(). > Here is the call flow: > An outbound call is generated: > sipxCallCreate() > sipxCallConnect() > |--------INVITE------->| > |<-100 Try (INVITE)| > |<-180 Ring(INVITE)| > Some time later, but before the other end answers: > sipxCallDestroy() > |--------CANCEL------->| > The far end responds with either > |<--200 OK (INVITE)--| > or > |<--487 Terminated---| > This is the race condition. Either they answered the call before seeing > the CANCEL, or they didn't. If they answer, and send a "200 OK (INVITE)", > then nothing happens on the sipXtapi side, and the far end keeps sending > the "200 OK (INVITE)" trying to elicit the ACK. If they send a "487 > Terminated", then sipXtapi sends the ACK and all is well. That is what > XCL-107 describes. >> Looking at >> the code, I'm guessing it is the CANCEL timer? If it is the CANCEL >> timer -- it looks like the call *may* leak if the BYE responses takes >> longer then 2 seconds. I would test that one case -- if that works, I >> think it is safe. You are also welcome to unwind that "HACK" comment >> in the cancel timer. =) It looks like a band aid to this problem. >> Instead of waiting for either a 200 OK or a 487 to the CANCEL, we are >> just closing our eyes and trying again in 2s. > Again, I am not qualified to comment on that. > The small change I am hoping to make SEEMS to solve the race condition > problem. If that change isn't right, then please help us to make the > right one. > --Woof! _______________________________________________ sipxtapi-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipxtapi-dev/
