[OpenSIPS-Users] t_on_failure()

[Patrick]

Ok, I took and comment out append_branch() and I only see one invite  
per destination.


On Jul 10, 2009, at 4:04 PM, Patrick wrote:


Interesting, in my testing I've seen the following:

I have a list of 4 destinations - if it fails for one, I'd like it to
roll through all four.    I have that occurring,  but when I did a
packet capture I see two INVITEs sent for each of the new destinations
after the first initial failure.   The first one appears to be okay
though with only one INVITE sent.

failure_route[2] {
         if (t_was_cancelled()) {
                 exit;
         };
         t_on_failure("2");
         append_branch();
         t_relay();
         exit;
}

Not only is this confirmed via a packet capture, but I see multiple
CDRs cut on the various destinations.

Here is the first two lines of the packets

U 192.168.100.208:5060 -> 192.168.100.202:5060
INVITE sip:5555551212 at 192.168.100.202:5060 SIP/2.0.

U 192.168.100.208:5060 -> 192.168.100.202:5060
INVITE sip:5555551212 at 192.168.100.202:5060 SIP/2.0.


These are in succession with no other packets in between....


Patrick


On Jul 9, 2009, at 6:48 PM, Alex Balashov wrote:

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


_______________________________________________
Users mailing list
Users at lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users