Hi Jeff, in 1.4.5 that big doesn't exist - it appeared in 1.5.0 due some changes. So, in 1.4.5 it should be ok without any fix. If not, please let me know.
Regards, Bogdan Jeff Pyle wrote: > Hi Bogdan, > > Old news, but it's become relevant again in my little world. Is this fix > also in 1.4.5? > > > Thanks, > Jeff > > > > On 3/9/09 9:55 AM, "Bogdan-Andrei Iancu" <[email protected]> wrote: > > >> Hi Jeff, >> >> That is correct - I made a fix of LCR next_gw() function. It should work >> now. >> >> Regarding DR questions: do_routing() accepts as param the routing group >> (as load_gw_from_grp()). For GW flags, there are the GW attributes (see >> http://www.opensips.org/html/docs/modules/devel/drouting.html#id272134) >> >> Regards, >> Bogdan >> >> Jeff Pyle wrote: >> >>> Hello, >>> >>> I¹m using the LCR module in Opensips 1.5. (I realize I should probably >>> be using drouting if I¹m starting from scratch, but I need the gateway >>> group and flags functionality that only appear to be in the LCR >>> module. More on that at the end.) >>> >>> Bogdan emailed the list about not needing append_branch any longer in >>> a failure_route >>> (http://www.mail-archive.com/[email protected]/msg00663.html). >>> All the documentation seems to indicate that next_gw still does the >>> append_branch automatically. >>> >>> The behavior I¹m seeing, along with Bogdan¹s email from January, seem >>> to indicate it¹s not necessary anymore. In my configuration, next_gw >>> is called from the request_route. The request is sent out with >>> t_relay. The request fails with a 503, and is caught in the armed >>> failure_route. next_gw is called again, then t_relay. There appear to >>> be two branches present, the old one to the first (failed) gateway and >>> the new one to the second newly loaded gateway. t_relay does a >>> parallel fork to both of them. The first gateway fails again 503, and >>> in my test setup, so does the second, also with a 503. One of these >>> 503s is properly processed by the armed failure_route, the other one >>> is converted to a 500 and relayed to the UAC. >>> >>> >>>> From the perspective of the UAC: It sends an INVITE, gets a 100 >>>> >>> Trying, then a 500 (relayed) and a 503 (scripted) at the same time. >>> The UAC ACKs both of them and the transaction is over. >>> >>> Is all of this due to the lcr module still appending a branch in the >>> failure route when it shouldn¹t be? Or, does it appear something else >>> is going on? Normally I¹d post config snippits but in it¹s got so much >>> more unrelated and properly-functioning stuff I didn¹t want to confuse >>> the issue with the truth. :) >>> >>> Or, as an aside, can drouting duplicate the load_gw_from_grp() and >>> gateway flags functionality of lcr? >>> >>> >>> Thanks, >>> Jeff >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> 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
