Small Enterprise in Edmonton, Canada

From SIPfoundry sipx, The Open Source SIP PBX for Linux - Calivia

# of Lines: 10 HW: One server on Debian Sarge Phones: Polycom GW: Audiocodes MP-108 (4 POTS)

We are a company in Edmonton, AB Canada, and we just set up a sipX IP PBX system a month and a half ago. Here is what I have to say:

We liked: sipX was very easy to install using Michael Steinmann's Debian packages. Worked with our phones right out of the box.

DIY sipX was about 3x cheaper than the price we were quoted for a PBX solution from the telco, and sipX will scale up with reasonable incremental costs to as large as we expect to be.

We disliked: sipX's Java components can be fairly slow on the 700MHz machine we installed it on. This doesn't seem to affect operation once the PBX is booted, but it is noticable whenever the java stuff is used.

I also think the logging is more oriented to developer debugging rather than end user monitoring - ie things I'm interested in are call logs, voice mail activity, etc but the logs seem to capture raw sip messages and puzzling looking warnings.

Why sipX: I felt sipx had a better path to becoming a turnkey supported product, probably by switching to something from Pingtel. Also, I think the sipX model of using external SIP gateways rather than pushing for PCI cards is quite good.

Interesting: As of this writing we still haven't resolved some interop problems with the MP-108 and the telco (Telus). Particularly disconnect supervision only works 50% of the time, caller id requires the latest (4.60) firmware, the line levels seem to be too low, there is excessive echo and calls seem to be very simplex (as though the echo canceler is canceling out the callers voice) - basically the voice quality to POTS presently sucks.

Aside from your survey..

When I set about doing this I was really prepared for a difficult install of the sipX software and a fairly easy time with the 3rd party equipment like the Phones and Audiocodes. What turned out was the exact opposite. Within about 10 mins of 'apt-get install sipxpbx' I was able to make in-house calls with the Polycom phones through sipX, and other than a few more little things in the web interface sipX itself was done.

It took a lot longer to get the Audiocodes itself setup and working, even to a basic level. Primarily this is because the unit as shipped included no usefull documentation. I did waste some time trying to get it to fetch the config from the tftp server like the phones do and the Wikki implies. [Aside: I now have got docs from my VAR and things are alot better.] The Wikki could definately use better information on this device.

The next thing was that sipX and the older firmware on the Polycom 301's didn't have working MWI, so it took a bit more puzzling and fuss to fix it by getting 1.6 firmware onto the phones. After that the Polycom's seem to work fairly well, though I've noticed they don't retain end user settings like ring tone after a reset..

Then it was more Audiocodes fun - caller ID wasn't picking up the phone number, only the caller name, this was fixed with a firmware upgrade. Also disconnect supervision didn't work at all, I've got it working with about 50% of calls now by adjusting the detection interval down to 500ms.. but presumably the telco has to enable something for it to work properly.

For added extra fun, the telco messed up our lines in their computer so when I phone them to say 'disconnect supervision doesn't work, can you check your CO?' all they say is 'your lines, they are not in our computer yet. Call again later'. Wee ;> If anyone reading this list has any suggestions what magic words to say to the telco to help interop with the audiocodes I'd be keen to hear them!

The final small trouble I'm seeing is a sipX problem, sipxvxml tends to hang on me. Twice the watchdog restarted it, but four other times it just sits there and refuses sip packets. strace says that the thread that usually does poll, either wasn't running or was blocked on a futex. I still have to build a debug binary and gdb it before I can talk about this meaningfully. I expect this is either a locking/race problem exposed by the slower hardware I'm using, or something buggy about Debian or the Debian build.