no really, only if you have different vals for different calls. Regards, Bogdan
Brett Nemeroff wrote: > 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] <mailto:[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]> > <mailto:[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]>> > <mailto:[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]>> > <mailto:[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
