VoIPowering Your Office: Warming Up PBX in a Flash

The admirable CentOS Linux distribution has its own distinctive approach to system setup. We show you the way.

By Carla Schroder | Posted Dec 3, 2007
Page of   |  Back to Page 1
Print ArticleEmail Article
  • Share on Facebook
  • Share on Twitter
  • Share on LinkedIn

Last week you enjoyed my kindly introduction to the newest entry in the Asterisk-based VoIP server appliance category, PBX in a Flash. Today the gloves come off—I've been pummeling it mercilessly on my test machine, and scribing a merciless, no-holds-barred review. It's not that I like making grown developers cry. Well, actually I do. It's easy and fun.

A different kind of installation
In these here modern times, installing anything Linux-based is as easy as falling over, and so, barely worthy of mention. But PBX in a Flash takes an unusual approach. The usual way to package a Linux-based software appliance is to bundle everything on a single CD—the operating system and all the applications. PBX in a Flash gives you CentOS Linux 5, which is my personal favorite for VoIP servers, because it's rock-solid, stable, and well maintained. Which it should be, as it is a direct clone of Red Hat Enterprise Linux. RHEL, according to the GPL and good manners, makes its source code readily available. The CentOS team take the RHEL source code, remove all the trademarked bits such as branding and artwork, and re-compile it as CentOS. Anyone can do this, so what makes CentOS special?

First of all, it's not a trivial task to re-compile an entire Linux distribution. Then find and weed out the trademarked and any other proprietary bits, and create and add your own artwork. Then you need download servers, and someone to handle ongoing maintenance. The CentOS team deliver a fair bit of added value by applying upstream patches and updates swiftly, supplying their own documentation, and their own user forums and mailing lists.

Okay then, back to the PBX in a Flash difference. The installation CD gives you CentOS, and then, instead of bundling all the additional applications that you need for a VoIP server, you get a batch of installation scripts that download and compile the applications on the fly. This is an unusual approach that I don't believe has been done by anyone else. Because the VoIP applications are maintained separately from the operating system, this (presumably, depending on the diligence of the developers) ensures that you always get updated applications. So you need an Internet connection to perform the installation, and a local DHCP server—and not be in a hurry. On my old Duron box (800 MHz CPU, 256 MB RAM) and not-very-fast DSL it took about an hour and a half. That's a pretty feeble box for a VoIP server, but it's fine for a test machine.

If your installation hangs at the partitioning page, re-start your installation and try running the text installer by entering linux text on the boot command line. The installation is mostly hands-off, but you will have to remove the CD when the CentOS portion of the installation is completed, or it will boot the CD again.

Post-installation
Log in and run the genzaptelconf script after the installation is completed. You need this to set up the ztdummy timing device, or any Zaptel hardware you've installed. By default this loads a bale of kernel modules you don't need, which eats up memory, so you should first edit /etc/sysconfig/zaptel and comment out all the interfaces that you don't have, except the TELEPHONY=yes line.

Then you must assign a static IP address to your server. As the helpful PBX in a Flash prompt tells you, run the help-pbx command to see all of the nifty custom scripts at your disposal. Use netconfig to assign a proper static address. (Unless, of course, you assign one from DHCP.) Now reboot and everything will come back up all nice and spiffy.

Quibbles
There is a good installation guide, but it has a couple of items with which I must take issue:

On page 17 you are advised that when you're configuring your network interface, your default gateway and primary nameserver must not have the same address. This depends on how your network is set up, so if they do have the same address, don't let these instructions derail you.

And now for a really big quibble, please refer to page 21, where you are advised to not write down your passwords. I'm sorry, my fine PBX in a Flash persons, but this is bad advice. This is what has created a generation of users and admins who use the same password for everything in the world, and who create easily guessed, easily cracked passwords. You should always write down your passwords, on paper, and keep them in a safe place. This is how you sanely manage multiple, properly-difficult passwords. Security guru Bruce Schneier recommends this if you don't want to take my word for it.

Come back next week and we'll take PBX in a Flash out on the test track and burn some rubber.

Special bonus: Where-are-the-IAX phones followup
A couple weeks ago I lamented about the dearth of IAX hard phones, and the limited selection of IAX softphones. The always-helpful Bill Miller of Digium offered this explanation:

"Actually, there are several IAX soft phones, including one by Securax... Zoiper (previously called Idefisk). There are several others but not sure if those are still active. There are several IAX ATAs—Digium still makes the IAXy, of course, and Googling turned up several others (ever heard of "Freshtel"?).

"Among the soft phones, though not are all in the "traditional" soft phone format (for example the Java soft phone that Tim Panton of Mexuar has done). There are also a number of low-cost Chinese and Taiwanese hard phones based on the AR-1688 chip (an IC commonly used for low-end ATAs and such). What does not exist at this point are business phones for IAX2. To hazard a guess, the low uptake in the biz-phone world stems from the limited market (only Asterisk and Asterisk-derived systems support IAX2 while EVERYTHING supports SIP), the state of the standard (currently only an Internet Draft rather than a full RFC) and the complexity in layering business features onto IAX2."

Me, I think it's because most vendors are running in packs, all fighting for the same slice of the market, instead of trying to take advantage of the wider possibilities. A lot of folks still look at Open Source the same way they look at snakes. But that's just my $0.02.

Comment and Contribute
(Maximum characters: 1200). You have
characters left.
Get the Latest Scoop with Enterprise Networking Planet Newsletter