PBX to redundant servers: Thoughts?

Last summer, my IT department assumed responsibility for the campus PBX and associated services. The PBX is a rock-solid Nortel Meridian switch. However, rock-solid doesn't necessarily mean that the switch is the right long-term solution for the College. For a variety of reasons that I won't go into, we're looking at options to replace this Nortel switch with something else. I'm sure we're not unique in this effort, so I thought I'd share the journey in this space. Voice is fast becoming just another LAN application with its own servers and hardware, albeit somewhat more complex than other services! I'd love to get reader thoughts on these thoughts and have you share your experiences in this space, too.

Since we're allowed to start from scratch with our voice services, the field is wide open. So far, we've made the following parameters important in our search for a solution to replace our PBX:

  • Cost: As always, cost is a huge factor. Again, right or wrong, for a number of reasons that I won't go into, this is actually the #1 factor for this project.
  • Easy to manage: I have a pretty small staff, so whatever solution we get has to be easy to manage.
  • Open: If at all possible, whatever solution we put into place needs to be as open as possible. I don't want to be locked into a particular type of phone and I'd like to see a system that is more easily integrated into our other services than the Meridian.
  • Feature-filled: Obviously, we have grown accustomed to a relatively rich feature set with the Nortel switch. We're working on an analysis of the features currently in use to determine exactly what our features needs are with a new switch.
  • IP-based with analog capability: For most of our faculty and staff, we'd like to provide IP-based devices to replace existing digital sets. However, we also support students in dorms and have a need for a relatively high number of analog ports as well.

Although a Cisco solution would meet many of our technical needs, the ongoing price tag is simply not feasible. For this project (and most of our projects), if a solution doesn't fall within our budget, we simply can't do it. Some might say that our budget for a project like this is too low, but that's a reality I have to take into consideration and I'm confident we'll be able to find a solution that meets our needs and our budget. We've also considered an Avaya solution, and are still working on that possibility, but that solution is not the focus of this post.

One thing I've found during this process is that there are a lot of "-tel" vendors out there, including Pingtel, Mitel/Intertel and Shoretel. I'm sure that there are more, but these are three that seem to be making serious efforts to supplant the traditional PBX with an all-IP open infrastructure. The solution I've focused on the most so far is the Pingtel solution. I have meetings scheduled with Mitel and Shoretel, too.

As its name implies, Pingtel's SIPxchange is an open source SIP-based IP PBX based on open standards. Pingtel sells service and support for what they consider an enterprise-grade service. The great part: If something supports SIP, SIPxchange will probably work with it and Pingtel might even support it. In my discussions, for example, Pingtel folks have indicated that, as long as the servers we use meet their system requirements, we're in good shape when it comes to installing SIPxchange and getting support. Pingtel's solution does provide high(er) availability through the use of redundant servers. Will availability match the Nortel? Maybe, maybe not, but I'd be willing to bet it gets darn close.

For my organization's project, we'd be looking at the following:

  • Two servers with SIPxchange, configured for redundancy and battery backed.
  • Replacing all of the digital phone sets and many staff analog phone sets with VoIP phones. The phones we choose will have a built-in switch so we can connect the person's computer to the phone set. Since we don't have PoE switches deployed campus-wide, and won't for four more years, we'll have the phones connected to the wall for power.
  • To accommodate emergency situations during a power outage, we'll deploy analog phones to common locations on campus. This would include a phone or two on each floor of each dorm. Since a vast majority of our students rarely use their phone service and many don't even have a phone connected, the impact will be minimal. For students that do want or need a phone, we'll patch their jack through. When all is said and done, we'll have about 200 IP phones and 200-250 analog lines on campus.
  • Analog devices will be run over copper to the location at which our current PBX resides and will be connected to an FXS port on an analog to IP gateway device. The copper to accommodate this is already available. These gateway devices will be backed by battery power, thus keeping them powered in the event of a power failure. Our ultimate goal is to also generator-back our data center and telephone infrastructure, but we're not there quite yet.

The pros:

  • A much more open voice infrastructure that we should be able to better integrate with our other services. For example, we'd like to roll out Office Communications Server 2007 for web conferencing and this service would work over SIP trunks to the SIPxchange servers. With the Nortel PBX, more SIP trunks = more licensing money and a configuration hassle.
  • Relatively significant cost savings, which means more spending on academics vs. infrastructure.
  • Providing all staff with more phone features. Most of our staff use analog phones with no speaker-phones, displays for caller ID, and more. When an analog user gets a call from a frantic student, he has no way of knowing from whence the call came. With the new service, caller ID will be standard.
  • We will likely run across many more.

There are, however, some downsides:

  • The Nortel box is rock solid and keeps all phones running for 2 to 4 hours during a power failure. With any IP-based solution we consider, only analog lines will be powered during a power failure. Our mitigation for this is deployment of a few analog phones in common areas.
  • Speaking of rock-solid, when was the last time your PBX crashed? You probably don't remember! Carrier-class PBXs simply work. In any IP solution we choose, high availability will be a must. With Pingtel, this will mean the installation of a part of SIPxchange servers.
  • Pingtel... not a ton of rollouts yet. We are speaking with some other customers, however, to gauge satisfaction and to look at the solution much more in-depth.
  • We will likely run across many more!

So, what exactly does SIPxchange include:

  • Voicemail/Unified Messaging (but we'll probably stick with Exchange 2007 regardless of what we do on the phone side unless the other solution simply blows us away)
  • Automated attendants
  • Call distribution
  • Expected call/phone set features, such as call transfer, hold, music on hold, conferencing, call pickup, multiple line appearances, do not disturb, call blocking, call waiting, E911 routing, hunt groups,
  • Call center services for... well... call centers!
  • Browser based configuration
  • A whole ton more

Pingtel's SIPxchange requires an Intel/AMD server with a minimum of 256MB of RAM, although 1GB is preferred. The product runs under Linux, although Pingtel prefers RedHat or Fedora.

You know, I tend to get really excited about cool new stuff and this is no exception. The techie in me drools over this stuff. However, the CIO side of me has to seriously evaluate the feasibility and practicality of any solution we consider. So, as we make our way through this process, I'll keep you informed about our progress and our ultimate decision.