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

Tavis P tavis.lists at galaxytelecom.net
Fri Jul 28 04:04:04 CEST 2006


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
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at openser.org
>>> http://openser.org/cgi-bin/mailman/listinfo/users
>>>
>>>     
>>>       
>>
>>   
>>     
>
>
> _______________________________________________
> Users mailing list
> Users at openser.org
> http://openser.org/cgi-bin/mailman/listinfo/users
>
>
>   





More information about the Users mailing list