- Getting Started
- Network Infrastructure Analysis
- Telecom Infrastructure Analysis
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
Telecom Infrastructure Analysis
This section examines the XYZ telecom infrastructure. The Telecom Infrastructure Analysis Questionnaire, included in Appendix C, assists you in conducting this analysis. You need to conduct this analysis to understand how the current telecom infrastructure is built and how it operates. Based on this information, you can design the IPT network so that it operates in a similar way, and at the same time introduce new features and services. The information presented in this section uses answers that XYZ provided to the questions in the questionnaire.
PBX Infrastructure and Migration
XYZ requires replacement of the PBX systems at all the remote branch locations and at the Sydney HQ location, except at the San Jose location, as mentioned in Chapter 3.
The PBX at the San Jose site requires integration with the new IPT system. Table 4-7 provides the details of the PBX systems at the San Jose and Sydney locations. This information helps you to determine what types of gateways are required to achieve the integration, what features in CallManager need to be enabled, etc.
Table 4-7 Details of XYZ PBX Systems
|
Site |
PBX Vendor Model Software Version |
PSTN Interface Signaling |
Interface Type to IPT System |
Number of T1 Trunks to PSTN |
|
San Jose |
Lucent/Avaya Definity G3Si Version 10 |
T1-PRI NI 2 |
T1-QSIG |
6 |
|
Sydney |
Lucent/Avaya Definity G3Si Version 10 |
E1-PRI NET5 |
E1-QSIG |
4 |
The large user presence at the San Jose site prevents a complete forklift of the PBX system. Hence, a slow migration is required at this site. A discussion with the PBX staff at San Jose proposed the solution described next for smooth migration of users to the IPT system.
As shown in Table 4-7, the San Jose site has six T1 trunks. At the beginning of the IPT deployment in the San Jose site, only four of the T1 trunks that are currently terminating on the PBX will be moved to voice gateways in the IPT system. In Sydney, you need to plan a complete migration to IPT. All users will retain their old PBX extensions after the migration to the new IPT system. When a user moves to the IPT system, the legacy PBX is configured to forward the calls to their IP phone.
At the end of the complete migration of users to the IPT system, all the remaining T1/E1 trunks will be moved to voice gateways. At this point, the legacy PBX systems might be removed.
Telephony Numbering Plan
XYZ uses a four-digit dial plan at every central and remote branch location. After the migration to IPT, each user will retain their old extension number on the new IP phones. At all sites, the carrier sends all the digits to the PBX. PBX retains only the last four digits to extend the call to the end station.
Table 4-8 provides information on the PSTN trunk types, Direct Inward Dial (DID) numbering ranges, and numbering plan for each site of XYZ.
Table 4-8 Current Numbering Plan at XYZ
|
Site Name |
DID Range |
Station Directory Range |
Type of PSTN Signaling |
|
San Jose |
+1 408 555 3000 to +1 408 555 4999 |
IP Phone DNs 3000–4999 |
6 T1 PRI NI2 |
|
|
+1 408 555 2500 to +1 408 555 2999 |
PBX station DNs 2500–2999 |
|
|
Seattle |
+1 206 555 2100 to +1 206 555 2199 |
2100–2199 |
1 T1-PRI |
|
Dallas |
+1 972 555 5600 (grouped line) +1 972 555 5611 (fax) |
5601–5619 (Non-DID numbers, private numbering plan) |
1 T1-PRI |
|
Sydney |
+61 2 5555 6000 to +61 2 5555 6999 |
6000–6999 |
4 E1 PRI ISDN Net 5 |
|
Melbourne |
+61 3 5555 4300 to +61 3 5555 4399 |
4300–4399 |
1 E1 PRI ISDN Net 5 |
|
Brisbane |
+61 7 5555 8680 (grouped line) |
8681–8699 (Non-DID numbers, private numbering plan) |
1 E1 PRI ISDN Net 5 |
Voice-Mail Infrastructure and Migration
From the initial requirements given in Chapter 3, XYZ has two voice-mail systems: one at San Jose and the other at Sydney. The Simplified Message Desk Interface (SMDI) integration method integrates the Octel voice-mail system with the PBX systems. The deployment of IPT enables migration of user mailboxes from Octel systems to the Cisco Unity system in a phased manner. As per the XYZ requirements, discussed in Chapter 3, in the "Integration and Replacement of Legacy Voice-mail Systems" section, Cisco Unity will be deployed in Sydney with the unified messaging mode in redundant fashion and the Octel voice mail systems in San Jose will continue to exist.
During the migration, XYZ requires all the users to be able to send and receive between the Octel voice-mail system in San Jose and the Cisco Unity system in Sydney. This requires networking of Cisco Unity and Octel voice-mail systems. The Cisco Unity Bridge application provides intermessaging between Cisco Unity and Octel voice-mail systems.
Emergency Services
Today, XYZ uses basic 911 service, in which calls are forwarded to a public safety answering point (PSAP). There is no guarantee that the call reaches the correct PSAP, and the PSAP does not get information about the location of the caller.
The Enhanced 911 (E911) solution, an advanced version of basic 911 services in North America, addresses the user mobility issue and provides the following benefits:
Automatically provides the location of the caller to the PSAP
Calls reach the right PSAP based on the user location
Cisco Emergency Responder (CER) tracks user movements and sends the user's current location information to the PSAP. CallManager provides the basic functionality required to route the emergency calls.
The XYZ branch offices are located in Seattle, Washington, and Dallas, Texas. As discussed in Chapter 1, in the "Cisco Emergency Responder" section, these two states do not require businesses to comply with E911 (as of the time of writing the design proposal). Hence, you do not need to design the IPT network with CER.
Telephony Features and Applications
The current PBX systems at the San Jose and Sydney central sites support basic functions, such as call forwarding, call transfer, call conferencing, and the following applications:
Auto-Attendant
An internal help desk support group with 10 agents supporting internal IT issues of XYZ
An external help desk support group with 40 agents supporting XYZ product issues
XYZ requires the future IPT network to migrate all the legacy applications to the IPT system. In addition, XYZ would like to implement the following functionality in the newly built IPT system:
IP phone services
Corporate directory lookup from IP phones
Calendar and other useful services
Extension Mobility feature for mobile users
Cisco IP SoftPhone support for a few users
Business Continuity and Disaster Recovery
Before you deploy any new product or system in the network, it is important to understand not only the potential underlying risks and impact of disasters, but also how to quickly recover from such situations and document these procedures by developing a business-continuity or disaster recovery plan.
In legacy voice networks, the central component of call processing are the PBX/key systems. A PBX system comes with dual process cards so that a failure of one card does not affect business operations. In a similar way, the Cisco IPT system offers grouping of CallManager servers to form a CallManager cluster. A cluster offers high availability. A failure of a single server in the cluster does not impact the call processing.
An organization that is looking for a high level of business continuity in case of any disaster should consider splitting a single CallManager between multiple data centers. Refer to the "Clustering over the IP WAN" section in Chapter 1 to understand this design and recommended best practices.
The second factor that affects business continuity is the availability of the backup power, as discussed earlier in this chapter in the "Power and Environmental Infrastructure" section.
You need to include the IPT systems as part of your backup operations and protect the systems from viruses and other security attacks by installing antivirus tools.
Securing IPT Infrastructure
The Internet has made it easy for anyone to access different denial of service (DoS) tools, viruses, and applications that are used for financial fraud, theft of information, and sabotaging data or networks. Usually, someone writes an application and puts it on the Internet, available for everyone to grab.
Many tools are easily available on the Internet to attack networks. These include, among many others, tools to carry out DoS attacks, VLAN attacks, Address Resolution Protocol (ARP) attacks, MAC attacks, and spanning tree attacks. If you are deploying real-time applications into your data networks, you need to make sure that security breaches are prevented. These security breaches can slow down or bring down the network, causing the network to be unable to support voice calls. You need to make sure that your internal and external network is not misused in any way. For example, if someone tries to introduce large amounts of traffic across your WAN link, it results in dropped voice calls. This is a potential case of DoS attack and, in this situation, having the right set of QoS policies and CAC in place prevents the excessive traffic and avoids the call drops.
Deciding which security measures to implement requires that you balance how much risk you are willing to accept and how much money you are ready to spend to protect your network against security breaches.
Regardless of your decision, you have to make sure that your network is built following a layered approach and you have taken the necessary measures to secure it at every layer. This means that compromised security at any one layer does not compromise security at every layer. For example, if someone is able to break the password and get into one of the VLANs, IP phones, CallManager, or any other network component, they should not be able to get into the whole network. PC endpoints usually require user authentication, but typically IP phones do not. You have to realize that if you want to build a secure IPT network, you have to build it on a secure data network. If your data network is not built securely, you will not be able to build a secure IPT network.
Remember that now your voice is traveling over your existing data network. Some of the simple steps to provide security include having separate voice and data VLANs, using access control lists (ACLs), and using firewalls.
Chapter 6 provides security recommendations to protect the XYZ IPT infrastructure.
Redundancy and High Availability
The key component of network design is redundancy. Redundancy not only prevents equipment failures from causing service outages, but it also provides a means for performing maintenance activities such as upgrades without impacting the service.
The predominant factor that determines the effectiveness of a redundancy scheme is the switchover coverage, defined as the probability of a successful switchover to the standby side whenever needed. Switchover coverage of 0.9 indicates that, on average, when a switchover is required, nine out of ten incidents will be successful. The chart in Figure 4-17 illustrates the impact of switchover coverage on the downtime of a system.
)
Figure 4-17 Impact of Switchover Coverage
Switchover coverage of 0 is equivalent to a simplex (nonredundant) system, thus rendering the redundancy setup completely ineffective. Switchover coverage of 1 represents an ideal redundancy setup; it reduces the downtime of a simplex system by about four orders of magnitude. Although it is difficult to achieve perfect coverage, a good redundancy design can achieve coverage of 0.99, which offers a downtime improvement over a simplex system by about two orders of magnitude.
Availability refers to the percentage of total time that a network or system is available for use. A network or system that has high availability includes specific design elements that are intended to keep the availability above a high threshold (for example, 99.999 percent).
XYZ requires the highest level of availability at every layer and component of the network. The following is a list of a few design principles to achieve high availability:
Maximize the redundancy—Maximizing the redundancy allows you to provide uninterruptible service to the end users. An example is a CallManager cluster, which contains more than one server and provides call-processing redundancy. Another example is the XYZ LAN infrastructure, which has two distribution layer switches and two core layer switches to provide redundancy.
Minimize complexity—Reducing complexity minimizes the time to rectify problems, thereby increasing the overall availability of the system or device.
Minimize points of single failure—Minimizing single points of failure increases the redundancy in the network. An example is a connection to the PSTN. If you have only a single T1/E1 circuit that, for some reason, goes down, no one from that location can make outbound calls. Hence, you should plan for redundant circuits to minimize these types of single points of failure.
As you have seen in the infrastructure analysis, XYZ has a high level of availability and redundancy in its current infrastructure. Chapter 6 provides recommendations to achieve the same level of high availability and redundancy for the IPT infrastructure of XYZ.
IPT Network Management System
Each IPT deployment is different, but generally, a Cisco AVVID IPT environment includes a CallManager cluster, IP phones, a PSTN gateway(s), a voice-mail system (Cisco Unity and/or a legacy voice-mail system), L2/L3 switches, routers, and applications such as Automated Attendant, Personal Attendant, Emergency Responder, CCC, CRS, and others.
While you are planning for management and monitoring of an IPT network, the main goal should be to define a list of parameters that can be proactively monitored in an IPT environment. The output of these predefined parameters is intended to establish a set of alarms for spontaneous problems and a proactive early-warning system that is based on comparing baseline data to current conditions.
The following two steps help you to define a solid management and monitoring policy for your IPT network:
Define a set of parameters that needs to be monitored on every component of your IPT network.
Select IPT network management and monitoring products and tools that are capable of monitoring the defined set of parameters.
Several products and tools are available to manage and monitor your IPT network. The CiscoWorks IP Telephony Environment Monitor (ITEM) product gives real-time, detailed fault analysis specifically designed for Cisco IPT networks and other products from third-party vendors. It is a proactive tool to evaluate the health of IPT implementations. Cisco ITEM provides alerting and notification of problems and areas that you should address to help minimize IPT service interruption. Cisco ITEM also identifies the underutilized or imbalanced gateway resources, whereas its historical trending and forecasting of future capacity requirements helps you to plan for growth.
Given the type of IPT infrastructure, CallManager server health, CallManager services health, CallManager functionality, IP phones functionality, IP gateway health, QoS monitoring, L2/L3 switches, and applications are some components that we recommended for monitoring your IPT network.
XYZ requires proper network management tools to monitor its IPT infrastructure. Chapter 9, "Operations and Optimization," discusses in detail the parameters, tools, and techniques for managing and monitoring IPT networks.