On Jun 22, 2009 at 19:44, Juha Heinanen jh@tutpro.com wrote:
i updated my tm module from git and replaced tm timer avps with t_set_fr calls. before i start calling next_gw()/t_relay(), i do
t_set_fr(75000, 3000)
accuracy of fr_timeout became good, but i'm still getting the error messages:
It's strange that the accuracy became good, because the timeout is set in a similar way when fr_timer_avp is used (so it should be always good, always at max. 125 ms drift with default TIMER_TICKS_HZ).
Jun 22 19:38:53 localhost /usr/sbin/sip-router[11411]: INFO: Routing initial INVITE to sip:0407058050@192.98.101.21:5060 and <<null>> Jun 22 19:38:56 localhost /usr/sbin/sip-router[11437]: INFO: Routing next INVITE to sip:0407058050@192.98.101.24:5060 Jun 22 19:38:59 localhost /usr/sbin/sip-router[11437]: INFO: Routing next INVITE to sip:0407058050@192.98.101.23:5060 Jun 22 19:39:02 localhost /usr/sbin/sip-router[11437]: INFO: Routing next INVITE to sip:0407058050@192.98.101.22:5060 Jun 22 19:39:05 localhost /usr/sbin/sip-router[11437]: INFO: Routing next INVITE to sip:0407058050@192.98.100.10:5060 Jun 22 19:39:07 localhost /usr/sbin/sip-router[11412]: ERROR: tm [t_reply.c:1066]: ERROR: t_should_relay_response: status rewrite by UAS: stored: 408, received: 403 Jun 22 19:39:07 localhost /usr/sbin/sip-router[11411]: ERROR: tm [t_reply.c:1066]: ERROR: t_should_relay_response: status rewrite by UAS: stored: 408, received: 403 Jun 22 19:39:07 localhost /usr/sbin/sip-router[11410]: ERROR: tm [t_reply.c:1066]: ERROR: t_should_relay_response: status rewrite by UAS: stored: 408, received: 403
like before, in this test the first four t_relays resulted in fr_timeout (gw didn't respond) and the last returned 403 (forbidden).
what is the next step, i.e., how to get rid of the error messages? i don't see that i would be doing anything wrong here in my cfg file.
We could log it at a lower level or add a config option for skipping the log message, but first we should see if it doesn't point to some other more serious error. I still don't understand why you get them.
Are you sure that the gateway does not respond later with 403 for the initial branches (after more then 14s)? Do you add a new branch in all the cases?
Could you send me a packet dump along with the log (preferably at a high debug level) and a short example on how you are doing this gateway failover from the failure route? It's most likely a too verbose message for your setup, but I'd like to be sure of that and that it does not hide a more important problem.
Andrei