[Serdev] Re: Handling of early CANCELs - was Re: [Serusers] SER Nokia CANCEL Problem

[Jan Janak]

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.