A short while ago we proclaimed Aastra's 57i as the world's best Asterisk phone. And, with a huge helping hand from Aastra's technical engineers and documentation writers, we built a user interface for the phone (see inset below) with every imaginable feature to prove it. Well... every feature but one. We've always cringed when the commercial PBX vendors start bragging that their phones are plug-and-play while nothing in the open source world ever quite was, at least until today. What we mean by plug-and-play is that you take a SIP telephone out of the box, plug it into the network on which your Asterisk server is running, and boom. The phone just works. No configuring, no scrambling for manuals. It just works. The new extension number for the phone is created on your PBX, and it displays on the front of the phone when it boots. And, yes, folks can start calling you. Well, today Nerd Vittles is pleased to provide you with the software to make that happen at no cost at least if you're using Aastra telephones and a PBX in a Flash server. If you're using another brand of LAMP-compatible Asterisk server with FreePBX such as trixbox ce 2.x, then today's scripts should work for you as well. And, lest we forget, we want to express our special thanks to John Drolet, Aastra's VP of U.S. Sales for getting us some equipment for our test and development center. Others might call it a basement. And our usual accolades to Philippe Lindheimer, who heads up the FreePBX development team, for lots of hints and some sample code that we ended up not using. So... don't blame Philippe if this smokes! All of the "engineering" unfortunately is mine. So let's get started. And P.S.: Be sure to read the Comments for late-breaking news.

System Requirements. To make this fly, you'll obviously need some Aastra phones. Out of the box, this application supports the 57iCT, 57i, and 55i phones. You'll also need to add or turn on a couple of features that don't come enabled by default on PBX in a Flash systems. The first is a TFTP server which is used to hand out the firmware and application code to the Aastra phones. It doesn't really matter where the TFTP server is housed for this application, but we recommend your PBX in a Flash server to keep things simple. The second critical piece is a DHCP 3.x server which is used to hand out an IP address for each new phone as well as the IP address of the TFTP server to be used to load the firmware and configuration onto the virgin phone. I've been dying to use that word in a column! Where were we? The DHCP server must be running on your PBX in a Flash or LAMP-compatible server. We'll explain why in a minute. Third, you'll need our application code which does the heavy lifting to set up an extension in FreePBX for each new phone and then writes the configuration file necessary to actually set up the telephone instrument for use. All of our code is licensed for use under GPL2.

Installing TFTP Server and Aastra Config Files. The simplest way to get started with this project is to begin by reading our original article and following all of the steps there to install, activate, and populate the TFTP server on your system. Complete all of the steps down to the final section on Activating Your Phone. Be aware that our delivered aastra.cfg configuration was specifically designed for Aastra 57i and 57iCT phones. It also will work with Aastra 55i phones (which are only about $25 cheaper than the 57i's) although you'll need to make yourself a sticker to match the top third of the display shown in the 57i screenshot below. The 55i is missing this extra screen real estate. See the phone on the left above (55i) and compare it to the phone in the second row above (57i). There's plenty of documentation on Aastra's web site to walk you through further customization. Aastra models further down the food chain will require some major button reworking in aastra.cfg before the rest of this tutorial will be of much benefit. HINT: In case you haven't figured it out, this is NOT the place to save money on your new phone system.

Installing Plug-and-Play Application. Let's set up the application first. Just log into your PBX in a Flash server as root and issue the following commands:

cd /
wget http://pbxinaflash.net/scripts/plugplay.tgz
mv /etc/dhcpd.conf /etc/dhcpd.conf.bak
tar -zxvf plugplay.tgz
rm plugplay.tgz


Configuring Plug-and-Play Application. To configure the application for use, there are three steps. First, we'll set a few variables to match your system. Second, we'll protect any existing Aastra phones that already are in use on your network. And third, we'll set up a cron job to check for new phones each minute of your workday. We'll reserve the third step until after we get your DHCP server up and running.

To set the defaults for your system, edit /root/dhcp/settings.conf: nano -w /root/dhcp/settings.conf. The default settings look like this:

START_EXTENSION="701"
PW="1234"
HOST="192.168.0.50"
CALLGROUP="1"
PICKUPGROUP="1"

Much like a DHCP server, the START_EXTENSION variable is used to tell the application the beginning extension number to use in setting up new phones. Pick a starting number with lots of downstream numbers available because there is no error checking! For example, if you already have an extension 702 on your system and you set this up to begin handing out extensions starting with 701, that means the second new phone you add to your system will cause a royal mess. If you think the most phones you'll ever add is 20, then pick a block of 40 numbers and enter the starting number between the quotes for START_EXTENSION. In case you couldn't figure it out, PW is the default password for the new phone extensions that are created. Pick something secure especially if your Asterisk server is exposed to the public Internet. Once the phones are set up, the passwords can be changed in the usual way using FreePBX. For HOST, enter the IP address of your PBX in a Flash server to which your new phones will be connecting. If you use call groups and pickup groups, adjust these settings to meet your requirements. Otherwise, leave them alone. Save your settings by pressing Ctrl-X, then Y, then ENTER.

Protecting Existing Aastra Phones. This next step is extremely important if you have existing Aastra phones functioning on your system. To properly protect their configurations from being overwritten, let's first walk through how the new software works. A cron job kicks off a script every minute that looks in your DHCP leases table to see if your DHCP server has handed out any new IP addresses. If it has, the application checks to see if the MAC address associated with any of the new dynamic IP addresses matches the Aastra MAC address signature. If there is a match on one or more MAC addresses, then the script checks each MAC address to see if it is already registered as an Aastra phone on your system. The way it does this is by searching for the existence of a configuration file in /tftpboot that matches the MAC address, e.g. 00085D19C5D2.cfg is an Aastra phone on our system. If the file is found, the program exits without configuring the phone. So... for phones you wish to protect, be sure that you create a MAC address config file for each of them in /tftpboot on your server, e.g. touch /tftpboot/00085D19C5D2.cfg would do the trick.

The Rest of the Story. Now let's cover how the application works once it discovers that an IP address has been handed out to an "Aastra phone" for which a config file does not exist in /tftpboot. First, the software will generate a new extension in FreePBX to serve as the dedicated extension for this new phone. It does not activate voicemail for the new extension. You can edit any of the new extensions and activate voicemail if you need it for particular phones. Next, the software puts a reservation for this new IP address and phone in the DHCP config file. This assures that this phone will always get the same assigned IP address even though it is managed by your DHCP server. Finally, the software generates a MAC address-specific config file in /tftpboot matching up the new extension created in FreePBX to this new phone. Once this is completed, the phone is rebooted which forces a refresh of its setup using the settings. The whole process only takes a minute or so per phone including a firmware refresh. Your new phone now is ready for use. You can make calls and receive them. And the extension number of the new phone will be shown on the main display of the phone as well as in the phone directory listing. If for some reason the process encounters a problem, you can force a new refresh of the phone by editing the MAC.cfg for the phone and adding something as insignificant as a blank line. Then restart the phone by pressing the Options or Tools button and choosing Restart Phone. We'll cover activation of the software after we get your DHCP server up and running.

Installing DHCP 3.x Server. PBX in a Flash is delivered with the DHCP 3.0 server already installed but not activated. Before you activate it, let us provide a few preparatory tips. The design today assumes that you have a hardware-based firewall/router and that your PBX in a Flash system sits on the private network behind that firewall. If this is not the case with your setup, stop here. The rest of this won't work! If it is your situation, then the first step will be to disable any existing DHCP server on your private network. Having more than one active DHCP server on the same subnet is a very bad idea because IP addresses will be plucked from the different DHCP servers randomly, and you'll end up with a colossal mess.

Before disabling your existing DHCP server, a little housekeeping will save you a lot of headaches. Keep in mind that DHCP servers hand out "leased" IP addresses, i.e. a particular device gets the IP address for a fixed period of use. When half of that lease expires, the device will request a renewal. Thus, when you disable your existing DHCP server, all of that institutional knowledge about existing leases will disappear. One way to avoid the Humpty Dumpty Syndrome is to create "reservations" for existing leases. In essence, you are telling the DHCP server to remember a particular MAC address of a networked device and always hand out a specified IP address to that address. This address MUST be in the range of IP addresses being managed by the DHCP server.

So... Step #1 is to go to the web interface of your existing DHCP server and write down the device names, MAC addresses, and IP addresses of every existing device. Why? Because, if you don't hard-code these reservations into your new DHCP server, there will be no guarantee that the same IP addresses get handed out when the leased addresses come due for renewal. Failure to heed this advice may result in all sorts of quirky network issues once the lease times expire on existing devices. MORAL: It's easier than you think to hard-code existing reservations. Being lazy will only cause you heartburn in the hours and days ahead.

Step #2 is to read this simple tutorial about how your DHCP server works. In a nutshell, we're going to create a dhcpd.conf configuration file in the /etc directory on your server. In fact, the software install above did it for you. Here's the way ours looks:

host Kitchen-Mac {
hardware ethernet 00:1B:63:18:75:E8;
fixed-address 192.168.0.125;
}
host eeepc-toy {
hardware ethernet 00:15:AF:6C:1A:6B;
fixed-address 192.168.0.222;
}
}


Now let's edit the one we installed: nano -w /etc/dhcpd.conf. NOTE: If you already had a dhcpd.conf file, we renamed it to dhcpd.conf.bak. Not to worry! This looks harder than it actually is. Let's begin with the obvious. A # character at the beginning of a line is a comment. Be careful about curly braces. If they don't pair up, your DHCP server won't start. Go to the bottom of the file first. The last two sections between the braces (not including the closing }) are "reservations" for IP addresses you wish to preserve. Simply cut-and-paste a copy of this code for each reservation you wish to create. Be sure each reservation has a unique host name, a correct MAC address, and the fixed IP address you wish to hand out to this device. Don't use hostnames similar to the two examples because those names are used by this application. And remember that each of these fixed IP addresses must be in the range of addresses being hosted by your DHCP server.

Now, for the basics. The third line beginning with subnet is where you specify the subnet under which this DHCP server will be operating. In our example, the subnet is 192.168.0.0. For most home routers, you will either use this value or 192.168.1.0. Check your existing router/firewall to be sure or type ifconfig for some hints. The range line is used to specify the starting and ending IP addresses that the DHCP server is authorized to hand out. The subnet obviously must match. option routers is used to specify the IP address of your subnet router. With a hardware-based firewall/router, it's typically 192.168.0.1 or 192.168.1.1. option broadcast-address must match the subnet and usually has a last octet value of 255. For option tftp-server-name, enter the IP address of your PBX in a Flash server. This line works all the magic in telling Aastra phones where to go for firmware and config updates so be sure you have the IP address of your TFTP server entered correctly. For option domain-name-servers, enter the IP address of your firewall/router or the DNS server entries in your existing firewall/router. option time-offset is the Greenwich mean time offset for your time zone... in seconds. The option ntp-servers IP address should be okay. We've entered the IP address of time.nist.gov for you. The lease times also should be left alone.

Feel free to remove our two sample reservations. But DON'T REMOVE the line above: # reserved IP addresses are next. We use this commented placeholder to insert new reservations as phones are added to your system with this Plug-and-Play software. If you remove the commented line, then new reservations won't get added.

Once you get all of your settings entered, save the file: Ctrl-X, Y, then ENTER. To start your DHCP server (after turning off all existing DHCP servers), type /etc/init.d/dhcpd start. Assuming you don't get an error, go ahead and enter the following commands to make sure your DHCP server starts automatically when your server is rebooted:

chkconfig --level 2345 dhcpd on
chkconfig --level 016 dhcpd off


To review your DHCP leases at any time, type the following command: cat /var/lib/dhcpd/dhcpd.leases.

Loading Aastra Firmware into /tftpboot. For each Aastra phone model, there is a different piece of firmware. All of these should be unzipped and copied into /tftpboot on your server. The file names should look like these: 57iCT.st, 57i.st, and 55i.st. If you followed along in our original tutorial, you will already have the firmware in place for the 57i, 57iCT, and 55i. You can download firmware for additional Aastra phone models from here and the other phone-type links in the upper right panel of this page. Unlike some manufacturers, with Aastra, you'll want to download the current SIP firmware for each of your phone types. It's that good!

Activating the Plug-and-Play Software. To get things going, edit /etc/crontab (nano -w /etc/crontab) and add an entry to the bottom of the file that looks like the following. Adjust the 5-21 entry to reflect the hours of the day that you would like this application to run. It runs once a minute and uses virtually no processing power on your system so be generous with the hours.

* 5-21 * * * root /root/dhcp/scandhcp.php > /dev/null


Removing a Phone from Your System. Should you ever decide to remove a phone from your system that has been set up using this Plug-and-Play application, here are the steps to gracefully delete the information associated with this phone. First, disable scnadhcp.php in your crontab. Then use a web browser to access FreePBX and delete the extension associated with this phone. Choose apply config changes to reload FreePBX. Next delete the IP reservation in /etc/dhcpd.conf using your favorite editor. Then issue the command: /etc/init.d/dhcpd restart which will free up that IP address for future use. Finally, delete the MAC.cfg file associated with this phone in /tftpboot. Be sure to list the file to make sure you're deleting the correct one! Finally, issue the command: amportal restart to restart Asterisk. Enjoy!

FreePBX Training. If you'd like to learn more about XML programming on the Aastra phones, rumor has it that the upcoming Open Technology Training Seminar in Las Vegas will include a workshop put on by both Aastra and the OTTS team, and they’ll even throw in a free 55i phone to help you get your feet wet.

Some Recent Nerd Vittles Articles of Interest...

14 Comments

• 

  By Simon Hobson, Tuesday, April 22, 2008 @ 7:33 am

  Err, what’s that you’re doing with the DHCP server ? As soon as I read the bit about creating reservations for newly issued leases I guessed that you might be applying some very Windows oriented thinking and build an invalid config file - and when I get to the sample config I see that you have.

  Any fixed addresses defined MUST, and I repeat MUST, NOT be within any range defined. That’s not a recommendation, it is an instruction - ignore it and sooner or later you WILL have an IP conflict !

  You see, unlike the Windows server where you “allow everything, and reserve what isn’t to be dynamic”, with the ISC server you define you dynamic ranges, and separately define any static addresses. The server does NOT check this - if you tell it that any address from 192.168.0.100 to 192.168.0.254 is dynamically allocatable then it will happily dynamically allocate them, ie it will do as it’s told !

  What you have done will work - for a while. However, once you start using static addresses, the usage of that address is no longer managed by having an active lease - so the lease issued will expire. Once that happens, the address can, and eventually will, be offered to another device. It won’t happen until all the unused addresses have been used up, but it will happen eventually. If the phone is not connected to the network at the time, then another device will get that address, and once the phone returns then you have a conflict. The server MAY detect an active phone using that address (and mark it as abandoned) before it offers it, but that is dependent on a number of variables.

  I believe that in version 3.1 of the server you can in fact mark a lease as reserved to that client - which is a different process to creating host declarations with fixed addresses. The server will then manage the lease for that address in the normal way except that it will never re-allocate it to another client. At present this requires stopping the DHCp server and editing the lease file.

  If you need any more help, please pop over to the DHCP Users list at http://www.isc.org/index.pl?/sw/bind/bind-lists.php where you’ll find us quite friendly.

  Apart from that, great work - I’m trying to persuade the boss to buy some new phones at the moment so I can try this out.

  [WM: Didn't really think it was Windows-thinking. Virtually every non-Cisco router I'm familiar with works much the same way. I also was relying upon the following text from man dhcpd.conf which appears to contradict your suggestion that "the [DHCP] server does NOT check this… it will happily dynamically allocate” these IP addresses even if they already are in use. The manpage entry states:

  “The DHCP server checks IP addresses to see if they are in use before allocating them to clients. It does this by sending an ICMP Echo request message to the IP address being allocated. If no ICMP Echo reply is
  received within a second, the address is assumed to be free. This is only done for leases that have been specified in range statements, and only when the lease is thought by the DHCP server to be free - i.e., the
  DHCP server or its failover peer has not listed the lease as in use.

  If a response is received to an ICMP Echo request, the DHCP server assumes that there is a configuration error - the IP address is in use by some host on the network that is not a DHCP client. It marks the
  address as abandoned, and will not assign it to clients.”

  And the version 3 manpage continues with this:

  RESERVED LEASES
  
  “It’s often useful to allocate a single address to a single client, in approximate perpetuity. Host statements with fixed-address clauses exist to a certain extent to serve this purpose, but because host statements are intended to approximate ’static configuration’, they suffer from not being referenced in a littany of other Server Services, such as dynamic DNS, failover, ‘on events’ and so forth.

  If a standard dynamic lease, as from any range statement, is marked ‘reserved’, then the server will only allocate this lease to the client it is identified by (be that by client identifier or hardware address).

  In practice, this means that the lease follows the normal state engine, enters ACTIVE state when the client is bound to it, expires, or is released, and any events or services that would normally be supplied during these events are processed normally, as with any other dynamic lease. The only difference is that failover servers treat reserved leases as special when they enter the FREE or BACKUP states - each server applies the lease into the state it may allocate from - and the leases are not placed on the queue for allocation to other clients. Instead they may only be ‘found’ by client identity. The result is that the lease is only offered to the returning client.”
  

  Since Aastra phones respond to ping requests, we (perhaps mistakenly) ASS-U-MEd that the DHCP server would mark the address as either abandoned or reserved which accomplishes exactly what he had hoped. We also added update-static-leases on; shortly after release of the article. Are we still missing something??]
• 

  By Simon Hobson, Tuesday, April 22, 2008 @ 9:54 am

  >> Since Aastra phones respond to ping requests, we (perhaps mistakenly) ASS-U-MEd that the DHCP server would mark the address as either abandoned or reserved which accomplishes exactly what he had hoped. We also added update-static-leases on; shortly after release of the article. Are we still missing something??

  Yes, as long as the phone is actually up and running, then the server will mark the address as abandoned - but this is really a “last chance” safety net which can be turned off (ping-before-offer setting). To rely on this to overcome sloppy config isn’t the right way to do it. If for any reason the phone isn’t actually on the network, then it won’t respond to a ping, and another device may get the address - leading to a conflict if you then reconnect the phone. I know it’s a small window of opportunity, but I do actually know people who unplug their phones for various reasons.

  I believe the correct way to ‘fix’ an address to a client as you want is to set it’s lease to “reserved” - but I don’t think there is a clean way to do that yet.

  Even simpler of course is to rely on the fact that the ISC server will try and keep an address for a specific client anyway - it’s RFC compliant behaviour which is ignored by every other DHCP server I’ve used ! So once attached to the network, a phone will not change address unless it is removed until it’s expired lease works it way to the top of the list - addresses are re-used on a “least recently used” basis so active devices will not change address.

  Hope that clarifies things !

  Also, I would disagree with the advice to create static assignments for existing devices. As long as the leaseable address ranges don’t overlap then there will be no problem at all - devices will switch to a new address at some point, normally when they start up, wake up, or have their network cable plugged in. If the address ranges overlap, if you simply get each device to renew it’s lease then it will be given the same address from the new server. Failing that, you are still unlikely to get a clash because the ISC server (at the moment) allocates addresses ‘top down’ due to the way the internal hashing works - and every other server I’ve worked with (especially the ones in most home routers) work ‘bottom up’. Creating fixed host addresses is (IMHO) a waste of time and effort better spent on more fun things - like building phone systems. An exception to this is for devices that NEED to be on a fixed address.

  BTW - why do the phones need fixed addresses ? That’s not mentioned in the articles.

  [WM: I thought "update-static-leases" was added to DHCP 3.0 to fix this very issue. At least that's the way the manpage reads. As for why we recommended fixed addresses, it just makes it easier to track down a phone when there is a problem. For those that are worried about this, the simple solution is to remove the static assignments AND the "# reserved IP addresses are next" comment line in /etc/dhcpd.conf. By removing the comment line, the insertion of future static IP address assignments to the table will fail in the script without doing any collateral damage. Thanks for the information!]
• 

  By Simon Hobson, Tuesday, April 22, 2008 @ 10:41 am

  “update-static-leases” simply makes the DHCP server update the DNS on every request from a client - it doesn’t alter the way the server handles leases. As there aren’t any zone or domain name declarations in the DHCP config you give, I assume (yes there’s that ASS-U-ME again !) that you aren’t actually expecting any DNS updates - so setting “none” would be a more appropriate setting for ddns-update-style.

  Sorry if I sound sound picky, but one of my pet hates is core networking (like DHCP and DNS) that isn’t set up properly. It just “really bugs me” when these things aren’t correct - life is so much nicer when it’s all ‘just right’

  A couple of other things you might want to take a look at :

  The DHCP server supports includes, so you could put your auto-generated stuff in an included file which would make updates slightly safer.

  Can the phones send a hostname configured from their config file ? If so, then with the right incantations you could have the phones all appear in the DNS with user-friendly names - that way the IP address doesn’t matter.

  [WM: One of the real beauties of GPL code is that anyone and everyone is encouraged to enhance it. If someone builds a better mousetrap, the people will come. I'm going to give my setup a few weeks to run and/or blow up. If it blows up, I'll be the first to talk about it. So far, it's been running for a week on a very busy private network with close to 150 DHCP leases in active use for phones, computers, sound systems, security, and assorted gizmos of various flavors. Every router on the planet has a way to insulate leased IP addresses from being stepped on. If dhcpd doesn't, THAT would be a major shortcoming, and I'll be squawking about that as well. So... we'll see what we see.]
• 

  By ward, Tuesday, April 22, 2008 @ 9:30 pm

  If you downloaded and installed this application before 9:30 p.m. EDT today, please repeat the drill. A last minute “improvement” also injected a typo. Our apologies. To err is human, etc., etc.
• 

  By Devious1, Thursday, April 24, 2008 @ 2:14 pm

  Wow great work! I’m learning Asterisk and am about to install my third server, started with Trixbox Pro and got rid of that once I saw it was configured externally, then to Trixbox CE, till I found nerdvittles.com, and I’m about to install PBX IAF. Based on your article, I’m getting an Aastra 57i CT for my house, and look forward to seeing how it all works. Too bad the only comments here yet are about DHCP, missing the point that you’ve created a Plug-and-Play solution! I say bravo and cheers!
• 

  By adam, Thursday, April 24, 2008 @ 2:52 pm

  So it sounds like for this to work we have to use the PBXiaF DHCP server and not another one..even if we can set the required DHCP “options”. True?

  [WM: Correct. We have to have a way to detect when new phones are added.]
• 

  By James Heppe-Smith, Friday, April 25, 2008 @ 8:07 am

  Just a minor point that had me scratching my head for ages - if you live east of GMT (ie the adjustment to the timeserver is positive) then do not put a ‘+’ sign in front of the number you calculate - I spent ages trying to figure out why the DHCP server wouldn’t start!

  It just didn’t like the plus sign…
• 

  By Rob A, Sunday, May 4, 2008 @ 9:36 pm

  Is there a way to change the default setting for whether a call is “public” or “private” on the cordless? The default is “private”, which is a pain in the neck for home use.
• 

  By Andy, Wednesday, May 21, 2008 @ 4:58 pm

  This is a great article. In terms of ‘ZERO ADMIN’ deployment, I believe we should couple DHCP initial config tool here with ‘EXTENSION-MOBILITY’ configuration with the phone. This way, all the phone canbe configured ‘EXACTLY’ the same way; while customized when a user login.
• 

  By Jon, Tuesday, September 2, 2008 @ 9:23 am

  I have a question regarding the DHCP Server aspect of this. I have in my house cable internet with a router that has IP 192.168.10.XXX and it hands out DHCP addresses to computers and printers and other devices on that network. Then, off of that, I have a second router that has the WAN port connected to the first one for internet access. The SECOND router has an IP subnet of 10.0.0.XXX. The 10.0.0. subnet is what the phones are on. I just finished setting up for plug-n-play for the Aastra 57i phone, and before I restart it, I just wanted to know if anyone could help me make it so that the PBX doesnt try to hand out addresses to the 192.168.10.XXX subnet. If you need more clarification (i know it might be confusing) please let me know.

  [WM: So long as your server is on the 10.0.0 subnet, you'll be OK.]
• 

  By karld, Thursday, February 19, 2009 @ 10:29 am

  Is there some kind of incompatibility with FreePBX 2.5.x? My 55i’s are detected and setup, but don’t show up under extensions in FreePBX. They do seem to work fine however.

  [WM: Apparently there's been a change. We have looked in a while.]
• 

  By Rajesh, Sunday, March 29, 2009 @ 11:42 am

  Uncle Ward,

  Great Work, i have setup my phones but some features not working (im a complete newbie) i used your instructions step by step but DND,Call FWD and AsteriDex not working yet, also the plug play we cant use since it involves disabling existing DHCP server since right now im only working on a test Asterisk Machine with FreePbx so i cant play with DHCP server so please let me know if there is any other work around for plug and play.

  Thank you so much.
• 

  By Rajesh, Tuesday, March 31, 2009 @ 11:55 am

  Uncle Ward,

  waiting for your answers my Call Fwd and DND isnt working yet….!

  [WM: Head to the forums. Can't do tech support on a blog. Sorry.]
• 

  By Apu, Friday, December 11, 2009 @ 12:45 am

  First, thanks for all the Asterisk resources. I’ve adapted a few of them to my own RPM-based Asterisk server. But, now I’m trying to build a PIAF-based demo system and running into trouble with this script having installed all the lastest PIAF and FreePBX updates.

  Basically, it boils down to the database schema having changed at some point so the “phonegen.sh” script cannot add the correct values to the MySQL database. Still working on the details but, for starters…

  directdid, didalert, faxexten, faxemail, answer, wait, privacyman are no longer fields in the users table.

  [Sorry, Ward. I'd post this in the forums but am still waiting for my account to be approved by the moderators. In the meantime, I figured at least the next person will be on the lookout for this issue if they perhaps read the comments here first.]

Other Links to this Post

RSS feed for comments on this post.

Leave a comment