3CX Large scale deployment (SBC vs VPN)

[VoiceOfNZ]

Hi team!

I'm looking at a few options for a relatively large scale deployment mainly reference architecture to show how you've done it, what issues arose and the solutions around them. It's going to be roughly 320 handsets and the PBX is in the cloud.

After looking at SBC documentation on the 3CX website, it states that under the SBC requirements an i7 based SBC will handle up to 100 extensions, and the performance benchmark states 100 concurrent calls over 30 mins. Is there an "idle" extension limit? e.g. am I able to run 320 handsets through one SBC although not exceeding 100 concurrent calls?

I've looked into the VPN route also however if there's any blips / changes in the network it will affect all the phones.

Would love to hear your ideas / feedback.

Kind regards, Anakin.

 

[cobaltit]

There's two options and you've pretty much outlined them. You can have more than one SBC at a location so if your VPN is that shaky, SBC is the way to go

 

[SweetAction]

TBH, you should go VPN - your time and money would be better suited towards making that stable then 320 phones through an SBC. There is better support for ATAs, more phones, etc.

If so concerned, make a group of phones via SBC or STUN. Or, desktop/mobile apps exist for a reason too.

 

[eddv123]

This question is a real pain to answer since both offer both benefits and negative points. Quite frankly one is not better than the other (in my view) you are best looking at the pro's and con's and fitting the solution per customer.

VPN:

Benefits include - easy access to site endpoints, security, support for ATA's and remote gateways, DHCP option 66 easy provisioning, no extra cost for hardware

Disadvantages include: some customers dont like you have direct access to the local network directly, in some cases you have to work with 3rd party IT companies, VPN settings need to be tweaked for performance (Phase 1 for connection Phase 2 for traffic), VPN's can become unstable if working with 2 different vendor hardware between sites, If you are hosting then you need a software firewall in the cloud with 3CX.

SBC:

Benefits include - One port required for access (5090 and HTTPS for the provisioning process), security from the tunnel, SIP traffic masked on 5090, Plug and play provisioning, better coverage on v16 3CX, no direct access to customer network, if windows is used you have direct access to site however.

Disadvantages include: Additional hardware or VM required = added cost, limit to amount of extensions per device, only works with supported devices, you cannot connect (with 3CX support) remote gateways and ATA's.

 

[VoiceOfNZ]

Thank you everyone for taking the time to reply, it's very appreciated.

I've been weighing up the pros and cons of both solutions, as you say @eddv123 there's not a solution that's a "one stop shop". I didn't mention in my original post that this install is a hotel style roll out, so I'll be using analogue devices with gateways to keep things simple.

I'd like to retain the support for gateways if I'm able too, the cost of one i7 NUC SBC (require 3 for the amount of extensions I'll have) is the same as running the entire system on prem, so the conversation with partners is leaning more towards that way since I'll be able to eliminate any network variables (VPN issues etc) while keeping everything inside the local network.

 

[eddv123]

analogue devices with gateways to keep things simple.

Ive setup something similar recently with Patton Analogue channel bank units (4332/4324) and would strongly recommend you using a VPN in this setup, SBC would probably work (but be un-supported) if using standard analogue phones (no FAX) but still if you can do VPN in this setup I would do it.

 

[SweetAction]

Hotels are one of my common deployments.

Are you doing PMS integration too? It's another reason to use VPN over SBC if so.

On prem is almost always how I do these installs - whats the main motivation for cloud hosting? Depending on the hotel, a PRI can be more cost effective then a SIP trunk - another reason for on prem.