FusionPBX on CentOS 8
- Thread starter kfeen
- Start date
- Status
The only thing I would say, I that going "Non-Standard" always seems to make it more difficult to get help. Probably becauase fewer people will understand your environment.
I also noticed that. I'm using Debian but it would be nice if you could install on CentOS.
moved to elastix, left fusion behind. sure it cost. but at fusions's $100 a month it was more affordable (many things are more affordable) and suddenly our NAT issues went away. It was a fusionpbx issues. Fusionpbx is great in theory but operates in a decade old opensource space.
My company is built on opensource, but fusion is very immature for the most part (the manual isn't really a manual). the manual leaves out important details which is an obvious play to get you to spend on the over priced support... the model need adjustments
FusionPBX is based on FreeSWITCH maybe you didn't realize that. Its not abstracted from FreeSWITCH so their books and documentation also are related to FusionPBX.
Comment on about the documentation maybe you didn't realize FreeSWITCH's documentation can be used with FusionPBX.
Documentation for NAT related issues. We don't always have time duplicate documentation that already exists.
freeswitch.org
freeswitch.org
freeswitch.org
freeswitch.org
So as you can see there is documentation on the topic.
Many people have figured out how to get it to work.
As far as pricing for support being high. This isn't true price has to be realistic or it will actually be a cause of support services failing. If the price is set too low support will fail because the work load will be too high for the people doing the support. Its a difficult balance and if emotion controls price this almost guarantees failure. I want the prices to be lower because but to do that have to train many new people and reach and economy of scale in order to do it. When the skills required to perform the support are high then it makes it harder to bring down the prices. We are still working to train everyone and build a larger team for FusionPBX support. I'll revisit pricing in the future to see where it needs to be to be realistically sustainable.
Here are a few examples for pricing.
Check out SQLite prices. I'm not knocking SQLite its public domain (open source) I love it its great software and most people don't need support but if you do they have realistic pricing for the skill level required. Their prices again make FusionPBX support look cheap. But I love SQLite and glad that some companies are paying them and that helps provide a very useful database providing sustainability for the most deployed database in the world.
They don't show their support prices online but they aren't cheap and they make FusionPBX support look cheap. I appreciate 2nd quadrants work and I'm grateful that their are companies that can afford to pay them and some of their work benefits PostgreSQL.
www.2ndquadrant.com
My point is you can complain about pricing if you want that is your right. However I and other people I work with actually have to do the support work and it has to be priced carefully to make sure it is sustainable. If the price ignores reality then it will fail. I want people to get support help when they need it and therefore have to price support carefully and find a sustainable balance.
Comment on about the documentation maybe you didn't realize FreeSWITCH's documentation can be used with FusionPBX.
Documentation for NAT related issues. We don't always have time duplicate documentation that already exists.
NAT Traversal - FreeSWITCH - Confluence
NAT - FreeSWITCH - Confluence
Auto Nat - FreeSWITCH - Confluence
General NAT example scenarios - FreeSWITCH - Confluence
So as you can see there is documentation on the topic.
Many people have figured out how to get it to work.
As far as pricing for support being high. This isn't true price has to be realistic or it will actually be a cause of support services failing. If the price is set too low support will fail because the work load will be too high for the people doing the support. Its a difficult balance and if emotion controls price this almost guarantees failure. I want the prices to be lower because but to do that have to train many new people and reach and economy of scale in order to do it. When the skills required to perform the support are high then it makes it harder to bring down the prices. We are still working to train everyone and build a larger team for FusionPBX support. I'll revisit pricing in the future to see where it needs to be to be realistically sustainable.
Here are a few examples for pricing.
Check out SQLite prices. I'm not knocking SQLite its public domain (open source) I love it its great software and most people don't need support but if you do they have realistic pricing for the skill level required. Their prices again make FusionPBX support look cheap. But I love SQLite and glad that some companies are paying them and that helps provide a very useful database providing sustainability for the most deployed database in the world.
They don't show their support prices online but they aren't cheap and they make FusionPBX support look cheap. I appreciate 2nd quadrants work and I'm grateful that their are companies that can afford to pay them and some of their work benefits PostgreSQL.
Home
EnterpriseDB provides secure, scalable database management software, enterprise-class Postgres solutions and a wide range of services with 24x7 Postgres support.
My point is you can complain about pricing if you want that is your right. However I and other people I work with actually have to do the support work and it has to be priced carefully to make sure it is sustainable. If the price ignores reality then it will fail. I want people to get support help when they need it and therefore have to price support carefully and find a sustainable balance.
We currently use FreePBX at my business and I'm playing around with FusionPBX to see if it's a viable option before we switch. If we were to switch we'd most likely have to fork the project and begin independent development as FusionPBX will need to be apart of our larger cloud offering.
I think FusionPBX is a great tool I just wish it had the community backing of something like FreePBX. That would make it far and away the best open source option. At least I'm my eyes.
FusionPBX is at least 5 year younger than FreePBX. We are catching up and have passed them in some regards like multi-tenant. FusionPBX can meet many peoples needs but I'm not going to say it does everything that everyone would want. Doing everything thing that everyone needs is a very large list.
Your comment about a larger project sounds like you might be happier starting from scratch writing your own interface over top of Asterisk or FreeSWITCH. Why because then you will have complete control of the design, ability to choose the operating system, programming language and fit seamlessly into your larger project.
Last edited:
I looked at 3CX/Elastix stuff some time ago and noted that it is proprietary software. The costs can go up at any time, and you don't have much choice with it being proprietary. Other than the 3 year free bait, I can't see how 3cx is cheaper unless maybe for fairly small PBX's.
Also used Asterisk variants such as FreePBX and Issabel. While there is some good community there, my general consensus and I would presume that of many others here is Asterisk and variants is the past, Freeswitch and variants is the future. Just take the PHP 5.x vs 7.x as one example -- Fusion has been years ahead of FreePBX in this area. FreePBX is making progress, but years after PHP 5.x was deprecated they are still on it. Fusion has been using PHP 7.x for years!
Also used Asterisk variants such as FreePBX and Issabel. While there is some good community there, my general consensus and I would presume that of many others here is Asterisk and variants is the past, Freeswitch and variants is the future. Just take the PHP 5.x vs 7.x as one example -- Fusion has been years ahead of FreePBX in this area. FreePBX is making progress, but years after PHP 5.x was deprecated they are still on it. Fusion has been using PHP 7.x for years!
If you are looking to go your own way with CentOS 8, I wish you well. I have similar gripes with Debian, namely the much shorter EOL schedule of it, and a few questionable choices with packaging or finicky things in the past. Also, a lot of server manufacturers only tend to provide their full suite of tools for RHEL and maybe SLES.
I've had a tinker myself, to see if I could submit a pull request but there's no sensible way to use FreeSwitch on CentOS8, unless you go completely off-piste with a random person's COPR repo or slog through the fresh hell of compiling from source for every update. FusionPBX pretty much has to adhere to what FreeSwitch deems a supported platform, and that is pretty much a strict 'Debian Only' policy for the time being.
I've had a tinker myself, to see if I could submit a pull request but there's no sensible way to use FreeSwitch on CentOS8, unless you go completely off-piste with a random person's COPR repo or slog through the fresh hell of compiling from source for every update. FusionPBX pretty much has to adhere to what FreeSwitch deems a supported platform, and that is pretty much a strict 'Debian Only' policy for the time being.
- Status