I forgot to include a note about the recent API work already done and underway, and have updated post #1
Another goal of FreePBX 16 is more integration flexibility, evidence of which have been revealed in recent forum and blog posts. The engineering team has been busily adding GraphQL API methods and documenting them on the API wiki page. We have also recently announced a beta integration with Zapier and have a few other integration projects in the pipeline but not ready to announce yet.
Please provide (and update) an installer tarball at the normal location (http://mirror.freepbx.org/modules/packages/freepbx/freepbx-16.0-latest.tgz) as has been the norm for past beta’s so those of us maintaining alternate distributions can get to work on necessary changes also.
There is no magic to the tarball… note 16.0.10.6 was the latest tag on github
wget https://github.com/FreePBX/framework/archive/refs/tags/release/16.0.10.6.tar.gz
tar -xzvf 16.0.10.6.tar.gz
mv framework-release-16.0.10.6 freepbx
tar -czvf freepbx-16.0-latest.tgz freepbx
With those commands…
tarfile 
You‘re still staying with CentOS? I had hoped the recent chaos with RHEL/CentOS would be the final nail in the coffin and the (overdue) switch to something predictable and reliable like Ubuntu LTS would finally be announced 
CentOS with its aging PHP components and constantly shifting release timeframes has been troublesome for the FreePBX distro multiple times if I recall correctly…
Is there a way to remotely (from a script) determine what the latest release available is in?:
https://github.com/FreePBX/framework/archive/refs/tags/release/
Hey,
Sorry I missed this question.
For now, We’re still sticking with CentOS 7.x as the release base for FreePBX. It was not without much thought and concern that that decision was made.
We originally wanted to target CentOS 8.x but the whole Streams thing messed around with that goal and so until one of the CentOS 8.x based forks gets a little more stable we’re going to stick with CentOS 7.x but add updated versions of PHP and other necessary packages for the PHP 7.x upgrade.
Matthew Fredrickson
Are you also updating the mariadb version?
For us non-distro users, we have to dumb-down the db defaults of “modern” mariadb installs to match the distro’s MariaDB v5.5 default settings.
Thx for this heads-up. Good to know.
We also wish there was better support for postgres, since thats the standard database in our realm.
How about some actual QA? I know there is supposed to be QA but too many simple things are being either ignored or not checked. From Advanced Recovery and the Warm Spare a few months back to now.
The Chan_SIP to Chan_PJSIP mass convertor has a pretty big bug. It is generating the outbound_proxy setting wrong. Per the Asterisk WIKI and the PJSIP configuration the outbound proxy should be a FULL SIP URI with the ;lr tag at the end (\ is needed to escape ; ) instead it is just the IP:port.
Things like this should not be something QA is missing, at all. It seems to happen way too much.
I don’t remember seeing this reported, what is the ticket number?
I just found it. I haven’t had a chance to open a ticket yet but then again, I’ve got tickets from 4 years ago I was assured would be handled by the CFO. Still open. I’ll report it when I have the chance.
Yeah, I have zero confidence that things are ever going to be handled in any kind of reasonable timeframe.
Example: @lgaetz suddenly hit a year old ticket of mine and now it will be closed in 5 days because I do not have time to respond immediately? I mean I would have to recreate the entire scenario at this point.
https://issues.freepbx.org/browse/FREEPBX-21590
Supposed to be, Corportate stated “there is”, and reality are 3 completely unrelated realities, when it comes to this project.
He didn’t ask you to reproduce it… He asked basically why can’t you.
Based on the other replies it looks like the ticket is basically a won’t fix…
I agree, that is looking how this is going. However, why wasn’t this handled that way back in June 2020? The fact that the ticket system is poorly managed is not helpful for anyone. Not the users, contributors or the developers that need to do the work.
If this ticket is truly a Won’t Fix, then comment on that and mark it Won’t Fix so it’s closed out. The current ticketing system looks like a mess of unattended and ignored bugs and feature requests. It really makes it look like no one is paying attention and there’s no real structure.
Just before I left I closed out anything over 2 years old. That seemed to be the consensus that anything within the last two years is probably workable but anything older may have already been taken care of. That said I know we did triage calls every Tuesday where we would go through all of the open bugs and build out what needed to be done. I don’t know what the current engineering plan is obviously. I have noticed in watching commits and pull requests which I still do that many tickets are done under FREEI which are internal tickets so you can’t necessarily see the relation or reasoning behind it. One of the things I saw recently made zero sense to me but it was an internal ticket so any explanation to why can’t be publicly seen. I hate to say this but one of my reasons for leaving was the project being controlled by project management which is 100% business case focused. This means all engineering decisions had to have a business case related to the bottom line. Some things that made it into 15 were forgiveness over permission.
That was obvious from the start.
You don’t show why/how things cause a problem with having a scenario in place to (re)produce it. Also, somehow I didn’t have a thread here first. I usually do. Annoying.
Would this be like the conversation from certain Sangoma members in the Open Source Lounge meetings 100% commenting on how things can be sold?