[OpenSIPS-Users] CANCEL handling

[Mariana Arduini]

Hi Bogdan,

Understood. Thanks again!

Mariana.


On Wed, Jan 9, 2013 at 5:09 PM, Bogdan-Andrei Iancu <bogdan at opensips.org>wrote:

> **
> Hi Mariana,
>
> no, you do not need to create the INVITE trasaction in advance - do it as
> usually : at the end, on t_relay(). Because if the INVITE transaction does
> not exist (not yet relayed), the t_check_trans() for CANCEL will fail and
> CANCEL will be dropped (not relayed). Only one of the following
> retransmissions on the CANCEL will get relayed as soon as the INVITE
> transaction is created.
>
> Regards,
>
> Bogdan-Andrei Iancu
> OpenSIPS Founder and Developerhttp://www.opensips-solutions.com
>
>
> On 01/09/2013 05:38 PM, Mariana Arduini wrote:
>
> Hi Bogdan,
>
>  So I understand that the only way to recognize the transaction of a
> CANCEL message received before relaying the INVITE is to create the
> transaction using t_newtran() just after receiving the INVITE, but this
> would affect some of our features.
>
>  In this case, we´ll have to work on the time our server is taking to
> process the INVITE and make sure it won´t be stuck for too long waiting for
> a DB query or something.
>
>  Thanks again for the kind help!
>
>  Regards,
> Mariana.
>
>
> On Wed, Jan 9, 2013 at 11:29 AM, Bogdan-Andrei Iancu <bogdan at opensips.org>wrote:
>
>>  Hi Mariana,
>>
>> According to RFC3261, the CANCEL processing (as cancelling the call) is
>> not up to a proxy, but up to the end devices. So a proxy has to simply
>> relay all received info (INVITE and CANCEL) - it cannot terminate the call
>> by itself.
>>
>> So you have to relay both INVITE and CANCEL and let the end device to
>> reject the call.
>>
>> Regarding Flavio's suggestion - that function (as name says) solves the
>> problem only for the flags, but not for changes as headers or SDP, AVPS,
>> etc.
>>
>> Regards,
>>
>> Bogdan-Andrei Iancu
>> OpenSIPS Founder and Developerhttp://www.opensips-solutions.com
>>
>>
>>   On 01/09/2013 02:31 PM, Mariana Arduini wrote:
>>
>> Hi All!
>>
>>  Thank you both for the hints and explanation.
>>
>>  The retransmission of CANCEL messages would for sure be really helpful,
>> but we´d like to be able to handle cases where processing the INVITE takes
>> too long. If introducing some huge delays in INVITE processing, OpenSIPS
>> will relay it when the processing finally ends, but UAC had already
>> canceled it, so UAS picks a dead call up.
>>
>>  Flavio´s suggestion looks interesting. I´m just wondering if
>> t_flush_flags() would update all kind of changes in the SIP message. We
>> perform lots of translations in headers and SDP and not applying any of
>> them would totally mess everything up. Any idea of limitations?
>>
>>  I begin to think that including timeouts during INVITE processing with
>> smaller values than the previous hop fr_inv would be less risky. I´d like
>> to hear your oppinions.
>>
>>  Thanks again for the help!
>>
>>  Regards,
>> Mariana.
>>
>>
>>
>> On Wed, Jan 9, 2013 at 9:54 AM, Bogdan-Andrei Iancu <bogdan at opensips.org>wrote:
>>
>>>  Hi Mariana,
>>>
>>> If CANCEL hits opensips while the the INVITE is still under processing
>>> (in a different process), the INVITE transaction will not exist yet (it is
>>> created by t_relay), so the t_check_trans() will return false -> script
>>> will exit without doing anything for the CANCEL - more or less the CANCEL
>>> will be dropped without being replied or fwded. This will force
>>> retransmission of Cancel -> buying more time to finish the processing of
>>> the INVITE.
>>>
>>> Hope this helped.
>>>
>>> Regards,
>>>
>>> Bogdan-Andrei Iancu
>>> OpenSIPS Founder and Developerhttp://www.opensips-solutions.com
>>>
>>>
>>> On 01/08/2013 10:49 PM, Mariana Arduini wrote:
>>>
>>>  Hello all,
>>>
>>>  I hope somebody can give me a kind hint on what to do here.
>>>
>>>  We have this piece of code for CANCEL handling:
>>>
>>>       # CANCEL processing
>>>     if (is_method("CANCEL")) {
>>>         if (t_check_trans()) {
>>>             t_relay();
>>>         }
>>>         exit;
>>>     }
>>>
>>>  What happens is sometimes we take too long to process the INVITE due
>>> to some DB issues, and the UAC sends us a CANCEL before we relay the
>>> INVITE.
>>>
>>>  We don´t use t_newtran() because of this big warning in docs saying
>>> that "the changes on the request that are made after this function call
>>> will not be saved into transaction!!!". We need to perform a lot of
>>> changes in the requests and I understand this wouldn´t be possible after
>>> calling t_newtran().
>>>
>>>  So our transaction is not created untill we relay the INVITE, which
>>> means that any CANCEL received before that will be dropped.
>>>
>>>  We also tried testing the CANCEL messages we´re receiving in these
>>> cases with has_totag() and loose_route(), but they won´t pass as well.
>>>
>>>  Is there any way to verify a CANCEL message in this scenario and relay
>>> it in case is belongs to a valid transaction?
>>>
>>>  Any help will be much appreciated.
>>>
>>>  Regards,
>>> Mariana.
>>>
>>>
>>> _______________________________________________
>>> Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20130109/e09ef225/attachment-0001.htm>