We have multiple sites (currently 8). We have a Mesh style VPN connecting all sites. Therefore each PBX can directly contact each other PBX. We have a 6 digit extension plan that accommodates our projected growth.
For intersite calling we are using IAX2 trunks to connect each site to each other site.
Our struggle is every time we add a new site, we then have to connect to every other site and add an IAX2 trunk to connect to the new site. When we have say 50 offices, this means that all 50 PBXs will have to have IAX2 trunks to talk to the other 49 sites. Is this scale-able?
We currently like having onsite PBXs at each site. it gives us reliability. It is currently part of our model. PBX, AD, FS and Print Server at each site.
Is there a better way? We considered routing all calls to our central server (in a colo), but many of our sites are on Cable connections. We are concerned that routing all Intersite calls to the central server and then to the destination site could increase latency and jitter to an unacceptable point.
Is there some sort of a “Router” approach? Some central location that looks up which server the dialed extension sits on and then directs the call directly to that server, without actually routing the call through the intermediary server?
If there is not a “router” type approach, is there a scripting resource that we could leverage to “Auto-Add” the new IAX2 trunk (when we bring on a new site) to all existing servers? it would save our team hours of work.
The hub and spoke model you propose works great. Central PBX “router” that can handles your PRI connections or SIP LD trunks for your offices, interoffice routing, fantastic. Latency? I doubt it would be a consideration assuming you run a reasonable capable network. You can push calls through multiple asterisk servers and nobody will notice. We have a PBX in Asia that are +200ms (Asia<->North America) and we have nearly zero problems with calls. My point is 200ms with a voip call does work.
Hub and spoke adds some dependency on the router PBX but you can can mitigate this with VM infrastructure or additional sites. My point is it definitely works (and the call connection time experience to the end users would be instant).
In conjunction with your router approach for failover or just an alternative way to deal with what could be hundreds of iax trunks in your current configuration, how about you logically group your PBX’s into smaller groups of 4, which a single trunk between each, PBX1 -> PBX2 -> PBX3 -> PBX4 -> PBX1
Just because you have 8 or 100 PBXs, it doesn’t necessarily mean that every PBX needs to be able to directly send a call to every other PBX.
PBX1 needs to call PBX4, the call can easily pass through 2 & 3 to get there.
Its a little out of the box approach, but it does work!
Thank you for this response. It is good to know Hub and Spoke does work. I tried to do some forum research before posting and several early posters were very concerned about Hub and Spoke latency/jitter when MetroE or MPLS is not used between all sites.
Are there any settings or special configuration changes you would recommend to make a hub and spoke model work? Currently all other network services, other than phones, function in Hub and Spoke.
Also, all of our FreePBX instances are running on VMWare eSXi VMs. This makes our management cost so much less per site.
Each site still gets it’s own SIP Trunks for inbound/outbound/fax external calling. The entire Phone VLAN is QoS and bandwidth prioritized.
I personally never made any special changes to get it to work, straight up FreePBX install. The DUNDi route might be more in tune with your type of installation though.
@dickson@arielgrin Thank you both! Both solutions were exactly what I was looking for.
After doing quite a bit of thinking about it, we are going to attempt a full “Hub and Spoke” model. We ran testing today when dialing an extension to another office and routing it through the colo instead of direct. It seemed to work well.
By moving from “mesh” to “Hub and Spoke” it will allow use to use smaller firewalls at each site when we scale to 50 or more locations. it will also cut down on management needs.
I do love the DUNDi idea. It is perfect for the mesh approach, but because we are going to attempt to move away from mesh, routing is going to work.
As far as I know, but might be wrong, DUNDi should not depend on whether you choose mesh or hub and spoke, in fact if I remember correctly, DUNDi could be seen as a protocol for call routing, you could set up a central server as the main directory and all secondary servers configured to route calls through the central server, kind of a star topology. Then again, I might be wrong.