[Users] BRANCH route support

[Iqbal]

yeah, maybe more from a user perspective, because most of the time I 
know what I want to do, just dont have a clue what function should be 
used, or what its called, so a example of use maybe good.

EG like inv_timer, which was being discussed on serusers, now most 
people may like to change timers, for IP --IP calling and have this 
different to ip --> PSTN, but they may not know the using avp and 
inv_timer does this, hence a example of use, could be noted...maybe 
could have a tips and tricks section, where users may post.

Iqbal

Bogdan-Andrei Iancu wrote:

> Hi Iqbal,
>
> I was thinking to a short doc to  describe the route types and their 
> utility, what functions may or may not be called and so on....
>
> regards,
> bogdan
>
> Iqbal wrote:
>
>> tks, I was just thinking with all these new features a simple one 
>> paragraph of "how to use it" would help , because then users like me 
>> could see how it may help/fit into their scenario
>>
>> Iqbal
>>
>> Bogdan-Andrei Iancu wrote:
>>
>>> Hi Iqbal,
>>>
>>> you can use the branch route if you want to add/remove headers 
>>> independently, per branch. Imagine the following scenario:
>>>
>>> you are doing parallel forking to a phone and to a GW; for the phone 
>>> you want to add header to set the ringing type, but this make no 
>>> sense to send also to GW; on the other hand you want to add to GW 
>>> some headers containing billing information, info that you do not 
>>> want to go also to the phone.
>>>
>>> So, what you do in branch route? if uri points to GW, add the 
>>> billing (or whatever) header to the request; if points to an usrloc 
>>> client, add the ringing type header.
>>>
>>> regards,
>>> bogdan
>>>
>>> Iqbal wrote:
>>>
>>>> So as a user, how would/could I use this
>>>>
>>>> Iqbal
>>>>
>>>> Bogdan-Andrei Iancu wrote:
>>>>
>>>>> Hi everybody,
>>>>>
>>>>> I just finished adding support for BRANCH routes. The idea and 
>>>>> frame were partial ported from SER (thanks to Juha for extracting 
>>>>> and adapting patches). For those who are not familiar with this 
>>>>> concept: branch route is a route to be execute separately for each 
>>>>> branch before being sent out - changes in that route should 
>>>>> reflect only on that branch.
>>>>>
>>>>> I say partial because the features, implementation were improved. 
>>>>> Shortly here is a list:
>>>>>    - remove from grammar default BRANCH ROUTE definition - since 
>>>>> this is a 100% TM route, make no sense
>>>>>    - RURI may be changed from a branch route (the routing will 
>>>>> accordingly change); This capability is essential, since there are 
>>>>> core function which alter the RURI, functions which cannot be 
>>>>> blocked in specific route types - not handling this, may easyly 
>>>>> lead to memory faults or leaks.
>>>>>    - flags per branch - if flags are changed in branch_route, the 
>>>>> change will not be visible for other branches, but it will be 
>>>>> visible for all replies of that branch (it might be useful for per 
>>>>> branch NAT traversal)
>>>>>    - full AVP support in branch route
>>>>>    - more efficient handling of lumps (changes in request) - 
>>>>> instead of cloning and removing the entire lump tree for each 
>>>>> branch, using lump flags, after each branch, the original lump 
>>>>> tree will be just cleaned only what was added during branch route 
>>>>> will be removed).
>>>>>
>>>>>
>>>>> still pending: how to handle append_branch() core function.....I 
>>>>> will prefer to handle properly all core functions, since their 
>>>>> execution cannot be banned from specific routes.
>>>>>
>>>>> For the moment only textops, avpops and xlog modules were enabled 
>>>>> for branch route. Other will come in the future.
>>>>>
>>>>>
>>>>> regards,
>>>>> Bogdan
>>>>>      PS: testing done only superficial (is quite late now).....any 
>>>>> help/reports are welcomed :D
>>>>>
>>>>> _______________________________________________
>>>>> Users mailing list
>>>>> Users at openser.org
>>>>> http://openser.org/cgi-bin/mailman/listinfo/users
>>>>>
>>>>> .
>>>>>
>>>>
>>>
>>>
>>> .
>>>
>>
>
>
> .
>