I’ve been playing with a few software-based VoIP PBXs lately. I accidentally came across SIPFoundry‘s sipXecs (commonly abbreviated SipX). Their Wiki home page gives some compelling reasons to try them out, so I did.

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.