

In the first of two case studies, Helen Beckett
looks at how the distributed nature of a voice over IP phone system
adds to its resilience in the face of unexpected
incidents.
When Brunel University began migration to a voice and data
network, it little realised that the case for voice telephony would
be proved in such a dramatic way.
A major incident occurred just days before roll-out was
completed. It demonstrated the network's resilience and gave an
early glimpse of the kind of flexibility that IP phone telephony
could bring to a business operation.
Twenty-four months into the phased IP telephony project, a
central heating valve that heated the entire Uxbridge campus
through underground ducts blew. The valve was adjacent to the
administration block that also housed the central - and still
analogue - PABX.
The temperature in the PABX room rose to sauna levels and then
fell within a few minutes. The team would later realise that the
PABX cards were destroyed as all the circuit boards were exposed to
100-degree temperature and high humidity.
At the time though, any thoughts of a rebuild were quickly
replaced by a call for more immediate action. The main switchboard
was down and the university cut off from the rest of the world. The
block housed not only the vice chancellor, but finance and student
registration staff too, and 350 employees were without phones.
"It was the day before payday, so it was vital we got critical
operations up and running as soon as possible," recalls Simon
Furber, network manager.
Furber was away in Miami at the time, and so the disaster
recovery operation fell chiefly to Will Templeton, IP consultant
with his team. A call to BT's provisioning centre to reroute the
main switchboard number to an IP line into the campus immediately
created a host of contingency options. Templeton opted to create a
user profile, login and hunting group from Cisco Call Manager.
The biggest obstacle to recovery was physically gaining access
to the damaged administration block, which had to be dried out for
48 hours. In the interim, key staff members in the finance and
administration departments were assigned IP phones and relocated to
a small disaster recovery space abutting the IT room.
The administration staff had been the last to be switched to the
new network, and so had not yet received training in VoIP. But
Templeton and his team created user profiles in batches for
administration staff and uploaded them to the Call Manager server.
The basic profile consisted of the ability to call in and out of
the network for national and mobile calls. The administration team
was back in action in two days.
Had the new voice and data network not been installed and ready
to plug into, and had the team been reliant on the legacy analogue
system, then recovery would have taken longer.
"We would probably have had to disassemble and reassemble the
entire PABX, which would have taken up to one week," says
Templeton.
The added resilience of IP telephony comes from its inherently
distributed topology, as Brunel has experienced at first hand. As
core processing and switching functions of the analogue PABX are
dispersed onto the call manager server, the data network and the IP
handsets themselves, so resilience increases.
"There are multiple servers and multiple locations with multiple
lines coming in compared to a single point of failure," says
Templeton. "People are always concerned about the phone network
going down. But with IP telephony a lot has to happen before the
network goes down because it is so distributed."
Mobility of extensions, however, is the most tangible evidence
of flexibility and has come in useful for a number of other
contingency scenarios that have cropped up on the campus. Some of
Brunel's buildings lie next to the river Pinn and flooding occurs
from time to time. "We have a disaster recovery room and people are
starting to use it more as they realise they can just arrive and
plug their phones in," says Furber.
The burst valve proved to be an early test of the flexibility of
VoIP. It was the first major disaster recovery scenario, and Furber
hopes, the last. And it passed with flying colours. "We moved 300
people in one day," says Furber.
VoIP had originally appealed to the university as it sought to
rationalise its networks and prepare for a digital future. In 2000,
the IT department started a project to re-cable its campus with
fibre, and whittle a medley of kit down to one supplier - Cisco. At
that time it maintained Siemens' ISDX PABXs on the main campus and
gradually introduced IP on to smaller satellite sites. The two
worlds connected at a basic level to provide an integrated dialling
plan.
The IT department also saw the upgrade as an opportunity to get
an early taste of IP telephony and started trialling VoIP from
Cisco in 2001. However, late delivery of Call Manager Version 3
software by Cisco meant a more comprehensive pilot of sophisticated
routing and management options was put on hold. The university
stuck to using the network as transport for voice traffic.
As a means of linking phone calls and of introducing new
telephone extensions to the network in a flexible manner, IP
telephony nonetheless proved to be a good investment. "The cost
advantage was primarily being able to service new users without
continuing investment in a system we had accepted we would
replace," says Furber.
The pilot grew organically to 400 extensions. "If we ran out of
cable on a copper bundle, or a new building was opened, we would go
in with the data network and drop in an IP phone," says Furber.
In 2003, with more mature call manager software available, the
university decided to move to one integrated voice and data network
and to use the infrastructure in place to implement VoIP.
Furber and his team hired IBM for the procurement and
consultancy and the installation. It picked Cisco because of its
existing track record as a technology partner and the major piece
of the VoIP upgrade was to move from layer two to layer three
design.
The later version distributes functionality more widely, and so
local boxes on the network play a bigger part in routing calls.
Read article:
The big bang approach to VoIP migration