[OpenSIPS-Users] CANCEL handling

[Bogdan-Andrei Iancu]

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/725e5492/attachment.htm>