Re-implement load distibution algorythm to use purely statistical approach with system PRNG (pseudo-random number generator). Turns out, that with relays operating close to its max capacity for large portions of its active time, effective  weights would be very fluid. As such there is no value in perceived persistancy/determinism from using hashing of call_id. We don't actually rely on such properties of pick_proxy() method to DTRT, so stop pretending that we do. Our previous algorythm effectively implemented poor-man's PRNG, with unknown (i.e. most likely very poor) statistical properties. What needs to be done instead, is to implement session binding persistency, so we can sustain restart of the "rtp_cluster" without any negative effect on its performance.
Re-implement load distibution algorythm to use purely statistical
approach with system PRNG (pseudo-random number generator). Turns out,
that with relays operating close to its max capacity for large portions
of its active time, effective  weights would be very fluid.
As such there is no value in perceived persistancy/determinism
from using hashing of call_id. We don't actually rely on such
properties of pick_proxy() method to DTRT, so stop pretending that
we do. Our previous algorythm effectively implemented poor-man's
PRNG, with unknown (i.e. most likely very poor) statistical
properties. What needs to be done instead, is to implement session
binding persistency, so we can sustain restart of the "rtp_cluster"
without any negative effect on its performance.

In addition, use "relative capacity utilization"  of each member
to scale weights dymanically, which should result in smoother load
distribution under the load.

Also separate portion of the code which deals with situation when
no active proxy that is below its nominal capacity, so that we can
refine it later. Right now it just picks least loaded proxy out of
those.

And last but not least, in the case when we have no active proxy at
all, whine loudly into the log. We also probably need to relay error
back to the client.

AVOXI/b2bua,sippy/b2bua,AVOXI/b2bua,sippy/b2bua