SIP Load Balancing (SLB) using Opensips
1. Load Balancing in OpenSIPS
The "load-balancing" module comes to provide traffic routing based on load. Shortly, when OpenSIPS routes calls to a set of destinations, it is able to keep the load status (as number of ongoing calls) of each destination and to choose to route to the less loaded destination (at that moment). OpenSIPS is aware of the capacity of each destination - it is preconfigured with the maximum load accepted by the destinations. To be more precise, when routing, OpenSIPS will consider the less loaded destination not the destination with the smallest number of ongoing calls, but the destination with the largest available slot.
Also, the "load-balancing" (LB) module is able to receive feedback from the destinations (if they are capable of). This mechanism is used for notifying OpenSIPS when the maximum capacity of a destination changed (like a GW with more or less E1 cards).
The "load-balancing" functionality comes to enhance the "dispatcher" one. The difference comes in having or not load information about the destinations where you are routing to:
- Dispatcher has no load information - it just blindly forwards calls to the destinations based on a probabilistic dispersion logic. It gets no feedback about the load of the destination (like how many calls that were sent actually were established or how many are still going).
- Load-balancer is load driven - LB routing logic is based primary on the load information. The LB module is using the DIALOG module in order to keep trace of the load (ongoing calls).
2. Load Balancing - how it works
When looking at the LB implementation in OpenSIPS, we have 3 aspects:
2.1 Destination set
A destination is defined by its address (a SIP URI) and its description as capacity.
Form the LB module perspective, the destinations are not homogeneous - they are not alike; and not only from capacity point of view, but also from what kind of services/resources they offer. For example, you may have a set of Yate/Asterisk boxes for media-related services -some of them are doing transcoding, other voicemail or conference, other simple announcement , other PSTN termination. But you may have mixed boxes - one box may do PSTN and voicemail in the same time. So each destination from the set may offer a different set of services/resources.
So, for each destination, the LB module defines the offered resources, and for each resource, it defines the capacity / maximum load as number of concurrent calls the destination can handle for that resource.
Example:
4 destinations/boxes in the LB set
1) offers 30 channels for transcoding and 32 for PSTN
2) offers 100 voicemail channels and 10 for transcoding
3) offers 50 voicemail channels and 300 for conference
4) offers 10 voicemail, 10 conference, 10 transcoding and 32 PSTN
This translated into the following setup:
+----+----------+------------------------+---------------------------------+
| id | group_id | dst_uri | resources |
+----+----------+------------------------+---------------------------------+
| 1 | 1 | sip:yate1.mycluset.net | transc=30; pstn=32 |
| 2 | 1 | sip:yate2.mycluset.net | vm=100; transc=10 |
| 3 | 1 | sip:yate3.mycluset.net | vm=50; conf=300 |
| 4 | 1 | sip:yate4.mycluset.net | vm=10;conf=10;transc=10;pstn=32 |
+----+----------+------------------------+---------------------------------+
For runtime, the LB module provides MI commands for:
- reloading the definition of destination sets
- changing the capacity for a resource for a destination
2.2 Invoking Load-balancing
Using the LB functionality is very simple - you just have to pass to the LB module what kind of resources the call requires.
The resource detection is done in the OpenSIPS routing script, based on whatever information is appropriated. For example, looking at the RURI (dialed number) you can see if the call must go to PSTN or if it a voicemail or conference number; also, by looking at the codecs advertised in the SDP, you can figure out if transcoding is or not also required.
if (!load_balance("1","transc;pstn")) {
sl_send_reply("500","Service full");
exit;
}
The first parameter of the function identifies the LB set to be used (see the group_id column in the above DB snapshot). Second parameter is list of the required resource for the call.
The load_balance() will automatically create the dialog state for the call (in order to monitor it) and will also allocate the requested resources for it (from the selected box).
The function will set as destination URI ($du) the address of the selected destination/box.
The resources will be automatically released when the call terminates.
The LB module provides an MI function that allows the admin to inspect the current load over the destinations.
2.3 The LB logic
The logic used by the LB module to select the destination is:
- gets the destination set based on the group_id (first parameter of the load_balance() function)
- selects from the set only the destinations that are able to provide the requested resources (second parameter of the load_balance() function)
- for the selected destinations, it evaluated the current load for each requested resource
- the winning destination is the one with the biggest value for the minimum available load per resources.
Example:
4 destinations/boxes in the LB set
1) offers 30 channels for transcoding and 32 for PSTN
2) offers 100 voicemail channels and 10 for transcoding
3) offers 50 voicemail channels and 300 for conference
4) offers 10 voicemail, 10 conference, 10 transcoding and 32 PSTN
when calling load_balance("1","transc;pstn") ->
1) only boxes (1) and (4) will be selected at as they offer both transcoding and pstn
2) evaluating the load :
(1) transcoding - 10 channels used; PSTN - 18 used
(4) transcoding - 9 channels used; PSTN - 16 used
evaluating available load (capacity-load) :
(1) transcoding - 20 channels used; PSTN - 14 used
(4) transcoding - 1 channels used; PSTN - 16 used
3) for each box, the minimum available load (through all resources)
(1) 14 (PSTN)
(2) 1 (transcoding)
4) final selected box in (1) as it has the the biggest (=14) available load for the most loaded resource.
The selection algorithm tries to avoid the intensive usage of a resource per box.
3. Study Case: routing the media gateways
Here is the full configuration and script for performing LB between media peers.
3.1 Configuration
Let's consider the case previously described:
4 destinations/boxes in the LB set
1) offers 30 channels for transcoding and 32 for PSTN
2) offers 100 voicemail channels and 10 for transcoding
3) offers 50 voicemail channels and 300 for conference
4) offers 10 voicemail, 10 conference, 10 transcoding and 32 PSTN
This translated into the following setup:
+----+----------+------------------------+---------------------------------+
| id | group_id | dst_uri | resources |
+----+----------+------------------------+---------------------------------+
| 1 | 1 | sip:yate1.mycluset.net | transc=30; pstn=32 |
| 2 | 1 | sip:yate2.mycluset.net | vm=100; transc=10 |
| 3 | 1 | sip:yate3.mycluset.net | vm=50; conf=300 |
| 4 | 1 | sip:yate4.mycluset.net | vm=10;conf=10;transc=10;pstn=32 |
+----+----------+------------------------+---------------------------------+
3.2 OpenSIPS Scripting
debug=1
memlog=1
fork=yes
children=2
log_stderror=no
log_facility=LOG_LOCAL0
disable_tcp=yes
disable_dns_blacklist = yes
auto_aliases=no
check_via=no
dns=off
rev_dns=off
listen=udp:xxx.xxx.xxx.xxx:5060
loadmodule "modules/maxfwd/maxfwd.so"
loadmodule "modules/sl/sl.so"
loadmodule "modules/db_mysql/db_mysql.so"
loadmodule "modules/tm/tm.so"
loadmodule "modules/xlog/xlog.so"
loadmodule "modules/uri/uri.so"
loadmodule "modules/rr/rr.so"
loadmodule "modules/dialog/dialog.so"
loadmodule "modules/mi_fifo/mi_fifo.so"
loadmodule "modules/mi_xmlrpc/mi_xmlrpc.so"
loadmodule "modules/signaling/signaling.so"
loadmodule "modules/textops/textops.so"
loadmodule "modules/load_balancer/load_balancer.so"
modparam("mi_fifo", "fifo_name", "/tmp/opensips_fifo")
modparam("dialog", "dlg_flag", 13)
modparam("dialog", "db_mode", 1)
modparam("dialog", "db_url", "mysql://opensips:opensipsrw@localhost/opensips")
modparam("rr","enable_double_rr",1)
modparam("rr","append_fromtag",1)
modparam("load_balancer", "db_url","mysql://opensips:opensipsrw@localhost/opensips")
route{
if (!mf_process_maxfwd_header("3")) {
sl_send_reply("483","looping");
exit;
}
if (!has_totag()) {
# initial request
record_route();
} else {
# sequential request -> obey Route indication
loose_route();
t_relay();
exit;
}
# handle cancel and re-transmissions
if ( is_method("CANCEL") ) {
if ( t_check_trans() )
t_relay();
exit;
}
# from now on we have only the initial requests
if (!is_method("INVITE")) {
send_reply("405","Method Not Allowed");
exit;
}
# detect resources and do balancing
if ($rU=~"^1") {
# looks like a Conference call
load_balance("1","conf");
} else if ($rU=~"^2") {
# looks like a VoiceMail call
load_balance("1","vm");
} else {
# PSTN call, but the GWs supports only G711
# for calls without G711, transcoding will be used on the GW
if ( !search_body("G711") ) {
load_balance("1","transc;pstn");
} else {
load_balance("1","pstn");
}
}
# LB function returns negative if no suitable destination (for requested resources) is found,
# or if all destinations are full
if ($retcode<0)>
