@lgaetz The required module listing is inane (ignoring the note about edge, that is expected for a beta).
Sangoma Connect v15.0.34 or v16.0.23
Sangomartapi v15.0.23 or v16.0.21
Sysadmin v15.0.23 or v16.0.8
Restapps v15.0.22 or v16.0.22
Firewall v15.0.30 or v16.0.43
Framework v15.0.18 or v16.0.11
Here is the list of modules installed on a system that is currently using SangomaConnect Mobile and Zulu.
[jbusch@pbx ~]$ sudo fwconsole ma listonline | grep "sangomaconnect\|sangomartapi\|sysadmin\|restapps\|firewall\|framework\|zulu"
| firewall | 16.0.44 | Enabled and up to date | AGPLv3+ |
| framework | 16.0.14 | Enabled and up to date | GPLv2+ |
| restapps | | Not Installed (Available online: 16.0.22) | Commercial |
| sangomaconnect | 16.0.18.19 | Enabled and up to date | Commercial |
| sangomartapi | | Not Installed (Available online: 16.0.20) | Commercial |
| sysadmin | 16.0.10 | Enabled and up to date | Commercial |
| zulu | 16.0.10 | Enabled and up to date | Commercial |
[jbusch@pbx ~]$
Double check that required modules are installed and daemons are running, and that Sangoma Phone has been enabled in User Management for the user in question.
Gonna be honest here, if you think that FreePBX runs on isolated, individual modules than you haven’t understood the project for a long time. I’ve had commercial modules not work because Core or other OSS modules are broken. I’ve had OSS modules that did not work because other OSS modules were broken or had bugs.
Moreso, all these modules are installed by default with the Distro. So, the fact you have to resintall a bunch of modules means you went through and uninstalled them originally. It kind of seems this is an issue only for those that have gone through and disabled/uninstalled a bunch of modules in their distro install.
I mean based on how much stuff in FreePBX requires other things in FreePBX to work, this seems like a strange hill to die on.
I’m not trying to set some weird ideological threshold here. I will absolutely be using this.
But there needs to some kind of logic to this, or why have separate modules. Sure some thing will always have some type of dependency, but this is excessive.
So? The recent 0-day with restapps proves that my process is better anyway. If an unused module is not installed, it cannot be exploited. Because of that I only had a few known systems to check and lock down. Various customers use various commercial modules. I am 100% behind the concept of commercial modules adding functionality.
The only one I’m unclear on is the rtapi. The rest make sense. Endpointman would obviously be for provisioning, since we are not using direct SIP credentials with the softphone. What else in the module list is illogical?
I’d be interested in technical details on why the functions were integrated previously and now split out into the modules.
I don’t know what the right philosophy should be. If EPM is “the module that does [all Sangoma] phone provisioning” and restapps is “the module that provides app functionality on [all Sangoma] phones” for both hardphones and softphones then it makes sense.
It sounds like you would be more in favor of a single “Sangoma Connect Desktop” module that does all, but wouldn’t this be duplicating functionality that’s already elsewhere in FreePBX?
There are doctoral dissertations on this subject.
There have been holy wars on this subject.
Splitting up your code is good design practice while simultaneously being bad design practice.
I have sat in meetings about new module vs extending out an existing module. A lot of thought typically goes in to these things. Core could actually be split in to 6 or 7 modules. If a dependency can be replaced with a logic check it should be. Dependency hell becomes real very fast. One module breaking could take out 20. If there was end to end testing (not easy again poor early design choices) it would be less of a concern.
I get both arguments but I have come to hate monolithic code files. I have moved to the camp of break out early and break out often.
Sangoma Phone is much more than just an audio sip client. There is visual voicemail and presence which uses the APIs provided by Phone Apps (restapps) thus the dependency; planned future features will use it as well. Phone Apps has been developed since day one exclusively for hard phones provisioned with EPM, hence that dependency. Sysadmin is a dependency of all commercial modules. Firewall is not a dependency of Sangoma Phone, but if it is installed, there are features in the latest firewall version that support Sangoma Phone. The wiki indicates this. The sangomartapi (Real Time API) module is a newer module that supports some nice features such as call history being shared across multiple devices.
Strictly speaking there are MANY other dependencies for Sangoma Phone, as each dependency has its own dependencies. The Phone Apps module all on its own has a few dozen. On a modular system, this could only be avoided by duplicating code which we have chosen not to do for this project.
Jared’s criticism is valid though, even if there is nothing to be done about it in the immediate term. Right now we don’t support a Sangoma Phone install for a userbase that only wants an audio client and nothing else, or allow a cafeteria style of features where some are excluded and thus remove the underlying dependency. Feedback like this allows us to inform our development efforts as we go forward.
