Features we are Considering for 2.9

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.

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

What Version of FreePBX Should You Use?

With 6+ years under our belt and releases that started as AMP followed by FreePBX versions 2.0 – 2.8 and now 2.9 underway, there are a lot of versions floating around out there that may make you wonder, “what should I be running?” This question is complicated by the fact that different FreePBX distributions tend to move slower than others in adopting new versions of FreePBX, with varying reasons why they each move at their own pace.

Given this confusion, I’d like to shed some light on our perspective and general approach to managing the various releases. I’ll start by quoting a comment I read the other day in a forum post that may imply some of you are mis-interpreting the bug tracking data and thus possibly making decisions you did not intend to. The user commented that:

“The other thing that sort of puts me off [upgrading] is the relatively high number of (so far) unaddressed bugs (see http://www.freepbx.org/trac/query?st…&group=version and note the relatively higher number under the 2.8 branch”

What does it really mean when you see bugs listed under a given branch? As a general rule, when a bug is reported, it is reported against the current branch and when not, if the bug exists in the current branch, it is often reassigned to that branch. The reality that we find is the majority of bugs reported in the current branch (and earlier) are bugs that have existed in many earlier versions, often going back years. Our normal process with bugs is to fix bugs in the current release and very rarely do we back port those fixes to the previously (supported) release or earlier ones.

The time that we see the most bugs being reported is when we are actively engaged in a beta/RC cycle. This activity prompts large numbers of the community to proactively look for issues and as a result, there are typically large numbers of bugs uncovered during these periods. We find that significant portions of these bugs exist in previous releases, though more often then not, they are never applied back to either of the currently supported releases unless they are determined to be significant. (When a bug has been sitting around for years un-detected/reported – it is usually not very significant).

What does all this mean? This approach is taken for a good reason; If the bug has been lurking in the code for so long un-reported, it’s probably best we not perturb the current releases since any bug fix always has a chance of breaking something else in the process no matter how careful we are. However, these very facts violate that premise assumed in the user’s quote above. The reality is each new release of FreePBX usually contains many less bugs than older releases. If that is your priority, you are usually better off moving forward. If you have a system that works and to your knowledge, there are no new features available in the new releases that you care about, then there is always prudence to “if it isn’t broken, don’t fix it!” However – I suspect most of you who have not poked around the new releases may not really know what awaits you for features that you didn’t know you really wanted!

The one exception to back porting bug fixes is with Security Vulnerabilities. Although I can assure you that 9 out of 10 such vulnerabilities reported to us are very insignificant and very low risk, we still back port them to many earlier releases. Up until this point, we typically back ported such security patches on all versions back to 2.3. Given the age of these older releases, and the busy work that is involved in updating them, we’ve decided to limit the number of releases that will be updated with security patches to 2 releases prior to the currently supported versions. At this time, that means we will back port security issues to version 2.5 and above since the currently supported releases are 2.7 and 2.8, unless we determine that a vulnerability is serious enough in which case we may supply updates to earlier releases as well. Versions prior to 2.3 have not had any updates for quite some time.

I hope this helps you better understand what we maintain in what releases, how to better interpret the bug tracking system and realize that our latest releases are typically the most stable and have the fewest bugs in them, contrary to many other software products out there.

Philippe – On behalf of the FreePBX Team

Lots of Good Stuff at Astricon 2010

Just go back from last week’s Astricon 2010 held in Maryland this year and we are excited about what the future prospects are for FreePBX after getting a taste of what Asterisk 1.8 and beyond have in store for us, as well as other various technologies and applications that we will have at our disposal to keep forging ahead. Of course some of you have already been playing with 1.8 and FreePBX which we strongly encourage to help clear the path for the rest of the community.

It was pointed out to me that FreePBX was rejecting Asterisk 1.8 at installation time and sure enough, we had updated the install_amp script in trunk but that had not made it back to 2.8. It’s there now and I’ve updated the 2.8 tarball with the minor changes to the install script so that it should no longer complain.

We are told by the Asterisk community that their goal for 1.8 was ZERO dialplan changes. The feedback we’ve heard so far seems to reinforce that but if you run into bugs, let us know and we’ll try to get right to them. (On 2.8, we won’t make any changes to prior releases of FreePBX).

I’ll highlight some of the exciting technologies that we saw at this year’s conference but with everything going on, this will only be a small snapshot. As we start consuming new features and technologies in future releases, we’ll try to talk more about them here.

During the Keynote presentation, the Asterisk team had a great dog and pony show demonstrating some proof of concept of what the future eventually holds. The new project is called SCF (Scaleable Communications Framework), an extension to Asterisk, allowing true distributed and fault tolerant solutions some day. In the demo, they had a live phone conference going which was already distributed between two servers. They pulled the plug on one of the servers and the conference just kept on ticking. The project is at its infancy but it’s very exciting to see what the future hold!

We got a taste of some of the 1.8 features that are here today. Distributed device state information amongst servers is a very exciting one that will go a long way for those of you trying to better glue together multiple servers such as branch offices with their own instance. We’ll start to see what tools we might be able to provide that could facilitate setting up such configurations more seamlessly. The Calendar functionality in 1.8 should be a fun one to start thinking about enhancements and maybe a new module in FreePBX. This function allows the diaplplan to query calendar state information in making call flow decisions (similar to what you may do with the Time Conditions module). It also would allow the Dialplan to write back to your calendar. Those are just a couple of the MANY new features coming this way.

One very interesting gem that I came across on the exhibition floor is something called VQA for Asterisk (Voice Quality Assurance) by a company called Ditech Networks. This is an add on module to Asterisk that can play miracles on the voice quality passing through your PBX, removing all kinds of background noise, far end echo that traditional echo cancellation doesn’t not address, and more. It’s not free but at only $10 per port, it’s not exactly expensive either. We are looking forward to getting some licenses loaded up and determine what simple changes will be needed to allow FreePBX systems to take advantage of this great technology.

I’ve only skimmed the surface as there were many other interesting technologies that will find their ways into our sphere, but for now, it’s time to go back and start playing with some of these instead of just talking about it!

Philippe – on behalf of the FreeBPX team!