[sr-dev] tm error: status rewrite by UAS
Andrei Pelinescu-Onciul
andrei at iptel.org
Mon Jun 22 19:07:50 CEST 2009
On Jun 22, 2009 at 19:44, Juha Heinanen <jh at 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 at 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 at 192.98.101.24:5060>
> Jun 22 19:38:59 localhost /usr/sbin/sip-router[11437]: INFO: Routing next INVITE to <sip:0407058050 at 192.98.101.23:5060>
> Jun 22 19:39:02 localhost /usr/sbin/sip-router[11437]: INFO: Routing next INVITE to <sip:0407058050 at 192.98.101.22:5060>
> Jun 22 19:39:05 localhost /usr/sbin/sip-router[11437]: INFO: Routing next INVITE to <sip:0407058050 at 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
More information about the sr-dev
mailing list