if t_relay() fails, for example, when tcp connection to destination is dead, no transaction is created and therefore tm:branch-failure event_route thus is not executed. this greatly complicates config script writing, for example, when trying to unregister unresponsive contacts.
is there any possibility to enhance the current t_relay implementation so that even if transaction is not created, tm:branch-failure would still be executed for each branch of the failing t_relay?
-- juha
Hello,
On 5/13/13 4:45 PM, Juha Heinanen wrote:
if t_relay() fails, for example, when tcp connection to destination is dead, no transaction is created and therefore tm:branch-failure event_route thus is not executed. this greatly complicates config script writing, for example, when trying to unregister unresponsive contacts.
is there any possibility to enhance the current t_relay implementation so that even if transaction is not created, tm:branch-failure would still be executed for each branch of the failing t_relay?
just thinking of it -- if you do t_newtran() before t_relay(), isn't it getting to failure route?
Perhaps it can be done (eventually with a modparam) for the case when the transaction structure can be created, but not when that fails (e.g., out of shared memory). These callbacks require transaction structure, if that is not available I expect it's going to require quite some changes in many places, not only tm module.
Cheers, Daniel
Daniel-Constantin Mierla writes:
just thinking of it -- if you do t_newtran() before t_relay(), isn't it getting to failure route?
yes, i do t_newtran() before t_relay, but still tm:branch-failure is not executed. here is an example with some debug xlog statements when t_relay() is called on dead contact:
May 13 18:10:59 siika /usr/sbin/sip-proxy[23826]: INFO: Creating new transaction May 13 18:10:59 siika /usr/sbin/sip-proxy[23826]: INFO: calling t_on_branch_failure("contact") May 13 18:10:59 siika /usr/sbin/sip-proxy[23826]: INFO: Routing INVITE sip:jh@192.98.102.10:5044;transport=tcp to contact via sip:192.98.102.10:42590;transport=TCP May 13 18:10:59 siika /usr/sbin/sip-proxy[23826]: ERROR: tm [../../forward.h:216]: msg_send: ERROR: tcp_send failed May 13 18:10:59 siika /usr/sbin/sip-proxy[23826]: ERROR: tm [t_fwd.c:1520]: ERROR: t_send_branch: sending request on branch 0 failed
my tm:branch-failure starts like this and the syslog message is not printed meaning that the event_route is never executed:
event_route[tm:branch-failure:contact] { xlog("L_INFO", "event_route[tm:branch-failure:contact]\n");
it would be a big help, if it would be executed.
-- juha
Juha Heinanen writes:
May 13 18:10:59 siika /usr/sbin/sip-proxy[23826]: ERROR: tm [t_fwd.c:1520]: ERROR: t_send_branch: sending request on branch 0 failed
now when i look the above more closely, it says that "sending request on branch 0 failed" and still tm:branch-failure route is not executed. this sounds like a contradiction to me.
perhaps there is some minor change in the t_fwd.c/t_send_branch() function to cause the branch-failure route to be executed?
-- juha
i did some reading of tm code and found that currently tm:branch_failure block seems to be handled only by code in t_reply.c. when t_relay() fails there is no reply processing and thus no execution of tm:branch-failure block.
perhaps something similar to t_reply()/run_branch_failure_handlers() could be done in t_send_branch() when sending fails? i'm pretty sure that t->on_branch_failure is set in t_send_branch(). it is thus the matter on getting the corresponding tm:branch_failure block executed.
-- juha
I can't remember if branches using TCP that fail to establish a connection generate a 408 Timeout response or not (eventually). I know I have seen them on the registrar servers when the edge/outbound proxy has failed (in certain tests e.g. when a 430 is not returned), but they might have been locally generated.
If an immediate error is detected, like a TCP connection failure, perhaps a different 'fake' reply, similar to timeout could be generated and sent through the reply handling code for that UAC. This would trigger the branch_failure route and also the failure route when all replies are received, allowing faster response handling instead of timeouts.
Hugh
On 13/05/2013 18:51, Juha Heinanen wrote:
i did some reading of tm code and found that currently tm:branch_failure block seems to be handled only by code in t_reply.c. when t_relay() fails there is no reply processing and thus no execution of tm:branch-failure block.
perhaps something similar to t_reply()/run_branch_failure_handlers() could be done in t_send_branch() when sending fails? i'm pretty sure that t->on_branch_failure is set in t_send_branch(). it is thus the matter on getting the corresponding tm:branch_failure block executed.
-- juha
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
Hugh Waite writes:
I can't remember if branches using TCP that fail to establish a connection generate a 408 Timeout response or not (eventually).
no, i get this immediately when t_relay() fails to dead tcp destination:
SIP/2.0 477 Unfortunately error on sending to next hop occurred (477/TM).
If an immediate error is detected, like a TCP connection failure, perhaps a different 'fake' reply, similar to timeout could be generated and sent through the reply handling code for that UAC. This would trigger the branch_failure route and also the failure route when all replies are received, allowing faster response handling instead of timeouts.
yes, if tm:branch-failure cannot be activated directly from tm [t_fwd.c:1520] then perhaps a fake reply can be generated from there. that, however, goes beyond my knowledge of tm module.
-- juha
-
Daniel-Constantin Mierla -
Hugh Waite -
Juha Heinanen