I might be overlooking it, but is there a blog post that highlights the new features of PBX 17 compared to PBX 16?
It seems to me that the FreePBX feature set has stayed mostly the same or similar ever since version 15 or before. Is there a list somewhere of the changes that are in the works that might be coming to FreePBX in the future, or is it going to continue to stay mostly the same?
I thought maybe on this thread would be a good place to mention this. Sorry if it is not.
I am just a userā¦but I think the migration to a different OS (including the support of php 8.2) is a huge step forward. What feature do you miss?
+1 Agreed.
Here is a list of things that I would find useful if they were added. None of them are really deal breakers.
- Call recording transcription - It would be nice to send call recordings to Azure transcription service and get that text added in the Call Recording report.
- Daily call reports - total calls, total call time, calls per extension, etc.
- More user readable CDR log.
- Ability to upload Voicemail greetings through the web interface.
- Call path report - would show the path a call would take per inbound route.
This is what I thought of at the moment. I imagine that at least some of this I could program if I was smart enough. 
I think you would like the CDR Pro module. There is a 1-month free trial available in the Sangoma portal store.
1 Like
This has been possible in UCP for a very long time.
I know, and I read some of the forum posts about this. But:
If am the admin, and want to upload voicemail greetings for numerous users, I have to login in the UCP as each user. Some of the users arenāt even setup to login to the UCP. In addition, Virtual extensions that are used for voicemail only canāt login to the UCP as far as I can tell.
Just thought it would be nice to be able to do this in the Voicemail Admin.
All good ideas, make them heard via the official channel:
Issues Ā· FreePBX/issue-tracker Ā· GitHub
Itās gotten quite easy to request features. Not a guarantee but puts it in front of the right people.
2 Likes
I believe that you could assign all of the desired extensions to one āadminā account and thus be able to access the voicemail settings for all associated extensions. Iām not sure that this would work for virtual extensions though and itās also not particularly clean since youād have to add the voicemail widget to the dashboard for all of those extensions. However, it would enable you to avoid having to log in many times.
I also agree that it would be very nice to do this via the voicemail admin.
1 Like
Iāve just submitted my two biggest feature requests on GitHub:
- Remember/Save Last Search Settings in the standard CDR module
- Add Support for Wildcards (RegEx) in the Blacklist module
Thanks for the suggestion. I submitted the request for uploading Voicemail recordings on Github.
I have benefited much from the discussion here, but I am sorry, by now it looks like I have derailed the thread. If someone thinks some of the posts should be split into a new topic, that is fine.
1 Like
I donāt see you have derailed the thread at all. As you pointed out the feature set really hasnāt changed much between 16 and 17 the major change was behind the scenes with the OS and most particularly with the latest version of php
Iām not a php developer but it seems to me that the maintainers of PHP change how php works more often than most people change their underwear. Breaking peopleās running php code seems to be their goal in life - literally there is not a single scrap of php code posted anywhere on the Internet that is older than 5 years old that works properly on current php versions. In my view this really hampers php development because people create php modules, post them, then they are forced into a constant merry-go-round of tinkering with the modules and a lot of people get tired of that - it seems to me older php modules that worked once, did something useful once, but are broken now, abound on the Internet. So, āfixingā all of the php code in FreePBX just to satisfy the moving target of what php is, is really a full time job. But, I digress.
Anyway, keep in mind that FreePBX 17 was sort of a ātransitory releaseā It shipped with Asterisk 21 which is NOT the LTS version of Asterisk - thatās version 22 which is in release candidacy now. Once Asterisk 22 ships my guess is FreePBX 17 will be updated to support that and then we will really have a nice solid milestone release of FreePBX 17. I havenāt yet built Asterisk 22 and run it under FreePBX 17 but it doesenāt look like there is going to be any significant breakage.
2 Likes
That gives me an explanation for the poor success rate I have had adding third party modules to FreePBX. There are some nice open source ones on github, but like you mention, too many of them are stale and donāt work any more.
If you want a call path report for inbound routes, although it may not be Sangoma signed, we use this module a lot:
We tweaked the code, as there was some issues with the PHP. It should work on 16 and 17. Also if it doesnāt work, please post a bug. Weāre happy to fix it where we can and maintain it.
1 Like
The installation script for FreePBX 17 supports the installation of older Asterisk versions, you just need to change a config variable for that (and use the --skipversion option to override the scriptās version checking). Even if you make a standard FreePBX 17 installation (with Asterisk 21) you can switch to Asterisk 20 LTS afterwards with asterisk-version-switch utility supplied by Sangoma. I always use Asterisk LTS versions in my setups, and Iām currently using Asterisk 20.9.3 (my own build) with FreePBX 17.
Thank you very much for posting this here. I tried another call path report module, but experienced PHP errors. I think this module is actually a fork of the one I tried.
This one actually works! 
I have an inbound route set to match any DID, and it will not visualize that. If I select āall inboundā, nothing will populate in the inbound route field.
Maybe I am doing something wrong, or the module is not set up to handle a situation like this?
Agreed, and it took a lot of work from @kgupta and team to get FreePBX 17 out the door on a new OS and a new PHP ā that is a huge ānew featureā right there ā so much thanks to them. 
Slightly asideā¦ not sure of the thought process on the part of the PHP developers, but it could make some sense why they broke things if you start from a premise that most old PHP code has outstanding security issues that are never getting fixed and deprecating that code at the language level is the safer choice for the users and the brand.
Back to the topicā¦
ā¦that should probably be in a new thread discussing the specific module.
That may be so but that is NOT the responsibility of the PHP developers to force obsolescence on code they donāt like. They could also have written a tool that could be run on old PHP code to make it ācurrentā
Security in code is highly dependent on the environment and the admin of whatever system that is in use gets the power to decide if some old module that is highly useful is too insecure for the environment, NOT the php devs.
Iām so sick of people using āsecurityā to justify poor behavior. The commercial software vendors do this all the time and their stuff still continues to get broken into. They are doing it out of sheer greed to force people to upgrade from their old insecure software to the new insecure software, that the crackers havenāt figured out the holes in yet.
This one works really well: GitHub - rectorphp/rector: Instant Upgrades and Automated Refactoring of any PHP 5.3+ code