[Serdev] Re: Handling of early CANCELs - was Re: [Serusers] SER Nokia CANCEL Problem

[Klaus Darilion]

Bogdan Pintea wrote:
> Hi,
> 
> Klaus Darilion wrote:
>> 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?

Because an error reply does not trigger a retransmission.
> 
>> 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)?

In case of openser we need a retransmission, thus the CANCEL is dropped. 
Probably with Ottendorf, which "remembers" the CANCEL, it should work.

>>
>> 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).

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