13 May
2013
13 May
'13
5:45 p.m.
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
13 May
13 May
5:51 p.m.
New subject: executing tm:branch-failure event_route also when t_relay() fails?
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 - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, San Francisco, USA - June 24-27, 2013
* http://asipto.com/u/katu *
6:15 p.m.
New subject: executing tm:branch-failure event_route also when t_relay() fails?
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
6:56 p.m.
New subject: executing tm:branch-failure event_route also when t_relay() fails?
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
8:51 p.m.
New subject: executing tm:branch-failure event_route also when t_relay() fails?
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
14 May
14 May
12:37 a.m.
New subject: executing tm:branch-failure event_route also when t_relay() fails?
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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
--
Hugh Waite
Principal Design Engineer
Crocodile RCS Ltd.
8:20 a.m.
New subject: executing tm:branch-failure event_route also when t_relay() fails?
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
4211
days inactive
4212
days old
6 comments
3 participants
participants (3)
-
Daniel-Constantin Mierla -
Hugh Waite -
Juha Heinanen