Traffic balancing – the insertion into the SIP flow

In the last post we talked about the different available flavors of traffic balancing with OpenSIPS. But picking the right balancing logic is just the first step. The next step, and an important one, is to decide how you want to have the balancer inserted into the SIP flow (between the end-points and the main servers). I’m saying this is an important step (and decision) because it has major repercussions over the overall performance of your system – the traffic on the balancer, the additional delay in the signaling, the processing load on the balancer, the network topology and many more.

I mentioned that there are multiple options when comes to inserting a balancer in your SIP flow. And if we stay at the SIP level, we can classify the balancers depending on how they deal with the SIP traffic: stateless, transaction stateful or dialog stateful. And more important, let’s see what are the dependencies / constraints between the balancing logic you chose and the balancer insertion in the SIP flow.

Dialog stateful insertion

Let’s start with the full insertion, the dialog stateful insertion. This means that the balancer is in the SIP path for the whole dialog (SIP call) lifetime –  for its creation, update and termination. All the SIP messages (requests and replies) of a call will go via the balancer, and there is no direct communication between the end-points and the main servers.

This is the most load & traffic intensive insertion, but is also the simplest and most powerful. It is simplest as all traffic is handled in the same way (via balancer). It is powerful as it allows the addition of advanced features on the balancer, like topology hiding, protocol conversion, security checks, traffic inspection, CDR generation, traffic statistics/analytics  and others.

In terms of OpenSIPS usage (as balancer), in order to anchor the entire call into OpenSIPS, you will have to do record routing or to use topology hiding for the INVITE (when the call starts).

Such full insertion in the SIP flow is suitable with all the balancing flavors – load based balancing (with internal o or external feed), probabilistic or weight based distribution.

Nevertheless, if you want to implement a load based balancing logic, it is a must to do a full balancer insertion (for the whole dialog lifetime) as the balancer has to be aware of how many calls are ongoing via each main server.

Transaction stateful insertion

The SIP transaction stateful insertion means that the balancer is inserted in the SIP flow only for the initial transaction, for the INVITE (for the request that actually routes the call) and its replies. Once the routing is done (and the main server is selected), the balancer is getting out of the SIP call – the following/sequential SIP requests like re-INVITE or BYE will not pass through the balancer, but they will go directly between end-points and main servers.

This kind of insertion is a good compromise between required resources and the balancer capabilities (as logic). As only part of the traffic will go via the balancer, less hardware and bandwidth are required. Still being transaction stateful, the balancer is able to perform failover/fallback between the main servers (hunting via sequential forking) – this ensure that any new call will land on an active main server.

In terms of OpenSIPS usage (as balancer), you just have to use stateful relaying for the INVITE requests. And of course, not to do any record route, to avoid being inserted in the call flow. The TM (transaction module) via failure_route will allow you perform main server failover – to detect when a server reports a failure (or doesn’t reply at all) and to send the call to another server.

The transaction stateful insertion is suitable for any probabilistic or weight based distribution with the additional benefit of doing the server failover.  Still, this insertion does not fit wit the load based balancing, as we do not have the full call on the balancer.

SIP stateless insertion

The SIP stateless insertion is the the most lose one, the minimal possible insertion. The balancer is visited only by the initial request. Nothing more, not even the replies of the initial request. Once the balancer forwarded (in stateless mode) the INVITE to a main server, it will be the duty of this server to send back the replies, directly to the end-point. This scenario pushes to the limits the SIP standards – the asymmetric request and reply exchange.

The stateless insertions consumes the minimum possible of resources, so it is the most scalable. Nevertheless, it is the most limited in terms of the balancer capabilities – this cannot do any additional features like protocol conversion, topology hiding or CDR. It is not even able to do failover between the main servers, as the balancer will never receive any kind of traffic back from these servers, so it will not be aware of their status. Basically, the entire traffic through the balancer will go in only one way, from the end-points to the main servers.

In terms of OpenSIPS usage (as balancer), all you have to use is the stateless relaying function for the INVITE requests – nothing more, no replies, no sequential requests.

The SIP stateless insertion works for any probabilistic or weight based distribution, but it cannot offer support for server failover/fallback. Of course, the load based balancing is out of the question.

Summary

Insertion	Traffic	Processing	Load Balancing	Probabilistic Balancing	Server Failover
Dialog stateful	100%	100%	Yes	Yes	Yes
Transaction stateful	70%	60%	No	Yes	Yes
Transaction stateless	20%	30%	No	Yes	No

Legend:

• Traffic – amount of SIP traffic handled by the balancer, where 100% is the entire traffic of a call (INVITE, ACK, BYE + requests);
• Processing – the processing effort (as CPU) , where 100% is the effort for routing all SIP packets in a call;
• Server Failover – if the balancer can provide failover / fallback for the main servers.

Conclusions

When you take the decision of placing a traffic balancer in your network, there is a sum of factors that you have to consider:

• what the is the desired balancing logic (load, weights, random)
• what is the way the balancer should be inserted (resources, delays, more traffic)
• what other features you want to have on the balancer (CDR, Topo Hiding, security)