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

[Klaus Darilion]

FYI: This is the pragmatic approach how openser users handle the problem:

1. drop the CANCEL if there is no corresponding INVITE transaction. The 
UAC must retransmit the CANCEL and meanwhile there should be the INVITE 
transaction. (since 1.0)

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;
}


2. delayed CANCEL. If openser hasn't forward a CANCEL because of missing 
provisional response, it remembers this branch and sends a CANCEL of 
there is a delayed provisional response from the caller (at least in 
CVS=1.2)

regards
klaus

Martin Hoffmann wrote:
> Greger V. Teigre wrote:
>> I forward this from the serusers list:
>>
>> A CANCEL is being sent from a UAC before having established a route set, 
>> thus the CANCEL has no Route header and is not caught by loose routing. 
>> The below thread shows that this case is difficult to understand. Jiri 
>> and Bogdan had a discussion on serusers regarding the race condition 
>> where the provisional reply from UAS and the CANCEL cross each other.
> 
> I seem to have missed this discussion, but shouldn't the race be between
> the final reply and the CANCEL?
> 
> In SER, there is a race between the INVITE and the CANCEL: If the INVITE
> processing hasn't been finished and the transaction for it has not yet
> been established through t_relay() before the CANCEL arrives, things go
> wonky.
>  
>> Q1:
>> This situation can be handled in 0.9.x by sending CANCEL through 
>> handling the CANCEL as an INVITE. Has this changed in SER 2.0?
> 
> If you already have a transaction for the INVITE, you should be fine by
> simply passing the CANCEL to tm by calling t_relay(). Don't remember
> what tm does with a CANCEL it doesn't have a transaction for. IMHO it
> should do nothing and give an error back.
> 
>> Q2:
>> At what point will t_reply be able to match the CANCEL against the state 
>> in tm?
>> I assume only when the provisional reply has been received from UAS.
> 
> The state is there the moment a transaction is established. The problem
> here is that SER doesn't CANCEL branches that have not yet received a
> 100 Trying since The Standard doesn't allow you to.
>  
>> Q3:
>> Jiri and Bogdans' discussion seems to conclude that the proxy should not 
>> do anything, but is the responsibility of the UAC.  This seems strange 
>> to me as a missing CANCEL (that in fact could have been routed 
>> correctly) is likely to result in an OK, then a BYE, and (as the thread 
>> below suggest) is often not handled properly by UACs.
>> So: What is the best way to practically handle this? (i.e. sysop's 
>> perspective)
> 
> As usual: Ignore. It's a borderline case, anyways. Most likely, it will
> fix itself anyways because the person that receives the false call will
> hang up and thus their UA will generate a BYE.
> 
>> Q4:
>> From a user's perspective, sending all CANCELs to t_relay() would be 
>> very appealing. It is natural to assume that tm could match the dialog 
>> and appropriate routing. Is this possible for 2.0? If not, is this feasible?
> 
> This depends on what tm is doing with a CANCEL it can't find a
> transaction for. If I understand the code right, it currently treats
> such a CANCEL as if it were nothing special. This would actually be in
> violation of 3261 which states that you MUST forward the CANCEL
> statelessly. However, the reasoning is that this is because the proxy
> may have forwarded the INVITE statelessly earlier. Since I never do
> that, I would happily violate that MUST.
> 
> Regards,
> Martin
> _______________________________________________
> Serdev mailing list
> Serdev at lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serdev


-- 
Klaus Darilion
nic.at