Shared Line Appearances would be great. I have done some googling, and it looks like this is more than a trivial task, but nonetheless, it would be great.
Also the ability to monitor historical trunk usage to see if you are over or under allocated.
My 2 cents - In order of preference:
1 - Enhancements to Call Parking now available in 1.8 (and maybe some in 1.6.2), possibly including multiple parking lots
2 - Providing destinations on extensions for BUSY, NOANSWER and CHANUNAVAIL that can route the call similar to other modules. (Today, it goes to either voicemail/vmx or returns busy if no voicemail, which would be the default if not set).
This is more far reaching that I noticed initially. This will allow you to do time conditions for inbound routes so all calls can go to an extensions voice mail during the set time conditions. Very common feature request.
3 - “Reverse CID” using the Asterisk 1.8 CONNECTEDLINE() function (let’s you push CNAM information back to the caller such as the internal display name of who is answering the phone), for those phones that support this
This is a common legacy feature sadly missed by users. It is supported by all of the common endpoints and to me is a tie for number 1.
4 - Extension “search” module (or ability), so you can type in a number (including wild cards) and have the system show you a list of extensions, ringgroups, etc that match that number (with links to go edit them) or go direct to the appropriate GUI page if you get an exact match.
Sure hope this makes it in.
5 - Option to have all internal calls to an extension act like an intercom call (auto-answer), but external calls still ring. (With a lot of caveats that would need to be worked out)
Another nice to have
All of the suggested features would be wonderful so it is very difficult for me to prioritize.
-Multi-Tenant Access
-Better-working custom context (more basic for defining outbound routes)
-Desktop Dialer (For all OSs)
-Call Controller (Like RingCentral, but free)
Someone (dkwiebe)in 2008 created a phone book module so with a click of a button the freepbx phone book creates an xml file for Polycom or Aastra phones, Ticket 2800 (new patches)
I think this is a useful tool.
Gary
[p_lindheimer] I have re-categorized that ticket to the 2.9 Milestone so it is on the radar and will be reviewed when we are running through updates. Thanks for “bumping” that ticket to keep it visible.
- I 2nd Rymes issue.
I have a couple of small 3-4 man call centers, and turning recording on causes the monitor dir to be unworkable in just 2-3 months, and they only take calls 3-4 hours during the day. The gui should do sql queries, not dir listings to parse the monitor dir.
Archiving is inevitable, but I should hope it only needs to be done once a year.
- A better CDR report - it would be nice to see a more organized CDR report that showed the DID or trunk that a call connected on.
I have two pieces of input:
1.) Since major releases are the only time to add functionality, and since 2.8 and prior are nice and stable, I would take a little extra time. On the same front, adding too much new stuff could lead to stability problems.
2.) For people like us, who enable recordings for all of our incoming queue calls, ARI does not work well with many, many monitor recordings. I’d like to see some improvements in these areas, possibly including links to the recorded file in the FreePBX CDR report. I know that there are difficulties that crop up related to searching many, many files, but I think they ought to be surmountable?
Tom
One feature I miss from my old analog PBX was the ability to page and then have a someone answer the page.
It worked like this:
You page all stations by dialing 34.
You say something like “Joe, pick up.”
Joe picks up one of the phones and dials 43 (opposite of 34). And the group page turns into a point-to-point intercom call to Joe.
It was simple, intuitive and useful.
The current workaround is to page everyone and announce where you are paging from, then hang up and wait for them to call back to you. It works, but not as elegant.
Hi Philippe! Been a long time off the forum here.
My votes would be for:
airport style paging
internal calls to act like intercoms if set
Provide destinations on extensions for BUSY, NOANSWER and CHANUNAVAIL (Might make this #1).
Thanks for all the work!
John
I wanted to take a moment to thank everyone for the input you have given so far.
I’d like to remind you that it’s important to verify if there are already feature requests in trac for these ideas and if not, to make sure that you put them in.
A discussion like this in the blog is great for generating and discussing ideas, but you want to make sure those ideas stick by assuring they are in trac where we ultimately go when reviewing features and enhancements in this release of future releases.
I also want to request that in addition to some of the ideas that have been brought up in the comments, that input is provided for those items listed in the original post. The fact that I put those ideas in the original post does not necessarily mean they will get done, we are looking for feedback. (Though in a few of the cases, some of the work has been done since we are also not standing still…)
Also very important is we really would like to get feedback on when you would like to see the next release. Do we drag it on and try to pile more features, or do we focus more and get 2.9 out sooner? You input is much appreciated and we look forward to keep hearing from you on this!
To the extent that Asterisk starts to enable these abilities we will start to look for opportunities in the dialplan to implement them. Up until now the limitations have been in Asterisk and even when Asterisk starts to enable such functionality, it is often dependent on certain SIP INFO features being supported on the specific phones in question.
I think Astersk 1.8 has this enabled. Not via SIP INFO, but via SIP Diversion header (for CT, CFU, CFNR, CFB…), and SIP PAI (Caller ID update in 200 OK, 180 Ringing… messages back to the caller).
All this CT info and CPU info can be done with these two SIP features… (I know Aastra and Polycom supports it).
[SkykingOH] This is correct, it is not an info message but an update contained in the RPID.
As long as the CALLEDPARTY (or is it CONNECTEDPARTY) variable is kept updated every channel bridge change event will generate a matching RPID change in the invite of diversion message.
I would love a way to enter a telephone number and be able to get a report which dialplan and trunk it was using. Graphical would be even better!
Secondly, a way to easily make an announcement to the caller (possibly identifying the trunk or cost) before sending a call out a trunk.
Thirdly, a way to easily export and import blacklist numbers.
I’d like to see the following implemented :
- a small, simple fax GUI like Elastix has
- more T.38 fax settings ( ECM settings etc… )
- more granular user rights ( assign very granular user rights to users. Read / Write / Full control for each of the modules rather than Full control or nothing ).
- extension provisioning ( this really has my highest priority. This alone would be worth upgrading to 2.9 )
- a FOP panel like Elastix has, but less bulky and less CPU intensive
- real-time asterisk support
- PostGreSQL support
How About Multiple CID in 1 Inbound route
When I make an attended transfer of a call, I would like to have caller ID transferred as well.
Besides, I would like to have caller ID information on my phone when I pickup a call from another ringing extension.
[p_lindheimer] To the extent that Asterisk starts to enable these abilities we will start to look for opportunities in the dialplan to implement them. Up until now the limitations have been in Asterisk and even when Asterisk starts to enable such functionality, it is often dependent on certain SIP INFO features being supported on the specific phones in question.
I’d like to put a vote in for the expanded parking lot features, specifically multiple parking lots
How about a modification in the Extension screen to allow specifying TCP transport for a particular extension.
In regards to the time frame, I’d like to see most module updates back ported to 2.8 installations running Asterisk 1.8 and have 2.9 out in various beta forms for at least 6 months before a final release. This would insure that developers of third-party modules have time to adapt to any new framework put forth for 2.9.
[mbrevda] for the most part, we dont anticipate that 3rd party dev’s will need to do any major work, if any work at all, to adapt to the proposed framework changes. While there may be some corner cases, we have gone to great lengths to ensure backwards compatibility and except most 3rd party module to breeze right past these changes.
kenn10,
backporting functionality is usually something we frown on fairly heavily, mainly due to a general rule of not adding new functionality to stable releases.
On occasion we will back port certain things to earlier releases as a means of “addressing” certain issues, such as the CSV upload ability in routes and trunks which we indicated quite some time ago that we would do it after hearing enough feedback that we felt comfortable with the changes (and it’s been fairly quiet ever since we did asked about it…) This approach is key to keeping the production versions extremely stable.
As far as the “internal plumbing” changes that have been on going and were commented on, they should have no affect on FreePBX modules, both ours and third party ones. To the extent that anything does, it should be extremely minimal (like the location of an include file changing). The changes that occurred going from 2.7 to 2.8 in the schema and APIs for outbound routes and affected a few non-FreePBX modules are rare, and there was really no way of keeping forward compatibility in making those changes. There is nothing even close to that level of impact that is being considered at this time.
Concerning Asterisk 1.8, we are responding to bug reports against FreePBX 2.8 as it is currently our intent that it should run with 1.8. To the extent that any of the 2.9 work is done as an independent module vs. something added to core, it is very likely that users will be able to manually install those modules on 2.8 even if we are not technically supporting it. The Google Voice trunks are an example, if we decide to do these as a separate module that simply configures a “Custom” trunk for you vs. building it into core, which would then not be easy to move back.
So given this new data, do you still feel that such a long beta cycle would be desirable? (and 6 months is quite long)
I just saw kenn10’s post on the PBX in a Flash forum, where he said:
For example: If people do not like the 2.8 change in the routing screen, then suggest fixes for 2.9 or that an import module be included for flat-file or Excel import.
Yes, I hope that will be fixed in 2.9. Assuming we’re not going to get the old behavior back (I wish), my preference would be for a way to upload route and trunk data from a comma-quote delimited text file (aka a CSV file, I think), since those can be created in any text editor and in many database programs. It would also be nice to be able to have a comparable download option, so you can download your route or trunk patterns from one system and upload them to another.
[p_lindheimer] The upload from CSV file has already been completed, see comment above “…and CSV file uploading of outbound route patterns and trunk dial rules.” Your request wrt to downloading is already being reviewed but the feedback is welcome. There are also some performance issues being looked at when large numbers of patterns are present.
you’re right, I’m wrong 
Of course I was thinking about “dialrules with trunks”. Thanks!
I hope that Support for Google Voice Trunks will also provide support for URIs in the phonebook.