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:
[]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

This would be VERY nice!!!

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)

if your did is 1234 then create a inbound route for did put 1234 and for callerid put _800NXXNXX (notice the underscore that creates a match)

I would like to see BLACKLIST feature have the functionality (option) to be explicitely set for all 800NXXNXX inbound dialing on a per extension basis.
This gives a viable option for those of us caught in tele-marketing pergatory. Please let me know if there is a possible dial pattern work around in the meantime. Thanks -Ed

Since it’s an issue that’s come up multiple times, AND you can brick your system if you do it wrong, IMHO, changing passwords for the ‘access FreePBX’ function (the one that has default username/password 'freepbx/fpbx’at http:///admin/) should be a function in FreePBX. Like:

user freepbx
New password ______________
Reenter New password ______________ /SAVE/

I am only an egg, but it does seem to me that

  1. Leaving the default password in place is a bad idea in principle, ESPECIALLY when FreePBX reminds us to change it when we log on for the first time! Physical security is all well and fine, but then why have a password at all?

  2. Making a noob user edit MULTIPLE conf text files to change the access password is a really really bad idea- what’s the point of FreePBX in the first place?

  3. This is the sort of thing (editing MULTIPLE, CRITICAL conf files) that computers do well, and people do poorly.

  4. Having some distinction between ‘user’ accounts (such as ‘admin’) and the access method user (freepbx at http:///admin/) would be helpful. This goes back to UI research- (what does a noob admin actually DO when they first fire up the system?)

Maybe somebody who understands Asterisk a whole lot better than I do could figure out how many different kinds of passwords and accounts are really needed? I’m confused about the distinction between the freepbx users, like ‘admin’ and the web access user ‘freepbx’ which got me in at http:///admin/.

Thanks for all you do. I understand this request is at a kindergarten level compared to all the grad degree requests from experienced sysadmins out there, but security does come back to the basic question for a home user: what do I really need to do to secure my phone system, on a wired/wireless network in my house, behind a router with a firewall?
(The best answer would be for Asterisk to automatically set up whatever’s needed (iptables, FailToBan, or maybe it’s secure enough without anything??) at a basic level, or just say Asterisk/FreePBX isn’t safe to use unless you know how to do that yourself.)

Russel updated information on the Connected Line Dial Plan function in the documentation wiki.


This is very cogent and useful. I am going to try some of these options tonight with Polycom, Linksys/Cisco/ Real Cisco and Astra.

I will start a new thread with “connected line testing status”

Unfortunately my only experience is with 2.6 and 2.7, and I don’t want to install a new system for this single comment so ignore it if this has been addressed in 2.8

  1. I would like to see more detail in the call report, specifically it would be nice to see what trunk was used for an outgoing call. I don’t think it is necessary to have more columns, but perhaps each entry could have a link to a window with more information, including trunk, recordings (if present), context etc.

  2. Also when a call comes into our system, it immediately hits a ring group, is answered by reception then blind transferred to another extension. No matter how many times the call is transferred, each leg of this call shows up in the reports with a dst as the original ring group, so you can’t tell specifically which extension ultimately ended up fielding the incoming call.

  3. It is alreay possible to create a misc. application with a pattern match, i.e. create a feature code of “_888X” which will match all 4 digit numbers starting with 888, but there does not seem to be a way to retain that unknown digit and pass it on to a misc. destination. It does not seem to be possible to create a custom feature code PREFIX with FreePBX.


  1. not sure what simplex is
  2. hmm - didnt think of feature maps. Have you tested if those work in conferences? How would you prevent them from being fired elsewhere?

Simplex is the opposite of Duplex (sorry perhaps a French only word).

Audio can only go to one direction. Most of the time from the caller to the callee.

No i didn’t tested if they work in conferences. Any other solution to detect an action on a phone ?? Perhaps hangup the phone ? Not as elegant. Or use an XML script (not as standard) ? Or a BLF key (does not work on all phones) ?

Or put the call on hold and come back to him ? If Asterisk is able to detect this.

olivier1010 - as for the second idea, technical details would be helpful, because I cant think of any way to do this as asterisk stands now.


For Paging with intercom answer, here is what i think :

  1. a call is done to a simplex paging group. All phones of the group go to autoanswer, so that everyone can here the announcement, but cannot answer yet.

The simplex mode is important here, to avoid audio echo and Larsen audio loops.

There is nothing special here, except that perhaps the call needs to be technicaly managed like a conference to allow next operations.

  1. If somebody wants to reply to the announcement, then he goes to the nearest phone of the paged group, and press a key (for example key “5”, it is easier for blind peoples because there is a small 3D mark on it).

  2. A feature application map recognize the key “5” on this phone, then :

  • it switch off the paging group except for this answering phone

  • it switch on duplex mode for this answering phone

  1. The answering people can talk privately to the caller in duplex mode.

On old analog paging systems, i remember (35 years ago at a client site !!) we had a red button on each pager to switch from public simplex paging to private intercom duplex mode. This is replaced here in my example by the feature application map on key “5”.

This has been discussed here in the forum between Philippe and me two or three years ago. The feature application map and conference call ideas does come from him, but at this time, according to Philippe, this would have been quite difficult to implement with Asterisk 1.4 (perhaps 1.2).

I will have only two important feature requests for version 2.9 we are waiting since years :

  • Caller ID update during call transfer and pickup. To my knowledge, this need a SIP reinvite with the new CallerID to work, at least with Aastra phones. Is Asterisk 1.8 able to send a reinvite to an extension during a call ?

  • Paging with intercom answer (switch from simplex paging group to duplex intercom pushing a key on the phone keyboard nearest to you)

This paging method was used on very old paging systems since more than 30 years and was very efficient.

[p_lindheimer] I think these are both very useful features. As already mentioned, to the extent that the new capabilities of 1.8 will provide the tools to improve the Caller ID ‘experience’ we will attempt to take advantage of those abilities. As far as the paging request, Asterisk has evolved to where we can do a reasonable job of implementing this and someone wants to breadboard the ‘guts’ of making this work, I’d be happy to see what we could to do get it in. The problem in the past has been limitations in the underlying conference application, but maybe with 1.8 there are new options available.

I don’t know if anyone has suggested this already but here goes. How about a user mini-portal that would require a password for access? From this users should be able to do basic tasks such as set the various flavors of call forwarding and maybe find-me follow-me, and to manage voicemails (listen, download, and/or delete, as well as upload custom greeting). The trick would be to only allow users into their portal where they could only affect their own settings, not those of any other user, and to keep them out of things they should not be allowed access to. I am aware that some third party distributions have made an attempt at this (and this might actually be a part of FreePBX now, it’s hard to tell), but in some cases these give users access to things that they should in no way have access to (for example a very popular distribution gives users access to a “Voicemail & Recordings” but also to other things such as “Flash Operator Panel” with no access protection at all - WTF??).

So my suggestion is to either add this feature, or if it’s already part of 2.8, then have a way to make it the first and only thing users see when they come to the web portal, and hide the FreePBX administration pages behind another link that can only be accessed by administrators, preferably with additional access controls (see Webmin’s access controls for examples). There should also be additional controls to protect web-facing 3rd-party apps, such as the aforementioned FOP, from being accessed by users trying to reach their personal settings page (I know, not part of FreePBX, but it’s still a security risk TO FreePBX if users can get into places they shouldn’t).

mbrevda - Not sure how this differs from the ARI? You may want to clarify this point, (possibly using less words to keep the clutter down)

p_lindheimer, sorry I did not catch your reply sooner, but I guess I’m not quite following how the statement “Inbound routing can also use patterns on CID” relates to using patterns in the blacklist, unless you make the blacklist a possible destination for inbound routes (or I suppose you could just use a "Terminate Call destination). From a user perspective, it would be a lot easier to just be able to use patterns in the blacklist. On the other hand, I read somewhere that the blacklist relies on the Asterisk database, so if Asterisk doesn’t support patterns in blacklisted numbers then I suppose it would not be possible for FreePBX to do it. It was just a suggestion.

Here’s another suggestion: In newer versions of FreePBX there are new pages for Asterisk SIP settings and Asterisk IAX settings. I know this is an attempt to make things easier for those who know how to set the values, but many new users have no idea. But also, the SIP settings module prints a warning that settings in /etc/asterisk/sip_general_custom.conf and in /etc/asterisk/sip_custom.conf may override the settings in the module. But because the module doesn’t show the settings it’s adding in the way they’d appear in a config file, users might have no idea which settings are conflicting and can be removed. My suggest in to add a button that would go out and read the possibly conflicting files, look for values that may conflict in those files, and display them on the screen, and then offer to simply remove those lines OR to import and remove them. In addition, under each conflicting value found, it would be great if a line or two could be added explaining what the value does and why one might set it a particular way.

And while on the subject, although the tooltips you get when you mouse over an item in those pages are informative, in some cases they don’t really explain enough for new users to understand. For example, which of the four choices should you pick for the NAT setting? What’s the difference between a Public IP and a Static IP? What are good values for the RTP times and under what circumstances would you want to change them? What reinvite behavior should I use if I know nothing about it? It would be nice if there was a page with maybe 1-3 paragraph descriptions of each of these items and others on these pages, aimed at giving the new user enough information to make intelligent choices without bogging them down in theory. Even a statement like “Most users set the Reinvite Behavior to…” would probably be helpful to those who have no idea what all that means. And I must admit, even though I’m not exactly a brand new user, I’m rather hazy on a few settings on the SIP page.

Again, just a suggestion, and I do realize that no one is forced to install and use those modules.

I’d like to see more “Bulk” pages along the lines of “Bulk DID’s” and “Bulk Extensions” - certainly for the blacklist module, but also for things like IVR’s, Outbound Routes, and Trunks. I do realize the latter two might be a bit more difficult because of the dial patterns.

Also, speaking of the blacklist, it would be great to be able to blacklist by means other than a straight 10 digit number. Caller ID Name (full or partial match) would be an obvious choice. Also I’d like the ability to blacklist by patterns, so that totally invalid numbers (for example, one or two digit Caller ID’s such as 0 or 99) could be rejected, without having to enter every possible number that might match that pattern individually, though care would have to be taken to make sure it can’t block calls from your own extensions.

On inbound routes, the ability to automatically strip a leading + sign from an incoming Caller ID number would be handy.

[p_lindheimer] There is already a context provided in extensions.conf (from-pstn-e164-us I think) that will strip off the + on CID and DID. Inbound routing can also use patterns on CID. So some of this is already there.


I don’t take it as an insult. In fact I never hear anything about GUI except from Philippe himself. So anything is better. Thanks for pointing me in the right direction with that site. I will have to check it out.

vote +1 for more improvements in user rights and for provisioning


  • good question! :wink:

I haven’t really played around with the FreePBX endpoint manager a lot, but the first impression just wasn’t “wow” - maybe it’s just because the GUI isn’t all-shiny and polished; the functionality might be okay (as said before I’ve still to check it out in-depth - and please don’t take my comment as an insult!!!)

What seems to be a really nice (looking and functionally) provisioning tool imho is that of Amooma’s “Gemeinschaft” (might mainly or only be in German, but that one is quite nice, at least for the snom phones we use). Some screens are on their web site as well as some YouTube vids - but their provisioning concept is a bit different from FreePBX’es.

A bad example of an Endpoint Manager (mainly concering functionality) is trixbox’es…

If I find some time I’d try to come up with some suggestions or stuff for the Endpoint Manager module.


What would make endpoint manager ‘really cool’?

1st priority:

There once was a bounty for this where I even put a few buck in. The endpoint manager in the extended repo is nice but quite a bit away from being really cool

5th or so priority:

Definitely a “nice to have”, imo. But: If we get taht, I’d like it to be “kick-ass”, not just quick and dirty (read: I’d prefer to wait some more time to get something cool in this area than haveing “something” asap!). If I had time I’d comit to volunteer for this task.

5th or so priority:

Another “nice to have”, but not #1 priority for me. (btw: Shouldn’t be that much work, or am I missing some complexity here?)

…and my other number 1 or 2 suggestion (as frequently requested/complained about by our users):
Some sort of logic to differentiate the routing of internal->internal v.s. external->internal calls. E.g. that Follow Me can be configured to behave differently on internal and external calls. (Having that also for Call Forward would possibly be massively more complicating.)

…and another “nice to have” suggestion (not a sohwstopper problem and really high prio - but our “#1 most frequently requested by users”):
Some sort of ringtone selection, e.g. in the ARI, so that users can select their own ringtone and have them played on calls to their fones (via alert-info). Yes, I know that there are quite some implementation problems with this!

P.S.: Many thanks for this one, Philippe: