Posts Tagged freepbx

FreePBX device-and-user mode, part two

In part one, I described how I reconsidered device-and-user mode in FreePBX, and did the initial changeover.  Read on to find out how I overcame a major issue with the configuration!

I have an ISDN phone line coming into my Asterisk system.  One of the indials is for our home number, the other is one I use for work.  Before I found FreePBX, I had manually worked the Asterisk dialplan to have calls made from my work phone(s) appear from the work phone number–useful not just for Caller-ID, but also required for the long-distance provider I use to bill calls for work.  With FreePBX I was able to use a custom context to pre-select a route that dialled the provider override prefix to send the calls through the other provider, but it was a bit of a hack using hand-written dialplan code and a bit of luck.

Before I changed to device-and-user, I naively assumed that FreePBX would allow a user to be associated with a context in the same way a device/extension can be.  This is not the case, and the context of the device is still used for routing.  This meant that I could not use a device for either work or personal calls without having to log onto FreePBX and change the device context (logging on as the work user was not enough).  I was back to square one…

I did a little research.  Firstly, I rediscovered how I was making the existing routing work.  The ISDN interface I use (driven by chan_capi in Asterisk) simply uses the outgoing caller-id of the call to select from available MSNs[1].  So I had one route that had the “normal” MSN set as the outbound caller-id, another route with the “work” MSN (plus the rewrites to add the long-distance override code at the front), and a custom context for the work devices that made only the route with the work MSN available.

Looking more closely at the user definition page, I saw that there is an “Outgoing Caller-ID” field.  By using this field, I was able to do away with the separate route and the custom context and set the work MSN there instead.  This gives me just what I need: a way to control my outbound MSN on a per-user basis!  This got me half-way there, as I still needed a way to set the long-distance override codes for work calls.  A bit more research turned up a predialling macro hook that the FreePBX folks made available.  With a bit of code to test the caller-id and the number dialled (the long distance company doesn’t handle free calls, for instance) I get just what I need.

Here’s the macro hook (this is added to extensions_custom.conf):

exten => s,1,NoOp(Trunk is ${OUT_${DIAL_TRUNK}}, CallerID ${CALLERID(num)} calling ${OUTNUM} )
exten => s,n,GotoIf($["${CALLERID(num)}" != "xxxxxxxxx"]?endit)
exten => s,n,GotoIf($["${OUT_${DIAL_TRUNK}:4:11}" != "CAPI/contr1"]?endit)
exten => s,n,GotoIf($["${OUTNUM}:0:4}" = "1800"]?endit)
exten => s,n,Set(OUTNUM=1xxx${OUTNUM})
exten => s,n(endit),MacroExit()

So I’m now a happy device-and-user user!

[1] Actually I don’t know if that’s chan_capi doing it for me or whether it’s just the way the ISDN network works.

Tags: , , , ,

Revisiting device-and-user mode in FreePBX

Buoyed by the success of a colleague I introduced to Asterisk and FreePBX a little while ago, I decided to have another look at the extension configuration mode I use on our system.

Check this post for a recap of the FreePBX configuration modes and my first thoughts.

Last time I looked at this I thought there were some problems with the way it was implemented that meant it didn’t work for my installation, so I ended up hacking together a mess of fake extensions, ring groups and queues that more-or-less reimplemented the good parts of device-and-user mode and still letting me use things from extensions mode.  Doing this however meant that FreePBX always complained about what it called “invalid destinations”, and I had to use some custom logic for doing something simple like a common voicemail access number.

What won me over to device-and-user mode again though was the ability to log a device on and off from a number.  I have a couple of Nokia handsets that have SIP clients now, and it’s handy to just have one device that all my work calls (for example) arrive on.  After-hours though, I didn’t want that device to still be tied up to the work line; it made more sense to be able to use that device for home calls.  To do that with extensions mode and my ring-group hack would mean reprogramming the ring-group (and one other change, which I’ll talk about later) when I wanted to switch over.  Presumably I could write some script or AGI logic that I could tie to a feature code in FreePBX, but I’d simply be making more custom modifications for little real gain.

In the end, I realised that the main thing keeping me in extensions mode–the ability to call a device by it’s “extension” number regardless of who’s logged on to it–wasn’t something I used often enough to warrant all the work I’d have to do to make extensions mode do what I needed.  With that in mind, I edited amportal.conf and made the all-important change:


I had to reload the FreePBX admin page a couple of times, but eventually the “Extensions” tab changed into two tabs, “Devices” and “Users”.  True to the description of extension and device-and-user modes given in the FreePBX doco, the Devices and Users tabs had the same number of entries.  All I needed to do was delete the users that were no longer required (i.e. almost all of them) and the devices that belonged to the voicemail extensions from my original setup.  I then ran through each of the device definitions and correctly assigned them as either “Fixed” (statically allocated to a user) or “Ad-Hoc” (able to be logged on to a user).

This was the point at which I worked out a solution to my original dial-a-device-directly problem.  I realised that the majority of times I need that functionality is when testing.  So, for those devices that I use for testing, I left the user definition in place and made it the “default” user for that device.  This means that when I log out of the real user from that device it is reachable by the default user number, and I can dial it directly for testing.  The other use for direct-connection to a device, the intercom, requires a separate SIP endpoint anyway (due to the Cisco phones not adhering to the SIP command for remote off-hook) so I need to keep those as separate users too.

I’m quite happy with how it’s turned out–at least, I was once I’d overcome the showstopper I found!  Read about that in part two.

Tags: , , , , ,

FreePBX modes

When I first set up FreePBX, I was frustrated by the inability to create a voicemail user independently of an extension.  It looked to me like an office system, where each handset was associated with an individual and had its own voicemail.  In the end I created a few extensions that were not associated with handsets and used them as the voicemail boxes (I disabled voicemail on all other extensions) and wrote a custom dialplan entry to work out which voicemail box was associated with the “usual” user of each handset.  Works fine, even if I have to check each upgrade of FreePBX doesn’t knock out my custom dialplan stuff.

Recently though, I found that FreePBX does indeed have an alternate programming method that matches up with my original intended use.  The default method is called “Extensions” mode, while the different method is called “Device-and-User”.  The extensions mode, in effect, creates a user for every device defined, and calls it an extension.  The device-and-user mode however allows you to configure each separately.  Your device configurations are simply end-points for your handsets (SIP definitions for example) and users are the entities you actually want to reach (i.e. people).

A device can be either “Fixed”, where it is always associated with a particular user, or it can be “Ad-hoc”.  An ad-hoc device allows a user to log on to the device and receive their calls at that device.  A user can be logged on to multiple devices at once, or even a mixture of fixed and ad-hoc devices.

I was really excited by this, as it seemed that I could replace everything I had set up with my extra extensions and associated Ring Groups by just switching to device-and-user.  There is a little snag though — even though devices still have to have a numeric name that looks just like an extension, it is not available to the dialplan in its own right.  If I have configured my ATA-attached cordless phone as device 852, I cannot dial 852 and make it ring.  I can only dial whatever user number the device is associated with, which in turn means that if no-one is logged-in to an ad-hoc device there is no way to make it ring.  Also, a device can only be associated with one user at a time.

I have auto-answer SIP presences on all the handsets that support it, which I use as a two-way intercom system.  This supplements FreePBX’s Paging facility which I use for broadcast, one-way announcements to all (such as “dinner is on the table!).  I couldn’t switch to device-and-user mode completely, as I would lose the ability to selectively dial devices such as the intercom lines that would not be associated with a user (or would need to be associated with more than one user to support both paging and intercom).

So for now I’m sticking with what I’ve got.  I like device-and-user, but by not making the device’s number addressable in the dialplan they’re eliminating a lot of flexibility and possible functionality.  When we moved into our current home I ripped out much of the builder’s phone wiring and replaced it because I didn’t want all my phones in parallel… that’s what device-and-user feels like right now: everything in parallel.  I’ll keep an eye on it though…

Tags: , ,

LDAP Caller ID again!

After a hiatus that has lasted since I first cut the phone system over to Trixbox (probably a year or more), LDAP caller-ID name lookup is working again on my Asterisk system!  A lot easier to maintain than the original version I implemented ages ago, too.  A bit of PHP code does the trick!

I’m using FreePBX for keeping my Asterisk box configured, and it’s working great — but there are a couple of tricks that I just haven’t quite been able to work around.  You see, FreePBX applies a few assumptions that work fine in a small office environment (like voicemail-per-extension) but don’t map to home use (one voicemail for the household).  The biggest aspect of FreePBX is that it maintains the dialplan in a set of files all of its own making — you can extend it using “custom applications” (basically a reference to a dialplan file of your own creation), but I’d be concerned about an upgrade trenching custom dialplan files…

My original LDAP caller-id lookup module implemented a new dialplan app (something like  LDAPCallerName).  I inserted it into the dialplan at the relevant place, et voila, name lookup.  But even if I could port my old code to the later revisions of Asterisk, or use the community LDAP lookup module (which was written just a little while after I wrote mine), how do I add the lookup into the dialplan?

FreePBX has a module called “Caller Name Lookup Sources”.  Out of the box, it has the types “Internal”, “ENUM”, “HTTP”, and “MySQL” (“SugarCRM” is listed as well, which I figured would be tied into the SugarCRM system that’s provided with Trixbox, but when you select it you get “not yet implemented”).  MySQL doesn’t help me, as I don’t want to transfer data out of LDAP into some other store.  ENUM is a name lookup system based on DNS, and having seen a lot of work on LDAP-backed DNS servers I thought this might be interesting… until I realised that I’d likely have to spend a heap of effort adding the DNS attributes and object types to my existing LDAP data (assuming that I could use the data in its existing structure at all).

I had disregarded the HTTP method as overly clumsy — on a single host, contacting the HTTP server to run a script to get data from the LDAP server just seemed too much overhead to me.  After I had a think about the available options though, it made a lot of sense — and half-an-hour after I decided to do it, I had a working prototype (and I consider myself very much a PHP newbie).  My script has a few nice features that tie in with the way the Caller Name Lookup module works in FreePBX, including the thing that I found was missing in the Asterisk LDAP module — the ability to drop leading zeroes from the number to be looked up, allowing you to have numbers stored in your database in international format.

Next to come will be the directory lookup CMXML app, that will allow the “External Directory” function on the Cisco phones to work again!

Tags: , ,