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] > 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]>> 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]> >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> >> >> >
_______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
