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

Ravi Patel ravi.patel at ecosmob.com
Tue Aug 1 09:58:28 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 4:12 PM, Bogdan-Andrei Iancu <bogdan at opensips.org>
wrote:

> Hello Ravi,
>
> It looks like the failed call to 3333 has no failure route set (this is
> why you directly get the 408 default timeout, as there is no failure route
> to handle the timeout event). Are you sure you t_on_failure() for each call
> attempt (especially when handling the call failure to 2222) ?
>
> Best 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/26/2017 04:35 PM, Ravi Patel wrote:
>
> 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 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/20170801/17391ff4/attachment-0001.html>


More information about the Users mailing list