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

[Martin Hoffmann]

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.

Regards,
Martin