Asterisk Hack One
- 1) Learn more about Asterisk and phones
- 2) Install a Sangoma B600D (with hardware echo cancellation)
- 3) Update and configure three Aastra 9133i phones
- 4) Vanquish bugs
- 5) Enjoy each other's company
The business currently uses Cisco 7940/60 phones, an eBay/Chinaroby (digium clone) phone card with software echo cancellation, and Asterisk 220.127.116.11 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.
Action item: should we upgrade to Asterisk 18.104.22.168 LTS?
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
Action item: figure out how to use the BLF, on the programmable and Line keys.
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).
Action item: figure out how to connect the lines.
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?
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.
Action item: figure out why the 9133i ignores the server-name field in /etc/dhcpd.conf . Does it need a numeric IP address?
resolved: The 9133 wants dhcpd option 66, which means that a simple
- in the dhcpd stanza doesn't work. This additional line makes it work:
server-name foobar; option tftp-server-name "foobar.example.com";
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.
9133i Problem: according to http://www.pbxinaflash.com/community/index.php?threads/aastra-9133i-hold-does-not-play-music.12698/ and https://issues.asterisk.org/jira/browse/ASTERISK-18086, Asterisk 22.214.171.124 and the 9133i do not handle HOLD properly. There is a patch here, which we can use to recompile channels/chan_sip.c, and that may be in the latest version. This is due to an obsolete and flawed behavior in the 9133i, which Aastra shows no intention of fixing, and was kluged around in earlier versions of Asterisk, and then regressed.
So, do we patch 126.96.36.199, or do we upgrade to 188.8.131.52, or does this problem not affect this particular instantiation?
Added note:probably do the patch, not the upgrade. The suggested patch is not in the file channels/chan_sip.c for either .7.1 or 11.1 . Thousands of lines of code have changed between the two versions, though, so it is quite possible that the problem was fixed elsewhere in version .11.1 . If we patch just the one module, and update only the executables that it changes, perhaps we can fix the problem with less breakage to the running system.
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.