[OpenSIPS-Users] t_on_failure()

Alex Balashov abalashov at evaristesys.com
Fri Jul 10 00:48:35 CEST 2009


I think from a methodological perspective, you're doing just fine.

Failure_route[1] isn't going to inherently be called cyclically because 
failure replies that trigger it are final replies.  The only way you can 
cycle through the same failure_route is if you created another branch 
and armed that failure route for it, too, after the t_relay().  Both of 
these have a recursion bottom;  failures only happen once, unless you 
manually cause a certain (branch) sequence of events to transpire beyond it.

If you saw failure_route[1] getting called twice, make sure it wasn't in 
response to a CANCEL from the near-end.  You need to have something like 
this in there, at the beginning.

   failure_route[1] {
      if(t_was_cancelled()) {
         log that we got a cancel, blah blah
         exit;
      }
   }

When you get a CANCEL, first failure_route[1] is called as part of 
CANCEL processing (automatically, if armed, by TM), and then, you're 
going to get it called again in response to the 487 Session Terminated 
message that is returned by the far end in response to the CANCEL.  The 
487 is part of the INVITE transaction, and since the proxy is only 
transaction-stateful, that's the best it can do.

Patrick wrote:

> Sorry, I should have included the code like you have to illustrate my 
> question (if you don't mind, I will borrow it):
> 
> 
> route {
> 
>   ...
> 
>   t_on_failure("1");
> 
>   if(!t_relay()) {
>       sl_reply_error();
>       exit;
>   }
> 
> }
> 
> ...
> 
> failure_route[1] {
>    t_on_failure("1");              <-----   here is what I am asking 
> about t_on_failure inside of a failure_route[x]
>    t_relay();
>   ...
> }
> 
> 
> Prior to setting this, I only saw entries in failure route twice:
>    1) the first time the call was attempted
>    2) if the call failed
> 
> It would stop there even when I had a third option.   Now it is trying 
> all three options, but just wanted to make sure this was a logical 
> methodology ....  I have safe guards in place to stop it from endlessly 
> looping
> 
> 
> Patrick
> 
> 
> On Jul 9, 2009, at 6:00 PM, Alex Balashov wrote:
> 
> You need both;  they do different things.
> 
> The failure_route[x] won't get triggered by default unless you associate 
> it with a transaction - in effect, telling OpenSIPS to trigger 
> failure_route[x] if a failure code is received for this transaction 
> after stateful relay.  That's what t_on_failure() does.
> 
> route {
> 
>   ...
> 
>   t_on_failure("1");
> 
>   if(!t_relay()) {
>       sl_reply_error();
>       exit;
>   }
> 
> }
> 
> ...
> 
> # This will never be run unless t_on_failure("1") is set
> # above.
> 
> failure_route[1] {
>   ...
> }
> 
> 
> Patrick wrote:
> 
>> Is it wise to have a t_on_failure inside of a failure_route[x] ?  Or  
>> is there another method I could / should use?
>> Thanks,
>> Patrick
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> 
> 


-- 
Alex Balashov
Evariste Systems
Web     : http://www.evaristesys.com/
Tel     : (+1) (678) 954-0670
Direct  : (+1) (678) 954-0671



More information about the Users mailing list