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.

Hi there. So this is the deal. As many of you know, I have been running a Billing for FusionPBX Funding to convert the code to Opensource. As a special, and a win-win to everybody, I have lowered down the funding goal from 22400 CAD to 7000 CAD (68.75% off). The challenge is the following: if by December 31st, 2017 23:59:59 this new low goal is reached, the source code will be published by January 6th, 2018 latest. If the goal is not reached the original goal will be restored on January 1st, 2018.

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:

  • check_fs_registered: which it sends a signal if you do not have enough endpoints registered
  • check_fs_registered_cap: which it sends a signal if you have too many endpoints registered
  • check_fs_channels: which it sends signals if too many channels are being used

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




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.