[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