So Brett did Bodgan's suggestion ever work?
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]> 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 > > -- View this message in context: http://n2.nabble.com/PDD-tp3043858p3816650.html Sent from the OpenSIPS - Users mailing list archive at Nabble.com. _______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
