Multiple 3CX system installation on SD-WAN network

[dashbrook]

I am considering the installation of 4 3CX PBX systems for different office locations. One office is located in the UK. Our offices are connected using an SD-WAN network based upon MPLS and Internet connectivity using Cisco routers, Fortinet firewalls and SilverPeak EdgeConnect SD-WAN hardware. The 3CX systems will be replacing a centralized Cisco Call Manager system currently hosting 160 phones. I want to decentralize the system to eliminate the central system dependency for phone operations. We will be replacing our Cisco 7971 phones with Yealink T46S units. We have a 3CX consultant in mind but would like to do the majority of the work internally.

Has anyone installed a system in a similar environment and can you provide any advice?

 

[VoIPTools]

Historically I have been a proponent of decentralizing your phone infrastructure. There continues to be valid arguments in support of this architecture:

• As you have noted, decentralizing your phone infrastructure minimizes the scope of network or server failures
• Makes it easier to handle geographical considerations. For example, 3CX has some limitations regarding holidays. If you have holidays that are only applicable for parts of your organization, you may find it necessary(in a single-server scenario) to create Call Flow Designer application to handle call routing based on your own holiday look-up rather than relying on a global holiday schedule.
• Because the global on-hold music (as the name implies) is global for the entire PBX, if you want/need different on hold music per location, you will want to have separate servers.
• There is only one "operator" extension per PBX so that's a consideration as well. There are ways to work around this, but it requires some additional considerations to address this.

There are a number of arguments for a centralized PBX. In an era where hosted servers has become the norm, with highly redundant and scalable infrastructures, you may find your reliability increases with a centralized server rather than the opposite. I know that is counter intuitive, but an argument can be made for this. Here are a few considerations:

• An organization-wide company directory
• Global contact lists (internal and external)
• Need fewer total simultaneous calls (shared pool)
• Ease of administration (one backup, etc.)

This is only a small list of considerations, but these are some considerations that come to mind. There are more considerations to be sure.

 

[rgruber]

Do the 160 users not call each other? You will need to have a more centralized like you have now and use software 3CX SBC at each of the remote locations for best results. There are a couple ways to do it, but this is probably the best way. You have a lot going on here, your SD-WAN can help manage the voice traffic. With the new SD-WAN technologies, why do you need the MPLS lines? Are the Fortigates not granular enough for you on the SD-WAN side? Asking because you could go with a cheaper bandwidth and maintain the same quality dropping the MPLS and using the FortiGate to eliminate all your extra hardware/software.

Back to your original question unless your locations will be separate, probably favor the centralization. Hope that helps.

 

[cobaltit]

I am considering the installation of 4 3CX PBX systems for different office locations. One office is located in the UK. Our offices are connected using an SD-WAN network based upon MPLS and Internet connectivity using Cisco routers, Fortinet firewalls and SilverPeak EdgeConnect SD-WAN hardware. The 3CX systems will be replacing a centralized Cisco Call Manager system currently hosting 160 phones. I want to decentralize the system to eliminate the central system dependency for phone operations. We will be replacing our Cisco 7971 phones with Yealink T46S units. We have a 3CX consultant in mind but would like to do the majority of the work internally.

Has anyone installed a system in a similar environment and can you provide any advice?

What advice exactly are you looking for? What similarities are you looking for? You mention decentralizing the systems but don't mention if you plan on bridging them nor what the goal is. It sounds like you have a fairly robust network with SDWAN hardware (assuming this is to aggregate multiple circuits) so the primary concern about multiple locations to a single point of failure seems to be addressed. But anyways, your network setup doesn't really matter as long as you understand networking and what 3CX needs to communicate. If you have a routed network with no NAT between the 3CX instance(s) and the phones, you configure them as local LAN. If you have NAT you would want SBC for locations with more than one phone and you may be able to get away with STUN for single phone locations. That's basically it. If you provide more detail about why you plan on decentralizing especially considering you seem to be coming from a centralized setup then more helpful suggestions can be made. But if you are the person who setup the SD-WAN/MPLS or are the person managing it, then you shouldn't have any issues implementing 3CX with minimal help. It's really just about networking.

 

[VoIPTools]

My assumption is that he wants people to be able to call each other. Bridging the 3CX systems together addresses this concern and is a built-in feature. I don't see that as a concern.

Further, my assumption is that the MPLS network is providing a private network between each of the locations, so connecting multiple 3CX servers together or utilizing a single 3CX instance will not require a SBC. It would only be needed for groups of people who are not connected to the VPN (MPLS network). If I understand correctly, essentially they have one private network shared by all locations (typical of MPLS). So essentially, from 3CX's perspective, everyone is local.

One could argue whether MPLS is justified if only for 3CX. Certainly 3CX could bridge together multiple 3CX servers over the public internet. But I suspect there are other business reasons for the MPLS network and he is just piggy-backing on an existing infrastructure. I agree that MPLS is not required for 3CX to function, and it is very expensive.

The conversation thus far has been focused primarily on the infrastructure, but I think it is a non-issue. Whether he uses the public internet to connect everyone/everything together or MPLS is largely irrelevant from 3CX's perspective. Provided that he has sufficient bandwidth and reliability, either approach will work well.

Therefore, the only real question is whether the limitations of running a central 3CX server across multiple time zones is a concern. I have outline some of those considerations above. if I had business units in multiple countries in different time zones, I would probably go distributed.

 

[dashbrook]

Thank you for your opinions.

The SD-WAN MPLS / Internet network is used for a lot of other traffic in addition to the new yet-to-be-established 3CX connectivity. I set it up and manage it. One of my primary purposes for decentralization is to eliminate the possibility of WAN or central server failure taking down an individual office's phone system. SD-WAN can take care of the WAN issue but not the central server issue. The MPLS lines will be with us for some time to come and are a contractual obligation. I am just using what we already have in place within our WAN. I provided the information for background purposes.

Each office has their own receptionist who is responsible for answering and transferring their own calls within their building. Our Cisco system does have a company-wide corporate directory accessible by all offices. Each office is in its own timezone, EST, CST, MST & GMT. Within our Cisco system, all extensions start with a different number for each office ( all extensions in one office start with 1, another office starts with 2, etc. ) Offices use 3 digit dialing to call other extensions, company wide.

I assume the 3CX bridge capabilities will allow us to continue to use 3-digit dialing between offices and hopefully provide the corporate directory functionality?

The Cisco proprietary skinny protocol uses a relatively low amount of bandwidth for each conversation and has a DSCP tag value I can prioritize. How much bandwidth is required for a typical 3CX conversation (no video) and will the 3CX system tag the traffic?

 

[dashbrook]

Another additional question. Due to COVID issues, many employees are now working from home permanently. What issues have you seen using the mobile app for these users? Anything I need to watch out for?

The SOHO users are connecting to their offices using localized VPN connections into individual office firewalls so I assume some could use a deskphone at home if they so chose in addition to or instead of the mobile app?

 

[VoIPTools]

It goes without saying that your concerns about a central server causing outages for the entire organization are valid. However, I would argue that global network outages are less of an issue today now that we have robust hosting services from AWS, Google, Azure and others. They can provide hardware level clustering and redundant internet connections. Given that you would likely be using the internet for your SIP trunks, you already have a dependency on the internet connection. However, I suppose you could have a database corruption or something like that which would not be addressed by clustering or VM replication. I will say, having spent some time working in the 3CX support organization, 3CX software failures are rare -- provided you are not doing something stupid like scanning a live 3CX database with anti-virus, etc.

Yes, you can have your own receptionist for each site even with a centralized server. What you cannot do easily is have separate operator extensions for each site. That is one of the limitations of a central 3CX server.

Yes, you can use 3-digit dialing across bridged 3CX servers using the existing approach of the first digit representing the location (though not required, it is a best practice).

Regardless of whether the SOHO users have a router-based VPN, they can use a hardware phone. It's easier to provision a physical phone with a hardware VPN, but not required. However, if you have multiple phones behind the same remote router, then a SBC would probably be appropriate. An SBC is not required when using the software clients.

Bandwidth requirements depend somewhat on what codec you choose, but I think 150kps is typical.

3CX does NOT offer a unified company directory that spans across multiple bridged 3CX servers.

One of the many strengths of 3CX is the ability to build custom integrations and extensions. For example, it is completely feasible to build your own company-wide directory. I'm not saying it is trivial, but this is exactly the kind of thing our company does. In fact, we built a "universal directory" for a customer probably 10 years ago. I have often thought I should dig up that code and make it another tool in our commercial suite of add-ons for 3CX. Maybe I will. You can't be the only company that would want the feature .