1 Sep
2009
1 Sep
'09
9:14 p.m.
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.