[OpenSIPS-Users] PDD
Brett Nemeroff
brett at nemeroff.com
Thu Jun 11 17:07:38 CEST 2009
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> 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>> 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>>> 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>>
>>
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.opensips.org/pipermail/users/attachments/20090611/e093d3f2/attachment.htm
More information about the Users
mailing list