Our old phone system was not working well. No one could leave messages. Two vendor attempts to fix the phone system had failed. Frequent conference calls were tying up the one phone line. It was time to upgrade our phone system and add a second line. Outbound calls and conference calls no longer tie up the main line, and the phone system is modern and sufficiently documented that we can maintain it ourselves.
Infrastructure Summary and Justifications
- The office has 2 basic PSTN lines with failover to voicemail but without rollover. If two people dial the office using the same number, then the second person will go straight to voicemail. However, if they dial different numbers, then they can both get through to the office. Rollover is not used because of the added expense (charged by provider) given the low frequency of its being necessary.
- We are using the Cisco SPA8800 IP Telephony Gateway as an FXO gateway to convert between PSTN and VoIP/SIP.
- We are using Axon Virtual PBX by NCH Software for call routing.
- We are using Polycom SoundPoint IP 550 phones, which receive high praise in most reviews online.
We are using basic PSTN lines for several reasons:
- Primary reason: using PSTN addresses basic QoS issues since calls do not compete for bandwidth (and we use significant amounts of bandwidth).
- We already had a long-term bundle contract.
- Various past experiences with local support and the underlying technologies made us averse to relying 100% on VoIP outside of our local network.
The SPA8800 has 4 FXO ports. During the research phase, we found relatively few gateway devices that would support multiple PSTN lines. We considered multiple single-line devices but this met our price point as an SMB while keeping us at a single device -- even if we add another line later. We also considered internal modems for the server, but limited PCI slots and future driver compatibility issues made that option less compelling for us since the PBX is running on a server used for other purposes as well.
Why Axon PBX?
This was not actually our first choice. I have had experience with Asterisk before but was looking for more of a Windows GUI-based PBX. We were willing to pay a reasonable amount to have something that just worked, that I could walk a coworker through troubleshooting in a pinch, and that was designed to natively run on Windows (rather than supporting a ported version or a dedicated box). In retrospect, looking for a solid Asterisk build might have been a better route.
At first, we attempted to use the IceWarp VoIP system. We have had great luck with their email and mailing list server, and we wanted to use their VoIP to take advantage of unified communications. Unfortunately, it did not work with our infrastructure out of the box, and they did not expose enough configurations or debug information for me to get everything working. After spending days working on that, I tried Axon PBX and had inbound calls working within two hours.
Many of the specific challenges will be documented in blog posts. To find them quickly, click the corresponding Technologies tag link below.