Open source tools such as Asterisk and SIP Enterprise Router are facing their biggest test yet at the University of Pennsylvania, where deployment of 15,000-seat VOIP network based on these open source IP telephony servers is rolling along.
The Philadelphia-based Ivy League university currently has over 1,250 Session Initiation Protocol (SIP) IP phones on desktops, tied to a back end based on SIP Express Router -- an open source VoIP call-control and routing stack, and Asterisk for voice mail messaging.
Deke Kassabian, the university's senior technology director for information systems and computing, plans to grow that installed base by a factor of more than 10 over the next five years. Driving the project is the desire to get off costly Centrex monthly fees and infrastructure, and the promise of an open source, standards-based VOIP infrastructure that provides superior integration and control.
"If we can run one modern IP network for voice, video and data .... there's a clear win," Kassabian says. "If we provide business telephony internally, less money leaves the university."
The infrastructure Kassabian and his team built is designed for high-availability VOIP, with redundant connections to IP call and feature servers, PSTN and IP telephony service provider (ITSP) point-of-presence links. Two data centers on campus host redundant clusters of Asterisk boxes, SIP proxy servers, and media/messaging feature servers. Phones on the network can register to and access any set of servers. "In this way, there's no single failure, and no single site failure that would take out the servers," Kassabian says.
For outbound calling, UPenn is using a mix of VoIP and PSTN services. For long distance service and other calls, UPenn is plugging its campus VoIP network directly into a SIP trunking service from Level 3. A pair of dedicated Cisco 3600 routers also support PSTN links for local calls, and as a back for ITSP service.
Optical fiber supporting multiple wavelengths of Gbps Ethernet over dense wavelength division multiplexing links UPenn's campus to a carrier hotel in Philadelphia, which provides ISP and SIP trunking services. A Session Border Controller sits at the edge of UPenn's VOIP network and peers with SBCs from Level 3 to connect campus SIP endpoints to IP and PSTN endpoints beyond the university.
The new method of tying a campus VOIP network to an ITSP's VOIP service was a more complex and challenging process than plugging into Centrex services, but worth it, Kassabian says.
"There's quite a bit of testing and certification that goes on in both directions with an ITSP," Kassabian says. "There's a whole series of certifications to make sure we can handle the set of situations that come up in the range of calls that will happen" between the ITSP's SIP SBCs, and the ones in UPenn's data centers. "There's several dozen inbound and outbound tests, and we work with their engineers."
However, the new service offers more flexibility, gives more control to the school's IT staff and lowers costs.
"Provisioning and managing Centrex," he says, "is a matter of filing the right paperwork and coordinating with the right people. That hasn't always been the easiest thing ... whereas VOIP provisioning is a technical process" over which IT has more control. The IT group already has a system for ordering and provisioning computer services through Web-based forms; IP telephony is now in that offering.
As for the phones themselves, desktop handsets include Cisco and Polycom handsets, with an IETF-standard SIP software image loaded on the devices. But this will change.
"We fully expect that we're going to have a mix of phone vendors' equipment in the network" Kassabian says. "In the same way that we don't have computers from all one vendor, we're going to have phones from multiple vendors."
This makes it important that all aspects of the SER call controllers and Asterisk messaging servers adhere to SIP, so that features are supported across any standard device added to the network.
"The goal, if you're running a project like ours, is to get the most functionality you can without using vendor-proprietary solutions," he says. This is one of the tricks in deploying open source and standard IP telephony -- getting the features right.
"The majority of telephony services that people want, we can provide," he says. "The ones we can't yet provide, we're working on."
Some features are hard to replicate in a standard, open source environment. Part of the learning process in pilot deployments was finding these out. The features include bridge-line appearance, which allows a phone to share calls with other extensions, and busy lamp indicator, which shows a bridge line as being in use.
While proprietary IP phone/IP call server provide these kinds of advanced PBX features, Kassabian says, "these are harder to implement in an open, standard way."
However, the features a proprietary signaling protocol adds do not make up for the lock-in costs of a closed system, or the recurring expense in licensing phones to work with a proprietary IP PBX server.
"There is a clear win over major vendor offerings and carrier services," he says. "From a financial standpoint there's a substantial cost savings."
Greater desktop-phone variety and saving some money were collateral benefits in choosing open source Asterisk and SIP over closed, commercial VOIP systems.
"In our case, [commercial IP PBXs] did not integrate well for us, with our middleware services, our directories and authentication systems," Kassabian says. "Those are designed with the typical corporate environments in mind, where there might be large installations of homogenous managed desktops and directory services. A university tends not to operate quite that way."
The Linux-based SER call control and Asterisk messaging servers were a better fit with UPenn's standard back ends for authentication (Kerberos and RADIUS), its OpenLDAP directory structure, and e mail. While commercial IP PBXs are adaptable to these platforms, "they don't work that way out of the box" typically, he adds.
With open source running extensively throughout the university -- from directories, to e-mail, DHCP and DNS -- the level of expertise in open source troubleshooting and development was there to support the Asterisk plans, Kassabian says.
"For years UPenn has had a strong open source talent pool. As a result, we have the staff and expertise to develop and roll out open source VOIP."
UPenn's work with the Asterisk community is also paying off by improving the product itself. University programmers have already contributed to two additions to the code base, which is now supported in the main release. One change integrates IMAP-based voice mail and messaging stores, and another involves improvements in SMDI signaling between IP phones and voice-mail system back end.
"Instead of going off and making changes ourselves," Kassabian says, "we get our changes built into [the code base] and don't have to maintain them ourselves. They're part of the next distribution."
From the several thousand phones deployed so far, Kassabian says the IT staff has absorbed valuable knowledge that should streamline the process as it snowballs.
"When you start to roll out," Kassabian has learned. "don't put a VOIP phone next to a standard telephone; you don't know if it's going to get used. Replace the phones. I recommend against a parallel network," of TDM and VOIP, at least on a department-by-department basis. This forces people to get used to the new devices -- which can be intimidating to some users. It's also a good idea to be on the same phone system as the group you are piloting. "Make sure you experience the system before you make anyone else experience it," he says.
Getting a VOIP lab up and running early is another good idea, Kassabian adds.
"We have a lab where we test new switches, routers, e-mail applications, but we never had that for voice because we had Centrex services for so long," he says. "It was a new thing to have to develop a voice development environment." Now this IT lab also runs a replica of the Asterisk servers in production.
Kassabian and his staff, mostly with IP networking backgrounds, also had to get up to speed with voice system jargon and terminology before being able to understand user needs. "We had to learn about how people use their phones," Kassabian says. "I had to learn what a bridge line appearance actually was."
Like many large organizations converging voice and data networks, consolidating the school's telecom and data network teams helped tremendously.
"Having people from our traditional telecom organization learning IP technology has been great," he says. "And our networking staff has been learning telephony. That's all been part of it. As time goes on, more of us are more well cross-trained and the two technologies come together very well."