On Jun 22, 2009 at 16:12, Juha Heinanen jh@tutpro.com wrote:
Andrei Pelinescu-Onciul writes:
In your case the final reply is 408 (timeout) and the new received one is 403. What might have happened is either the gw sent the 403 after the fr_inv_timer did hit for the branch corresponding to your fifth call or the gw sent the 403 for one of the previous branches, but it's hard to say without more info.
andrei,
i set fr_timer_avp to 3000 (3 sec) before calling t_relay. i have
^^^^^^ the avp timers are in seconds, so you should set them it to 3. All the other timeouts are in ms (I'll add a note to the docs).
modparam("tm", "fr_inv_timer", 75000)
i have defined fr_inv_timer_avp, but it has not been given a value during processing of this request. could the explanation be this:
k:
1.3.11. fr_timer_avp (string)
If you set the AVP to an empty string, the whole mechanism for variable timeout will be disabled, falling back to the static value.
sr:
1.3.29. fr_inv_timer_avp (string)
The value of fr_inv_timer timer can be overriden on per-transaction basis. The administrator can provide a value to be used for a particular transaction in an AVP. This parameter contains the name of the AVP that will be checked. If the AVP exists then its value will be used for the fr_inv_timer timer, effectively overriding the value configured in fr_inv_timer parameter for the current transaction.
Yes, this is it.
what does sr do if fr_inv_timer_avp exists, but is not set before t_relay is called?
An avp always has a value if it exists. If its value is the empty string or 0 => the avp integer value will be 0 => in this case the timer will be set to 0.
I'll add a check for 0 in sr too (so that it will be compatible with the k way).
Note that in ser the modern way to use avps for timers is via t_set_fr() & friends (you can set everything from fr timers to retransmission and lifetime, you can later reset to default via t_reset_fr() and you can use it only when needed).
Andrei