The Load Balancer is a very simple proxy that is useful in SIP-based VoIP installations where there are multiple ingress proxy servers.
The Load Balancer permits pooling these servers, thereby eliminating the need to balance user demands for connectivity through a complicated provisioning algorithm. All users can send their INVITEs and REGISTERs to the same SIP URI and the Load Balancer will assign ingress proxy servers dynamically to each transaction. In this way, the traffic load is balanced over a pool of proxy servers based on the real-time demand for services.

The Load Balancer receives SIP requests from endpoints on a port that is specified in the configuration file(?). It then forwards the request to the next available ingress proxy server that appears on a list of associated proxy servers that is created at compile time(?). The Load Balancer receives responses on a different port, and then forwards them back to the originators of the requests.

The Load Balancer adds itself to the Via header of requests to enable responses to return before being sent to orginating endpoint. This only works with SIP messages sent over UDP (User Datagram Protocol).

When used in a high reliability mode, ideally, it would be configured so that multiple copies of it were running concurrently, all listening on the same virtual IP address for incoming SIP messages. A switch or router would then randomly send UDP traffic to any instance of the Load Balancer. This type of reliability could also be achieved with the virtual router utilities found within the Linux operating system. If these tools were used, a proxy could be selected to receive the SIP request along with all future messages serving the same dialog.

Stickyness is computed by hashing one of either the CallID, To, From, or SIP URI. Collisions are handled by using the same entry to permit two calls that hash to the same output will be sent to the same proxy.

The stickyness DB is syncronized by flooding across a group of proxies. Stickyness information eventually expires - the time for this depends on the application. If it only needs to go to the same proxy for the duration of the dialog, it can be set very low (60 seconds). If it needs to stay up for the length of the call then session timers should be used for the call and set to the same value as the stickyness expiration - for example, 10 minutes.

Every proxy can listen for peer connections. If there are mutiple proxies running on one server, each proxy should listen on different ports for example, 1000, 2000, 3000. The Load Balancer initates peer connections with source ports that are between the port it is listening to and another port number that is 1000 greater. Peer
connections are intiated between port numbers (n)000 and (n+1)000, e.g. 1000 and 2000.

When a peer receives a connection, it looks at the 1000's part of the soruce port to figure out which peer connected to it. Any server can request connections to others. It will keep trying periodically until a connection is established.

When the Load Balancer first comes up, the number of synchronized records is computed by on both sides and then, each side sends this number to its peer. As well, any time there is a change to the information base, the change is sent to all peers that are currently on-line. This includes changes learned through peering so the the
information floods.

The information is all marked with a timestamp of when it was first created. This requires loose time syncornization between the machines. NTP (Network Time Protocol) is assumed. Conflicts are resolved by giving precidence to the latest modification. Synchronized data is transmitted in blocks between peers to minimize the impact on performance.