The first two chapters provided an overview of the Cisco IP telephony (IPT) solution, a brief introduction to the various components and protocols involved in an IPT network, and a tutorial on the planning, design, implementation, operation, and optimization (PDIOO) methodology to deploy IPT networks. The customer requirements provided in this chapter are used as the basis for the planning activities described in this book.
In this chapter, we consider a large-scale customer named XYZ, Inc., which is pursuing a Cisco IPT solution to replace its existing PBX systems as part of an emerging technology deployment project. The goal of this project is to establish a reliable, manageable, integrated, and scalable IPT solution that meets or exceeds the capabilities of the current voice network that is deployed with the legacy PBX systems.
To achieve this goal as a network engineer, you need to study the existing data, legacy voice network infrastructure and understand the customer’s network requirements for the IPT project. This information will help you to properly design the IPT network and enable the infrastructure to carry the integrated data/voice/video traffic smoothly.
The information presented in this chapter is used in subsequent chapters to guide you through the various tasks in the PDIOO methodology, which can help you to deploy IPT in real-world networks. The idea here is not to discuss complex networks and confuse you with a lot of requirements. Instead, you will build the IPT network for XYZ, Inc. with commonly deployed IPT features and applications. You will be able to use the basic principles and design techniques discussed in this book to customize or add more applications to meet your IPT network requirements.
This chapter also serves as a reference to voice architecture teams that are tasked to write a Request for Proposal (RFP). It gives guidance as to what needs to go into the RFP so that IPT product vendors can respond with their proposed architectures.
Note
The information presented in the “Customer Profile” and “Customer Requirements” sections in this chapter is usually provided by customers in the form of an RFP. If you are a network engineer who is responsible for the IPT network design and you do not have this information, you must collect it prior to starting any tasks described in the PDIOO methodology by meeting with the voice network architecture group in the customer organization.
XYZ, Inc. (hereafter referred to as XYZ) is one of the largest manufacturers of pharmaceutical products in the United States. The company headquarters is located in San Jose, California. The company has grown rapidly and currently has two branch offices in the United States and an international presence in Australia.
The San Jose headquarters location has 1000 employees. Within the United States, the company has two branch sales offices, in Seattle and Dallas. The international headquarters in Sydney, Australia has 500 employees and has two branch sales offices, in Melbourne and Brisbane. Table 3-1 lists the exact number of employees per site.
Table 3-1. Employee Counts for XYZ Offices
Site Name | Number of Users |
|---|---|
San Jose – U.S. Headquarters | 1000 |
Seattle – branch | 50 |
Dallas – branch | 15 |
Sydney – International Headquarters | 500 |
Melbourne – branch | 40 |
Brisbane – branch | 10 |
XYZ is looking for ways to improve its customer service. Its goal is to achieve higher customer satisfaction while reducing operational costs. Because telephone communications is one of the primary ways that XYZ does business with its customers, it has decided that it can achieve its goal by deploying a new IPT system and associated applications.
Figure 3-1 shows the existing data and voice network architecture of XYZ. The voice and data networks are separate and operated independently. The central sites for the XYZ network are San Jose and Sydney. The Seattle and Dallas sites are the remote sites in the U.S. that connect to the San Jose central site. The Melbourne and Brisbane sites are the remote sites in Australia that connect to the Sydney central site. The data traffic from the remote sites traverses across the IP-WAN links to the central sites. A 2-Mbps leased circuit connects the central sites in San Jose and Sydney.
Figure 3-2 depicts the physical LAN architecture at the San Jose and Sydney central sites. The San Jose and Sydney offices have a similar LAN architecture. At XYZ, every desk in the current campuses has a set of two RJ-45 ports for data communications and two RJ-11 ports for connecting telephony devices. With the deployment of IPT, only one of the two RJ-45 ports is required for both data and voice communications.
Note
At XYZ, most of the LAN switches and WAN routers that are deployed are products from Cisco Systems. However, in some building closets, LAN switches from other vendors are also deployed. Hence, you need to consider these exceptions when proposing the IPT solution, because their presence affects how the power to the IP phones is provided and has quality of service (QoS) implications such as marking and prioritizing voice and signaling packets.
Chapter 4, “Planning Phase,” discusses these exceptions and provides recommendations for handling them.
Tip
When you are building new cabling infrastructure for future campuses, you need only one RJ-45 port at every desk for both data and voice communications, eliminating the need for extra cabling infrastructure to support voice communications. However, having a second RJ-45 port and connecting to a different switch or to a different module on the same switch chassis provides physical redundancy.
In Figure 3-2, the access layer Catalyst 6500 switches connect via two Gigabit Ethernet fiber links to two Catalyst 6500 switches in the distribution layer. Two distribution layer Catalyst 6500 switches use the Hot Standby Routing Protocol (HSRP) between them for path redundancy. Each distribution layer Catalyst 6500 switch connects back to the two core layer Catalyst 6500 switches via a routed Gigabit Ethernet link. The core layer Catalyst 6500 switches also connect to WAN routers, which connect to the carrier to provide WAN connectivity.
Figure 3-3 shows the physical LAN and WAN architecture at the remote sites.
As shown in Figure 3-3, the WAN link from each branch site is the WAN link from each branch site is a Frame Relay IP circuit that connects it to the respective central site. Also, the LAN is a switched network. The branch routers are either Cisco 3745 or Cisco 2651 XM routers, and the LAN switches are Cisco 3550 inline power-capable switches.
As shown in Figure 3-1, each site has PBX systems deployed locally. Each site processes its own calls. Failure of the PBX system at any site does not impact other sites.
All the calls that originate from the individual sites are routed via the local PSTN connection. The international calls between the U.S. sites and Australian sites traverse the PSTN and are the major part of the XYZ telecommunications expenditure.
At XYZ, commonly used applications are e-mail, file transfers, web, and some database applications. No real-time application in the network requires traffic prioritization. However, the QoS policies and configurations must ensure that the performance of existing applications does not degrade because of the traffic prioritization that is required for real-time applications.
The XYZ corporate directory architecture is based on Microsoft Active Directory. The messaging environment is based on Microsoft Exchange 2000 on a Windows 2000 Server operating system platform. Users use Microsoft Outlook to retrieve e-mail via Post Office Protocol Version 3 (POP3).
As shown earlier in Figure 3-1, all the locations have PBX systems today. The PBX systems support the following functions:
Call park—. Allows a phone user to “park” a call that is received on their phone, effectively placing the call in a hold state, retrieve the call at another station, and continue the conversation. Another phone user can also retrieve the parked call if notified by the first phone user. This feature provides phone users with mobility and eliminates the need to return calls.
Call transfer—. Allows a phone user to transfer the call received on their phone to another phone user within the system or transfer the call to an external phone user. This feature eliminates the need for the calling party to hang up and dial another number to reach the desired party.
Call pickup—. Allows a phone user to retrieve and answer a call ringing at another phone, or on any other phone in the phone user’s assigned call-pickup group (call pickup). The phone user can also pick up the call that is ringing on another phone that is part of another call-pickup group (group pickup). The phone user dials a preconfigured call-pickup number to take the call.
Call back—. Notifies a phone user of the availability of a previously called user phone if that user did not answer the call previously. The phone user who invokes this feature gets an audible or visual notification informing them of the availability of the other phone user.
Ad hoc conferencing—. Allows a phone user to add a third user to the existing conversation, effectively making the call a conference call.
Class of Restrictions (CoR)—. Allows you to assign calling privileges on a per-phone basis based on the location of the phone or the type of user. For example, you can configure a lobby phone to prevent someone from making long-distance or international calls.
Speed dialing—. Allows a phone user to program the buttons on their phone with frequently dialed numbers. The phone user can call the number by pressing the button instead of dialing the whole number.
Music on Hold—. Provides a phone user with announcements while their call is placed on hold.
Call forwarding—. Allows a phone user to forward calls received on their phone to another phone within the system or to an external phone number. The following functionalities are supported:
—Call Forward All (CFwdAll)—. Forward all calls to a programmed destination number
—Call Forward Busy (CFB)—. Forward the calls to another number to a voice-mail system if the user phone is engaged in another conversation
—Call Forward No Answer (CFNA)—. Forward calls to another number within the system or external to the system if the phone user does not answer the call at their phone
Display call history—. Allows a phone user to view the missed calls, previously dialed numbers, and received calls on their phone and to dial the numbers without entering the digits manually.
Call waiting—. Provides a visual notification or alert mechanism to the phone user to inform them of other incoming calls arriving at their phone while they are engaged in a conversation on the same line.
Site-specific Automated Attendant functionality—. Allows external callers when they dial the branch main number to search the phone directory based on the user’s extension number or by their first or last name.
Call Detailed Recording (CDR)—. Stores the information about incoming/outgoing calls received or dialed by every phone user in the system. This information is useful in generating department-wide billing reports or doing a study of the calling patterns in the organization.
XYZ’s voice-mail systems are currently completely separate from the e-mail environment. The existing voice-mail systems support the following features:
Message Waiting Indication (MWI)—. Provides a user with a visual or audible notification on the phone that new voice mails are waiting in the mailbox.
Message notifications—. Allows a user to configure the settings on their mailbox to notify them via e-mail, pager, or cell phone whenever they get new voice mails.
Alternate greetings—. Allows a user to set up different greetings to inform the calling party that the user is on an extended absence or is out of the office temporarily.
Directory service—. Allows an external/internal user to search the company’s phone directory by using the extension number or by entering the first or last name of the user.
Group mailboxes or distribution lists—. Allows voice-mail users to be grouped so that a voice message sent to such a group is distributed to all users in that group. This feature allows executives or management to send out voice messages to the entire company staff or to a group of people about company events.
Storage—. Approximately 20 minutes of storage is available per user mailbox.
Remote voice-mail access—. Access to voice mail from remote locations is available via the Telephony User Interface (TUI).
The proposed IPT solution should support at minimum all of the preceding functionalities and features that exist in the current PBX and voice-mail systems.
This section lists the XYZ IPT network requirements. As mentioned at the beginning of this chapter, customers usually provide this information in the RFP.
While reviewing the existing voice network infrastructure, system administrators at XYZ have identified the following limitations in the current system:
Because of the multivendor PBX systems that exist in the network and the use of nonstandard, propriety signaling mechanisms and interfaces on the PBX systems, XYZ cannot interconnect the PBX systems to save the communications costs on the interoffice calls.
Some PBX systems and key systems are old and lack the functionality and the call features required.
Nonavailability of empty slots on the PBX systems is preventing the expansion plans.
Because the equipment is old, cost of replacement parts is high.
Costs incurred in maintaining the PBX and voice-mail systems by external vendors have increased substantially over the years, resulting in more recurring expenditures.
Coordinating with external vendors to implement the changes or additions is causing an extra delay and impacting negatively on the company productivity figures.
Moves, adds, and changes cost $200 to $250 every time a staff member relocates to a new office. This cost is for the PBX engineer to reprogram the PBX systems and the cable contractor to install the new connection. This whole process sometimes takes up to two business days for completion, which impacts overall company productivity.
These system limitations and extra costs have forced the administrators of XYZ to consider the migration to IPT solutions. The following sections provide the minimum requirements for the proposed IPT network.
XYZ has been expanding its operations rapidly because of growing demand for its products. To protect the investments made and to achieve quicker expansion, XYZ requires a scalable call-processing system that
Requires minimal redesign in case of an expansion.
Optimizes bandwidth utilization on the WAN links for voice traffic.
Supports keeping the call control at the central sites and providing local call processing capability on the WAN routers at the branch sites during WAN link failure.
At XYZ, the IP phones can be categorized as follows:
Employee phones
Assistant/secretary phones
Conference/meeting room phones
Lobby/break room phones
The employee and assistant/secretary phones must support headsets. Assistant/secretary phones usually have multiple lines. The phones and headsets are required to work with hearing-impaired users. High-quality conference phones are required in meeting rooms for conference calls. Lobby/break room phones do not require; PC connectivity from the phones.
The phones must obtain power from the wiring closet switches and, if required, must work with other vendors’ networking equipment by taking advantage of interoperable standards.
All the sites currently have either PBX systems or key systems. These systems are not interconnected. A phased migration to the new IPT system is required for the San Jose site because of the large user presence. The PBX system at the San Jose site requires integration with the new IPT system. At all other locations, the PBX lease periods are ending; hence, IPT systems can replace legacy PBX systems.
There are two Avaya Octel voice-mail systems, one each at San Jose and Sydney. The Octel system at San Jose has mailboxes for all the employees in the United States. Similarly, the mailboxes for all the users in Australia reside on the Octel system in Sydney.
As a part of the new technology deployment, XYZ would like to deploy a new voice-mail system that supports unified messaging. The proposed voice-mail system architecture should have high availability and redundancy. The proposed voice-mail system should be able to leverage the already deployed messaging infrastructure.
In the initial deployment, the international office (Sydney, Melbourne, and Brisbane) users’ mailboxes are migrated from the Octel system to the new voice-mail system. The Octel voice-mail system at the San Jose Headquarters site will continue to exist.
The new proposed voice-mail system at Sydney must be integrated with the existing Octel voice-mail system at the San Jose central site. The networking of the Octel and new voice-mail systems is a requirement to route voice mails between the two systems.
Every location requires a voice gateway to connect to the local PSTN and must support T1/E1 PRI trunks. Each site routes local calls via a PSTN connection that is terminated on the local gateway.
The remote branch gateways should provide call-processing functionality to the connected devices in case of WAN link failure. The IP phones that are attached to the local voice gateways should use the local conferencing resources as a first preference and the central site conferencing resources as a secondary choice.
XYZ wants to deploy Fax over IP across its entire network. Hence, voice gateways must support analog ports to connect the fax machines.
XYZ requires good voice quality with its IPT network. Integrated voice and data networks require an intelligent network infrastructure that can properly interpret the QoS markings set by the IPT endpoints.
The XYZ network does not have QoS enabled currently. The XYZ network requires the following:
The endpoints that can mark real-time frames and packets for QoS
The infrastructure that can give preference to the marked frames
Despite the low cost of national long-distance service charges within the United States, to save costs on the calls made between the offices within the United States, XYZ would like to use the IP-WAN for routing voice calls. The following are the requirements of call routing in the new IPT system:
Calls should be routed via IP-WAN as the first choice, where available, and then via PSTN trunks if bandwidth is not available or a WAN link has failed.
Within the site, users should use four digits to dial other extensions. Site-to-site dialing also should use four digits.
Tail-End Hop-Off (TEHO) is enabled where legally allowed and bandwidth permits. Transporting voice calls across the existing WAN links requires additional bandwidth. Hence, the proposed IPT system must clearly specify the amount of additional bandwidth required in such cases and provide an optimized solution to conserve it.
Note
In certain countries, transporting the voice call across the IP WAN links to another location before terminating the call on a PSTN is illegal.
The remote sites in each global region must use the local gateways to route the local calls and use the gateways at the central sites as an alternative if the local PSTN connection is not available.
A mechanism must be included to control the number of calls that traverse the IP-WAN considering the traffic utilization on the WAN links.
Classes of restrictions must be provided based on the phone type (e.g., a lobby phone versus an employee phone).
For the initial deployment, branch sites will have a single PRI or multiple PRI circuits where needed. The IPT system must be flexible enough to make new changes and must be easy to troubleshoot.
All small branch sites have direct connectivity to the PSTN, and the billing number is associated with the street address of each branch site. All the emergency calls need to be routed via the PSTN connections from the branch sites. This avoids the emergency service calls being accidentally routed via the TEHO and connecting to an incorrect public safety answering point (PSAP). All the remote sites have a single T1/E1 PRI connectivity to the PSTN. Where possible, you should provide backup circuits to route the emergency calls if the T1/E1 PRI links are unavailable.
Within the United States, the IPT system must comply with Federal Communications Commission Enhanced 911 (E911) regulations. For more information on E911, go to http://www.fcc.gov/911/enhanced/.
Note
To determine if a particular state’s law requires businesses to comply with E911, go to the following website:
http://www.nena9-1-1.org/9-1-1TechStandards/state.htm
Based on this website, the three states in which the U.S. locations reside—California, Texas, and Washington—do not require businesses to comply with E911.
There are currently no requirements for E911-equivalent functionality in Australia.
The “Customer Requirements” section, earlier in this chapter, mentioned the limitations of the current voice network infrastructure at XYZ. The management staff of XYZ is looking for an IPT solution that can remove those limitations and provide the following additional features and applications that were not possible with the legacy infrastructure:
Attendant Console—. Provides a centralized attendant operator for each site that has a web-based GUI that can be used to answer the incoming calls and direct them to the right user within the company.
Manager/Assistant (Boss/Secretary) Feature—. Allows assistants to receive/transfer calls received for managers. Managers can designate more than one assistant to handle their calls.
IP phone services—. The following services should be provided:
—Corporate directory lookup from IP phones
A corporate directory lookup application allows IP phone users to search against the XYZ corporate Active Directory for a user’s phone number. Applications of this type improve employee productivity.
—Calendar and other useful services
Multiple line appearances—. Provides more than one line appearance on the phone and is especially useful for call center agents who need one line that is specifically used for handling incoming customer support calls and another line for making other calls.
Mobility—. Some users at XYZ frequently travel between the sites, and XYZ company policy encourages telecommuters. The IPT system should enable such users to log in from any phone and personalize the phone with their extension number, speed dials, and other settings. This allows the users to work from any phone and still receive the calls as if they were at their desk phone.
Help desk support for 25 agents—. XYZ requires the IPT application that provides Automated Call Distribution (ACD), wherein the external/internal callers are directed to the right skill group agent to handle the customer support calls for the following two groups:
—Internal IT help desk group
—Customer support group
IP SoftPhone support for mobile users—. A SoftPhone is an application that is installed on a user’s computer/laptop and emulates the real IP phone. This type of application is especially useful for mobile users because they can carry the phone with them.
Conferencing support—. Currently, XYZ uses an external provider to provide the conference bridge services. With the deployment of IPT, XYZ wants to deploy self-manageable conferencing resources that can support up to ten participants per conference call and that enables conference calls to be scheduled and managed via a web-based GUI.
With the integration of voice and data solutions, the call-processing servers and the telephony endpoints—such as gateways, media resource devices, and IP phones—will be part of the data network. Security plays a critical role in achieving the high availability of the IPT networks. XYZ has the following basic security requirements:
Multiple administration levels for the administrative and operations staff to configure the call-processing servers
Intrusion detection system
Antivirus software support
Logging of user login attempts and configuration changes
Secure call-processing and application servers through the use of firewalls
XYZ requires this solution to provide redundancy and fault tolerance at every level. A failure of a server, gateway, gatekeeper, switch, or any other critical resource should not affect end users. The failure must be transparent to end users.
The IPT solution should provide 99.999 percent uptime for all the IPT devices and infrastructure.
XYZ has a global network operations center (NOC) located in San Jose that monitors all the existing networking devices. XYZ is looking for a complete network management solution to monitor the IPT components covering all the following aspects:
Fault management
Configuration management
Accounting
Performance management
Security management
Change management
ROI analysis takes into account cost of technology ownership and the strategic value of the IT initiative. For effective maximization of ROI, you need to understand how your overall cost of network ownership (voice, video, and data) will be lower in a converged environment. You have to compare the cost of implementing a converged environment to the cost of having a separate voice, video, and data network infrastructure, which includes expenses for separate IT groups for voice, video, and data networks; license renewal fees for your legacy voice systems; expenses for moves, adds, and changes; and other overhead.
According to a study conducted by Sage Research, Inc. for Cisco Systems (to download the “Sage IPT Productivity Study” presentation, go to http://www.cisco.com/partner/cnic/presentations.shtml), 75 percent of the survey respondents believed that cost savings is the main reason to move to a converged network, whereas 65 percent feel that employee productivity gains is the key driver motivating companies to deploy IPT.
XYZ, similar to other companies, is looking to save costs and at the same time recognizes the potential for a converged network to improve employee productivity, enable new application capabilities, and potentially drive revenues.
Tip
A detailed white paper, “The Strategic and Financial Justification for IP Communications,” is available to provide senior network engineers and managers with the factual support to justify a strategic and financial decision to invest in a converged voice, video, and data network.
This white paper is available for download from http://www.cisco.com/partner/cnic/roi.pdf.
This chapter provided the requirements of the customer XYZ that will be used in the upcoming chapters to build the IPT network based on the PDIOO approach.
Because it is impossible to cover every case scenario in this book, as mentioned at the beginning of this chapter, the requirements set for XYZ in this chapter are similar to what you commonly see in the majority of the IPT networks that exist today or in the networks that are transitioning to IPT. We feel confident that either you will find all the major requirements of your customer in the scenarios described in this book, or you will meet your customer requirements by slightly modifying the scenarios described in this book.
Chapter 4 discusses the planning phase of the PDIOO model. The goal of the planning phase is to identify the gaps in the existing network infrastructure and provide recommendations and best practices to make the infrastructure scalable and highly available to support the converged data and voice traffic. At the end of the planning phase, you should have a list of equipment required at each site, site-specific QoS policies, WAN bandwidth requirements, and dial plan requirements.