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.
Don't take it wrong, Fail2ban is an excellent tool to prevent brute-force attacks. However, sometimes there are production scenarios where you need to keep your door slightly open. It is the classic dilemma security vs utilization; in pro fo the security, you may have a lot of countermeasures that will block many things, depending your paranoia, you may close as much as you want to a point that you may start to have false positives; in pro of the production you may need to keep up and running your service no matter what, you even will need to accept some brute-force attacks from "clean" IPs.
If you don't know, Homer is a very powerful tool that VoIP companies use to analyze what happened (or what is happening win semi-real-time) in the PBX. You can analyze what happened in a call reported one hour ago without disrupting the customer (sounds awesome right?).
However, the not so bright side of Homer is that it needs a lot of babysitting. Sooner than later, because of the way it works, your database will be overloaded. The more calls you have the more information Homer will need to store, then you will need a really huge server. Another thing you must know is that Homer needs a lot of love, the vanilla installation won't help you a lot. You must set up the reports, which could take some time to master.
I have a solution if you are okay by giving up some few things.