On Jun 22, 2009 at 16:12, Juha Heinanen <jh(a)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