[SR-Users] New: max branches configurable via parameter

[Daniel-Constantin Mierla]

Hello,

being brought in discussions many times, including in the recent past
days, I replaced the static define of max branches limit with a core
parameter. It impacts the destination set stored in core and the uac
fields stored in transaction.

It can be set now with global parameter: max_branches

The old limit was 12, now it can be set in the range of 1 to 31.

Few aspects that I would like to discuss to get this refactored to fit
the best of common scenarios:

1) the 31 upper limit comes from tm cancelled branches bitmask, which
now is stored in an integer. Should be easy to get it to 63 (planned
after some testing that proves the concept used now is ok). Would it be
a need for even more?

2) would it make sense to specify the max number of branches per
transaction, in config, before creating the transaction? The upper limit
will be the max_branches value from the core.

3) thinking of common cases of what can be forked a lot, I thought that
we can a simplification of 2) by specifying two limits: one for initial
requests which are very likely to have many branches (think of initial
INVITE via LCR or location) and one for requests within dialog which are
likely to have one or very few branches (e.g., replicating BYE to a peer
server). Opinions?

The main benefit for 2) and 3) would be less memory usage.

Testing and feedback of the new max_branches parameter is very appreciated.

Cheers,
Daniel

[Olle E. Johansson]

Post by Daniel-Constantin Mierla
Hello,
being brought in discussions many times, including in the recent past
days, I replaced the static define of max branches limit with a core
parameter. It impacts the destination set stored in core and the uac
fields stored in transaction.
It can be set now with global parameter: max_branches
The old limit was 12, now it can be set in the range of 1 to 31.
Few aspects that I would like to discuss to get this refactored to fit
1) the 31 upper limit comes from tm cancelled branches bitmask, which
now is stored in an integer. Should be easy to get it to 63 (planned
after some testing that proves the concept used now is ok). Would it be
a need for even more?
2) would it make sense to specify the max number of branches per
transaction, in config, before creating the transaction? The upper limit
will be the max_branches value from the core.

Yes!
We will need this to implement the max-breadth limit at some point and
manage it. It must be very very related to what you're up to now.

/O

Post by Daniel-Constantin Mierla
3) thinking of common cases of what can be forked a lot, I thought that
we can a simplification of 2) by specifying two limits: one for initial
requests which are very likely to have many branches (think of initial
INVITE via LCR or location) and one for requests within dialog which are
likely to have one or very few branches (e.g., replicating BYE to a peer
server). Opinions?
The main benefit for 2) and 3) would be less memory usage.
Testing and feedback of the new max_branches parameter is very appreciated.
Cheers,
Daniel
--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
_______________________________________________
sr-dev mailing list
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev

[Muhammad Shahzad]

Good stuff. I am upgrading a couple of kamailio dev servers now to test
this. I will get back to you if i find any problem later today.

I think max 31 branches are fine, at least for my needs.

Max branches per transaction would be really great. Per my own
requirements, I need higher number of max branches for only a few special
cases (e.g. call over push notification, location based on-net call routing
etc.), for other cases i would hardly need 3-5 max branches.

Regarding point 3, i am not sure if i have any use of it (besides the
better performance as you mentioned), but i guess there is no harm in it
and it may be useful for other users.

Thank you.



On Fri, Oct 17, 2014 at 11:39 AM, Daniel-Constantin Mierla <

Post by Daniel-Constantin Mierla
Hello,
being brought in discussions many times, including in the recent past
days, I replaced the static define of max branches limit with a core
parameter. It impacts the destination set stored in core and the uac
fields stored in transaction.
It can be set now with global parameter: max_branches
The old limit was 12, now it can be set in the range of 1 to 31.
Few aspects that I would like to discuss to get this refactored to fit
1) the 31 upper limit comes from tm cancelled branches bitmask, which
now is stored in an integer. Should be easy to get it to 63 (planned
after some testing that proves the concept used now is ok). Would it be
a need for even more?
2) would it make sense to specify the max number of branches per
transaction, in config, before creating the transaction? The upper limit
will be the max_branches value from the core.
3) thinking of common cases of what can be forked a lot, I thought that
we can a simplification of 2) by specifying two limits: one for initial
requests which are very likely to have many branches (think of initial
INVITE via LCR or location) and one for requests within dialog which are
likely to have one or very few branches (e.g., replicating BYE to a peer
server). Opinions?
The main benefit for 2) and 3) would be less memory usage.
Testing and feedback of the new max_branches parameter is very appreciated.
Cheers,
Daniel
--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

[Juha Heinanen]

group messages (if implemented using forking) would be one app that
requires lost of branches for initial request. for this kind of app,
number of branches would need to be configurable per message. perhaps
there are better means to implement group messages.

-- juha

[Jorj Bauer]

Post by Daniel-Constantin Mierla
1) the 31 upper limit comes from tm cancelled branches bitmask, which
now is stored in an integer. Should be easy to get it to 63 (planned
after some testing that proves the concept used now is ok). Would it be
a need for even more?

We did some preliminary work to make this 63 as well (some years ago). I'm glad to see this getting traction.

I'm generally opposed to hard limits like this. There are many cases where you might want to ring a number of phones at once, and the sizes of those ring groups are currently limited by this. I suspect that once we have > 31 in our production environment, we'll quickly have a case that wants > 63.

But right now, I can only say that we have use cases > 31.

-- Jorj