26 Feb
2007
26 Feb
'07
6:45 p.m.
Bogdan Pintea wrote:
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
Klaus Darilion wrote:
The assumption is that there is a race and that there will be a
transaction soon and all is fine with the re-transmit.
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 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)?