Juha,
There is the parameter restart_fr_on_each_reply, its documentation says:
Setting it to 0 is especially useful when dealing with bad UAs that
continuously retransmit 180s, not allowing the transaction to timeout
(and thus making impossible the implementation of certain services,
like automatic voicemail after x seconds).
The parameter is enabled by default. Shouldn't we disable this when we
do serial forking with t_next_contacts. To guarantee that UAs
retransmitting 180s do not prevent serial forking from happening?
-- Jan
Juha,
Function t_loads contacts in tm/t_serial.c encodes the Request-URI and
all branches of the SIP message into an AVP. At the end the function
calls clear_branches to remove all branches from the SIP request, so
that a subsequent call to t_next_contacts can only restore those with
highest q number.
I am wondering if calling clear_branches is enough. Shouldn't the
function also call reset_dst_uri to reset the value of the dst_uri
(which is now also stored in the AVP), and perhaps also clear the send
socket, the branch flags and the path vector for the Request-URI?
All these values are encoded into the AVP, but they are only cleared
for additional branches (in clear_branches), but not for the
Request-URI "branch".
I also considered doing that in clear_branches, but then I realized
that this function is called from other places and modules and it
could break them.
Any thoughts on this? How thorough should t_load_contacts be when it
resets variables whose values are stored in the AVP?
-- Jan
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
i didn't get any answer to my question about this commit.
it looks to me that there is now two versions of sip-router core. i
thought that the agreement was that there is only one core and that all
commits to core are done to sr_3.0 branch.
can someone explain to me what is going on? am i missing something?
why this commit could not use done to sr_3.0 perhaps #ifdef kamailio or
something like that so that there would be only one core?
-- juha
Hi, sorry for this off-topic.
I'm starting with Git (yeah!) and creating a repository in my server to manage
various projects.
I'm learning about Git and access control (users, permissions, authorization
per repository and so).
How is this stuff implemented in SR Git repository? does it use Gitosis? If
not, how is managed the permissions?
Thanks for any tip.
--
Iñaki Baz Castillo <ibc(a)aliax.net>