[OpenSIPS-Users] OpenSIPS reseting issue with $T_fr_inv_timeout while forwarding

Ravi Patel ravi.patel at ecosmob.com
Wed Aug 2 04:46:26 EDT 2017


Dear Bogdan and Ben,
Thanks for your replies.

Previously, I set t_on_failure() when forwarded call came back to
OpenSIPS(not in failure_route) , Now after your suggestion I set
*t_on_failure()* before *t_relay()* in *failure_route*.

That Indeed solved the issue of forwarding and timeout, but faced another
issue after this change.

Here is the brief of issue:

in failure_route, I fetched some *headers* from *SIP Message,* that checks
the number of forwarding and if not exceeded max count, it proceed to
forward the call(t_relay()).
Now in this logic I added *t_on_failure()* before *t_relay()* , now here I
am not able to get the headers from SIP Message in failure_route where I am
checking the max forwarding count.

Is there any way to get the headers in failure_route after using
t_on_failure in failure_route ??

Hope I explained well.

Let me know If you need anything else from my side.

Regards,
Ravi Patel

On Fri, Jul 28, 2017 at 9:09 PM, Ben Newlin <Ben.Newlin at genesys.com> wrote:

> Ravi,
>
>
>
> Are you sure you are arming the failure route after each step using
> t_on_failure? It sounds like you are only doing this on the call to 2222,
> which allows you to failover to 3333. But when you send to 3333 you have to
> arm the failure route again.
>
>
>
> Ben Newlin
>
>
>
> *From: *Users <users-bounces at lists.opensips.org> on behalf of Ravi Patel <
> ravi.patel at ecosmob.com>
> *Reply-To: *OpenSIPS users mailling list <users at lists.opensips.org>
> *Date: *Friday, July 28, 2017 at 11:36 AM
> *To: *Bogdan-Andrei Iancu <bogdan at opensips.org>
> *Cc: *OpenSIPS users mailling list <users at lists.opensips.org>
> *Subject: *Re: [OpenSIPS-Users] OpenSIPS reseting issue with
> $T_fr_inv_timeout while forwarding
>
>
>
> Dear Bogdan,
>
> I am Grateful for your reply.
>
> I applied *$T_fr_inv_timeout* before doing each *t_relay().* by applying
> it , I am able to achieve it at 1st forwarding but unfortunately not
> working for 2nd forwarding.
>
> The scenario is:
> 1111
> 2222 (fr_inv_timeout 10 sec)
> 3333 (fr_inv_timeout 5 sec)
> 4444 (fr_inv_timeout 20 sec)
>
> when 1111 calls 2222 : OpenSIPS generates CANCEL at 10 secs and forwards
> call to 3333.
> now --> 3333 : OpenSIPS generates CANCEL at 5 secs but does not forward
> call to 4444 instead it sends *408 to Caller(1111)* and drops call.
>
> I am attaching packets where sip.client.com refers to the SIP clients and
> sip.server.com refers to the OpenSIPS Server.
>
> Also find the attached snapshots of the call flow.
>
> Please guide what can be done or where I am doing wrong ?
>
> Let me know if you need any other information.
>
> Best Regards,
>
> Ravi Patel
>
>
>
>
>
>
>
>
>
> On Tue, Jul 25, 2017 at 9:07 PM, Bogdan-Andrei Iancu <bogdan at opensips.org>
> wrote:
>
> Hi Ravi,
>
> Before each t_rely() you have to set the your custom $T_fr_inv_timeout and
> $T_fr_timeout, otherwise the default values will be used.  As you have a
> serial forking scenario, you do a new t_relay() at each step.
>
> Regards,
>
> Bogdan-Andrei Iancu
>
>   OpenSIPS Founder and Developer
>
>   http://www.opensips-solutions.com
>
>
>
> OpenSIPS Bootcamp 2017, Houston, US
>
>   http://opensips.org/training/OpenSIPS_Bootcamp_2017.html
>
> On 07/25/2017 05:34 PM, Ravi Patel wrote:
>
> Hi Team,
>
> What is the right way to reset timers *$T_fr_inv_timeout* and
> *$T_fr_timeout* ??
>
> I am using OpenSIPS-2.2 version
> The below scenario will help to understand issue,
>
> There are 4 SIP users,
> 1111,2222,3333,4444
>
> What I want to achieve is:
> 1111 ---> 2222 (FORWARD ON NOANSWER) ---> 3333 (FORWARD ON NOANSWER) --->
> 4444
>
> *1st Test Case Scenario:*
>
> 1111
> 2222 (fr_inv_timeout 20 sec)
> 3333 (fr_inv_timeout 25 sec)
> 4444 (fr_inv_timeout 30 sec)
>
>
> when 1111 calls 2222 : OpenSIPS generates CANCEL at 20 secs (thats working
> proper as expexted) and forwards call to 3333 as per my configuration.
> so in --> 3333 : OpenSIPS generates CANCEL at *20 secs instead of 25 secs*
> and send 408 to 1111. and not processing the 2nd forwarding.
>
> *2nd Test Case Scenario:*
> 1111
> 2222 (fr_inv_timeout 20 sec)
> 3333 (fr_inv_timeout 15 sec)
> 4444 (fr_inv_timeout 30 sec)
>
> when 1111 calls 2222 : OpenSIPS generates CANCEL at 20 secs (that is
> working proper as expexted) and forwards call to 3333 as per my
> configuration.
> now --> 3333 : OpenSIPS generates CANCEL at 15 secs and forwards the call
> to 4444, Here OpenSIPS generates CANCEL *after 5 secs instead of 30 secs.*
>
>
> We set timeout by using $T_fr_inv_timeout.
> ------------
> route[ring_timeout]{
>                 xlog("L_INFO","------------------- RING_TIMEOUT
> ---------------\n");
>                 if (!is_method("INVITE"))
>                         return;
>                 avp_db_load("$rU","$avp(ringtimeout)/usr_preferences");
>                 if($avp(ringtimeout)!=null)
>                 {
>                         $T_fr_inv_timeout = NULL;
>                         xlog("L_INFO","$rU: Ring timeout :
> $avp(ringtimeout)");
>                         $T_fr_inv_timeout =$(avp(ringtimeout){s.int}) ;
>                         xlog("L_INFO","$rU: Ring timeout is setted:
> [$T_fr_inv_timeout]");
>                 }
>                 else
>                 {
>                         xlog("L_INFO","$rU: Ring timeout is NOT setted");
>                 }
> }
> ------------------
>
> From both the scenarios what we found, it sticks to the first timeout of
> 2222,that is 20secs in our case.
> In first scenario it generates CANCEL on 3333 at 20 secs instead of 25
> that is 2222's Timeout.
> In second scenario it generates CANCEL on 3333 at 15sec and on 4444 at 5
> sec (15 + 5 = 20 sec) that is also 2222's timeout.
>
>
> Can I know the right method to set $T_fr_inv_timeout ?
>
> Let me know if any other information is needed.
>
> Thanks,
>
> Ravi
>
>
>
>
>
> _______________________________________________
>
> Users mailing list
>
> Users at lists.opensips.org
>
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
>
>
>
> _______________________________________________
> Users mailing list
> 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/20170802/c4853a85/attachment.html>


More information about the Users mailing list