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

[Andrei Pelinescu-Onciul]

On Feb 26, 2007 at 12:09, Martin Hoffmann <hn at nvnc.de> wrote:
> 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.
> 
> I seem to have missed this discussion, but shouldn't the race be between
> the final reply and the CANCEL?
> 
> In SER, there is a race between the INVITE and the CANCEL: If the INVITE
> processing hasn't been finished and the transaction for it has not yet
> been established through t_relay() before the CANCEL arrives, things go
> wonky.

It's mostly fixed in Ottendorf. There is still some race potential if
the CANCEL arrives after t_relay() started but before the message being
forwarded (e.g. during branch adding inside t_relay()).

>  
> > 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?
> 
> If you already have a transaction for the INVITE, you should be fine by
> simply passing the CANCEL to tm by calling t_relay(). Don't remember
> what tm does with a CANCEL it doesn't have a transaction for. IMHO it
> should do nothing and give an error back.

It forwards it statefully.

> 
> > 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.
> 
> The state is there the moment a transaction is established. The problem
> here is that SER doesn't CANCEL branches that have not yet received a
> 100 Trying since The Standard doesn't allow you to.
>  
> > 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)
> 
> As usual: Ignore. It's a borderline case, anyways. Most likely, it will
> fix itself anyways because the person that receives the false call will
> hang up and thus their UA will generate a BYE.
> 
> > 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.
> 
> Regards,
> Martin


Andrei