[Kamailio-Devel] SF.net SVN: openser:[5679] trunk/etc/kamailio.cfg

Daniel-Constantin Mierla miconda at gmail.com
Tue Mar 10 20:44:03 CET 2009



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




More information about the Devel mailing list