[OpenSIPS-Users] CANCEL handling

[Mariana Arduini]

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/6023c056/attachment-0001.htm>