<div dir="ltr"><div><div>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.<br><br></div>I think max 31 branches are fine, at least for my needs.<br><br></div>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.<br><div><div><div><br></div><div>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.<br></div><div><br></div><div>Thank you.<br><br><br></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Oct 17, 2014 at 11:39 AM, Daniel-Constantin Mierla <span dir="ltr"><<a href="mailto:miconda@gmail.com" target="_blank">miconda@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello,<br>
<br>
being brought in discussions many times, including in the recent past<br>
days, I replaced the static define of max branches limit with a core<br>
parameter. It impacts the destination set stored in core and the uac<br>
fields stored in transaction.<br>
<br>
It can be set now with global parameter: max_branches<br>
<br>
The old limit was 12, now it can be set in the range of 1 to 31.<br>
<br>
Few aspects that I would like to discuss to get this refactored to fit<br>
the best of common scenarios:<br>
<br>
1) the 31 upper limit comes from tm cancelled branches bitmask, which<br>
now is stored in an integer. Should be easy to get it to 63 (planned<br>
after some testing that proves the concept used now is ok). Would it be<br>
a need for even more?<br>
<br>
2) would it make sense to specify the max number of branches per<br>
transaction, in config, before creating the transaction? The upper limit<br>
will be the max_branches value from the core.<br>
<br>
3) thinking of common cases of what can be forked a lot, I thought that<br>
we can a simplification of 2) by specifying two limits: one for initial<br>
requests which are very likely to have many branches (think of initial<br>
INVITE via LCR or location) and one for requests within dialog which are<br>
likely to have one or very few branches (e.g., replicating BYE to a peer<br>
server). Opinions?<br>
<br>
The main benefit for 2) and 3) would be less memory usage.<br>
<br>
Testing and feedback of the new max_branches parameter is very appreciated.<br>
<br>
Cheers,<br>
Daniel<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Daniel-Constantin Mierla<br>
<a href="http://twitter.com/#!/miconda" target="_blank">http://twitter.com/#!/miconda</a> - <a href="http://www.linkedin.com/in/miconda" target="_blank">http://www.linkedin.com/in/miconda</a><br>
<br>
<br>
_______________________________________________<br>
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list<br>
<a href="mailto:sr-users@lists.sip-router.org">sr-users@lists.sip-router.org</a><br>
<a href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users" target="_blank">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users</a><br>
</font></span></blockquote></div><br></div>