On 03/10/2009 09:23 PM, Juha Heinanen wrote:
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.
At least when the transaction is not created the
failure route cannot be
called. And transaction cannot be called if parts of the sip message are
bad.
The failure route expects some things to be done right. It is not easy
doable to call failure_route for any t_relay() error.
Cheers,
Daniel
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
--
Daniel-Constantin Mierla
http://www.asipto.com