I would like to see each module be its own DEB package, and fully integrate FreePBX with the Debian package ecosystem - using it for upgrades and maintenance as well as new installs.
Good points for sure. A lot of time could be saved by bringing the relevant information together in one place.
On point 6 - it may not be the exact thing you are asking for, but I really like the visual layout of āDial Plan Vizualizerā by Adam Volchko, and the fact that you can click on any of the elements to jump out to the configuraton.
I read what you wrote, but sorry, have no idea what it means in relation to my request.
Really ? How is that ? If an account (remote phone) does not register and connect with FreePBX, there is no way for it to make a call. yes ?
Yep. I had to do this for a large scale programming language that was millions of lines of code. After 20 years of operations and over 500 programmers involved, We needed to see how the system full flow path was handled. modules constantly called out to other modules and even created loops. Some had designed a āhard exitā to loops if necessary (creating a deliberate code crash instead of trying to back itself out) I had to set up loop detection to get that flow diagram to work.
Yes, Its how I do things. And considering there are MILLIONS of downloads of FreePBX, and the forums here are filled with only a small fraction of those downloaded users, You can pretty much be sure many of these requests are not just a āmeā problem or request, but info that others would find beneficial too.
It never ceases to amaze me when companies/organizations ask for feedback and improvements, and then immediately pick apart and dismiss many of those suggestions - for whatever reason. Again, there are millions of users of the platform, yes ? That is the standpoint of how you need to receive the suggestions that my voice may represent even 1% of the userbase. What would that interpret to ? 10,000 + users ?
And Yes, I have been in IT and programming for 40+ years now. Old school. Have worked on massive systems in programming with millions of lines of code and no user interfaces but text. But, when we are dealing with a well developed User Interface like FreePBX that has been around for YEARS, an end user or administrator should not really be forced to constantly run out to run a CLI to get fairly basic and common data from the system. Build a complete tool.
Especially if they are not constantly readily sitting with a system that has SSH or whatever way necessary to remote into it. I spend about 30% of my week doing client site visits, and often I will get frantic calls when I am on the road āCurt - this is not working !ā and need to figure out why one of our national call centers remote operators working from home all of a sudden cant connect in, when it worked yesterday, or just a few hours ago. If you are a programmer sitting in an office all day and a computer at your fingertips constantly, yea, CLI is an option. but for on the road administrators, or people that move from site to site, That gets really cumbersome, real fast.
Over my 40+ years in IT this is one of my observations. Many Linux based programmers find it completely standard to expect an end user to go to CLI to get work done. UI based programmers often figure out what you are going to need, and if the system does not do it natively, you can often export it to some type of report, spreadsheet, CSV file, etc, right from the GUI. This is a cultural difference in programming platforms.
Again - The entire point being > this is another example of having to jump between 2 different screens to find out if some type of thing exists, and the information is split between 2 different location, under 2 different menu items. If I am creating an extension, I have to not only look at the extension list to see what extension exist, we have to run over to the ring groups screen and make sure an extension we are trying to create does not already exist. The same in reveres applies. trying to create a ring group and we have to first make sure a matching extension does not already exist. The work flow to find information requires we jump all around in the system to get that info. Reducing and eliminating that would be a benefit to everyone in not wasting their time
Do you mean you donāt want to create Ring Group 650 if Extension 650 already exists? By default thereās āDialable Extension Mappingā in FreePBX. That means if a dialable destination exists be it a ring group, queue, miscapp, extension, etc. the field in the form will warn you.
Tried to create Ring Group 100 but thereās already extension 100. It warns me.
And you know, vice versa when trying to create an extension. But if 100 was already a queue it would do the same thing. So any place you enter a dialable extension number, for whatever application, it will tell you if itās already in use and by what.
No. Registration is a location service, the phone registers to tell the PBX (in this case) āSend requests for me to this locationā which is its SIP URI (generally from the contact header). It has zero relationship to outbound requests from a device. A device can still send an INVITE to the PBX without being registered, the INVITE is challenged and authorized. Again, not related to the registered (or not) location of the device.
This is why a common NAT issue is āI canāt receive inbound calls but I can make outbound callsā. Because inbound and outbound are not related to each other. Or the contact is not available but can still make outbound calls.
Itās also why a lot of hackers for fraud calls just need the credentials and SIP address. They will also register to make it look like a legit contact making the call but they donāt need to be registered at all.
Although Iād much rather see it as an update to 17, letsencrypt, it should be an option to use DNS for certs and updates, all our servers (web/mail) are created and updated by using DNS (via acme.sh).
FreePBX mainly uses extensions to mean local devices that look like phones. That is not how Asterisk uses the term, and even FreePBX sometimes uses it in something more like the Asterisk sense of the number you dial to access a particular service.
Even with the narrower version of the FreePBX definition, chan_dahdi āextensionsā have no IP address, as they use circuit switched networks, and association of the device with address is hardwired, so there is no registration process. Thatās one of the zero to one cases.
With chan_pjsip you can have simultaneous registrations from multiple IP addresses. Thatās a case of many to one.
Itās possible to have SIP devices bound by IP address, without registration, although I donāt think that is supported directly in the GUI, for āextensionsā.
The implementation of ring groups, in FreePBX, involves extensions, in the Asterisk sense, and they can use different technologies, and even within registration based SIP, can have different credentials.
If you try and create a single table, you are limiting yourself to one to one, IP and registration based devices.
Letās not forget if the devices are remote to the PBX you could have multiple registrations from the same IP address. Registration cares about the IP and the port not just the IP part. Which is why an endpoint that has multiple contacts can see the same device registered multiple times at certain points. Because bad NAT meant the phone registered from one IP and port the first time and then the next register came from the same IP but a different port. These are treated as two separate contacts and will not replace (or reject) an existing contact as it should since the contact URI doesnāt match.
Dial Plan Vizualizer is a module I have been working on for a few years. Just released a new version this morning.
Full thread here: Dial Plan Vizualizer 1.0.34 Released
Installation and upgrade instructions are on GitHub link at the bottom.
Reduce the software stack. Its riddled with to many layers for a PBX. Itās clear in the last few years JS has been dropped in the backend for some modules and itās damn right awful. Full systems has MySQL, Redis and MongoDB. A complete disaster for such a system like this. Not going to happen for 18, but Iād like to see some slimming down of the backend technology used, thereās too many dependencies running inside an initial install.