10 Mar
2009
10 Mar
'09
3:23 p.m.
Daniel-Constantin Mierla writes:
yes, i know that. i meant automatic de-arming when t_relay is called.
at least in some case i have noticed earlier that if i don't set again
failure/branck/reply routes in failure route, they are not necessarily
set when t_relay is called in failure route.
thanks for
that. there is still work to do regarding t_relay failures
(also applies to fork.cfg). based on today's tests (that i wrote
another message about), i'm totally confused regarding tm's t_relay
behavior. there is no documentation on de-arming of route blocks,
you have to
give "0" as parameter to functions arming tm route
> blocks. Probably different codes should be returned in case
of errors, to
differentiate the behavior in the config.
i would prefer that the default behavior is that failure route is called
no matter what error happened. there could be a way to override that if
someone wants to have more manual control.
for example, lets say that there is a syntax error in r-uri of a
branch that is being t_relayed. if failure route is set, it should get
called with error "400 Bad Request".
i cc this to sr-dev lists, since in my opinion sip-router tm module
should allow user friendly, simple handling of t_relay failures.
-- juha