So, if you are a lucky one of having a FusionPBX VoIP cluster and you are sort of paranoid about the availability of your service, you may think about the ultimate countermeasure to mitigate an unavailability risk. Your answer is the deployment of a DRP.
A Disaster Recovery Plan is more than just having an emergency server. But in this article, I will describe just the technical part of deploying this emergency server.
I always deploy my FusionPBX Clusters with a MariaDB Galera cluster on the back. Then, I will write about it.
Just another beautiful day to have databases issues. This time, I have a beautiful MariaDB Galera Cluster running as a backend of a FreeSWITCH Cluster. It seems that operation does not take a single rest and it is keeping adding new extensions. New extensions mean more calls, which it can be translated to more databases queries and connections.
The issue here is not changing the max_connection value in the database configuration file. The issue, as I see, is that doing that will waste memory that could be used somewhere else. Therefore, the value needs to increased gradually; at some point, this will not be enough and more tunings, including database register cleaning might be done. For now, just let's configure an alert that will tell us when it is a good time to start thinking what to do.
When communication with your FreeSWITCH breaks abruptly, it is a common symptom you have what we call zombie calls. A zombie call seems to be listed when you do show channels or show calls command, and it seems to still be using system resources.
Today, I have published in OKay's RPM repository RPMs for the Nagios FreeSWITCH plugin 0.0.4. This is a very simple Nagios plugin that connects to your FreeSWITCH through the fs_cli application to get useful information.
Release 0.0.4 has the following plugins:
I want to thanks to T5 Telecom for sponsoring the release 0.0.1 and VoipLy for 0.0.4.
RPM's are available for CentOS 6 and 7. You can find it doing a yum search nagios-plugins-freeswitch
IP Authentication is the fact of linking a sip extension against a set of known IP's. Therefore, any call signaled to or from a given IP will be linked to a linked SIP account. IP Authentication is needed if you want to configure your PBX as a Class 4 PBX. If you want to know more about the difference between Class 4 and Class 5, read the article I published some years ago in this blog.
So, our scenario is our FusionPBX (pbx-b) is the carrier of another PBX (pbx-a). The pbx-a uses pbx-b as a carrier configured without registration (IP authenticated). Users register into pbx-a. When an outbound call is done, the user signals the authenticate INVITE to pbx-a, then pbx-a forwards the SIP INVITE without authentication. Finally, pbx-b forwards the INVITE to the upstream carrier.
FusionPBX by default is shipped as a Class 5 PBX. You will need to do some web tuning to make it work as a Class 4 PBX. In this article, I will write about the SIP Authentication, which it is one of the many steps you need to do.
Configuration is pretty straightforward. Let us say you have a brand new deployment and you have configured the customer1.inside-out.xyz tenant with an extension pbx1 (I recommend using alphanumeric extensions when dealing with Class 4 PBX configuration).
Within FusionPBX WEB GUI go to menu Advanced -> Access Control and create one ACL with a deny default policy. Add in that ACL all the known IP's for customer1 tenant. Take note of the ACL name, you will need it later.
Edit the pbx1 extension and modify the Auth ACL field, put there the ACL name.
You are done. In your other PBX configure your FusionPBX as a carrier without registration.