Asterisk Hack One

The goals:

The business currently uses Cisco 7940/60 phones, an eBay/Chinaroby (digium clone) phone card with software echo cancellation, and Asterisk compiled from source. The server and firewall run Scientific Linux (A Red Hat Enterprise clone), and do nightly backups to two different backup servers, onsite and offsite. I hand-built my own extensions.conf and other config files, rather than use one of the excellent but somewhat opaque GUIs. The GUI versions are nice as they come with complete install CDs, including the OS and distros, but the components (distros and asterisk versions) are usually older.

Note: Between Asterisk 1.6 and 1.8, the older "zaptel" configuration files have been renamed to "dahdi". The documentation is still catching up, and the name change is confusing.

Note: Although this is normally not recommended, I run Asterisk on the same server as the internal business management server. With only 3 lines, and a fast dual-core Pentium, the load average hardly ever goes above 0.03 . This simplifies IT, allows me to tie the business management software to the phones, and means I can mirror the whole shebang to an offsite spare. If the building burns down, we can move the business to another site in a few hours. That may mean purchasing a second Sangoma card and more Aastra phones, or perhaps we can get clever and use the Chinaroby and Cisco phones for the spare. If a bunch of us settle on Aastra and Sangoma, perhaps we can pool some money and buy one set of hardware spares for all of us, as insurance.

Three incoming analog POTS lines, two public lines in a hunt group and a business line. Though the phones are potentially capable of talking SIP to the world, they are only connected to the internal business network, and through VPN to my home network.

Cisco 7940s are ancient, and Cisco wants to charge for everything, but the phones were free (thanks, w.!), there are lots of users and online FAQs. There is much information

The Aastra 9133i is newer, available used on eBay for around $40, much more featureful, has more programmable buttons, a backlit display, and lots of BLF / Busy Lamp Field.

The 9133i has three line specific keys (L1/L2/L3) with BLF - punch L1 and you are connected to Line 1, for example. The color and blink style of the BLF indicate the status of a call (available, in use, on hold, etc).

There are 6 programmable keys, and the 3 L1/L2/L3 keys. Can we map extensions to some, and outside line status indications to others?

The 9133i has a web interface for configuration, though it is better to configure most things with DHCP and TFTP. The 9133i is very similar to the Aastra 480i .

We use dhcpd on the firewall to tie each phone's hardware MAC address to a name, and provide a TFTP boot URL (which is working for the Cisco's, not for the Aastra yet!). Then BIND/named (also on the firewall) provides an IP address.

         server-name foobar; 

         server-name foobar;
         option tftp-server-name "";

After the phone has an IP address, it asks the tftp server for more configuration files, stored as /tftpboot/aastra.cfg (for information common to all phones) and MACADDRESS.cfg (for unit specific information). tftpd runs on the server, not the firewall, because the files are phone-associated and should not be exposed to the public internet.

The current dialplan, stored in /etc/asterisk/extensions.conf, is complicated. Incoming public lines go straight to a phone menu, which screens calls for hours and information requests, and redirection information for a departed associate. The caller can then select the "Receptionist", who can transfer the call to the "Boss". If neither the Boss or Receptionist answer, the caller can leave a message.

The business line is not screened, but rings the Receptionist on the first ring, then both Receptionist and Boss on the subsequent rings. If no answer, the caller can leave a message.

So, do we patch, or do we upgrade to, or does this problem not affect this particular instantiation?

In general, a problem with automated updates and canned Asterisk distros is that they can introduce flaws like this, and developers, used to the latest and greatest, don't pay much attention to such flaws.


Note: none of these older phones are IPV6 compatible. At some point, we upgrade again.

asterhack (last edited 2012-05-01 20:40:29 by KeithLofstrom)