VoIPowering Your Office: Taking SipXecs for a Spin

Our installation/setup experience with the new SipXecs iPBX was a bit rocky—possibly not the program's fault.

By Carla Schroder | Posted Apr 28, 2008
Page of   |  Back to Page 1
Print ArticleEmail Article
  • Share on Facebook
  • Share on Twitter
  • Share on LinkedIn

Last week we took a tour of the SipX SIP-based iPBX and SIP proxy, which is now renamed sipXecs and has over 170 new features—including such sterling items as auto-provisioning phones and integration with Active Directory and Exchange 2007 . Today we're going to install it and check out some of the new goodies and see if they live up to their billing.

Installation

Installation, surprisingly, was glitchy, but I suspect it's something odd with my test server. First I downloaded the ISO and made an installation CD, but for some reason my test server did not recognize the disk and would not boot it. I tried it in several other PCs, including my laptops, and they had no trouble with it. I could run any other of my vast collection of bootable CDs, but not sipXecs. I even burned a second CD and tried it, but that didn't work either. So I went to Plan B, which was to install sipXecs on top of the CentOS 5 operating system that was already installed on the test server. The nice sipXecs maintainers make this easy and give good instructions. Everything went smoothly until Yum hit the cgicc package from the sipXecs repository—it had no GPG key, and the default is strict GPG key checking, so the installation did not succeed. The fix is to disable strict checking, which is a bad idea because it is a necessary and fundamental security feature; it ensures that you are getting packages that have not been tampered with. It's a test system so what do I care, but in real life this needs to be fixed. Once that was changed the installation proceeded smoothly.

Manual setup

A manual installation, rather than using the CD, means having to configure networking and generate SSL certificates after installation. I use the excellent Dnsmasq on my network for local name services because configuration is much simpler than the horrid BIND, and it supplies both DHCP and DNS. I'm reinstalling operating systems a lot on my test servers, so this line is a real time-saver:

dhcp-host=00:1D:7D:2A:68:2D,192.168.1.77,redsonja

That means give the IP address 192.168.1.77 and the hostname redsonja to the computer with MAC address 00:1D:7D:2A:68:2D. Dnsmasq automatically enters DHCP assignments into DNS, so redsonja can be reached by her hostname, and Dnsmasq is configured to give her a fully qualified domain name as well. She also gets routes and important servers, such as the local timeserver, automatically pushed out to her from DHCP. It is necessary for your sipXecs server to keep accurate time and to have a correct FQDN, so make sure these are in place.

Next, make sure there is a sipx alias in /etc/aliases, and that root's mail is configured to go to a real user. This ensures that you will get daily reports and warnings when there are problems:

sipx: root
# Person who should get root's mail
root: carla@alrac.net

Run the newaliases command after making changes.

Your sipXecs server won't start until you generate some new SSL certificates. Do this with the /usr/bin/ssl-cert/gen-ssl-keys.sh script. Now you can start your new server:

# /etc/init.d/sipxpbx start

This runs a systems check first. If it finds problems you'll have to fix them. On my CentOS system it complained about having an iptables firewall running and SELinux in enforcing mode. Poor old SELinux, nobody wants it. I changed it to disabled in /etc/selinux/config, then restarted the system. Configuring a firewall for a sipXecs server is quite fun because there are so many services running, which means you have to punch a lot of holes in your firewall. Run netstat -untap to see for yourself; you'll be astounded and amazed.

Running the /etc/init.d/sipxpbx configtest and /etc/init.d/sipxpbx status commands performs the same checks as at startup. configtest should be run after making any configuration changes.

DNS and SRV records

You now have a running server, but there is one more step you should take, and that is to set up DNS SRV records. SRV records point to a domain instead of a specific server, so you can do easy load-balancing and swap servers without having to re-do all your phone configurations. It also makes addressing simpler, so your phones can point to alrac.net instead of redsonja.alrac.net. See DNS Configuration for details. You probably don't want your sipXecs server providing name services for your whole domain, but only for your VoIP clients.

First login—fast

Once it's up and running you can log in remotely via the Web interface. Which you should do immediately, because the first thing it does is ask you to set the superadmin password. Anyone who logs in before you do this can set their own password. Of course you can reclaim it by resetting the superadmin password with the /usr/bin/sipxconfig.sh --database reset-superadmin command. If your name services and network configuration are correct, you can log into the Web interface using the hostname, the IP address, or the FQDN. On my test system this is http://redsonja.alrac.net, or http://redsonja.

Stopping and starting the sipXpbx is done from your Linux command line:

# /etc/init.d/sipxpbx start|stop|restart

sipXecs claims it will auto-discover and provision a number of phones and gateways. Auto-provisioning is one of the most important features of an iPBX. It also boasts of a user-configurable auto attendant for every user, and integration with Microsoft Active Directory and Exchange 2007. We'll take a look at these next week.

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