17 Oct
2009
17 Oct
'09
3:23 a.m.
Juha,
I wrote a very simple sip-router script to test serial forking based
on q values with t_load_contacts and t_next_contacts. I noticed that
when I use t_next_contacts before the transaction exists, it uses the
value of fr_inv_timer_next even for the first branch.
Is this itendended behavior? Shouldn't the function use the value of
fr_inv_timer for the first branch and then fr_inv_timer_next for
subsequent branches?
This is where fr_inv_timer_next is set for the first branch:
http://git.sip-router.org/cgi-bin/gitweb.cgi?p=kamailio;a=blob;f=modules/tm…
-- Jan
17 Oct
17 Oct
10:27 a.m.
Jan Janak writes:
I wrote a very simple sip-router script to test serial
forking based
on q values with t_load_contacts and t_next_contacts. I noticed that
when I use t_next_contacts before the transaction exists, it uses the
value of fr_inv_timer_next even for the first branch.
Is this itendended behavior? Shouldn't the function use the value of
fr_inv_timer for the first branch and then fr_inv_timer_next for
subsequent branches?
jan,
it is the intended behavior and it has always been like that. it has
even been documented in the readme:
Function t_next_contacts() sets fr_inv_timer to fr_inv_timer_next value
if, after t_next_contacts() is called, there are still lower qvalue
contacts available, and to fr_inv_timer value if there are not.
the idea is that using fr_inv_timer_next, one can shorten the "ringing"
if there are still other contacts to try. if the set of contacts to try
is that last one (or the only one), "ringing" time is normal, i.e.,
specified by fr_inv_timer. if you would wait for normal time already on
the first set, the call would timeout before you have had a change to
try the remaining contacts.
-- juha
3:10 p.m.
On Sat, Oct 17, 2009 at 9:27 AM, Juha Heinanen <jh(a)tutpro.com> wrote:
Jan Janak writes:
Ohh, I see. I did not get that from the documentation and the code.
So, if I understand it correctly, what you are saying is that
fr_inv_timer_next is used if serial forking takes place and in that
case it is used for all branches except those that are tried last. The
last set of parallel branches in serial forking uses the usual
fr_inv_timer.
I think we might need to clear this up a little in the readme because
I did not understand it from the documentation. In fact, I was
wondering why t_next_contacts resets the timer to fr_inv_timeout at
the end and it makes sense now. Thanks.
-- Jan
I wrote a very simple sip-router script to test
serial forking based
on q values with t_load_contacts and t_next_contacts. I noticed that
when I use t_next_contacts before the transaction exists, it uses the
value of fr_inv_timer_next even for the first branch.
Is this itendended behavior? Shouldn't the function use the value of
fr_inv_timer for the first branch and then fr_inv_timer_next for
subsequent branches?
jan,
it is the intended behavior and it has always been like that. it has
even been documented in the readme:
Function t_next_contacts() sets fr_inv_timer to fr_inv_timer_next value
if, after t_next_contacts() is called, there are still lower qvalue
contacts available, and to fr_inv_timer value if there are not.
the idea is that using fr_inv_timer_next, one can shorten the "ringing"
if there are still other contacts to try. if the set of contacts to try
is that last one (or the only one), "ringing" time is normal, i.e.,
specified by fr_inv_timer. if you would wait for normal time already on
the first set, the call would timeout before you have had a change to
try the remaining contacts.
3:14 p.m.
Jan Janak writes:
Ohh, I see. I did not get that from the documentation
and the code.
So, if I understand it correctly, what you are saying is that
fr_inv_timer_next is used if serial forking takes place and in that
case it is used for all branches except those that are tried last. The
last set of parallel branches in serial forking uses the usual
fr_inv_timer.
you did understand correctly.
I think we might need to clear this up a little in the
readme because
I did not understand it from the documentation. In fact, I was
wondering why t_next_contacts resets the timer to fr_inv_timeout at
the end and it makes sense now. Thanks.
feel free to try to make it more clear in the readme. it is said there,
but may be not very well.
-- juha
5516
days inactive
5516
days old
3 comments
2 participants
participants (2)
-
Jan Janak -
jh＠tutpro.com