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