[OpenSIPS-Users] OpenSIPS reseting issue with $T_fr_inv_timeout while forwarding
Ravi Patel
ravi.patel at ecosmob.com
Tue Aug 22 10:15:47 EDT 2017
Dear Bogdan,
Apologize for the late reply.
I was checking my logic and your suggestions in lab.
Finally what my observation is,
1)
I set an avp variable in main route. say for example: $avp(test)=0
that I found it in failure_route and I am incrementing it by 1 and call
forwarded to OpenSIPS again.
Now in main route I am not able to get that variable, but yes when call
went again to failure_route on failure case , I got its value 1 and able to
increment it by 1.
2)
Second thing I found is:
Say for example my call scenarios is:
1111 --> 2222 --Forward on No Answer--> 3333 --Foraward on No Answer--> 4444
-----------------------
1111 -> 2222 : 2222 did not answer.
in Failure_route, I set append_hf("test: 1\r\n"); and call forwarded to
OpenSIPS again with $rU=3333.
2222 -> 3333 :
In Main Route I am able to get its value.
***** Now I use remove_hf("test"); before forwarding call to 3333.
3333 did not pick up the call.
call lands on failure_route.
in Failure_route, I set append_hf("test: 2\r\n"); and call forwarded to
OpenSIPS again with $rU=4444.
3333 -> 4444 :
In Main Route when I fetch $hdr(test), I got the value 1 instead of 2. When
I check its SIP trace, I found two headers with name "test" with values 1
and 2.
------------------
So, remove_hf at ***** removes it from the OutBound SIP packet, but it is
not removed at failure_route.
I hope I explained well(It is a bit complex).
Let me know if you need anything else to debug it.
Regards,
Ravi Patel
On Wed, Aug 2, 2017 at 7:23 PM, Bogdan-Andrei Iancu <bogdan at opensips.org>
wrote:
> Hi Ravi,
>
> I have to admit I did not understand your whole scenario, but you can read
> SIP headers in failure route, for sure. I think you are more fighting how
> the changes are done per-branch in OpenSIPS - whatever you change in
> request route (as changes) will be inherited by all branches/forks of that
> transaction. What you change in failure route will propagate only for that
> new branch.
>
> IF you want to count the number of serial forking attempts, better use an
> $avp(_name_) variable - you can init it to 0 in request route and increment
> it each time you do a new t_relay().
>
> 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 08/02/2017 11:46 AM, Ravi Patel wrote:
>
> 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/20170822/eadc9f11/attachment-0001.html>
More information about the Users
mailing list