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

[Bogdan Pintea]

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?

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

[*]:
"  If a request is destined to an IP address, port, and transport to
   which an existing connection is open, it is RECOMMENDED that this
   connection be used to send the request, but another connection MAY be
   opened and used."
(RFC3261)


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


Yes, there is a pending feature request for this issue, which will 
probably make to next release.


Cheers,
Bogdan.

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

-- 
Bogdan Pintea

iptego GmbH  -  VoIP Security
http://www.iptego.de