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.
[/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

42 thoughts on “Features we are Considering for 2.9

  1. 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)

  2. 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
  3. 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.)

  4. 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.

    Lorne

  5. 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.

  6. mbrevda,

    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.

    2) 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).

    3) 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

    4) 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).

  7. 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.
    [i]
    [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]

  8. 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).

    [i]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)[/i]

  9. 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.

  10. 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.

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

  11. pwalker,

    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.

  12. tm1000,

    – good question! 😉

    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 [url=http://www.amooma.de/gemeinschaft]”Gemeinschaft”[/url] (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.

  13. 1st priority:
    [quote]12. End Point Management[/quote]
    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:
    [quote]8. Some level of integration with the Asterisk 1.8 Calendar function[/quote]
    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:
    [quote] 10. Add Check-box to Feature Code module to indicate which feature codes to create “destinations” for[/quote]
    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:
    [quote]I just finished implementing a dedicated feature code for each time condition that can be assigned to a BLF.[/quote]

  14. 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.

  15. 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.

  16. 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
    [i]
    [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]

  17. 1. 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.

    2. 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.

  18. 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

  19. 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.

  20. 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

  21. 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!

  22. [i]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]

    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).

    [i]
    [SkykingOH] This is correct, it is not an info message but an update contained in the RPID.
    [/i][i]
    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]

  23. 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.

  24. 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
  25. 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.

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

  26. 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.

    [i][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.[/i]

  27. 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)

  28. 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.
    [i]
    [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.
    [/i]

  29. It’s definitely not critical but ‘nice to have’ feature – I would like to see position up/down arrows for the Dial Patterns on Edit Route page, the same way we have this for Trunk Sequence on the same page. Thanks!

    [i][p_lindheimer] The request is noted, be aware though that the order of patterns in outbound routes is ultimately sorted in ascending order. The order has no affect on functionality. That is very different from dialrules with trunks where the order can make a difference. Is that what you had intended in this request?[/i]

  30. The three that stand out to me are:

    * Extension “search” module – would be very useful when large numbers of extensions in use
    * Endpoint Management
    * Providing destinations on extensions for BUSY, NOANSWER and CHANUNAVAIL that can route the call similar to other modules.

    [i][p_lindheimer] Related to the extension search module, I did just updated the Print Extensions module so that all the numbers listed are now links. Not quite the same but related in case you are interested. Concerning the Extension destinations, those have just been added to 2.9 as some work had already started on that prior to this post, just FYIs for now…
    [/i]

Leave a Reply