After returning from Astricon where we reviewed Asterisk 1.8 and other exciting technologies [url=/news/2010-11-01/lots-of-good-stuff-at-astricon-2010]I blogged[/url] a bit about it which led several of us developers to discuss what features should we put into the next release and consequently when should we target that release to come out? Between those discussions and scanning tickets and some forum posts we’ve come up with a handful of ideas but wanted to pass them by the general community to get your feedback or other thoughts before starting to crank some of these out. Of course the choices will have an impact in the schedule we set for the next release which means at some point we’ll have to make some decisions depending on whether you would rather wait less or more time to get 2.9 out the door. Also, as always in Open Source, the personal interests of those contributing to the development also influences what gets done.
There has been ongoing work on 2.9 so a handful of features are already there. For example, I just finished implementing a [url=/trac/ticket/4636]dedicated feature code for each time condition[/url] that can be assigned to a BLF. It will always show the current state of the time condition, and allow you to manually switch over to the “other state” while automatically resetting itself once the current period is over. In other words, 3:00PM on Friday we decide to close early, you press the button, and Monday morning it has already reset to the standard mode for opening hours.
There’s also been significant work in what I always refer to as the “internal plumbing” which translates to anything from code cleanup to performance enhancements, or more. A few other bits that come to mind (and I’m sure there’s lots I’m not thinking of) are support for app_confbridge, optional SIP diversion headers and CSV file uploading of outbound route patterns and trunk dial rules. I also know there are some patches that have been submitted to trac for various things which we still need to go through and get into the code where appropriate.
So the question: where do we focus our efforts on this next release and what date do we shoot for? Some of the ideas we have been floating around include :
[list]
[*]Enhancements to Call Parking now available in 1.8 (and maybe some in 1.6.2), possibly including multiple parking lots
[*]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).
[*]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.
[*]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)
[*]Support for Google Voice Trunks with Asterisk 1.8
[*]Camp-On Feature using the Asterisk 1.8 CallCompletionRequest Application
[*]”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
[*]Some level of integration with the Asterisk 1.8 Calendar function (adjusting call flow based on the current state of an external calendar
[*]Move all the amportal.conf settings into the GUI and configurable there (with the exception of some basic ones like the database credentials), this could have impact on non-FreePBX applications that depend on the settings in this file
[*]Add Check-box to Feature Code module to indicate which feature codes to create “destinations” for, so they can be used with other modules (e.g. IVR) without having to create a separate Misc Destination for each
[*]Airport Style paging (message is recorded and once you hang up, the page goes out a short time later)
[*]End Point Management
[*]DAHDi card management
[*]Internal changes that affectively “bootstrap” the FreePBX environment giving a developer access to all the common functions (APIs) that normal FreePBX modules have access to. This could also have some impact on non-FreePBX applications in the eco system that depend on the current structure today but will make it much easier for new external applications to be written and the changes to existing applications should be fairly straight forward.
[/list]
These are some of the ideas floating around that we have had from various discussions. Clearly some of them require Asterisk 1.8 and would be of no value until moving to 1.8, which is very immature today. There are many other ideas that are floating around in the trac ticket system and in some cases, already implemented solutions that we will pull out and take advantage of where they make sense to do so. But with a list as long as the above, it helps to get your input, as well as other ideas not listed. The other important factor is how soon do you want to see 2.9? Two months from now, 3 months, … Some of these features could also have an impact on existing external programs within the FreePBX eco system. The bootstrapping ability and the module to replace amportal.conf settings are examples. This translates to, they could break other people’s programs which then need to be fixed. They are great ideas and we will eventually do them (with the same eventual consequences) but the question is, do we do them now or do we consider them in the next release after this?
So … with these ideas as a starting point, tell us what you think. I hope this to be a productive exchange, please try to do so. In order to plan ahead, I will mention that I reserve the right to moderate the discussion if needed to keep it on track, though hope there is no need for that.
Philippe – On behalf of the FreePBX Team