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