There are various ways that people have approached the issue of load balancing with Asterisk. One of the tools used for load balancing that has really taken off is using DUNDi. There are various approaches for integrating DUNDi into your Asterisk network, and I do not intend to go into them in detail now. However, i would like to share something that I just added to Asterisk trunk that could prove to be another useful tool for using DUNDi for load balancing.

When a DUNDi query is sent out, all of the responses that come back carry a weight. This weight is used for sorting the responses to figure out which order to try them. Previously, this weight could only be a static value set in dundi.conf. Now, it can be determined dynamically.

Here is an snippet from the sample DUNDi configuration file that demonstrates the new feature:

;
; Weights for mappings can be set a few different ways:
;
; 1) It can be set as a static number.
;testmap1 => context1,222,IAX2,guest@peer1/${NUMBER}
;
; 2) It can be an Asterisk global variable.
;testmap2 => context2,${DUNDITESTVAR},IAX2,guest@peer2${NUMBER}
;
; 3) It can be retrieved using a dialplan function.  This can be extremely
;    useful if you want to let an external script decide what the weight
;    in a response shouuld be.
;testmap3 => context3,${SHELL(echo 123)},IAX2,guest@peer3/${NUMBER}
;
; Note than when using a global variable or dialplan function to set the
; weight for a mapping, that response caching should be disabled if you
; plan for these values to change frequently at all.  If the results are
; cached, then any change in value will not take effect until the cache
; has expired.
;

The most interesting example here is the ability have a custom script to determine the weight used in the response. This script could do something as simple as return the number of calls currently active on the system. Then, when a query is sent out, the responses would carry a weight with how many calls each server is currently handling. The highest ranking result would be the one from the server currently servicing the fewest number of calls.

Thanks to blitzrage and jsmith in #asterisk-bugs on IRC for giving me the idea to go implement this.

--
Russell