My eyes alighted on the 3CX website (www.3cx.com) I’d seen a year ago. It had a brand-new version of the software, and I was impressed by the depth of the configuration handholding it offered on third-party hardware (both the phones and the analogue phone line gateways). It soon became apparent that these devices are as friendly as cornered rats, so clear, step-by-step instructions on how to get them up and running was definitely an attraction.
I ordered some Grandstream phones, and a Grandstream VoIP analogue interconnection box which takes up to four analog phone lines. Downloading the software was easy enough: it appears not to impose too big a computing load – and it will happily run on an XP desktop PC, and even in a virtual machine. And this software will support a small office of up to 50 or so users.
Big box power
Clearly, I needed something bigger for my trial, so I cranked up the HP DL740 rack server and dropped Server 2003 Enterprise edition onto it. I’ll admit that an eight-processor Xeon rack-mount server with 20GB of RAM (4GB in hotswap failover) might seem like overkill, but I wanted to ensure the software had the best environment in which to run. In time, 3CX will get sucked into a virtual machine and run on the HyperV-based Windows 2008 64-bit Datacenter Server that sits below it, but for the time being it can stretch its legs on a box more suited to running the entire telephony requirements of Norwich city.
Doing the setup wasn’t too difficult, but I strongly recommend you read all the relevant parts of the excellent manuals, available both as web pages and PDFs. The setup installs an Apache-based web server into the box, along with a Postgres database engine, and a pile of other services that simply auto-run as you’d expect. The whole management interface is through a web browser, and here it’s considerably tidied up compared to the previous release. Inline expandable help is available at a mouse click.
The first thing you need to do is get the main server software running, which takes only a couple of mouse clicks. Then set up a couple of telephone extensions in the software. There’s a good wizard for doing this and good help, too. Since it is software-based and runs over Ethernet, you need to enter a little more information than “Line 1”: each extension has an ID and password associated with it. When the appropriate phone logs into the server it passes these credentials over, and thus the switch knows which phone represents each extension. Having set up two extensions (numbered 100 and 101 in a fit of originality) it was time to turn to some real physical phones. I’d ordered a pair of the Grandstream 2000 phones, which are a bit office-drab, but they do have a nice big backlit LCD panel.
Now you have to suspend usual phone beliefs. In the past, a phone was something you plugged into a wall socket, but an IP phone has its own web server built into it, and it’s through this that you get to the myriad options contained within the phone. Indeed, the phone has its own embedded OS, and can have firmware updates automatically downloaded to it over the internet. Clearly, choice of IP address is going to be crucial, so that you know what IP address to use when you connect to the phone, but for general operation DHCP addressing is just fine: remember that the phone logs into the server, so the server knows where the phone is.
At this point, things take a turn for the worse. When you open up the web browser onto one of these phones you’re faced with some of the most densely-packed web forms in the history of mankind and, worse still, although they’re in English it isn’t any form that you’re used to reading. Do you want an “iLBC frame size” of 20ms or 30ms? How about an “iLBC payload type” that’s set to 97, with the page helpfully telling me that it could be anywhere between 96 and 127? Naturally, a value of “f1=440,f2=440,c=25/525” makes perfect sense for the setting of Call Waiting Tone, and your “UAS Specify Refresher” can be either “UAC or UAS (when UAC didn’t specify refresher tag)”. Well, obviously!