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/
