Invoicing in A2Billing is not the easiest thing in the world to manage and can be overly complicated if all you want is a figure for the monthly call spend for each A2Billing customer.

I got sent the following script by a business associate and thought you might find it useful.

It e-mails a report (that could be scheduled to run monthly) detailing each A2Billing customer’s call spend for the previous month. These figures could then be used in your existing invoicing system.

As always you use at your own risk and I would strongly urge you to check that the figures it produces are as expected. You will need to change the database details to match your system. You can probably find these in /etc/a2billing.conf.

Check out Lansalot Ltd @ www.lansalot.co.uk

Continue reading ‘A2Billing — Monthly report detailing call spend’ »

In part1 and part2 of this post we look at setting up Master/Slave MySQL redundancy and also A2Billing load balancing.

In this last post we are going to look at what to do if we need to fail over to the Slave MySQL database we set up in part1. This requires 2 steps -

• Tell the Slave MySQL is is now the Master
• Point the Asterisk/A2Billing servers to the Slave (new Master) server

On 2.2.2.2 – change MySQL from a Slave to a Master MySQL server and configure Asterisk/A2Billing to use it

Stop the Slave service running -

Continue reading ‘A2Billing – MySQL Master / Slave and Asterisk load balancing – Part 3’ »

In part 1 of this post we went through the configuration of MySQL replication plus configuring 3 A2Billing/Asterisk servers to use a common MySQL database.

Now for some simple load balancing.

Load balancing round robin DNS

If you are just making outbound calls then the simplest way to load balance is to use round robin DNS. Here you would create a DNS name for the A2Billing/Asterisk servers and assign multiple IP addresses to it. I would also suggest creating individual entries for the servers also.

So, for the example in part 1 of the guide, I might create

• red1.sysadminman.net = 1.1.1.1
• red2.sysadminman.net = 2.2.2.2
• red3.sysadminman.net = 3.3.3.3
• red.sysadminman.net = 1.1.1.1   2.2.2.2   3.3.3.3

By default (although I would test this is what your DNS provider does) when someone queries red.sysadminman.net they will get all three entries back, but with the primary address being rotated each time a query is made.

Using DNS in this was has some limitations that you should be aware of -

• DNS changes can take a while to propagate. You should look at having a low TTL. This could be an issue should one of the servers fail.
• If a server becomes unavailable the client may not automatically re-resolve the updated DNS entry

Below are instructions for setting up A2Billing with a MySQL Master/Slave database. In this configuration the A2Billing database is replicated to a standby/slave server. Whilst it would require a manual failover to the standy server, the configuration is pretty simple and easy to manage.

It also walks through setting up A2Billing load balancing across multiple Asterisk servers. This relies on Asterisk/A2Billing being configured to use RealTime, which it is by default on the SysAdminMan template.

All 3 servers used were built using the SysAdminMan VPS template. You will need to change IP addresses throughout the instructions to match your server IPs. The test servers used are -

• Server 1 – IP Address 1.1.1.1 – Master MySQL server + Asterisk server
• Server 2 – IP Address 2.2.2.2 – Slave MySQL server + Asterisk server
• Server 3 – IP Address 3.3.3.3 – Asterisk server

While the instructions are quite long the outline of what is happening is -

• Open ports in the firewall
• Configure server 1 as the Master MySQL database
• Export the mya2billing database from the Master server and copy it to the slave
• Configure server 2 as the Slave MySQL database
• Import the database from the Master server and start the replication
• On all 3 servers configure Asterisk and A2Billing to use the Master database

Continue reading ‘A2Billing — MySQL Master / Slave and Asterisk load balancing — Part 1’ »