[OpenSIPS-Users] PDD
Bogdan-Andrei Iancu
bogdan at voice-system.ro
Thu Jun 11 17:10:06 CEST 2009
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
> <bogdan at voice-system.ro <mailto:bogdan at voice-system.ro>> 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
> <bogdan at voice-system.ro <mailto:bogdan at voice-system.ro>
> <mailto:bogdan at voice-system.ro
> <mailto:bogdan at voice-system.ro>>> 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
> <bogdan at voice-system.ro <mailto:bogdan at voice-system.ro>
> <mailto:bogdan at voice-system.ro <mailto:bogdan at voice-system.ro>>
> <mailto:bogdan at voice-system.ro
> <mailto:bogdan at voice-system.ro>
> <mailto:bogdan at voice-system.ro
> <mailto:bogdan at voice-system.ro>>>> 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
> Users at lists.opensips.org
> <mailto:Users at lists.opensips.org>
> <mailto:Users at lists.opensips.org
> <mailto:Users at lists.opensips.org>>
> <mailto:Users at lists.opensips.org
> <mailto:Users at lists.opensips.org>
> <mailto:Users at lists.opensips.org
> <mailto:Users at lists.opensips.org>>>
>
>
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
>
>
>
>
More information about the Users
mailing list