Martin Hoffmann wrote:
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.
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.