What would you like to see added in FreePBX 15?

auto update of modules as well. When the auto updates part was mentioned for v14, I thought that would include the modules, not just “under the hood” stuff.

It does both

How the hell did I miss that. :slight_smile:

I noticed that here on the forum, when Sangoma employees talk about estimated release dates of features, update scripts, modules, beta software, etc., the estimations are almost always way too optimistic and not realistic.
The actual release dates turn out to be months later.

That’s not necessarily about FreePBX 15, but more of a general, friendly feedback.
No offense, just something I have noticed and wanted to mention.
:wink:

You have just described the entire software industry.

7 Likes

Is this the method you are recommending?

I am requesting it to be added to that dropdown. Just click “save as mp3” and be done. That would make things a lot easier then having to configure scripts.

I’m curious why there is demand for this feature. There is usually no problem playing the (mono, 16-bit samples, 8 kHz sampling rate) .wav files in Windows, Mac, Linux, iOS or Android. At 128 kbps, the files aren’t terribly large (1 TB is > 16,000 hours of conversation). And if for some reason lossy compression was desired, I’d choose a format (OPUS, AMR-WB, perhaps AAC) with less degradation for a given bitrate.

I previuosly mentioned Flash Operator Panel functionality. Specifically it would be nice for a main reception console to be able to have a list of all extensions and ring groups and then be able to drag and drop an incoming call onto an extension or ring group or queue, or even directly to an extensions voicemail. This is very much needed in larger deployments.

2 Likes

Flash is slated to die at the end of 2020 (and hopefully that date is kept IMO) — is the flash operator panel a holdover name that a new HTML/JS version uses? I haven’t used said operator panel so I’m not familiar with it. If it does indeed refer to an Adobe Flash version it may not be wise to put more development effort into it.

Yes, it’s html5

1 Like

I would like to have an option to create inbound routes per dahdi channel and not only per DID.

This is for the actual recordings of the calls, not the system recordings. For call recordings difference between wav and mp3 is gigabytes.

What bitrate are your .wav files? Your .mp3 files? And why .mp3 instead of OPUS or another modern codec that provides less degradation for a given bitrate?

another +1 for improved IPv6 support. Unless I’m badly mistaken I cannot even configure an IPv6 transport using the GUI. Just tried to do this for PJSIP and failed miserably.

Users / Groups:

  1. Don’t delete users/groups from external directories if they’re deleted in the external directory - just flag them for cleanup. We continue to have issues with user and group settings occasionally disappearing, presumably due to sync issues (perhaps rebooting or otherwise losing connectivity to an AD server during sync or something?). Even beyond sync issues, there is also the possibility of admin error and we don’t have granular backup/restore capabilities for these settings like we do with AD itself. This has been a pain point for us.

  2. Related to (1) above, support multiple AD servers for syncing. Or preferably just let us specify the domain and pull the server list from DNS (_ldap.tcp.dc._msdcs.mydomain.com).

  3. Move all of the user / group data into an extended AD / LDAP schema - this would eliminate (1) completely and make it very easy to backup and restore, and might lead into some very interesting scalability / failover capabilities for large organizations.

High availability:

  1. Support multiple Ethernet interfaces for failover (we have a situation where we have to use RFC-1918 addresses for internal clients and a publicly routable IPv4 for the provider over MPLS, and we will probably run into this again).
  2. Support cross-site failover (I think this is already planned for 15, but including anyway).
  3. Active/Active support - many phones will allow a secondary (or more) SIP PBX connection, and with cross-site failover this would provide better support for datacenter site failover.
1 Like

Extension / endpoint management:

  1. Extension Groups, please, please, please. Managing them individually is a huge time-waster.
  2. As mentioned by some others, more aggressive support in Endpoint Manager. If you had to triple the price to accomplish this I’d be perfectly happy to pay it. I can see where this is just a massive, hideous, soul-draining pile of suck from a development and maintenance standpoint, but as customers we really do need this.
  3. Don’t default to PJSIP for installations. It would be nice if it was ready for prime time, but in our experience it is not. First thing we do with new FreePBX installs is switch the ports around so that SIP is the main protocol.

UCP / Phone Apps:

  1. A system for placing local extensions, system-wide contact lists, site-wide contact lists (by user / extension group), and end-user contact lists on the phone BLF keys / expansion modules. We have a hacked system internally for this (site extensions first, system-wide contact lists, site-wide contact lists, then personal contact lists ordered by list name), but it would be nice to have a formal solution for this.
  2. Flesh out XMPP support some more in UCP - show other users, preferably with the ability to filter out those who are not members of the same group(s).
  3. Access to various contact lists for SMS. We have a customer who dispatches drivers via texting and an internal web app, and they would LOVE to have access to their various driver lists by User Group (not just for SMS - for calling, etc.).

If that’s your experience please help everyone by telling us why you think PJSIP isn’t working for you and the details of your problems.
If those things aren’t put into a bug report either with Sangoma or Digium, unfortunately nothing will be done to improve it and in five years we’ll still be saying “PJSIP isn’t ready for prime time”.
In fact Digium receives hardly any bug reports on it, so PJSIP won’t be different a year from now if we don’t provide them any.

In fact there is a lengthy thread about PJSIP, the perception of it, and its problems:

@avayax Interestingly the very last post on that thread you linked to had you saying

“You can use pjsip on internal extensions, but use chansip for your Sip trunk providers”

Have you changed your mind?

There are many VSP’s that will ONLY register against 5060

It is relatively trivial to arrange for all you internal (and external) extensions to use your pjsip port (5060 would be my last choice for any number of reasons) , I’m not saying chan_pjsip is bad it has great enhancements for extensions , not so much needed for trunks and chan_sip is pretty well rock solid , the VSP’s accept that fact and provide howto’s for provisioning it.