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 [url=/news/2012-09-20/freepbx-extension-routing-module]Extension Routing module[/url] 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 [float=right]Route Destinations[/float]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 [float=left]Busy Trunk as Congested[/float]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!

First I should say thank you! for the new features, the old ones, and for your efforts.

It’s pointed out on the link below that we can post feature requests here.

I’d like to see full support for DUNDI configuration and possibly test buttons and add status on the dashboard.
Lastly, there is a module hanging around to configure chan_sccp, but it does not work. It does no install on 2.9 or 2.10

Keep it up!

Hi Lucorium,

That module was provided to us by a developer that basically dropped the module on our laps and then never came back. It’s pretty much in a holding state and is not even remotely supported by FreePBX. Hopefully someone will take it on and fix it up but at this time it’s hanging in the air.

Thanks for the feedback so far! On the DUNDi comments why don’t you start up a separate thread on the subject in the forums since it seems like it could use more definition. As the original author of the one DUNDi module that provides a level of support but still requires some manual setup, that would be the place to discuss it and see how much interest there really is since the main reason nothing more was ever done was because of the perceived lack of general interest in the greater population after having written that module as well as discussed it with many OTTS classes where we eventually stopped even teaching about it.

The SCCP-B module is of growing interest as more people would like to ditch Cisco Call Manager and use Asterisk. One great feature of SCCP-B is the ability to do shared extension appearances…a feature badly needed with Asterisk.

I would like to see additional development for configuring SCCP phones. The End Point Manager module currently provisions only SIP for Cisco phones.

As to DUNDI, I agree that better GUI support would be tremendously helpful. It should include fully setting up the routes, trunks, contexts, mappings, etc. Ideally, I’d like to see a module that allows for real-time DUNDI mapping where one extension could register at any of a cluster of Asterisk PBX’s and be mapped correctly.


What are you talking about/referring too. Very confused as no one said anything negative about SCCP. We don’t support it. That’s all. We do not have the resources. If you’d like to volunteer you are more than welcome

I disagree with your thoughts on sccp and (my) common sense would say that as more people move from Call Manager to Asterisk the more sccp support is needed.

Anyway, I now got my way around manual configuration, but I pulled a lot of hair in the beginning.

Trunk failover on busy is great - thanks!

It would be very useful to have a way to restrict extensions to certain trunks (a complementary feature to the route-access controls discussed above).

The common case for me is to ensure a FXS device used for faxing always (and only) uses a particular T.38-enabled SIP trunk dedicated to its use. Right now, I need to use custom contexts (not the module, I just create them myself) to add special prefix numbers. Calls are then directed to the appropriate trunk by matching outbound routes that start with those special numbers. It’s cumbersome.

This would also help multi-tenant situations where one tenant should only use specified trunks.

Tim Miller Dyck


Thanks for the feedback.

Concerning your FAX situation, it is trivial to make an outbound route dedicated to faxes only. You can put that route towards the end of your route list so that normal extensions don’t use it. Then, simply enable that route only for your FAX extension and disable the other routes for those extensions. WIth that setup, those fax devices will use only that route, where as the other extensions won’t since it will come after the normal routes whether you disabled that route or not for them. Now that route can be limited to FAX capable trunks only.

Hi Philippe,

Thanks for your advice!

Just to clarify, this approach depends on the new FreePBX Extension Routing Module (described at ) to selectively enable a specific outbound route just for the fax device (and this special route would have just the desired fax SIP trunk specified in it)?



Yes your summary is correct.

I was describing that what you want to do can be done more or less as you were requesting with the new routing module and didn’t need the requested addition of specifying trunks.

Under normal conditions, if a route matches your pattern, no routes below it will ever be tried so it would never work because it would never get to that route. When you select a specific set of routes for a specific extension, it’s as if that was all that was configured for that extension so it will hit that route. You can actually do the same thing “in reverse” without the module but using the CID field. You can have a route that matches your desired pattern for the specific extensions using the CallerID field. You would however put that route BEFORE the normal route that other extensions would use. Since that route won’t match those extensions, they will always fall through to the normal route but this will always catch the fax extension when it dials.

So … as is often the case there are multiple ways to achieve the end goal in FreePBX. For your case, it’s a lot easier and more intuitive to simply create routes that are just for the fax extensions. You can then choose to put them last knowing they will never be used by the other extensions if you designed your patterns correctly, or if you want to really be sure, you can uncheck all the other extension’s from that route which is more work but assures you don’t ‘mess up.’