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
_______________________________________________
sr-dev mailing list
[email protected]
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
