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 <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@lists.sip-router.org > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev >
_______________________________________________ sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
