There is a thread, now closed, which touched on the subject of how 3CX handled remote phones -
While 3CX does refer to the devices as a SBC, I too believe that the device is more akin to a VPN/proxy. Grandstream and Yeastar also have a a scheme to allow remote phone connectivity (ICE, STUN and TURN) that overcomes the common NAT issues that arise.
WIth 3CX, their device sits behind the remote firewall and all the devices that sit alongside same are proxied thru the device which in-turn encapsulates the UDP and TCP traffic onto port 5090 with a proprietary tunnel that connects directly back into the 3CX system which is secured with a password. The device can handle a relatively large number of phones behind the firewall along with a given number of BLF keys per phone and can run on a Pi or other machine for a larger capacity using Debian or Windows. As mentioned in the other thead, in the event of an Internet outage the device will still manage and allow calls between extensions on the same site. The device is extremely suited to handling remote phones that connect to a cloud hosted 3CX instance.
3CX has since come out with what is now called a router phone. The phones which are certain models from Yealink and Fanvil can act the same as the standalone SBC albeit with a smaller population of devices (10). Nevertheless, the router phone can also be used in a one-off work from home environment.
Provisioning of configurations are also accomplished via either the device and/or the router phones.
While most phones support OpenVPN, the issue is that one must program each phone manually so it can be rather tedious. Additionally, if there is ever a firmware change that impacts a manufacturer’s OpenVPN implementation, then the possibility exists that one will have to re-program the phone client side VPN. Grandstream, for instance, uses a rather old version of OpenVPN in their GXP series of products.
With the 3CX implementation being a proxy, the phone can be provisioned via the SBC which will include the proxy info to associate the phone to the SBC and subsequently register to the PBX. Granted, the 3CX implementation does not prevent DDoS attacks and other Edge threats, but then, neither does the OpenVPN method.
The FreeSBC does not seem to lend itself easily to a cloud based PBX and the link on the VitalPBX integration page points to an outdated link - https://docs.telcobridges.com/Tbwiki/FreeSBC:Baremetal:Installation_A
In summary, the issue is not so much related to the functionality of a true SBC, but rather how one can minimize the amount of effort needed to setup and provision remote phones even if the remote public IP is dynamic while averting many of the issues that can arise with the remote NAT while not unnecessarily having to expose either ends to open ports or broad ranges of IPs while using a hosted PBX or, a premise based one for that matter.
I would like to know what method that VitalPBX might have that takes these same considerations into account. While I do not really consider OpenVPN to be an elegant solution, I see a commercial module for OpenVPN, but I do not see any spec as to how many clients that will support or related system size nor the version of OpenVPN it encompasses. I also do not know if the VPN module is an included module with the VitalPBX One (3CX competitior) version as the Webpage for the One product indicates that the plan has - And all VitalPBX Modules.
I am interested in the VitalPBX One plan, but I want to understand the nuances and what I may have to go thru to keep clients functional when remote to the PBX. The 3CX system of handling such has been trouble free for me and worked well for years. However, there are other aspects that have caused me to consider alternative systems.
Thanks and sorry for the lengthy post.
