[sr-dev] tm issues with TCP forwarding failures

[Klaus Darilion]

Andrei Pelinescu-Onciul schrieb:
> 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();
> }
> 

Is it also possible to t_relay the call a second time? For example 
relaying failed as the destination SIP proxy is not available can I 
redirect the call to an announcement server? e.g.:

if (!t_relay()){
     if (t_lookup_request())
	$du = "sip:announcement01 at 1.2.3.4";
	t_relay();	
         exit;
     else
         sl_reply_error();
}

regards
Klaus



> 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