3CX remote vs Vital remote

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.

Since I posted that question back in March 2023, I’ve slowly been migrating clients to Vital. I now have dozens of tenants and hundreds of remote extensions. At first I only moved clients that had few phones and only very basic needs. Now that I’m more comfortable with the system, and confident it will meet mine and my customers needs, I’m adding all new clients to Vital and migrating others as their annual licenses expire this year.

Vital has worked very well for me with remote extensions save for a couple of weird problems with SIP ALG on cheap routers. In those isolated instances I’ve been able to solve the issue with better networking gear or by using the OVPN module.

I won’t deny that Vital isn’t as trivial to set up and configure as other systems out there, but I like the product. It is extremely configurable and I like that VitalPBX as a company seems to understand and support its partners.

1 Like

Thanks for the info. I am not worried about the ability of Vital to accommodate the telephony needs per se, or even its setup, but rather how or what they are doing to overcome the various issues associated to remote connectivity using desk, soft and/or web) when using a hosted instance of Vital.

I am not disputing that OpenVPN offers some relief, but I believe you made some observatios abouts its use which I also raised. Apparently, you have decided that the issues associated to using OpenVPN outweighed the continued use of 3CX and have been successful in doing so.

Thanks again.

This might be of interest: Detailed Guide On FreeSBC Integration With VitalPBX

Thanks, I saw that, but I sort of lost interest when I clicked on the associated links and both links are dead -

I suppose I could do some research and see if there is a way, but it does not give me the feeling that the integrated product is as fully supported as it may have once been given that the post is over 5 years old.

The original links are bad but FreeSBC is sill available if you go to their site. The VitalPBX thread is a bit stale but the theory still stands.

For a single or small group of remote stations, I’d rather just use a router with OpenVPN back to the host system. 3CX had a good idea but they’ve changed their marketing and pricing to the point it isn’t worth it for small implementations. Sangoma sells a hardware SBC for use with Free*PBX and other systems as well.

Patton, Ribbon and others also have SBCs, but then that complicates the issue when hosting the PBX. Yes, as indicated, I could look around and see about Free/ProSbc, but it also appears to have the same issue and again it seems stale as VitalPBX 4 was not yet released when that FreeSBC doc was created. Had there been any real traction, then I assume that both VitalPBX and Telco Bridges would have updated things over the past 5.5 years. My guess is that an appliance based SBC meets more of the demand.

I have not discounted using OpenVPN at this point, but I hate to add that additional complexity and time associated to such.

3CX still has the most elegant and easy to implement remote solution and with the advent of the router phone, perhaps the most cost effective as well for home workers or with the webclient or softphone.

Where I have issues with 3CX is the ever changing landscape of the offerings and how they tend to deprecate or move features that were in a lower version to higher, more costly versions. Then, they “upgrade” you for that remainder of the clients’ license period “free of charge”, but at the next renewal, you are stuck at the higher renewal rate. Now they are eliminating all but one version for Windows (Enterprise) focusing instead on Linux Debian. Finally, they announced a price increase come May of 10-20%. I have a number of Windows clients as I started with 3CX in 2008; before they bought Elastix and then ventured into Linux. Windows was their big selling point as virtually all businesses were MS based at the time and no need to learn a new OS - the 3CX advertisement read. This is like 3CX bringing out the PBX on a Raspberry Pi as well as their SBC. It was a very cost effective solution, but then when they came out with their own hosting for smaller systems, they removed the Pi for PBX use citing that the hosting solution was every bit as cost effective. However, that cost effectivity kind of got lost on those that already had the Pis in use and had to move to something else.

It is their product, management strategy and general overall arrogance that after 15 years has caused me to look further and I had already moved some of my more basic clients to other platorms as a result. The VitalPBX One plan caught my eye.

Hello everyone,

I want to preface this by stating that I am not an expert network administrator, but I’ve embarked on an interesting experiment that might intrigue those familiar with advanced networking concepts.

Objective: We’re attempting to replicate the functionality of a 3CX SBC using Tailscale, an open-source WireGuard manager that seems almost magical in its simplicity and effectiveness.

Current Setup:

  1. Raspberry Pi: We’ve installed Tailscale on a Raspberry Pi, previously utilized for a 3CX SBC setup.
  2. VitalPBX on Digital Ocean: Similarly, Tailscale is installed on our VitalPBX instance hosted on a Digital Ocean VM.
  3. Yealink Phones Behind the Firewall, not possible to install Tailscale on them.

Both devices are under the same Tailscale account, effectively joining the same Tailnet.

Device IPs:

  • Raspberry Pi: Local IP = 192.168.1.163, Tailscale IP = 100.110.110.5
  • VitalPBX: Public IP = [redacted for security], Tailscale IP = 100.100.22.1

Currently, the Raspberry Pi and VitalPBX can communicate via their Tailscale IPs.

Configuration Steps:

  • The Raspberry Pi is set up to act as a Subnet Router. This adjustment allows VitalPBX to recognize devices on the local subnet (e.g., 192.168.1.42).
  • Phones are connected to the Raspberry Pi using a static IP configuration, where the Pi serves as the Network Gateway (differing from the typical SIP outbound proxy setup in 3CX).

image



Results: The setup works successfully! Multiple phones can connect to the Raspberry Pi without requiring a local appliance.

Additional Experiment:

  • We’ve also integrated Tailscale directly on an EdgeRouter X. Phones connected via DHCP can seamlessly access VitalPBX, circumventing the need for additional local configurations.

This setup feels somewhat magical due to its simplicity and efficacy.

Conclusion:

  • I am considering creating a detailed step-by-step guide or a video tutorial based on the demand and interest from this community.
  • I welcome feedback, especially from those with more experience, to identify any potential issues or improvements.

Thank you for reading, and please let me know if you’re interested in more detailed documentation or have any insights to share!