As many people have asked me about the load balanced cluster; I have found that one of the most common issues is handling the correct way the incoming calls. The issue comes with some carriers as some won't allow hostnames and others allow a basic round-robin balancing which may present connectivity and delaying issues if the node in the balancing cluster is down.
I have come with a solution. It is basically adding an (at least 2-nodes) high availability cluster that acts as an SBC. You can think on this cluster as an extension of the load balanced cluster. I will explain how it works.
The first answer is because of personal preference. However, I have found that FreeSWITCH with the LUA script is very powerful. Coding with LUA you can do complex decisions, consult multiple and complex database queries, use Memcached and many other things. I do not doubt you can do it with Kamailio, but the LUA way (using FusionPBX libraries) is way too easy to do.
This deployment has three sub-clusters:
The SIP Proxy Cluster consists of a little high availability cluster (also known as floating IP) that offers a single point of contact to the carriers. The cluster nodes are FusionPBX nodes that share the same database that the SIP Cluster (in load balanced mode) connects. This node has an LUA script that consults the shared information in the database cluster to do an educated guess. I will explain the scenarios in a moment.
This is the best case scenario.
When an incoming call arrives, it will hit the floating IP from the SIP Proxy Cluster. The proxy node will analyze some information from the database such as dial plans, call detailed records and current registrations. After that, the node will forward the SIP INVITE signal to the proper SIP node (where the user is registered).
As you see, the RTP flow is between the carrier and the SIP node. The SIP Proxy node does not touch the RTP.
Now, the worst case scenario. Sometimes, the SIP Proxy node will not be able to know where the user is registered. Therefore, the call flow is as follows.
If the SIP Proxy node forwards to a SIP node where the user is not registered, the SIP node will forward the SIP INVITE signal to the correct peer. This is the same scenario as an inter-PBX call. The RTP will flow between the carrier and the SIP node.
Nothing to say, the SIP node interacts directly with the carrier.
The first thing a cluster holder needs to remember is that the SIP Proxy Cluster is a high availability cluster on top of a load balanced cluster. So, first let's talk about the pros:
Now the cons:
Some side effects could be:
Easy, just send me a text. I am pretty sure we can work something out.
blog comments powered by Disqus