[Users] Resetting flags in branch_route[] resets flags for ALL branches

Tavis P tavis.lists at galaxytelecom.net
Sat Jul 29 00:10:54 CEST 2006


Just to cap it all up i'll document here my experiences and what
solution i came to


So originally i had an issue with flag manipulation in branch_route
because i wasn't aware of the tm module parameter that allows you to set
certain flags as branch_flags

Here i encountered some non-ideal behaviour (to me at least), in that
once a flag is marked as being a branch flag    
----
modparam("tm", "branch_flag_mask", "b00000000000000000000000000000100")
----

If the flag has been set in the main routing blocks it will only exist
in the FIRST branch_route (regardless to any append_branch() calls)
Where I was expecting that all global flags that have been flagged as
branch_flags would be copied into each branch on branch_route execution

This wasn't a problem by any means, just required extra work on my part
to isolate those flags that were global and those that needed to be set
for different branches, maybe it would make a good optional feature
(enabled by a tm parameter) in the future?

Also, on the topic of interesting features, it might be useful to some
to be able to set per branch onreply_routes (currently changing the
onreply_route inside branch_route changes the onreply_route for all
branches)


Thanks for everyones help!

tavis

Tavis P wrote:
> Good news and bad news
>
> It seems that setting t_on_reply() inside a route[] called from a branch
> route changes the onreply_route for ALL branches =P
>
> However i missed some information inside the docs regarding per branch
> flags (Bogdan pointed them out to me) which can be enabled with a TM
> module setting
>
> Its shame, being able to set the onreply_route within branch_route
> created some interesting opportunities
>
> Tavis P wrote:
>   
>> Setting t_on_reply() inside a route block called from a branch_route
>> does work, good thinking!
>>
>> Now i can reference two different on_reply routes within branch_route,
>> one for those who need mediaproxying and one for those who dont
>>
>> Somewhat inelegant but it should work!
>>
>> Tavis P wrote:
>>   
>>     
>>> I believe it needs to be set before executing t_relay(), also adding
>>> "t_on_reply("11");" to branch_route breaks script compilation
>>>
>>> I've added a bug in the sourceforge bug tracker
>>> (http://sourceforge.net/tracker/index.php?func=detail&aid=1530057&group_id=139143&atid=743020)
>>> regarding this issue
>>>
>>> This is a big problem for anyone trying to use branch_route to call
>>> mediaproxy/rtpproxy on a per branch basis (which is where it is causing
>>> a problem for me)
>>>
>>> For fun i will try to set t_on_reply() inside a route[] block that will
>>> be called from branch_route[] and let you know how it works out
>>>
>>> tavis
>>>
>>> Klaus Darilion wrote:
>>>   
>>>     
>>>       
>>>> Not sure, but I had problems with settings AVPs in reply_route and it
>>>> turned out, that reply route AVPs did not belong to the transaction
>>>> structure. Maybe its the same problem with flags. Maybe it is possible to
>>>> set activate different reply_route in branch_route?
>>>>
>>>> regards
>>>> klaus
>>>>
>>>> On Fri, July 28, 2006 0:20, Tavis P said:
>>>>   
>>>>     
>>>>       
>>>>         
>>>>> I'm using branch route to trigger mediaproxy logic per branch for UAC
>>>>> directed calls and i'm experiencing some strange behavior:
>>>>>
>>>>> t_relay() is called, there are two branches
>>>>>
>>>>> In both branches there are two flags set
>>>>> During branch_route processing of the first branch both are left intact.
>>>>> During branch_route processing of the second branch, both are reset
>>>>> (unset)
>>>>>
>>>>> The destination UAC for the first branch picks up the phone call,
>>>>> sending a SIP OK message
>>>>>
>>>>> This is where i'm experiencing the problem
>>>>> Inside of the onreply_route both flags are NOT set, even though they
>>>>> were unset in a different call branch
>>>>>
>>>>> Has anyone experienced this behavior before?
>>>>> Is it supposed to work this way?
>>>>>
>>>>> This is using a recent (1-2 weeks ago) cvs checkout of OpenSER 1.0.0
>>>>>
>>>>> tavis
>>>>>
>>>>>           





More information about the Users mailing list