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

[Jan Janak]

Greger V. Teigre wrote:
> I forward this from the serusers list:
> 
> A CANCEL is being sent from a UAC before having established a route set,
> thus the CANCEL has no Route header and is not caught by loose routing.
> The below thread shows that this case is difficult to understand. Jiri
> and Bogdan had a discussion on serusers regarding the race condition
> where the provisional reply from UAS and the CANCEL cross each other.
> 
> Q1:
> This situation can be handled in 0.9.x by sending CANCEL through
> handling the CANCEL as an INVITE. Has this changed in SER 2.0?

   No.

> Q2:
> At what point will t_reply be able to match the CANCEL against the state
> in tm?
> I assume only when the provisional reply has been received from UAS.

  TM will be able to match the CANCEL agains the state created by INVITE
  even if no provisional reply has been received from downstream. It's
  just that it will not forward it down the branch.

> Q3:
> Jiri and Bogdans' discussion seems to conclude that the proxy should not
> do anything, but is the responsibility of the UAC.  This seems strange
> to me as a missing CANCEL (that in fact could have been routed
> correctly) is likely to result in an OK, then a BYE, and (as the thread
> below suggest) is often not handled properly by UACs.
> So: What is the best way to practically handle this? (i.e. sysop's
> perspective)
> 
> 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?

   Yes, it would be possible, you could have a catch-all-CANCELs code at
   the very beginning of your configuration file, but it won't cover the
   cases when no INVITE transaction exist. In such a case t_relay will
   relay the CANCEL which would enter a forwarding loop because the
   Request-URI does not change.

       Jan.