[Devel] ask invite/cancel race condition issue again

[Bogdan-Andrei Iancu]

Hi Di-Shi,

if you have a stateful proxy, there is reason to do any special CANCEL 
processing in script as the TM will guarantee sending it to the same 
destination as the INVITE (conforming to RFC). So, we try to optimize 
CANCEL processing in script via this shortcut.

if the sipp does not retransmit CANCEL, it is buggy. NOTE that you must 
not send any reply for CANCEL from the script - ant provisional reply 
stops the retransmission.

regards,
bogdan

Di-Shi Sun wrote:
> Hi Norman,
>
> Thank you for your info. It looks like OpenSER does not use the same way
> that SER uses to deal with this issue. I hope the source devices of our
> customers will re-send the CANCEL. I used SIPp as call generator. It did not
> re-send CANCEL.
>
> Thanks,
>
> Di-Shi Sun.
>
> ----- Original Message ----- 
> From: "Norman Brandinger" <norm at goes.com>
> To: "Bogdan-Andrei Iancu" <bogdan at voice-system.ro>
> Cc: "Di-Shi Sun" <di-shi at transnexus.com>; <devel at openser.org>
> Sent: Saturday, February 24, 2007 2:17 AM
> Subject: Re: [Devel] ask invite/cancel race condition issue again
>
>
>   
>> Here is an example adapted from one of Klaus' postings.  Thanks Klaus.
>>
>> #------------------------------------------------------------------
>> # CANCEL without matching INVITE transaction, discard it
>> #------------------------------------------------------------------
>> 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 next time the INVITE transaction is already created
>>     xlog("L_NOTICE", "CANCEL without matching transaction discard.\n");
>>     exit;
>> }
>>
>> Regards,
>> Norm
>>
>>
>> Bogdan-Andrei Iancu wrote:
>>     
>>> Hi Di-Shi,
>>>
>>> yes, there is a solution for this - at the beginning of the script use
>>> t_check_tran() to see if the CANCEL does match an INVITE request. IF
>>> no, just silently discard it - this will force the UAC to retransmit
>>> the CANCEL until the proxy actually finished processing the INVITE
>>> (and build transaction for it).
>>>
>>> BTW, fo you have any input for bug 1592883 ?
>>>
>>> regards,
>>> bogdan
>>>
>>> Di-Shi Sun wrote:
>>>       
>>>> Hi All,
>>>>
>>>> I met the INVITE/CANCEL race condition that had been disscussed long
>>>> ago in this maillist. The formal script of this issue like this:
>>>>
>>>> *the CANCEL arrives BEFORE the INVITE, or
>>>> *it arrives after but you are doing other high-cost processing steps
>>>> (i.e., DNS lookup (ENUM)) before calling t_relay which will lead to
>>>> process the CANCEL before creating the transaction.
>>>>
>>>> It said that this issue had been fixed. But I cannot find the
>>>> solution. Could anyone give me some suggestion?
>>>>
>>>> Thanks,
>>>>
>>>> Di-Shi Sun.
>>>>
>>>>         
>>> ------------------------------------------------------------------------
>>>       
>>>> _______________________________________________
>>>> Devel mailing list
>>>> Devel at openser.org
>>>> http://openser.org/cgi-bin/mailman/listinfo/devel
>>>>
>>>>         
>>> _______________________________________________
>>> Devel mailing list
>>> Devel at openser.org
>>> http://openser.org/cgi-bin/mailman/listinfo/devel
>>>
>>>
>>>       
>>
>>     
>
>
>
> _______________________________________________
> Devel mailing list
> Devel at openser.org
> http://openser.org/cgi-bin/mailman/listinfo/devel
>
>