Have you verified that the call has been completely dropped and deleted afterwards? Not just sending the BYE?
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 don't understand the what is detecting the race and then whacking the call. Is that your application or call processing? 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. On Thursday, August 17, 2006, 12:57:41 PM, Andy Spitzer wrote: > Woof! > On Thu, 17 Aug 2006 11:47:00 -0400, Bob Andreasen <[EMAIL PROTECTED]> > wrote: >> When I had read this earlier, I thought it was checking against a >> to tag -- not the to field which would make much more sense to me. > Yep, that is what I thought at first as well. But the comment clearly > documents "has a to field", and code does indeed checks the length of the > to field [strToField.length()]. Thus it makes no sense. >> I worry that we are going to leak calls in some cases if you allow >> processing of re-INVITEs while the call is being dropped. This also >> may be related to some funky transfer cases. > That is why I'd like to understand what this check was trying to do, > because I don't believe it achieved what was wanted. >> Could you explain how this fixes the XCL-107? > The fix for XCL-107 involves allowing the 200 OK to the INVITE to be > handled by CpPeerCall. Note that the test checks for seqMethod, which > comes from the Cseq header. So as written it filters out both requests > AND responses. Filtering out the 200 OK response here means it isn't > handled anywhere, and no ACK is ever sent. By allowing the 200 OK in, the > upper layers detect the race and send the ACK, as well as send a BYE. > The proposed change is this: > if (mDropping && seqMethod == "INVITE" && !sipMsg->isResponse()) > This will allow the response to be handeled by CpPeerCall, yet still > "filter out" (as far as CpPeerCall is concerned) requests. I'm not sure > we SHOULD filter out requests here, especially if they match in the > callID, but this would be the most minimal change that fixes XCL-107. > --Woof! _______________________________________________ sipxtapi-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipxtapi-dev/
