Daniel-Constantin Mierla writes:
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.
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.
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