On-Prem Topology Idea - Questions Utilizing SD-WAN and On-Prem SIP

[CHR15M]

Hello everyone! We are a small IT department relatively new to 3CX and are trying to learn the system as best we can before we have a conversation soon with a local 3CX partner. If its okay, I would like to run our concept by you guys to see if we are on the right track with our thinking. Phones are NOT my specialty but the system itself seems very user friendly and the features seem abundant for the price point. What do you guys think? Please let me know if this is not allowed. Thanks for your help!


Current Site Setup
10 Locations connected via SD-WAN
2 of our sites have AT&T Voice services for the next few years. One primary and one failover. (we have the ability to move our numbers over to the failover site)
Each site has anywhere from 25-75 desk phones. Roughly 525 in total.
FUTURE 1x 3CX server VM at the Primary Site and 1x 3CX server VM at the failover site.

Questions
Do we need to have SBCs at remote sites where the servers are not located?
Is there a better way to set this up with our configuration? We have considered hosted but we are stuck with on-prem SIP for a little while. (not sure if there's a way to utilize hosted with local AT&T SIP?)

 

[SweetAction]

Do we need to have SBCs at remote sites where the servers are not located?
Is there a better way to set this up with our configuration? We have considered hosted but we are stuck with on-prem SIP for a little while. (not sure if there's a way to utilize hosted with local AT&T SIP?)

You do not need SBCs since your SD-WAN makes each phone appear as on LAN to the server.
I would skip the 2 servers (go one server) and make that server highly available. I assume you have a virtualization cluster - use that to make the single VM highly available. Your experience will be better. You can have 2 SIP Trunks on Prem talk to a single 3CX server with your SDWAN without an issue.
You can technically make on-prem SIP work with Hosted by 3CX, but I can't see a reason to make that fight. If you want to host the VM outside of your system, spin up your own 3CX in the cloud in Azure, AWS, GCP, etc and then you can use a Site2Site tunnel to your SDWAN. You can convert the on prem into SIP that goes over that VPN at that point with ease.

To be perfectly transparent, this is a conversation to have with your partner because it can be done a ton of ways depending on your driving motivators and system needs. You don't need a local partner specifically for this part either - but you do need someone with strong networking background.

 

[CHR15M]

You do not need SBCs since your SD-WAN makes each phone appear as on LAN to the server.
I would skip the 2 servers (go one server) and make that server highly available. I assume you have a virtualization cluster - use that to make the single VM highly available. Your experience will be better. You can have 2 SIP Trunks on Prem talk to a single 3CX server with your SDWAN without an issue.
You can technically make on-prem SIP work with Hosted by 3CX, but I can't see a reason to make that fight. If you want to host the VM outside of your system, spin up your own 3CX in the cloud in Azure, AWS, GCP, etc and then you can use a Site2Site tunnel to your SDWAN. You can convert the on prem into SIP that goes over that VPN at that point with ease.

To be perfectly transparent, this is a conversation to have with your partner because it can be done a ton of ways depending on your driving motivators and system needs. You don't need a local partner specifically for this part either - but you do need someone with strong networking background.

Thanks for your reply! Are you recommending one VM split across a cluster at the primary and failover sites? I was contemplating the single VM after reading up about the challenges of 3CX's native failover. I could have a current copy of the VM sitting at site 2 (failover site) in theory. During a failover scenario, spin up the VM, Re-IP the VM, update the DNS records, and move our numbers over to the failover site. It does seems like a bit of work but the goal is to not have to failover. Definitely open to other ideas if we can make the failover a smooth process. Hosted would likely be better if we can figure out how to use our on-prem primary and failover SIP connectivity. We're stuck with on-prem SIP for a little while. It sounds like this system is very flexible which is great to hear! Thanks again!

 

[SweetAction]

Thanks for your reply! Are you recommending one VM split across a cluster at the primary and failover sites? I was contemplating the single VM after reading up about the challenges of 3CX's native failover. I could have a current copy of the VM sitting at site 2 (failover site) in theory. During a failover scenario, spin up the VM, Re-IP the VM, update the DNS records, and move our numbers over to the failover site. It does seems like a bit of work but the goal is to not have to failover. Definitely open to other ideas if we can make the failover a smooth process. Hosted would likely be better if we can figure out how to use our on-prem primary and failover SIP connectivity. We're stuck with on-prem SIP for a little while. It sounds like this system is very flexible which is great to hear! Thanks again!

How do you currently handle DR for any machine at site 1?

My advice is to do the same thing for 3CX.

As for the SIP, you can register both site 1 and 2 against a single 3CX server and in your outbound rules configure it so that it tries site1 and then 2 SIP if site1 isn't reachable.

In this design, for the 3CX VM - whatever you do for everything else, do for 3CX. If you have to manually turn it on, IP it, etc - these should be automated at the VM level. I can't speak to that until I know more about your infra / BCDR plans. For the SIP level - nothing would need to happen - it would be automatic.