12 Mar
2007
12 Mar
'07
12:49 p.m.
Bogdan Pintea wrote:
In case of openser we need a retransmission, thus the CANCEL is dropped.
Probably with Ottendorf, which "remembers" the CANCEL, it should work.
You are right - dropping the CANCEL which was received over a reliable
transport is a bad idea - regardless if the same connection is used or
the request comes in via a new connection. Thus my workaround only works
with UDP.
regards
klaus
--
Klaus Darilion
nic.at
Hi,
Klaus Darilion wrote:
Because an error reply does not trigger a retransmission.
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)?
if ( is_method("CANCEL") && !t_check_trans() ) {
# CANCEL without matching INVITE transaction, ignore!
# May happen if the INVITE is slower than the CANCEL.
# Ignore the CANCEL, as the client will retransmit it, and maybe
# the INVITE transaction is already created for the next CANCEL
xlog("L_WARN","$ci CANCEL without matching transaction ...
ignore\n");
exit;
}
I guess the protocol might have to be checked, as well (at least to
reply with an error, rather than drop): for reliable transports you
won't see any retransmission and it seems that a client is allowed to
open a second connection for the CANCEL[*]; given the fact that INVITEs
usually go through multiple checks, the probability of a CANCEL being
run against the "transaction table" before the INVITE might not be that
low, after all (especially on loaded servers).