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

[Jiri Kuthan]

At 18:45 26/02/2007, Martin Hoffmann wrote:
>> 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).

It is a kind of trad-off. You could do it immediatelly after receipt of
a message. Downside: if SER reboots a nanosecond after that, UAC is led
in belief everything is okay and stops retransmitting and elicit the
striven-for action. The other extreme way is sending after SER processing 
is finished, which may take such a while, that UAC unnecesssarily retransmits.
Personally, none of these two alternatives seems dramatically worse to me 
than the other.

>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.

not sure if dropping it is too nice -- particularly because of SER reboots
which may lead tis way to for-ever ringing UASs. I would say rather not.
For the forwarding case, I'm kind of twisted on if it is okay to do
it statelessly. I would say it is roughly okay. (forking for example should
be stateful to avoid UAC confused by an unexpected variaty of asnswers,
but I think it is not sooo bad .. UACs have to deal with multiple OKs
for INVITEs anyhow, and who cares about answers for CANCELs.....)

-jiri