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/
