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

[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 <
miconda at gmail.com> wrote:

> 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
>
> --
> Daniel-Constantin Mierla
> http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
>
>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-dev/attachments/20141017/c3db6fc5/attachment.html>