23 Oct
2014
23 Oct
'14
3:49 a.m.
My team is very interested in this solution so I tried to size up the
effort. My analysis revealed it would take a major redesign to support
this since many static structures, like struct cell, depend on it. If I'm
wrong, we would really like to see this changed to dynamic.
Bob
On Tue, Oct 21, 2014 at 11:20 AM, Alex Hermann <alex(a)speakup.nl> wrote:
On Friday 17 October 2014, Daniel-Constantin Mierla
wrote:
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?
I suggest to skip option 3, as 2 is a superset of it. No need to introduce
another limited interface.
I would prefer a different solution though: remove the maximum altogether
and dynamically allocate branch/uac structures. A lot of memory is wasted
now because memory is always allocated for the maximum number of branches
even though they're rarely being used.
--
Alex
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev