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

Bogdan-Andrei Iancu bogdan at opensips.org
Fri Jul 28 06:42:14 EDT 2017


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 <http://sip.client.com> 
> refers to the SIP clients and sip.server.com <http://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 <mailto: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 <http://www.opensips-solutions.com>
>
>     OpenSIPS Bootcamp 2017, Houston, US
>        http://opensips.org/training/OpenSIPS_Bootcamp_2017.html
>     <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 <http://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 <mailto:Users at lists.opensips.org>
>>     http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>     <http://lists.opensips.org/cgi-bin/mailman/listinfo/users>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20170728/3e2ca74f/attachment-0001.html>


More information about the Users mailing list