... 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.
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. Could you explain how this fixes the XCL-107? - Bob On Monday, August 14, 2006, 5:26:27 PM, Andy Spitzer wrote: > Woof! > I believe I have uncovered the root cause of > http://track.sipfoundry.org/browse/XCL-107 "CANCEL race condition with > INVITE 200 OK" > It has to do with this code fragment in CpPeerCall::willHandleMessage() > ... > // DWW 08/18/03 If we are dropping and a invite comes in, but > // has a to field, we should let the callmanager create a new > call. > // Otherwise, if a invite comes in, and does not have a to > field, > // the we SHOULD handle it. > if (mDropping && seqMethod == "INVITE" && strToField.length()) > ; > else > { > ... > This causes the 200 OK for an INVITE of a cancelled call to be ignored, > instead of being handled where it will be ACKed (see XCL-107). > Can anyone out there explain what bad things would happen if I removed > that check? I don't understand exactly what it is trying to do, as all > well formed SIP messages will have a to field. Perhaps it was trying to > check for the existance of a TAG on the to field...but even so, if the > callId matches why shouldn't this CpPeerCall handle that message? > Thanks, > --Woof! > _______________________________________________ > sipxtapi-dev mailing list > [email protected] > List Archive: http://list.sipfoundry.org/archive/sipxtapi-dev/ _______________________________________________ sipxtapi-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipxtapi-dev/
