[OpenSIPS-Users] next_gw still does append_branch in failure_route?

[Bogdan-Andrei Iancu]

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" <bogdan at voice-system.ro> 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/devel@lists.opensips.org/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
>>> Users at lists.opensips.org
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>   
>>>       
>
>
>