Yeah, this is exactly what I was thinking.. Is setting the fr_timer avp really necessary there? It doesn't seem to change..
I'll give this a shot and let you know what I get.. Thanks! -Brett On Thu, Jun 11, 2009 at 10:04 AM, Bogdan-Andrei Iancu < [email protected]> wrote: > ok :) > > so, do something like: > > enable restart_fr_on_each_reply and onreply_avp_mode (see > http://www.opensips.org/html/docs/modules/1.5.x/tm.html#id271347) > > before sending out the INVITE, set $avp(fr_timer) =2 (see > http://www.opensips.org/html/docs/modules/1.5.x/tm.html#id271112) , so > that if no reply is coming in 2 secs, timeout will fire. > > in onreply_route, when receiving 100, set $avp(fr_inv_timer) =5; the timer > will be reset and the new val used. > > > in onreply_route, when receiving 18x, set $avp(fr_inv_timer) =200; the > timer will be reset and the new val used. > > > never tried this, to be honest :D... > > Regards, > Bogdan > > Brett Nemeroff wrote: > >> Ok, let me try this a different way because I think I may be spreading my >> confusion. :) >> >> The behavior I'm looking for is: >> INVITE goes to carrier. >> 100 Trying MUST come back in 2 seconds >> THEN >> 18X MUST come back in 5 seconds else FAIL >> THEN >> Allow ringing for 200 seconds >> >> from what you've described, it sounds like I can't have the 2 seconds and >> 5 seconds be different numbers (static tm module param fr_timer). But even >> now.. I have fr_timer set to 5 and it's perfectly happy waiting 20 seconds >> between 100 and 180. Why does it not time out there? >> >> Thanks! >> -Brett >> >> >> >> On Thu, Jun 11, 2009 at 9:44 AM, Bogdan-Andrei Iancu < >> [email protected] <mailto:[email protected]>> wrote: >> >> Brett, >> >> first of all you cannot reset the timers manually from script - >> the timers handling is automatically done by TM, totally >> transparent for the script. >> >> second, the restart_fr_on_each_reply controls the fr_inv_timer. >> >> >> Brett Nemeroff wrote: >> >> Ok, so at first I was thinking.. what I need to do is set the >> fr_inv_timer to something like 10 seconds. But then in the >> on_reply route, check for a 18X reset the fr_inv_timer to like >> 200 seconds to allow the call to ring. >> >> I'm pretty confused now.. I thought the fr_timer was the timer >> to get a provisional reply. so as soon as you get a 100 the >> timer isn't used anymore. This option suggests that if you set >> restart_fr_on_each_reply to 1, then after you get a 100 >> Trying, then it will allow for fr_timer seconds again before >> timing out. Is that right? This of course, leads me to my next >> question, the documentation says that by default it does this, >> but I'm certainly not seeing this behavior. >> >> maybe the the 100 + 180 where too fast and close to INVITE, and no >> other reply before 200 OK, so "visibly" effect of a restart.... >> >> >> let me make sure I have this clear please: >> fr_timer = time from trigger (request) to ANY reply. The >> trigger point depends on the restart_fr_on_each_reply setting. >> If off, it's just from the request. If on, each provisional >> reply will cause the timer to be reinvoked, else it would have >> been ignored. In other words if fr_timer = 5 seconds and I get >> a 100 Trying after 500ms, and then the 183 Ringing occurs 8 >> seconds later, the only way the timer would be tripped is if I >> set reset_fr_on_each_reply=1? >> >> fr_inv_timer = the max amount of time between an initial >> request and a positive final reply (2XX) >> >> >> as said , the restart_fr_on_each_reply controls the fr_inv_timer. >> NOTE that setting a new avp for fr_inv_timer in onreply_route (set >> the usage of AVPs in onreply_route) will update the value of the >> timer !! interesting ;). >> >> >> How mixed up am I? And is restart_fr_timer_on_each_reply >> really default to 1? >> >> yes :) >> >> and if so, why does it not work how I expect? (ie: now, as >> long as I get the 100 Trying in 5 secs (fr_timer) the 18X >> could come 20 seconds later and everything is happy (but me). >> >> not sure I get the scenario..... >> >> Regards, >> Bogdan >> >> >> Thanks! >> -Brett >> >> >> >> >> >> On Thu, Jun 11, 2009 at 3:14 AM, Bogdan-Andrei Iancu >> <[email protected] <mailto:[email protected]> >> <mailto:[email protected] >> <mailto:[email protected]>>> wrote: >> >> Hi Brett, >> >> The relevant timer are: >> - A - timeout at transport level, if no reply comes back >> - B - timeout at transaction level, if the transaction >> did not >> completed (no final response received) >> >> What may help you is the fact that the B timer may be reset >> after >> each provisional reply. see: >> >> http://www.opensips.org/html/docs/modules/1.5.x/tm.html#id271074 >> >> Regards, >> Bogdan >> >> Brett Nemeroff wrote: >> >> All, >> Is there a tm timer for pdd? >> What I want is to timeout between a 100 and a 18X >> reply.. so >> if I get a 100 and say more than 6000ms elapses without >> another provisional reply, proceed to failure route. >> >> I don't see a way to do this now without fr_inv_timer which >> effectively is the "ring timer" as far as I understand. >> which >> isn't quite right (timer from 1XX to >=200?) >> >> Thanks, >> Brett >> >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Users mailing list >> [email protected] >> <mailto:[email protected]> >> <mailto:[email protected] >> <mailto:[email protected]>> >> >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> >> >> >> >
_______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
