28 Feb
2007
28 Feb
'07
12:42 p.m.
Martin Hoffmann wrote:
SER/tm forwards the CANCEL statefuly if the corresponding INVITE
transaction does not exist in tm. The reason for this measure (as far
as I can remember) was improved robustness in the rare cases when no
matching INVITE transaction could be found (such as after SER restarts
or transaction timeouts). The idea here was that in such cases SER
should try to execute exactly the same routing logic for the CANCEL as
it did for the INVITE, to increase the chance that the CANCEL would
reach the correct final destination.
SER can be configured (and is by default) to drop long-lasting INVITE
transaction _silently_, i.e. without terminating it explicitly (see
the noisy_ctimer parameter of tm module). If this happened and SER did
not forward the CANCEL (although the corresponding INVITE transaction
did not exist anymore) then you could end up having a phone ringing
indefinitely (or until the first hammer hit by your roommate, it is
unbelievable but there are people that can't stand phones ringing for
hours).
This is also the reason, by the way, why most SER configuration files
do not contain just if (method=="INVITE") but:
if (method=="INVITE" || method=="CANCEL"). This is to ensure that
CANCELs will go down the same path in the configuration files as
INVITEs and that they hit the same destination as the INVITE did.
This, of course, does not work when parallel or sequential forking
takes place, or when you have a very complex configuration file in
place.
This is my recap what is SER doing with CANCELs that have no matching
INVITE transaction in tm and why. I am not sure whether this logic is
still relevant today, given the complexity of most configuration files
and frequent use of forking.
Jan.
Q4:
From a user's perspective, sending all CANCELs to t_relay() would be
very appealing. It is natural to assume that tm could match the dialog
and appropriate routing. Is this possible for 2.0? If not, is this feasible?
This depends on what tm is doing with a CANCEL it can't find a
transaction for. If I understand the code right, it currently treats
such a CANCEL as if it were nothing special. This would actually be in
violation of 3261 which states that you MUST forward the CANCEL
statelessly. However, the reasoning is that this is because the proxy
may have forwarded the INVITE statelessly earlier. Since I never do
that, I would happily violate that MUST.