I have a situation where CANCEL messages sent by the caller through SER are sometimes ignored by the destination switch. These events are infrequent, and seem to be ignored only if they are received in a narrow window between the 100 Trying and the 183 Session Progress or 180 Ringing message. The destination switch eventually emits a 183/180 and even a 200 OK as the called party answers the call of a long-departed caller.

I don't believe that this is a race condition, as the called numbers are sometimes wireless parties, who have 4-10 seconds of time between 100 Trying/IAM and 180/183/ACM responses, and I have seen ignored cancels at the beginning and middle of that lengthy period. So a race condition for that large a period with such an infrequent occurrence seems unlikely.

The destination (SIP to ISUP gateway) equipment vendor points out that in the dozen samples of this occurring that the branch tag of the CANCEL didn't match the one shown in the INVITE, and per RFC 3261, their decision to ignore the CANCEL seems to be the right one. In particular, section 17.2.3 criteria 1.

This immediately made me think of SER and its habit of saving time and memory by not remembering some or all call state unless you tell it to, via various knobs that are turned off by default. However, I can't explain why most cancels that arrive in the same point in the call setup apparently do meet criteria and only a small number don't. It would seem that SER would have mismatched branch tags all the time or never, depending on the knob settings.

Any ideas? Thanks in advance.