Hi HMC-Brad, footnote for 'clarity' in case it is helpful at all?
with a standard 'modern' cloud 3cx deployment
3cx will require either SBC proxy to facilitate connections for phone handset hardware
or
you will need at least one modern phone handset with built-in proxy function - a so-called 'router phone'
broadly speaking - the 'better' option will depend on your site size and 'preference'
if a site is ~relatively modest (ie, not a lot of handset) then possibly a router phone as your proxy is fine.
note inherently this config means that if the router phone device is offline / unplugged // then all your other phone handsets at this site are also offline.
if the site is not so small, or you do not with that dependency to exist (ie, all phones depend on one phone being alive to work)
then deploy an SBC will be the better pick. You can then locate the SBC in a 'secure location' (network closet, server room, etc) so that end-users don't have the option of "hey, I will unplug this thing now because I feel like it" - which might make life easier for you.
note that a 3cx SBC is not a demanding function - you can run it on a standard "MiniPC" or an 'entry level server' and some people deploy them using Pi hardware I believe. Given the modest cost of 'standard' mini PC boxes these days (ie, you can get something pretty solid for ~$200) - that path has been my own preference - it means you have a 'very standard x86 computer box, with a normal monitor keyboard mouse hookup, no custom parts needed, etc - 'it just works'.. Alternately if you have a site with on-prem virtualization server, you can easily spin up a 3cx SBC VM on ~any standard virtualization platform (ie, full hardware virtualization - KVM based / VMWare / Xen / Whatever).. Again, the requirements of the SBC are modest so a ~pretty basic VM will do the trick (ie, 2Gb ram, 1 vCPU, 10gb disk - single LAN NIC - approx).
presumably you are looking at using older hardware because maybe? you have such parts from a prior voip project or something like that. This is "OK" for deployment, especially if the phones are listed as "work ok" with 3cx. I've deployed a number of different older phones over the years, and generally 'they work fine'. If you have less-supported phones that you choose to use, it might mean more work with deployment and config management long term. If you plan to 'deploy and forget' the handsets this might be a non-issue. (ie, "EXT 200" will be "room 200" and this will never change during the life cycle of the handset > possibly means you don't care if elegant provision config management features are broken or not available?)
You might want to do nice simple deploy path
1) have a clean 3cx cloud deployed server lit up and alive / base config in place.
2) do some test calls / connectivity via web-client first
3) deploy an on-prem SBC at your 'test site' and then boot up a phone handset <> so it becomes visible in 3cx after booting up while in same LAN as your SBC
4) test calls with that handset
5) rinse and repeat the process, spin up your different handset model, make sure it works as expected. Keep notes about what you are doing / what does/not work.
6) once you have a standard process for deployment well tested & understood, it is easy to fan out and add more SBC/Sites and more handsets as needed.
good luck with your deployment.
Tim
