[OpenSIPS-Users] t_on_failure()

[Patrick]

Yep, I'm using 1.5 - once I removed it all was well.  On a side note,  
I confirmed to myself that parallel forking works.  Unfortunately ,  
the call was not answered so I don't know the outcome if someone would  
have actually answered the call  :)


On Jul 17, 2009, at 8:26 AM, Bogdan-Andrei Iancu wrote:

Hi Patrick,

I guess you are using 1.5 - for the append_branch() issue, see  http://www.opensips.org/Resources/DocsMigration14to15#toc4

Regards,
Bogdan

Patrick wrote:
> 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
>>>
>
>
>