Nathan Prisk and Chris Whitwood
University College Falmouth

Abstract

IP telephony is what is generally meant when traditional telephony is replaced with IP technologies – such as Voice over IP (VoIP) – within an enterprise or campus network. This briefing document provides an insight into the decisions behind and outcomes of deploying a VoIP system on a new campus site.

Introduction

For many years large organisations have been using their structured cabling systems to move voice data from the central telephony switch to each individual handset. This requires as a minimum a single wire from the main telephone system to the handset, and at best a single cable broken by some sort of compression device to allow many calls to be converged down a copper or fibre cable and then split back to multiple copper cables closer to the handset.

Over the last five years there has been a massive growth in network access to desktop computers, with the move from dumb terminal access to LAN-to-desktop requirements, but what has not happened until very recently is a comparative growth of voice traffic over the same network. This document hopes to answer some questions and provide others that will be useful to organisations contemplating such an upgrade.

Why was VoIP Chosen Over Traditional Telephony?

At University College Falmouth decisions were related to the delivery of a new network and telephony service to the new CUC (Combined Universities in Cornwall) campus. We knew that we had to deploy approximately 1000 handsets, with over 500 handsets in halls of residence and the remainder in three old listed buildings and one new very large building. The new building contained 10 comms rooms from which the network would be distributed. We had very high levels of skills in our networking team but relied heavily on a support contract for our old PBX (Private Branch Exchange) telephony system. We saw a potential saving if we could provide the majority of telephony support from within our existing network team. We were also excited by the potential of deploying a telephony system which had a ‘plug-and-play’ approach to adds/moves and changes, but although this was offered within the advertising literature it was a long way from the initial completed project.

Once the deployment had begun it became clear that automated port configuration was not achievable with the configuration of the network and the lack of PoE (Power over Ethernet) ports. However, with hindsight this issue could have been easily avoided if every Ethernet port on the network had the ability to be powered from Day 1: this would have resolved any plug-and-play issues.

Another reason for moving the telephony infrastructure to VoIP was the savings made by not maintaining the old PBX system. The majority of hardware is already covered under existing network maintenance and the remaining items, such as the call management servers, are relatively inexpensive devices to maintain and therefore have a low maintenance cost.

So to sum up our reasons for moving to VoIP:

1. We had no spare capacity in our existing PBX.
2. We needed to deploy 1000 handsets over multiple locations.
3. We wanted to provide in-house management.
4. We were deploying a brand new network.
5. We were looking for flexibility.
6. We wanted to save costs.

Selection of Architecture and Vendor

We came to the VoIP project already knowing that we were deploying a new state of the art campus network and this influenced our decisions accordingly. At first we examined all the potential solutions from a distance, i.e. not involving suppliers or sales people. This gave us the freedom to reject suppliers that did not meet our initial requirements.

We then chose to trial a small number of VoIP handsets to ensure that we could communicate effectively with our existing PBX. This allowed us to evaluate the potential of VoIP without a potential loss of communication or the massive projects costs associated with a full campus-wide replacement project. We chose not to involve schools or departments in our decisions but followed an existing features requirement exercise which looked at what the users currently did or believed they were doing. The results of this exercise should be considered by organisations ready to deploy any telephony refresh, because we found that over 95% of users only need to be able to dial an outside line and receive an incoming call, or to have that called forwarded to voicemail. These findings are echoed elsewhere.

We involved our existing telephony manager, who was connected to the Estates department, to ensure a smooth handover and to ensure a seamless delivery to all new and existing users.

We were confronted with two differing views on architecture:

1. a centrally provided VoIP switch that utilised existing network equipment for distribution, or
2.  a gatekeeper/gateway solution requiring extra VoIP switches deployed and managed within localised comms rooms, and usually away from the centre.

In our selection process we were mindful of the potential ways in which we might enhance the existing provision without necessitating further expenditure on staff time or budget. Therefore we were looking for a system that could be managed within our existing network team but that mimicked existing provision.

Packet Filters and Firewalls

Clustering internal Call Managers with a Call Manager outside our firewall requires the creation of a hole in the firewall for a single host, and limited access to ports associated with the H.323 set of protocols. The ultimate goal of this type of deployment is to limit access to the voice network from outside an organisation to the smallest number of hosts possible.

Capacity Planning

When we deployed our first phase of VoIP, we decided to use the G.711 codec for our calls, which equates roughly to a 100kbit/s stream over the network for each VoIP device. From this we were able to calculate the bandwidth requirements for our comms areas based on an average number of calls. As our slowest link was 100Mbit/s and we were installing approximately 300 VoIP devices, this clearly showed that capacity was not an issue.

Currently there seems to be a trend towards the integrated service model where bandwidth is reserved at every hop along the route of a call prior to the call being established. We opted for the more flexible differentiated services model which allows us to prioritise voice traffic through our network. It is worth noting that congestion management mechanisms will not have any effect on voice traffic. Only congestion avoidance mechanisms will have any impact on the voice traffic, due to the connectionless nature of RTP (Real-time Transport Protocol: the protocol for transporting real-time data, including audio and video).

However, as we learnt to our cost, QoS should not be relied on as the ‘Holy Grail’ of VoIP. The biggest problem that we encountered with our VoIP deployment came from broadcasts. The issue was not with network devices; our switches/routers had no problem forwarding all of these very small broadcast packets. It was the handsets that seemed to have difficulty processing audio through a codec and listening to a large number of ARPs (Address Resolution Protocol) at the same time. This was resolved by segmenting the voice network into a number of broadcast domains.

Pros and Cons and Things to Think About

Was there anything we would have done differently? From a purely technical perspective I believe not, but as highlighted above we had the luxury of deploying a whole new network and VoIP system from a single supplier. If our situation was different and we only had the option to deploy voice on an existing infrastructure then I believe a different approach would be warranted. It would include a full network analysis report to ensure the underlying infrastructure was capable of supporting the deployment but also of supporting future growth for both data and voice. We would need to be mindful that video is a bandwidth-hungry resource and we are seeing a growth in convergence issues with CCTV, voice and access control all vying for this precious bandwidth and quality of service.

It is necessary to find out from the manufacturer what features are available on what handsets. You may find that some features require more expensive phone handsets than anticipated, or that to obtain an essential feature necessitates the installation of a particular software application on the user’s computer.

Conclusion

Although the first two years of the VoIP project were taken up with the installation of a basic IP-based replacement for a traditional PBX system, we can now move the project into a new phase where resolution of technical issues has been replaced with development. These developments, including XML applications and the ability to display differing data sets from a database for moving images, are what differentiates a traditional PBX from a VoIP system.

Do I believe we have installed the right technology? Yes, without a doubt. We now have a stable platform from which to enhance voice delivery within our organisation and we will be looking for opportunities to explore new features.