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
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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
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
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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
Hugh Waite writes:
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.
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
-
Hugh Waite -
Juha Heinanen