Replication for multiple FusionPBX servers

[GoogleCodeExporter]

It would be nice to see a replication feature to allow us to have multiple 
FusionPBX servers inside a pool. It's a very useful feature in a high 
availability environment.

I've built this myself but use a very customised implementation of FusionPBX, 
each time a change is made this is written to a transaction table. The 
FusionPBX servers check the transaction tables on the other systems at set 
intervals and then update the effected tables and re-sync the config (if 
required).

The recording\sound directories also sync as part of the replication job.

Original issue reported on code.google.com by shaun.st...@itec-support.co.uk on 2 Mar 2015 at 1:36

[GoogleCodeExporter]

I guess you missed the 3 day High availability and failover class.

Original comment by nysoluti...@gmail.com on 6 Mar 2015 at 6:17

[GoogleCodeExporter]

The class is the other side of the globe, I'm not in a position to attend 
unfortunately.

In my environment we build different dialplans on each servers as we have 
different gateways associated with each of the server, or they may be spread 
across different sites.

How does this tie in with what FusionPBX can already do?

Original comment by shaunjst...@aol.com on 6 Mar 2015 at 6:37

[GoogleCodeExporter]

The FusionPBX classes are also online so there is no need for you to travel to 
the otherside of the globe. I live in the UK and have been taking the class 
from the comfort of my UK home for 3 years.

With regards to routing to the different gateways you can make a condition in 
the dialplan to check the hostnames of the server then route the calls 
accordingly.

Original comment by ewsamu...@gmail.com on 22 Mar 2015 at 1:51

• Changed state: WontFix

[GoogleCodeExporter]

Thanks for the tip, I may have to look at the online classes.

In our environment we have extensions which exist on another platform (connect 
via trunk), these also exist on Fusion (virtually) so that we can setup call 
routing as if it was a real extension on Fusion. Each of these extensions has 
its own set of dialplans so for each tenancy there can be 50-200 custom 
dialplans which are built using a custom set of functions and classes.

We try to avoid touching the dialplans by building additional applications on 
Fusion to handle this, this way there's less room for human error. We've also 
edited all of the existing applications so they select an extension (via 
drop-down) as defined by the extension-range application for that tenancy.

The major problem we have is keeping it up to date with current versions of 
Fusion, as our implementation of Fusion is so bespoke it's very time consuming 
to apply updates since I have to manually process each page and make changes 
accordingly to fit in our environment.

Original comment by shaunjst...@aol.com on 22 Mar 2015 at 8:31