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 <bog...@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.new...@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-boun...@lists.opensips.org> on behalf of Ravi Patel >> <ravi.pa...@ecosmob.com> >> *Reply-To: *OpenSIPS users mailling list <users@lists.opensips.org> >> *Date: *Friday, July 28, 2017 at 11:36 AM >> *To: *Bogdan-Andrei Iancu <bog...@opensips.org> >> *Cc: *OpenSIPS users mailling list <users@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 <bog...@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@lists.opensips.org >> >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> >> >> >> >> _______________________________________________ >> Users mailing list >> Users@lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> > >
_______________________________________________ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users