The Road to FreePBX v17 is not as smooth as impression given

Beta Program Issues
1

So we are getting closer and closer to FreePBX v17 becoming a General Availability release but the actual upgrade path for those on older or current versions of FreePBX has been not very clear. Unfortunately, the advice of “Just backup current system and restore to FreePBX v17 system” is not as cut and dry as it seems which means for a subset of users this migration will have a bunch of issues.

This project has dragged its feet for almost a decade when it came to keeping up with the changes in Asterisk from modifications, improvements, new features and the removal of features/applications. What that means is anyone who has done any customizing or modifications to their FreePBX, up until basically this moment in time, has had to use deprecated methods that should have no longer been used. As well, this project never made a serious or real effort to get their user base off of deprecated applications and functions in Asterisk. The biggest of that being never forcing the migration of Chan_SIP to Chan_PJSIP and continuing to allow Chan_SIP to be used.

What does this mean? It means that if you are running 3rd party applications on your FreePBX system you need to validate that they will continue to work going forward. Sadly, a lot of 3rd party projects for Asterisk have stopped being active because keeping up with Asterisk over the last decade was too much work for them. For example, if you are running an application that only has Chan_SIP support and that is why you’re still on Chan_SIP…it’s not going to work past Asterisk v20. If you have any customization in the dial plan or other interactions you may have developed/written for FreePBX that depend on things like Chan_SIP or Macro() calls, those are going to stop working past Asterisk v20. This also includes validating any 3rd party FreePBX modules.

Keep in mind that FreePBX v17 installs Asterisk v21 by default, which makes all the legacy stuff break. If you are running legacy items like Chan_SIP or require Macro() calls still, your first step in setting up a FreePBX v17 system is to switch your Asterisk version to v20 so your stuff will work.

Also keep in mind, any of the predial-hooks that FreePBX encouraged the use of to tie into existing dialling functions where all Macro() based but now in FreePBX v17 none of the core call logic makes Macro() calls even if Asterisk v18/v20 are installed. It’s now all Gosub based. So any custom dialplan that was created based on existing predial-hooks, needs to be modified and updated as a Gosub routine or there will be issues.

This has just been broad strokes I’ve brought up. We haven’t even covered the impact of the OS level things and the various differences between CentOS and Debian. The fact that things like PHP8.x, current versions of MySQL/MariaDB have much more strict validation, handling. Meaning that poor code, SQL statements or poorly structured database tables will cause issues to happen and break things.

I think there should be a comprehensive document highlight that variety of changes that moving to FreePBX v17 will have and how it could possibly impact current deployments. I’ve already seen issues submitted in the issue tracker of people moving to FreePBX v17 and finding stuff breaking and this is during the beta phase…imagine once it’s GA…

5 Likes
2

Adding to this, I was never successful in using the SNG7 Python 3 implementation, so I have Python 2.7 programs that run I have been working on rewriting.

To be honest, I know that they have kept chan_sip included in asterisk versions prior to 21 but if you haven’t switched to pjsip yet then you’re the problem. The FreePBX and Asterisk teams have been letting everyone know for years that it’s going away.

1 Like
3

@adell4444 I’ve tried, I’ve tried…

5 Likes
4

@jcolp I love you and your hats. Keep up the good work!

5

As someone who is working on somewhere in the neighborhood of 30ish 3rd party modules this update is taking a bit of effort. That said it is all welcome changes including things being more strict. We got away with murder across the board in php. In some cases it was justifiable homicide because of phpisms. In any case one goal of FreePBX has been broad compatibility which is why Asterisk 11 was supported way longer than anyone wanted. The goal is to accommodate as many users as possible. Getting people to change is like pulling teeth and for every 100 people who want a change there are 300 that hate it. Fortunately a whole bunch of factors came together to force this move of technologies. So there is no more sitting on your hands. That said I as of last year still encounter people running trixbox 2.6. In the right environment with the right setup and a distinct lack of sticky fingers this you can probably run Current versions another 9001 years. The issues are only for those that need/want to migrate for some reasons. The cost of having updates and cool new hotness is the loss of some old stuff that people have to stop using. These updates to code etc are the cost of doing business. Realistically the stuff I am maintaining now has mostly been simple fixes like uninitialized variables. I am happy to help anyone working on open source modules if they get stuck on something.

3 Likes
6

I would like to say I appreciate everyone’s hard work on this. FreePBX 16 has a vulnerability score in our security software that is approximately sixteen times higher than FreePBX 17.

7

Coding your own module including your dialplan will eplace automatically the Macro to Gosub now. There is a documentation for that.
I don’t talking about chan_sip of course, it’s another song.

However, with17, I expect to get a script to install FreePBX system on Centos or any other Linux Distro.
If now the install is done through a script. Then that will be pretty easy to install on Debian, Ubuntu, Centos, Rocky Linux…etc
Whatever the OS is. Linux is Linux.
And more, if we can install any commercial modules everywhere. Good point!

Moving on PHP 8.x …etc It’s a good point too.
There was much packet in oldest version like fail2ban…etc

Anyway this kind of migration is like hair removal. It hurts but you have to pull quickly so that it doesn’t hurt too much, and then it gets better.

Anyway, good job for the dev team.

8

I agree with you, but I also see good progress. I just moved all my extensions to PJSIP, and my trunks. I am having trouble importing my config without it Breaking UCP and Fail2ban in FreePBX 17. Config comes into FreePBX16 fine, but these things break in 17. I have been testing and submitting bugs when I encounter things. I’m looking forward to the Commercial modules being available on FreePBX 17/Debian and looking forward to testing that. I am feeling positive about the change and progress even with setbacks. I figure if I can test, this will help.