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
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 writes:
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.
so currently "no transaction" => "no failure route".
is this also true:
"t_relay returns negative value" => "no failure route"?
the other question is:
"negative t_relay code X" => "no transaction" for -6 <= X <= -1?
The failure route expects some things to be done right. It is not easy doable to call failure_route for any t_relay() error.
not knowing what those are, but i would imagine that is would be possible to relax that, i.e., some default value would be provided for "wrong" thing.
-- juha
El Martes, 10 de Marzo de 2009, Juha Heinanen escribió:
Daniel-Constantin Mierla writes:
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.
so currently "no transaction" => "no failure route".
is this also true:
"t_relay returns negative value" => "no failure route"?
the other question is:
"negative t_relay code X" => "no transaction" for -6 <= X <= -1?
I'd really like to document the appropiate responses for these questions here: http://www.kamailio.org/dokuwiki/doku.php/troubleshooting:tm:t_relay :)
-
Daniel-Constantin Mierla -
Iñaki Baz Castillo -
jh＠tutpro.com