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

[Andrei Pelinescu-Onciul]

On Feb 26, 2007 at 17:45, Martin Hoffmann <hn at nvnc.de> wrote:
> Bogdan Pintea wrote:
> > Klaus Darilion wrote:
> > >FYI: This is the pragmatic approach how openser users handle the problem:
> > >
> > >1. drop the CANCEL if there is no corresponding INVITE transaction.
> > 
> > Why not politely return an error?
> 
> The assumption is that there is a race and that there will be a
> transaction soon and all is fine with the re-transmit.
> 
> > >The UAC must retransmit the CANCEL and meanwhile there should be the 
> > >INVITE transaction. (since 1.0)
> > 
> > Wouldn't it be easier to only provisionally reply after the transaction 
> > is already created (="visible" also from the other processes)?
> 
> When does the "100 Trying" happen in SER. You are, of course, right that
> this fixes the race (and explains why the rule not to cancel
> transactions without provisional responses exists in the first place).
> 
> Which makes it all the more apparent that t_relay() should never relay a
> CANCEL. Ever. It should return with an error and I then can decide
> whether I have a stateless proxy or not to statelessly forward the
> CANCEL or just error it away.

I think it should relay the CANCEL and if an INVITE comes and the CANCEL
transaction is still alive, it should reply w/ 487 (Ottendorf does
this).


Andrei