Asterisk and Fedora Core 7

Looking over my blog stats, most of you reach me via a Google search for FC7 and Asterisk. With that, this post will detail installing Asterisk on FC6-7 or any modern Linux distribution for that matter as nothing here is Fedora specific anyways.

Getting Asterisk compiled and installed is quite trivial, so I thought it would be wise to spend a few moments examining the hardware you intend to use with Asterisk. If you are using a PSTN interface card through ZapTel such as Digium TDM or something else, you need to be aware that these cards generate a tremendous number of interrupts during their operation and the target system must be able to handle these interrupts quickly.

I’ve deployed Asterisk at the office where it provides call queues, automatic attendant, voice-mail and telephony services for 30+ people. This particular setup runs on a Dell 2850 with 1GB of RAM at 3.0ghz with a Digium TDM2400 card to analog PSTN lines. This setup’s load average rarely peeks over 0.01 during the day and the only complaint is occasional echo on the PSTN lines. We will soon be ditching the PSTN lines in favour of SIP channels from Primus providing both a huge cost savings and improved call quality.

At home, I’ve run Asterisk on a PIII-800 with 256MB of RAM using SIP only (no PSTN hardware) and have never had a problem with load related glitching or call drops.

The point in all this is to ensure that you select hardware appropriate for the application; don’t expect that old surplus P-III550 to serve as a corporate PBX for very long; but for home purposes that’ll only ever have 1 or 2 concurrent calls, it’ll probably be fine.

If you go with PSTN hardware, make sure to run the “zaptest” (or other for non-Zaptel hardware) program to test the interrupt timings.

Getting on with the installation, you should probably start by making sure any distribution specific Asterisk packages or Asterisk look-a-like clones are removed before you start. On FC7, OpenPBX is an available package, but in my opinion isn’t worth wasting the download. Go and get Asterisk from Digium directly and build your own.

This assumes you have a working build environment; generally the development packages for your particular distribution should have installed the basics like “make” and “gcc”… You’re really on your own here.

We’re going to be compiling Asterisk 1.2 at this time. Although 1.4 is out and in reasonable shape, I only have 1.2 experience and I’m quite happy with it so far.

Download the following source packages:

Asterisk 1.2.23 The Asterisk Code

Add-Ons 1.2.7 Asterisk Add-ons

Asterisk Sounds Pre-Recorded PBX sounds.

If you are going to be using ZapTel hardware, you’re going to have to build a kernel module. Download ZapTel as well.

To make things really easy, I’m going to include the commands to get this done. Lets start with Asterisk. Get, untar and build.

[skin@borg ~]$ mkdir asterisk
[skin@borg ~]$ cd asterisk/
[skin@borg asterisk]$ ls
[skin@borg asterisk]$ wget http://ftp.digium.com/pub/asterisk/releases/asterisk-1.2.23.tar.gz
--21:22:42--  http://ftp.digium.com/pub/asterisk/releases/asterisk-1.2.23.tar.gz
Resolving ftp.digium.com... 216.27.40.102
Connecting to ftp.digium.com|216.27.40.102|:80... connected.
...downloading...
[skin@borg asterisk]$ tar -xzvf asterisk-1.2.23.tar.gz
... lots of files...
[skin@borg asterisk]$ cd  asterisk-1.2.23
[skin@borg asterisk-1.2.23]$ make
...compiling...
 +--------- Asterisk Build Complete ---------+
 + Asterisk has successfully been built, but +
 + cannot be run before being installed by   +
 + running:                                  +
 +                                           +
 +               make install                +
 +-------------------------------------------+
[skin@borg asterisk-1.2.23]$ su root -c "make install"
[skin@borg asterisk-1.2.23]$ su root -c "make samples"

If everything worked out, you are the proud owner of a new Asterisk installation. There are a couple more things that need to be done though.

Lets do the sounds next.

[skin@borg asterisk-1.2.23]$ cd ..
[skin@borg asterisk]$ wget http://ftp.digium.com/pub/asterisk/releases/asterisk-sounds-1.2.1.tar.gz
[skin@borg asterisk]$ tar -xzvf asterisk-sounds-1.2.1.tar.gz
[skin@borg asterisk]$ cd asterisk-sounds-1.2.1
[skin@borg asterisk-sounds-1.2.1]$ su root -c "make install"

Lets do the add-ons now. If you want to use MySQL for CDR support, you need to make sure the MySQL-devel packages are installed for your distro before you run this. It going to look for mysql.h, errmsg.h and mysql_version.h.

[skin@borg asterisk]$ cd ..
[skin@borg asterisk]$ wget http://ftp.digium.com/pub/asterisk/releases/asterisk-addons-1.2.7.tar.gz
[skin@borg asterisk]$ tar -xzvf asterisk-addons-1.2.7.tar.gz
[skin@borg asterisk]$ cd asterisk-addons-1.2.7
[skin@borg asterisk-addons-1.2.7]$  make
[skin@borg asterisk-addons-1.2.7]$  su root -c "make install"

At this point, you should have a fully installed, ready for configuration Asterisk PBX. The installation gets a little more complicated if you need ZapTel for some PSTN hardware. If you’re planning to use the Conference Room feature, you’re going to need a ZapTel timer even if you don’t have hardware. It probably a good idea to build ZapTel anyways.

Like above, Get, untar, and build ZapTel.

[skin@borg asterisk-addons-1.2.7]$ cd ..
[skin@borg asterisk]$ wget http://ftp.digium.com/pub/zaptel/releases/zaptel-1.2.19.tar.gz
[skin@borg asterisk]$ tar -xzvf zaptel-1.2.19.tar.gz
[skin@borg asterisk]$ cd zaptel-1.2.19
[skin@borg asterisk]$ make
[skin@borg asterisk]$ su root -c "make install"
Building /etc/modprobe.d/zaptel...
***
*** WARNING:
*** If you had custom settings in /etc/modprobe.d/zaptel,
*** they have been moved to /etc/modprobe.d/zaptel.bak.
***
*** In the future, do not edit /etc/modprobe.d/zaptel, but
*** instead put your changes in another file
*** in the same directory so that they will not
*** be overwritten by future Zaptel updates.
***

Now we can try the ZapTel basics. Become root and try:

[root@borg ~]# modprobe zaptel
[root@borg ~]# lsmod
Module                  Size  Used by
wctdm                  37056  0
zaptel                183972  1 wctdm
crc_ccitt               6337  1 zaptel
.
.
.

The lsmod should show ZapTel loaded. This doesn’t imply that your hardware is configured, just that the ZapTel basics are in place. You’ll have to reference the specific module and configuration for your hardware, but the basics should be in place to get you going.

PHP Installation: A myriad of options

I suppose that a site that discusses PHP and Linux affairs should probably have some sort of documentation or links to reasonable how-tos on the subject. However, the thought of detailing a PHP/Apache/MySQL installation doesn’t appeal to me much either, so I’ll take a different slice on this. Rather than regurgitating the same steps as every other PHP How-To, I’ll talk about some configuration choices based on the machine’s role.

Alright then, you want to install PHP on your PC or “server” type machine. I’d hazard that you’re either already running Linux or have the misfortune of running Windows. While PHP runs on just about on hardware and OS combo, the Unix flavours perform better and seem to be more stable, not to mention there is less voodoo involved in making it work right.

In a nutshell, PHP is typically run in one of two different modes, either in CGI mode or SAPI mode.

In CGI mode, when a PHP page is called the webserver invokes the PHP executable to evaluate and execute the named script. The PHP binary is read into memory each time effectively isolating the execution. This mode is popular with certain ISP’s as it allows PHP to be further secured to client web home and configured to constrain to certain policies such memory and execution restrictions. There is some overhead performance cost with the CGI mode, but it is reliable and unlikely to knock over a shared host when properly configured. Most Windows IIS installations will run in CGI mode.

In SAPI mode things are a little different. The PHP code is complied into both a CGI and library form. This library is configured for use within the webserver and when PHP pages are being rendered, the in-memory library is used instead of an isolated process such as CGI mode. Under Apache, this seems to work great both on Linux and Windows. SAPI under Windows IIS tends to be a frustrating, futile exercise. PHP in SAPI mode tends to perform very well, less disk I/O overhead is achieved by taking full advantage of webserver caches, and optional PHP OpCode caches that further boost performance. In a shared environment it can be somewhat more complicated to configure some client restrictions and access rights, but there are many resources dedicated to locking-down PHP in these such configurations.

If you are a Windows user running IIS, don’t waste your time. Go with the standard CGI installation and save yourself the agony of running the SAPI module. PHP in CGI mode under Windows is bomb-proof and is very easy to install. Getting the SAPI to work under IIS isn’t all that difficult but it never seems to be very stable; no matter what, it will begin to complain about exception errors, and will open pop-up windows on the server complaining about something or other, sometimes locking up the webserver altogether. It just doesn’t seem to be very robust or clear if PHP is supposed to be production quality under IIS.

If you’re a Linux user, life is good for you in this regard. Check the details of your distribution, chances are there is a PHP package that can installed with only a few clicks of your mouse. Recently, Fedora Core has been my distro of choice and its PHP packages are great; they come compiled with all sorts of extras such as GD, LDAP and a few other neat-o extensions.

The next question that may come up is which version of PHP to install? PHP is currently being developed in 3 major versions, both  4, 5 and 6. At this time, PHP 4 support will be discontinued by the end of 2007 with only critical security fixes applied on a case-by-case basis until August 2008. PHP 5 is the way to go, its stable, production quality and has a future.

Compiling PHP from scratch is a good way to go on Linux but can be nuisance if it gets installed along side a pre-packaged file such as an RPM or if you have a lot of dependencies for extensions you need to include.

If you decide to roll-your-own PHP, I recommend starting from scratch; remove any repackaged webserver and PHP if already installed. Acquire the sources for PHP, Apache and any additional (-devel) dependencies for the extensions you want to build. I can’t really speak to compiling PHP under Win32 as I’ve never attempted it; there just doesn’t seem to be a good reason to do so, most extensions are precompiled and available from PHP.net directly.

Recommendations?

For a Windows based PHP developer, the PHP CGI under IIS works great and is easy to install and upgrade while not performing as well as similar hardware under Linux and Apache. Every time someone uses a Windows IIS MySQL PHP (WIMP) configuration in production, God kills a kitten. Just don’t do it.

For a Linux based PHP developer. You most likely have it the easiest of all. Depending on your distribution, it’ll probably only take you a few clicks using the package manager. If not, roll-your-own.

For Production purposes, a scratch built Apache 2.x and PHP5 SAPI running on Solaris/BSD/Linux compiled with only the required extensions. This is then optimized with an OpCode cache such as APC (Alternative PHP Cache) providing a robust and extremely fast PHP server capable of making short work of even the most complex PHP scripts.

Where to get platform specific installation info? Go straight to the horse’s mouth: PHP Installation Documentation

Blog Moved to the hosted WordPress…

Why the heck not? Its one less thing to worry about. I had installed the WordPress that came with Fedora core 7 but have since had some trouble with the i2o disk controllers. I basically lost everything on a RAID-5 array. Nothing aside from the few posts I made were really at risk of being lost, everything was just backed up prior to the system shuffling anyways.

The cause of this bizarre failure still escapes me.

I’d been tinkering with some new 100mm fans that I picked up at the local automotive/everything surplus store. The plan was to stuff as any of these as possible throughout both my desktop PC case and the server. 5 fans at $2.49ea…. great deal. I started with my desktop PC; in there is an eVGA 8800 GTS that idled in the mid 60C and would peak into the 80’s under load. 2 intake fans were added to it as well as an intake fan directly over the video card mounted on the case door. This did a great job of bringing the idle temps down to the mid-50’s and does a great job dissipating the heat under load.

Anyways, this is where it started to go wrong. After completing the fan install on my Desktop PC, I shelled into the FC7 box and issued a ‘halt’. Usually, the system crunches around, kills off all the processes and preps the system for shutdown. The usually finishes with a message like “System Halted. Power down”. 15 minutes have gone by and the shutdown process seems to have stalled; its not doing anything. I think this sort of thing happens on all Linux installs occasionally; perhaps due to some process that was killed manually and the PID file stays behind perhaps making the init script wait for a process that has already ended… It really could be anything and there is no way of knowing after-the-fact what it was.

So I gave it the “Big Red Button”. Powered-off, unplugged it and installed a few case fans. The fan went onto the PSU lead with the other fans using a full 12volt line. (There will be a rant about Antec’s “Fan Only” PSU lead in a future post). Checked my work, closed up the case and reconnected everything. Flicked the power switch…

It passes POST as usual but this time, instead of booting off the Adaptec 2400, it fell through and tried to boot off the CD, then tried to PXE off of each NIC. “No biggie” I thought; on rare occasions CMOS data can get reset when tampering inside a case… it does happen. So, power on again, mash the [DEL] key. Immediately I recognize that the settings are fine, as I left them.

Try to boot again… same deal.

Boot again and access the Adaptec hardware configuration, no problem, the array is still there. The tool only lets you manage the array, nothing configurable about the card such as boot interrupts or memory addresses.

Alrighty…. I don’t quite have the “Oh No!” feeling yet, so I boot off the FC7 DVD to see if I can determine if the card is still working on the Linux side; I can get my data off or even repair over-top. So I boot the Recover option from the DVD. The I2o drivers come up, the card is seen, capacity of the drives listed… but NO PARTITION TABLE! WtF? I break out of the installer to the first available console and try ‘fdisk’ for myself…. yup, its a big old empty partition table.

The “Oh No!” feeling sets in.

Fu-diddly-ck.

Having let FC7 configure the partition table when first installed, I didn’t note the specific partition sizes and disk layout. I’m no expert with the guts of the FC installer so manually invoking the partition tool escapes me. So I began to evaluate the old “diminishing returns” formula… RAID controllers tend to re-initialize when partition tables are written, so either way it looks like this installation is up-the-creek.

FC only takes a few minutes to re-install and I’d only be “out” 2 things, my WordPress installation/posts (a bit of searching later yields an XML file. w00t) and my latest configuration of Asterisk, Samba and such. So rather than messing around for hours on end, I quickly re-installed and got things going again.

At this point, I’m entertaining wild theories and ideas about what might have happened here and what I could have done to recover from this. Something mangled the partition table, I know that much. I’d suggest something about the RAID superblocks… but nothing hinted that the array was ever broken, its like something just blew away the partition table.

I suppose the lesson is, no matter how young and installation is, its never going to be immune from a good backup regime. Back-it-up or else!!

Fedora Core 7: Distro Review

My first ever WordPress blog entry… goodbye cherry!

Starting off with a few notes and observations of Fedora Core 7 seems appropriate as it (used to, I moved to WordPress.com) powers this site and some supporting elements for my home network.

Someone looking in might think I’m crazy, but my job and interests keep my stables quite full of computers. My wife and I each have our desktops, as well as one older HP NetServer 2U server as a firewall/ LAMP install and finally a PIII-800 with about 200GB of disk space that serves as my file dumpster and SAMBA NT domain controller.

Eco-concerns being what they are, it makes sense on a few fronts to combine the best of left over parts and build something to replace the HP and the PIII clone.

The target machine is my old desktop: (only the hydro company would reboot it)

• an AMD XP Athlon 3200+,
• 512 MB RAM and
• 140GB of IDE disks on an Adaptec 2400 RAID controller
• 8x DVD Burner
• Nvidia GeForce2 TI 64MB AGP
• Intel E1000 NIC

The obvious challenge in this configuration is an install kernel thats aware of the Adaptec 2400. Trustix 3.1.x supports this and if it was a lesser machine I’d certainly have gone with it; however I found it wasteful to dedicate such hardware to the menial task of packet forwarding. This naturally lead me down the path of an X based distro and my previous experiences with Fedora Core 6 being quite good I opted to try FC version 7.

The ISO was downloaded from ibiblio in record time and committed it to DVD.

The installation was seamless. It detected all the hardware! A Web Server configuration with a GNOME desktop was selected and the install was invoked. The format took a little while, but the disk array had not fully synced; not that it hurts anything, it just slows things down. The installer went about its business and rebooted.

The GUI came up in an optimal 1600×1200 resolution and I logged in as root.

Strangely, eth0 (e1000) would not get an IP address from my current DHCP server. After reviewing the message log, I discovered that the onboard 1394 controller was being aliased as eth0 during boot up. You’d have to own a 1394 device in order to need a 1394 adapter, so I took the coward’s way out and disabled it in the BIOS. Surprise, surprise, eth0 came right up and got an IP.

Once the YUM update manager did its thing and if memory serves me correctly, there were a 104 updates. The server was left to update the software and the installation continued the next day.

Next article we’ll look at FC7’s OpenPBX package and why it should be avoided.

All in all, this is a good distribution.  It hasn’t given me much grief and I’ve been able to accomplish everything I needed it to do.  Nothing new really seems to jump up at you, and everything is where you’d expect it to be found.

Fedora Core 7: OpenPBX

Following the theme of my previous post on Fedora Core 7, I really wanted to touch on my experience with OpenPBX.

Just for a bit of background, we’ve opted out of traditional telephone in favour of a SIP based VoIP, provided by a Montreal area re-seller named BabyTel. I had figured out and configured BabyTel to run under Asterisk 1.2 on my HP NetServ machine where it was happily doing its job answering the phone and taking messages etc… However, with all this swapping and upgrading, the HP NetServ is being retired.

So, looking through the FC7 package manager I see a listing for OpenPBX; I dig a bit deeper. OpenPBX is built on Asterisk and is somewhat different. Here’s what the authors claim make it different.

• OpenPBX.org has built-in STUN support for SIP NAT traversal
• OpenPBX.org uses SpanDSP which means better codecs and full T.38 fax over IP support
• OpenPBX.org uses Sqlite instead of Berkeley DB as its internal database
• OpenPBX.org has a universal jitterbuffer for use with any channel type
• OpenPBX.org uses POSIX timers which means there are no Zaptel timing dependencies
• OpenPBX.org has much faster and more efficient dialplan execution because it uses hashing
• OpenPBX.org evaluates correctness and integrity of configuration data (work in progress)
• OpenPBX.org runs well under a virtual machine such as Xen or VMware

Looking at this list, one assumes that the basics work and the folks at OpenPBX are diligently working on icing and candy. Sounds pretty good right? Prepackaged solution, easy to install, standard Asterisk config? What could go wrong?

So I embarked on the journey; OpenPBX installed via the FC7 Package Manager and then configuration began…

Having working extension.conf, sip.conf and voicemail.conf files, the theory is you should be able to drop these files in and basically start OpenPBX and life should go on. So, I grabbed the files off the old Asterisk server and copied them to /etc/openpbx.org/ on the new rig.

The copy was immediately followed by a service openpbx start.

Lo and behold, OpenPBX did start and did register the SIP channel with BabyTel. So I proceeded with a test call to the local talking clock (613-745-1576); great success! The call was answered and I was told the time.

Next and finally I moved onto voicemail. My callplan has the * key linked with VoiceMailMain; so to access any voicemail that was left, one would simply dial * and follow the prompts.

As soon as I tried the * key from a desktop phone; “click” the call was dropped. Looking through the logs the problem seems obvious; OpenPBX doesn’t ship with sound files.

Right around here is where OpenPBX begins to resemble a jet engine, in that it concurrently sucks and blows. I begin to search of a tarball of sound files for OpenPBX. OpenPBX seems to be a product without a real identity; searching for OpenPBX yields a sparse wiki and something much worse called CallWeaver. It would seem that OpenPBX is now something called CallWeaver. Take your pick, documentation for both packages is just plain terrible.

After searching and following countless 404’s the sound files were eventually fished out of svn://svn.openpbx.org/openpbx-sounds/trunk/sounds/ using svn. These files included a Make that ran each WAV through SOX for formatting presumably. Once complete the files were copied to the sound path specified in OpenPBX’s config files.

So, I try again. Dial voicemail using “*”. Click… hangup.

In the log again, this time its bemoaning the fact that it cannot find a codec to handle the translation of ulaw to g729. Which I suppose is fine as there is no g729 codec installed under OpenPBX. I deal with this by removing all references to g729 from SIP.conf to see if that helps.

Reloaded OpenPBX and tried again… A similar error this time; Unable to find a codec translation path.

mmmmkay. So now its bitching about codec paths that aren’t even configured. I figured a “reload” was enough, so I stopped and started OpenPBX. During the subsequent start-up it complained about the g729 codec. Loader.c: /usr/lib/openpbx.org/modules/codec_g729.so: undefined symbol: ast_log.

Assuming that an Asterisk compatible module would work in OpenPBX was a mistake. Based on the error one can only assume that in the process of “making” OpenPBX the authors did a wholesale “Find and Replace” on certain “asterisk” like words that resulted in breaking binary compatibility all over the place.

With a sour mouthful of OpenPBX tainting my palette, enoughs enough. YUM was called in to remove OpenPBX with extreme prejudice. I visited the Asterisk home page, downloaded the latest version of Asterisk and the supporting files and rolled-my-own build of Asterisk. I copied my configuration and g729 codec over and rigged up an init.d script based on the stock proftpd script.

First try, the talking clock worked.

Second try, the voicemail worked.

Given the 5 minutes of effort it took to download, compile, install and configure it took to get Asterisk going, I feel I’m way ahead of the 2 hours I’ve been tooling around with OpenPBX.

Why I can’t recommend OpenPBX to anyone:

1. Its a package looking for an identity. Not very clear what it is… or who is in charge of it.
2. The name change from OpenPBX to Callweaver further skews this identity.
3. Documentation is piss-poor. You might as well look up Asterisk how-to docs or use voip.info.org .
4. Binary compatibility with Asterisk is broken
5. Doesn’t seem to persist SIP registration between shutdowns. All the devices need to re-register. There may be a setting for this… but Asterisk does this out-of-the-box
6. Uses SQLite… but it doesn’t work nor is there any documentation to help.
7. Installation does not work out-of-the-box. There are a number of obscure downloads and builds required.

What does it have going for it?

1. Its a FC7 package. Maybe the worst one, but its easy to install but easy stops there!

Recommendation? Stay away. Get the real-deal from Asterisk. It works and has a future.

LightScribe Impressions

Having recently replaced my desktop PC with an Intel E6600 based rig, I’m finally getting around to trying out all the new toys. Yes, I have been hiding under a rock, having only ever heard about LightScribe, this is really my first exposure to this feature.

As part of the upgrade kit, I had requested a new DVD burner. The order wasn’t very specific but my contact at Elco system did his best call to fill the order. A Samsung Model SH-S182 was selected.

I opted against the bundled Samsung Nero software and went with my Nero version. Using the Cover Page designer I was able to Copy and Paste some FC7 logos and a screen shot of the Gnome desktop to the layout and “print” to the label side of the LightScribe discs. Yeah, you need special LightScribe discs too.

The process took 17 minutes to complete but the resulting label is really pretty neat. This particular label was somewhat complex which is presumably why it took so long to process.

Label Close-Up

Features like this are great for me… my Sharpies are constantly being stolen or lost leading to my evil stack of unlabeled media. I guess I’m a slave to LightScribe media now!

Its gonna take some getting used to, but I can really see this being useful. Way to go HP!