Bogdan Pintea wrote:
Klaus Darilion wrote:
FYI: This is the pragmatic approach how openser users handle the problem:
- 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