[OpenSIPS-Users] CANCEL handling

Bogdan-Andrei Iancu bogdan at opensips.org
Wed Jan 9 20:09:10 CET 2013


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 Developer
http://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 <mailto: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 Developer
>     http://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 <mailto: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 Developer
>>         http://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 list
>>>         Users at lists.opensips.org  <mailto:Users at lists.opensips.org>
>>>         http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20130109/a2de5c0b/attachment.htm>


More information about the Users mailing list