Cisco IP Telephony Network Design Guide Cisco CallManager Release 3.0(5) Corporate Headquarters Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 USA http://www.cisco.
THE SPECIFICATIONS AND INFORMATION REGARDING THE PRODUCTS IN THIS MANUAL ARE SUBJECT TO CHANGE WITHOUT NOTICE. ALL STATEMENTS, INFORMATION, AND RECOMMENDATIONS IN THIS MANUAL ARE BELIEVED TO BE ACCURATE BUT ARE PRESENTED WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED. USERS MUST TAKE FULL RESPONSIBILITY FOR THEIR APPLICATION OF ANY PRODUCTS.
C O N T E N T S Preface xi Purpose xi Audience xii Organization xii Revision History xiv Conventions xv Additional Information xvii Obtaining Documentation xviii World Wide Web xviii Documentation CD-ROM xviii Ordering Documentation xviii Documentation Feedback xix Obtaining Technical Assistance xix Cisco.
Contents Multisite IP WAN with Distributed Call Processing 1-7 Multisite IP WAN with Centralized Call Processing 1-10 CHAPTER 2 Campus Infrastructure Considerations 2-1 Overview 2-2 Power Protection Strategies 2-4 Network Infrastructure 2-5 High Availability 2-7 Physical Connectivity Options 2-9 Power to IP Phones 2-10 Inline Power 2-10 Establishing Power to the IP Phone 2-12 Inline Power Configuration 2-13 Other Inline Power Considerations 2-15 External Patch Panel Power 2-17 Wall Power 2-20 Summary of
Contents Quality of Service 2-28 Traffic Classification Types 2-28 Trust Boundaries 2-29 Traffic Classification at Layer 2 2-30 Traffic Classification at Layer 3 2-34 Layer 3 Traffic Classification on the Cisco Catalyst 6000 2-34 Summary of Capabilities and Recommendations 2-36 CHAPTER 3 Cisco CallManager Clusters 3-1 Cluster Operation and Scalability Guidelines 3-1 Device Weights 3-3 Intracluster Communication 3-5 Cisco CallManager Redundancy 3-6 Redundancy Group Configurations 3-6 Device Pool Configur
Contents CHAPTER 4 Gateway Selection 4-1 Supported Protocols 4-2 DTMF Relay 4-3 Skinny Gateways 4-4 Cisco IOS H.323 Gateways 4-4 MGCP Gateway 4-4 Cisco CallManager Redundancy 4-5 Skinny Gateways 4-5 IOS H.323 Gateways 4-5 MGCP Gateway 4-6 Supplementary Services 4-7 Skinny Gateways 4-7 IOS H.
Contents Configuring Dial Plan Groups and Calling Restrictions 5-14 Partitions 5-15 Calling Search Space 5-15 Dial Plan Guidelines and Configuration 5-18 Campus and Individual Site Dial Plans 5-19 Multi-Site WAN Dial Plans 5-21 The Role of a Gatekeeper 5-21 CHAPTER 6 Multisite WAN with Distributed Call Processing 6-1 Distributed Call Processing Model 6-1 Call Admission Control 6-3 Operational Model 6-8 Gatekeeper Configuration 6-9 Cisco CallManager Configuration 6-10 Interaction Between Cisco CallManage
Contents CHAPTER 7 Multisite WAN with Centralized Call Processing 7-1 Centralized Call Processing Model 7-1 Call Admission Control 7-3 Caveats for Locations-Based Call Admission Control 7-4 Dial Plan Considerations 7-5 Interlocation Calls 7-5 Intercluster Calls 7-6 Local PSTN Calls 7-6 Design Example 7-6 Cisco CallManager Cluster Considerations 7-8 DSP Resource Provisioning for Transcoding and Conferencing 7-10 Voice Messaging Considerations 7-12 CHAPTER 8 Quality of Service 8-1 Campus QoS Model 8-1 T
Contents CHAPTER 9 Catalyst DSP Provisioning 9-1 Understanding the Catalyst DSP Resources 9-2 Catalyst Conferencing Services 9-4 Conferencing Design Details 9-4 Conferencing Caveats 9-6 Catalyst MTP Transcoding Services 9-7 MTP Transcoding Design Details 9-7 IP-to-IP Packet Transcoding and Voice Compression 9-7 Voice Compression, IP-to-IP Packet Transcoding, and Conferencing 9-9 IP-to-IP Packet Transcoding Across Intercluster Trunks 9-10 MTP Transcoding Caveats 9-12 Catalyst 4000 Voice Services 9-13 Cata
Contents Can I Just Use SMDI? 10-21 What If I Cannot Use SMDI? 10-22 Choosing an Integration Mode 10-22 Using the Simple Integration Mode 10-23 Using the Hybrid Integration Mode 10-24 Using the Multiple Integration Mode 10-25 CHAPTER 11 Network Management 11-1 Remote Serviceability for Cisco CallManager 11-1 SNMP Instrumentation on the Cisco CallManager Server 11-2 System Logging Components 11-3 Syslog Collector 11-4 Syslog Administrative Interface 11-6 CiscoWorks2000 Voice Management Features 11-8 Camp
Preface This preface describes the purpose, intended audience, organization, and conventions for the Cisco IP Telephony Network Design Guide. Purpose This document serves as an implementation guide for Cisco AVVID (Architecture for Voice, Video and Integrated Data) networks based on Cisco CallManager Release 3.0(5). With such a high level of industry interest regarding IP telephony, customers are aggressively pursuing Cisco solutions for both large and small networks.
Preface Audience Audience This guide is intended for systems engineers and others responsible for designing Cisco AVVID networks based on Cisco CallManager Release 3.0(5). Caution The design guidelines in this document are based on the best currently available knowledge about the functionality and operation of the Cisco AVVID components. The information in this document is subject to change without notice.
Preface Organization Chapter Title Description Chapter 7 Multisite WAN with Centralized Provides design guidelines for multi-site WAN Call Processing systems using Cisco CallManager Release 3.0(5) for centralized call processing. Chapter 8 Quality of Service Addresses the QoS requirements for Cisco AVVID implementations over the enterprise WAN. Chapter 9 Catalyst DSP Provisioning Describes the Catalyst digital signal processor (DSP) resources and discusses how to provision these resources.
Preface Revision History Revision History The following revisions have been made to this document: Revision Date 12/08/00 11/22/00 06/30/00 Major Changes Since Previous Edition • Added Chapter 11 on network management. • Revised gatekeeper information in Chapter 6. • Revised document for Cisco CallManager Release 3.0(5). • Updated details of campus infrastructure design in Chapter 2. • Revised bandwidth requirements for inter-cluster calls in Chapter 3.
Preface Conventions Conventions This document uses the following conventions: Convention Description boldface font Commands and keywords are in boldface. italic font Arguments for which you supply values are in italics. [ ] Elements in square brackets are optional. {x|y|z} Alternative keywords are grouped in braces and separated by vertical bars. [x|y|z] Optional alternative keywords are grouped in brackets and separated by vertical bars. string A nonquoted set of characters.
Preface Conventions Notes use the following conventions: Note Means reader take note. Notes contain helpful suggestions or references to material not covered in the publication. Timesavers use the following conventions: Timesaver Means the described action saves time. You can save time by performing the action described in the paragraph. Tips use the following conventions: Tips Means the information contains useful tips. Cautions use the following conventions: Caution Means reader be careful.
Preface Additional Information Additional Information This section contains references to documents that provide additional information on subjects covered in this guide. • High availability design: – http://www.cisco.com/warp/partner/synchronicd/cc/sol/mkt/ent/ndsgn/hig hd_wp.htm – http://www.zdnet.com/zdtag/whitepaper/campuslan.pdf • Power protection: – http://www.apcc.com/go/machine/cisco/3a.cfm • Simple Mail Transfer Protocol (SMTP): – http://www.cisco.
Preface Obtaining Documentation Obtaining Documentation The following sections provide sources for obtaining documentation from Cisco Systems. World Wide Web You can access the most current Cisco documentation on the World Wide Web at the following sites: • http://www.cisco.com • http://www-china.cisco.com • http://www-europe.cisco.com Documentation CD-ROM Cisco documentation and additional literature are available in a CD-ROM package, which ships with your product.
Preface Obtaining Technical Assistance Documentation Feedback If you are reading Cisco product documentation on the World Wide Web, you can submit technical comments electronically. Click Feedback in the toolbar and select Documentation. After you complete the form, click Submit to send it to Cisco. You can e-mail your comments to bug-doc@cisco.com. To submit your comments by mail, for your convenience many documents contain a response card behind the front cover.
Preface Obtaining Technical Assistance technical support, download and test software packages, and order Cisco learning materials and merchandise. Valuable online skill assessment, training, and certification programs are also available. Customers and partners can self-register on Cisco.com to obtain additional personalized information and services. Registered users can order products, check on the status of an order, access technical support, and view benefits specific to their relationships with Cisco.
Preface Obtaining Technical Assistance If you cannot resolve your technical issue by using the TAC online resources, Cisco.com registered users can open a case online by using the TAC Case Open tool at the following website: http://www.cisco.com/tac/caseopen Contacting TAC by Telephone If you have a priority level 1(P1) or priority level 2 (P2) problem, contact TAC by telephone and immediately open a case.
Preface Obtaining Technical Assistance Cisco IP Telephony Network Design Guide xxii 78-11103-03
C H A P T E R 1 Introduction This chapter presents a high-level overview of several basic models that you can use in designing your IP telephony network. This overview provides some guidance with respect to when and why a particular design should be selected. Subsequent chapters delve into each network model in greater detail, beginning with the simplest model and building to increasingly complexity models.
Chapter 1 Introduction General Design Models Figure 1-1 Composite Model Branch office (With local call processing) Large campus (Up to 10,000 users) Rest of world V IP IP V IP PSTN IP Cisco IOS gatekeeper IP IP IP WAN V IP IP IP V IP 40763 Telecommuter (Without local call processing) Branch office (Without local call processing) Cisco IP Telephony Network Design Guide 1-2 78-11103-03
Chapter 1 Introduction Single-Site Model The overall goals of an IP telephony network are as follows: • End-to-end IP telephony • IP WAN as the primary voice path with the Public Switched Telephone Network (PSTN) as the secondary voice path between sites • Lower total cost of ownership with greater flexibility • Enabling of new applications For IP telephony networks based on Cisco CallManager Release 3.
Chapter 1 Introduction Single-Site Model Figure 1-2 Single-Site Model Msg store Msg store LDAP Directory Cisco uOne GateServer Cisco CallManager cluster IP IP IP WAN PSTN IP Catalyst backbone Catalyst wiring closet 40764 IP Cisco IP Telephony Network Design Guide 1-4 78-11103-03
Chapter 1 Introduction Multiple Sites with Independent Call Processing The single-site model has the following design characteristics: • Single Cisco CallManager or Cisco CallManager cluster. • Maximum of 10,000 users per cluster. • Maximum of eight servers in a Cisco CallManager cluster (four servers for primary call processing, two for backup call processing, one database publisher, and one TFTP server). • Maximum of 2,500 users registered with a Cisco CallManager at any time.
Chapter 1 Introduction Multiple Sites with Independent Call Processing Figure 1-3 Multiple Independent Sites V IP IP IP V PSTN IP IP IP V IP IP 40765 IP Cisco IP Telephony Network Design Guide 1-6 78-11103-03
Chapter 1 Introduction Multisite IP WAN with Distributed Call Processing The model for independent multiple sites has the following design characteristics: • Cisco CallManager or Cisco CallManager cluster at each site to provide scalable call control. • Maximum of 10,000 IP phones per cluster. • No limit to number of clusters. • Use of PSTN for networking multiple sites and for all external calls. • DSP resources for conferencing at each site.
Chapter 1 Introduction Multisite IP WAN with Distributed Call Processing Figure 1-4 Multisite Model with Distributed Call Processing Site B V IP IP PSTN (Secondary voice path) IP V IP IP IP WAN Primary voice path) IP Site A Cisco IOS gatekeeper for admission control V IP IP 40766 IP Site C Cisco IP Telephony Network Design Guide 1-8 78-11103-03
Chapter 1 Introduction Multisite IP WAN with Distributed Call Processing The multisite IP WAN with distributed call processing has the following design characteristics: • Cisco CallManager or Cisco CallManager cluster at each location (10,000 users maximum per site). • Cisco CallManager clusters are confined to a single campus and may not span the WAN. • IP WAN as the primary voice path between sites, with the PSTN as the secondary voice path.
Chapter 1 Introduction Multisite IP WAN with Centralized Call Processing Multisite IP WAN with Centralized Call Processing Figure 1-5 illustrates the model for multiple sites with centralized call processing.
Chapter 1 Introduction Multisite IP WAN with Centralized Call Processing The multisite IP WAN with centralized call processing has the following design characteristics: • Central site supports only one active Cisco CallManager. A cluster can contain a secondary and tertiary Cisco CallManager as long as all IP phones served by the cluster are registered to the same Cisco CallManager at any given time. This is called a centralized call processing cluster.
Chapter 1 Introduction Multisite IP WAN with Centralized Call Processing Cisco IP Telephony Network Design Guide 1-12 78-11103-03
C H A P T E R 2 Campus Infrastructure Considerations To ensure successful implementation of Cisco IP Telephony Solutions, you must first consider your LAN infrastructure. Before adding voice to your network, your data network must be configured properly. You can use these concepts and implementation techniques regardless of whether you have a headquarters with tens of thousands of users or a small branch with fewer than a hundred users.
Chapter 2 Campus Infrastructure Considerations Overview Overview Cisco IP Telephony Solutions rely on the stable foundation of Cisco multiprotocol routers and Catalyst multilayer LAN switches, which are the building blocks in enterprise networks. Figure 2-1 illustrates a general model of a Cisco IP telephony network using these components.
Chapter 2 Campus Infrastructure Considerations Overview Figure 2-1 Cisco IP Telephony General Deployment Model Msg store Msg store LDAP Directory Cisco uOne GateServer Cisco CallManager cluster IP IP IP WAN IP PSTN Catalyst backbone Catalyst wiring closet 40768 IP Cisco IP Telephony Network Design Guide 78-11103-03 2-3
Chapter 2 Campus Infrastructure Considerations Power Protection Strategies Power Protection Strategies Reliable power is vital to IP telephony. An uninterruptible power supply (UPS) can be used to ensure a reliable and highly available infrastructure by protecting it from power failures. Each UPS has some amount of battery that will keep the equipment running for a certain period of time. The UPS can be configured with the appropriate amount of battery for desired results.
Chapter 2 Campus Infrastructure Considerations Network Infrastructure Network Infrastructure Building an end-to-end IP telephony system requires an IP infrastructure based on Layer 2 and Layer 3 switches and routers, with switched connections to the desktop. Network designers must ensure that the endpoints are connected using switched 10/100 Ethernet ports, as illustrated in Figure 2-2.
Chapter 2 Campus Infrastructure Considerations Network Infrastructure Figure 2-2 Switched 10/100 Ethernet Network Infrastructure Cisco IP Phones IP IP IP IP IP IP Access Layer Distribution Layer Layer 3 Core Server Farm 40776 Cisco CallManagers Cisco IP Phones, which are connected to the switch port, also provide connectivity for an attached computer.
Chapter 2 Campus Infrastructure Considerations High Availability Note The three-port switch has two external ports and one internal port. Figure 2-3 shows the two basic parts of the IP phone—phone circuitry and switching electronics—housed in the same package. There are two switched connections available as RJ-45 jacks: one goes to the switch in the wiring closet using a straight-through cable, and the other connects a PC or workstation.
Chapter 2 Campus Infrastructure Considerations High Availability as power and supervisor modules. Network redundancy, however, is achieved with a combination of hardware, software, and intelligent network design practices. Network redundancy is achieved at many levels (see Figure 2-2). Physical connections exist from the edge devices where IP phones and computers are attached to two spatially diverse aggregation devices.
Chapter 2 Campus Infrastructure Considerations Physical Connectivity Options Physical Connectivity Options This section describes the various ways in which IP phones and computers can be connected to the network (see Figure 2-4).
Chapter 2 Campus Infrastructure Considerations Power to IP Phones the phone and PC to ports on different modules, thus achieving another layer of redundancy by providing protection for one of the devices if either module goes down. The third option shown in Figure 2-4 differs from the others in that the phone is not a hardware device, but is a JTAPI application running on a computer.
Chapter 2 Campus Infrastructure Considerations Power to IP Phones The inline method of supplying power requires the new power-enabled line card for the switch. This mechanism is currently available in the following Cisco Catalyst systems: • Catalyst 6000 Family Switches with minimum Cisco CatOS Release 5.5 or later. • Catalyst 4000 Family Switches (Catalyst 4006 with Power Entry Module and Auxiliary Power Shelf. Require minimum of two power supplies to power 240 ports.) Minimum Cisco CatOS Release 6.
Chapter 2 Campus Infrastructure Considerations Power to IP Phones Establishing Power to the IP Phone To establish power to the IP phone, the power-enabled Catalyst switch performs the following steps: 1. The switch performs phone discovery by sending specific tones down the wire to the IP phone. In its unpowered state, the IP phone loops these tones back to the switch.
Chapter 2 Campus Infrastructure Considerations Power to IP Phones Inline Power Configuration The inline power method requires Catalyst software Release 5.5 for Catalyst 6000, Cisco CatOS 6.1 or higher for Catalyst 4000, and Cisco IOS Release 12.0(5)XU or later for Catalyst 3524-PWR. These software releases support all the necessary commands to enable the switch to deliver power through the power-enabled line card.
Chapter 2 Campus Infrastructure Considerations Power to IP Phones Note The remainder of this chapter uses the Cisco CatOS command syntax. For native Cisco IOS commands, refer to the specific product documentation for the switches and line cards. Configuring the Default Power Allocation You can configure the default power allocation using the following command: set inlinepower defaultallocation value This command specifies how much power, in watts, to apply on a per-port basis.
Chapter 2 Campus Infrastructure Considerations Power to IP Phones Here is an example display from the show port inlinepower command: Default Inline Power allocation per port: 12.500 Watts (0.29 Amps @42V) Total inline power drawn by module 7: 37.80 Watts (0.90 Amps @42V)y module 5: 37.80 Watts ( 0.
Chapter 2 Campus Infrastructure Considerations Power to IP Phones Error and Status Messages You can configure the system to send syslog messages that indicate any deviations from the norm.
Chapter 2 Campus Infrastructure Considerations Power to IP Phones Ports and Power Supplies Table 2-1 shows the number of IP phones that can be supported with the 1050W, 1300W, and 2500W power-enabled line cards on a Cisco Catalyst 6509 with the Policy Feature Card (PFC). Table 2-1 IP Phones Supported with Power-Enabled Line Cards Power Supply IP Phones Supported at 6.
Chapter 2 Campus Infrastructure Considerations Power to IP Phones As shown in Figure 2-7, the patch panel has two ports per connection: one port on the switch side and one port on the phone side. Figure 2-7 Power Patch Panel Connectivity to Cisco IP Phone 2 pairs (4 wires) Switch side 1 3 5 RJ-45 2 46 47 48 Phone side 1 3 5 2 46 RJ-45 47 48 IP IP IP IP IP 40775 4 pairs (8 wires) This arrangement of applying power to the phone uses all four pairs in the Category 5 cable.
Chapter 2 Campus Infrastructure Considerations Power to IP Phones Figure 2-8 External Power Through the Power Patch Panel Power patch panel port Switch port without inline power Switch side RJ-45 Pair 2 Pair 3 Category 5 cable Pair 1 Power Phone side RJ-45 IP Pair 4 40777 AC Source Cisco IP phone As shown in Figure 2-8, pairs 2 and 3 from the switch are patched straight through to pairs 2 and 3 coming from the phone.
Chapter 2 Campus Infrastructure Considerations Power to IP Phones Wall Power The last option is to power the Cisco IP Phone from a local transformer module plugged into a nearby outlet (maximum of 3 meters), as illustrated in Figure 2-9. Wall Powered Cisco IP Phone AC source 110 VAC wall power to 48VDC converter IP 40778 Figure 2-9 A combination of these power options can provide redundant power to the Cisco IP Phone.
Chapter 2 Campus Infrastructure Considerations IP Addressing and Management IP Addressing and Management Each IP phone requires an IP address, along with associated information such as subnet mask, default gateway, and so on. Essentially, this means that your organization’s need for IP addresses doubles as you assign IP phones to users. This information can be configured statically on the IP phone, or it can be provided by the Dynamic Host Configuration Protocol (DHCP).
Chapter 2 Campus Infrastructure Considerations IP Addressing and Management CDP Enhancements Cisco Discovery Protocol (CDP) is a device discovery protocol that runs on all Cisco equipment. With CDP, each device sends periodic messages to a multicast address and in turn listens to the periodic messages sent by other devices. This allows devices on the network to discover one another and learn information such as protocols used, protocol addresses, native VLAN of interconnected ports, and so on.
Chapter 2 Campus Infrastructure Considerations IP Addressing and Management Power Requirement Field When the switch provides inline power to an IP phone, it has no way of knowing how much power the phone needs (this varies by model). Initially, the switch allocates 10W, then adjusts the delivered power according to the requirements sent by the IP phone in the CDP message. Auxiliary VLANs and Data VLANs The new voice VLAN is called an auxiliary VLAN in the Catalyst software command-line interface (CLI).
Chapter 2 Campus Infrastructure Considerations IP Addressing and Management Voice VLAN Configuration To configure the VVID from the Catalyst software CLI, use the set port auxiliaryvlan command. You can use this command to set the VVID on a single port, on a range of ports, or for an entire module. The following example shows how to display the command syntax: Console> (enable) set port auxiliaryvlan help Usage: set port auxiliaryvlan (vlan + 1..
Chapter 2 Campus Infrastructure Considerations IP Addressing and Management Connecting to the Network The following steps outline the process that takes place when an IP phone is powered up and plugged into the network: Note 1. The IP phone begins a CDP exchange with the switch. The phone issues a trigger CDP to force a response from the switch. That response contains the VVID for the phone. 2.
Chapter 2 Campus Infrastructure Considerations IP Addressing and Management Sample Addressing Plan and Recommendations Figure 2-11 shows examples of preferred IP addressing for connecting IP phones and PCs. Figure 2-11 Preferred IP Addressing Plans IP phone + PC on separate switch ports IP phone + PC on same switch ports 171.68.249.100 171.68.249.100 IP 10.1.1.1 171.68.249.101 IP phone uses “10.0.0.0” network IP phone uses “10.0.0.0” network 40783 IP 10.1.1.
Chapter 2 Campus Infrastructure Considerations IP Addressing and Management Figure 2-12 shows examples of preferred IP addressing for connecting IP phones, PCs, and Cisco IP SoftPhones. Figure 2-12 Optional IP Addressing Plans IP phone + PC on separate switch ports IP phone + PC on same switch ports Real IP addresses 171.68.249.101 IP phone + PC share the same device (Cisco IP Softphone) IP 171.68.249.100 171.68.249.100 IP IP 171.68.249.100 Real IP addresses Real IP addresses 40782 171.68.249.
Chapter 2 Campus Infrastructure Considerations Quality of Service Quality of Service In a converged environment, all types of traffic travel over a single transport infrastructure. Yet all traffic types are not the same. Data is bursty, loss intolerant, and not latency sensitive. Voice, on the other hand, is nonbursty and has some tolerance to loss but is latency sensitive. The challenge is in providing the required level of service for each of these traffic types.
Chapter 2 Campus Infrastructure Considerations Quality of Service Trust Boundaries The concept of trust is an important and integral one to implementing QoS. Once the end devices have a set class of service (CoS) or type of service (ToS), the switch has the option of trusting them or not. If the switch trusts the settings, it does not need to do any reclassification; if it does not trust the settings, then it must perform reclassification for appropriate QoS.
Chapter 2 Campus Infrastructure Considerations Quality of Service Traffic Classification at Layer 2 Cisco IP Phones can mark voice packets as high priority using CoS as well as ToS. By default, the phone sends 802.1Q tagged packets with the CoS and ToS set to a value of 5. Figure 2-13 shows packets from the IP phone being sent as tagged frames with the 802.1p fields set to 5 and frames from the PC being sent untagged. Figure 2-13 Frame Tagging with PVID and VVID IP Untagged 802.3 40769 Tagged 802.
Chapter 2 Campus Infrastructure Considerations Quality of Service Figure 2-14 PC Is Not Trusted Example: set port qos 2/1 trust-ext untrusted IP PC is untrusted Phone ASIC rewrites CoS = 0 CoS = 5 CoS = 5 CoS = 7 40770 CoS = 0 The switch uses its queues (available on a per-port basis) to buffer incoming frames before sending them to the switching engine. (It is important to remember that input queuing comes into play only when there is congestion.
Chapter 2 Campus Infrastructure Considerations Quality of Service Note All the values for WRED, WRR, and queue size are configurable. Cisco Catalyst 6000 family switches also support the notion of trusted and untrusted QoS on a per-port basis. This parameter is configured with the following command: set port qos mod/ports..
Chapter 2 Campus Infrastructure Considerations Quality of Service Figure 2-16 shows a different case in which the PC is not trusted completely, yet it gets a level of service higher than it would with CoS=0. This is achieved by extending a specific CoS value to the PC traffic. Figure 2-16 PC Is Not Trusted but Gets a Non-Zero CoS Example: set port qos 2/1 cos-ext 2 IP CoS = 5 PC is untrusted.
Chapter 2 Campus Infrastructure Considerations Quality of Service Traffic Classification at Layer 3 Using the 802.1p bits within the 802.1Q tag provides the desired QoS results at Layer 2. When traffic has to cross a Layer 3 boundary, however, it becomes imperative to implement these mechanisms using Layer 3 parameters, such as the 3 IP precedence bits (commonly referred to as ToS) or the new DSCP parameter, which uses the six most significant bits within the ToS byte of the IP header.
Chapter 2 Campus Infrastructure Considerations Quality of Service QoS ACLs can also include Layer 4 information for classifying individual applications. Cisco Catalyst 6000 family switches are also capable of policing traffic based on Layer 3 addresses and Layer 4 port numbers. For example, you can police individual HTTP flows to 1 Mbps and aggregate all HTTP flows to 25 Mbps.
Chapter 2 Campus Infrastructure Considerations Quality of Service Summary of Capabilities and Recommendations Table 2-2 briefly summarizes the capabilities within the Cisco Catalyst switch families.
Chapter 2 Campus Infrastructure Considerations Quality of Service • Use QoS ACLs for more granular classification of packets using Layer 4 information. • Use policing if necessary to limit traffic for individual flows as well as aggregate flows. • Have traffic going to the WAN edge classified at Layer 3 so that the router can use it for advanced WAN queuing mechanisms. • Use a WAN edge router as the classifier for very small remote site networks where a Layer 3 capable switch is not available.
Chapter 2 Campus Infrastructure Considerations Quality of Service Cisco IP Telephony Network Design Guide 2-38 78-11103-03
C H A P T E R 3 Cisco CallManager Clusters This chapter discusses the concept, provisioning, and configuration of Cisco CallManager clusters. Clusters, which were introduced with Cisco CallManager Release 3.0, provide a mechanism for distributing call processing seamlessly across a converged IP network infrastructure to support IP telephony, facilitate redundancy, and provide feature transparency and scalability.
Chapter 3 Cisco CallManager Clusters Cluster Operation and Scalability Guidelines A dedicated database publisher and a dedicated TFTP server are recommended for large systems. For smaller systems, the function of database publisher and the TFTP server can be combined. Table 3-1 provides guidelines for scaling devices with Cisco CallManager clusters.
Chapter 3 Cisco CallManager Clusters Cluster Operation and Scalability Guidelines The maximum number of registered devices per Cisco CallManager is 5000 in the case of the MCS-7835, including a maximum of 2500 IP telephones, gateways, and Digital Signaling Processor (DSP) devices such as transcoding and conferencing resources. In the event of failure of one of the Cisco CallManagers within the cluster, the maximum number of registered devices remains 5000 per Cisco CallManager in the case of the MCS-7835.
Chapter 3 Cisco CallManager Clusters Cluster Operation and Scalability Guidelines The total number of device units that a single Cisco CallManager can control depends on the server platform. Table 3-3 gives details of the maximum number of devices per platform.
Chapter 3 Cisco CallManager Clusters Cluster Operation and Scalability Guidelines Intracluster Communication There are two primary kinds of intracluster communications within a Cisco CallManager cluster (Figure 3-1). The first is a mechanism for distributing the database that contains all the device configuration information. The configuration database (Microsoft SQL 7.0) is stored on a publisher and replicated to the subscriber members of the cluster.
Chapter 3 Cisco CallManager Clusters Cisco CallManager Redundancy Cisco CallManager Redundancy Within a cluster, each registered IP phone can be assigned a prioritized list of up to three Cisco CallManagers with which it can register for call processing. Shared resources such as gateways using the Skinny Gateway Protocol are also capable of using this redundancy scheme. The Media Gateway Control Protocol (MGCP) also operates in a similar fashion to provide spatial redundancy for call processing.
Chapter 3 Cisco CallManager Clusters Cisco CallManager Redundancy Note The sizes of clusters and redundancy groups are subject to change in future releases of Cisco CallManager. The following recommendations apply to the configuration of redundancy groups for Cisco CallManager Release 3.0(5): • Cisco CallManager cluster for up to 2500 users: – Server A is a dedicated database publisher and TFTP server. – Server B is the primary Cisco CallManager for all registered devices.
Chapter 3 Cisco CallManager Clusters Cisco CallManager Redundancy – Server G is the primary Cisco CallManager for IP phones 7501 through 10,000. – Server H is the backup Cisco CallManager for IP phones 5001 through 10,000. In the above configuration, four Cisco CallManager redundancy groups are required for servers CE, DE, FH and GH. Figure 3-3 illustrates this configuration. Triple redundancy is also possible in this case by configuring the redundancy groups as CEH, DEH, FHE and GHE.
Chapter 3 Cisco CallManager Clusters Cisco CallManager Redundancy Device Pool Configuration You can use device pools to scale and simplify the distribution of Cisco CallManager redundancy groups. A device pool allows you to assign the following three primary attributes globally to devices: • Region—Required only if multiple voice codecs are used within an enterprise. • Date/time group—Specifies date and time zone for a device.
Chapter 3 Cisco CallManager Clusters Cisco CallManager Redundancy In Figure 3-4, a device pool called Branch 1 G.711 ADE is configured with the following characteristics: • It is assigned the region Branch 1 G.711. This region contains devices that are capable of communicating by means of G.711 only, such as a voice mail system or conference bridge. • It is assigned to the appropriate date/time group.
Chapter 3 Cisco CallManager Clusters Cisco CallManager Redundancy Interregion Configuration Screen 40788 Figure 3-5 The exact clustering model—and hence device pools used—is driven by the deployment model. The typical device pool configurations, however, have the following characteristics: • Single-site cluster with no WAN voice interconnectivity – Device pools are configured based only on Cisco CallManager redundancy groups.
Chapter 3 Cisco CallManager Clusters Campus Clustering Guidelines Campus Clustering Guidelines All members of a Cisco CallManager cluster must be interconnected over a LAN. Cisco CallManager Release 3.0(5) clusters are not supported over a WAN. The following considerations apply when configuring a campus IP telephony network: • Maximum of eight servers per cluster with Cisco CallManager release 3.0(5). • Maximum of 10,000 total registered devices.
Chapter 3 Cisco CallManager Clusters Campus Clustering Guidelines Figure 3-6 Campus or MAN Cluster V V Conf Transcoder Conf V Transcoder Transcoder Conf V Conf Transcoder Conf 40789 Transcoder In Figure 3-6 a Cisco CallManager is placed at each of the five buildings or sites. This configuration ensures that, in the event of a failure, local call processing is possible at each site.
Chapter 3 Cisco CallManager Clusters Intercluster Communication Intercluster Communication The following sections discuss intercluster communications and address issues in cluster provisioning for isolated campus deployment, multisite WAN deployment with distributed call processing, and multisite WAN deployment with centralized call processing. Cluster Provisioning for the Campus Where the requirement for a campus network exceeds 10,000 users, additional clusters are required.
Chapter 3 Cisco CallManager Clusters Intercluster Communication In Figure 3-7 the dotted lines represent the H.323 intercluster links, which are configured in pairs to provide redundancy in the event of loss of IP connectivity to any member of the cluster. If desired, you could configure these links as a full mesh. However, Cisco recommends limiting intercluster configuration to two peers. In the majority of situations, this is sufficient to provide adequate resiliency.
Chapter 3 Cisco CallManager Clusters Intercluster Communication Table 3-4 Number of Intercluster Calls Recommended Bandwidth Configuration for Intercluster Calls Using G.
Chapter 3 Cisco CallManager Clusters Intercluster Communication Figure 3-8 Intercluster Communication Using Gatekeepers Site B Gatekeeper(s) V IP IP V PSTN IP IP IP IP WAN Primary voice path IP Site A IP V IP 40791 IP Site C Cisco IP Telephony Network Design Guide 78-11103-03 3-17
Chapter 3 Cisco CallManager Clusters Intercluster Communication Clusters for Multisite WAN with Centralized Call Processing As stated earlier, Cisco CallManagers within a cluster must be interconnected over a local area network. Cisco CallManager also provides locations-based call admission control that enables provisioning of small branch and telecommuter solutions where remote call processing is acceptable. Figure 3-9 illustrates this model.
Chapter 3 Cisco CallManager Clusters Intercluster Communication To ensure that only a single Cisco CallManager is active at a time, all devices should be assigned to a single Cisco CallManager redundancy group. This Cisco CallManager redundancy group consists of a prioritized list of up to three Cisco CallManagers. For a centralized call processing cluster, only a single Cisco CallManager redundancy group is recommended, and it should be the default group.
Chapter 3 Cisco CallManager Clusters Intercluster Communication Figure 3-11 Centralized Call Processing Cluster Interconnected with Two Clusters Cluster1 CM1 Cluster1 CM5 Cluster1CM4 Cluster1 CM2 Centralized call processing Cluster1CM3 H.323 IP IP Primary Cluster X Location 1 IP IP IP IP IP IP Secondary IP IP H.
Chapter 3 Cisco CallManager Clusters Intracluster and Intercluster Feature Transparency Intracluster and Intercluster Feature Transparency The distributed architecture of a Cisco CallManager cluster provides the following primary benefits for call processing: • Spatial redundancy • Resiliency • Availability • Survivability In addition, a cluster provides transparent support of user features across all devices in the cluster.
Chapter 3 Cisco CallManager Clusters Intracluster and Intercluster Feature Transparency Cisco IP Telephony Network Design Guide 3-22 78-11103-03
C H A P T E R 4 Gateway Selection This chapter discusses issues concerning the selection of gateways for connecting an IP telephony network to the PSTN or legacy PBX and key systems. Choosing a gateway from some 20 candidates—ranging from specialized, entry-level standalone voice gateways to the high-end, feature-rich integrated router and Catalyst gateways—can be daunting.
Chapter 4 Gateway Selection Supported Protocols Supported Protocols Using Cisco CallManager Release 3.0(5), three types of gateway protocols are supported: • Skinny Gateway Protocol—used by the digital gateways, including the Cisco Access Digital Trunk Gateway DT-24+ and DE-30+, as well as the Cisco Catalyst 6000 Voice Gateway module. • Media Gateway Control Protocol (MGCP)—used by Cisco CallManager to control the new Cisco Voice Gateway 200 (VG200) standalone analog gateway. • H.
Chapter 4 Gateway Selection DTMF Relay Table 4-1 Cisco IP Telephony Gateways and Supported Protocols (continued) Gateway Skinny Gateway Protocol H.323 MGCP Cisco 2600 No Yes Future Cisco 3600 No Yes Future Cisco 7200 No Yes No Cisco 7500 No Future No Cisco AS5300 No Yes No Note The VG200 supports only Foreign Exchange Station (FXS) and Foreign Exchange Office (FXO) interfaces in MGCP mode. A wider interface selection is offered when the VG200 is configured in H.323v2.
Chapter 4 Gateway Selection DTMF Relay Skinny Gateways The Cisco Access Digital Trunk Gateway DT-24+, the Cisco Access Digital Trunk Gateway DE-30+, and the Catalyst 6000 gateway use the Skinny Gateway Protocol to carry DTMF signals out of band using the TCP port 2002. Out-of-band DTMF is the default gateway configuration mode. Cisco IOS H.323 Gateways The Cisco 1750, 2600, 3600, 7200, and AS5300 series products communicate with Cisco CallManager using H.323. Both Cisco CallManager Release 3.
Chapter 4 Gateway Selection Cisco CallManager Redundancy You must enter additional configuration parameters in the Cisco CallManager MGCP gateway configuration interface. Cisco CallManager Redundancy Integral to the Cisco IP telephony solution is the provision for low-cost, distributed PC-based systems to replace expensive and proprietary legacy PBX systems. This distributed design lends itself to the robust, fault-tolerant architecture of clustered Cisco CallManagers.
Chapter 4 Gateway Selection Cisco CallManager Redundancy The following example shows the configuration for H.323 gateway failover: interface Loopback0 ip address 1.1.1.1 255.255.255.0 voip-gateway voip bind srcaddr 1.1.1.1 dial-peer voice 101 voip destination-pattern 1111 session target ipv4:10.1.1.101 preference 0 voice class h323 1 dial-peer voice 102 voip destination-pattern 1111 session target ipv4:10.1.1.
Chapter 4 Gateway Selection Supplementary Services If the primary Cisco CallManager becomes available at a later time, the VG200 can revert to the original Cisco CallManager. This fallback can either occur immediately, after a configurable amount of time, or only when all connected sessions have been released.
Chapter 4 Gateway Selection Supplementary Services IOS H.323 Gateways Only H.323v1 was supported prior to Cisco CallManager Release 3.0. The inability to modify the destination of an Real-Time Transport Protocol (RTP) stream after H.323v1 call setup prohibited supplementary services such as hold, forward, and transfer. Because H.
Chapter 4 Gateway Selection Site-Specific Gateway Requirements 4. Cisco CallManager issues a request to IP phone 2, using the Skinny Station Protocol, to set up an RTP connection to the Cisco IOS gateway. At the same time, Cisco CallManager issues an OpenLogicalChannel request to the Cisco IOS gateway with the new destination parameters, but using the same SessionID. 5. After the Cisco IOS gateway acknowledges the request, an RTP voice bearer channel is set between IP phone 2 and the Cisco IOS gateway.
Chapter 4 Gateway Selection Site-Specific Gateway Requirements • Is direct inward dialing (DID) required? DID is a private branch exchange (PBX) or Centrex feature that permits outside calls to be placed directly to a station line without use of an operator. • Is calling line ID (CLID) needed? CLID is a service available on digital telephone networks that tells the called party which number is calling.
Chapter 4 Gateway Selection Site-Specific Gateway Requirements To help narrow the focus, the site-specific feature list can be compared to Table 4-2 and Table 4-3, which correlate analog and digital gateways with supported telephony features. Table 4-2 Analog Gateways by Site-Specific Features Gateway FXS FXO E & M1 VG200 Yes Yes In H.323v2 mode Future Cisco Access DT-24+ and Cisco Access DE-30+ No No No N/A Cisco 1750 Yes Yes Yes Future Cisco 3810 V3 Yes Yes Yes 12.1(3)T/12.
Chapter 4 Gateway Selection Site-Specific Gateway Requirements Table 4-3 Digital Gateways by Site-Specific Features User Side Network PRI2 Side PRI User Side BRI3 Network Digital Side BRI DID4/CLID5 Gateway T1 CAS1 E1/R2 E1 CAS VG200 In No H.323v2 mode In H.323v2 mode No No No No N/A Cisco Access DT-24+ and Cisco Access DE-30+ No No No Yes Yes No No Yes Cisco 1750 No No No No No Future Future N/A Cisco 3810 V3 Yes No Yes No No Yes No Yes Cisco 2600 Yes 12.
Chapter 4 Gateway Selection Site-Specific Gateway Requirements Table 4-4 lists the gateways of each type along with the data interfaces, PSTN interfaces, and voice compression supported. Table 4-4 Gateways with Supported Interfaces and Compression Types Analog PSTN Data Interfaces Interfaces Digital PSTN Interfaces in DS0s Voice Compression Gateway Type Gateway Skinny Gateway Protocol Cisco Access DT-24+ 10BaseT 0 24 G.711, G.723.1 Cisco Access DE-30+ 10BaseT 0 30 G.711, G.723.
Chapter 4 Gateway Selection Site-Specific Gateway Requirements Table 4-4 Gateways with Supported Interfaces and Compression Types (continued) Analog PSTN Data Interfaces Interfaces Digital PSTN Interfaces in DS0s Voice Compression Gateway Type Gateway H.323 Cisco 1750 10BaseT, T1/E1 serial 4 0 G.711, G.729 VG200 100BaseT 4 48/60 G.711, G.729a, G.723.1 Cisco 2600 10/100BaseT, Token Ring, T1/E1 serial 4 48/60 G.711, G.729a, G.723.
C H A P T E R 5 Dial Plan Architecture and Configuration This chapter discusses the architecture and operation of the Cisco CallManager dial plan and provides design recommendations. A dial plan is essentially a telephony system interface that allows users to reach each other easily by dialing strings that can be routed to diverse locations by the system.
Chapter 5 Dial Plan Architecture and Configuration Cisco CallManager Dial Plan Architecture allow for greater scalability, flexibility, and ease of use, while tighter integration of Cisco CallManager and Cisco IOS gateways allows for larger network deployments. The Cisco CallManager dial plan architecture is set up to handle two general types of calls.
Chapter 5 Dial Plan Architecture and Configuration Cisco CallManager Dial Plan Architecture Figure 5-1 Goal of a Well-Designed Dial Plan Gatekeeper(s) Site B V PSTN IP V IP IP IP IP WAN IP 40794 IP Headquarters Primary voice path Secondary voice path The dial plan for internal calls to IP phones registered with a Cisco CallManager cluster is fairly simple. On initial configuration, an IP phone is assigned a directory number (DN), which it maintains wherever it resides.
Chapter 5 Dial Plan Architecture and Configuration Cisco CallManager Dial Plan Architecture Note IP phones are not the only devices that can be accessed in this manner. Other devices that register with Cisco CallManager and maintain a directory number can include Cisco IP SoftPhones, analog phones, and fax machines attached to gateways that use MGCP or the Skinny Gateway Protocol. Configuring Cisco CallManager to handle external calls requires the use of a route pattern.
Chapter 5 Dial Plan Architecture and Configuration Cisco CallManager Dial Plan Architecture Figure 5-2 Cisco CallManager Dial Plan Architecture Dialed number Route pattern Digit manipulation Route list Digit manipulation on a per-route-group 1st basis choice No Try 2nd choice Overrides the route pattern 2nd No choice Try 3rd choice (if available) Route group Route group Route groups point to devices IP WAN V PSTN V Cisco CallManager cluster Device types put in route groups: * Gateways (H.
Chapter 5 Dial Plan Architecture and Configuration Cisco CallManager Dial Plan Architecture Route Pattern The route pattern identifies a dialed number (E.164 numbers in North America) and uses the underlying route list and route group configurations to determine how to route the call. A route pattern can be entered as a specific number or, more commonly, a number range. Using a route pattern to represent a number range minimizes the number of entries required.
Chapter 5 Dial Plan Architecture and Configuration Cisco CallManager Dial Plan Architecture Route List The term route point from previous releases of Cisco CallManager has been replaced by route list in Cisco CallManager Release 3.0, though the function remains much the same. A route list defines the way a call is routed. Route lists are configured to point to one or more route groups, which effectively serve the purpose of trunk groups.
Chapter 5 Dial Plan Architecture and Configuration Cisco CallManager Dial Plan Architecture Devices All IP endpoints are viewed as devices, but only certain devices can be entered in a route group. Figure 5-3 illustrates the types of devices that can be in route groups. Figure 5-3 Device Types to Which Route Groups Point Route group V Skinny based MGCP based H.
Chapter 5 Dial Plan Architecture and Configuration Cisco CallManager Dial Plan Architecture An important feature of the route pattern dial structure is that it is typically used when IP phone calls are destined to go to gateways or remote Cisco CallManagers using H.323. In these cases, alternate routes can be taken in the event the primary path to a destination is not available.
Chapter 5 Dial Plan Architecture and Configuration Special Dial String Considerations Digit translation can also be performed within the route pattern structure using called/calling party transformation, which performs the same digit translation functions for both incoming and outgoing calls.
Chapter 5 Dial Plan Architecture and Configuration Special Dial String Considerations On-Net Route Pattern In a multisite IP WAN with distributed call processing, an abbreviation of the full E.164 address is typically used for ease of dialing. For example, where an on-net location has a number range of (408) 526-1000 through 1999, there may be only a single route pattern with an entry of 61XXX. This simplifies user dialing and requires only one route pattern entry where the Xs serve as wildcards.
Chapter 5 Dial Plan Architecture and Configuration Special Dial String Considerations Figure 5-4 Calls Across the IP WAN with Different Digit Manipulation per Path Users required to dial 7 digits for intersite calls 526-1111 Gatekeeper(s) Secondary voice path Prepend 1408 and send to PSTN V PSTN IP V IP IP IP WAN IP (408) 526-XXXX 5-digit internal dialing Primary voice path Strip 52 and deliver 6111 to remote Cisco CallManager IP 40797 IP Outbound Calls Through the PSTN Outbound calls thro
Chapter 5 Dial Plan Architecture and Configuration Special Dial String Considerations between a local seven-digit number and a local area code to determine when the dialing is complete. Otherwise, Cisco CallManager waits 10 seconds without detecting any digits before assuming the dialing is complete. Local PSTN gateway dial plan configuration is fairly simple. The gateways based on MGCP and the Skinny Gateway Protocol have all of their dial plan information configured in Cisco CallManager, while an H.
Chapter 5 Dial Plan Architecture and Configuration Configuring Dial Plan Groups and Calling Restrictions Option 2: Route Pattern = 0.!# 0. Represents the local PSTN access code. ! Stands for any digit and any number of digits. This also means that Cisco CallManager must wait 10 seconds (the default) without receiving any digits before it assumes the dialing is complete and sends the call.
Chapter 5 Dial Plan Architecture and Configuration Configuring Dial Plan Groups and Calling Restrictions Partitions A partition is a group of devices with similar reachability characteristics. Devices you can place in partitions are IP phones, directory numbers, and route patterns. Each partition name should be chosen to have some meaningful correlation to the group of users it represents. For example, for users located in Building D in San Jose, you could create a partition called SJ-D.
Chapter 5 Dial Plan Architecture and Configuration Configuring Dial Plan Groups and Calling Restrictions Figure 5-6 Partitions and Calling Search Spaces Used to Provide Dialing Restrictions San Jose V PSTN IP IP IP Partition assignment “SJ-Users” = All SJ IP phones “SJ-PSTN” = “9” route pattern Calling search space Headquarters “Unrestricted” = SJ-Users, SJ-PSTN “SJ-Only” = SJ-Users IP phone calling search space assignment 40799 Staff IP phones = “Unrestricted” Lobby IP phones = “SJ-Only” Staf
Chapter 5 Dial Plan Architecture and Configuration Configuring Dial Plan Groups and Calling Restrictions second calling search space called SJ-Only is created and contains only the SJ-Users. San Jose staff IP phones are assigned the Unrestricted calling search space, which means they are allowed to dial anywhere. The lobby phones are assigned the SJ-Only calling search space, which means they can dial only local phones within the local site.
Chapter 5 Dial Plan Architecture and Configuration Dial Plan Guidelines and Configuration • Intrasite, intersite, local emergency, and national long-distance PSTN calls only • Fully unrestricted dialing, including international numbers Partitions and calling search spaces permit independent dial ranges on a partition basis. This means that extensions and access codes within different partitions can have overlapping numbers and yet function independently.
Chapter 5 Dial Plan Architecture and Configuration Dial Plan Guidelines and Configuration Campus and Individual Site Dial Plans In a campus environment with no multisite IP WAN connectivity, the most common dial plan considerations are concerned with providing PSTN access.
Chapter 5 Dial Plan Architecture and Configuration Dial Plan Guidelines and Configuration North American dialing includes 911 services. The route group is configured to discard the access code by digit manipulation. This strips the 9 off the string sent to the local PSTN gateway, which is a Cisco IOS gateway in this case. Cisco CallManager denotes any digits to the left of the dot (.
Chapter 5 Dial Plan Architecture and Configuration The Role of a Gatekeeper This configuration assumes that 1+10 digit dialing would be required for long-distance calls to the PSTN, and 7-digit dialing would be required for local PSTN calling. Although the scope of the 9.@ route pattern includes emergency 911 services, the Cisco IOS H.323 gateway still requires a dial peer for 911. Various dial peers can be added for 411 and 611 services, which are included in the scope of the 9.@ route pattern as well.
Chapter 5 Dial Plan Architecture and Configuration The Role of a Gatekeeper Figure 5-9 Using a Gatekeeper for Call Admission Control Cisco IOS Gatekeeper Cisco 3600 V IP X1001 WAN "Call placed" PSTN "voice overflow" Cisco CallManager 1xxx Cisco 3600 V IP X2002 Cisco CallManager 2xxx 49596 Call flow H.323 RAS signaling If the WAN is unavailable in this scenario, the call cannot go through as dialed.
C H A P T E R 6 Multisite WAN with Distributed Call Processing This chapter provides design guidelines for multisite WAN systems that use Cisco CallManager for distributed call processing. The discussion emphasizes issues specific to the distributed call processing model, with reference to relevant material in other sections of this guide.
Chapter 6 Multisite WAN with Distributed Call Processing Distributed Call Processing Model Figure 6-1 Multisite WAN with Distributed Call Processing Model Directory Voice/e-mail Directory Voice/e-mail Conf MTP Gatekeeper(s) V IP IP Conf IP MTP Directory PSTN Voice/e-mail V IP IP IP WAN primary voice path IP IP V IP Headquarters Conf IP Branch Offices 40802 MTP In Cisco CallManager Release 3.
Chapter 6 Multisite WAN with Distributed Call Processing Call Admission Control Voice calls between sites can use the IP WAN as the primary path and the PSTN as the secondary path in the event the IP WAN is down or has insufficient resources to handle additional calls. Whether calls use the IP WAN or the PSTN can be transparent to both the calling party and the called party.
Chapter 6 Multisite WAN with Distributed Call Processing Call Admission Control Figure 6-2 Why Call Admission Control is Needed WAN bandwidth can only support 2 calls. What happens when 3rd call attempted? Call #1 IP IP Call #2 Call #3 causes poor quality for all calls IP IP IP 40803 VoIP data network IP For distributed call processing systems, you can implement call admission control with an H.323 gatekeeper.
Chapter 6 Multisite WAN with Distributed Call Processing Call Admission Control Figure 6-3 Call Admission Control Using a Gatekeeper Gatekeeper(s) ARQ “May I make a call?” ACF “Yes, there is enough bandwidth.” V IP PSTN IP V IP IP IP IP WAN 61111 61112 61113 (408) 526-XXXX Zone 1 Zone 2 Call flow H.
Chapter 6 Multisite WAN with Distributed Call Processing Call Admission Control Figure 6-4 Dynamic Routing of Calls Between Sites Regional Center Headquarters Router plus voice gateway IP Router plus voice gateway IP V V PSTN IP IP IP IP Branch Office X IP WAN Router plus voice gateway V IP IP Telecommuter 49080 IP IP In this model, it is important to be able to detect when the IP WAN is down or when there are insufficient resources for the IP WAN to handle additional calls, so that cal
Chapter 6 Multisite WAN with Distributed Call Processing Call Admission Control to this solution. In this case, the dial plan is tightly coupled with the gatekeeper call admission control mechanism because it is the dial plan that ultimately decides when to place a call across the IP WAN and what to do if the gatekeeper rejects the call. Dial plan issues are addressed in the “Dial Plan Considerations” section on page 6-15. As mentioned before, you can use an H.
Chapter 6 Multisite WAN with Distributed Call Processing Call Admission Control Operational Model There are two parts to configuring the gatekeeper method of call admission control: • Gatekeeper configuration. This is where the network administrator configures a Cisco IOS Multimedia Conference Manager (MCM) that acts as the gatekeeper. Recommended platforms are Cisco 2600, 3600, or 7200 routers with Cisco IOS Release 12.1(3)T or higher.
Chapter 6 Multisite WAN with Distributed Call Processing Call Admission Control Gatekeeper Configuration The following gatekeeper configuration defines four zones. Each zone contains a cluster with two Cisco CallManagers (except zone SJC1, which contains three Cisco CallManagers) that could possibly register as the gateway. ! Enter gateway configuration mode. gatekeeper ! Define each zone that this gatekeeper administers. zone local LHR cisco.com zone local HKG cisco.com zone local SJC1 cisco.
Chapter 6 Multisite WAN with Distributed Call Processing Call Admission Control Cisco CallManager Configuration Figure 6-5 shows the Cisco CallManager configuration screen where you can associate Cisco CallManager as a VoIP gateway to the gatekeeper.
Chapter 6 Multisite WAN with Distributed Call Processing Call Admission Control Interaction Between Cisco CallManager and Gatekeeper Cisco CallManager sends a Registration Request (RRQ) to register itself as a single VoIP gateway. Currently the Cisco IOS Multimedia Conference Manager (MCM) cannot accept E.164 address ranges within an RRQ, but you can configure the address ranges statically on the gatekeeper as shown in the “Gatekeeper Configuration” section on page 6-9.
Chapter 6 Multisite WAN with Distributed Call Processing Call Admission Control have registered with it. Also, by way of Cisco IOS configuration, the gatekeeper knows which Cisco CallManager belongs to what zone, and the amount of bandwidth associated with each zone.
Chapter 6 Multisite WAN with Distributed Call Processing Call Admission Control Figure 6-7 Request to Admit a Call Cisco IOS Gatekeeper 1) Cisco CallManager sends its E.164 address in ARQ. ARQ ACF Site 1 Cisco 3600 IP WAN 2) Cisco CallManager uses returned IP address in ACF to target remote Cisco CallManager. 3) Cisco CallManager requests proper bandwidth in ARQ.
Chapter 6 Multisite WAN with Distributed Call Processing Call Admission Control Figure 6-8 Receiving a Call Through the Gatekeeper 1) Local Cisco CallManager identifies remote Cisco CallManager by E.164 address in H255 setup information of incoming call. Local Cisco CallManager uses its route patterns to verify validity of calling device and to determine amount of bandwidth needed to complete the call.
Chapter 6 Multisite WAN with Distributed Call Processing Dial Plan Considerations Considerations for Using a Gatekeeper The following considerations apply when using gatekeeper-based call admission control: • The gatekeeper must be the Cisco IOS MCM. Recommended platforms are the Cisco 2600, 3600, or 7200 with Cisco IOS Release 12.1(3)T or greater.
Chapter 6 Multisite WAN with Distributed Call Processing Dial Plan Considerations Anonymous Device. This device can be thought of as a point-to-multipoint trunk, which removes the necessity for the meshed point-to-point trunks in the Cisco CallManager dial plan model. The Anonymous Device uses the gatekeeper to route calls to the correct Cisco CallManager cluster.
Chapter 6 Multisite WAN with Distributed Call Processing Dial Plan Considerations – Requires only one Anonymous Device in each Cisco CallManager cluster. – Requires only two route patterns, one for intercluster calls to all locations and one for PSTN access. – You configure the dial plan in the gatekeeper (not in every Cisco CallManager) to route intercluster calls. – Users must dial the correct PSTN number to access a remote site if the IP WAN is down or is busy.
Chapter 6 Multisite WAN with Distributed Call Processing Dial Plan Considerations Figure 6-9 Using Cisco CallManager to Route Intercluster Calls Secondary voice path Prepend “1408” and send to PSTN Users required to dial 7 digits for intersite calls “526-1111” San Jose Gatekeeper(s) V IP PSTN IP V IP IP IP IP WAN Philadelphia IP (408) 526-XXXX 5-digit internal dialing Primary voice path Strip “1408” and Deliver 61111 to Remote CallManager Route pattern 52.
Chapter 6 Multisite WAN with Distributed Call Processing Dial Plan Considerations As shown in Figure 6-9, the route list contains two route groups, SJ-IPWAN and PHL-PSTN, listed in order of priority. The SJ-IPWAN route group is listed first (highest priority) and points to the San Jose Cisco CallManager. The digit manipulation specified in route pattern SJ-IPWAN discards the access code (52).
Chapter 6 Multisite WAN with Distributed Call Processing Dial Plan Considerations Using this enhanced gatekeeper registration process, we can deploy the Cisco AVVID solution shown in Figure 6-10 with a minimum of configuration.
Chapter 6 Multisite WAN with Distributed Call Processing Dial Plan Considerations The following table lists the configuration parameters for the configuration shown in Figure 6-10. Cisco CallManager IP Addresses Directory Number Range Bandwidth Available to This Site San Jose Cluster 1 (SJC1) 172.26.17.2 172.26.17.3 172.26.17.4 1000 to 1999 2048 kbps San Jose Cluster 2 (SJC2) 172.26.17.130 172.26.17.131 2000 to 2999 2048 kbps London (LHR) 172.26.18.2 172.26.18.
Chapter 6 Multisite WAN with Distributed Call Processing Dial Plan Considerations Cisco CallManager Configuration On each Cisco CallManager cluster, you must configure the gatekeeper with the intercluster codec you are using and must also enable the Anonymous Device. In addition, you must configure a route pattern to allow calls between clusters. To select the codec for intercluster calls, define a region and select the acceptable rate (type of compression), as illustrated in Figure 6-11.
Chapter 6 Multisite WAN with Distributed Call Processing Dial Plan Considerations Figure 6-12 Configuring a Device Pool in Cisco CallManager Next, you must define the gatekeeper, making sure to associate it with the correct device pool and to enable Anonymous Calls, as illustrated in Figure 6-13.
Chapter 6 Multisite WAN with Distributed Call Processing Dial Plan Considerations Figure 6-13 Configuring a Gatekeeper in Cisco CallManager During registration with the gatekeeper, Cisco CallManager registers itself as a VoIP gateway with a technology prefix for voice. To configure the voice technology prefix on the Cisco CallManager server, select Service > Service Parameters and update the Cisco CallManager service parameter GateKeeperSupportedPrefix as illustrated in Figure 6-14.
Chapter 6 Multisite WAN with Distributed Call Processing Dial Plan Considerations Figure 6-14 Configuring Gatekeeper Service Parameters in Cisco CallManager Only one route pattern is required for intercluster calls, and you can configure it as illustrated in Figure 6-15.
Chapter 6 Multisite WAN with Distributed Call Processing Dial Plan Considerations Figure 6-15 Configuring a Route Pattern for Intercluster Calls Note The simplified dial plan in this example provides no automatic fallback or overflow to the PSTN. This capability would require a route group for each destination, as in previous releases of Cisco CallManager. You can add manual access to the PSTN in the standard way.
Chapter 6 Multisite WAN with Distributed Call Processing Dial Plan Considerations Gatekeeper Configuration The gatekeeper configuration requires you to enter the zones, each Cisco CallManager that will register with that zone, the zone prefix (directory number ranges), bandwidth allowed for call admission, and the technology prefix for voice.
Chapter 6 Multisite WAN with Distributed Call Processing Dial Plan Considerations Gatekeeper Selection and Redundancy Fault tolerance for the gatekeeper is very important in the Cisco AVVID network. Through the use of Hot Standby Router Protocol (HSRP), you can achieve redundancy for the gatekeepers. Configuring a pair of gatekeepers with HSRP allows the active gatekeeper to process requests, and, in the event of a failure, the standby gatekeeper will take over.
Chapter 6 Multisite WAN with Distributed Call Processing Dial Plan Considerations Figure 6-16 illustrates the use of regions for distributed call processing environments, where often only two regions need be assigned. Note Just one WAN region is associated with all H.323 devices across the IP WAN because of the single codec restriction. In future releases of Cisco CallManager, multiple WAN regions may be supported.
Chapter 6 Multisite WAN with Distributed Call Processing Cisco CallManager Cluster Considerations Cisco CallManager Cluster Considerations The following design considerations apply for Cisco CallManager clusters in a distributed call processing environment using Cisco CallManager Release 3.0: • Each Cisco CallManager cluster can support 10,000 users. • No more than 2500 users can be registered on any given Cisco CallManager, even under failure conditions.
Chapter 6 Multisite WAN with Distributed Call Processing DSP Resource Provisioning for Transcoding and Conferencing Figure 6-17 DSP Resources Across the WAN Call setup to Cisco CallManager A or 666-1212 B Set up RTP stream to Cisco CallManager DSP farm IP IP Router/GW Router/GW IP WAN MTP MTP IP IP 666-1212 555-1212 dials 666-1212 G.711 only G.711 only Region B Intraregion Interregion A to B A=G.711 G.729 Compresses call leg G.
Chapter 6 Multisite WAN with Distributed Call Processing Voice Messaging Considerations configuration step, Cisco CallManager cannot automatically select the proper transcoder, and the RTP stream will not complete transmission if the codecs are mismatched. Voice Messaging Considerations In a multisite IP WAN with distributed call processing, each site must have its own voice messaging components. This is the case whether using Cisco uOne or interfacing to a legacy voice messaging system.
C H A P T E R 7 Multisite WAN with Centralized Call Processing This chapter provides design guidelines for multisite WAN systems that use Cisco CallManager Release 3.0(5) for centralized call processing. The discussion emphasizes issues specific to the centralized call processing model, with reference to relevant material in other sections of this guide.
Chapter 7 Multisite WAN with Centralized Call Processing Centralized Call Processing Model Figure 7-1 Multisite WAN with Centralized Call Processing Branch offices Aggregation V IP IP Cluster ISDN backup IP PSTN V IP IP WAN V IP IP IP IP 40811 IP In Figure 7-1 the Cisco CallManager cluster is located at the central site. Because all IP phones within this cluster must register with a single Cisco CallManager, this solution can scale to 2500 users per cluster.
Chapter 7 Multisite WAN with Centralized Call Processing Call Admission Control Call Admission Control Where centralized call processing is used, call admission control is provided using the locations construct. Under this scheme, locations are created with a geographical correspondence, such as a branch office. For example, a location could be designated as Branch 1, Mountain View Office. (A postal zip code could also be used.
Chapter 7 Multisite WAN with Centralized Call Processing Call Admission Control restricted to using gateways based on Skinny Gateway Protocol. You can now use Cisco IOS gateways based on H.323 or MGCP for media stream termination, and use of Media Termination Point (MTP) is no longer required. Table 7-1 details the common branch gateways and minimum Cisco IOS releases. Table 7-1 Cisco IOS Minimum Releases for IOS Gateway Platforms Platform Minimum Cisco IOS Release Cisco 1750 12.1.
Chapter 7 Multisite WAN with Centralized Call Processing Dial Plan Considerations does not use E.164 addresses in the admission request (ARQ) when it queries the gatekeeper for admission. This restriction may change in future releases of Cisco CallManager. Dial Plan Considerations A centralized call processing cluster must be able to handle three primary types of calls: • Intracluster calls between IP phones within the cluster. • Intercluster calls between Cisco CallManager clusters.
Chapter 7 Multisite WAN with Centralized Call Processing Dial Plan Considerations Intercluster Calls Intercluster calls are made using H.323 and can use alternative routing, including routing calls to the PSTN. Between clusters connected over a WAN, a gatekeeper is required for call admission control. The issues with intercluster calls are covered in greater detail in Chapter 6, “Multisite WAN with Distributed Call Processing.” See also Figure 3-11.
Chapter 7 Multisite WAN with Centralized Call Processing Dial Plan Considerations Figure 7-3 IP WAN with Three Branches Branch offices Aggregation V IP IP Cluster ISDN backup IP PSTN V IP IP WAN V IP IP IP IP 40811 IP In the case of Figure 7-3, the partitions detailed in Table 7-2 would be configured to allow users to have access to either all intracluster locations or all intracluster locations and a local gateway.
Chapter 7 Multisite WAN with Centralized Call Processing Cisco CallManager Cluster Considerations The calling party search spaces in Table 7-3 would then need to be defined. These calling search spaces would allow users to be assigned the ability to dial either numbers within the cluster only or all numbers within the cluster as well as PSTN calls through the local gateway.
Chapter 7 Multisite WAN with Centralized Call Processing Cisco CallManager Cluster Considerations With WAN Cisco CallManager clusters, all active devices are required to register with a single Cisco CallManager. This allows the Cisco CallManager to maintain call state for all calls and thereby ensure that the specified bandwidth to a location is not exceeded. Figure 7-4 shows devices registered to a single Cisco CallManager.
Chapter 7 Multisite WAN with Centralized Call Processing DSP Resource Provisioning for Transcoding and Conferencing DSP Resource Provisioning for Transcoding and Conferencing Centralized call processing is typically done in environments where the provisioning of dedicated call processing at each site is not cost effective or is administratively unacceptable. The benefits of such a configuration are its central administration and low cost when spread across many sites.
Chapter 7 Multisite WAN with Centralized Call Processing DSP Resource Provisioning for Transcoding and Conferencing Figure 7-6 Call Flow for a Centrally Transcoded Call to Voice Mail IP Router/gateway IP WAN IP Router/gateway IP 40816 Trans IP Compressed call leg G.711 call leg Conferencing poses another example of an application that uses G.711 only. Consequently, if the party wanting to make a conference call can traverse the WAN using only a low-bit-rate codec, the call must be transcoded to G.
Chapter 7 Multisite WAN with Centralized Call Processing Voice Messaging Considerations Voice Messaging Considerations Voice mail, like call processing, is usually not cost effective at the branch locations. Centrally locating voice mail simplifies voice mail administration as well as the provisioning of IP phones.
C H A P T E R 8 Quality of Service This chapter addresses the Quality of Service (QoS) requirements for implementations of IP telephone solutions over an enterprise network. By applying the prerequisite tools, you can achieve excellent quality voice, video, and data transmissions over an IP infrastructure, irrespective of media and even at low data rates. For more detailed information on designing Quality of Service networks for AVVID deployments, please see the Cisco AVVID QoS Design Guide at http://www.
Chapter 8 Quality of Service Campus QoS Model Campus QoS really involves two separate areas of configuration, which are discussed in the following sections: • Traffic Classification • Interface Queuing Traffic Classification Classifying or marking traffic as close to the edge of the network as possible has always been an integral part of the Cisco network design architecture.
Chapter 8 Quality of Service Campus QoS Model in small, finite intervals as a result of the bursty nature of network traffic. When this occurs, any packets destined for that transmit interface are dropped. The only way to prevent dropped voice traffic is to configure multiple queues on campus switches. Table 8-2 lists the Cisco Ethernet switches that support enhanced queuing services.
Chapter 8 Quality of Service WAN QoS Model WAN QoS Model The enterprise WAN model is shown in Figure 8-1. Figure 8-1 Typical Enterprise WAN IP Regional/HQ office Cisco 2600 Cisco 7200 IP IP ATM/Frame Relay Cisco 3600 Branch offices IP Point to point Cisco 3600 IP 40819 Cisco 3600 WAN Provisioning Before voice and video can be placed on a network, it is necessary to ensure that adequate bandwidth exists for all required applications.
Chapter 8 Quality of Service WAN QoS Model Figure 8-2 Provisioning a Converged Network Bandwidth Provisioning BW = (Min BW for Voice + Min BW for video + Min BW for Data) /0.75 Voice Voice Ctrl Video SNA Data Routing etc. 40820 0.75 x link capacity Link capacity WAN QoS Tools This section discusses the tools used to implement QoS for IP telephony applications over the enterprise WAN. These tools include traffic prioritization, link fragmentation and interleaving (LFI), and traffic shaping.
Chapter 8 Quality of Service WAN QoS Model Figure 8-3 shows this prioritization scheme as follows: • Voice is placed into a queue with priority queuing capabilities and is allocated a bandwidth of 48 kbps. The entrance criterion to this queue should be the differentiated services code point (DSCP) value of EF, or IP precedence value of 5. Traffic in excess of 48 kbps would be dropped if the interface becomes congested.
Chapter 8 Quality of Service WAN QoS Model Optimized Queuing for VoIP over the WAN Layer 3 Queuing Subsystem Packets in 1 1 1 1 2 2 PQ Voice Link Fragmentation and Interleave Police PQ Video Packets out Class = X 3 3 4 4 4 0 0 0 0 Layer 2 Queuing Subsystem Low Latency Queuing Interleave Class = Y CBWFQ WFQ TX Ring 0 4 3 2 1 1 Fragment Packets out Default 49086 Figure 8-3 The following points must be taken into account when configuring low-latency queuing (LLQ): • The minimum system soft
Chapter 8 Quality of Service WAN QoS Model schemes, such as G.729, can squeeze a 64-kbps call down to an 8-kbps payload. Cisco gateways and IP phones support a range of codecs that can enhance efficiency on these low-speed links. The link efficiency can be further increased by using compressed RTP (cRTP), which compresses a 40-byte IP + UDP + RTP header to approximately two to four bytes.
Chapter 8 Quality of Service WAN QoS Model Traffic Shaping Traffic shaping is required for multiple access, non-broadcast media such as ATM and Frame Relay, where the physical access speed varies between two endpoints. Traffic shaping technology accommodates mismatched access speeds. In the case of Frame Relay with FRF.12, traffic shaping also allows delay variation, or jitter, to be bounded appropriately. For ATM, data rates are such that fragmentation is typically not required.
Chapter 8 Quality of Service WAN QoS Model Best Practices Table 8-4 shows the minimum recommended software release for enterprise voice implemented over the WAN and includes recommended parameters for QoS tools. The currently recommended Cisco IOS versions will change with future releases. Table 8-4 Recommended Cisco IOS and QoS Tools Minimum Cisco IOS Data Link Type Release Classification Prioritization LFI Traffic Shaping Serial Lines 12.
Chapter 8 Quality of Service WAN QoS Model Call Admission Control Call admission control is required to ensure that network resources are not oversubscribed. Calls that exceed the specified bandwidth are either rerouted using an alternative route such as the PSTN, or a busy tone is returned to the calling party. Figure 8-6 demonstrates that call admission control is needed regardless of whether the implementation model is toll bypass or IP telephony to the desktop.
Chapter 8 Quality of Service WAN QoS Model Cisco IP Telephony Network Design Guide 8-12 78-11103-03
C H A P T E R 9 Catalyst DSP Provisioning This chapter describes Catalyst digital signal processor (DSP) resources, with emphasis on two new Catalyst 4000 and Catalyst 6000 voice modules, and it discusses how to provision these resources. These new modules are the WS-X4604-GWY for the Catalyst 4000 and the WS-X6608-T1 (WS-X6608-E1 for countries outside the USA) for the Catalyst 6000. They are available for use with Cisco CallManager Release 3.0(5).
Chapter 9 Catalyst DSP Provisioning Understanding the Catalyst DSP Resources Understanding the Catalyst DSP Resources The DSP resources on the new Catalyst 4000 and 6000 gateway modules essentially provide hardware support for IP telephony features offered by Cisco CallManager. These features are hardware-enabled voice conferencing, hardware-based MTP support for supplementary services, and transcoding services. Catalyst-enabled conferencing is the ability to support voice conferences in hardware.
Chapter 9 Catalyst DSP Provisioning Understanding the Catalyst DSP Resources Table 9-1 Catalyst DSP Resource Matrix Catalyst Voice Modules Catalyst 4000 WS-X4604-GWY Catalyst 6000 WS-6608-T1 or WS-6608-E1 PSTN Gateway Sessions Conferencing Sessions MTP Transcoding Sessions G.711 only G.711 only To G.
Chapter 9 Catalyst DSP Provisioning Catalyst Conferencing Services Catalyst Conferencing Services To scale IP telephony systems in large enterprise environments, hardware-based conferencing must be used. The new hardware for the Catalyst 4000 and 6000 switch families was developed with this requirement in mind. These new Catalyst voice modules can handle conferencing in hardware, eliminating the requirement of running a software conferencing service on a Windows NT server in the IP telephony network.
Chapter 9 Catalyst DSP Provisioning Catalyst Conferencing Services with a maximum of 32 simultaneous G.711 or G.723 conference callers per configured logical port. This results in a maximum of 256 conference participants per module with G.711 or G.723 calls. See Table 9-1 for a summary of conference call densities for each module.
Chapter 9 Catalyst DSP Provisioning Catalyst Conferencing Services Catalyst Conferencing Services Voice mail Cisco CallManager server cluster V IP IP PSTN MTP Conf Router/gateway Conf = Conferencing DSP farm 40827 Figure 9-1 Conferencing Caveats The following caveats apply to Catalyst conferencing services: • The Catalyst 4000 conferencing services support G.711 connections only, unless an MTP transcoding service is used.
Chapter 9 Catalyst DSP Provisioning Catalyst MTP Transcoding Services Catalyst MTP Transcoding Services Introducing the WAN into an IP telephony implementation forces the issue of voice compression. In the previous designs shown in this document, all campus-oriented voice was uncompressed (G.711) to provide the highest quality while incurring the fewest complications. Once a WAN-enabled network is implemented, voice compression between sites is the recommended design choice.
Chapter 9 Catalyst DSP Provisioning Catalyst MTP Transcoding Services functionality has been added to two of the new modules for the Catalyst 4000 and Catalyst 6000. A packet-to-packet gateway is a device with DSPs that has the job of transcoding between voice streams using different compression algorithms. That is, when a user on an IP phone at a remote location calls a user at the central location, Cisco CallManager instructs the remote IP phone to use compressed voice, or G.
Chapter 9 Catalyst DSP Provisioning Catalyst MTP Transcoding Services Voice Compression, IP-to-IP Packet Transcoding, and Conferencing Connecting sites across an IP WAN for conference calls presents a complex scenario. In this scenario, the Catalyst modules must perform the conferencing service as well as the IP-to-IP transcoding service to uncompress the WAN IP voice connection. In Figure 9-3 a remote user joins a conference call at the central location.
Chapter 9 Catalyst DSP Provisioning Catalyst MTP Transcoding Services Figure 9-3 Multisite WAN Using Centralized MTP Transcoding and Conferencing Services Cisco CallManager A Voice mail server G.711 only IP IP WAN IP IP VSM Compressed Call Leg G.711 Call Leg DSP Farm Transcoding VSM 43752 IP IP-to-IP Packet Transcoding Across Intercluster Trunks H.323v2 Intercluster Trunks are used to connect Cisco CallManager clusters.
Chapter 9 Catalyst DSP Provisioning Catalyst MTP Transcoding Services Figure 9-4 Intercluster Call Flow with Transcoding DSP DSP Conference DSP's DSP DSP DSP IP H.
Chapter 9 Catalyst DSP Provisioning Catalyst MTP Transcoding Services The following list gives intercluster MTP/Transcoding details: • If transcoding is required between Cisco CallManager clusters, the H.323 Intercluster trunk must be configured with an MTP resource. • All calls between Cisco CallManager clusters will go through MTPs. • Outbound Intercluster calls will use an MTP/Transcoding resource from the Cisco CallManager from which the call originates.
Chapter 9 Catalyst DSP Provisioning Catalyst 4000 Voice Services Catalyst 4000 Voice Services The PSTN gateway and voice services module for the Catalyst 4003 and 4006 switches, supports three analog voice interface cards (VICs) with two ports each or one T1/E1 card with two ports and two analog VICs. The VIC interfaces can be provisioned in any combination of Foreign Exchange Office (FXO), Foreign Exchange Station (FXS), or Ear & Mouth (E&M).
Chapter 9 Catalyst DSP Provisioning Catalyst 4000 Voice Services Figure 9-5 Catalyst Voice Gateway Module in Gateway Mode SIMM DSP Resources DSP DSP DSP GE back plane int. DSP DSP DSP DSP DSP DSP DSP DSP DSP DSP DSP DSP DSP DSP DSP DSP DSP DSP DSP DSP DSP Encryption ATM slot CPT TDM switch Future modules VIC VIC 40825 TDM bus VIC G.
Chapter 9 Catalyst DSP Provisioning Catalyst 6000 Voice Services To configure this module as a DSP farm (gateway mode), enter one or both of the following CLI commands: voicecard conference voicecard transcode • The WS-X4604-GWY requires its own local IP address, in addition to the IP address for Cisco CallManager. It is also good practice to specify a loopback IP address for the local Signaling Connection Control Part (SCCP).
Chapter 9 Catalyst DSP Provisioning Catalyst 6000 Voice Services Whether acting as a PSTN gateway, a conferencing resource, or an MTP transcoding resource, each port on the module requires its own IP address. The port can be configured to have either a static IP address or an IP address provided by DHCP. If a static IP is entered, a TFTP server address must also be added because the ports actually get all configuration information from the downloaded TFTP configuration file.
C H A P T E R 10 Migrating to an IP Telephony Network This chapter explains how an enterprise can migrate from a conventional PBX and its adjunct systems, principally voice messaging, to an IP telephony network. Four migration models are presented, encompassing various feature sets, and the steps for achieving each are outlined.
Chapter 10 Migrating to an IP Telephony Network PBX and Voice Messaging Interfaces and Protocols Figure 10-1 Closed Versus Open Protocols in a Voice Network Proprietary voice mail networking Voice mail system Networked voice mail Proprietary voice mail/PBX interconnect Proprietary voice mail/PBX interconnect Proprietary CCS Legacy PBX 40834 Legacy PBX Voice mail system PBX and Voice Messaging Interfaces and Protocols When an IP network is introduced into this environment, the users on the IP net
Chapter 10 Migrating to an IP Telephony Network Simple IP Network Migration Sequence Table 10-1 Interfaces and Protocols for PBX and Voice Mail System Networking Vendor PBX to PBX Protocols PBX to Voice Mail Interfaces Voice Mail to Voice Mail Networking Cisco PRI, QSID, CAS SMDI, analog AMIS-A1 Avaya PRI, DCS, QSIG Digital set emulation Octelnet Proprietary, X.
Chapter 10 Migrating to an IP Telephony Network Simple IP Network Migration Sequence Figure 10-2 Initial Conventional Voice Network Voice messaging system PSTN 40835 PBX Figure 10-3 shows the migration phase, with users moving in blocks from PBX to IP network. Figure 10-3 Migration Phase Voice messaging system IP Gateway LAN IP V Gateway V IP PSTN PSTN Pilot user migration 40836 PBX Figure 10-4 shows the network when migration is completed and the PBX is retired.
Chapter 10 Migrating to an IP Telephony Network Simple IP Network Migration Sequence Figure 10-4 Migration Completed IP LAN IP PSTN IP 40837 V Usually the transition from a conventional voice network to an IP network is made in stages, as follows: Step 1 Pilot stage—the IP network is introduced, and a very limited number of users are given IP service.
Chapter 10 Migrating to an IP Telephony Network Reference Models for Migration Configurations Reference Models for Migration Configurations This section considers four basic migration configurations. These models are depicted in Figure 10-5.
Chapter 10 Migrating to an IP Telephony Network Reference Models for Migration Configurations The models shown in Figure 10-5 have the following characteristics: • Model A is the simplest; it is concerned only with PBX services and does not address voice messaging. • Model B includes a voice messaging system behind the PBX and assumes that the voice mail system does not offer an open interface for connection to an IP network.
Chapter 10 Migrating to an IP Telephony Network Reference Models for Migration Configurations Model A poses two main questions for consideration: • Should the trunk connections remain on the PBX until the end of the migration, or should some trunks be moved to the IP network along with users? • What type of connection should be used between the PBX and the IP network? Table 10-2 shows the feature set supported by each type of connection.
Chapter 10 Migrating to an IP Telephony Network Reference Models for Migration Configurations Note • MWI on/off can instruct the receiving switch to illuminate the message waiting indicator on a phone when the user has a new message. Without this capability on the link, MWI cannot be available on the switch remote from the voice messaging system. • Both-ways origination refers to the capability to initiate and answer a call on the same trunk.
Chapter 10 Migrating to an IP Telephony Network Reference Models for Migration Configurations If the trunks remain on the PBX, so that billing can be done at one point, it can be difficult to identify IP-originated calls by calling number. The following configuration steps are required for the type A system: Step 1 Step 2 Step 3 Configure the PRI link. a. Add PRI gateway in Cisco CallManager and configure. b. Add PBX PRI card and cable to IP network, and configure PRI on PBX. c.
Chapter 10 Migrating to an IP Telephony Network Reference Models for Migration Configurations The following list summarizes the cost of the type A system: Hardware • PRI gateway for IP network • PRI card on PBX Software • Nothing extra on Cisco CallManager • PRI software on PBX The following list summarizes the pros and cons of the type A system: Pros Cons • Easy and inexpensive to implement • Minimal reconfiguration of the PBX is needed.
Chapter 10 Migrating to an IP Telephony Network Reference Models for Migration Configurations Detailed Discussion of Model B Figure 10-7 shows the topology for model B, which includes both a PBX and voice messaging. Figure 10-7 Migration Model B—PBX with Voice Messaging Voice messaging system IP PBX LAN V IP IP Migration 40840 PSTN The considerations for telephony features in model B are the same as for model A, but the introduction of voice messaging brings a number of extra considerations.
Chapter 10 Migrating to an IP Telephony Network Reference Models for Migration Configurations There are three important requirements for IP telephony applications in model B networks: • When a party calls an IP phone and the call is forwarded to voice mail, the caller should hear the IP user’s greeting for call answering. This can be a problem because, if the PBX sees the call from the IP network as a trunk call, it might not preserve the original called number on the call.
Chapter 10 Migrating to an IP Telephony Network Reference Models for Migration Configurations It is not possible for the voice messaging system to select the proper greeting (“busy”, “no answer,” or “all calls”) for IP users because that information is not sent across the PRI to the PBX. It is also not possible for MWI information to traverse the PRI from the PBX to the IP network. The message indication feature would, therefore, not be available to IP users in a type B system.
Chapter 10 Migrating to an IP Telephony Network Reference Models for Migration Configurations The following list summarizes the pros and cons of the type B system: Pros Cons • IP users get access to voice messaging as they migrate from the PBX. • Relatively inexpensive to implement • Same voice feature shortfall as type A systems • No MWI support for IP users • Workaround entails administration complexity and possibly PBX hardware.
Chapter 10 Migrating to an IP Telephony Network Reference Models for Migration Configurations For voice messaging, model C fixes the drawbacks of model B. Because the voice messaging system deals with the PBX and the IP network as separate systems, calls that reach the IP network can be forwarded directly into voice messaging without being routed back through the PBX. This should allow all normal call answering and message retrieval functions.
Chapter 10 Migrating to an IP Telephony Network Reference Models for Migration Configurations The following list summarizes the cost of the type C system: Hardware Software • PRI gateway for IP network • PRI card on PBX • Analog gateways for IP network for voice messaging • Analog cards on voice messaging system • SMDI interface on voice messaging system • Nothing extra on Cisco CallManager • PRI software on PBX The following list summarizes the pros and cons of the type C system: Pros Co
Chapter 10 Migrating to an IP Telephony Network Reference Models for Migration Configurations Detailed Discussion of Model D Figure 10-9 shows the topology for model D, which includes a PBX with voice messaging system that migrates to an IP network with Cisco uOne unified messaging. The discussion of this model considers only the voice messaging component of Cisco uOne.
Chapter 10 Migrating to an IP Telephony Network Reference Models for Migration Configurations Audio Messaging Interchange Specification Analog (AMIS-A) networking of voice messaging systems is planned for a future release of Cisco uOne. When it is available, if both Cisco uOne and the voice messaging system are configured for networking, it will be possible to provide basic voice mail messaging functionality across the systems (provided the voice messaging system supports AMIS-A).
Chapter 10 Migrating to an IP Telephony Network Cisco Digital PBX Adapter (DPA) The following list summarizes the pros and cons of the type D system: Pros • IP users get access to voice messaging as they migrate from the PBX. • Relatively inexpensive to implement Cons • Same voice feature shortfall as type A systems • No voice mail interaction between voice messaging and Cisco uOne • Ideally, DID (DDI) trunks would be moved from PBX to IP network to follow the users.
Chapter 10 Migrating to an IP Telephony Network Cisco Digital PBX Adapter (DPA) Understanding How the DPA 7630 Works The Cisco DPA 7630 enables you to integrate your existing Octel voice mail and Lucent PBX systems with Cisco CallManager. The DPA 7630 functions by emulating digital phones or a PBX system. This capability allows it to appear like these devices to Cisco CallManager, Octel, and Lucent systems.
Chapter 10 Migrating to an IP Telephony Network Cisco Digital PBX Adapter (DPA) What If I Cannot Use SMDI? SMDI might not be an option for you, particularly if you are using a digital interface on your Octel systems. Octel systems with digital line cards emulate digital phones, appearing to the PBX as digital extensions, referred to as per-port or PBX Integration Cards (PICs). On PIC systems, the voice and data are on the same path. MWI is set and cleared via feature access codes on dedicated ports.
Chapter 10 Migrating to an IP Telephony Network Cisco Digital PBX Adapter (DPA) Using the Simple Integration Mode In the simple integration mode, the DPA 7630 handles all processing and signaling between the Octel and Cisco CallManager systems (see Figure 10-10).
Chapter 10 Migrating to an IP Telephony Network Cisco Digital PBX Adapter (DPA) Using the Hybrid Integration Mode If you want to connect Cisco CallManager to Octel voice mail and Lucent PBX systems, you must use the hybrid integration mode. In the hybrid configuration, the DPA 7630 handles processing and signaling among the Octel, Lucent, and Cisco CallManager systems (see Figure 10-11).
Chapter 10 Migrating to an IP Telephony Network Cisco Digital PBX Adapter (DPA) Using the Multiple Integration Mode If your system requires more than the hybrid integration mode provides, you might want to add multiple DPA 7630 systems to your network (see Figure 10-12).
Chapter 10 Migrating to an IP Telephony Network Cisco Digital PBX Adapter (DPA) You might add multiple DPA 7630 systems to your network if you are using the DPA 7630 to capacity, and you need the following capability: • More than eight MWI ports to the Lucent system. If you need more MWI ports to the Lucent system, add an additional DPA 7630 in hybrid mode. However, you cannot use all 24 ports for Lucent MWIs.
C H A P T E R 11 Network Management This chapter introduces two network management tools available for Cisco AVVID enterprise deployment models: • Remote Serviceability for Cisco CallManager, page 11-1 • CiscoWorks2000 Voice Management Features, page 11-8 This chapter contains a brief overview of network management and the CiscoWorks2000 system architecture, including its capability to manage Cisco AVVID components in enterprise networks.
Chapter 11 Network Management Remote Serviceability for Cisco CallManager Table 11-1 lists the features that have been provided for network management applications to export data and, particularly for CiscoWorks2000, to provide reporting, proactive management, debugging, and other capabilities.
Chapter 11 Network Management Remote Serviceability for Cisco CallManager Two Management Information Bases (MIBs) were introduced in Cisco CallManager Release 3.0 to permit the export of data as well as to support server advertisement and discovery. Both MIBs are extension agents and are independent of each other to facilitate future applications and functionality: • CISCO-CCM-MIB This MIB exports data from the Cisco CallManager database and other data sources.
Chapter 11 Network Management Remote Serviceability for Cisco CallManager event traces. Cisco CallManager and CiscoWorks2000 provide this functionality for unified message logging, display, and management. The following are the two main components to the system logging mechanism: • Syslog Collector, which resides on Cisco CallManager • Syslog Receiver (The CiscoWorks2000 server can also function as a receiver, as described in the “Syslog Administrative Interface” section on page 11-6.
Chapter 11 Network Management Remote Serviceability for Cisco CallManager Figure 11-1 Syslog Architecture for the Interoperability of Cisco CallManager and CiscoWorks2000 Cisco CallManager (on Windows NT) CiscoWorks 2000 Syslog Receiver CORBA Syslog Collector Application UDP SAenvProperties.ini Database Syslog Daemon UDP Application Cisco IOS Voice Gateways 49984 Report Syslog.
Chapter 11 Network Management Remote Serviceability for Cisco CallManager Syslog Administrative Interface The Syslog administrative interface is a web-based interface that is part of Cisco Call Manager Administration, under Service > Trace. A new page shows the status of each trace flag and the trace output options of each service for each server in a Cisco CallManager cluster, as illustrated in Figure 11-2.
Chapter 11 Network Management Remote Serviceability for Cisco CallManager Options also exist to enable the debug trace messages and to configure the Syslog server name. You should enable the debug trace message option only when there is little activity in the system. This method avoids putting excessive traffic on the network and lessens the burden on the system. You can send the debug trace messages to the Windows 2000 EventLog, to a local file, to the Syslog server, or to all three.
Chapter 11 Network Management CiscoWorks2000 Voice Management Features CiscoWorks2000 Voice Management Features CiscoWorks2000 is a suite of products for network management, inventory control, analysis, and debugging. The Common Management Framework (CMF) in CiscoWorks2000 is a web-based application with various plug-in application suites that provide certain management feature sets. Figure 11-3 illustrates the user interface to the CMF.
Chapter 11 Network Management CiscoWorks2000 Voice Management Features Each application suite in the common web-based interface takes advantage of a common database. CiscoWorks2000 can run on either Windows NT or a Sun Solaris platform. Table 11-2 describes the respective components needed to complete the product suite for Cisco AVVID network management. Table 11-2 Components of CiscoWorks2000 Product Suite CiscoWorks2000 Components Description and Function Common Management Framework Release 1.1.
Chapter 11 Network Management CiscoWorks2000 Voice Management Features Figure 11-4 CiscoWorks2000 Architecture Campus Manager Resource Manager Essentials User Tracking Syslog Topology Map Device Inventory Trace Path Asynchronous Network Interface Desktop Common Management Framework Devices Syslog Messages SNMP Devices 49985 SNMP Discovery of the network occurs when you provide a seed device, preferably a router or a switch, through which the ANI can discover the network by reading its nei
Chapter 11 Network Management CiscoWorks2000 Voice Management Features Campus Manager The ANI discovery process added the support for voice components of the Cisco AVVID network in Common Management Framework (CMF) Release 1.1.1. This CMF release supports the following voice devices and functions: • Cisco CallManager Cisco CallManager Release 3.0 (and later) contains the CDP driver, and it supports partial CDP MIB and SNMP.
Chapter 11 Network Management CiscoWorks2000 Voice Management Features User Tracking User Tracking (UT), a service module of the Campus Manager and ANI, specifically discovers end user nodes such as systems, Cisco CallManager hosts, Cisco IP Phones, and non-CDP systems as well. User Tracking performs an initial discovery of all hosts in the topology map and a subsequent discovery to maintain the user tracking table. You can specify a time limit for this subsequent discovery, and the default is 1 hour.
Chapter 11 Network Management CiscoWorks2000 Voice Management Features Figure 11-5 User Tracking Phone Table Trace Path Analysis The Path Analysis tool, a part of the Campus Manager, traces IP connectivity between any managed devices in the network. The end points of the trace must be a managed device or end-user node in UT because there is a heavy reliance on accurate information for the trace to be performed.
Chapter 11 Network Management CiscoWorks2000 Voice Management Features Figure 11-6 shows an example trace path analysis, with Layer 2 and Layer 3 devices displayed. Figure 11-6 Example Trace Path Analysis Details of CDRs returned for matched criteria. Specify calling or called number, or time 49980 period for voice traces. Search performed on CDRs and all Cisco CallManagers.
Chapter 11 Network Management CiscoWorks2000 Voice Management Features Resource Manager Essentials The CiscoWorks2000 LAN management solution is also bundled with the Resource Manager Essentials (RME), which are primarily responsible for inventory control, system configuration repository and configuration management, syslog server and syslog analysis, and other reporting functions. RME Release 3.
Chapter 11 Network Management CiscoWorks2000 Voice Management Features Figure 11-7 Example Device Report from RME Count of devices connected to and disconnected from the Cisco CallManager host. System information via the sysDescr and sysObjectID. 49981 Cisco CallManager hosts known to a particular Cisco CallManager RME also supports report of Multi-Service Port Report (MSP).
Chapter 11 Network Management CiscoWorks2000 Voice Management Features Syslog Standard Report. On the other hand, the Syslog messages from the unmanaged devices all go to the Unexpected Device Report. Figure 11-8 shows the administrative user interface for the Standard Report. Figure 11-8 Standard Report in CiscoWorks2000 You can also use the administrative interface of CiscoWorks2000 to define custom reports such as user URL, automated action, and message filters (as shown in Figure 11-9).
Chapter 11 Network Management CiscoWorks2000 Voice Management Features Syslog Message Filtering In addition to System Diagnostic Interface (SDI) filtering, there are two places in the Syslog Analyzer where you can perform message filtering: Note • In the Syslog Analyzer Collector (SAC) process, before the message is sent to the network • In the CiscoWorks2000 server, where the administrator can define a custom report If you set the Syslog filters on the CiscoWorks2000 server, all defined Syslog mes
Chapter 11 Network Management CiscoWorks2000 Voice Management Features Figure 11-9 Message Filter Defined for a Remote SAC Alarms The Syslog Analyzer in CiscoWorks2000 has a web-based administrative interface to define an automatic action for a set of events or Syslog messages from particular devices. In future releases of CiscoWorks2000, this feature will be enhanced further to generate alarms or traps.
Chapter 11 Network Management CiscoWorks2000 Voice Management Features Cisco IP Telephony Network Design Guide 11-20 78-11103-03
G L O S S A R Y A—B ACF admission confirm ACL access control list ADPCM adaptive differential pulse code modulation AMIS-A Audio Messaging Interchange Specification Analog ANI automatic number identification ARQ admission request ASIC application-specific integrated circuit AVVID See Cisco AVVID. BRI Basic Rate Interface. See also PRI.
Glossary Cisco AVVID Cisco Architecture for Voice, Video, and Integrated Data CLID calling line ID CO central office codec coder-decoder CoS class of service CPE customer premises equipment.
Glossary EIGRP Enhanced Interior Gateway Routing Protocol FB forward-busy FIFO first-in, first-out FNA forward-no-answer FXO foreign exchange office FXS foreign exchange station G—H GK gatekeeper GW gateway H.
Glossary LCD liquid crystal display LDAP Lightweight Directory Access Protocol LFI link fragmentation and interleaving LLQ low latency queuing M MCM Multimedia Conference Manager MCS media convergence server MGCP Media Gateway Control Protocol MIME Multipurpose Internet Mail Extension MLPPP Multilink Point-to-Point Protocol MTP media termination point MWI message waiting indicator N—Q NIC network interface card OSPF Open Shortest Path First PBX Private Branch Exchange PCM pulse
Glossary POTS plain old telephone service PQ priority queueing PRI Primary Rate Interface PSTN public switched telephone network PVID port VLAN ID QoS quality of service R RAS Registration, Admission, and Status protocol route list Replaces route point in CallManager 3.0.
Glossary T—U TAPI Telephony Application Programming Interface. See also JTAPI.
I A N D E X for QoS 8-11 gatekeeper 3-15, 6-8, 6-15 additional information xvii locations 3-18, 7-4 addresses 2-21, 2-26 Call Detail Record (CDR) 11-1 admission control 3-15, 3-18, 6-3 called party transformation 5-9 for centralized call processing 7-3 calling party transformation 5-9 for QoS 8-11 calling search space 5-14, 5-15 gatekeeper 3-15, 6-8, 6-15 campus infrastructure 2-1 locations 3-18, 7-4 Campus Manager 11-11 alarms 11-19 Catalyst switches 9-1 ANI 11-8 4000 family 9-13 assi
Index Resource Manager Essentials (RME) 11-15 CORBA 11-4 User Tracking (UT) 11-12 CoS 2-28 class of service (CoS) 2-28 clusters 3-1 communication between 3-14 communication within 3-5 D database for centralized systems 7-8 publisher 3-1, 3-5 guidelines 3-12 subscriber 3-5 in distributed systems 6-30 default power allocation 2-14 provisioning 3-14 design goals 1-1 size of 3-1 device pools 3-9 with centralized call processing 3-18 devices with distributed call processing 3-15 in route grou
Index digital signal processor (DSP) 9-1 F digit translation 5-9 distributed call processing 1-7, 3-15, 6-1 features required for gateway selection 4-1 documentation feature transparency 3-21 CD-ROM xviii obtaining xviii ordering from Cisco xviii G World Wide Web xviii gatekeeper 3-15, 6-8, 6-15, 6-19 your feedback xix gateways 4-1 DPA 7630 10-20 list of 4-2 described 10-20 required features 4-1 integration modes 10-22 site requirements 4-9 DSP 9-1 supported protocols 4-2 for centralize
Index intercluster communication 3-14 MIB 11-2 interface queuing 8-2 migration to IP telephony network 10-1 intracluster communication 3-5 MTP 9-7 IP addresses 2-21, 2-26 multisite 1-5 IP phones 2-25 with centralized call processing 1-10, 7-1 addresses 2-21, 2-26 with distributed call processing 1-7, 6-1 external power supply 2-17 with independent call processing 1-5 internals 2-5 power consumption 2-15 power to 2-10 wall power 2-20 IP telephony N network design 1-1 composite model 1-1 desi
Index PSTN 5-12 P publisher of the database 3-1 partitions 5-14, 5-15 PBX migration 10-1 physical connections 2-9 power Q QoS 2-28, 2-33, 8-1 consumption 2-15 quality of service (QoS) 2-28 default allocation 2-14 queuing 8-2 error messages 2-16 external patch panel 2-17 for IP phones 2-10 R from Catalyst module 2-10 redundancy 2-7, 3-6 inline 2-10 supported in IOS H.
Index Analyzer Collector (SAC) 11-4 S Collector 11-1, 11-4 SAC 11-4 components 11-3 SAenvProperties.
Index U UDP 11-4 uninterrruptible power supply (UPS) 2-4 UPS 2-4 User Datagram Protocol (UDP) 11-4 User Tracking (UT) 11-12 UT 11-12 V VLAN 2-22, 2-23, 2-24 voice compression 9-7 voice messaging for centralized systems 7-12 for distributed systems 6-32 migration to IP network 10-1 Voice VLAN ID (VVID) 2-22 VVID 2-22 W wall power 2-20 WAN bandwidth provisioning 8-4 multisite with centralized call processing 7-1 multisite with distributed call processing 6-1 QoS 8-1 Cisco IP Telephony Network Design Guide
Index Cisco IP Telephony Network Design Guide 8 78-11103-03
