On to the on-site IP PBX options.
If you like rolling your own, the most open, customizable, and versatile option is to take any old computer, and load software onto it that turns it into a PBX. If all of your incoming trunks are going to be IP-based, and all of your telephones are IP-based, you need no special hardware. Asterisk is an open source product that runs on Linux, some other Unix OS’s, including Mac OS X, and, through a port called AsterixWin32, on Windows. 3CX is a program for Windows. There are others. A group of vendors providing extensive hardware and software support for Asterisk has arisen. You can buy line and trunk cards for your Intel hardware, and you can also buy complete PBXs built on Asterisk. There are a couple of dozen other products to look at in this category.
If you have the hardware and software chops, and like to play in the sandbox, a software PBX is a good choice. If you’re an IT department with a tight budget supplying telephone service for several hundred people, it may be a great choice. I didn’t want to take on all the work myself, and I have a small number of phones, so I decided to look at a proprietary IP PBX. I’ve been using a local telephony inataller for the last ten years, and I’ve been happy with them, so I asked them what vendors they worked with. There were two: NEC and Cisco. I did some research, and decided that, although I liked the Cisco phones better, there were some issues that I couldn’t get around.
The first was that the Cisco PBX needs to run its own DHCP server, and therefore, to avoid conflicts with existing DHCP servers, needs to run in its own private virtual local area network (VLAN). It turns out that my LAN switches are capable of creating and managing VLANs, but I didn’t want to deal with the additional layers of complexity. Another issue is the Cisco IP protocols. For the systems I was considering, Cisco phones communicate with the Cisco PBX using a proprietary protocol called Skinny Call Control Protocol (SCCP, or just “Skinny”) that Cisco acquired when it bought Selsius in 1998. I wanted to have the option of installing other IP phones in the future. I am told that the Cisco PBXs support some standard protocols for local phones, but it doesn’t seem to be the main thrust of the company. The Cisco PBXs do support standard protocols for trunks.
That left me with the NEC PBXs, which do use standard protocols for communicating with local phones, and will let me run by own DHCP (they provide information for me to load on the DHCP server to allow the phones to find the PBX). There’s no guarantee that I’ll be able to install, say, a Polycom IP speakerphone, but I think I’ll have a better chance.
The NEC PBX initially looked to be cheaper than the Cisco, but, by the time I added a fancy voicemail system (more on that in a later post) the cost was about a wash.
I am more comfortable with the security aspects of an on-site PBX than I am with a cloud-based service. The PBX can act as a proxy for calls over IP trunks: the trunks connect, via UDP, to the PBX, and the PBX connects, also via UDP, to the phones. That way there’s only a surgical firewall hole, from the PBX’s IP address to the SIP trunk provider’s IP address, that needs to be opened.
Leave a Reply