23 Aug
2005
23 Aug
'05
8:02 p.m.
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
23 Aug
23 Aug
8:10 p.m.
Bogdan-Andrei Iancu writes:
- 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).
what if some headers were removed in branch route? will they be still
there for other branches?
-- juha
8:14 p.m.
Juha Heinanen wrote:
Bogdan-Andrei Iancu writes:
all adds / removes are actually lumps added to original request - all
lumps added in a branch route are removed after its execution, so all
changes (add or remove) will be cancelled for the rest of the branches.
so, if toy remove a hdr from a branch route, the hdr will still be
visible for the rest of the branches.
regards,
bogdan
- 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).
what if some headers were removed in branch route? will they be still
there for other branches?
8:13 p.m.
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(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
.
24 Aug
24 Aug
11:29 a.m.
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(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
.
1:26 p.m.
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(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
.
5:28 p.m.
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(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
.
5:32 p.m.
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(a)openser.org
> http://openser.org/cgi-bin/mailman/listinfo/users
>
> .
>
.
7040
days inactive
7041
days old
7 comments
3 participants
participants (3)
-
Bogdan-Andrei Iancu -
Iqbal -
Juha Heinanen