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(a)lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

On Oct 17, 2014, at 5:39 AM, Daniel-Constantin Mierla <miconda(a)gmail.com> wrote: 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?