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.

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.

Advertiser Disclosure:
Some of the products that appear on this site are from companies from which QuinStreet receives compensation. This compensation may impact how and where products appear on this site including, for example, the order in which they appear. QuinStreet does not include all companies or all types of products available in the marketplace.

Thanks for your registration, follow us on our social networks to keep up-to-date