9 Apr
2013
9 Apr
'13
11:57 a.m.
Hugh Waite writes:
- Can I do everything I can do in FAILURE_ROUTE in this event route?
No. This event_route uses a new route type (a new BRANCH_FAILURE_ROUTE
flag internally) which means functions and PVs are limited to ones that
have this flag set. So far, I have enabled the functions that are
required to enable outbound flow retries.
Since this route is run in a very similar way to the failure_route, it
is likely that most functions that work in a FAILURE_ROUTE will also
work in a BRANCH_FAILURE_ROUTE just by enabling the flag, but it is a
matter of whether they are appropriate for this route.
hugh,
i tried to enable two new functions on branch failure route by including
the flag:
{"t_branch_timeout", t_branch_timeout, 0, 0,
FAILURE_ROUTE|BRANCH_FAILURE_ROUTE },
{"t_branch_replied", t_branch_replied, 0, 0,
FAILURE_ROUTE|BRANCH_FAILURE_ROUTE },
but i still get to syslog:
0(29943) ERROR: <core> [cfg.y:3412]: misused command t_branch_timeout
0(29943) : <core> [cfg.y:3554]: parse error in config file
/etc/sip-proxy/sip-proxy.cfg, line 2559, column 32: Command cannot be used in the block
0(29943) ERROR: <core> [cfg.y:3412]: misused command t_branch_replied
0(29943) : <core> [cfg.y:3554]: parse error in config file
/etc/sip-proxy/sip-proxy.cfg, line 2559, column 55: Command cannot be used in the block
what is it that i still need to do?
-- juha
9 Apr
9 Apr
12:28 p.m.
New subject: git:master: modules/tm: Added branch_failure event route to tm documentation
Hi,
The config syntax has not been changed to treat the branch_failure route
differently, so it does not understand about the BRANCH_FAILURE route type.
Functions that are run in an event_route need to have the EVENT_ROUTE
flag enabled (which is the same as REQUEST_ROUTE) to pass the config
syntax check.
The functions that I used were already enabled for REQUEST_ROUTE so this
problem didn't happen for me.
Hugh
On 09/04/2013 09:57, Juha Heinanen wrote:
Hugh Waite writes:
- Can I do everything I can do in FAILURE_ROUTE in this event route?
No. This event_route uses a new route type (a new BRANCH_FAILURE_ROUTE
flag internally) which means functions and PVs are limited to ones that
have this flag set. So far, I have enabled the functions that are
required to enable outbound flow retries.
Since this route is run in a very similar way to the failure_route, it
is likely that most functions that work in a FAILURE_ROUTE will also
work in a BRANCH_FAILURE_ROUTE just by enabling the flag, but it is a
matter of whether they are appropriate for this route.
hugh,
i tried to enable two new functions on branch failure route by including
the flag:
{"t_branch_timeout", t_branch_timeout, 0, 0,
FAILURE_ROUTE|BRANCH_FAILURE_ROUTE },
{"t_branch_replied", t_branch_replied, 0, 0,
FAILURE_ROUTE|BRANCH_FAILURE_ROUTE },
but i still get to syslog:
0(29943) ERROR: <core> [cfg.y:3412]: misused command t_branch_timeout
0(29943) : <core> [cfg.y:3554]: parse error in config file
/etc/sip-proxy/sip-proxy.cfg, line 2559, column 32: Command cannot be used in the block
0(29943) ERROR: <core> [cfg.y:3412]: misused command t_branch_replied
0(29943) : <core> [cfg.y:3554]: parse error in config file
/etc/sip-proxy/sip-proxy.cfg, line 2559, column 55: Command cannot be used in the block
what is it that i still need to do?
-- 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.
1:08 p.m.
New subject: git:master: modules/tm: Added branch_failure event route to tm documentation
Hugh Waite writes:
The config syntax has not been changed to treat the
branch_failure route
differently, so it does not understand about the BRANCH_FAILURE route type.
Functions that are run in an event_route need to have the EVENT_ROUTE
flag enabled (which is the same as REQUEST_ROUTE) to pass the config
syntax check.
ok, but there still exists BRANCH_FAILURE_ROUTE flags in tm.c, e.g.
{"t_check_status", t_check_status, 1, fixup_t_check_status,
REQUEST_ROUTE | FAILURE_ROUTE | ONREPLY_ROUTE | BRANCH_FAILURE_ROUTE},
why is that and why does the flag exists?
do you see any problems in adding EVENT_ROUTE flag to t_branch_timeout
and t_branch_replied functions or would that require changing the
implementation of these two functions?
in my opinion, it would be very useful to be able to check in branch
failure route those two branch related things.
-- juha
6:58 p.m.
New subject: git:master: modules/tm: Added branch_failure event route to tm documentation
Juha,
On 09/04/2013 11:08, Juha Heinanen wrote:
why is that and why does the flag exists?
There
are two things that, admittedly, I have confused a bit myself.
The parser checks that you are allowed to run a function in particular
route types and will create a syntax error if this does not match.
Without modifying the config syntax, the parser cannot tell event routes
apart, so there is nothing to stop me from calling e.g. xhttp_reply() in
a branch_failure route!
Internally when a route is run, the route type can be set explicitly.
This allows the function to behave differently depending on which route
it is called in. See t_check_status() for example.
I have created a new internal route type BRANCH_FAILURE_ROUTE and needed
to modify t_check_status to add the new type to the switch statement.
Also t_next_contact_flow() will generate an error if called from any
other route type (e.g. in an xhttp event route) but only at runtime.
Functions that do not check the route type, such as xlog or
t_branch_replied/timeout, do not need modification to be run in this
route, but do need EVENT_ROUTE added to the definition to get through
the config parser.
This is the flag needed, and not BRANCH_FAILURE_ROUTE.
do you see any problems in adding EVENT_ROUTE flag to
t_branch_timeout
and t_branch_replied functions or would that require changing the
implementation of these two functions?
I don't see a problem with these. If
EVENT_ROUTE is added to the
functions in tm.c than these functions will return the presence of the
replied/timeout flags.
in my opinion, it would be very useful to be able to
check in branch
failure route those two branch related things.
-- 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:42 p.m.
New subject: git:master: modules/tm: Added branch_failure event route to tm documentation
Hugh Waite writes:
hugh,
thanks for the explanation. i now have
{"t_branch_timeout", t_branch_timeout, 0, 0,
FAILURE_ROUTE|EVENT_ROUTE},
{"t_branch_replied", t_branch_replied, 0, 0,
FAILURE_ROUTE|EVENT_ROUTE},
and my config that uses those two in tm:branch-failure event route, is
now accepted without errors.
regarding implementation of the functions, i added check that the
function is called from proper route, e.g.,
int t_branch_timeout(struct sip_msg* msg, char* foo, char* bar)
{
switch(get_route_type()) {
case FAILURE_ROUTE:
case BRANCH_FAILURE_ROUTE:
return (msg->msg_flags & FL_TIMEOUT)?1:-1;
default:
LOG(L_ERR, "ERROR:t_check_status: unsupported route type %d\n",
get_route_type());
}
return -1;
}
however, i'm still uneasy about the implementation. instead of
msg->msg_flags, should it test in BRANCH_FAILURE_ROUTE case
t->uac[get_t_branch()].branch_flags instead?
perhaps daniel has a comment too?
-- juha
do you see any
problems in adding EVENT_ROUTE flag to t_branch_timeout
and t_branch_replied functions or would that require changing the
implementation of these two functions?
I don't see a problem with these. If
EVENT_ROUTE is added to the
functions in tm.c than these functions will return the presence of the
replied/timeout flags.
4276
days inactive
4276
days old
4 comments
2 participants
participants (2)
-
Hugh Waite -
Juha Heinanen