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/
