freepbx

We are working on a new Distro Install Process as we speak.

The plan is to let you go through the normal Centos Setup screens with a full Centos ISO and than we will prompt you with a payload/version option for what version of the Distro you want to install and it would pull down the packages it needs for the Distro like Asterisk, Dahdi, FreePBX and such so the amount of time it spends pulling down packages from the Internet should be about 1/4 of what it currently is with the Net Install only option that we have.

Which brings be to this Blog.

We are trying to come up with a better version number for the Distro mainly because lots of people equate the 1.8.2.x-x with that we are either using Asterisk 1.8.2 or FreePBX 1.8.

What I am thinking of is as followed.

asteriskversion.freepbxversion.centosversion-minor release number.

So for example the next release would be
1.85.29.55-1
This would equate to a Asterisk 8.5 with FreePBX 2.9 and Centos 5.5

We will also have a
1.85.29.60-1
Which would equate to Asterisk 8.5 with FreePBX 2.9 and Centos 6.0.

I would love feedback from everyone on what they would like to see in regards to version numbering so we can polish off the new Full ISO builds for everyone this week.

This will also allow you to wget the setup script from our webserver and just execute the script on any stock Centos Machine to turn it into a full fledge FreePBX Distro system.

Related posts:

1. Elastix 1.4 released
2. FreePBX 2.8 beta2
3. Hello from the FreePBX v3 coders!

freepbx

It has now been a little over a month since Tony Lewis announced the release of the new FreePBX Market Place. We have had an excellent response from the FreePBX community on the Professional Modules that have been released thus far. With that said it is apparent that the FaxPro module has stirred up the most interest. I wanted to put this blog out to answer the most common questions I have been getting and explain a little more about the module itself.

Here are some of the most frequently asked questions on FaxPro.

Q. What is the FaxPro module?
A. The Fax Pro module is a reliable, robust inbound/outbound faxing server. You simply enable faxing for any user on the system; then you point a phone number to specific fax user and let the FaxPro module answer the fax call.

Q. Does the FaxPro module work with T.38?
A. T.38 is handled by asterisk behind the scenes and has nothing to do with the FaxPro module. As long as your system is configured properly you can utilize both inbound and outbound t.38.

Q. Can I use FaxPro with my Trixbox / Elastix / Brand X deployment?
A. No. The FaxPro module can only be used with the FreePBX Distro.

Q. I have a standard Asterisk server, can I use the FaxPro module?
A. No. Again the FaxPro module can only be used with the FreePBX Distro.

Q. How is outbound faxing handled?
A. Outbound faxing is done through a web interface on your FreePBX Distro server. Simply enter the phone number you are faxing to and upload a PDF you would like to fax.

Q. I have a custom asterisk deployment. Can you work with me to implement a faxing solution?
A. We are always happy to discuss the scope of your project to determine if there is an opportunity for us to help. Please contact us.

FaxPro Features

• Individual inbound Fax to Email account for unlimited users.
  • This allows all of your users to have inbound faxes delivered directly to there inboxes. No need to stand by a fax machine to wait for an incoming fax.
• Outbound Faxes from PDF’s.
  • Outbound faxing made easy! Instead of walking across the office to a fax machine simply select the PDF that you want to send. This makes sending faxes quick and easy!
• Simple web interface to manage inbound and outbound faxes.
  • We have made viewing and managing faxes simple with a straight forward web interface.
• Have all inbound and outbound faxes stored on the server for easy viewing and archiving.
  • Access your Faxes from anywhere! Great feature for reviewing a quote you sent last month, or checking your inbound faxes when away from your office computer.
• Create company wide fax coversheets that allow easy customization for each user.
  • Allow easy customization of Cover Sheets for every user!

Here are some screenshots of the FaxPro Module.

Related posts:

1. AsteriskNOW 1.7.1 now available with add-on installer module for FreePBX
2. Preview the all-new Directory
3. New Elastix: version 1.1 available

freepbx

With 2.9 solidly behind us and one of the most feature rich releases ever, we are really pumped to keep up the momentum and brining you more great things! Several of us (active developers) spent some time last week to map out what we want to try and accomplish in the next release, when it should come out, and tackle the hard problem of what we will need to move out of the 2.10 wish list so that we can get a release out before the end of 2012! Since it’s really important for us to bounce off such plans on all of you, I wanted to share a summary of what is on our mind.

Because the last release cycle was just shy of a year and incorporated some substantial architectural changes, we thought we would take a bit of a breather and shoot for a target date of Astricon 2011 for our next cycle, which means right around Nov 1. Since 2.9 has been out for about a month, this means we have about a 6 month cycle, or 5 months from now. That will gauge what we can and can’t get in.

So what are we planning in that time frame? I will be updating the 2.10 Milestone to reflect more details of our current thoughts, but in a nutshell this is what we have in mind. First, what are the big things going into the release that people have currently signed up for:

1. Call Recording functionality. This is the one ”big ticket item” that we want to try and tackle in this next release. For those long timers who care about call recording, you are probably aware of the limitations and issues with getting calls recorded. Our plan is to revisit the call recordings ability system wide and try to come up with an overall call recording capability that deals with policy constraints such as call recording between extensions if one allows and one doesn’t, etc. More to come on what we have in mind once we sit down and really start to design this out.
2. Backup Module. Schmooze has stepped up to the plate and is planning on doing a rewrite of this module that has been long plagued with various challenges. Although this module often works fine for many, there continues to be a background ‘buzz’ of various issues that continue to be encountered and no one likes to find out that their backups failed at the time of restoring. Add your thoughts/comments/feature requests tothis thread!
3. IVR Module. Schmooze has also stepped up to the plate with a plan to rewrite this module. Details of what this means for features will be forth coming, but many of the changes are more internal coding changes that will facilitate our ability for other modules to “hook” into this. (This allows new functionality to be introduced, for example, a speech recognition module that could add the ability to speech enable an IVR).
4. New Features. This is always the one we have a lot of fun with and where we can best engage the community! We have yet to dig through the hundreds of tickets or hear your feedback to blogs like this one in determining what we can squeeze into this release so that will all be forth coming. There are lots of ideas and I’m sure plenty of you will take this opportunity to add more! We will do our best to listen to all the input, read through all the tickets, and see what we can realistically get into the release given the time schedule and other “big” changes we are working towards! For now though, feel free to toss out your ideas!

Outside of these major points, there are other decisions we have made going forward. Here is a summary and there will be more to come on some of these.

1. Asterisk release support: This topic is always sensitive and there has been a lot of discussion about this for quite some time. The challenge we always face is how far back to support an Asterisk release, in conjunction with their own support life commitments, and at the same time try to innovate and come out with new features and capabilities. In the timeframe of this release, 1.8 will have been out for a year and its stability is anticipated to be quite solid (it’s already looking pretty good now). Asterisk 1.10 will be coming out at the same time and as always we want to support the newest release. Both 1.4 and 1.6.x have already had their end of life announced and by the time 2.10 is really mature, will no longer be supported by the Asterisk team. Given all that, we’ve decided to take the approach for 2.10 that we will focus on 1.8 and 1.10 support. This does NOT mean that it will not support 1.4 and 1.6, it means that we won’t go out of our way to support those and it’s unknown until we get a bit further down the road if there will be support issues for these releases. We will evaluate the situation further down the road and if it turns out that these release will be affected, we will make sure that 2.9 has a long enough support life to cover the requirements of those in the community who need to stay on older Asterisk releases, even to the extent that the Asterisk team is no longer supporting these.
2. PHP Support: We will no longer support PHP4, which should not be an issue as PHP4 has been obsoleted now for multiple years and the measurable FreePBX population still on PHP4 is almost insignificant. We will be coding against PHP 5.3 and even though current releases of popular Linux distributions are not yet on 5.3, FreePBX already comes with a compatibility library that includes the missing pieces such that these will all be fine.
3. A few things we will be deferring because of the release schedule is a rewrite of the User Portal (ARI) and the replacement of the current CDR Reports. However, due to the Call Recordings re-architecting mentioned above, the ARI will be maintained so as to tie into those changes.
4. FOP: This one is a challenge we have been wrestling with for quite some time. The current FOP is not being maintained given the FOP2 that asternic has had out for quite some time. FOP2 is an excellent product and will be available in our Market Place, but the free version is quite lacking in its inability to have any control as to what gets displayed in the 15 free icons, thus making it very difficult to evaluate if it’s worth the purchase. (For you big sites, that’s not really an issue, but for all the small guys and hobbyists out there, it matters a bit more.) However, as it stands FOP does not really work and is plagued with issues which are not being addressed and we feel our hands are a bit forced in that it probably needs to be removed. That means outside of FOP2 (free and commercial) and the iSymphony solutions that will also be available in the marketplace, we are left without a good “free” replacement for FOP. We are happy to hear your thoughts and ideas around this as we really feel it’s something that is not in our control.

Well, there’s a pretty good overview of what is going on and where our collective thoughts are at. We really look forward to hearing from you as we continue to move forward on this and will make sure to keep you up to date and incorporate your feedback into our planning process!

Philippe - On behalf of the FreePBX Team!

read more

Related posts:

1. FreePBX 2.7 Is Final
2. FreePBX 2.8 beta2
3. Heavy Queue Usage in FreePBX

freepbx

We are excited to have the 2.8 release finalized and released for general availability. We moved to final release status at the beginning of this past week finishing the 2.8 Milestone with 332 closed tickets comprising of 231 bugs and 101 feature requests and similar. As always, a majority of the bug fixes are bugs from version 2.7 and earlier which are usually only addressed in the new release.

The efforts of 2.8 have been going strong since the beginning of March and we extended the beta testing period to assure a solid release since there were several changes in critical sections of the dialplan. There are way too many changes to recap all the added benefits throughout the release, some visible, some hidden. Some of the big areas that had substantial improvements include Outbound Routes (and some visual changes to outbound trunks), the newCompany Directory, some HA related enhancements to the Backup and Restore module, some significant scalability improvements to Queues, visual improvements to tool tips and “destination select boxes” thoughout and a host of other enhancements and new features across the system.

Join the 3900 systems who have moved to 2.8 so far and spend some time digging around to see what new features may be valuable to your system!

While we relish in a job well done on 2.8, the steam is already building up on work for 2.9! I mentioned plans around the Endpoint Manager and DAHDi configuration modules in last week’s blog and progress on that front continues to be strong! The definition of other features for 2.9 is still very much in the planning state as you will notice if you visit the 2.9 Milestone. We’ve had some suggestions in the forums and in tickets concerning other important areas people would like us to work on but more input is very welcome. If you already have feature requests in the ticket system, feel free to bump them onto the the radar scope. We will be looking though existing requests but they can be easy to miss when there are almost 500 tickets to sift through!

Related posts:

1. FreePBX 2.8 beta2
2. FreePBX 2.7 Is Final
3. Hello from the FreePBX v3 coders!

We are really excited about this new release and all that it brings. Just as exciting is the extremely low bug rate since we “opened the flood gates” by enabling the Version Upgrade module and all the new systems it has brought online. If the incident rate remains as low as it has we will probably be looking at a Release Candidate as early as next week! We’ve had early beta testers actively using the system for a few months now so confidence is high that this release is in a good state to move forward!

We provided a Sneak Preview of the release in an earlier blog, and have discussed just a few of the exciting features such as the Company Directory Module and the enhanced Remote Backup (e.g poor man’s HA) capabilities in earlier blogs as well.

There are way too many enhancements both big and small to try and list them here, and some of them you may find are quite “hidden” without digging though. For example, did you know that you can now collapse/expand categories in the Left Navigation bar by simply clicking on the category? If you are really picky, have a look at the new “secret”freepbx_admin.conf INI file, which lets you completely re-arrange the layout and names on the Left Navigation bar. (Sorry, there’s no GUI or module for that yet, maybe in the future…).

For those of you who have followed the attempts to get the Custom Contexts module ported to 2.8, you will be glad to know that the upgrade has happened and the module now functions properly on 2.8. In addition, it has had a handful of minor enhancements and other fixes that were previously not there. You’ll notice, for example, that the context text box is no longer present on extensions/devices; and on device types that can’t have a custom context assigned, the select box no longer shows up. You’ll also find that the context orders are now properly sorted based on the assigned priority and Outbound Routes default to the proper route order as dictated by the Outbound Route’s module when given equivalent priorities.

For now, we are looking forward that you to spend some time exploring all the small and big things we have done with version 2.8. As we wrap up this milestone, we are really excited to start planning for the next one. We have some great ideas in mind and as always we’ll be sifting through the trac system looking at open tickets to consider when planning the next release. We’ve also been thinking about a new facelift as it’s been a while, maybe we’ll get motivated … stay tuned!

Related posts:

1. FreePBX 2.8 beta2
2. Hello from the FreePBX v3 coders!
3. FreePBX 2.7 Is Final

Along with the kind assistance provided by some customers of FreePBX Professional Support (in the form of time donated for a feature they needed for their business), the boys over at Schmoozecom Com (disclaimer: including yours truly) have once again surpassed all expectations. As of FreePBX 2.8, (currently in beta – more on that later) the Backup module includes built in support for High Availability clustering!

The following is an interview I had with Me (aka myself), elaborating on the new features:

I: So, what is this new HA (High Availability) feature, and why are we so excited with it?
Me: To ensure that their critical infrastructure maintains a high level of reliability, many business seek out HA solutions of one type of another. To that end, we have introduced an automated capability for a designated server (herein: backup server) to periodically backup a production server (herein: primary server) and to restore said backup on the backup server. This ensures that the backup server always has a fresh copy of the primary server’s settings, and is ready to take over should the primary server fail.

I: Billions of bilious blistering barnacles – that’s not true HA! True HA means the backups in real time and instant hand off between the two servers?!
Me: Actually, according to ( wait for it – you’ll never guess!) Wikipedia, HA is “is a system design … to ensures a certain degree of operational continuity…“. While there may be some benefit to having both the backups and hand-offs in real-time, such solutions can to be overly complex and way above the requirements of many organizations. Additionally, such solution tend to require a unique and complex setup with additional components not usually installed on FreePBX based distributions. Being OS agnostic, FreePBX is best not left to deal with the configuration and maintenance of such solutions. Instead, FreePBX takes a simplistic approach, removing much obscurity and confusion from the picture. Keep in mind, however, that FreePBX’s HA implementation can be used as part of a greater HA solution, perhaps including real-time fail-over support.

I: So, how does FreePBX backup a server?
Me: The backup server can perform backups at any requested interval – ranging from every minute (not recommended for most scenarios) to multiple times per hour/day/week/month, etc. It then restores the backup to itself, wiping away any previous configurations, and replacing them with the latest setting from the production server.

Optionally, the backup server can be configured NOT to restore the setting locally, and act as a storage area for backing up MANY primary servers. In this configuration, the backup server keeps copies of backups handy, ready to be restored locally in the event of a failure to any of the primary servers. Please note that in this scenario, the backup server will continue to function as a backup server, even in the capacity of a surrogate to the failed production server.

I: How dose production move to the backup server?
Me: As mentioned previously, on its own – it doesn’t. The sysadmin is required to manually change the ip address of the server so that all peers can find it. This also allows the sysadmin more control of the switching over process, more notification to error’s and an incentive to ensure that the primary server doesn’t fail in the first place!

Additionally, there are services that can do the fail over automatically, but those are beyond the scope of this discussion. Apparently, these can be enabled in certain routers as well.

I: Great! This is the perfect way to backup my CDR’s!
Me: Actually, if you require real-time backups of cdr’s, your probably better off with a master-slave setup for your database (for the cdrs that is).

I: After a backup is restored, what happens to my trunks – will they automatically try to register to my provider and ‘steal’ the incoming calls from the primary server?
Me: No. FreePBX requires that you click the orange bar at the top of the screen for any changed settings to go in to affect. This can be done manually or, if you’re using other elements as part of you HA solution, programmaticly by calling/var/lib/asterisk/bin/module_admin reload. If you have traditional PSTN trunks (not VoIP), additional measures will have to be taken to connect those lines to your PBX and assure they are up and running.

I: Bougainvillea! How do I backup the backup server?!
Me: Exposed now in the GUI are many different options that can be run after a backup is complete. For example, copy the backup to an ftp server, ssh the backup to another host, or even have it emailed to you.

I: Doesn’t the ability to pull a backup off a primary server pose a security risk?
Me: We have gone to great lengths to ensure that your phone system remains safe and secure throughout this process. The backups are all executed over ssh and encrypted with the public key.

I: Public keys rock! (Uh, What are public keys?)
Me: Public/private keys are a method to encrypt data sent over insecure connections – easily considered one of the securest method in the world. See here for more info.

I: Right, I knew that! But just to make sure, can you ‘remind’ me how to set up ssh keys?
Me: That’s probably something better left for the wiki/forums, but here is a very, very, very quick primer (designed for Cent OS systems, assuming asterisk is running as Linux user asterisk):

sudo -u asterisk ssh-keygen
hit [enter]
hit [enter]
hit [enter]

Then copy the public key to the primary server:
sudo -u asterisk ssh-copy-id -i /var/lib/asterisk/.ssh/id_rsa.pub root@<primary server ip or hostname>
Your output should look something like this:

[root@localhost /]# sudo -u asterisk ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/var/lib/asterisk/.ssh/id_rsa):
Created directory '/var/lib/asterisk/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /var/lib/asterisk/.ssh/id_rsa.
Your public key has been saved in /var/lib/asterisk/.ssh/id_rsa.pub.
The key fingerprint is:
ae:2d:fd:b7:19:d3:e8:34:8a:a9:7d:76:1c:71:c4:a8 asterisk@localhost.localdomain

[root@localhost /]# sudo -u asterisk ssh-copy-id -i /var/lib/asterisk/.ssh/id_rsa.pub  root@myserver.example.com

The authenticity of host 'myserver.example.com (21.158.66.3)' can't be established.
RSA key fingerprint is 8e:ae:6a:49:bb:1b:1b:91:3f:02:4f:65:ab:e7:5e:6b.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'myserver.example.com,21.158.66.3' (RSA) to the list of known hosts.
root@myserver.example.com's password:
Now try logging into the machine, with "ssh 'root@myserver.example.com'", and check in:

  .ssh/authorized_keys

to make sure we haven't added extra keys that you weren't expecting.
[root@localhost /]#

I: Duh! Now, what do I need to do in the backup module?
Me: Under Remote Backup Options, put in the hostname or IP address of the primary server, the user name (probably root), and the private ssh key (if you followed the steps above, that should be: /var/lib/asterisk/.ssh/id_rsa). To restore the backup immediately, check “Restore to this server”.

I: Great, I’m all set. One last thing – why don’t I see these options in my backup module?
Me: These options were included starting with FreePBX 2.8, currently in beta. Feel free to start beta testing 2.8! Have a look here for more info.

I: Thank you so much for sharing your thoughts with me. Is there anything else you would like to add?
Me: Yes. As of last week there were some issues threatening the continuity of Custom Contexts as of FreePBX 2.8. Congratulation and a tip of the hat to all those that step up to contribute and help resolve the issue!
Moshe Brevda

Related posts:

1. FreePBX 2.8 out the Door and 2.9 Coming Strong
2. FreePBX 2.10 plans – what we are thinking
3. FaxPro Module

We started out highlighting the All New Directory which has panned out quite nicely. We still need to get some better recordings made up to polish off the default recordings but we are very much looking for your feedback on what’s there so far. Also, don’t miss the tie-in with the 2.8 IVR which let’s you enable direct dialing to Directory members in addition to or in place of the dial-by-name functionality.

I showed some Sneak Previews of some of the changes including several visual improvements such as the double cascading destination selections and the new Outbound Routes and Trunks Dial Rules GUI boxes. However, as excitement built up for this release so did the additional contributions, bug fixes and various other great ideas that have made this another blockbuster release! As of this blog, there are 223 closed tickets against the milestone so far, of which about 1/3 of those are new Feature Requests, big and small!

For those of you who followed the efforts of Kenn10 and the Custom Context Efforts, it looks like that was a success so I will be coordinating with Kenn10 to get that effort under way as well!

Since there are several changes in some of the critical core components of the dialplan, I’m approaching this beta more cautiously then usual. We could really use another wave of testing and new testers before I add the 2.8 Version Upgrade module to the 2.7 repository. Your help in both flushing out any issues or giving us other feedback about things you like (or dislike) would be very welcome! (For instance – check out the Accordion effect on the Left Module navigation bar – do we keep that, or put it back the way it was, or other suggestions?)

With this beta2 release we are more-or-less freezing new features on 2.8. There is a small handful of changes that we plan on rolling in and did not want to hold up beta2, but beyond these, we will be pushing most new feature requests out until we get 2.8 finalized.

There are two options to install or upgrade to 2.8 and help us test. If you want to stick with the GUI only, you can manually download the 2.8 Upgrade Module onto your existing FreePBX install and then upgrade though the Module Admin GUI.

You can get the Upgrade module here:

2.8 Version Upgrade Module

which is not yet available through the online repository until we get a little more testing done.

Alternatively, you can download the 2.8.0beta2 tarball and use the traditional install_amp installation/upgrade option, instructions can be found on the Upgrade Instructions page.

Which ever route you take, please give us feedback either here, though the ticket system or in the forums to help us drive this release to a final version!

Philippe - On behalf of the FreePBX Team

Related posts:

1. Hello from the FreePBX v3 coders!
2. Heavy Queue Usage in FreePBX
3. FreePBX 2.8 out the Door and 2.9 Coming Strong

The current Dial-by-Name directory achieves some basic goals but has always left a lot to be desired. In a lot of use cases it was plagued with issues that made it less than desirable and in my opinion often not viable.

If all your users had voice mail boxes, and all your users were on the same system, and none of your users were reachable via Queues, Ring Groups, or Custom Extensions, and you didn’t need to exclude any voice mail user from the list, and you’re happy with the default prompts, and [your own specific needs here] – then it was great to have around. For the rest of us, read on…

The FreePBX development team, in conjunction with Schmooze Com are proud to announce the all-new Directory Module. We have aimed to fix just about every thing that was wrong with the old directory – and then some. Some of the features that we are really excited about include:

1. Add/Remove just about anything anyone/thing that you can spell
2. Include users from other systems (by setting a custom user)
3. Multiple directories
4. Multiple entries (for different spelling/tags)
5. Include all users or just some

There are other features as well, but we wouldn’t want to spoil the surprise! Nevertheless, here is a screen shot of the new Directory (spoiler alert ):

If your running the 2.8 beta (in a beta environment of course), you can install this Directory module from the Module Admin. If you aren’t actively testing the 2.8 beta, what are you waiting for? Install it now and start checking out all the 2.8 goodness, including new tooltips, reworked outbound routing, and a really cool new feature that I will leave to you to find (hint). Oh, and don’t forget to look back here next week for the answer.

Of course, should your extensive test show any abnormalities in the Directory module feel free to file a bug.

One more thing. Some of you have been running the Custom Context module for a while. Save for some quirks, the module has been pretty stable. Until today. With the advent of FreePBX 2.8, Custom Context is pretty much End of Life.

But … it doesn’t have to be. A group of concerned community members have set out to bring the Custom Context module up to date so that you can continue with your context quirkiness. They need your help. Please take a momentto read the details and help out in every way you can. Because Open Source is really for You.

p.s. Just a quick heads up: Some of you may have known me by my forum handle lazytt. As of today, I’ll be mbrevda in both the forums and on irc.

Moshe Brevda - on behalf of the FreePBX Team!

Related posts:

1. FreePBX 2.8 beta2
2. v3, 2.8 and Custom Contexts
3. Sneak Preview of 2.8

v3 ISO

The v3 code is in pretty good shape as Darren pointed out in his blog last week. There are a handful of bugs that are being worked but what’s a few bugs… and there is an upgrade capability in v3 to update the code, a precursor to its future “Module Admin” capability. For now the biggest delay is simply getting the ISO processes built so we can get some ISOs out to you.

Since v3 will run both Asterisk and FreeSWITCH we will have two ISOs initially, at least until we can get fancy to allow Asterisk or FreeSWITCH to be chosen during ISO install time. We seem to be in good shape on the Asterisk front. Bryan (GameGamer43) with Schmoozecom.com has offered to leverage their ISO process used for their robust commercial products and put together a CentOS 5 based ISO since they have all the required Asterisk RPMs build and readily available to generate one.

We are a little lacking on the FreeSWITCH front though. No one has stepped up to offer help in generating the FreeSWITCH RPM for the ISO. Talking with the great folks over in “FreeSWITCH Land” they do have a spec file that should build the required RPMs but we are looking for someone who is willing to do that so that we can get them over to Bryan to spin up the FreeSWITCH version of the v3 ISO. If you would like to help move things along, please let us know or even better, send us the RPMs!. (PM me if this is something you would be willing to help with!) We’ll get it to the FreeSWITCH team as well so that they can make it available to anyone.

2.8 Progress

The 2.8 version has been moving along quite nicely and I’m not too far off from making it available to a larger audience. We originally had it pegged for the middle of May but just moved it into June to deal with the need to balance resources between v3 and 2.8, and get the Company Directory module out and tested which has been moving along but not yet finished.

No Custom-Context in 2.8

The early beta testing drew attention to the fact that one of the popular third party modules, Custom Context, will no longer function due to changes we made in the outbound routing section of FreePBX. I previsouly warned about this and it was confirmed with the beta testing of 2.8. This has resulted in quite a few threads being spurred both in our forums as well as those of other distros that package FreePBX (whether they call it FreePBX or not…).

One of our community members, kenn10, decided to take it upon himself to see if he could rally up support from the community to find someone (with my help) to make the required changes and migrations to keep Custom Context in the mix given how important many community members indicated it was in the various forum discussions. I have helped facilitate his efforts by creating a dedicated page and setting up a paypal account to facilitate the collection of needed funds in order to get the module updated so that it continues to work in 2.8 and beyond. I’ve also spent a good amount of time reviewing what is needed to move it forward. (Of course I also contacted the original author to see if they were available to do the modifications (for pay or for free) but unfortunately they indicated that they are having trouble finding time to even sleep these days!)

The reaction has been a bit luke warm to this point considering some of the strong sentiments expressed of the importance of custom context to many resellers and businesses, so kenn10 is waiting patiently to see if the required funds can be raised in order to move forward with the required work. I’m hoping that this blog post may make a few more of you who are making a living off of FreePBX come forward and help make sure that you can continue to use custom context going forward.

If this module is important to you and/or your business, please help yourself and make sure it does not go End of Life! Here is the link with more information and where you can contribute to its future.

Custom Context Bounties Page

For now it’s time to sign off, I’ll be back in another week or so with more.

Philippe – on behalf of the FreePBX Team!

Related posts:

1. FreePBX 2.8 beta2
2. Preview the all-new Directory
3. FreePBX 2.8 Almost Ready for Release Candidate!

v3 is alive and well and is still actively being developed. We are just a couple weeks out from what we are titling the “FreePBX v3 General Preview”. Consider this more mature than a beta but not quite a production release – we’re really just looking for bugs at this point – but we believe much of the core functionality needed to run a small or medium sized PBX is now there. This includes device setup, multi-user conferencing, voicemail, number management, general call routing, ring groups and basic trunk setup. FreePBX v2 has a history of having extremely reliable upgrades, so we don’t want to tarnish that reputation by releasing too early. Therefore, we’re not *quite* ready to call this production-ready, although it is getting close. We also believe the foundations are there to build features that are missing and to push out updates to folks when a new feature comes along.

Now, let’s take a closer look at what’s new.

Look & Feel
Some of you have not seen the FreePBX v3 interface since we revealed it last year and it’s changed a tremendous amount. Just to show you how much we value your feedback, we’ve completely redesigned the core skin, the colors and the navigational approach. This has resulted in a cleaner look and has made it easier to get around. The most complained about issue was the scrolling navigation bar at the top – so now, it’s gone! It’s been replaced with a rich, category-based menu bar that groups similar items together.

Take a look at some of the screen shots of the new interface:

FreePBX v3 – Device Manager: The device editor – note the new navigation bar at the top!

FreePBX v3 Screenshot – Auto Attendants: Auto Attendant Editor

FreePBX v3 Screenshot – Ring Groups: Ring Groups

FreePBX v3 Screenshot – XML Editor: FreeSWITCH XML Editor

FreePBX v3 Screenshot – Help Popups: Help Popups

FreePBX v3 Screenshot – Destinations: v3 – Destination Popups

FreePBX v3 Screenshot – Destinations Picker: Pick a destination and routing options

Development Progress
Under the hood, there is some really neat stuff in the new v3 for both Asterisk and FreeSWITCH!

Asterisk
We should first note that the Asterisk driver is now fully built and should be functional. We are really in need of a few testers here, as there are likely many bugs to be found. All general features we currently expose (listed earlier in this article) are now available for Asterisk. Please help us play with it!

For Asterisk, we’ve heavily utilized the AMI interface in Asterisk 1.6 (and higher) which allows for writing of configuration files remotely. While we haven’t yet exposed a way to configure the Asterisk host IP, you can do it within the PHP files for now. (HINT: modules/asterisk/config/asterisk.php) This feature lets you keep your web server, database and FreePBX interface on one machine (in the cloud, if you wish) and your actual Asterisk box on a completely separate machine. Each time you make a change in the FreePBX v3 interface, the FreePBX software connects via TCP to the Asterisk box’s AMI interface, requests the change be written to disk, and records it in the local FreePBX database for consistency. In this manner you could use an ALIX or other small board running Asterisk at a client site while keeping your FreePBX GUI interface in the cloud. With some reasonably minor tweaks, this opens the door to all sorts of neat enhancements – like having a change in your config automatically propagate to multiple boxes, or splitting configuration options between clients. You could also make “throw-away” style Asterisk boxes – when you need a new one, you just install Asterisk on it and point an existing FreePBX node to the box, and the config could be re-generated fully. The possibilities are somewhat limitless. You could alternatively rip out just the AMI library from FreePBX v3 for use in your own program – it’s completely independent.

The AMI-based driver also follows the same design pattern as the FreeSWITCH driver. It changes only things it actively “understands” and is intending to modify. If you’ve added dialplan sections or configuration options in other files, we don’t touch those, we just work around them. This adds some overhead and can be turned off if necessary.

FreeSWITCH
For FreeSWITCH, we’ve spent a lot of time working on the SIP Interface module. We admit it’s still a bit too confusing, but once you learn it, you’ll understand that it empowers you to operate multiple clients on the same box, giving each client their own IP/port combo to operate on and allowing for the separation of call routing between clients. This is an important foundational piece of multi-tenancy and we’ll likely do a full tutorial on how to use this feature soon.

There are a host of other enhancements and under-the-hood goodies so I’ll try and post them periodically on this site going forward.

Bugs, Chatter, Moving Forward…
We have a laundry list of bugs still in the hopper over at http://www.freepbx.org/v3/report/3. We’re hoping to finish those up this week and next. We’ll then re-build and re-post an ISO for easy installation and setup, including some demo data pre-loaded. This should let everyone easily test out (and even deploy, if you’re a bleeding-edge type of person) an install of FreePBX v3.

I’ve seen some chatter in the community related to why v3 has “taken so long” to get a first production-ready release out. We just want to remind folks of the ambitious goals with this project – not just “getting it working”. We’ve put a tremendous amount of time and energy into mapping out how we want things to grow going forward to ensure they don’t become spaghetti code. FreePBX v2 was previously much more organic, but even it took over five years to get where it is today. So v3 will likely still need some time under it’s belt before it’s as mature. In addition, we’re building our own ISO, making things skinnable, supporting multiple switching engines and providing other such features that were never a part of v2. So there’s a tremendous amount of lower-level programming happening that still has yet to be exposed. That said, we are close to a release, so just a little more patience and we’ll get you on your way.

Licensing
Last but not least, we wanted to let everyone know that we’ve changed the licensing on FreePBX v3. FreePBX v3 is now licensed MPL. This license is slightly more open then our previous selection of the CPAL license, but it removes any attribution requirements on the interface/GUI pages. The main drive for doing this was to ensure our license is inline with others out there and is easily recognizable and understood. MPL is a much more popular license, although we may also dual-license FreePBX v3 down the road if we get enough requests for alternative licenses.

Join Us!
We think we’re off to a great start – but we’re looking for more help. If you think you can participate in any of the following areas:

- Programming PHP (any skill level)
- Testing Asterisk / FreeSWITCH installs
- Building an ISO
- Setting up automated builds
- Building CSS-based skins (and general graphics work)
- Verifying language translations
- Writing documentation

or would like to just generally join in with our work on v3, please visit us at:

#freepbx-dev (on irc.freenode.net)

or drop me a line at

d@d-man.org

Special Thanks
The two other largest contributors to the project, by far, are Michael Phillips and Karl Anderson. I want to take the opportunity to thank these two individuals for their fantastic work and contribution to making v3 a reality.

A special mention also goes to our quiet code reviewer Dale Hege (fdhege). While he idly sits in the channel, if we ever check anything in that’s broken, he politely reminds us that he’s watching by submitting a patch almost instantly.

In Closing…
I look forward to getting the next generation of FreePBX out there to the world as quickly as possible – and we’re closer to our first release then ever before!

Sincerely,
Darren Schreiber

Related posts:

1. FreePBX 2.7 Is Final
2. v3, 2.8 and Custom Contexts
3. FreePBX 2.8 out the Door and 2.9 Coming Strong

Many of you have a favorite feature request you want in the next release. Sometimes it may come complete with a fully functioning patch sitting in the tracker and it can be very frustrating to you when we decide it is not going to go in the release. “Why won’t you just put it in, it’s just a few lines of code and it’s all right there…” is something I’ve encountered on more than one occasion. It may appear to be simple and sometimes things are, but more often then not they are not. Unfortunately when looking at your own feature you may not always see the subtle things it may break, and often we don’t see them right away either but experience has taught us that they are there.

An example is the addition of the CallerID field for outbound routing that was introduced in 2.7. It was presented to us at the tail end of the 2.6 release cycle by a very knowledgeable community member who said “look, if you simply modify the javascript validation that restricts the use of “/” in dialpatterns for outbound routes, we can add the ability to support outbound routing by extension with the use of the CallerID field.” This sounded harmless enough that one of the developers decided to checkin the code even though we were in feature freeze and close to release. Well one of the privileges / curses of being the project leader is that I get to be the one who says “that has to go, it’s too late to add features so put it in the next release.” Something that is never appreciated. None the less I took it out and moved it into 2.7 where it would have ample time to be tested and run through proper beta cycles.

Needless to say, small changes can have big consequences, especially when they are sitting in a critical call flow path. The first issue that came up and was included in the original checkin was the fact that we don’t even know the true “CID” of the extension until Macro(user-callerid) is executed which doesn’t happen until you are in the route. Well that’s just a minor change, we’ll just move that instruction out of the route and in the outbound-allroutes context. Sure enough that does the trick and all looks great, or does it? Eventually someone comes along with a route that has multiple trunks and you start scratching your head wondering how a call is completing on a trunk that is not part of your route?!? Oops … the CID is changed by Macro(outbound-callerid) so if the trunk falls through to another trunk, “everything has changed.” Well that’s an easy enough fix once again (after many hours of scratching your head..), We’ll just reset the CID each time we exit one of the Macro(dialout-trunk) or equivalents. Now we’re getting somewhere, it all seems to work, right? So far, so good but that’s not to say that everything else that used to work is still working.

Our first casualty comes in, the popular third party module Custom Contexts is broken. This is not one of our modules so who cares, right? Isn’t that why it is not a core module and not supported by the core team? Well technically that’s true however it is not in our interest to break other things that worked and FreePBX has always tried hard to not break compatibility and things that used to work. So after spending yet more time thinking about the failure mode and what we could do differently out comes another change and this time we are feeling pretty good about “that small change to the javascript validation allowing the “/” character” finally being put to rest. Then comes the day before my trip to Maui and in comes the next report, the AMPBADNUMBER=false configuration that allows “Early Dial” configured phones to work properly has been broken by our nifty little fix of moving Macro(user-callerid) into outbound-allroutes. So once again off to spend more time thinking about and testing various alternatives to resolve the newest bug without knocking down the rest of the card castle… For now, once again we think its finally licked, at least until the next issue gets presented. (If that happens in the next couple weeks though, you can rest assured that I’ll let the power of open source solve the problem in my absence because despite how much I may enjoy working on FreePBX, it’s not going to happen in Maui!)

I hope this digression helps to understand that there is often much more than meets the eyes when thinking about new features and capabilities for FreePBX. When you have an installed base counted in the hundreds of thousands you are going to find people doing all sorts of things that you haven’t anticipated. We try to take this into account when considering new feature development. We look at many other factors as well. Who’s interested in doing the feature? How popular is the request? Are there other ways of doing certain things today that may make one feature less urgent then another one? What do we anticipate the consequence and required support to be? Is the author of a requested feature going to be around/willing to maintain the new code and be responsive to issues when they come up? Is the feature important enough that a customer is willing to pay the true anticipated cost of implementing and future support of that feature? (Remember the javascript change above; imagine the reaction if a customer had made such a request and were told it would cost them $1000, which would have been a bargain when considering the time it has taken so far…).

So … next time you are wondering why that small feature of yours may still be outstanding, or why a knowledgeable developer may have quoted you what sounded like an exaggerated sum for something that seemed easy and small, I hope you can appreciate the job and challenge we have when evaluating such requests and considering what is in or out of a release.

For now, I’m signing off and thinking about beaches and sunshine….I’ll be back in a couple weeks!

Philippe – On behalf of the FreePBX Team

Related posts:

1. Sneak Preview of 2.8
2. FreePBX 2.8 out the Door and 2.9 Coming Strong
3. FreePBX 2.8 beta2

So what’s so exciting that I had to go blogging about it just a week after announcing 2.8 plans? If you spend much time in FreePBX you probably become skilled at navigating land mines! (You know, those annoying tooltips which are scattered around the page to help all those newbies but popup instantly the minute you get your cursor within detonation range!)Seriously though, this has annoyed me for years especially knowing that there was surely 2-3 lines of magic that could make it much more usable. Well kudos to Moshe again (lazytt) with Schmoozecom.com for solving the problem after I put the bug in his ear. Sure enough a very minor change to the CSS file, and depending on how you count, one line of jquery magic and 5.5 years of frustration solved in a puff of smoke! Here’s the secret sauce:

  $("a.info").hover(function(){
    var pos = $(this).offset();
    var left = (200 - pos.left)+"px";
    $(this).find("span").css("left",left).stop(true, true).delay(500).animate({opacity: "show"}, 750);
    }, function() {$(this).find("span").stop(true, true).animate({opacity: "hide"}, "fast");
});

Between that snippet of code and a few changed lines in the CSS file, we get this:

So what’s different about that tooltip other than looking a heck of a lot nicer? Well the code snippet does the magic but for most of you it’s probably greek, so here’s what it does… If you move the mouse over a label with tooltip, you will have a 1/2 second grace period before the land mine goes off. Once that time has passed though it doesn’t explode open like before, it fades in over a 3/4 second period and as soon as the cursor is moved from the target, it quickly fades away. The end result, you can move the cursor freely across the screen without being bombarded by exploding tooltips!

That’s not the only magic Moshe has been up to. In my last blog I commented on the cascading select boxes that would make those long cluttered destination targets a thing of the past. It took a few more lines of jquery and some other code changes but the results are spectacular! A picture of the new IVR layout tells the whole story, and these cascading select boxes now replace all modules that have a “Destination if no Answer” style selection. Here’ s the new look:

Now imagine that screen with a dozen choices compared to the old look! (And behind the scene, we’ve also increased the server side rendering performance of such multiple destination options significantly!)

Moving on to Outbound Routes and Trunks. While working on the internal plumbing I decided to get rid of those dialruletextareas in favor of a GUI that might make it more intuitive and less error prone. So out goes the textarea and in comes something that looks like this:

Let me translate this for those used to the old format. Recall outbound routes can match on a pattern including an optional dial prefix, and send the resulting number (less the prefix) to the trunks. In addition, FreePBX 2.7 added the ability to match on the CID portion as well. The results might look like the following, these rules allow access to this route by dialing 9 first (like those traditional inflexible PBXs that we love running circles around):

9|011.
9|1NXXNXXXXXX
9|411
9|311
9|NXXXXXX

This example allows for 7 and 11 digit NPA dialing, as well as international, 311 and 411 access using a prefix of 9. It drops the 9 and sends the resulting number to the trunks.

You can see where a CallerID (typically an extension number or pattern matching a group of extensions) can be added as part of the match. There is also an optional prepend field not previously available. These digits are prepended to the resulting match prior to going to the trunks. This new feature can solve some powerful problems. One example, providing 7 digit dialing to extensions that are remote. For example, your main office is in Seattle where 7 digit dialing results in 206 being prepended. However you have branches with remote extensions in Chicago and you want their 7 digit dialing to prepend a 312. I’ll leave it as an exercise to the readers to see how to achieve this and for those coming to our upcoming OTTS Training at Digium, I’ll give you the answer if you have not figured it out.

The trunk page has been modified with a similar GUI interface. It has also added the ability to include the “+” as a valid digit which was previously not possible. You light-weight appliance users will also appreciate the elimination of the underlying fixlocalprefix AGI script in place of native dialplan used to apply these rules.

Enough blogging, it’s time for you to get your hands dirty and help us make this a reality! You can download the 2.8.0beta1 tarball and see all this for yourselves. If tarballs intimidate you (or, what’s a tarball comes to mind…) thendownload the version upgrade module to your desktop, then upload it in Module Admin through the GUI and get yourself on the bleeding edge without touching the command line! (You won’t find the upgrade module in the Online Repositoryyet, you will have to install it this way). There’s still more feature development to come on 2.8 so there will be at least another beta release before we do a feature freeze. If you don’t see all the advertised features there like the great Company Directory that Schmoozecom.com is working on (yup … Moshe again) that is why.

For now, have fun and thanks for getting involved!

Philippe – on behalf of the FreePBX team!

Related posts:

1. Preview the all-new Directory

OTTS FreePBX Training

If you’re not familiar with our training program you can get details on the OTTS training link on this site. It’s the only officially sponsored FreePBX training that is hands on and heavily lab oriented. The next class is scheduled for April 27-29 at Digium’s Headquarters so if you are thinking of coming, get registered now. If you are a previous attendee to our training series (all you Leap Frogs out there) and are interested in coming for a refresher with all that has happened in the last few releases, contact us for a repeat customer discount! This should be an exciting class and as always when at Digium you have the opportunity to meet some of the great minds behind Asterisk, which is almost as good as meeting with us! We’ll also try to have a v3 system configured and available for show & tell if the timing works out!

v3 Happenings

While on the subject of v3 let me brief you on what is going on. In the last couple of months the v3 team has done an amazing job stabilizing the release with heavy work on both the Asterisk and FreeSWITCH engines! The new platform promises to be a fantastic foundation to launch the next generation of FreePBX and we are super excited to what the future potential holds!. The bulk of the work over the last year has been an intense journey exploring the different dimensions involved in redesigning a new platform to launch a next generation FreePBX product. The team is working hard to stabilize the current capabilities so that we can deliver a general preview release in the next weeks, complete with ISO, so that we can start to get some heavy involvement of the broader community. We then have some ideas of ways to have a little fun in getting developers to come pouring in and helping to rapidly accelerate v3 with new modules and features in a similar way to what we saw happen in the FreePBX 2.0-2.3 era, a time of rapid expansion… We’ll follow with another blog and more details on what is going on with v3 soon!

v2 Happenings

The mainstream v2 bread and butter is doing anything but standing still despite the rapid and intense work going on with v3! Version 2.7, released less than two weeks ago, made some great contributions but the momentum has doneanything but slowed down! I’ll digress briefly to make a comment on the general shift in release philosophy with v2. In the past we targeted releases every 6-9 months which resulted in significant change when the releases came out. Despite our stellar track record of near perfect migrations (all the way back to AMP 1.0!), system admins still get a little nervous when they see significant change and thus hesitate to dive in (as they should, though you never heard that from me!). With v2′s level of maturity being over 5 years old, we are shifting to more frequent and smaller releases. This helps us realize a few goals. We can continue to limit updates within a release to bug fixes only which makes most of you more comfortable accepting updates knowing we are not introducing new features. At the same time, we can get new capabilities delivered to you quicker with the introduction of new releases. Lastly, the new releases can be smaller in scope which allows us to focus into the changes required for the new features being introduced and thus continue our un-matched record in increased stability with each new version!

So back to 2.8 and what’s going on there! You can have a look at the 2.8 Milestone to keep track on it’s progress and focus. This release is going to be a mix of internal plumbing upgrades and cool new features (as always!). I won’t dwell on the internal changes, it’s one of those necessary areas that us engineers thrive on but usually go un-noticed by most users who don’t quite understand why it’s needed and what it brings in potential. On the feature front there are several areas being reviewed and worked on. In addition to some great new capabilities introduced for Outbound Routes, we are looking at a scattering of smaller features on several fronts.

One small and one big feature that I’m really excited about is somethings that Moshe (lazytt) over at Schmoozecom.com is actively developing for 2.8. On the small side, we’ll see all those cluttered destinations made up of rows of select boxes with radio buttons give way to a cascading pair of select boxes, the first being the module and the second being the destination within that module, the existing select to the right of each radio button. This will do wonders to cleanup modules like IVR, Time Conditions, Day Night and even the Extension page when the Fax Detection option is enabled! On the big side, Schmooze is developing a long overdue real company directory module that will finally enable the creation of multiple company directories that can include/exclude existing extensions on the system as well as custom entries to allow for maximum flexibility. Not only will these be available as a destination to the IVR or any other module (to replace the existing directory which is based off of the voicemail.conf file), but the same directories will be available to control direct extension dialing solving many common challenges people face wanting to direct dial a Ring Group, Conference bridge, Queue, etc. We also look forward to a much cleaner user experience when calling into the company directory then today’s less then optimal implementation.

I could go on but this blog is getting a bit long. For now I encourage you to poke around if you haven’t already and get a feel for all of the excitement and energy going into this project! It’s all possible because of the great chemistry created by Open Source so come and get involved if you have been just watching from the side lines! (If you are not a developer, there are plenty of other areas from testing to documentation on the site to bribing other developers to build features that are important to you!).

Philippe – on behalf of the FreePBX Team!

Related posts:

1. Sneak Preview of 2.8
2. FreePBX 2.8 out the Door and 2.9 Coming Strong
3. FreePBX 2.7 Is Final

The biggest changes in 2.7 were around the Fax handling and the new FAX module which provides a much more intuitive GUI for dealing with FAXes with both shared voice/FAX DIDs that require detection or dedicated FAX DIDs. It also introduced support for FAX For Asterisk (FFA) in addition to the legacy support for spanddsp based FAX reception. You can get more details about the changes in the 2.7.0 Beta1 Release announcement.

Outside of FAX, you can see a more comprehensive list of features and bugs addressed as well as an overall summary in the 2.7 Milestone along with direct links and stats to all 142 closed Feature Request and Bug tickets addressed during this run!

A few highlights include some great enhancements to Queues and Backup, as well as additional abilities in Outbound Routes, Follow Me, Ring Groups, Trunks and Conferences to name just a few. If you are particularly interested in Queuesyou may want to have a look at the recent Heavy Queue Usage in FreePBX Technical Corner article we just put out which talks about various advanced capabilities in the Queue module that may be of interest.

With 2.7 now final it means that FreePBX 2.5 is now off support so if you are still running 2.5 or older versions, you may want to seriously think about an upgrade plan. The project’s support policy is to support the current and previous major releases.

We have started to compile up a list of what we want to target for our next v2 release and you can see the plans as they evolve in the 2.8 Milestone. More to come on that as we better define it. We will also be working hard to get our v3 General Preview Release Candidate out with support for both Asterisk and FreeSWITCH. It has been available as a Developer release since last August and is now getting to the point where we will be able to get more user feedback to really shape its development going forward!

For now go have fun with all the great new stuff we are getting out to all of you and we will be back shortly with more news to come!

Philippe – On behalf of the FreePBX Team!

No related posts.

Throughout the article we will refer to FreePBX Queue Agents as members to be consistent with the Asterisk naming convention. FreePBX commonly refers to any queue member as a Queue Agent which is someone who answers calls destined for the queue and does not specifically refer to the Asterisk agents.conf agents.

Before going into the solutions we will frame the problem and describe why FreePBX runs into issues that other Asterisk configurations may not. The root cause of the issues described in this article hinge on two fundamentals that are employed by FreePBX. First of all, FreePBX abstracts extensions from the device(s) they are associated with. You can read more about this in a past article FreePBX Devices and Users Under the Hood. As a result, queue members are not dialed by calling the device directly but instead are sent down the Asterisk dialplan through the Local channel. This allows the extension to be called in the same way that they would be dialed by another user on the system. It also enables all possible features such as call forwarding, follow-me, etc. It further allows arbitrary external phone numbers to be treated as members in addition to other creative uses. This leads to the second fundamental, all internal calls in FreePBX employ the use of the dialparties.agi AGI script along with other AGI scripts when making calls. As a result, calling a queue member is a “heavy” operation (as is calling any extension on the system). In the case of a queue, this is multiplied when employing a ringall strategy (very common) because every queue call that is dispatched ends up in simultaneous calls to every member, and thus a barrage of heavy dialplan and AGI scripts are launched, often just to find out that most of the members are currently in use and should not have their phones rung anyhow.

Aside from overloading the system when many members are present, the most common side effect of using the Localchannel when making calls is encountered when a member transfers their received call elsewhere. When this occurs in conjunction with the Asterisk queues configuration of ringinuse=no (see below), that member remains “Busy” until that transferred call is terminated. This occurs because of the nature of the Local channel. This means that the member is now free but will not receive any calls from the queue.

So what has FreePBX done to address both these common problems, as well as get around the fact that many of the desirable features of the PBX are problematic when an extension is included as part of a queue? To answer the latter question, there have been various features added to the queue module, often features that are outside of those provided by the underlying Asterisk queue application. The most important additions have included:

• Agent Restrictions
  • Call as Dialed
    Send all calls down the standard FreePBX Local channel
  • No Follow-Me or Call Forward
    Restrict calls to known extensions down a specific context which blocks all Call Forward and avoids Follow-Me configurations
  • Extensions Only
    Allow only extensions to be dialed, and send them down a special context that puts further restrictions on them. Certain safe guards are removed from the queue calls that normally help block calls from hittingmember voicemails since the special context handles that. As a result, this mode is also safe for direct device dialing.
• Skip Busy Agent
  • No
    Occupied members will have new queue calls presented to them.
  • Yes
    Occupied members will be treated as if they did not have call waiting. The calls will be dispatched to them (resulting in system load) but the calls will be blocked within dialparties.agi (or macro-dial-one if using this new capability described below.)
  • Yes + (ringinuse=no)
    Same situation as above with the addition of the queues.conf setting of ringinuse=no. With no patches and standard Local channel members, this will result in calls not being dispatched to busy members from this queue including those who subsequently transferred their calls elsewhere (an undesirable side effect). With the patch below installed, this side effect goes away.
  • Queue Calls Only (ringinuse=no)
    Without the patch below, this will result in the queue not sending calls to members currently on calls from this or another queue. It has the same side effects as the previous case. If there are no queue calls the call will be dispatched and if the member is on their phone with a non-queue call, their phone will still ring with this call (unless they have call waiting disabled). When the patch is introduced, this setting is functionally equivalent to the previous one.

These settings provide various levels of filtering to avoid undesirable features such as different Call Forward and Follow-Me features, or multi-line phones ringing additional queue calls when members are busy on existing calls.

Addressing the two main issues of this article, overloaded systems and members seen as busy after a call transfer takes a bit more work and often some patches to Asterisk that we have developed and submitted to the Asterisk bug tracker and available for anyone to take advantage of. We will first discuss the member who remains busy after a call transfer as the solution to that problem is connected to the system overload issue. The crux of the problem is that the queue members are viewed as Local channels, in asterisk terms, they are represented in the queues_additional.conf file as:

member=Local/2201@from-internal/n,0

or something similar. So once the queue sends a call down to that member, even if the call is subsequently transfered, the original Local channel is still busy and the queue application does not have any more information to determine the state of that member, so they remain busy and no additional calls are sent to that member if the Asterisk queue configuration ringinuse=no is set. The Asterisk team recognized the limitation in version 1.6 and introduced some additional parameters to the member assignment. They introduced the ability to associate a different device state with the queue member. They also recognized the limitation as enough of an issue that they made a rare move and added the new “feature” as a back port starting in Asterisk 1.4.25. This was a great move however the solution was incomplete and does not become complete until Asterisk 1.8 (unless enough of you complain). Adding the ability to use the state of a device is nice, but it misses the fact that the state of an extension is not solely based on a device state. It is based on the state of the “hint” associated with that extension and could include multiple devices as well as custom extension state information (such as a server side DND feature). Since all extensions in FreePBX are abstracted and use such hints to determine their state, this new ability can not be employed without patching asterisk to make their solution complete. (Ahint in Asterisk is what is used to provide status to telephone BLF buttons and implement more sophisticated dialplan, see Asterisk documentation for more information on the hint priority).

Not wanting to miss out on the this new capability which comes so close to solving the problem, we set out to “finish” what Asterisk started and submitted a patch against Asterisk 1.4 in May of 2009 that would add the “device” state” ofHINT:nnn@context as a way to associate a hint vs. a real device. If this patch is applied to your Asterisk install, and the secret “USEQUEUESTATE=yes” amportal.conf variable is set, FreePBX will generate the dialplan and configuration files to associate the extension hints with the queue members. As a result, the “member transferred call” previously discussed will now result in the member appearing available by the queue again, since their hint will no longer show busy. (In addition, it ties into other enhancements. For example, if your system employs server side DND, and you have included the 1.4 back port of DEVICE_STATE() that is common on many 1. 4 system, and set the secret FreePBX amportal.conf variable of “USEDEVSTATE=true” then your member will be seen as busy by the queue and calls will not be attempted to the them. Note, the back port of this patch has not been modified for Asterisk 1.6 and as of this writing, the Asterisk team has chosen to delay this capability until Asterisk 1.8. We feel this is a big mistake as the original “fix” introduced by Asterisk was an incomplete solution in that it completely ignored the fundamental state mechanism that Asterisk is designed around, the hint priority.)

Now back to the overloaded queue situation discussed earlier. The crux of the issue occurs when you don’t set Skip Busy Agent to Yes + (ringinuse=no) or Queue Calls Only (ringinuse=no). Doing options other than these two tells the queue to try all members regardless of whether they are on the phone or not. Without the above patch, this gets around the “member transferred call” issue but results in all members being called whether or not they are busy. The underlying dialplan still blocks the member’s phone from ringing in dialparties.agi, however the system can be loaded heavily because of the barrage of dialplan and AGI scripts being run. When the above patch is applied, you now remove that barrier resulting in a solution that addresses both issues. By setting either of these two settings in conjunction with themember hint information supplied by the patch, the queue will not overload the system with attempted calls to anymember seen as in use based on their hint information. This can take a tremendous load off the system while maintaining proper state information and avoiding in use members from receiving calls that will just be rejected bydialparties.agi. Now if the Asterisk team would recognize the limitation of their original fix and back port the “HINT:”solution to 1.4 and 1.6 we could all benefit from this ability without the need to patch Asterisk!

This new Asterisk capability in conjunction with the required patch solves the “transfer” problem and reduces the number of members being called to those who are actually available to take a call. That is often enough to solve the problem on heavily loaded systems since in most call center environments members who are not available will either have their phones set to DND or use the Dynamic Member ability of queues and logout when they should not be taking calls. However, for those members who are busy, a call is still sent down the Local channel for each member which results in heavy dialplan and the dialparties.agi script being run for each member. This may still be a problem in some environments so more extreme actions may be necessary.

If the above solutions are not adequate for some installations, or patching Asterisk is not an option, there are two new capabilities that have were introduced in FreePBX 2.7. These are designed for advanced users who are ready to thoroughly test their installations to assure that other system functions are not compromised. The first one is the ability to use device in place of extensions for queue members. The ability to represent an extension as “Annn” has existed for a few years and results in the the queue agent referencing channel Agent/nnn. This has always been an experimental ability with known limitations and no GUI support to configure the required agents.conf configuration file. Asterisk has deprecated the channel Agent in 1.4 and no longer supports it in 1.6. FreePBX 2.7 has introduced syntax that allows SIP, IAX2, DAHDI and ZAP devices to be referenced directly. This is achieved by prefacing the member number with S, X, D or Z respectively. This capability is only available for static members. When this is done the queue calls are dispatched direct to the specified device completely bypassing the FreePBX dialplan. In the past, doing this resulted in broken features such as subsequent transfers to voicemail hanging up on the caller. By setting “Agent Restrictions” to “Extensions Only” this problem is now eliminated. This results in all of the dialplan including the heavy use of dialparties.agi being avoided. It should be understood that avoiding the dialplan also means that features will also be avoided, such as an extension that is set to always record calls will not have the calls recorded unless other settings ultimately enable this.

The device specific members are limited to Static Agents and may not be desirable for this or other reasons. We have thus introduced an experimental macro that is ultimately targeted for general release in FreePBX 2.8 but accessible in 2.7 with some magic settings. This macro, macro-dial-one, serves as a replacement for macro-dial + dialparties.agi in all cases where a single extensions is being called. This is always the case when the queue is dispatching calls. We have included the macro in 2.7 in order to get early testing since we plan it to replace macro-dial + dialparties.agi for single extension dialing in 2.8. Enabling the macro has two requirements. First, you must set the magic variableUSEDIALONE=true in amportal.conf. Secondly, if running Asterisk 1.4 you must have the 1.4 back port of the functionEXTENSION_STATE() that is not officially available until 1.6. The advantage of this macro is the elimination of thedialparties.agi script which results in a forked process and relatively heavy php environments being run for eachmember that is being called. The call is still sent down the Local channel and results in a fair amount of Asterisk dialplan executing but avoids the heavy system load created by expensive process forking and php AGI scripts. More details and a copy of the func_extstate.c can be obtained in the macro-dial-one trac ticket. It should be stressed that the macro is at an alpha level. We hope people will test it and report issues or patches to address bugs as they are discovered to help prepare this for the 2.8 release. Setting USEDIALONE=true results in all single extension dialing to use this macro, not just the queue.

There have been many other enhancements included with queues and not listed here to improve the overall capabilities and flexibilities of the Queue Module as well as other articles written in this Technical Corner series about queues. For now, we hope the information presented is useful for those of you who have busy queues and are looking for ways to optimize your environment as well as those of you who are just interested in knowing more about the inner workings of FreePBX + Asterisk and what makes it all tick!

Philippe – On behalf of the FreePBX Team

Related posts:

1. FreePBX 2.7 Is Final
2. Small Changes Big Consequences
3. Hello from the FreePBX v3 coders!