Requirements

Here are the things I wanted my PBX system to do:

• Answer two incoming POTS lines, one business line and one personal line.
• Answer the Magicjack line, also as a POTS line. (Unfortunately, Magicjack does not yet allow users to access them as a VoIP provider without the use of the Magicjack hardware.)
• Route these three lines to two existing analog phone lines in the house, and eventually to a SIP phone for the home office.
• Route outgoing calls based on least cost. In particular, local calls should go out on the personal line (which has unlimited local calling), and long-distance on the Magicjack. “Local” in this case is loosely defined as area codes 619 and 858. I only dial 7 digits for 619 phone numbers, but I have to dial 1 + the area code to reach 858 numbers. Ideally least cost could be differentiated more granularly, as some 858 prefixes are probably toll calls and should go out on the Magicjack.
• If possible, run in a virtual machine. The host is an old 2 GHz Pentium 4 with 1 GB of memory, running XP Professional.
• If possible, cost nothing for software.
• Oh yeah:  and deliver crisp, clear audio with no jitter, crackling, drop-outs, echo, or all those other annoying problems that have become so familiar with VoIP.

A quick aside for those who want to try this at home:  before doing anything else, I had to modify my existing phone wiring. I basically installed a multi-port phone jack at the point where the phone lines come into the house. The top ports of the jack are the incoming phone lines. The bottom ports feed back out to the existing analog phones. My PBX goes in between.

Choosing a VoIP PBX

A couple years ago, I needed to replace a small traditional PBX for a client. It quickly became apparent that a computer-based VoIP PBX would be significantly cheaper than buying a new traditional PBX. I eventually went with Trixbox, and it’s still working pretty good.

Trixbox is basically a pre-built ISO that installs the CentOS flavor of Linux, then sets up FreePBX, which is based on Asterisk. Trixbox has since gone commercial. While they still offer a free version, I decided this time to look at PBX in a Flash (PiaF). PiaF also uses CentOS, FreePBX, and Asterisk.

I’d seen mention of 3CX in some forums. Since I mostly use Windows boxes, the idea of a Windows-based PBX is appealing. I decided to look at 3CX.

Somewhere along the way I stumbled across sipXecs and spent some time looking at that as well. I’ve already blogged on that so I won’t spend any more time on that here.

Trying Out 3CX

It was pretty easy to get 3CX set up and running in a Windows virtual machine under Microsoft Virtual PC/Server. (That’s saying a lot compared to the hoops you have to jump through to run a Linux-based PBX in a virtual machine!) And once set up, there’s a lot to like:

• Consistent user interface.
• Decent documentation on how to set up Analog Terminal Adapters (ATAs) and phones.
• Pretty easy to configure.
• Caller ID was captured correctly (number only, no name)
• Good voice quality, except with the Magicjack, which turned out to be a pretty universal problem.

However it didn’t take long before I started encountering some limitations:

• Web access to voicemail, and fax service, are only available in the commercial edition.
• Voicemails can be sent as email attachments, but the .wav files occupy about 1MB per minute.
• Outbound call rules can only be set up based on number length, number starting with, or which extension is making the call. I did not see an obvious way to set up my least-cost dialing rules (although it might be possible to set up area codes with the “number starting with” option). My forum post on the topic yielded no solution.

I initially had some other issues, but they were mostly related to the Grandstream HT-503 ATAs that I started testing with. I wound up returning those ATAs when I was unable to get them to reliably deliver Caller ID.

Trying Out PBX in a Flash

PBX in a Flash (PiaF) has a great web site with loads of documentation and an active forum. PiaF uses FreePBX , which has its own site and forum. FreePBX is built around Asterisk, also with its own site and forum. This multi-level product can be a bit confusing at first, but ultimately it is one of its strengths. It wasn’t until I looked at sipXecs that I was reminded what it’s like to deal with “raw” open-source software. The great thing about PiaF and FreePBX is that these guys have tested a bunch of different versions of the software plus dozens of add-ons, have found combinations that work, and have created packages that install everything for you automagically (more or less).

Some of the other PiaF/FreePBX pluses:

• Outbound calling rules are infinitely configurable through a kind of regular expression syntax. FreePBX can even pull in a pre-built list of local phone number prefixes.
• The free version includes web access to email and fax service.
• Voicemails sent as email attachments are compact–under 100K per minute.
• Voice quality is good except with the Magicjack.
• Lots and lots of add-ons are available. I may not need or use most of these, but it is nice to use a platform (Asterisk) that is so widely implemented and enhanced.

Of course, PiaF is not without its difficulties:

• By far the biggest hassle is getting PiaF running well in a virtual machine. More on that in a separate blog post.
• The PiaF/FreePBX user interface has improved greatly in the last couple years, but it’s still clear that PiaF incorporates programs by several different authors:  the “look and feel” is not consistent throughout.
• You can’t entirely avoid knowing something about Linux. This could also be listed as a “plus” since learning Linux is probably a good thing. But it does make the install more difficult when you need to search Google every time you want to run some simple command (check the IP address of the computer, list files with their sizes, etc.).

General Findings and Moving Forward

After much testing, I’ve had to accept that the Magicjack may not work reliably with a VoIP PBX system. It seems that going from a VoIP device to analog and back to VoIP, with all those analog-to-digital transitions, may be too much too ask. I’ve moved Magicjack compatibility down the priority list. Hopefully Magicjack will eventually support a “BYOD” (Bring Your Own Device) solution so I can directly register the Asterisk server with Magicjack as a VoIP provider.

Running a PBX in a virtual machine is indeed a questionable endeavor. 3CX, the Windows-based PBX, seemed to run pretty well in virtual Windows client. But for some reason, getting a Linux-based PBX to run well in a virtual machine is more difficult. I’ll try running it virtually for a while, but I may wind up installing directly on a physical machine.

Both 3CX and PBX in a Flash have much to recommend them. I’ve decided to go with PiaF for now. For my own records, I need to document the steps that I took to get it all working. Hopefully by putting the information in a series of posts, it will help some of you out there as well. Here they are:

Setting Up PBX in a Flash, Part 1:  Configuring a Virtual Machine

Setting Up PBX in a Flash, Part 2:  Before Running FreePBX

Setting Up PBX in a Flash, Part 3:  Configuring FreePBX

Setting Up PBX in a Flash, Part 4:  Configuring a Linksys SPA-3102

Update 11/24/2008:  I ultimately converted to a physical machine, though the virtual machine was a great test bed and is probably a good alternative for production with the right host. See more here.

Environment

At least for test purposes, I want to run SipX in a virtual machine. I’m most familiar with Microsoft Virtual PC and Server, so I used those.

Installing SipX

Here are some random things I encountered trying to get SipX running in a Microsoft virtual machine. I used the Single CD Installation CD because, “It cannot be much easier than this.” Some of the issues that I encountered were due to the virtual environment. Some are due to SipX itself.

• Virtual PC and Server cannot display the 24-bit graphics used by the CentOS 5 installation program. By examining some of the installation files on the CD, I determined that typing sipx text at the first prompt would get the CentOS installation started in text mode, which worked fine.
• The SipX installation CD is hard-coded to look for SATA or SCSI disks. Unless you want to rewrite the SipX CentOS kickstart file, that rules out Virtual PC’s IDE disks. I got around this by installing under Virtual Server R2 SP1 and adding a SCSI controller. After installation, I re-attached the disk as an IDE disk because I didn’t want to fuss with the SCSI drivers under Linux.
• At one point during the installation, it presented me with a SIPDomain name parsed out from a previous hostname entry, and told me that my SIPDomain was wrong and it could not continue. I eventually found the source code using Google and discovered that it was hard-coded to only allow a lowercase domain name. I didn’t remember giving it uppercase in the first place, but by overtyping its default with lowercase, I was able to continue.
• The SipX installation requires you to use a fixed IP address. I prefer to use the router to assign the IP address based on the MAC address. After the installation, I had to use system-config-network to go back to DHCP client mode.
• The installation apparently does not start the network card automatically. I had to edit /etc/sysconfig/network-scripts/ifcfg-eth0 and set ONBOOT=yes. Only then would service network restart actually start the eth0 card.
• The SSL certs failed due to clock issues. This is a Virtual Server issue. Once I got the Microsoft Virtual Machine Additions for Linux installed (a challenge in itself), this problem went away.
• After installation, SipX does not work. You have to run yum update in order to get the call resolver to start. Since yum update installs 148 packages, it takes forever.
• After getting the call resolver to start, I had some trouble getting SipXConfig to run. You’re supposed to be able to go to http://host.domain.name. That redirects to you to https://host.domain.name:8443/sipxconfig, which tells me Page Not Found. I tried some of the stuff on the SipX ConfigServer Troubleshooting Page but got nowhere. Finally I found a random post on Voxilla that mentions that the URL should be https://host.domain.name:8443/sipxconfig/app. Sure enough, adding “/app” got me to the setup page for the application. Later, I found that http://host.domain.name did redirect correctly; I’m not sure what changed–possibly that I had manually accepted the SSL certificate that the browser considered invalid.

Wow! That was a lot of work. Perhaps the most frustrating part was the lack of accurate documentation. The SipX Wiki has potential, but its articles are frequently out of date, and since they carry no dates or version information, there is no way to know what level of accuracy to expect from any given article. SipFoundry hosts no user forum, just an old-style mailing list with no search function other than Google. Voxilla hosts a sipX forum, but since May 2005 it has garnered a total of 76 threads, most with zero replies.

Somewhere in the middle of all this, I got tired of trying to do it myself and decided to try SipX’s much-touted Live CD to see if SipX was worth pursuing. That page links to the ISO directory where you are supposed to be able to download the Live CD. Unfortunately, as of this writing, there is no Live CD there.

Running SipX

Once I was able to start the program, I must say that I was impressed with the UI and functionality. The UI has a nice, integrated feel with all functions available from a series of menus. With that said, I missed being able to monitor basic system performance (CPU and memory usage) from within the UI, and their CentOS build does not install webmin by default.

SipX has done a lot of work on creating the ability to remotely provision some gateways and phones. This requires a DHCP server that has Option 66 to route to the SipX tftp server. Without that kind of DHCP support, the SipX configuration tests fail. I was able to work around this in my test by manually configuring my Linksys SPA-3102 gateway (which isn’t on their auto-configure list anyway).

Unfortunately, audio quality was not great when used together with the SPA-3102. Calls to voicemail from both the FXS and FXO side of the gateway sounded choppy. I attribute this entirely to running in the Virtual Server environment–I’m having similar issues getting FreePBX to run well under Virtual PC. Interestingly, SipX audio quality under Virtual Server is a little better than FreePBX audio quality under Virtual PC. However, SipX’s CPU usage is higher than FreePBX’s.

Closing Thoughts

If SipX wants to encourage broad testing and use of their system, they need to streamline the installation and documentation, and add better user-to-user support (a forum). However, luring thousands of “newbies” to the project probably isn’t their goal. Maybe one day, communities will grow up around SipX as they have around Asterisk (Trixbox, FreePBX, PBXInAFlash, etc.). In the meantime, my impression is that SipX is a serious project that would take significant effort to learn and implement, but that would scale well and probably be worth the effort in a large installation.