Sorry, I should have been more specific.
I used the feature a year ago and if my memory serves well, here are
the issues that I encountered:
- if the sum of all weights is less then 100, then the remaining
weight is assigned to the first entry (if one entry has a weight of 10
and the second one a weight of 20, then the real weight will be 80%
for the first entry and 20% for the second one)
- if the sum of all weights is more then 100, then only the first 100
are taken into consideration (if first entry has a weight of 80 and
the second one a weight of 80, then the real weight will be 80% for
the first entry and 20% for the second one)
Maybe, for now, it's enough to document this, if the behavior is still the same.
I haven't tested the feature in a long time, this is what I remember.
Hope this helps,
Ovidiu
On Fri, Dec 12, 2014 at 4:49 AM, Daniel-Constantin Mierla
<miconda(a)gmail.com> wrote:
On 11/12/14 16:29, Ovidiu Sas wrote:
Also 'weight' attribute is not fully
documented. There are missing
examples and details about how it works.
IIRC, the sum of all weights must be 100, otherwise strange things happens.
Can you give some examples of such strange things, because otherwise it
is impossible to guess where to look for.
Daniel
On Thu, Dec 11, 2014 at 10:18 AM, Olle E. Johansson <oej(a)edvina.net> wrote:
On 11 Dec 2014, at 16:15, Daniel-Constantin
Mierla <miconda(a)gmail.com> wrote:
Hello,
it is supposed to be the upper limit for call load distribution -- if
number of active calls gets to it, no new call should be sent there. If
not implemented, then I forgot about it.
I think there's a risc that your
latest statement is true. If so, this is a gentle
reminder ;-)
/O
Cheers,
Daniel
On 11/12/14 15:41, Olle E. Johansson wrote:
> Hi!
>
> In the source code for dispatcher there is parsing of a predefined attribute called
"maxload".
>
> It's not documented and I don't see it used anywhere in the source code. Only
in output of
> attributes and debug code.
>
> Anyone that knows more? Can we remove this unused attribute or is it planned for
future glory?
>
> /O
> _______________________________________________
> sr-dev mailing list
> sr-dev(a)lists.sip-router.org
>
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda -
http://www.linkedin.com/in/miconda
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda -
http://www.linkedin.com/in/miconda
--
VoIP Embedded, Inc.
http://www.voipembedded.com