[sr-dev] tm issues with TCP forwarding failures

[Andrei Pelinescu-Onciul]

On Jan 21, 2010 at 17:37, Klaus Darilion <klaus.mailinglists at pernau.at> wrote:
> Hi!
> 
> The sr/ser/kamailio smaple configs contain:
> 
>         if (!t_relay()) {
>                 sl_reply_error();
>         }
> 
> I wonder if this is still the case. I did some TCP tests and when the 
> TCP forwarding fails (e.g. RST received or set_forward_no_connect() 
> activated), then tm module itself replies stateful with 477 and then 
> returning to script with FALSE. Thus, sl_reply_error will send 500 
> response stateless too.

t_relay() will return error if it fails to create a transaction
(unlikely, only on out-of-mem), send failed on all branches (your case),
 cancel failed or stateless ACK forwarding failed.
tm will send an error reply only if no other statefull reply (t_reply()) is
sent in the script.

One way to handle this from the script is first to try t_reply() and
only if t_reply() fails, sl_reply_error(). E.g.:
if (!t_relay()){
    if (!t_reply("500", "Some error"))
        sl_reply_error();
}

Another possible way:
if (!t_relay()){
    if (t_lookup_request())
        exit; # transaction exists -> exit to trigger the auto-reply
    else
        sl_reply_error();
}

You could also use t_newtran(). If t_newtran() fails => sl_reply(). If
it doesn't and t_relay() fails => t_reply() let tm generate the reply.

> 
> IMO if tm module already sent a final response, it should exit without 
> entering script again.

tm sends a final response only at the end of the script and only no
other reply was sent from the script via t_reply. This allows overriding
the final reply from the script.

> 
> Even better would be to reply only if there is no failure route sent.
> 
> Further, if TCP forwarding fails due to set_forward_no_connect() it logs:
> 
>    ERROR: tm [../../forward.h:169]: msg_send: ERROR: tcp_send failed
>    ERROR: tm [t_fwd.c:1235]: ERROR: t_send_branch: sending request on
>    branch 0 failed
> 
> IMO it would be good to log this only with L_INFO, as it is not an 
> error, but intended behavior.

Agreed, but is quite hard to propagate the reason for the send failure
back to tm.

Andrei