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 < mico...@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@lists.sip-router.org > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users >
_______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
