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:[email protected]:5060 SIP/2.0. > > U 192.168.100.208:5060 -> 192.168.100.202:5060 > INVITE sip:[email protected]: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 >>> [email protected] >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>> > > > _______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
