29 Mar
2007
29 Mar
'07
9:31 p.m.
At 18:45 26/02/2007, Martin Hoffmann wrote:
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.
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.
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