[Users] BRANCH route support
iqbal at gigo.co.uk
Wed Aug 24 13:26:59 CEST 2005
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
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.
> Iqbal wrote:
>> So as a user, how would/could I use this
>> 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.
>>> PS: testing done only superficial (is quite late now).....any
>>> help/reports are welcomed :D
>>> Users mailing list
>>> Users at openser.org
More information about the sr-users