More Routing and Trunking Enhancements in 2.11
Back again with a few more features being added to the Routing and Trunks category though this time targeted at 2.11. Tony told you about the Extension Routing module a week or so ago which resulted in a lot of positive feedback and happy community members who have wanted a simple solution to this problem. While we were messing around with this part of the code I thought I'd address a handful of other requests that have been outstanding in this area!
To recap Extension Routing, this was the introduction of a module available on 2.10 that allows you to restrict extensions to certain routes in a simple and easy to understand way. Tony's blog post goes into a lot more detail if you didn't get a chance to read it.
Outbound Route Destinations
The first of today's highlighted features is the addition of an optional Destination that can be chosen for an Outbound Route. This dialplan destination would be followed if all the trunks configured reported some form of CONGESTION and you wanted to do something more creative with the call then simply playing one of the messages configurable from the Route Congestion Messages module. A simple use case for this might be a custom announcement for all 900 phone numbers informing your users that these numbers are not allowed. You can route a call to any other destination you have on your system where I'm sure our user base will come up with all sorts of creative uses for this feature!
Outbound Route Recording
When we re-engineered Call Recording in 2.10 we added the ability to force a call to be recorded based on the inbound DID it came in, within Modules like Ring Groups, Queues and Conferences or though a specific call flow directive. The last loose end was forcing all calls out a specific route to be recorded, just like the setting with inbound routes. That's now been implemented in 2.11.
Trunk Fail-Over on Busy
Something that comes up repeatedly in the forums are users running into carriers that don't know how to signal properly. The carrier will send back a BUSY when they should have been sending back a CONGESTION. A BUSY is suppose to mean the far end destination you just tried does not want or can't be bothered at the moment. Given this 'proper' interpretation FreePBX does not bother to fail over to the next trunk since the message was clear, THEY ARE BUSY!, and another trunk is not going to tell you something differently! In order to get around these carrier issues, we've added a per-trunk feature so you can configure any one or multiple trunks to 'always' fail over to the next trunk if they can't get the far end ringing. This is not limited to the BUSY scenario, your carrier might be signaling a number as invalid because their switch is programmed improperly or for other reasons. When configured, this will always overflow to the next trunk or configured destination on an un-successfrul call attempt.
These new features will all require 2.11 to take advantage of and with Astricon fast approaching, I'll try to get a proper 2.11 beta tarball rolled this week so you don't have to pull these from SVN if you want to get started with them early. Of course don't let me stop you from grabbing the code now!
Speaking of Astricon, a bunch of us plan on being there this year and we'll have a booth as well so come by and say hi and see what we are up to!
For now, give us feedback on these features or other other ideas this might trigger since it's always a good time to make sure "long ignored features" show up on our radar when we are in a push to get a release finished!
Philippe on behalf of the FreePBX Team!
P.S. We haven't touched on the New Website Design in a while. We've been looking for an experienced Drupal developer to help with the implementation of the new design. This includes both the Drupal backend configuration and migration as well as Drupal Theme design for the new look we are shooting for. If you know someone you can recommend, can you please PM me with that information? We have funds to do this so it doesn't have to be free though it isn't going to be a 'huge' project either. Thanks!