CasperJS needs PhantomJS 1.9. My RPM will download this dependency for you.
RPM's are available for Centos 6 and 7. And you can find it if you type yum search casperjs.
Music on hold (MoH) is the stream you listen when you are being transferred, or when you are in a queue. If my understanding is right, it happens that MoH is continuously reviewed and played within the FreeSWITCH. A single server with many MoH queues will be using/wasting your CPU. Here it is what I have figured out to workaround this situation.
If you have a cluster with many tenants (aka domains), and each user is able to upload its own music on hold you soon will realize that your CPU's utilization starts growing like crazy. I used to have one server in which the FreeSWITCH daemon was reported to use 30% of CPU constantly even without 1 extension registered. If I unload the mod_local_stream module, FreeSWITCH CPU utilization drops to 1%. Insane right? But it clearly tells me it has to be with MoH. Of course, I was loading 99 queues.
Here it is what I did.
If you have installed FusionPBX from the installation scripts you will notice it has already some fail2ban configurations. If you are using my RPM's, it doe not include any kind of this configuration as my philosophy is to specialize the package to do one thing, not a do-it-all. Anyway, if you are only using FusionPBX with FreeSWITCH as a personal PBX those rules should be more than enough.
I recommend you do a quick reading of my previous fail2ban post where I describe the gap between Layer 7 exposures versus Layer 3 controls. You will understand my thinking.
If you are being more serious about your PBX or you are running a business you will find at one point those rules are not enough. I will explain myself a little more. As a commercial service, your exposure to the world is bigger; your domain is advertised, telephones do DNS, HTTP and SIP request to your servers and sooner than later you will start getting your first kiddy scripts targeting your servers. As you grow, you will find your customers are far to be technical; they do many dumb things (wrong password because they changed something on the service or inside jobs from tech staff are some examples) which it leads to fail2ban rule applications.
There is nothing more harmful than a bad review from an ignorant customer. They do not know why they are being blocked. So, here is where we need to tun fail2ban and add some important information to pre-block offending IP's.