Solution Reference Network Design Guide 7.X

Cisco Unified CommunicationsSolution Reference Network Design(SRND)Based on Cisco Unified Communications Manager Release 7.xJuly 21, 2010Americas HeadquartersCisco Systems, Inc.170 West Tasman DriveSan Jose, CA 95134-1706USAhttp://www.cisco.comTel: 408 526-4000 800 553-NETS (6387)Fax: 408 527-0883Text Part Number: OL-16394-07

ALL DESIGNS, SPECIFICATIONS, STATEMENTS, INFORMATION, AND RECOMMENDATIONS (COLLECTIVELY, "DESIGNS") IN THIS MANUAL AREPRESENTED "AS IS," WITH ALL FAULTS. CISCO AND ITS SUPPLIERS DISCLAIM ALL WARRANTIES, INCLUDING, WITHOUT LIMITATION, THEWARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OR ARISING FROM A COURSE OF DEALING,USAGE, OR TRADE PRACTICE. IN NO EVENT SHALL CISCO OR ITS SUPPLIERS BE LIABLE FOR ANY INDIRECT, SPECIAL, CONSEQUENTIAL, ORINCIDENTAL DAMAGES, INCLUDING, WITHOUT LIMITATION, LOST PROFITS OR LOSS OR DAMAGE TO DATA ARISING OUT OF THE USE OR INABILITYTO USE THE DESIGNS, EVEN IF CISCO OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.THE DESIGNS ARE SUBJECT TO CHANGE WITHOUT NOTICE. USERS ARE SOLELY RESPONSIBLE FOR THEIR APPLICATION OF THE DESIGNS. THEDESIGNS DO NOT CONSTITUTE THE TECHNICAL OR OTHER PROFESSIONAL ADVICE OF CISCO, ITS SUPPLIERS OR PARTNERS. USERS SHOULDCONSULT THEIR OWN TECHNICAL ADVISORS BEFORE IMPLEMENTING THE DESIGNS. RESULTS MAY VARY DEPENDING ON FACTORS NOT TESTEDBY CISCO.Cisco and the Cisco Logo are trademarks of Cisco Systems, Inc. and/or its affiliates in the U.S. and other countries. A listing of Ciscos trademarks can be found atwww.cisco.com/go/trademarks. Third party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnershiprelationship between Cisco and any other company. (1005R)Any Internet Protocol (IP) addresses used in this document are not intended to be actual addresses. Any examples, command display output, and figures included in thedocument are shown for illustrative purposes only. Any use of actual IP addresses in illustrative content is unintentional and coincidental.Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x)© 2010 Cisco Systems, Inc. All rights reserved.

CONTENTS Preface xxxiii New or Changed Information for This Release xxxiv Revision History xxxv Obtaining Documentation, Obtaining Support, and Security Guidelines xxxv Cisco Product Security Overview xxxvCHAPTER 1 Introduction 1-1 Overview of Cisco Unified Communications 1-2 Cisco IP Network Infrastructure 1-4 Quality of Service 1-4 Call Processing Agent 1-4 Communication Endpoints 1-5 Presence 1-6 Conferencing, Messaging, and Collaboration Capabilities 1-7 Applications 1-8 Security 1-10 Network Management 1-10CHAPTER 2 Unified Communications Deployment Models 2-1 Whats New in This Chapter 2-1 Single Site 2-2 Best Practices for the Single-Site Model 2-3 Multisite with Centralized Call Processing 2-4 Best Practices for the Centralized Call Processing Model 2-6 Remote Site Survivability 2-7 Voice Over the PSTN as a Variant of Centralized Call Processing 2-11 VoPSTN Using AAR 2-13 VoPSTN Using Dial Plan 2-14 Multisite with Distributed Call Processing 2-15 Best Practices for the Distributed Call Processing Model 2-17 Call Processing Agents for the Distributed Call Processing Model 2-18 Unified CM Session Management Edition 2-18 When to Deploy Unified CM Session Management Edition 2-19 Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) OL-16394-07 iii

Contents Differences Between Unified CM Session Management Edition and Standard Unified CM Clusters 2-20 Clustering Over the IP WAN 2-21 WAN Considerations 2-22 Intra-Cluster Communications 2-23 Unified CM Publisher 2-23 Call Detail Records (CDR) and Call Management Records (CMR) 2-24 Delay Testing 2-24 Error Rate 2-25 Troubleshooting 2-25 Local Failover Deployment Model 2-25 Unified CM Provisioning for Local Failover 2-29 Gateways for Local Failover 2-30 Voicemail for Local Failover 2-30 Music on Hold and Media Resources for Local Failover 2-30 Remote Failover Deployment Model 2-30 Design Considerations for Section 508 Conformance 2-32CHAPTER 3 Network Infrastructure 3-1 Whats New in This Chapter 3-3 LAN Infrastructure 3-4 LAN Design for High Availability 3-4 Campus Access Layer 3-4 Routed Access Layer Designs 3-7 Campus Distribution Layer 3-9 Campus Core Layer 3-13 Network Services 3-14 Power over Ethernet (PoE) 3-29 Category 3 Cabling 3-30 IBM Type 1A and 2A Cabling 3-30 LAN Quality of Service (QoS) 3-31 Traffic Classification 3-32 Interface Queuing 3-34 Bandwidth Provisioning 3-34 Impairments to IP Communications if QoS is Not Employed 3-35 WAN Infrastructure 3-35 WAN Design and Configuration 3-36 Deployment Considerations 3-36 Guaranteed Bandwidth 3-37 Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) iv OL-16394-07

Contents Dynamic Multipoint VPN (DMVPN) 3-38 Best-Effort Bandwidth 3-38 WAN Quality of Service (QoS) 3-39 Traffic Prioritization 3-40 Link Efficiency Techniques 3-42 Traffic Shaping 3-43 Resource Reservation Protocol (RSVP) 3-46 RSVP Principles 3-46 RSVP in MPLS Networks 3-49 RSVP and QoS in WAN Routers 3-52 RSVP Application ID 3-56 RSVP Design Best Practices 3-58 Bandwidth Provisioning 3-58 Provisioning for Bearer Traffic 3-60 Provisioning for Call Control Traffic with Centralized Call Processing 3-67 Provisioning for Call Control Traffic with Distributed Call Processing 3-72 Wireless LAN Infrastructure 3-72 WLAN Design and Configuration 3-73 Wireless Infrastructure Considerations 3-73 Wireless AP Configuration and Design 3-76 Wireless Security 3-77 WLAN Quality of Service (QoS) 3-79 Traffic Classification 3-80 Interface Queuing 3-80 Bandwidth Provisioning 3-81CHAPTER 4 Gateways 4-1 Whats New in This Chapter 4-1 Traffic Patterns and Gateway Sizing 4-2 Definitions and Terminology 4-2 PSTN Traffic Patterns 4-3 Normal Business Traffic Profile 4-3 Contact Center Traffic Profile 4-3 Gateway Sizing for Contact Center Traffic 4-4 Voice Activity Detection (VAD) 4-5 Codec 4-5 Performance Overload 4-5 Performance Tuning 4-5 Additional Information 4-6 Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) OL-16394-07 v

Contents TDM and VoIP Trunking Gateways 4-7 Understanding Cisco Gateways 4-7 Cisco Access Analog Gateways 4-7 Cisco Access Digital Trunk Gateways 4-8 Tuning Gateway Gain Settings 4-8 Gateway Selection 4-8 Core Feature Requirements 4-8 Gateway Protocols 4-9 Gateway Protocols and Core Feature Requirements 4-11 DTMF Relay 4-12 Supplementary Services 4-13 Unified CM Redundancy 4-16 Site-Specific Gateway Requirements 4-18 QSIG Support 4-26 Fax and Modem Support 4-27 Gateway Support for Fax Passthrough and Fax Relay 4-27 Best Practices 4-29 Super-Group 3 Fax Support 4-30 Gateway Support for Modem Passthrough and Modem Relay 4-31 Best Practices 4-32 V.90 Support 4-33 Supported Platforms and Features 4-33 Platform Protocol Support 4-33 Gateway Configuration Examples 4-34 Cisco IOS Gateway Configuration for Modem Passthrough 4-35 Cisco VG248 Configuration for Modem Passthrough 4-35 Clock Sourcing for Fax and Modem Passthrough 4-36 T.38 Fax Relay 4-36 Named Service Event (NSE) T.38 Fax Relay 4-37 Protocol-Based T.38 Fax Relay 4-37 Gateways for Video Telephony 4-39 Routing Inbound Calls from the PSTN 4-40 Routing Outbound Calls to the PSTN 4-42 Automated Alternate Routing (AAR) 4-43 Least-Cost Routing 4-45 ISDN B-Channel Binding, Rollover, and Busy Out 4-45 Inbound Calls 4-46 Outbound Calls 4-47 Configuring the Gateways in Unified CM 4-47 Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x)vi OL-16394-07

Contents Call Signaling Port Numbers 4-47 Call Signaling Timers 4-48 Bearer Capabilities of Voice Gateways 4-48CHAPTER 5 Cisco Unified CM Trunks 5-1 Whats New in This Chapter 5-1 A Comparison of H.323 and SIP Trunks 5-2 Overview of H.323 Trunks 5-3 Overview of SIP Trunks 5-4 IP PSTN and IP Trunks to Service Provider Networks 5-5 Cisco Unified Border Element 5-5 Cisco Unified SIP Proxy 5-6 H.323 Trunks 5-7 Intercluster Trunk (Non-Gatekeeper Controlled) 5-7 Intercluster Trunk (Gatekeeper Controlled) 5-8 H.225 Trunk (Gatekeeper Controlled) 5-8 Gatekeeper Trunk Redundancy, Resilience, and Load Balancing 5-9 H.323 Trunks with Media Termination Points 5-14 H323 Outbound FastStart Call Connections 5-14 Other MTP Uses 5-14 H.323 Operation in Unified CM 5-15 SIP Trunks 5-17 General Deployment Considerations 5-17 DTMF Transport 5-18 SIP Delayed Offer and Early Offer 5-19 Media Termination Points 5-20 SIP Trunk Transport Protocols 5-20 SIP Intercluster Trunks 5-21 SRTP in SIP Trunks 5-23 Calling Party Number Normalization and SIP Trunks 5-23 Codec Selection Over IP Trunks 5-24 Cisco Unified CM Trunks and Emergency Services 5-25 Design Recommendations for Deploying IP Trunks 5-25CHAPTER 6 Media Resources 6-1 Whats New in This Chapter 6-2 Voice Termination 6-2 Medium and High Complexity Mode 6-3 Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) OL-16394-07 vii

Contents Flex Mode 6-3 DSP Resources for Voice Termination 6-4 Redundancy and Failover Considerations for Cisco IOS-Based Media Resources 6-9 Audio Conferencing 6-10 Audio Conferencing Resources 6-10 Video Conferencing 6-13 Secure Conferencing 6-13 Transcoding 6-15 Transcoding Resources 6-16 Media Termination Point (MTP) 6-17 Re-Packetization of a Stream 6-18 DTMF Conversion 6-18 DTMF Between Endpoints 6-19 SIP Trunk 6-20 SIP Early Offer 6-20 DTMF Relay over SIP Trunks 6-20 SIP Trunk MTP Requirements 6-21 Configuration of DTMF on SIP Gateways 6-22 H.323 Trunks and Gateways 6-22 H.323 Supplementary Services 6-22 H.323 Outbound Fast Connect 6-22 DTMF Relay over H.323 Trunks 6-23 Configuration of DTMF on H.323 Gateways 6-23 CTI Route Points 6-23 MTP Usage with a Conference Bridge 6-24 MTP Resources 6-24 Trusted Relay Point 6-25 Annunciator 6-25 Cisco RSVP Agent 6-27 Cisco IP Voice Media Streaming Application 6-27 Hardware and Software Capacities 6-28 PVDMs 6-28 Cisco 2900 and 3900 Series Platforms 6-29 Cisco 2800 and 3800 Series Platforms 6-30 Network Modules 6-30 Calculating DSP Requirements for the NM-HDV 6-31 General Design Guidelines 6-31 Media Resource Groups and Lists 6-31 Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x)viii OL-16394-07

Contents Media Functions and Voice Quality 6-32 Deployment Models 6-33 IP PSTN Access 6-35CHAPTER 7 Music on Hold 7-1 Whats New in This Chapter 7-2 Deployment Basics of MoH 7-2 Unicast and Multicast MoH 7-2 Co-resident and Standalone MoH 7-3 Fixed and Audio File MoH Sources 7-4 MoH Server as Part of the Unified CM Cluster 7-5 Basic MoH and MoH Call Flows 7-5 Basic MoH 7-5 User and Network Hold 7-7 Unicast and Multicast MoH Call Flows 7-8 MoH Configuration Considerations and Best Practices 7-9 Codec Selection 7-9 Multicast Addressing 7-9 MoH Audio Sources 7-10 Using Multiple Fixed (Live) Audio Sources 7-10 Unicast and Multicast in the Same Unified CM Cluster 7-11 Redundancy 7-12 Quality of Service (QoS) 7-12 Hardware and Capacity Planning for MoH Resources 7-13 Server Platform Limits 7-13 Resource Provisioning and Capacity Planning 7-14 Implications for MoH With Regard to IP Telephony Deployment Models 7-15 Single-Site Campus (Relevant to All Deployments) 7-15 Centralized Multisite Deployments 7-15 Call Admission Control and MoH 7-16 Multicast MoH from Branch Routers 7-17 Distributed Multisite Deployments 7-20 Clustering Over the WAN 7-21 Detailed Unicast and Multicast MoH Call Flows 7-21 SCCP Call Flows 7-21 SIP Call Flows 7-24CHAPTER 8 Call Processing 8-1 Whats New in This Chapter 8-2 Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) OL-16394-07 ix

Contents Unified CM Cluster Guidelines 8-2 Hardware Platforms 8-2 Unified CM Cluster Services 8-4 Intracluster Communications 8-5 Intracluster Security 8-7 Publisher 8-8 Call Processing Subscriber 8-8 TFTP Server 8-13 CTI Manager 8-13 IP Voice Media Streaming Application 8-14 Voice Activity Detection 8-14 Unified CM Applications 8-15 Unified CM Platform Capacity Planning 8-15 Unified CM Support for Locations and Regions 8-16 Unified CM Support for Gateways and Trunks 8-17 Capacity Calculations 8-18 Computer Telephony Integration (CTI) 8-18 CTI Architecture 8-19 CTI Applications and Clustering Over the WAN 8-20 Unified CM Capacity Planning 8-22 Provisioning 8-23 Implementation 8-26 Gatekeeper Design Considerations 8-26 Hardware Platform Selection 8-27 Gatekeeper Redundancy 8-27 Hot Standby Router Protocol (HSRP) 8-27 Gatekeeper Clustering (Alternate Gatekeeper) 8-30 Directory Gatekeeper Redundancy 8-33 Interoperability of Unified CM and Unified CM Express 8-36 Overview of Interoperability Between Unified CM and Unified CME 8-37 Call Types and Call Flows 8-37 Music on Hold 8-37 Ad Hoc and Meet Me Hardware Conferencing 8-38 Unified CM and Unified CME Interoperability via SIP in a Multisite Deployment with Distributed Call Processing 8-38 Best Practices 8-39 Design Considerations 8-39 Unified CM and Unified CME Interoperability via H.323 in a Multisite Deployment with Distributed Call Processing 8-42 Best Practices 8-43 Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x)x OL-16394-07

Contents Design Considerations 8-44CHAPTER 9 Call Admission Control 9-1 Whats New in This Chapter 9-2 Call Admission Control Principles 9-3 Topology-Unaware Call Admission Control 9-3 Topology-Aware Call Admission Control 9-7 Special Considerations for MPLS Networks 9-11 Call Admission Control Elements 9-12 Unified CM Static Locations 9-12 Locations and Regions Settings 9-14 Unified CM Support for Locations and Regions 9-15 Cisco IOS Gatekeeper Zones 9-16 Unified CM RSVP-Enabled Locations 9-18 Cisco RSVP Agent Provisioning 9-20 Cisco RSVP Agent Registration 9-21 RSVP Policy 9-24 Migrating from Static Locations to RSVP Call Admission Control 9-25 RSVP Application ID 9-28 Cisco IOS Gatekeeper and Cisco Unified Border Element with RSVP 9-29 Via-Zone Gatekeeper 9-30 Design Best Practices 9-31 Redundancy 9-32 Configuration Guidelines 9-33 Call Admission Control Design 9-37 Simple Hub-and-Spoke Topologies 9-37 Centralized Unified CM Deployments 9-38 Distributed Unified CM Deployments 9-39 Two-Tier Hub-and-Spoke Topologies 9-41 Centralized Unified CM Deployments 9-42 Distributed Unified CM Deployments 9-44 Simple MPLS Topologies 9-45 Centralized Unified CM Deployments 9-47 Distributed Unified CM Deployments 9-50 Generic Topologies 9-52 Centralized Unified CM Deployments 9-53 Distributed Unified CM Deployments 9-56 Design Recommendations for Call Admission Control 9-62 Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) OL-16394-07 xi

ContentsCHAPTER 10 Dial Plan 10-1 Whats New in This Chapter 10-2 Dial Plan Enhancements in Unified CM 7.x 10-2 Overview of the New Dial Plan Features 10-3 Local Route Group 10-3 Support for + Dialing 10-3 Calling Party Number Transformations 10-4 Called Party Number Transformations 10-4 Incoming Calling Party Settings (per Gateway) 10-4 Logical Partitioning 10-5 Planning Considerations 10-6 Dialed Pattern Recognition 10-6 Grouping by Dialing Habits 10-7 On-Net versus Off-Net Dialing 10-7 Abbreviated Dialing 10-8 Avoiding Overlap of Extension Dialing 10-8 Dialing String Length 10-9 Uniform On-Net Dial Plan 10-9 Variable Length On-Net Dial Plan 10-11 On-Net and Off-Net Access Codes 10-11 Plan Ahead 10-12 Design Considerations 10-12 New Design Approach 10-13 Localized Call Ingress 10-13 Globalized Call Routing 10-17 Localized Call Egress 10-17 Benefits of the New Design Approach 10-19 Automated Alternate Routing (AAR) 10-19 Cisco Emergency Responder 10-20 Call Forward Unregistered (CFUR) 10-20 Tail End Hop Off (TEHO) 10-20 Design Guidelines for Multisite Deployments 10-21 Choosing a Dial Plan Approach 10-24 Deploying Uniform On-Net Dial Plans 10-26 Inter-Site Calls Within a Cluster 10-28 Outgoing PSTN and IP WAN Calls 10-28 Emergency Calls 10-28 Incoming Calls 10-28 Voicemail Calls 10-28 Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) xii OL-16394-07

Contents Deploying Variable-Length On-Net Dial Plans with Flat Addressing 10-29 Inter-Site Calls Within a Cluster 10-31 Outgoing PSTN and IP WAN Calls 10-32 Incoming Calls 10-34 Voicemail Calls 10-35 Special Considerations for Deployments Without Site Codes 10-35 Deploying Dialed Pattern Recognition in SIP Phones 10-37 Building Classes of Service for Unified CM 10-39 Building Classes of Service for Unified CM with the Traditional Approach 10-39 Building Classes of Service for Unified CM with the Line/Device Approach 10-43 Building Classes of Service in Cisco IOS with H.323 10-51 Deploying Call Coverage 10-54 Deploying Call Coverage in a Multisite Centralized Call Processing Model 10-55 Deploying Call Coverage in a Multisite Distributed Call Processing Model 10-56 Hunt Pilot Scalability 10-57 Dial Plan Elements 10-58 User Interface on IP Phones 10-58 Calling Party Transformations on IP Phones 10-59 Support for + Dialing on the Phones 10-59 User Input on SCCP Phones 10-59 User Input on Type-A SIP Phones 10-60 User Input on Type-B SIP Phones 10-62 SIP Dial Rules 10-63 Call Routing in Unified CM 10-66 Support for + Sign in Patterns 10-67 External Routes in Unified CM 10-67 Route Patterns 10-68 Route Lists 10-72 Route Groups 10-72 Calling and Called Party Transformation Patterns 10-72 Incoming Calling Party Settings (per Gateway) 10-74 Route Group Devices 10-75 Local Route Group 10-75 Centralized Gateway with Local Failover to the PSTN 10-77 Calling Privileges in Unified CM 10-78 Partitions 10-79 Calling Search Spaces 10-80 Translation Patterns 10-85 Automated Alternate Routing 10-86 Establish the PSTN Number of the Destination 10-86 Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x)OL-16394-07 xiii

Contents Prefix the Required Access Codes 10-87 Voicemail Considerations 10-88 Select the Proper Dial Plan and Route 10-89 Special Considerations for Sites Located Within the Same Local Dialing Area 10-89 Device Mobility 10-90 Extension Mobility 10-92 Special Considerations for Cisco Unified Mobility 10-93 Immediate Divert (iDivert) 10-98 Hunt Lists and Line Groups 10-99 Hunt Pilot 10-99 Hunt List 10-100 Line Group 10-100 Hunt Group Logout 10-101 Line Group Devices 10-101 Time-of-Day Routing 10-102 Logical Partitioning 10-103 Logical Partitioning Device Types 10-104 Geolocation Creation 10-104 Geolocation Assignment 10-105 Geolocation Filter Creation 10-105 Geolocation Filter Assignment 10-105 Logical Partitioning Policy Configuration 10-105 Logical Partitioning Policy Application 10-106 Call Routing in Cisco IOS with H.323 Dial Peers 10-106 Call Routing in Cisco IOS with a Gatekeeper 10-109 Centralized Gatekeeper Configuration 10-113 Distributed Gatekeeper Configuration 10-115 Distributed Gatekeeper Configuration with Directory Gatekeeper 10-116 Calling Privileges in Cisco IOS with H.323 Dial Peers 10-118 Digit Manipulation in Cisco IOS with H.323 Dial Peers 10-120CHAPTER 11 Emergency Services 11-1 Planning for 911 Functionality 11-2 Public Safety Answering Point (PSAP) 11-2 911 Network Service Provider 11-2 Interface Points into the Appropriate 911 Networks 11-3 Interface Type 11-4 Dynamic ANI (Trunk Connection) 11-4 Static ANI (Line Connection) 11-6 Emergency Response Location Mapping 11-6 Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) xiv OL-16394-07

Contents Emergency Location Identification Number Mapping 11-7 Nomadic Phone Considerations 11-9 Cisco Emergency Responder 11-9 Emergency Call String 11-10 Gateway Considerations 11-11 Gateway Placement 11-11 Gateway Blocking 11-11 Answer Supervision 11-12 Cisco Emergency Responder Considerations 11-13 Emergency Responder Version Compatibility with Unified CM 11-13 Device Mobility Across Call Admission Control Locations 11-13 Default Emergency Response Location 11-13 Soft Clients 11-14 Test Calls 11-14 PSAP Callback to Shared Directory Numbers 11-14 Multi-Cluster Considerations 11-15 Single Cisco ER Group 11-15 Multiple Cisco ER Groups 11-17 Emergency Call Routing within a Cisco ER Cluster 11-19 Scalability Considerations for Cisco ER Clustering 11-20 ALI Formats 11-20CHAPTER 12 Third-Party Voicemail Design 12-1 Whats New in This Chapter 12-2 SMDI 12-2 Cisco Messaging Interface 12-2 Cisco VG248 12-4 Considerations When Using FXS Ports 12-4 Dual PBX Integration 12-5 Centralized Voicemail 12-5 Positive Disconnect Supervision 12-9 Summary of Third-Party Voicemail Integration 12-9CHAPTER 13 Cisco Voice Messaging 13-1 Whats New in This Chapter 13-2 Voice Messaging Portfolio 13-2 Messaging Deployment Models 13-5 Single-Site Messaging 13-6 Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) OL-16394-07 xv

Contents Centralized Messaging 13-6 Distributed Messaging 13-6 Messaging and Unified CM Deployment Model Combinations 13-7 Cisco Unity and Unity Connection Messaging and Unified CM Deployment Models 13-8 Centralized Messaging and Centralized Call Processing 13-8 Distributed Messaging with Centralized Call Processing 13-9 Combined Messaging Deployment Models 13-12 Centralized Messaging with Clustering Over the WAN 13-13 Distributed Messaging with Clustering Over the WAN 13-15 Messaging Redundancy 13-16 Cisco Unity 13-16 Cisco Unity Connection 13-17 Cisco Unity Failover and Clustering Over the WAN 13-17 Centralized Messaging with Distributed Unified CM Clusters 13-19 Cisco Unity Express Deployment Models 13-19 Overview of Cisco Unity Express 13-20 Deployment Models 13-21 Fax Deployment 13-25 Cisco Unity and Unity Connection Fax Deployment 13-25 Cisco Unity Express Fax Deployment 13-25 Voicemail Networking 13-28 Cisco Unity Express Voicemail Networking 13-28 Voicemail Networking with Cisco Unified Messaging Gateway 13-29 Best Practices for Voice Messaging 13-31 Best Practices for Deploying Cisco Unity and Cisco Unity Connection with Unified CM 13-31 Managing Bandwidth 13-31 Native Transcoding Operation 13-32 Cisco Unity Operation 13-33 Disabling Native Transcoding in Cisco Unity 13-33 Cisco Unity Connection Operation 13-33 Integration with Unified CM 13-35 Best Practices for Deploying Cisco Unity Express 13-41 Voicemail Integration with Unified CM 13-41 Cisco Unity Express Codec and DTMF Support 13-42 JTAPI, SIP Trunk and SIP Phone Support 13-42CHAPTER 14 Cisco Unified MeetingPlace 14-1 What’s New in This Chapter 14-1 Cisco Unified MeetingPlace Components 14-2 Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) xvi OL-16394-07

Contents Unified MP Deployment Models 14-3 Single-Site Unified MP Deployment 14-3 Reservationless Single-Number Access Deployment 14-5 Segmented Meeting Access Option 14-7 Integrating Unified MP with SIP and H.323 Call Processing Agents 14-8 SIP 14-8 H.323 14-8 Call Admission Control, QoS, and Bandwidth 14-9 Call Admission Control 14-9 QoS Markings 14-10 Bandwidth 14-10 DTMF Support 14-11 External Directory Integration via Unified CM 14-11 Unified MP and Cisco WebEx Integration 14-12 Capacity and Sizing 14-14 Unified MP Media Server 14-14 Virtual Cascading 14-15 Guidelines for Sizing Unified MP Audio Conferencing 14-15 Guidelines for Sizing Unified MP Video Conferencing 14-16 Unified MP Web Collaboration Server 14-16 Guidelines for Sizing Unified MP Web Conferencing 14-17 Redundancy 14-18 Unified MP Application Server 14-18 Single Data Center Design 14-19 Dual Data Center Design 14-19 Unified MP Media Server 14-20 Unified MP Web Collaboration Server 14-20 Call Control 14-21CHAPTER 15 Cisco Unified MeetingPlace Express 15-1 Whats New in This Chapter 15-1 Overview 15-1 Conferencing Support 15-2 Video Support 15-2 Protocol Support 15-3 DTMF Support 15-4 Deployment Models 15-4 Single Site 15-4 Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) OL-16394-07 xvii

Contents Multisite WAN with Centralized Call Processing 15-6 Multisite WAN with Distributed Call Processing 15-7 Clustering Over the WAN 15-8 Segmented Meeting Access Option 15-9 Call Admission Control, Bandwidth, and QoS 15-10 Call Admission Control 15-10 Bandwidth Considerations for Web Applications and Screen Sharing 15-10 QoS 15-12 External Directory Integration via Unified CM 15-12 H.323 and SIP Integration with Unified CM 15-13 H.323 Gateway 15-14 SIP Trunk 15-14 Gatekeeper Integration 15-14 Capacity and Sizing 15-15 System Resource Unit (SRU) 15-16 Redundancy 15-16 Unified MPE Server Redundancy 15-16 Redundancy Using a Gatekeeper 15-17 Redundancy Using H.323 Gateway Integration 15-17 Redundancy Using SIP Trunk Integration 15-18 Other Important Design Considerations 15-18CHAPTER 16 IP Video Telephony 16-1 Whats New in This Chapter 16-1 IP Video Telephony Solution Components 16-1 Administration Considerations 16-2 Protocols 16-2 Regions 16-4 Topology-Aware Locations 16-6 Retry Video Call as Audio 16-8 Wait for Far-End to Send TCS 16-11 Multipoint Conferencing 16-13 SCCP MCU Resources 16-16 Media Resource Groups and Lists 16-17 Intelligent Bridge Selection 16-18 H.323 and SIP MCU Resources 16-18 Sizing the MCU 16-20 IVR for Dial-In Conference 16-21 Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) xviii OL-16394-07

Contents Gatekeepers 16-22 Supported Gatekeeper Platforms 16-25 Endpoint Gatekeepers 16-26 Provisioning H.323 Clients 16-26 Provisioning H.323 MCUs 16-31 Provisioning H.320 Gateways 16-32 Gatekeeper Zone Configuration 16-33 Summary of Endpoint Gatekeepers 16-41 Applications 16-44 CTI Applications 16-44 Cisco Emergency Responder 16-44 Cisco Unified Communications Manager Assistant 16-45 Cisco Unified IP Interactive Voice Response and Cisco Unified Contact Center 16-45 Cisco Attendant Console 16-46 Cisco IP SoftPhone and Cisco IP Communicator 16-46 Collaboration Solutions 16-46 T.120 Application Sharing 16-46 Cisco Unified MeetingPlace 16-46 Wireless Networking Solutions 16-47 Cisco Unified Wireless IP Phones 7920 and 7921 16-47 XML Services 16-47CHAPTER 17 LDAP Directory Integration 17-1 Whats New in This Chapter 17-2 What is Directory Integration? 17-2 Directory Access for IP Telephony Endpoints 17-3 Directory Integration with Unified CM 17-5 Cisco Unified Communications Directory Architecture 17-6 LDAP Synchronization 17-9 Synchronization Mechanism 17-13 Security Considerations 17-15 Best Practices for LDAP Synchronization 17-15 Additional Considerations for Microsoft Active Directory 17-16 LDAP Authentication 17-17 Additional Considerations for Microsoft Active Directory 17-20 Sizing Unified CM Database Synchronization 17-22 Using the LDAP Structure to Control Synchronization 17-23 Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) OL-16394-07 xix

ContentsCHAPTER 18 IP Telephony Migration Options 18-1 Whats New in This Chapter 18-1 IP Telephony Migration 18-1 Phased Migration 18-2 Parallel Cutover 18-3 The Need for QSIG in Multisite Enterprises 18-3 Summary of IP Telephony Migration 18-5 Video Migration 18-5 Dedicated H.323 Video Network 18-5 ISDN Endpoints 18-6 Migration of Voice and Desktop Collaboration Systems 18-6 Hosted Systems 18-6 On-Premises System 18-6CHAPTER 19 Voice Security 19-1 Whats New in This Chapter 19-1 General Security 19-2 Security Policy 19-2 Security in Layers 19-3 Secure Infrastructure 19-4 Physical Security 19-4 IP Addressing 19-5 Phone Security 19-5 PC Port on the Phone 19-6 Gratuitous ARP 19-6 PC Voice VLAN Access 19-7 Web Access 19-8 Video Capabilities 19-9 Settings Access 19-9 Phone Authentication and Encryption 19-10 Access Security 19-11 Voice and Video VLANs 19-11 Switch Port 19-12 Port Security: MAC CAM Flooding 19-13 Port Security: Prevent Port Access 19-14 Port Security: Prevent Rogue Network Extensions 19-14 DHCP Snooping: Prevent Rogue DHCP Server Attacks 19-16 DHCP Snooping: Prevent DHCP Starvation Attacks 19-17 Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) xx OL-16394-07

Contents DHCP Snooping: Binding Information 19-19 Requirement for Dynamic ARP Inspection 19-20 Quality of Service 19-24 Access Control Lists 19-24 VLAN Access Control Lists 19-24 Router Access Control Lists 19-26 Gateways and Media Resources 19-28 Putting Firewalls Around Gateways 19-29 Firewalls and H.323 19-30 Firewalls 19-31 Routed ASA and PIX 19-34 Transparent ASA and PIX 19-34 ASA TLS Proxy Feature 19-35 ASA and PIX Configuration Example 19-36 FWSM Routed Mode 19-37 FWSM Transparent Mode 19-37 FWSM Configuration Example 19-38 Data Center 19-39 Applications Servers 19-40 Cisco Security Agent on the Unified CM and Application Servers 19-40 Unmanaged Cisco Security Agent 19-40 Managed Cisco Security Agent 19-41 Antivirus 19-41 General Server Guidelines 19-41 Deployment Examples 19-42 Lobby Phone Example 19-42 Firewall Deployment Example (Centralized Deployment) 19-44 Securing Network Virtualization 19-45 Scenario 1: Single Data Center 19-46 Scenario 2: Redundant Data Centers 19-47 Conclusion 19-49CHAPTER 20 Unified Communications Endpoints 20-1 Whats New in This Chapter 20-1 Recommendations for Selecting Endpoints 20-2 Analog Gateways 20-3 Analog Interface Module 20-3 Low-Density Analog Interface Module 20-3 Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) OL-16394-07 xxi

Contents High-Density Analog Interface Module 20-4 Supported Platforms and Cisco IOS Requirements for Analog Interface Modules 20-5 Cisco Communication Media Module (CMM) 20-6 WS-X6624-FXS Analog Interface Module 20-6 Cisco VG202 and VG204 Gateways 20-6 Cisco VG224 Gateway 20-6 Cisco VG248 Gateway 20-7 Cisco ATA 186 and 188 20-7 Cisco Unified IP Phones 20-7 Cisco Basic IP Phones 20-7 Cisco Unified SIP Phone 3911 20-8 Cisco Unified IP Phone 7902G 20-8 Cisco Unified IP Phone 7905G 20-8 Cisco Unified IP Phone 7906G 20-8 Cisco Unified IP Phone 7910G and 7910G+SW 20-8 Cisco Unified IP Phone 7911G 20-8 Cisco Unified IP Phone 7912G 20-9 Cisco Business IP Phones 20-9 Cisco Unified IP Phone 6921 20-9 Cisco Unified IP Phone 6961 20-9 Cisco Unified IP Phone 7931G 20-9 Cisco Unified IP Phone 7940G 20-9 Cisco Unified IP Phone 7941G 20-10 Cisco Unified IP Phone 7941G-GE 20-10 Cisco Unified IP Phone 7942G 20-10 Cisco Unified IP Phone 7945G 20-10 Cisco Manager IP Phones 20-11 Cisco Unified IP Phone 6941 20-11 Cisco Unified IP Phone 7960G 20-11 Cisco Unified IP Phone 7961G 20-11 Cisco Unified IP Phone 7961G-GE 20-12 Cisco Unified IP Phone 7962G 20-12 Cisco Unified IP Phone 7965G 20-12 Cisco Unified IP Phone 8961 20-12 Cisco Executive IP Phones 20-12 Cisco Unified IP Phone 7970G 20-12 Cisco Unified IP Phone 7971G-GE 20-13 Cisco Unified IP Phone 7975G 20-13 Cisco Unified IP Phone 9951 20-13 Cisco Unified IP Phone 9971 20-13 Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x)xxii OL-16394-07

Contents Cisco Unified IP Phone Expansion Modules 7914, 7915, and 7916 20-14 Deployment Considerations for Cisco Unified IP Phones 6900 Series 20-14 Deployment Considerations for Cisco Unified IP Phones 8900 and 9900 Series 20-15 Firmware Upgrades 20-15 Network Connectivity Through a Wireless Interface 20-16 Power Over Ethernet 20-16 Applications 20-17 Support on SRST, Unified CME, and Unified CME as SRST 20-17 Software-Based Endpoints 20-17 Cisco Unified Personal Communicator 20-17 Cisco IP Communicator 20-18 Cisco Unified Client Services Framework 20-18 Softphone Mode of Operation 20-19 Deskphone Mode of Operation 20-19 Wireless Endpoints 20-19 Site Survey 20-20 Authentication 20-20 Capacity 20-22 Phone Configuration 20-23 Roaming 20-23 AP Call Admission Control 20-24 Bluetooth Support 20-25 Cisco Unified IP Conference Station 20-25 Video Endpoints 20-26 SCCP Video Endpoints 20-26 Cisco Unified Video Advantage 20-26 Cisco IP Video Phone 7985G 20-29 Codecs Supported by Cisco Unified Video Advantage and Cisco IP Video Phone 7985G 20-29 Third-Party SCCP Video Endpoints 20-30 Third-Party SIP IP Phones 20-31 QoS Recommendations 20-31 Cisco VG224 and VG248 20-31 Cisco ATA 186 and IP Conference Station 20-32 Cisco ATA 188 and IP Phones 20-32 Software-Based Endpoints 20-37 Cisco Unified Wireless IP Phones 20-39 Video Telephony Endpoints 20-40 Cisco Unified Video Advantage with a Cisco Unified IP Phone 20-41 Cisco IP Video Phone 7985G 20-43 Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x)OL-16394-07 xxiii

Contents Sony and Tandberg SCCP Endpoints 20-43 H.323 and SIP Video Endpoints 20-45 Endpoint Features Summary 20-47CHAPTER 21 Device Mobility 21-1 Need for Device Mobility 21-2 Device Mobility Feature 21-3 Dial Plan Design Considerations 21-7 Device Mobility Considerations for Building Classes of Service 21-7 Traditional Approach 21-7 Line/Device Approach 21-9 Choosing a Dial Plan Model 21-11 Uniform On-Net Dialing Using the Line/Device Approach 21-11 Variable Length On-Net Dialing with Partitioned Addressing Using the Line/Device Approach 21-13 Variable Length On-Net Dialing with Flat Addressing Using the Line/Device Approach 21-15 Design Guidelines for Using a VPN 21-16CHAPTER 22 Cisco Unified Presence 22-1 Whats New in This Chapter 22-2 Presence 22-3 Cisco Unified Presence Components 22-3 Cisco Unified Presence User 22-4 Unified CM Presence 22-5 Unified CM Presence with SIP 22-5 Unified CM Presence with SCCP 22-7 Unified CM Speed Dial Presence 22-7 Unified CM Call History Presence 22-8 Unified CM Presence Policy 22-8 Unified CM Subscribe Calling Search Space 22-8 Unified CM Presence Groups 22-9 Unified CM Presence Guidelines 22-9 Cisco Unified Presence Server 22-10 Cisco Unified Presence Server Cluster 22-10 Cisco Unified Presence Server Redundancy 22-13 Cisco Unified Presence Deployment Models 22-14 Cisco Unified Presence Deployment Examples 22-15 Cisco Unified Presence Server Performance 22-17 Cisco Unified Presence Licensing 22-17 Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) xxiv OL-16394-07

Contents Cisco Unified Presence Deployment 22-18 Single-Cluster Deployment 22-18 Multi-Cluster Deployment 22-21 Clustering Over the WAN 22-22 Federated Deployment 22-23 Cisco Unified Presence Server Policy 22-26 Cisco Unified Presence Calendar Integration 22-27 Cisco Unified Presence Mobility Integration 22-28 Cisco Unified Presence Third-Party Open API 22-30 Guidelines for Deploying Cisco Unified Presence 22-32 Cisco IP Phone Messenger Application 22-33 Cisco IP Phone Messenger Bandwidth Considerations 22-38 Cisco Unified Personal Communicator 22-38 Cisco Unified Personal Communicator Deployment 22-38 Design Considerations for Cisco Unified Personal Communicator 22-41 Third-Party Presence Server Integration 22-43 Microsoft Communications Server 22-43 IBM Sametime 7.5 22-45CHAPTER 23 Cisco Collaboration Clients and Applications 23-1 Cisco WebEx Connect Architecture 23-2 Cisco WebEx Connect Client 23-2 Presence 23-2 Instant Messaging 23-3 Spaces 23-3 Calendar Integration 23-3 Cisco WebEx Meeting Center Integration 23-3 Cisco Unified Communications Integration 23-4 Cisco WebEx Connect Unified Communications Widgets 23-4 Cisco Unified Communications IntegrationTM for Cisco WebEx Connect 23-4 Cisco WebEx Connect Platform 23-6 Security 23-6 Cisco WebEx Connect Deployment 23-7 High Availability 23-7 Redundancy, Failover, and Disaster Recovery 23-7 Network Requirements 23-8 Capacity and Bandwidth Requirements 23-8 Desktop Requirements 23-8 Ports and IP Address Ranges 23-9 Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) OL-16394-07 xxv

Contents Firewall Domain White List 23-9 Instant Messaging Logging 23-10 Design Considerations for Cisco WebEx Connect 23-10 One Unified CM Integration per Managed Connect Domain 23-10 Unified CM CTI Manager 23-10 Third-Party XMPP Clients Connecting to Cisco WebEx Connect Platform 23-10 Instant Message and Presence Federation Using Third-Party XMPP Clients 23-11 Other Resources and Documentation 23-11CHAPTER 24 Cisco Unified CM Applications 24-1 Whats New in This Chapter 24-2 IP Phone Services 24-2 IP Phone Services Phone Support 24-2 Unified CM Services and IP Phone Service Enterprise Parameters 24-3 Unified CM Services for IP Phone Services 24-3 IP Phone Service Enterprise Parameters 24-3 IP Phone Services Architecture 24-5 IP Phone Services Redundancy 24-8 IP Phone Services Scalability 24-9 Guidelines and Restrictions for IP Phone Services 24-9 Extension Mobility (EM) 24-9 EM Phone Support 24-10 Unified CM Services and EM Service Parameters 24-10 Unified CM Services for EM 24-10 EM Service Parameters 24-11 EM Architecture 24-12 EM Redundancy 24-14 EM Security 24-15 Guidelines and Restrictions for EM 24-16 EM Performance and Capacity 24-16 EM Interactions: Unified CM Assistant, Attendant Console, and WebDialer 24-17 Unified CM Assistant 24-17 Unified CM Assistant Phone Support 24-17 Unified CM Services and Unified CM Assistant Service Parameters 24-17 Unified CM Services for Unified CM Assistant 24-18 Unified CM Assistant Service Parameters 24-18 Unified CM Assistant Functionality and Architecture 24-20 Unified CM Assistant Proxy Line Mode 24-20 Unified CM Assistant Share Lined Mode 24-21 Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) xxvi OL-16394-07

Contents Unified CM Assistant Architecture 24-22 Unified CM Assistant Dial Plan Considerations 24-24 Unified CM Assistant Console 24-27 Unified CM Assistant Console Installation 24-27 Unified CM Assistant Desktop Console QoS 24-27 Unified CM Assistant Console Directory Window 24-27 Unified CM Assistant Phone Console QoS 24-28 Unified CM Assistant Redundancy 24-28 Service and Component Redundancy 24-29 Device and Reachability Redundancy 24-30 Guidelines and Restrictions for Unified CM Assistant 24-31 Unified CM Assistant Performance and Capacity 24-32 Unified CM Assistant Interactions with EM 24-34 Attendant Consoles 24-34 Cisco Unified Communications Manager Attendant Console 24-34 Unified CM Attendant Console Phone Support 24-35 Unified CM Services and Unified CM Attendant Console Service Parameters 24-35 Unified CM Attendant Console Functionality and Architecture 24-36 Attendant Console Desktop Application 24-39 Unified CM Attendant Console Redundancy 24-42 Guidelines and Restrictions for Unified CM Attendant Console 24-44 Unified CM Attendant Console Performance and Capacity 24-45 Unified CM Attendant Console Interactions with EM 24-45 Cisco Unified Department, Business, and Enterprise Attendant Consoles 24-46 Functionality and Architecture 24-46 Redundancy 24-48 Guidelines and Restrictions 24-49 WebDialer 24-50 WebDialer Phone Support 24-50 Unified CM Services and WebDialer Service Parameters 24-51 Unified CM Services for WebDialer 24-51 WebDialer Service Parameters 24-51 WebDialer Functionality and Architecture 24-52 WebDialer Servlet 24-52 Redirector Servlet 24-53 WebDialer Architecture 24-56 WebDialer URLs 24-57 WebDialer Redundancy 24-58 Service and Component Redundancy 24-59 Device and Reachability Redundancy 24-59 Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x)OL-16394-07 xxvii

Contents Guidelines and Restrictions for WebDialer 24-59 WebDialer Performance and Scalability 24-60 WebDialer Interactions with EM 24-61CHAPTER 25 Cisco Mobility Applications 25-1 Whats New in This Chapter 25-3 Cisco Unified Mobility 25-4 Mobile Connect 25-5 Mobile Connect Phone Support 25-6 Unified CM Service Parameters for Mobile Connect 25-6 Mobile Connect Functionality 25-7 Desk Phone Pickup 25-8 Remote Destination Phone Pickup 25-9 Mid-Call Features 25-10 Single Enterprise Voicemail Box 25-13 Enabling and Disabling Mobile Connect 25-14 Access Lists for Allowing or Blocking Mobile Connect Calls 25-14 Mobile Connect Architecture 25-15 Mobile Connect Redundancy 25-15 Unified CM Server Redundancy 25-16 PSTN Gateway Redundancy 25-16 Mobile Voice Access and Enterprise Feature Access 25-16 Mobile Voice Access and Enterprise Feature Access Phone Support 25-17 Unified CM Services and Service Parameters for Mobile Voice Access and Enterprise Feature Access 25-17 Unified CM Service for Mobile Voice Access 25-17 Unified CM Service Parameters for Mobile Voice Access and Enterprise Feature Access 25-17 Mobile Voice Access IVR VoiceXML Gateway URL 25-18 Mobile Voice Access Functionality 25-18 Mobile Voice Access Using Hairpinning 25-19 Enterprise Feature Access with Two-Stage Dialing Functionality 25-21 Desk and Remote Destination Phone Pickup 25-22 Enabling and Disabling Mobile Connect 25-22 Mobile Voice Access and Enterprise Feature Access Number Blocking 25-23 Access Numbers for Mobile Voice Access and Enterprise Feature Access 25-23 Remote Destination Configuration and Caller ID Matching 25-23 Mobile Voice Access and Enterprise Feature Access Architecture 25-24 Mobile Voice Access and Enterprise Feature Access Redundancy 25-25 Unified Mobility 25-26 Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) xxviii OL-16394-07

Contents Dial Plan Considerations for Cisco Unified Mobility 25-26 Remote Destination Profile Configuration 25-26 Automatic Caller ID Matching and Enterprise Call Anchoring 25-27 Caller ID Transformations 25-28 Maintaining and Troubleshooting Unified Mobility 25-28 Guidelines and Restrictions for Unified Mobility 25-30 Cisco Unified Mobility Performance and Capacity 25-31 Design Recommendations for Deploying Unified Mobility 25-32 Cisco Unified Mobile Communicator 25-33 Cisco Unified Mobile Communicator Phone Support and Data Plan Requirements 25-34 Cisco Unified Mobile Communicator Integration with Cisco Unified CM 25-35 Cisco Unified Mobile Communicator Architecture 25-36 Cisco Unified Mobile Communicator Features and Functionality 25-37 LDAP Directory 25-37 Cisco Unified CM 25-38 Cisco Unified Presence 25-42 Cisco Unity and Unity Connection Voice Mail 25-42 Cisco Unified MeetingPlace 25-42 Microsoft Exchange 25-43 Secure Text Messaging 25-44 Cisco Unified Mobile Communicator Redundancy 25-44 Cisco Unified Mobile Communicator Performance and Capacity 25-45 Design Recommendations for Deploying Cisco Unified Mobile Communicator 25-45 Dual-Mode Phones and Clients 25-46 Dual-Mode Phone Architecture 25-47 Voice over Wireless LAN Network Infrastructure 25-48 Dual-Mode Features and Functions 25-51 Dual-Mode Clients: Cisco Mobile 25-56 Dual-Mode Clients: Nokia Call Connect 25-59 High Availability for Dual-Mode Phones 25-64 Capacity Planning for Dual-Mode Phones 25-64 Design Considerations for Dual-Mode Phones 25-65CHAPTER 26 Network Management 26-1 Whats New in This Chapter 26-2 Network Infrastructure Requirements for Cisco Unified Network Management Applications 26-3 Cisco Unified Operations Manager 26-4 Cisco Unified Operations Manager Design Considerations 26-5 Failover and Redundancy 26-6 Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) OL-16394-07 xxix

Contents Ports and Protocols 26-6 Bandwidth Requirements 26-7 Cisco Unified Operations Manager Server Performance 26-7 Cisco Unified Service Monitor 26-7 Voice Quality Measurement 26-8 Cisco 1040 Sensor Voice Quality Monitoring 26-8 Strategic vs. Tactical Monitoring 26-9 Design Considerations for the Cisco 1040 Sensor 26-9 Unified CM Voice Quality Monitoring 26-10 Cisco Network Analysis Module (NAM) 26-10 Comparison of Voice Quality Monitoring Methods 26-11 Failover and Redundancy 26-11 Unified SM Server Performance 26-12 Ports and Protocol 26-12 Cisco Unified Service Statistics Manager 26-13 Integration with Unified OM and Unified SM 26-13 Unified SSM Server Performance 26-14 Ports and Protocol 26-15 Cisco Unified Provisioning Manager 26-15 Call Processors and Message Processors 26-16 Best Practices 26-17 Unified PM Design Considerations 26-18 Launching Cisco Unified Operations Manager 26-19 Redundancy and Failover 26-19 Cisco Unified Provisioning Manager Server Performance 26-20 Ports and Protocol 26-21 Integration with Cisco Unified Communications Deployment Models 26-21 Single Site 26-22 Multisite WAN with Centralized Call Processing 26-24 Multisite WAN with Distributed Call Processing 26-26 Clustering over the WAN 26-27CHAPTER 27 Cisco Unified Communications Manager Business Edition 27-1 Whats New in This Chapter 27-2 Deployment Models 27-2 Unified CMBE Single-Site Deployment 27-2 Benefits of a Unified CMBE Single-Site Deployment 27-5 Best Practices for a Unified CMBE Single-Site Deployment 27-5 Unified CMBE Multisite WAN Deployment with Centralized Call Processing 27-5 Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) xxx OL-16394-07

Contents Benefits of a Unified CMBE Multisite WAN Deployment with Centralized Call Processing 27-8 Best Practices for a Unified CMBE Multisite WAN Deployment with Centralized Call Processing 27-8 Unified CMBE Multisite WAN Deployment with Distributed Call Processing 27-8 Benefits of a Unified CMBE Multisite WAN Deployment with Distributed Call Processing 27-13 Best Practices for a Unified CMBE Multisite WAN Deployment with Distributed Call Processing 27-13 Dial Plan 27-13 Survivable Remote Site Telephony (SRST) 27-15 Unified CMBE Directory Management 27-17 Unified CMBE Migration 27-18 Capacity Planning and Scaling the System 27-19 Busy Hour Call Attempts (BHCA) 27-19 Device Calculations 27-20 Contact Center Example 27-21 Cisco Unified CM Applications 27-22 Cisco Extension Mobility (EM) 27-22 Cisco Unified Communications Manager Assistant (Unified CM Assistant) 27-22 Cisco Unified Communications Manager Attendant Console (AC) 27-23 Cisco WebDialer 27-23 Cisco Unified Mobility 27-24APPENDIX A Recommended Hardware and Software Combinations A-1GLOSSARYINDEX Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) OL-16394-07 xxxi

Contents Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x)xxxii OL-16394-07

Preface Last revised on: July 21, 2010 This document provides design considerations and guidelines for deploying a Cisco Unified Communications System based on Cisco Unified Communications Manager 7.x (7.0 and all subsequent 7.x releases). This document focuses on the following major components of the Cisco Unified Communications System: • Cisco Unified Communications Manager (Unified CM), formerly Cisco Unified CallManager • Cisco Unified Communications Manager Business Edition (Unified CMBE) • Cisco Unity, Unity Express, and Unity Connection • Cisco Unified MeetingPlace and Unified MeetingPlace Express • Cisco Unified Video Advantage • Cisco Unified Presence • Cisco Unified Mobility This document should be used in conjunction with other documentation available at the following locations: • For other Solution Reference Network Design (SRND) documents: http://www.cisco.com/go/ucsrnd • For more information about the Cisco Unified Communications System: http://www.cisco.com/go/unified-techinfo http://www.cisco.com • For more information about Cisco Unified Communications Manager: http://www.cisco.com/en/US/products/sw/voicesw/ps556/tsd_products_support_series_home.html http://www.cisco.com • For other Cisco design guides: http://www.cisco.com/go/designzone Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x)OL-16394-07 xxxiii

PrefaceNew or Changed Information for This Release Note Unless stated otherwise, the information in this document applies to Cisco Unified Communications Manager 7.x (7.0 and all subsequent 7.x releases). Any differences between the various releases of Cisco Unified Communications Manager are specifically noted in the text. The following chapters are either new in the current release of this document, or they contain information that has changed significantly from previous releases of this document. • Unified Communications Deployment Models, page 2-1 • Network Infrastructure, page 3-1 • Gateways, page 4-1 • Cisco Unified CM Trunks, page 5-1 • Media Resources, page 6-1 • Music on Hold, page 7-1 • Call Processing, page 8-1 • Call Admission Control, page 9-1 • Dial Plan, page 10-1 • Third-Party Voicemail Design, page 12-1 • Cisco Voice Messaging, page 13-1 • Cisco Unified MeetingPlace, page 14-1 • Cisco Unified MeetingPlace Express, page 15-1 • IP Video Telephony, page 16-1 • LDAP Directory Integration, page 17-1 • IP Telephony Migration Options, page 18-1 • Voice Security, page 19-1 • Unified Communications Endpoints, page 20-1 • Cisco Unified Presence, page 22-1 • Cisco Collaboration Clients and Applications, page 23-1 • Cisco Unified CM Applications, page 24-1 • Cisco Mobility Applications, page 25-1 • Network Management, page 26-1 • Cisco Unified Communications Manager Business Edition, page 27-1 Within each chapter, new and revised information is listed in a section titled What’s New in This Chapter. Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x)xxxiv OL-16394-07

PrefaceRevision History This document may be updated at any time without notice. You can obtain the latest version of this document online at: http://www.cisco.com/go/ucsrnd Visit this Cisco.com website periodically and check for documentation updates by comparing the revision date (on the front title page) of your copy with the revision date of the online document. The following table lists the revision history for this document. Revision Date Comments July 21, 2010 Minor corrections to some illustrations. June 4, 2010 Various minor updates and error corrections. November 6, 2009 Added a new chapter on Cisco Collaboration Clients and Applications, page 23-1, and information on Cisco Unified IP Phones 8900 Series and 9900 Series. September 18, 2009 Updated content for Cisco Unified Communications System Release 7.1(3). May 22, 2009 Updated content for Cisco Unified Communications System Release 7.1(2). December 15, 2008 Updated content as indicated in New or Changed Information for This Release, page xxxiv. August 5, 2008 Initial version of this document for Cisco Unified Communications Manager Release 7.0.Obtaining Documentation, Obtaining Support, and SecurityGuidelines For information on obtaining documentation, obtaining support, providing documentation feedback, security guidelines, and also recommended aliases and general Cisco documents, see the monthly What’s New in Cisco Product Documentation, which also lists all new and revised Cisco technical documentation, at: http://www.cisco.com/en/US/docs/general/whatsnew/whatsnew.htmlCisco Product Security Overview This product contains cryptographic features and is subject to United States and local country laws governing import, export, transfer and use. Delivery of Cisco cryptographic products does not imply third-party authority to import, export, distribute, or use encryption. Importers, exporters, distributors and users are responsible for compliance with U.S. and local country laws. By using this product you agree to comply with applicable laws and regulations. If you are unable to comply with U.S. and local laws, return this product immediately. Further information regarding U.S. export regulations may be found at: http://www.access.gpo.gov/bis/ear/ear_data.html Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) OL-16394-07 xxxv

Preface Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x)xxxvi OL-16394-07

CH A P T E R 1 Introduction Last revised on: August 5, 2008 The Cisco Unified Communications System delivers fully integrated communications by enabling data, voice, and video to be transmitted over a single network infrastructure using standards-based Internet Protocol (IP). Leveraging the framework provided by Cisco IP hardware and software products, the Cisco Unified Communications System delivers unparalleled performance and capabilities to address current and emerging communications needs in the enterprise environment. The Cisco Unified Communications family of products is designed to optimize feature functionality, reduce configuration and maintenance requirements, and provide interoperability with a wide variety of other applications. The Cisco Unified Communications System provides this capability while maintaining a high level of availability, quality of service (QoS), and security for your network. The Cisco Unified Communications System incorporates and integrates the following major communications technologies: • IP telephony IP telephony refers to technology that transmits voice communications over a network using IP standards. Cisco Unified Communications includes a wide array of hardware and software products such as call processing agents, IP phones (both wired and wireless), voice messaging systems, video devices, and many special applications. • Customer contact center Cisco Unified Contact Center products are a combination of strategy and architecture that promote efficient and effective customer communications across a globally capable network by enabling organizations to draw from a broader range of resources to service customers. They include access to a large pool of agents and multiple channels of communication as well as customer self-help tools. • Video telephony The Cisco Unified Video Advantage products enable real-time video communications and collaboration using the same IP network and call processing agent as Cisco Unified Communications. With Cisco Unified Video Advantage, making a video call is as easy as dialing a phone number. • Rich-media conferencing Cisco Conference Connection, Cisco Unified MeetingPlace and MeetingPlace Express enhance the virtual meeting environment with a integrated set of IP-based tools for voice, video, and web conferencing. Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x)OL-16394-07 1-1

Chapter 1 Introduction Overview of Cisco Unified Communications • Mobility Cisco wireless and mobility solutions enable users to increase productivity and responsiveness by enabling access to network resources and applications securely, regardless of location or client device. • TelePresence Cisco TelePresence delivers real-time, face-to-face interactions between people and places in their work and personal lives using advanced visual, audio, and collaboration technologies. These technologies transmit life-size, high-definition images and spatial discrete audio that make users feel like they are in the same room even when they are half a world away. • Third-party applications Cisco works with leading-edge companies to provide the broadest selection of innovative third-party IP communications applications and products focused on critical business needs such messaging, customer care, and workforce optimization. The remainder of this document focuses on system design considerations for the following components of the Cisco Unified Communications System: • Cisco Unified Communications Manager (Unified CM), formerly Cisco Unified CallManager • Cisco Unified Communications Manager Business Edition (Unified CMBE) • Cisco Unified MeetingPlace and MeetingPlace Express • Cisco Unity and Unity Express • Cisco Unified Video Advantage • Cisco Unified Communications endpoints • Cisco Unified Presence • Cisco Unified Communications applications For information about other aspects of the Cisco Unified Communications System, such as Cisco Unified Contact Center, refer to the documentation available at the following locations: http://www.cisco.com/go/ucsrnd http://www.cisco.com/go/unified-techinfo You can also find additional documentation for the Cisco Unified Communications family of products at the following location: http://www.cisco.comOverview of Cisco Unified Communications The Cisco Unified Communications System is the leading converged network unified communications solution for organizations that want to increase productivity and reduce the costs associated with managing and maintaining separate voice and data networks. The flexibility and sophisticated functionality of the Cisco IP network infrastructure provides the framework that permits rapid deployment of emerging applications such as desktop IP telephony, unified messaging, telepresence, mobility, desktop collaboration, enterprise application integration with IP phone displays, and collaborative IP contact centers. These applications enhance productivity and increase enterprise revenues. Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) 1-2 OL-16394-07

Chapter 1 Introduction Overview of Cisco Unified Communications Figure 1-1 illustrates a typical Cisco Unified Communications deployment employing the Cisco IP network infrastructure, with Cisco Unified Communications Manager (Unified CM) as the call processing agent. Figure 1-1 Typical Unified Communications Deployment Branch (with Call Processing Headquarters and Applications) Applications M M M M Cisco M M Unified CM cluster M M V Gatekeeper IP IP PSTN Branch V (with SRST and Applications) IP IP IP WAN Rest of IP IP world 74350 The foundation architecture for Cisco Unified Communications includes of the following major components (see Figure 1-1): • Cisco IP Network Infrastructure, page 1-4 • Quality of Service, page 1-4 • Call Processing Agent, page 1-4 • Communication Endpoints, page 1-5 • Presence, page 1-6 • Conferencing, Messaging, and Collaboration Capabilities, page 1-7 • Applications, page 1-8 • Security, page 1-10 • Network Management, page 1-10 Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x)OL-16394-07 1-3

Chapter 1 Introduction Overview of Cisco Unified CommunicationsCisco IP Network Infrastructure The network infrastructure includes public switched telephone network (PSTN) gateways, analog phone support, and digital signal processor (DSP) farms. The infrastructure can support multiple client types such as hardware phones, software phones, and video devices. The infrastructure also includes the interfaces and features necessary to integrate legacy PBX, voicemail, and directory systems. Typical products used to build the infrastructure include Cisco voice gateways (non-routing, routing, and integrated), Cisco IOS and Catalyst switches, and Cisco routers. For more information about the IP network infrastructure, see the chapter on Network Infrastructure, page 3-1.Quality of Service Voice, as a class of IP network traffic, has strict requirements concerning packet loss, delay, and delay variation (also known as jitter). To meet these requirements for voice traffic, Cisco Unified Communications includes Quality of Service (QoS) features such as traffic classification, queuing, traffic shaping, compressed Real-Time Transport Protocol (cRTP), and Transmission Control Protocol (TCP) header compression. The QoS components for Cisco Unified Communications are provided through the rich IP traffic management, queueing, and shaping capabilities of the Cisco IP network infrastructure. Key elements of this infrastructure that enable QoS for Cisco Unified Communications include: • Traffic marking • Enhanced queuing services • Link fragmentation and interleaving (LFI) • Compressed RTP (cRTP) • Low-latency queuing (LLQ) • Link efficiency • Traffic shaping • Call admission control (bandwidth allocation) For more information about QoS, see the various sections on QoS in the chapter on Network Infrastructure, page 3-1.Call Processing Agent Cisco Unified Communications Manager (Unified CM) is the core call processing software for the Cisco Unified Communications System. It builds call processing capabilities on top of the Cisco IP network infrastructure. Unified CM software extends enterprise telephony features and capabilities to packet telephony network devices such as IP phones, media processing devices, voice gateways, and multimedia applications. Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) 1-4 OL-16394-07

Chapter 1 Introduction Overview of Cisco Unified Communications You can deploy the call processing capabilities of Unified CM according to one of the following models, depending on the size, geographical distribution, and functional requirements of your enterprise: • Single-site call processing model In the single-site model, each site or campus has its own Unified CM or cluster of Unified CMs to perform call processing functions. No voice traffic travels over the IP WAN; instead, external calls or calls to remote sites use the public switched telephone network (PSTN). • Multisite WAN model with centralized call processing In the multisite WAN model with centralized call processing, the Unified CM cluster resides at the main (or central) campus, and communication with remote branch offices normally takes place over the IP WAN. If either the central site or the IP WAN is down, the remote sites can continue to have service through a feature called Survivable Remote Site Telephony (SRST). The remote sites can also place calls over the PSTN if the IP WAN is temporarily oversubscribed, and you can interconnect a number of central sites through intercluster trunks. • Multisite WAN model with distributed call processing In the multisite WAN model with distributed call processing, each site has its own Unified CM cluster for call processing. Communication between sites normally takes place over the IP WAN, with the PSTN serving as a backup voice path. With this model, you can interconnect any number of sites across the IP WAN. • Clustering over the IP WAN You may deploy a single Unified CM cluster across multiple sites that are connected by an IP WAN with QoS features enabled. To provide call processing redundancy, you can deploy backup servers either locally at each site or at a remote site across the WAN. Clustering over the WAN is well suited as a disaster recovery plan for business continuance sites or as a single solution for small or medium sites. For information on how to apply these deployment models in designing your Cisco Unified Communications network, see Unified Communications Deployment Models, page 2-1.Communication Endpoints A communication endpoint is a user instrument such as a desk phone or even a software phone application that runs on a PC. In the IP environment, each phone has an Ethernet connection. IP phones have all the functions you expect from a telephone, as well as more advanced features such as the ability to access World Wide Web sites. In addition to various models of desktop Cisco Unified IP Phones, Unified Communications endpoints include the following devices: • Software-based endpoints Cisco IP Communicator and Cisco Unified Personal Communicator are desktop applications that turn your computer into a full-featured IP phone with the added advantages of call tracking, desktop collaboration, and one-click dialing from online directories. Cisco IP Communicator is a software-based application that delivers enhanced telephony support through the PC. It is designed to meet diverse customer needs by serving as a supplemental telephone when traveling, as a telecommuting device, or as a primary desktop telephone. Cisco Unified Personal Communicator integrates a wide variety of communications applications and services into a single desktop computer application to provide quick and easy access to powerful communications tools for voice, video, web conferencing, call management, directories, and presence information. Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) OL-16394-07 1-5

Chapter 1 Introduction Overview of Cisco Unified Communications • Video telephony endpoints Video telephony capability is fully integrated with Cisco Unified CM. In addition, Cisco Unified Video Advantage brings video telephony functionality to Cisco Unified IP Phones and the Cisco IP Communicator softphone application. The video telephony solution consists of a Windows-based application and USB camera. Users make calls from their Cisco Unified IP Phones using the familiar phone interface, and calls are displayed with video on their PCs without requiring any extra button pushes or mouse clicks. • Wireless (mobility) endpoints The Cisco Wireless IP Phones 7920 and 7921G extend the Cisco family of IP phones from 10/100 Ethernet to the wireless LAN (WLAN). Both are hardware-based phones with built-in radio antenna. The Cisco Unified Wireless IP Phone 7920 enables 802.11b wireless LAN connectivity to the network, while the Cisco Unified Wireless IP Phone 7921G enables 802.11b, 802.11g, or 802.11a connectivity to the network. These phones provide features and functionality similar to other Cisco Unified IP Phones. For more information about the various types of endpoints, see Unified Communications Endpoints, page 20-1.Presence Presence refers to the ability and willingness of a user to communicate across a set of devices. Cisco Unified Presence consists of many components that enhance the value of a Cisco Unified Communications system by providing information regarding a users availability status and communications capabilities. The users availability status indicates whether or not the user is actively using a particular communications device such as a phone. The users communications capabilities indicate the types of communications that user is capable of using, such as video conferencing, web collaboration, instant messaging, or basic audio. User status changes can be determined automatically by recognizing user keyboard activity, phone use, or device connectivity to the network. This status information is gathered from all the available sources, privacy policies are applied, and the current status is aggregated, synchronized, and stored on a server. Desktop applications, calendar applications, and devices can then access the user status information to provide real-time updates for the end users to make better communication decisions. Status combines the capabilities of what the device or user can do (voice, video, web collaboration, and so forth) and the attributes showing the state of the device or user (available, busy, on a call, and so forth). Presence status can be derived from automatic events such as computer login and telephone off-hook, or it can be derived from explicit notification events for changing status such as the user selecting Do Not Disturb from a change-status pick list. For more information about presence functionality in a Cisco Unified Communications system, see Cisco Unified Presence, page 22-1. Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) 1-6 OL-16394-07

Chapter 1 Introduction Overview of Cisco Unified CommunicationsConferencing, Messaging, and Collaboration Capabilities Cisco Unified Communications supports the following additional features and applications to provide conferencing, voice messaging, and multi-media collaboration functionality: • Conferencing Cisco Unified CM can interface with a number of other Cisco software and hardware devices to provide complete conferencing capability, including annunciator functions and music on hold. For more information about designing and provisioning conference capabilities in Unified CM, see Media Resources, page 6-1. • Unified Messaging Unlike proprietary messaging solutions based on time division multiplexing (TDM), the Cisco Unified Communications platform is built on a Cisco standards-based, open-protocol architecture for voice and data. The standards-based services platform combines synchronous and asynchronous message types, including Voice over IP (VoIP), Internet fax, store-and-forward voicemail, and email under a common message store and directory. This arrangement eliminates the need to synchronize disparate message stores and directories, such as different voicemail and email systems, and dramatically reduces operational and maintenance costs. For more information about integrating third-party voicemail systems with Unified CM, see Third-Party Voicemail Design, page 12-1. For more information about integrating Cisco Unity, Unity Express, and Unity Connection with Unified CM, see Cisco Voice Messaging, page 13-1. • Video Telephony Video telephony capability is fully integrated into Cisco Unified CM, and there are also video endpoints available from Cisco and its strategic partners. Video calls and conferences are now just as easy to make as a voice call on an IP phone. For more information about video capability with Unified CM, see IP Video Telephony, page 16-1. • Multi-Media Collaboration Cisco Unified MeetingPlace and Cisco Unified MeetingPlace Express are complete rich-media conferencing applications that integrate voice, video, and web conferencing capabilities to make remote meetings as natural and effective as face-to-face meetings. For more information about integrating MeetingPlace with Unified CM, see Cisco Unified MeetingPlace, page 14-1, and Cisco Unified MeetingPlace Express, page 15-1. • TelePresence Cisco TelePresence is an innovative solution that uses advanced visual, audio, and collaboration technologies to create an "in-person" meeting experience over the converged network. Cisco TelePresence uses the standard IP technology deployed in corporations today and runs on an integrated voice, video, and data network. The system supports high-quality, real-time voice and video communications with branch offices using broadband connections. It offers capabilities for ensuring quality of service (QoS), security, reliability, and high availability for high-bandwidth applications such as high-definition video. Cisco TelePresence is not covered in this document, but more information is available at: http://www.cisco.com/en/US/products/ps7060/index.html Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) OL-16394-07 1-7

Chapter 1 Introduction Overview of Cisco Unified CommunicationsApplications Applications build upon the call processing infrastructure to enhance the end-to-end capabilities of Cisco Unified Communications by adding sophisticated telephony and converged network features such as the following: • IP Phone Services Cisco Unified IP Phone Services are applications that utilize the web client and/or server and XML capabilities of the Cisco Unified IP Phone. The Cisco Unified IP Phone firmware contains a micro-browser that enables limited web browsing capability. These phone service applications provide the potential for value-added services and productivity enhancement by running directly on the user’s desktop phone. • Extension Mobility The Cisco Extension Mobility (EM) feature enables users to configure a Cisco Unified IP Phone as their own, on a temporary basis, by logging in to that phone. After a user logs in, the phone adopts the users individual device profile information, including line numbers, speed dials, services links, and other user-specific properties of a phone. The EM feature dynamically configures a phone according to the authenticated users device profile. The benefit of this application is that it allows users to be reached at their own extension from any phone within the Cisco Unified CM cluster, regardless of physical location, provided the phone supports EM. • Cisco Unified Communications Manager Assistant Cisco Unified CM Assistant is a Unified CM integrated application that enables assistants to handle incoming calls on behalf of one or more managers. With the use of the Unified CM Assistant Console desktop application, assistants can quickly determine a managers status and decide what to do with a call. Assistants can manipulate calls using their phones softkeys or via the PC interface with either keyboard shortcuts, drop-down menus, or by dragging and dropping calls to the managers’ proxy lines. • Attendant Console The Cisco Unified Communications Manager Attendant Console (AC) application enables a receptionist to answer and transfer or dispatch calls within an organization. The attendant can install the attendant console, a client/server Java application, on a PC that runs Windows 2000 or Windows XP. The attendant console connects to the Cisco Unified CM Attendant Console Server for login services, line state, and directory services. Multiple attendant consoles can connect to a single AC server. • WebDialer Cisco WebDialer is a click-to-dial application for Cisco Unified CM that enables users to place calls easily from their PCs using any supported phone device. There is no requirement for administrators to manage CTI links or build JTAPI or TAPI applications because Cisco WebDialer provides a simplified web application and HTTP or Simple Objects Access Protocol (SOAP) interface for those who want to provide their own user interface and authentication mechanisms. Either way, the solution scales to support the entire Unified CM cluster with full redundancy. For more information about these applications, see Cisco Unified CM Applications, page 24-1. In addition to the preceding applications for enterprise telephony users, Cisco mobility applications provide the ability to deliver features and functionality of the Cisco Unified Communications environment to mobile workers wherever they might be. Mobility functionality delivered within the Cisco Unified Communications solution is provided via the Cisco Unified Mobility application server. Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) 1-8 OL-16394-07

Chapter 1 Introduction Overview of Cisco Unified Communications The Unified Mobility server communicates with Cisco Unified CM via the Java Telephony Application Programming Interface (JTAPI) and AVVID XML Layer (AXL), and it provides the following mobility application functionality: • Mobile Connect Mobile Connect or Single Number Reach provides Cisco Unified Communications users with the ability to be reached via a single enterprise phone number that will ring on both their IP desk phone and their cellular phone simultaneously. Mobile Connect users can pick up an incoming call on either their desk or cellular phones and at any point can move the in-progress call from one of these phones to the other without interruption. • Mid-Call Features Mid-call features allow a user to invoke hold, resume, transfer, conferencing, and directed call park features from their mobile phone during in-progress mobility calls. These features are invoked via the mobile phone keypad and take advantage of enterprise media resources such as music on hold and conference bridges. • Single Enterprise Voicemail Box Single Enterprise Voicemail box ensures that any unanswered calls made to the users enterprise number and extended to the users mobile phone will end up in the enterprise voicemail system rather than in a mobile voicemail system. This provides a single consolidated voicemail box for all business calls and eliminates the need for users to check multiple voicemail systems for messages. • Mobile Voice Access and Enterprise Feature Access with two-stage dialing Mobile Voice Access and Enterprise Feature Access with two-stage dialing provide mobile users with the ability to make calls from their mobile phone as if they were calling from their enterprise IP desk phone. These features provide a cost savings in terms of toll charges for long distance or international calls, and they provide the enterprise with an easy way to track phone calls made by users via a uniform and centrally located set of call detail records. Furthermore, these features provide the ability to mask a users mobile phone number when sending outbound caller ID. Instead, the users enterprise number is sent as caller ID. This ensures that returned calls to the user are made to the enterprise number, thus resulting in enterprise call anchoring. Cisco Unified Mobile Communicator provides a graphical client that works in conjunction with a server running the Cisco Unified Mobility Advantage software to provide a rich user interface for accessing and controlling mobile phone features and functionality. The system integrates into existing corporate LDAP directories, allowing users to use a single set of credentials across all devices. Further, all traffic between Cisco Unified Mobile Communicator and Unified Mobility Advantage is protected by the Secure Socket Layer (SSL) protocol. Cisco Unified Mobile Communicator provides the following functionality for mobile phone users: • Access to corporate and personal directories • Presence and buddy synchronization with the enterprise • Visual access to corporate voicemail • Visibility into desk phone history of missed, placed, and received calls • Secure store-and-forward text messaging • Reception of conference notifications • Dial-via-office using Cisco Unified CM For more information on Cisco Unified Mobility and related applications, see Cisco Mobility Applications, page 25-1. Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x)OL-16394-07 1-9

Chapter 1 Introduction Overview of Cisco Unified CommunicationsSecurity Security for a Cisco Unified Communications deployment involves the following main considerations, among others: • Physical security for restricting physical access to important application servers and network components • Network access security to prevent hostile logins or attacks • Security measures for Cisco Unified CM, endpoint devices, and various directories and databases • Mechanisms for defining calling privileges for various classes of users • Careful network design and management to enhance security For more information about security for Cisco Unified Communications networks, see Voice Security, page 19-1.Network Management Network management is a service consisting of a wide variety of tools, applications, and products to assist network system administrators in provisioning, operating, monitoring and maintaining new and existing network deployments. Network management helps system administrators monitor each network device and network activity so that they can isolate and investigate problems in a timely manner for better performance and productivity. The network management phases typically include: planning, design, implementation, and operation (PDIO). A network manager implements the various management phases to strategically manage the performance and availability of Cisco Unified Communications applications such as voice, video, contact center, and rich media applications. The Cisco Unified Communications Management Suite offers the following set of integrated tools that help to test, deploy, and monitor the Cisco Unified Communications System: • Cisco Unified Provisioning Manager (Unified PM) — Manages provisioning of initial deployments and ongoing operational activation for IP communications services. • Cisco Unified Operations Manager (Unified OM) — Provides comprehensive monitoring with proactive and reactive diagnostics for the entire Cisco Unified Communications System. • Cisco Unified Service Monitor (Unified SM) — Provides a reliable method of monitoring and evaluating voice quality in Cisco Unified Communications systems. • Cisco Unified Service Statistics Manager (Unified SSM) — Provides advanced statistics analysis and reporting capabilities for Cisco Unified Communications deployments. • Cisco Monitor Manager (MM) — Can be deployed in small or medium business (SMB) locations with 5 to 250 users to actively monitor key device parameters in Cisco Unified Communications systems. • Cisco Monitor Director (MD) — Works in conjunction with Cisco Monitor Manager (MM) for support of active voice and data network management in SMB sites at managed service-provider locations. • Cisco netManager — Provides managing, monitoring, and diagnostic functionality for Cisco Unified Communication systems in the SMB environment. For more information on the Cisco Unified Communications Management Suite, see Network Management, page 26-1. Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) 1-10 OL-16394-07

CH A P T E R 2 Unified Communications Deployment Models Last revised on: June 4, 2010 This chapter describes the deployment models for Cisco Unified Communications Manager (Unified CM). For design guidance with earlier releases of Cisco Unified CM, refer to the Unified Communications Solution Reference Network Design (SRND) documentation available at http://www.cisco.com/go/ucsrnd Each Cisco Unified Communications solution is based on a Unified CM deployment model, and the type of deployment model is based on one or more of the following factors: • Number of call processing agent clusters • Number of IP phones • Locations of the call processing agent cluster(s) and IP phones The following sections describe the various types of deployment models: • Single Site, page 2-2 • Multisite with Centralized Call Processing, page 2-4 • Multisite with Distributed Call Processing, page 2-15 • Clustering Over the IP WAN, page 2-21Whats New in This Chapter Table 2-1 lists the topics that are new in this chapter or that have changed significantly from previous releases of this document. Table 2-1 New or Changed Information Since the Previous Release of This Document New or Revised Topic Described in: Cisco Unified CM Session Management Unified CM Session Management Edition, page 2-18 Edition Cisco Unified Communications Manager Best Practices for Unified CME in SRST Mode, page 2-10 Express (Unified CME) in SRST mode now supports Cisco Unity Express. Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) OL-16394-07 2-1

Chapter 2 Unified Communications Deployment Models Single Site Table 2-1 New or Changed Information Since the Previous Release of This Document New or Revised Topic Described in: CTI Manager over the WAN Local Failover Deployment Model, page 2-25 Increase in number of supported Single Site, page 2-2 gateways and regions Multisite with Centralized Call Processing, page 2-4 Multisite with Distributed Call Processing, page 2-15Single Site The single-site model for Cisco Unified Communications consists of a call processing agent cluster located at a single site, or campus, with no telephony services provided over an IP WAN. An enterprise would typically deploy the single-site model over a LAN or metropolitan area network (MAN), which carries the voice traffic within the site. In this model, calls beyond the LAN or MAN use the public switched telephone network (PSTN). The single-site model has the following design characteristics: • Single Cisco Unified CM cluster. • Maximum of 30,000 configured and registered Skinny Client Control Protocol (SCCP) or Session Initiation Protocol (SIP) IP phones or SCCP video endpoints per cluster. • Maximum of 2,100 gateways and trunks (that is, the total number of H.323 gateways, H.323 trunks, digital MGCP devices, and SIP trunks) per Unified CM cluster. • PSTN for all calls outside the site. • Digital signal processor (DSP) resources for conferencing, transcoding, and media termination point (MTP). • Voicemail, unified messaging, Cisco Unified Presence, audio and video components. • Capability to integrate with legacy private branch exchange (PBX) and voicemail systems. • H.323 clients, MCUs, and H.323/H.320 gateways that require a gatekeeper to place calls must register with a Cisco IOS Gatekeeper (Cisco IOS Release 12.3(8)T or greater). Unified CM then uses an H.323 trunk to integrate with the gatekeeper and provide call routing and bandwidth management services for the H.323 devices registered to it. Multiple Cisco IOS Gatekeepers may be used to provide redundancy. • MCU resources are required for multipoint video conferencing. Depending on conferencing requirements, these resources may be either SCCP or H.323, or both. • H.323/H.320 video gateways are needed to communicate with H.320 videoconferencing devices on the public ISDN network. • High-bandwidth audio (for example, G.711, G.722, or Cisco Wideband Audio) between devices within the site. • High-bandwidth video (for example, 384 kbps or greater) between devices within the site. The Cisco Unified Video Advantage Wideband Codec, operating at 7 Mbps, is also supported. Figure 2-1 illustrates the model for a Cisco Unified Communications network within a single campus or site. Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) 2-2 OL-16394-07

Chapter 2 Unified Communications Deployment Models Single Site Figure 2-1 Single-Site Deployment MCUs Applications Gatekeeper(s) Cisco Unified CM cluster M M M M M H.320 gateways IP ISDN network V IP Voice 119459 gatewayBest Practices for the Single-Site Model Follow these guidelines and best practices when implementing the single-site model: • Provide a highly available, fault-tolerant infrastructure based on a common infrastructure philosophy. A sound infrastructure is essential for easier migration to Cisco Unified Communications, integration with applications such as video streaming and video conferencing, and expansion of your Cisco Unified Communications deployment across the WAN or to multiple Unified CM clusters. • Know the calling patterns for your enterprise. Use the single-site model if most of the calls from your enterprise are within the same site or to PSTN users outside your enterprise. • Use G.711 codecs for all endpoints. This practice eliminates the consumption of digital signal processor (DSP) resources for transcoding, and those resources can be allocated to other functions such as conferencing and Media Termination Points (MTPs). • Use Media Gateway Control Protocol (MGCP) gateways for the PSTN if you do not require H.323 functionality. This practice simplifies the dial plan configuration. H.323 might be required to support specific functionality such as support for Signaling System 7 (SS7) or Non-Facility Associated Signaling (NFAS). Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) OL-16394-07 2-3

Chapter 2 Unified Communications Deployment Models Multisite with Centralized Call Processing • Implement the recommended network infrastructure for high availability, connectivity options for phones (in-line power), Quality of Service (QoS) mechanisms, and security. (See Network Infrastructure, page 3-1.) • Follow the provisioning recommendations listed in the chapter on Call Processing, page 8-1.Multisite with Centralized Call Processing The model for a multisite deployment with centralized call processing consists of a single call processing agent cluster that provides services for many remote sites and uses the IP WAN to transport Cisco Unified Communications traffic between the sites. The IP WAN also carries call control signaling between the central site and the remote sites. Figure 2-2 illustrates a typical centralized call processing deployment, with a Unified CM cluster as the call processing agent at the central site and an IP WAN with QoS enabled to connect all the sites. The remote sites rely on the centralized Unified CM cluster to handle their call processing. Applications such as voicemail, presence servers, interactive voice response (IVR) systems, and so forth, are typically centralized as well to reduce the overall costs of administration and maintenance. Note In each solution for the centralized call processing model presented in this document, the various sites connect to an IP WAN with QoS enabled.Figure 2-2 Multisite Deployment with Centralized Call Processing IP Gatekeeper(s) Cisco Unified CM cluster M H.320 IP gateway M M M M V H.320 Branch A Applications gateway PSTN MCUs IP IP WAN V V IP IP IP Headquarters 119460 Branch B Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) 2-4 OL-16394-07

Chapter 2 Unified Communications Deployment Models Multisite with Centralized Call Processing The multisite model with centralized call processing has the following design characteristics: • Single Unified CM cluster. • Maximum of 30,000 configured and registered Skinny Client Control Protocol (SCCP) or Session Initiation Protocol (SIP) IP phones or SCCP video endpoints per cluster. • Maximum of 2000 locations or branch sites per Unified CM cluster. • Maximum of 2,100 gateways and trunks (that is, the total number of H.323 gateways, H.323 trunks, digital MGCP devices, and SIP trunks) per Unified CM cluster. • PSTN for all external calls. • Digital signal processor (DSP) resources for conferencing, transcoding, and media termination point (MTP). • Voicemail, unified messaging, Cisco Unified Presence, audio and video components. • Capability to integrate with legacy private branch exchange (PBX) and voicemail systems. • H.323 clients, MCUs, and H.323/H.320 gateways that require a gatekeeper to place calls must register with a Cisco IOS Gatekeeper (Cisco IOS Release 12.3(8)T or greater). Unified CM then uses an H.323 trunk to integrate with the gatekeeper and provide call routing and bandwidth management services for the H.323 devices registered to it. Multiple Cisco IOS Gatekeepers may be used to provide redundancy. • MCU resources are required for multipoint video conferencing. Depending on conferencing requirements, these resources may be either SCCP or H.323, or both, and may all be located at the central site or may be distributed to the remote sites if local conferencing resources are required. • H.323/H.320 video gateways are needed to communicate with H.320 videoconferencing devices on the public ISDN network. These gateways may all be located at the central site or may be distributed to the remote sites if local ISDN access is required. • High-bandwidth audio (for example, G.711, G.722, or Cisco Wideband Audio) between devices in the same site, and low-bandwidth audio (for example, G.729 or G.728) between devices in different sites. • High-bandwidth video (for example, 384 kbps or greater) between devices in the same site, and low-bandwidth video (for example, 128 kbps) between devices at different sites. The Cisco Unified Video Advantage Wideband Codec, operating at 7 Mbps, is recommended only for calls between devices at the same site. • Minimum of 768 kbps or greater WAN link speeds. Video is not recommended on WAN connections that operate at speeds lower than 768 kbps. • Unified CM locations (static or RSVP-enabled) provide call admission control, and automated alternate routing (AAR) is also supported for video calls. • Survivable Remote Site Telephony (SRST) versions 4.0 and higher support video. However, versions of SRST prior to 4.0 do not support video, and SCCP video endpoints located at remote sites become audio-only devices if the WAN connection fails. • Cisco Unified Communications Manager Express (Unified CME) versions 4.0 and higher may be used for remote site survivability instead of an SRST router. Unified CME also provides more features than the SRST router during WAN outage. • Cisco Unified Communications Manager Express (Unified CME) can be integrated with the Cisco Unity server in the branch office or remote site. The Cisco Unity server is registered to the Unified CM at the central site in normal mode and can fall back to Unified CME in SRST mode when Unified CM is not reachable, or during a WAN outage, to provide the users at the branch offices with access to their voicemail with MWI. Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x)OL-16394-07 2-5

Chapter 2 Unified Communications Deployment Models Multisite with Centralized Call Processing Connectivity options for the IP WAN include: • Leased lines • Frame Relay • Asynchronous Transfer Mode (ATM) • ATM and Frame Relay Service Inter-Working (SIW) • Multiprotocol Label Switching (MPLS) Virtual Private Network (VPN) • Voice and Video Enabled IP Security Protocol (IPSec) VPN (V3PN) Routers that reside at the WAN edges require quality of service (QoS) mechanisms, such as priority queuing and traffic shaping, to protect the voice traffic from the data traffic across the WAN, where bandwidth is typically scarce. In addition, a call admission control scheme is needed to avoid oversubscribing the WAN links with voice traffic and deteriorating the quality of established calls. For centralized call processing deployments, locations (static or RSVP-enabled) configured within Unified CM provide call admission control. (Refer to the chapter on Call Admission Control, page 9-1, for more information on locations.) A variety of Cisco gateways can provide the remote sites with PSTN access. When the IP WAN is down, or if all the available bandwidth on the IP WAN has been consumed, users at the remote sites can dial the PSTN access code and place their calls through the PSTN. The Cisco Unified Survivable Remote Site Telephony (SRST) feature, available for both SCCP and SIP phones, provides call processing at the branch offices for Cisco Unified IP Phones if they lose their connection to the remote primary, secondary, or tertiary Unified CM or if the WAN connection is down. Cisco Unified SRST functionality is available on Cisco IOS gateways running the SRST feature or on Cisco Unified CME Release 4.0 and higher running in SRST mode. Unified CME running in SRST mode provides more features for the phones than SRST on a Cisco IOS gateway.Best Practices for the Centralized Call Processing Model Follow these guidelines and best practices when implementing multisite centralized call processing deployments: • Minimize delay between Unified CM and remote locations to reduce voice cut-through delays (also known as clipping). • Configure locations (static or RSVP-enabled) in Unified CM to provide call admission control into and out of remote branches. See the chapter on Call Admission Control, page 9-1, for details on how to apply this mechanism to the various WAN topologies. • The number of IP phones and line appearances supported in Survivable Remote Site Telephony (SRST) mode at each remote site depends on the branch router platform, the amount of memory installed, and the Cisco IOS release. SRST on a Cisco IOS gateway supports up to 720 phones, while Unified CME running in SRST mode supports 240 phones. (For the latest SRST or Unified CME platform and code specifications, refer to the SRST and Unified CME documentation available at http://www.cisco.com.) Generally speaking, however, the choice of whether to adopt a centralized call processing or distributed call processing approach for a given site depends on a number of factors such as: – IP WAN bandwidth or delay limitations – Criticality of the voice network – Feature set needs – Scalability Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) 2-6 OL-16394-07

Chapter 2 Unified Communications Deployment Models Multisite with Centralized Call Processing – Ease of management – Cost If a distributed call processing model is deemed more suitable for the customers business needs, the choices include installing a Unified CM cluster at each site or running Unified CME at the remote sites. • At the remote sites, use the following features to ensure call processing survivability in the event of a WAN failure: – For SCCP phones, use SRST on a Cisco IOS gateway or Unified CME running in SRST mode. – For SIP phones, use SIP SRST. – For MGCP phones, use MGCP Gateway Fallback. SRST or Unified CME in SRST mode, SIP SRST, and MGCP Gateway Fallback can reside with each other on the same Cisco IOS gateway.Remote Site Survivability When deploying Cisco Unified Communications across a WAN with the centralized call processing model, you should take additional steps to ensure that data and voice services at the remote sites are highly available. Table 2-2 summarizes the different strategies for providing high availability at the remote sites. The choice of one of these strategies may depend on several factors, such as specific business or application requirements, the priorities associated with highly available data and voice services, and cost considerations. Table 2-2 Strategies for High Availability at the Remote Sites High Availability for High Availability for Strategy Data Services? Voice Services? Redundant IP WAN links in branch router Yes Yes Redundant branch router platforms + Redundant IP Yes Yes WAN links Data-only ISDN backup + SRST or Unified CME Yes Yes Data and voice ISDN backup Yes Yes (see rules below) Cisco Unified Survivable Remote Site Telephony No Yes (SRST) or Unified CME in SRST mode The first two solutions listed in Table 2-2 provide high availability at the network infrastructure layer by adding redundancy to the IP WAN access points, thus maintaining IP connectivity between the remote IP phones and the centralized Unified CM at all times. These solutions apply to both data and voice services, and are entirely transparent to the call processing layer. The options range from adding a redundant IP WAN link at the branch router to adding a second branch router platform with a redundant IP WAN link. Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) OL-16394-07 2-7

Chapter 2 Unified Communications Deployment ModelsMultisite with Centralized Call Processing The third and forth solutions in Table 2-2 use an ISDN backup link to provide survivability during WAN failures. The two deployment options for ISDN backup are: • Data-only ISDN backup With this option, ISDN is used for data survivability only, while SRST or Unified CME in SRST mode is used for voice survivability. Note that you should configure an access control list on the branch router to prevent Skinny Client Control Protocol (SCCP) or Session Initiation Protocol (SIP) traffic from entering the ISDN interface, so that signaling from the IP phones does not reach the Unified CM at the central site. • Data and voice ISDN backup With this option, ISDN is used for both data and voice survivability. In this case, SRST or Unified CME in SRST mode is not used because the IP phones maintain IP connectivity to the Unified CM cluster at all times. However, Cisco recommends that you use ISDN to transport data and voice traffic only if all of the following conditions are true: – The bandwidth allocated to voice traffic on the ISDN link is the same as the bandwidth allocated to voice traffic on the IP WAN link. – The ISDN link bandwidth is fixed. – All the required QoS features have been deployed on the routers ISDN interfaces. Refer to the chapter on Network Infrastructure, page 3-1, for more details on QoS. The fifth solution listed in Table 2-2, Survivable Remote Site Telephony (SRST) or Unified CME in SRST mode, provides high availability for voice services only, by providing a subset of the call processing capabilities within the remote office router and enhancing the IP phones with the ability to “re-home” to the call processing functions in the local router if a WAN failure is detected. Figure 2-3 illustrates a typical call scenario with SRST or Unified CME in SRST mode. Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x)2-8 OL-16394-07

Chapter 2 Unified Communications Deployment Models Multisite with Centralized Call ProcessingFigure 2-3 Survivable Remote Site Telephony (SRST) or Unified CME in SRST Mode Central site Central site IP IP IP IP IP IP Unified CM Unified CM cluster cluster M M M M M M V V V V ISDN ISDN backup PSTN backup PSTN IP WAN IP WAN Voice traffic Voice traffic V V Signaling Signaling IP IP IP IP Branch office Branch office 74353 Normal operation WAN failure Under normal operations shown in the left part of Figure 2-3, the branch office connects to the central site via an IP WAN, which carries data traffic, voice traffic, and call signaling. The IP phones at the branch office exchange call signaling information with the Unified CM cluster at the central site and place their calls across the IP WAN. The branch router or gateway forwards both types of traffic (call signaling and voice) transparently and has no knowledge of the IP phones. If the WAN link to the branch office fails, or if some other event causes loss of connectivity to the Unified CM cluster, the branch IP phones re-register with the branch router in SRST mode. The branch router, SRST, or Unified CME running in SRST mode, queries the IP phones for their configuration and Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) OL-16394-07 2-9

Chapter 2 Unified Communications Deployment Models Multisite with Centralized Call Processing uses this information to build its own configuration automatically. The branch IP phones can then make and receive calls either internally or through the PSTN. The phone displays the message “Unified CM fallback mode,” and some advanced Unified CM features are unavailable and are grayed out on the phone display. When WAN connectivity to the central site is reestablished, the branch IP phones automatically re-register with the Unified CM cluster and resume normal operation. The branch SRST router deletes its information about the IP phones and reverts to its standard routing or gateway configuration. Unified CME running in SRST mode at the branch can choose to save the learned phone and line configuration to the running configuration on the Unified CME router by using the auto-provision option. If auto-provision none is configured, none of the auto-provisioned phone or line configuration information is written to the running configuration of the Unified CME router. Hence, no configuration change is required on Unified CME if the IP phone is replaced and the MAC address changes. Note When WAN connectivity to the central site is reestablished, or when Unified CM is reachable again, phones in SRST mode with active calls will not immediately re-register to Unified CM until those active calls are terminated. Unified CME in SRST Mode When Unified CME is used in SRST mode, it provides more call processing features for the IP phones than are available with the SRST feature on a router. In addition to the SRST features such as call preservation, auto-provisioning, and failover, Unified CME in SRST mode also provides most of the Unified CME telephony features for the SCCP phones, including: • Paging • Conferencing • Hunt groups • Basic automatic call distribution (B-ACD) • Call park, call pickup, call pickup groups • Overlay-DN, softkey templates • Cisco IP Communicator 2.0 • Cisco Unified Video Advantage 2.0 • Integration with Cisco Unity with MWI support at remote sites, with distributed Microsoft Exchange or IBM Lotus Domino server Unified CME in SRST mode provides call processing support for SCCP phones in case of a WAN failure. However, Unified CME in SRST mode does not provide fallback support for SIP phones or MGCP phones or endpoints. To enable SIP and MGCP phones to fall back if they lose their connection to the SIP proxy server or Unified CM, or if the WAN connection fails, you can additionally configure both the SIP SRST feature and the MGCP Gateway Fallback feature on the same Unified CME server running as the SRST fallback server. Best Practices for Unified CME in SRST Mode • Use the Unified CME IP address as the IP address for SRST reference in the Unified CM configuration. • The Connection Monitor Duration is a timer that specifies how long phones monitor the WAN link before initiating a fallback from SRST to Unified CM. The default setting of 120 seconds should be used in most cases. However, to prevent phones in SRST mode from falling back and re-homing to Unified CM with flapping links, you can set the Connection Monitor Duration parameter on Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x)2-10 OL-16394-07

Chapter 2 Unified Communications Deployment Models Multisite with Centralized Call Processing Unified CM to a longer period so that phones do not keep registering back and forth between the SRST router and Unified CM. Do not set the value to an extensively longer period because this will prevent the phones from falling back from SRST to Unified CM for a long amount of time. • Phones in SRST fallback mode will not re-home to Unified CM when they are in active state. • Phones in SRST fallback mode revert to non-secure mode from secure conferencing. • Configure auto-provision none to prevent writing any learned ephone-dn or ephone configuration to the running configuration of the Unified CME router. This eliminates the need to change the configuration if the IP phone is replaced or the MAC address changes. For more information on using Unified CME in SRST mode, refer to the Cisco Unified Communications Manager Express System Administrator Guide, available at http://www.cisco.com/en/US/products/sw/voicesw/ps4625/products_installation_and_configuratio n_guides_list.html For more information on SIP SRST, refer to the Cisco Unified SIP SRST System Administrator Guide, available at http://www.cisco.com/en/US/products/sw/voicesw/ps2169/products_installation_and_configuratio n_guides_list.html For more information on MGCP Gateway fallback, refer to the information on MGCP gateway fallback in the Cisco CallManager and Cisco IOS Interoperability Guide, available at http://www.cisco.com/en/US/docs/ios/12_3/vvf_c/interop/ccm_c.html Best Practices for SRST Router Use a Cisco Unified SRST router, rather than Unified CME in SRST mode, for the following deployment scenarios: • For supporting a maximum of 720 phones on a single SRST router. • For up to 1000 phones, use two SRST routers. Dial plans must be properly configured to route the calls back and forth between the SRST routers. • For simple, one-time configuration of basic SRST functions. • For SRTP media encryption, which is available only in Cisco Unified SRST (Secure SRST). • For support of the Cisco VG248 Voice Gateway. • For routing calls to and from phones that are unreachable or not registered to the SRST router, use the alias command.Voice Over the PSTN as a Variant of Centralized Call Processing Centralized call processing deployments can be adapted so that inter-site voice media is sent over the PSTN instead of the WAN. With this configuration, the signaling (call control) of all telephony endpoints is still controlled by the central Unified CM cluster, therefore this Voice over the PSTN (VoPSTN) model variation still requires a QoS-enabled WAN with appropriate bandwidth configured for the signaling traffic. You can implement VoPSTN in one of the following ways: • Using the automated alternate routing (AAR) feature. (For more information on AAR, see the section on Automated Alternate Routing, page 10-86.) • Using a combination of dial plan constructs in both Unified CM and the PSTN gateways. Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) OL-16394-07 2-11

Chapter 2 Unified Communications Deployment Models Multisite with Centralized Call Processing VoPSTN can be an attractive option in deployments where IP WAN bandwidth is either scarce or expensive with respect to PSTN charges, or where IP WAN bandwidth upgrades are planned for a later date but the Cisco Unified Communications system is already being deployed. Note VoPSTN deployments offer basic voice functionality that is a reduced subset of the Unified CM feature set. In particular, regardless of the implementation choice, the system designer should address the following issues, among others: • Centralized voicemail requires: – A telephony network provider that supports redirected dialed number identification service (RDNIS) end-to-end for all locations that are part of the deployment. RDNIS is required so that calls redirected to voicemail carry the redirecting DN, to ensure proper voicemail box selection. – If the voicemail system is accessed through an MGCP gateway, the voicemail pilot number must be a fully qualified E.164 number. • The Extension Mobility feature is limited to IP phones contained within a single branch site. • All on-net (intra-cluster) calls will be delivered to the destination phone with the same call treatment as an off-net (PSTN) call. This includes the quantity of digits delivered in the call directories such as Missed Calls and Received Calls. • Each inter-branch call generates two independent call detail records (CDRs): one for the call leg from the calling phone to the PSTN, and the other for the call leg from the PSTN to the called phone. • There is no way to distinguish the ring type for on-net and off-net calls. • All destination phones require a fully qualified Direct Inward Dial (DID) PSTN number that can be called directly. Non-DID DNs cannot be reached directly from a different branch site. • With VoPSTN, music on hold (MoH) is limited to cases where the holding party is co-located with the MoH resource. If MoH servers are deployed at the central site, then only calls placed on hold by devices at the central site will receive the hold music. • Transfers to a destination outside the branch site will result in the hairpinning of the call through the branchs gateway. Traffic engineering of the branchs gateway resources must be adjusted accordingly. • Call forwarding of any call coming into the branchs gateway to a destination outside the branch site will result in hairpinning of the call through the gateway, thus using two trunk ports. This behavior applies to: – Calls forwarded to a voicemail system located outside the branch – Calls forwarded to an on-net abbreviated dialing destination located in a different branch The gateway port utilization resulting from these call forwarding flows should be taken into account when sizing the trunks connecting the branch to the PSTN. • Conferencing resources must be co-located with the phone initiating the conference. • VoPSTN does not support applications that require streaming of IP audio from the central site (that is, not traversing a gateway). These applications include, but are not limited to: – Centralized music on hold (MoH) servers – Interactive Voice Response (IVR) – CTI-based applications Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x)2-12 OL-16394-07

Chapter 2 Unified Communications Deployment Models Multisite with Centralized Call Processing • Use of the Attendant Console outside of the central site can require a considerable amount of bandwidth if the remote sites must access large user account directories without caching them. • Because all inter-branch media (including transfers) are sent through the PSTN, the gateway trunk group must be sized to accommodate all inter-branch traffic, transfers, and centralized voicemail access. • Cisco recommends that you do not deploy shared lines across branches, such that the devices sharing the line are in different branches. In addition to these general considerations, the following sections present recommendations and issues specific to each of the following implementation methods: • VoPSTN Using AAR, page 2-13 • VoPSTN Using Dial Plan, page 2-14VoPSTN Using AAR This method consists of configuring the Unified CM dial plan as in a traditional centralized call processing deployment, with the automated alternate routing (AAR) feature also properly configured. AAR provides transparent re-routing over the PSTN of inter-site calls when the locations mechanism for call admission control determines that there is not enough available WAN bandwidth to accept an additional call. To use the PSTN as the primary (and only) voice path, you can configure the call admission control bandwidth of each location (branch site) to be 1 kbps, thus preventing all calls from traversing the WAN. With this configuration, all inter-site calls trigger the AAR functionality, which automatically re-routes the calls over the PSTN. The AAR implementation method for VoPSTN offers the following benefits: • An easy migration path to a complete Cisco Unified Communications deployment. When bandwidth becomes available to support voice media over the WAN, the dial plan can be maintained intact, and the only change needed is to update the location bandwidth value for each site. • Support for some supplementary features, such as callback on busy. In addition to the general considerations listed for VoPSTN, the following design guidelines apply to the AAR implementation method: • AAR functionality must be configured properly. • As a general rule, supported call initiation devices include IP phones, gateways, and line-side gateway-driven analog phones. • Inter-branch calls can use AAR only if the destination devices are IP phones or Cisco Unity ports. • Inter-branch calls to other endpoints must use a fully qualified E.164 number. • All on-net, inter-branch calls will display the message, "Network congestion, rerouting." • If destination phones become unregistered (for example, due to WAN connectivity interruption), AAR functionality will not be invoked and abbreviated dialing will not be possible. If the destination phone has registered with an SRST router, then it can be reached by directly dialing its PSTN DID number. • If originating phones become unregistered (for example, due to WAN connectivity interruption), they will go into SRST mode. To preserve abbreviated dialing functionality under these conditions, configure the SRST router with an appropriate set of translation rules. Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) OL-16394-07 2-13

Chapter 2 Unified Communications Deployment Models Multisite with Centralized Call Processing • Shared lines within the same branch should be configured in a partition included only in that branchs calling search spaces. Inter-site access to the shared line requires one of the following: – The originating site dials the DID number of the shared line. – If inter-site abbreviated dialing to the shared line is desired, use a translation pattern that expands the user-dialed abbreviated string to the DID number of the shared line. Note In this case, direct dialing of the shared lines DN from another branch would trigger multiple AAR-based PSTN calls.VoPSTN Using Dial Plan This method relies on a specific dial plan configuration within Unified CM and the PSTN gateways to route all inter-site calls over the PSTN. The dial plan must place IP phone DNs at each site into a different partition, and their calling search space must provide access only to the sites internal partition and a set of route patterns that point to the local PSTN gateway. Abbreviated inter-site dialing can still be provided via a set of translations at each branch site, one for each of the other branch sites. These translations are best accomplished with H.323 gateways and translation rules within Cisco IOS. The dial plan method for implementing VoPSTN offers the following benefits: • Easier configuration because AAR is not needed. • Abbreviated dialing automatically works even under WAN failure conditions on either the originating or destination side, because the Cisco IOS translation rules within the H.323 gateway are effective in SRST mode. In addition to the general considerations listed for VoPSTN, the following design guidelines apply to the dial plan implementation method: • There is no support for supplementary features such as callback on busy. • Some CTI-based applications do not support overlapping extensions (that is, two or more phones configured with the same DN, although in different partitions). • There is no easy migration to a complete Cisco Unified Communications deployment because the dial plan needs to be redesigned. Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) 2-14 OL-16394-07

Chapter 2 Unified Communications Deployment Models Multisite with Distributed Call ProcessingMultisite with Distributed Call Processing The model for a multisite deployment with distributed call processing consists of multiple independent sites, each with its own call processing agent cluster connected to an IP WAN that carries voice traffic between the distributed sites. Figure 2-4 illustrates a typical distributed call processing deployment.Figure 2-4 Multisite Deployment with Distributed Call Processing M M M Applications M M Cisco Unified CM Gatekeeper(s) cluster Media Resources IP M H.320 gateway IP M M V M M Branch A H.320 Applications gateway H.320 ISDN gateway network M Media Resources M M M M IP WAN V V Applications IP IP PSTN Media Headquarters Resources 141851 IP IP Branch B Each site in the distributed call processing model can be one of the following: • A single site with its own call processing agent, which can be either: – Cisco Unified Communications Manager (Unified CM) – Cisco Unified Communications Manager Express (Unified CME) – Other IP PBX • A centralized call processing site and all of its associated remote sites • A legacy PBX with Voice over IP (VoIP) gateway Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) OL-16394-07 2-15

Chapter 2 Unified Communications Deployment Models Multisite with Distributed Call Processing The multisite model with distributed call processing has the following design characteristics: • Maximum of 30,000 configured and registered Skinny Client Control Protocol (SCCP) or Session Initiation Protocol (SIP) IP phones or SCCP video endpoints per cluster. • Maximum of 2,100 gateways and trunks (that is, the total number of H.323 gateways, H.323 trunks, digital MGCP devices, and SIP trunks) per Unified CM cluster. • PSTN for all external calls. • Digital signal processor (DSP) resources for conferencing, transcoding, and media termination point (MTP). • Voicemail, unified messaging, and Cisco Unified Presence components. • Capability to integrate with legacy private branch exchange (PBX) and voicemail systems. • H.323 clients, MCUs, and H.323/H.320 gateways that require a gatekeeper to place calls must register with a Cisco IOS Gatekeeper (Cisco IOS Release 12.3(8)T or greater). Unified CM then uses an H.323 trunk to integrate with the gatekeeper and provide call routing and bandwidth management services for the H.323 devices registered to it. Multiple Cisco IOS Gatekeepers may be used to provide redundancy. Cisco IOS Gatekeepers may also be used to provide call routing and bandwidth management between the distributed Unified CM clusters. In most situations, Cisco recommends that each Unified CM cluster have its own set of endpoint gatekeepers and that a separate set of gatekeepers be used to manage the intercluster calls. It is possible in some circumstances to use the same set of gatekeepers for both functions, depending on the size of the network, complexity of the dial plan, and so forth. (For details, see Gatekeepers, page 16-22.) • MCU resources are required in each cluster for multipoint video conferencing. Depending on conferencing requirements, these resources may be either SCCP or H.323, or both, and may all be located at the regional sites or may be distributed to the remote sites of each cluster if local conferencing resources are required. • H.323/H.320 video gateways are needed to communicate with H.320 videoconferencing devices on the public ISDN network. These gateways may all be located at the regional sites or may be distributed to the remote sites of each cluster if local ISDN access is required. • High-bandwidth audio (for example, G.711, G.722, or Cisco Wideband Audio) between devices in the same site, but low-bandwidth audio (for example, G.729 or G.728) between devices in different sites. • High-bandwidth video (for example, 384 kbps or greater) between devices in the same site, but low-bandwidth video (for example, 128 kbps) between devices at different sites. The Cisco Unified Video Advantage Wideband Codec, operating at 7 Mbps, is recommended only for calls between devices at the same site. Note that the Cisco VT Camera Wideband Video Codec is not supported over intercluster trunks. • Minimum of 768 kbps or greater WAN link speeds. Video is not recommended on WAN connections that operate at speeds lower than 768 kbps. • Call admission control is provided by Unified CM locations for calls between sites controlled by the same Unified CM cluster, and by the Cisco IOS Gatekeeper for calls between Unified CM clusters (that is, intercluster trunks). Automated alternate routing (AAR) is also supported for both intra-cluster and inter-cluster video calls. An IP WAN interconnects all the distributed call processing sites. Typically, the PSTN serves as a backup connection between the sites in case the IP WAN connection fails or does not have any more available bandwidth. A site connected only through the PSTN is a standalone site and is not covered by the distributed call processing model. (See Single Site, page 2-2.) Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x)2-16 OL-16394-07

Chapter 2 Unified Communications Deployment Models Multisite with Distributed Call Processing Connectivity options for the IP WAN include: • Leased lines • Frame Relay • Asynchronous Transfer Mode (ATM) • ATM and Frame Relay Service Inter-Working (SIW) • Multiprotocol Label Switching (MPLS) Virtual Private Network (VPN) • Voice and Video Enabled IP Security Protocol (IPSec) VPN (V3PN)Best Practices for the Distributed Call Processing Model A multisite deployment with distributed call processing has many of the same requirements as a single site or a multisite deployment with centralized call processing. Follow the best practices from these other models in addition to the ones listed here for the distributed call processing model. (See Single Site, page 2-2, and Multisite with Centralized Call Processing, page 2-4.) Gatekeeper or Session Initiation Protocol (SIP) proxy servers are among the key elements in multisite distributed call processing deployments. They each provide dial plan resolution, with the gatekeeper also providing call admission control. A gatekeeper is an H.323 device that provides call admission control and E.164 dial plan resolution. The following best practices apply to the use of a gatekeeper: • Use a Cisco IOS gatekeeper to provide call admission control into and out of each site. • To provide high availability of the gatekeeper, use Hot Standby Router Protocol (HSRP) gatekeeper pairs, gatekeeper clustering, and alternate gatekeeper support. In addition, use multiple gatekeepers to provide redundancy within the network. (See Gatekeeper Design Considerations, page 8-26.) • Size the platforms appropriately to ensure that performance and capacity requirements can be met. • Use only one type of codec on the WAN because the H.323 specification does not allow for Layer 2, IP, User Data Protocol (UDP), or Real-time Transport Protocol (RTP) header overhead in the bandwidth request. (Header overhead is allowed only in the payload or encoded voice part of the packet.) Using one type of codec on the WAN simplifies capacity planning by eliminating the need to over-provision the IP WAN to allow for the worst-case scenario. • Gatekeeper networks can scale to hundreds of sites, and the design is limited only by the WAN topology. For more information on the various functions performed by gatekeepers, refer to the following sections: • For gatekeeper call admission control, see Call Admission Control, page 9-1. • For gatekeeper scalability and redundancy, see Call Processing, page 8-1. • For gatekeeper dial plan resolution, see Dial Plan, page 10-1. SIP devices provide resolution of E.164 numbers as well as SIP uniform resource identifiers (URIs) to enable endpoints to place calls to each other. Unified CM supports the use of E.164 numbers only. The following best practices apply to the use of SIP proxies: • Provide adequate redundancy for the SIP proxies. • Ensure that the SIP proxies have the capacity for the call rate and number of calls required in the network. • Planning for call admission control is outside the scope of this document. Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) OL-16394-07 2-17

Chapter 2 Unified Communications Deployment Models Multisite with Distributed Call ProcessingCall Processing Agents for the Distributed Call Processing Model Your choice of call processing agent will vary, based on many factors. The main factors, for the purpose of design, are the size of the site and the functionality required. For a distributed call processing deployment, each site has its own call processing agent. The design of each site varies with the call processing agent, the functionality required, and the fault tolerance required. For example, in a site with 500 phones, a Unified CM cluster containing two servers can provide one-to-one redundancy, with the backup server being used as a publisher and Trivial File Transfer Protocol (TFTP) server. The requirement for IP-based applications also greatly affects the choice of call processing agent because only Unified CM provides the required support for many Cisco IP applications. Table 2-3 lists recommended call processing agents.Table 2-3 Recommended Call Processing AgentsCall Processing Agent Recommended Size CommentsCisco Unified Communications Up to 240 phones • For small remote sitesManager Express (Unified CME) • Capacity depends on Cisco IOS platformCisco Unified Communications Up to 575 phones • For small sitesManager Business Edition • Supports centralized or distributed call processing(Unified CMBE)Cisco Unified Communications 50 to 30,000 phones • Small to large sites, depending on the size of theManager (Unified CM) Unified CM cluster • Supports centralized or distributed call processingLegacy PBX with VoIP gateway Depends on PBX • Number of IP WAN calls and functionality depend on the PBX-to-VoIP gateway protocol and the gateway platformUnified CM Session Management Edition Unified communications deployments using Cisco Unified Communications Manager Session Management Edition are a variation of the multisite distributed call processing deployment model and are typically employed to interconnect large numbers of unified communications systems through a single front-end system, in this case the Unified CM Session Management Edition. This section discusses the relevant design considerations for deploying Unified CM Session Management Edition. Cisco Unified CM Session Management Edition is essentially a Unified CM cluster with trunk interfaces only and with no IP endpoints. It enables aggregation of multiple unified communications systems, referred to as leaf systems. With Cisco Unified CM 7.1(3) and later releases, Unified CM Session Management Edition supports the following features: • H.323 Annex M1 intercluster trunks • SIP intercluster trunks • SIP trunks • H.323 trunks • MGCP trunks Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) 2-18 OL-16394-07

Chapter 2 Unified Communications Deployment Models Multisite with Distributed Call Processing • Voice calls • Video calls • Fax calls Unified CM Session Management Edition may also be used to connect to third-party unified communications systems such as IP PSTN connections, PBXs, and centralized unified communications applications. (See Figure 2-5.) However, as with any standard Unified CM cluster, third-party connections to Unified CM Session Management Edition must be tested for interoperability prior to use in a production environment.Figure 2-5 Multisite Deployment with Unified CM Session Management Edition IP PSTN CUBE CUBE M Unified CM M M Session Manager Cluster H.323 or H.323 Annex M1 M M MGCP SIP M M Unified CM Unified CM QSIG PBX QSIG PBX Q931 PBX Q931 PBX Cluster 1 Cluster n 252947 IP IP Leaf Unified CM Clusters Leaf third-party unified communications systemsWhen to Deploy Unified CM Session Management Edition Cisco recommends deploying Unified CM Session Management Edition if you want to do any of the following: • Create and manage a centralized dial plan Rather than configuring each unified communications system with a separate dial plan and trunks to connect to all the other unified communications systems, Unified CM Session Management Edition allows you to configure the leaf unified communications systems with a simplified dial plan and trunk(s) pointing to the Session Management. Unified CM Session Management Edition holds the centralized dial plan with information to reach all the other unified communications systems. Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) OL-16394-07 2-19

Chapter 2 Unified Communications Deployment Models Multisite with Distributed Call Processing • Provide centralized PSTN access Unified CM Session Management Edition can be used to aggregate PSTN access to one (or more) centralized IP PSTN trunks. Centralized PSTN access is commonly combined with the reduction, or elimination, of branch-based PSTN circuits. • Centralize applications The deployment of a Unified CM Session Management Edition enables commonly used applications such as conferencing or videoconferencing to connect directly to the Session Management cluster, thus reducing the overhead of managing multiple trunks to leaf systems. • Aggregate PBXs for migration to a Unified Communications system Unified CM Session Management Edition can provide an aggregation point for multiple PBXs as part of the migration from legacy PBXs to a Cisco Unified Communications System.Differences Between Unified CM Session Management Edition and Standard Unified CM Clusters The Unified CM Session Management Edition software is exactly the same as Unified CM. However, the software has been enhanced significant to satisfy the requirements and the constraints of this new deployment model. Unified CM Session Management Edition is designed to support a large number of trunk-to-trunk connections, and as such it is subject to the following design considerations: • Capacity It is important to correctly size the Unified CM Session Management cluster based on the expected BHCA traffic load between leaf Unified Communications systems (for example, Unified CM clusters and PBXs), to and from any centralized IP PSTN connections, and to any centralized applications. Work with your Cisco account Systems Engineer (SE) or Cisco Partner to size your Unified CM Session Management Edition cluster correctly. • Trunks Where possible, avoid the use of static MTPs on Unified CM trunks (that is, "MTP required" must not be checked on the leaf or Session Management Unified CM SIP or H.323 trunks). MTP-less trunks offer more codec choices; support voice, video, and encryption; and do not anchor trunk calls to MTP resources. If SIP Early Offer is required by a third-party unified communications system, use the Delayed Offer to Early Offer feature with Cisco Unified Border Element. Dynamically inserted MTPs can be used on trunks (for example, for DTMF translation from in-band to out-of-band). • Encryption Encrypted calls are not supported with the current release of Unified CM Session Management Edition. • Unified CM versions Both the Unified CM Session Management Edition and Unified CM leaf clusters require Cisco Unified CM 7.1(2) or later release. Unified CM 7.1(2) has a number of enhancements for trunk-to-trunk calls. Older version of Unified CM might experience problems that can be resolved only by upgrading your cluster to Unified CM 7.1(2) or later release. • Interoperability Even though most vendors have some degree of conformance to standards, differences can and do exist between protocol implementations from various vendors. As with any standard Unified CM cluster, Cisco strongly recommends that you conduct interoperability testing with any unverified third-party unified communications system before deploying the system in a production environment. The interoperability testing should verify call flows and features from Cisco and Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) 2-20 OL-16394-07

Chapter 2 Unified Communications Deployment Models Clustering Over the IP WAN third-party leaf systems through the Unified CM Session Management cluster. To learn which third-party unified communications systems have been tested by the Cisco Interoperability team, go to www.cisco.com/go/interoperability and select the link for Cisco Unified Communications Manager - Session Management Edition. If your unified communications system has not been tested by Cisco, then you should engage Cisco Advanced Services to conduct this testing. If this is not possible, Cisco partners and customers can obtain documentation from their Cisco representative that describes the type of testing to perform. • Load balancing for inbound and outbound calls Configure trunks on the Unified CM Session Management Edition and leaf unified communications systems so that inbound and outbound calls are evenly distributed across the Unified CM servers within the Session Management cluster. For more information on load balancing for trunk calls, refer to the chapter on Cisco Unified CM Trunks, page 5-1. • Design assistance Unified CM Session Management Edition designs should be reviewed by your Cisco SE in conjunction with the Cisco Unified CM Session Management Team. For more information of the Unified CM Session Management Edition design review process, Cisco partners and employees can refer to the documentation at http://docwiki.cisco.com/wiki/Unified_Communications_Manager_-_Session_Manager_EditionClustering Over the IP WAN You may deploy a single Unified CM cluster across multiple sites that are connected by an IP WAN with QoS features enabled. This section provides a brief overview of clustering over the WAN. For further information, refer to the chapter on Call Processing, page 8-1. Clustering over the WAN can support two types of deployments: • Local Failover Deployment Model, page 2-25 Local failover requires that you place the Unified CM subscriber and backup servers at the same site, with no WAN between them. This type of deployment is ideal for two to four sites with Unified CM. • Remote Failover Deployment Model, page 2-30 Remote failover allows you to deploy primary and backup call processing servers split across the WAN. Using this type of deployment, you may have up to eight sites with Unified CM subscribers being backed up by Unified CM subscribers at another site. Note Remote failover deployments might require higher bandwidth because a large amount of intra-cluster traffic flows between the subscriber servers. You can also use a combination of the two deployment models to satisfy specific site requirements. For example, two main sites may each have primary and backup subscribers, with another two sites containing only a primary server each and utilizing either shared backups or dedicated backups at the two main sites. Some of the key advantages of clustering over the WAN are: • Single point of administration for users for all sites within the cluster • Feature transparency • Shared line appearances Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) OL-16394-07 2-21

Chapter 2 Unified Communications Deployment Models Clustering Over the IP WAN • Extension mobility within the cluster • Unified dial plan These features make this solution ideal as a disaster recovery plan for business continuance sites or as a single solution for up to eight small or medium sites.WAN Considerations For clustering over the WAN to be successful, you must carefully plan, design, and implement various characteristics of the WAN itself. The Intra-Cluster Communication Signaling (ICCS) between Unified CM servers consists of many traffic types. The ICCS traffic types are classified as either priority or best-effort. Priority ICCS traffic is marked with IP Precedence 3 (DSCP 24 or PHB CS3). Best-effort ICCS traffic is marked with IP Precedence 0 (DSCP 0 or PHB BE). The various types of ICCS traffic are described in Intra-Cluster Communications, page 2-23, which also provides further guidelines for provisioning. The following design guidelines apply to the indicated WAN characteristics: • Delay The maximum one-way delay between any two Unified CM servers should not exceed 40 msec, or 80 msec round-trip time. Measuring the delay is covered in Delay Testing, page 2-24. Propagation delay between two sites introduces 6 microseconds per kilometer without any other network delays being considered. This equates to a theoretical maximum distance of approximately 3000 km for 20 ms delay or approximately 1860 miles. These distances are provided only as relative guidelines and in reality will be shorter due to other delay incurred within the network. • Jitter Jitter is the varying delay that packets incur through the network due to processing, queue, buffer, congestion, or path variation delay. Jitter for the IP Precedence 3 ICCS traffic must be minimized using Quality of Service (QoS) features. • Packet loss and errors The network should be engineered to provide sufficient prioritized bandwidth for all ICCS traffic, especially the priority ICCS traffic. Standard QoS mechanisms must be implemented to avoid congestion and packet loss. If packets are lost due to line errors or other “real world” conditions, the ICCS packet will be retransmitted because it uses the TCP protocol for reliable transmission. The retransmission might result in a call being delayed during setup, disconnect (teardown), or other supplementary services during the call. Some packet loss conditions could result in a lost call, but this scenario should be no more likely than errors occurring on a T1 or E1, which affect calls via a trunk to the PSTN/ISDN. • Bandwidth Provision the correct amount of bandwidth between each server for the expected call volume, type of devices, and number of devices. This bandwidth is in addition to any other bandwidth for other applications sharing the network, including voice and video traffic between the sites. The bandwidth provisioned must have QoS enabled to provide the prioritization and scheduling for the different classes of traffic. The general rule of thumb for bandwidth is to over-provision and under-subscribe. • Quality of Service The network infrastructure relies on QoS engineering to provide consistent and predictable end-to-end levels of service for traffic. Neither QoS nor bandwidth alone is the solution; rather, QoS-enabled bandwidth must be engineered into the network infrastructure. Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) 2-22 OL-16394-07

Chapter 2 Unified Communications Deployment Models Clustering Over the IP WANIntra-Cluster Communications In general, intra-cluster communications means all traffic between servers. There is also a real-time protocol called Intra-Cluster Communication Signaling (ICCS), which provides the communications with the Cisco CallManager Service process that is at the heart of the call processing in each server or node within the cluster. The intra-cluster traffic between the servers consists of the following: • Database traffic from the IBM Informix Dynamic Server (IDS) database that provides the main configuration information. The IDS traffic may be re-prioritized in line with Cisco QoS recommendations to a higher priority data service (for example, IP Precedence 1 if required by the particular business needs). An example of this is extensive use of Extension Mobility, which relies on IDS database configuration. • Firewall management traffic, which is used to authenticate the subscribers to the publisher to access the publishers database. The management traffic flows between all servers in a cluster. The management traffic may be prioritized in line with Cisco QoS recommendations to a higher priority data service (for example, IP Precedence 1 if required by the particular business needs). • ICCS real-time traffic, which consists of signaling, call admission control, and other information regarding calls as they are initiated and completed. ICCS uses a Transmission Control Protocol (TCP) connection between all servers that have the Cisco CallManager Service enabled. The connections are a full mesh between these servers. Because only eight servers may have the Cisco CallManager Service enabled in a cluster, there may be up to seven connections on each server. This traffic is priority ICCS traffic and is marked dependant on release and service parameter configuration. • CTI Manager real-time traffic is used for CTI devices involved in calls or for controlling or monitoring other third-party devices on the Unified CM servers. This traffic is marked as priority ICCS traffic and exists between the Unified CM server with the CTI Manager and the Unified CM server with the CTI device. Note For detailed information on various types of traffic between Unified CM servers, refer to the port usage document at http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/port/7_0/CCM_7.0PortList.pdf.Unified CM Publisher The publisher server replicates a partial read-only copy of the master database to all other servers in the cluster. Most of the database modifications are done on the publisher. If changes such as administration updates are made in the publisher’s master database during a period when another server in the cluster is unreachable, the publisher will replicate the updated database when communications are re-established. Database modifications for user-facing call processing features are made on the subscriber servers to which the IP phones are registered. These features include: • Call Forward All (CFA) • Message Waiting Indication (MWI) • Privacy Enable/Disable • Do Not Disturb (DND) Enable/Disable • Extension Mobility Login (EM) • Monitor (for future use; currently no updates at the user level) • Hunt Group Logout Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) OL-16394-07 2-23

Chapter 2 Unified Communications Deployment Models Clustering Over the IP WAN • Device Mobility • CTI Certificate Authority Proxy Function (CAPF) status for end users and application users • Credential hacking and authentication Each subscriber replicates these changes to every other server in the cluster. Any other configuration changes cannot be made on the database during the period when the publisher is unreachable or offline. Most normal operations of the cluster, including the following, will not be affected during the period of publisher failure: • Call processing • Failover • Registration of previously configured devices Other services or applications might also be affected, and their ability to function without the publisher should be verified when deployed.Call Detail Records (CDR) and Call Management Records (CMR) Call detail records and call management records, when enabled, are collected by each subscriber and uploaded to the publisher periodically. During a period that the publisher is unreachable, the CDRs and CMRs are stored on the subscriber’s local hard disk. When connectivity is re-established to the publisher, all outstanding CDRs are uploaded to the publisher, which stores the records in the CDR Analysis and Reporting (CAR) database.Delay Testing The maximum round-trip time (RTT) between any two servers must not exceed 80 msec. This time limit must include all delays in the transmission path between the two servers. Verifying the round trip delay using the ping utility on the Unified CM server will not provide an accurate result. The ping is sent as a best-effort tagged packet and is not transported using the same QoS-enabled path as the ICCS traffic. Therefore, Cisco recommends that you verify the delay by using the closest network device to the Unified CM servers, ideally the access switch to which the server is attached. Cisco IOS provides a extended ping capable to set the Layer 3 type of service (ToS) bits to make sure the ping packet is sent on the same QoS-enabled path that the ICCS traffic will traverse. The time recorded by the extended ping is the round-trip time (RTT), or the time it takes to traverse the communications path and return. The following example shows a Cisco IOS extended ping with the ToS bit (IP Precedence) set to 3: Access_SW#ping Protocol [ip]: Target IP address: 10.10.10.10 Repeat count [5]: Datagram size [100]: Timeout in seconds [2]: Extended commands [n]: y Source address or interface: Type of service [0]: 3 Set DF bit in IP header? [no]: Validate reply data? [no]: Data pattern [0xABCD]: Loose, Strict, Record, Timestamp, Verbose[none]: Sweep range of sizes [n]: Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.10.10.10, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) 2-24 OL-16394-07

Chapter 2 Unified Communications Deployment Models Clustering Over the IP WANError Rate The expected error rate should be zero. Any errors, dropped packets, or other impairments to the IP network can have an impact to the call processing performance of the cluster. This may be noticeable by delay in dial tone, slow key or display response on the IP phone, or delay from off-hook to connection of the voice path. Although Unified CM will tolerate random errors, they should be avoided to avoid impairing the performance of the cluster.Troubleshooting If the Unified CM subscribers in a cluster are experiencing impairment of the ICCS communication due to higher than expected delay, errors, or dropped packets, some of the following symptoms might occur: • IP phones, gateways, or other devices on a remote Unified CM server within the cluster might temporarily be unreachable. • Calls might be disconnected or might fail during call setup. • Users might experience longer than expected delays before hearing dial tone. • Busy hour call completions (BHCC) might be low. • The ICCS (SDL session) might be reset or disconnected. In summary, perform the following tasks to troubleshoot ICCS communication problems: • Verify the delay between the servers. • Check all links for errors or dropped packets. • Verify that QoS is correctly configured. • Verify that sufficient bandwidth is provisioned for the queues and across the WAN to support all the traffic.Local Failover Deployment Model The local failover deployment model provides the most resilience for clustering over the WAN. Each of the sites in this model contains at least one primary Unified CM subscriber and one backup subscriber. This configuration can support up to four sites. The maximum number of phones and other devices will be dependant on the quantity and type of servers deployed. The maximum total number of IP phones for all sites is 30,000. (See Figure 2-6.) Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) OL-16394-07 2-25

Chapter 2 Unified Communications Deployment Models Clustering Over the IP WANFigure 2-6 Example of Local Failover Model Site A Publisher/TFTP server Site B M Sub A Sub B Sub A Sub B M M M M M WAN M Backup V V Backup Voice Mail Voice Mail Gateway Server MOH Gateway Server MOH V V JTAPI JTAPI Conf IP-AA/IVR Conf IP-AA/IVR Xcode IP Phone Xcode IP Phone IP IP SoftPhone SoftPhone 74360 Observe the following guidelines when implementing the local failover model: • Configure each site to contain at least one primary Unified CM subscriber and one backup subscriber. • Configure Unified CM groups and device pools to allow devices within the site to register with only the servers at that site under all conditions. • Cisco highly recommends that you replicate key services (TFTP, DNS, DHCP, LDAP, and IP Phone Services), all media resources (conference bridges and music on hold), and gateways at each site to provide the highest level of resiliency. You could also extend this practice to include a voicemail system at each site. • Under a WAN failure condition, sites without access to the publisher database will lose some functionality. For example, system administration at the remote site will not be able to add, modify, or delete any part of the configuration. However, users can continue to access the user-facing features listed in the section on Unified CM Publisher, page 2-23. • Under WAN failure conditions, calls made to phone numbers that are not currently communicating with the subscriber placing the call, will result in either a fast-busy tone or a call forward (possibly to voicemail or to a destination configured under Call Forward Unregistered). Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) 2-26 OL-16394-07

Chapter 2 Unified Communications Deployment Models Clustering Over the IP WAN • The maximum allowed round-trip time (RTT) between any two servers in the Unified CM cluster is 80 msec. Note At a higher round-trip delay time and higher busy hour call attempts (BHCA), voice cut-through delay might be higher, causing initial voice clipping when a voice call is established. • A minimum of 1.544 Mbps (T1) bandwidth is required for Intra-Cluster Communication Signaling (ICCS) for 10,000 busy hour call attempts (BHCA) between sites that are clustered over the WAN. This is a minimum bandwidth requirement for call control traffic, and it applies to deployments where directory numbers are not shared between sites that are clustered over the WAN. The following equation may be used as a guideline to calculate the bandwidth for more than 10,000 BHCA between non-shared directory numbers at a specific delay: Total Bandwidth (Mbps) = (Total BHCA/10,000) ∗ (1 + 0.006 ∗ Delay), where Delay = RTT delay in msec This call control traffic is classified as priority traffic. Priority ICCS traffic is marked with IP Precedence 3 (DSCP 24 or PHB CS3). • In addition to the bandwidth required for Intra-Cluster Communication Signaling (ICCS) traffic, a minimum of 1.544 Mbps (T1) bandwidth is required for database and other inter-server traffic for every subscriber server remote to the publisher. • For customers who also want to deploy CTI Manager over the WAN, the following formula can be used to calculate the CTI bandwidth (Mbps): (Total BHCA/10,000) ∗ 1.25 Example 2-1 Bandwidth Calculation for Two Sites Consider two sites, Site 1 and Site 2, with Unified CM clustered over the WAN across these two sites that are 80 msec round-trip time apart. Site 1 has one publisher, one combined TFTP and music on hold (MoH) server, and two Unified CM subscriber servers. Site 2 has one TFTP/MoH server and two Unified CM subscriber servers. Site 1 has 5000 phones, each having one DN; and Site 2 has 5000 phones, each having one DN. During the busy hour, 2500 phones in Site 1 call 2500 phones in Site 2, each at 3 BHCA. During that same busy hour, 2500 phones in Site 2 also call 2500 phones in Site 1, each at 3 BHCA. In this case: Total BHCA during the busy hour = 2500∗3 + 2500∗3 = 15,000 Total bandwidth required between the sites = Total ICCS bandwidth + Total database bandwidth Because total BHCA is 15,000 (greater than 10,000), we can use the formula to calculate: Total ICCS bandwidth = (15,000/10,000) ∗ (1 + 0.006∗80) = 2.22 Mbps Total database bandwidth = (Number of servers remote to the publisher) ∗ 1.544 = 3 ∗ 1.544 = 4.632 Mbps Total bandwidth required between the sites = 2.22 Mbps + 4.632 Mbps = 6.852 Mbps (Approximately 7 Mbps) • When directory numbers are shared between sites that are clustered over the WAN, additional bandwidth must be reserved. This overhead or additional bandwidth (in addition to the minimum 1.544 Mbps bandwidth) for 10,000 BHCA between shared DNs can be calculated using the following equation: Overhead = (0.012 ∗ Delay ∗ Shared-line) + (0.65 ∗ Shared-line), where: Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x)OL-16394-07 2-27

Chapter 2 Unified Communications Deployment Models Clustering Over the IP WAN Delay = RTT delay over the IP WAN, in msec Shared-line = Average number of additional phones on which a directory number is shared across the WAN. The following equation may be used as a guideline to calculate the bandwidth for more than 10,000 BHCA between shared directory numbers at a specific delay: Total bandwidth (Mbps) = (Total BHCA/10,000) ∗ (1 + 0.006 ∗ Delay + 0.012 ∗ Delay ∗ Shared-line + 0.65 ∗ Shared-line), where: Delay = RTT delay in msec Shared-line = Average number of additional phones on which a directory number is shared across the WAN. Example 2-2 Bandwidth Calculation for Two Sites with Shared Directory Numbers Consider two sites, Site 1 and Site 2, with Unified CM clustered over the WAN across these two sites that are 80 msec round-trip time apart. Site 1 has one publisher, one combined TFTP and music on hold (MoH) server, and two Unified CM subscriber servers. Site 2 has one TFTP/MoH server and two Unified CM subscriber servers. Site 1 has 5000 phones, each having one DN; and Site 2 has 5000 phones, each sharing a DN with the 5000 phones in Site 1. Thus, each DN is shared across the WAN with an average of one additional phone. During the busy hour, 2500 phones in Site 1 call 2500 phones in Site 2, each at 3 BHCA. This also causes the phones in Site 1 to ring. During that same busy hour, 2500 phones in Site 2 call 2500 phones in Site 1, each at 3 BHCA. This also causes the phones in Site 2 to ring. In this case: Total BHCA during the busy hour = 2500 ∗ 3 + 2500 ∗ 3 = 15,000 Total bandwidth required between the sites = Total ICCS bandwidth + Total database bandwidth Because total BHCA is 15,000 (greater than 10,000), we can use the formula to calculate: Total ICCS bandwidth = (15,000/10,000) ∗ (1 + 0.006∗80 + 0.012∗80∗1 + 0.65∗1) = 4.635 Mbps Total database bandwidth = (Number of servers remote to the publisher) ∗ 1.544 = 3 ∗ 1.544 = 4.632 Mbps Total bandwidth required between the sites = 4.635 Mbps + 4.632 Mbps = 9.267 Mbps (Approximately 10 Mbps) Note The bandwidth requirements stated above are strictly for ICCS, database, and other inter-server traffic. If calls are going over the IP WAN, additional bandwidth must be provisioned for voice or media traffic, depending on the voice codec used for the calls. • Subscriber servers in the cluster read their local database. Database modifications can occur in both the local database as well as the publisher database, depending on the type of changes. Informix Dynamic Server (IDS) database replication is used to synchronize the databases on the various servers in the cluster. Therefore, when recovering from failure conditions such as the loss of WAN connectivity for an extended period of time, the Unified CM databases must be synchronized with any changes that might have been made during the outage. This process happens automatically when database connectivity is restored to the publisher and other servers in the cluster. This process can take longer over low bandwidth and/or higher delay links. In rare scenarios, manual reset or repair of the database replication between servers in the cluster might be required. This is performed by using the commands such as utils dbreplication repair all and/or utils dbreplication reset all at the command line interface (CLI). Repair or reset of database replication using the CLI on remote Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x)2-28 OL-16394-07

Chapter 2 Unified Communications Deployment Models Clustering Over the IP WAN subscribers over the WAN causes all Unified CM databases in the cluster to be re-synchronized, in which case additional bandwidth above 1.544 Mbps might be required. Lower bandwidths can take longer for database replication repair or reset to complete. Note Repairing or resetting of database replication on multiple subscribers at the same remote location can result in increased time for database replication to complete. Cisco recommends repairing or resetting of database replication on these remote subscribers one at a time. Repairing or resetting of database replication on subscribers at different remote locations may be performed simultaneously. • If remote branches using centralized call processing are connected to the main sites via clustering over the WAN, pay careful attention to the configuration of call admission control to avoid oversubscribing the links used for clustering over the WAN. – If the bandwidth is not limited on the links used for clustering over the WAN (that is, if the interfaces to the links are OC-3s or STM-1s and there is no requirement for call admission control), then the remote sites may be connected to any of the main sites because all the main sites should be configured as location Hub_None. This configuration still maintains hub-and-spoke topology for purposes of call admission control. – If you are using the Multiprotocol Label Switching (MPLS) Virtual Private Network (VPN) feature, all sites in Unified CM locations and the remote sites may register with any of the main sites. – If bandwidth is limited between the main sites, call admission control must be used between sites, and all remote sites must register with the main site that is configured as location Hub_None. This main site is considered the hub site, and all other remote sites and clustering-over-the-WAN sites are spokes sites. • During a software upgrade, all servers in the cluster should be upgraded during the same maintenance period, using the standard upgrade procedures outlined in the software release notes. The software upgrade time might increase for higher round-trip delay time over the IP WAN. Lower bandwidths such as 1.544 Mbps (T1 link) can cause the software upgrade process to take longer to complete, in which case additional bandwidth above 1.544 Mbps might be required if a faster upgrade process is desired.Unified CM Provisioning for Local Failover Provisioning of the Unified CM cluster for the local failover model should follow the design guidelines for capacities outlined in the chapter on Call Processing, page 8-1. If voice or video calls are allowed across the WAN between the sites, then you must configure Unified CM locations in addition to the default location for the other sites, to provide call admission control between the sites. If the bandwidth is over-provisioned for the number of devices, it is still best practice to configure call admission control based on locations. If the locations-based call admission control rejects a call, automatic failover to the PSTN can be provided by the automated alternate routing (AAR) feature. To improve redundancy and upgrade times, Cisco recommends that you enable the Cisco Trivial File Transfer Protocol (TFTP) service on two Unified CM servers. More than two TFTP servers can be deployed in a cluster, however this configuration can result in an extended period for rebuilding all the TFTP files on all TFTP servers. You can run the TFTP service on either a publisher or a subscriber server, depending on the site and the available capacity of the server. The TFTP server option must be correctly set in the DHCP servers at each site. If DHCP is not in use or if the TFTP server is manually configured, you should configure the correct address for the site. Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) OL-16394-07 2-29

Chapter 2 Unified Communications Deployment Models Clustering Over the IP WAN Other services, which may affect normal operation of Unified CM during WAN outages, should also be replicated at all sites to ensure uninterrupted service. These services include DHCP servers, DNS servers, corporate directories, and IP phone services. On each DHCP server, set the DNS server address correctly for each location. IP phones may have shared line appearances between the sites. During a WAN outage, call control for each line appearance is segmented, but call control returns to a single Unified CM server once the WAN is restored. During the WAN restoration period, there is additional traffic between the two sites. If this situation occurs during a period of high call volume, the shared lines might not operate as expected during that period. This situation should not last more than a few minutes, but if it is a concern, you can provision additional prioritized bandwidth to minimize the effects.Gateways for Local Failover Normally, gateways should be provided at all sites for access to the PSTN. The device pools should be configured to register the gateways with the Unified CM servers at the same site. Partitions and calling search spaces should also be configured to select the local gateways at the site as the first choice for PSTN access and the other site gateways as a second choice for overflow. Take special care to ensure emergency service access at each site. You can centralize access to the PSTN gateways if access is not required during a WAN failure and if sufficient additional bandwidth is configured for the number of calls across the WAN. For E911 requirements, additional gateways might be needed at each site.Voicemail for Local Failover Cisco Unity or other voicemail systems can be deployed at all sites and integrated into the Unified CM cluster. This configuration provides voicemail access even during a WAN failure and without using the PSTN. Using Voice Mail Profiles, you can allocate the correct voicemail system for the site to the IP phones in the same location. You can configure a maximum of four voicemail systems per cluster that use the SMDI protocol, that are attached directly to the COM port on a subscriber, and that use the Cisco Messaging Interface (CMI).Music on Hold and Media Resources for Local Failover Music on hold (MoH) servers and other media resources such as conference bridges should be provisioned at each site, with sufficient capacity for the type and number of users. Through the use of media resource groups (MRGs) and media resource group lists (MRGLs), media resources are provided by the on-site resource and are available during a WAN failure.Remote Failover Deployment Model The remote failover deployment model provides flexibility for the placement of backup servers. Each of the sites contains at least one primary Unified CM subscriber and may or may not have a backup subscriber. This model allows for a deployment of up to eight sites, with IP phones and other devices normally registered to a local subscriber when using 1:1 redundancy and the 50/50 load balancing option described in the chapter on Call Processing, page 8-1. Backup subscribers are located across the WAN at one or more of the other sites. (See Figure 2-7.) Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) 2-30 OL-16394-07

Chapter 2 Unified Communications Deployment Models Clustering Over the IP WAN Figure 2-7 Remote Failover Model with Four Sites M Publisher / TFTP M M M V V M IP IP IP IP WAN M V V M IP IP IP IP 74361 When implementing the remote failover model, observe all guidelines for the local failover model (see Local Failover Deployment Model, page 2-25), with the following modifications: • Configure each site to contain at least one primary Unified CM subscriber and an optional backup subscriber as desired. If a backup subscriber over the IP WAN is not desired, a Survivable Remote Site Telephony (SRST) router may be used as a backup call processing agent. • You may configure Unified CM groups and device pools to allow devices to register with servers over the WAN. • Signaling or call control traffic requires bandwidth when devices are registered across the WAN with a remote Unified CM server in the same cluster. This bandwidth might be more than the ICCS traffic and should be calculated using the bandwidth provisioning calculations for signaling, as described in Bandwidth Provisioning, page 3-58. Note You can also combine the features of these two types of deployments for disaster recovery purposes. For example, Unified CM groups permit configuring up to three servers (primary, secondary and tertiary). Therefore, you can configure the Unified CM groups to have primary and secondary servers that are located at the same site and the tertiary server at a remote site over the WAN. Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x)OL-16394-07 2-31

Chapter 2 Unified Communications Deployment Models Design Considerations for Section 508 ConformanceDesign Considerations for Section 508 Conformance Regardless of which deployment model you choose, you should consider designing your Cisco Unified Communications network to make the telephony features more accessible to users with disabilities, in conformance with Section 255 of the Telecommunications Act and U.S. Section 508. Observe the following basic design guidelines when configuring your Cisco Unified Communications network to conform to Section 508: • Enable Quality of Service (QoS) on the network. • Configure only the G.711 codec for phones that will be connected to a terminal teletype (TTY) device or a Telephone Device for the Deaf (TDD). Although low bit-rate codecs such as G.729 are acceptable for audio transmissions, they do not work well for TTY/TDD devices if they have an error rate higher than 1% Total Character Error Rate (TCER). • Configure TTY/TDD devices for G.711 across the WAN, if necessary. • Enable (turn ON) Echo Cancellation for optimal performance. • Voice Activity Detection (VAD) does not appear to have an effect on the quality of the TTY/TDD connection, so it may be disabled or enabled. • Configure the appropriate regions and device pools in Unified CM to ensure that the TTY/TDD devices always use G.711 codecs. • Connect the TTY/TDD to the Cisco Unified Communications network in either of the following ways: – Direct connection (Recommended method) Plug a TTY/TDD with an RJ-11 analog line option directly into a Cisco FXS port. Any FXS port will work, such as the one on the Cisco VG248, Catalyst 6000, Cisco ATA 188 module, or any other Cisco voice gateway with an FXS port. Cisco recommends this method of connection. – Acoustic coupling Place the IP phone handset into a coupling device on the TTY/TDD. Acoustic coupling is less reliable than an RJ-11 connection because the coupling device is generally more susceptible to transmission errors caused by ambient room noise and other factors. • If stutter dial tone is required, use an analog phone in conjunction with an FXS port on the Cisco VG248 or ATA 188. In addition, most Cisco IP Phones support stutter dial tone, which is sometimes referred to as audible message waiting indication (AMWI). For a list of the specific Cisco IP Phone models that support this functionality, see the Endpoint Features Summary, page 20-47. Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) 2-32 OL-16394-07

CH A P T E R 3 Network Infrastructure Last revised on: June 4, 2010 This chapter describes the requirements of the network infrastructure needed to build an IP telephony system in an enterprise environment. Figure 3-1 illustrates the roles of the various devices that form the network infrastructure, and Table 3-1 summarizes the features required to support each of these roles. IP telephony places strict requirements on IP packet loss, packet delay, and delay variation (or jitter). Therefore, you need to enable most of the Quality of Service (QoS) mechanisms available on Cisco switches and routers throughout the network. For the same reasons, redundant devices and network links that provide quick convergence after network failures or topology changes are also important to ensure a highly available infrastructure The following sections describe the network infrastructure features as they relate to: • LAN Infrastructure, page 3-4 • WAN Infrastructure, page 3-35 • Wireless LAN Infrastructure, page 3-72 Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x)OL-16394-07 3-1

Chapter 3 Network InfrastructureFigure 3-1 Typical Campus Network Infrastructure Central Site IP IP IP IP IP IP IP IP IP Campus access layerCampus distribution layer Campus core layer WAN aggregation V V ISDN backup IP WAN PSTN Branch router V V V V Branch switch IP IP IP IP IP IP IP IP 77290 Branch offices Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) 3-2 OL-16394-07

Chapter 3 Network Infrastructure Whats New in This Chapter Table 3-1 Required Features for Each Role in the Network Infrastructure Infrastructure Role Required Features Campus Access Switch • In-Line Power • Multiple Queue Support • 802.1p and 802.1Q • Fast Link Convergence Campus Distribution or Core • Multiple Queue Support Switch • 802.1p and 802.1Q • Traffic Classification • Traffic Reclassification WAN Aggregation Router • Multiple Queue Support (Site that is at the hub of the • Traffic Shaping network) • Link Fragmentation and Interleaving (LFI) • Link Efficiency • Traffic Classification • Traffic Reclassification • 802.1p and 802.1Q Branch Router • Multiple Queue Support (Spoke site) • LFI • Link Efficiency • Traffic Classification • Traffic Reclassification • 802.1p and 802.1Q Branch or Smaller Site Switch • In-Line Power • Multiple Queue Support • 802.1p and 802.1QWhats New in This Chapter Table 3-2 lists the topics that are new in this chapter or that have changed significantly from previous releases of this document. Table 3-2 New or Changed Information Since the Previous Release of This Document New or Revised Topic Described in: Cisco Unified Wireless IP Phone 7925G Mentioned in various sections throughout this chapter Dynamic Multipoint VPN Dynamic Multipoint VPN (DMVPN), page 3-38 Interference from Bluetooth devices Wireless Interference, page 3-75 Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) OL-16394-07 3-3

Chapter 3 Network Infrastructure LAN Infrastructure Table 3-2 New or Changed Information Since the Previous Release of This Document New or Revised Topic Described in: QoS Enforcement using Trusted Relay QoS Enforcement Using a Trusted Relay Point (TRP), Point (TRP) page 3-34 Routed access layer designs Routed Access Layer Designs, page 3-7 RSVP P Hop Overwrite RSVP in MPLS Networks, page 3-49 Security for wireless endpoints Wireless Security, page 3-77LAN Infrastructure Campus LAN infrastructure design is extremely important for proper IP telephony operation on a converged network. Proper LAN infrastructure design requires following basic configuration and design best practices for deploying a highly available network. Further, proper LAN infrastructure design requires deploying end-to-end QoS on the network. The following sections discuss these requirements: • LAN Design for High Availability, page 3-4 • LAN Quality of Service (QoS), page 3-31LAN Design for High Availability Properly designing a LAN requires building a robust and redundant network from the top down. By structuring the LAN as a layered model (see Figure 3-1) and developing the LAN infrastructure one step of the model at a time, you can build a highly available, fault tolerant, and redundant network. Once these layers have been designed properly, you can add network services such as DHCP and TFTP to provide additional network functionality. The following sections examine the infrastructure layers and network services: • Campus Access Layer, page 3-4 • Campus Distribution Layer, page 3-9 • Campus Core Layer, page 3-13 • Network Services, page 3-14 For more information on campus design, refer to the Gigabit Campus Network Design white paper at http://www.cisco.com/warp/public/cc/so/neso/lnso/cpso/gcnd_wp.pdfCampus Access Layer The access layer of the Campus LAN includes the portion of the network from the desktop port(s) to the wiring closet switch. Access layer switches have traditionally been configured as Layer 2 devices with Layer 2 uplinks to the distribution layer. The Layer 2 and spanning tree recommendations for Layer 2 access designs are well documented and are discussed briefly below. For newer Cisco Catalyst switches supporting Layer 3 protocols, new routed access designs are possible and offer improvements in convergence times and design simplicity. Routed access designs are discussed in the section on Routed Access Layer Designs, page 3-7. Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) 3-4 OL-16394-07

Chapter 3 Network Infrastructure LAN InfrastructureLayer 2 Access Design Recommendations Proper access layer design starts with assigning a single IP subnet per virtual LAN (VLAN). Typically, a VLAN should not span multiple wiring closet switches; that is, a VLAN should have presence in one and only one access layer switch (see Figure 3-2). This practice eliminates topological loops at Layer 2, thus avoiding temporary flow interruptions due to Spanning Tree convergence. However, with the introduction of standards-based IEEE 802.1w Rapid Spanning Tree Protocol (RSTP) and 802.1s Multiple Instance Spanning Tree Protocol (MISTP), Spanning Tree can converge at much higher rates. More importantly, confining a VLAN to a single access layer switch also serves to limit the size of the broadcast domain. There is the potential for large numbers of devices within a single VLAN or broadcast domain to generate large amounts of broadcast traffic periodically, which can be problematic. A good rule of thumb is to limit the number of devices per VLAN to about 512, which is equivalent to two Class C subnets (that is, a 23-bit subnet masked Class C address). Typical access layer switches include the stackable Cisco Catalyst 2950, 3500XL, 3550, and 3750, as well as the Cisco 3560 and the larger, higher-density Catalyst 4000 and 6000 switches. Note The recommendation to limit the number of devices in a single Unified Communications VLAN to approximately 512 is not solely due to the need to control the amount of VLAN broadcast traffic. For Linux-based Unified CM server platforms, the ARP cache has a hard limit of 1024 devices. Installing Unified CM in a VLAN with a IP subnet containing more than 1024 devices can cause the Unified CM server ARP cache to fill up quickly, which can seriously affect communications between the Unified CM server and other Unified Communications endpoints. Even though the ARP cache size on Windows-based Unified CM server platforms expands dynamically, Cisco strongly recommends a limit of 512 devices in any VLAN regardless of the operating system used by the Unified CM server platform. Figure 3-2 Access Layer Switches and VLANs for Voice and Data Distribution Switches Access Switches Cat4000 Cat4000 Cat3550 Cat3550 Cat3550 VVID=110 VVID=111 VVID=310 VVID=311 VVID=312 IP IP IP IP IP VLAN=10 VLAN=11 VLAN=30 VLAN=31 VLAN=32 114468 High Density Switches Stackable Switches Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) OL-16394-07 3-5

Chapter 3 Network Infrastructure LAN Infrastructure When you deploy voice, Cisco recommends that you enable two VLANs at the access layer: a native VLAN for data traffic (VLANs 10, 11, 30, 31, and 32 in Figure 3-2) and a voice VLAN under Cisco IOS or Auxiliary VLAN under CatOS for voice traffic (represented by VVIDs 110, 111, 310, 311, and 312 in Figure 3-2). Separate voice and data VLANs are recommended for the following reasons: • Address space conservation and voice device protection from external networks Private addressing of phones on the voice or auxiliary VLAN ensures address conservation and ensures that phones are not accessible directly through public networks. PCs and servers are typically addressed with publicly routed subnet addresses; however, voice endpoints should be addressed using RFC 1918 private subnet addresses. • QoS trust boundary extension to voice devices QoS trust boundaries can be extended to voice devices without extending these trust boundaries and, in turn, QoS features to PCs and other data devices. • Protection from malicious network attacks VLAN access control, 802.1Q, and 802.1p tagging can provide protection for voice devices from malicious internal and external network attacks such as worms, denial of service (DoS) attacks, and attempts by data devices to gain access to priority queues through packet tagging. • Ease of management and configuration Separate VLANs for voice and data devices at the access layer provide ease of management and simplified QoS configuration. To provide high-quality voice and to take advantage of the full voice feature set, access layer switches should provide support for: • 802.1Q trunking and 802.1p for proper treatment of Layer 2 CoS packet marking on ports with phones connected • Multiple egress queues to provide priority queuing of RTP voice packet streams • The ability to classify or reclassify traffic and establish a network trust boundary • Inline power capability (Although inline power capability is not mandatory, it is highly recommended for the access layer switches.) • Layer 3 awareness and the ability to implement QoS access control lists (These features are required if you are using certain IP telephony endpoints, such as a PC running a softphone application, that cannot benefit from an extended trust boundary.)Spanning Tree Protocol (STP) To minimize convergence times and maximize fault tolerance at Layer 2, enable the following STP features: • PortFast Enable PortFast on all access ports. The phones, PCs, or servers connected to these ports do not forward bridge protocol data units (BPDUs) that could affect STP operation. PortFast ensures that the phone or PC, when connected to the port, is able to begin receiving and transmitting traffic immediately without having to wait for STP to converge. Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) 3-6 OL-16394-07

Chapter 3 Network Infrastructure LAN Infrastructure • Root guard or BPDU guard Enable root guard or BPDU guard on all access ports to prevent the introduction of a rogue switch that might attempt to become the Spanning Tree root, thereby causing STP re-convergence events and potentially interrupting network traffic flows. Ports that are set to errdisable state by BPDU guard must either be re-enabled manually or the switch must be configured to re-enable ports automatically from the errdisable state after a configured period of time. • UplinkFast and BackboneFast Enable these features where appropriate to ensure that, when changes occur on the Layer 2 network, STP converges as rapidly as possible to provide high availability. When using stackable switches such as the Catalyst 2950, 3550, or 3750, enable Cross-Stack UplinkFast (CSUF) to provide fast failover and convergence if a switch in the stack fails. • UniDirectional Link Detection (UDLD) Enable this feature to reduce convergence and downtime on the network when link failures or misbehaviors occur, thus ensuring minimal interruption of network service. UDLD detects, and takes out of service, links where traffic is flowing in only one direction. This feature prevents defective links from being mistakenly considered as part of the network topology by the Spanning Tree and routing protocols. Note With the introduction of RSTP 802.1w, features such as PortFast and UplinkFast are not required because these mechanisms are built in to this standard. If RSTP has been enabled on the Catalyst switch, these commands are not necessary.Routed Access Layer Designs For campus designs requiring simplified configuration, common end-to-end troubleshooting tools, and the fastest convergence, a distribution block design using Layer 3 switching in the access layer (routed access) in combination with Layer 3 switching at the distribution layer provides the fastest restoration of voice and data traffic flows.Migrating the L2/L3 Boundary to the Access Layer In the typical hierarchical campus design, distribution blocks use a combination of Layer 2, Layer 3, and Layer 4 protocols and services to provide for optimal convergence, scalability, security, and manageability. In the most common distribution block configurations, the access switch is configured as a Layer 2 switch that forwards traffic on high-speed trunk ports to the distribution switches. The distribution switches are configured to support both Layer 2 switching on their downstream access switch trunks and Layer 3 switching on their upstream ports toward the core of the network, as shown in Figure 3-3. Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) OL-16394-07 3-7

Chapter 3 Network InfrastructureLAN Infrastructure Figure 3-3 Traditional Campus Design — Layer 2 Access with Layer 3 Distribution Core Layer 3 Distribution HSRP Active HSRP Root Bridge Standby Layer 2 Access 271569 VLAN 2 Voice VLAN 3 Voice VLAN n Voice VLAN 102 Data VLAN 103 Data VLAN 100 + n Data The purpose of the distribution switch in this design is to provide boundary functions between the bridged Layer 2 portion of the campus and the routed Layer 3 portion, including support for the default gateway, Layer 3 policy control, and all the multicast services required. An alternative configuration to the traditional distribution block model illustrated in Figure 3-3 is one in which the access switch acts as a full Layer 3 routing node (providing both Layer 2 and Layer 3 switching) and the access-to-distribution Layer 2 uplink trunks are replaced with Layer 3 point-to-point routed links. This alternative configuration, in which the Layer 2/3 demarcation is moved from the distribution switch to the access switch (as shown in Figure 3), appears to be a major change to the design but is actually just an extension of the current best-practice design. Figure 3-4 Routed Access Campus Design — Layer 3 Access with Layer 3 Distribution Core Layer 3 Distribution Access Layer 2 271570 VLAN 2 Voice VLAN 3 Voice VLAN n Voice VLAN 102 Data VLAN 103 Data VLAN 100 + n Data In both the traditional Layer 2 and the Layer 3 routed access designs, each access switch is configured with unique voice and data VLANs. In the Layer 3 design, the default gateway and root bridge for these VLANs is simply moved from the distribution switch to the access switch. Addressing for all end stations and for the default gateway remains the same. VLAN and specific port configurations remain Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x)3-8 OL-16394-07

Chapter 3 Network Infrastructure LAN Infrastructure unchanged on the access switch. Router interface configuration, access lists, "ip helper," and any other configuration for each VLAN remain identical but are configured on the VLAN Switched Virtual Interface (SVI) defined on the access switch instead of on the distribution switches. There are several notable configuration changes associated with the move of the Layer 3 interface down to the access switch. It is no longer necessary to configure an HSRP or GLBP virtual gateway address as the "router" interfaces because all the VLANs are now local. Similarly, with a single multicast router, for each VLAN it is not necessary to perform any of the traditional multicast tuning such as tuning PIM query intervals or ensuring that the designated router is synchronized with the active HSRP gateway.Routed Access Convergence The many potential advantages of using a Layer 3 access design include the following: • Improved convergence • Simplified multicast configuration • Dynamic traffic load balancing • Single control plane • Single set of troubleshooting tools (for example, ping and traceroute) Of these advantages, perhaps the most significant is the improvement in network convergence times possible when using a routed access design configured with EIGRP or OSPF as the routing protocol. Comparing the convergence times for an optimal Layer 2 access design (either with a spanning tree loop or without a loop) against that of the Layer 3 access design, you can obtain a four-fold improvement in convergence times, from 800 to 900 msec for the Layer 2 design to less than 200 msec for the Layer 3 access design. For more information on routed access designs, refer to the document on High Availability Campus Network Design – Routed Access Layer using EIGRP or OSPF, available at http://www.cisco.com/application/pdf/en/us/guest/netsol/ns432/c649/ccmigration_09186a0080811 468.pdfCampus Distribution Layer The distribution layer of the Campus LAN includes the portion of the network from the wiring closet switches to the next-hop switch. Distribution layer switches typically include Layer 3-enabled Cisco Catalyst 4000 and 6000 Series switches and the Cisco Catalyst 3750 for smaller deployments. At the distribution layer, it is important to provide redundancy to ensure high availability, including redundant links between the distribution layer switches (or routers) and the access layer switches. To avoid creating topological loops at Layer 2, use Layer 3 links for the connections between redundant Distribution switches when possible.First-Hop Redundancy Protocols In the campus hierarchical model, where the distribution switches are the L2/L3 boundary, they also act as the default gateway for the entire L2 domain that they support. Some form of redundancy is required because this environment can be large and a considerable outage could occur if the device acting as the default gateway fails. Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) OL-16394-07 3-9

Chapter 3 Network Infrastructure LAN Infrastructure Hot Standby Router Protocol and Virtual Router Redundancy Protocol Cisco developed the Hot Standby Router Protocol (HSRP) to address the need for default gateway redundancy. The Internet Engineering Task Force (IETF) subsequently ratified Virtual Router Redundancy Protocol (VRRP) as the standards-based method of providing default gateway redundancy. HSRP and VRRP with Cisco enhancements both provide a robust method of backing up the default gateway, and they can provide failover in less than one second to the redundant distribution switch when tuned properly. In choosing between HSRP and VRRP, Cisco recommends HSRP because it is a Cisco-owned standard, which allows for the rapid development of new features and functionality for HSRP before VRRP. However, VRRP is the logical choice when interoperability with a non-Cisco device is required. Gateway Load Balancing Protocol (GLBP) Like HSRP and VRRP, Ciscos Gateway Load Balancing Protocol (GLBP) protects data traffic from a failed router or circuit, while also allowing packet load sharing between a group of redundant routers. When HSRP or VRRP are used to provide default gateway redundancy, the backup members of the peer relationship are idle, waiting for a failure event to occur for them to take over and actively forward traffic. Before the development of GLBP, methods to utilize uplinks more efficiently were difficult to implement and manage. In one technique, the HSRP and STP/RSTP root alternated between distribution node peers, with the even VLANs homed on one peer and the odd VLANs homed on the alternate. Another technique used multiple HSRP groups on a single interface and used DHCP to alternate between the multiple default gateways. These techniques worked but were not optimal from a configuration, maintenance, or management perspective. GLPB is configured and functions like HSRP. For HSRP, a single virtual MAC address is given to the endpoints when they use Address Resolution Protocol (ARP) to learn the physical MAC address of their default gateways. Two virtual MAC addresses exist with GLBP, one for each GLBP peer. When an endpoint uses ARP to determine its default gateway, the virtual MAC addresses are checked in a round-robin basis. Failover and convergence work just like with HSRP. The backup peer assumes the virtual MAC address of the device that has failed, and begins forwarding traffic for its failed peer. The end result is that a more equal utilization of the uplinks is achieved with minimal configuration. As a side effect, a convergence event on the uplink or on the primary distribution node affects only half as many hosts, giving a convergence event an average of 50 percent less impact. The following section provides a description of HSRP configuration and operation. As stated, GLBP is configured and functions like HSRP, but has the additional benefit of basic load balancing functionality. For more information on HRSP, VRRP, and GLBP, refer to the Campus Network for High Availability Design Guide, available at http://www.cisco.com/application/pdf/en/us/guest/netsol/ns431/c649/ccmigration_09186a008093b 876.pdfHot Standby Router Protocol (HSRP) HSRP should also be enabled at the distribution layer to ensure that all routers are made redundant and that, in the event of a failure, another router can take over. HSRP configuration should incorporate the following: • Standby track The standby track command indicates that the HSRP should monitor a particular interface(s). If the interface goes down, then the HSRP priority of the box is reduced, typically forcing a failover to another device. This command is used in conjunction with the standby preempt command. Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) 3-10 OL-16394-07

Chapter 3 Network Infrastructure LAN Infrastructure • Standby preempt This command ensures that, when a devices priority becomes higher than all the other HSRP-configured devices in the standby group, that device will take over as the active Layer 3 router for the HSRP standby address. HSRP should also be configured in such a way as to load-balance traffic between both HSRP routers. To provide load balancing, configure each HSRP device as the active HSRP router for one VLAN or interface, and configure the standby router for another VLAN or interface. Evenly distributing active and standby VLANs between both HSRP devices ensures load-balancing. Devices on one VLAN use the active HSRP device as their default gateway, and devices on another VLAN use the same HSRP device as a standby default gateway only if the other HSRP device fails. This type of configuration prevents all network traffic from being sent to a single active router and enables other HSRP devices to help carry the load. Figure 3-5 shows an example of an HSRP-enabled network. In this figure, the two Catalyst 6500 switches (6500-SW1 and 6500-SW2) have been configured with multiple VLAN interfaces. Assuming that there are no link failures in the network, 6500-SW1 is the standby HSRP router for VLAN 110 (the voice VLAN for Group A phones) and is the active HSRP router for VLAN 10 (the data VLAN) and for VLAN 120 (the voice VLAN for Group B phones). 6500-SW2 is configured in reverse; it is the active HSRP router for VLAN 110 and the standby HSRP router for VLAN 10 and VLAN 120. As configured, both switches are actively in use, and the load can be distributed between the two by evenly distributing all Layer 2 VLANs between them. Each switch is also configured to track its local VLAN 200 interface and, in the event of a VLAN 200 link failure, the other switch will preempt and become the active router for all VLANs. Likewise, if either switch fails, the other switch will handle the traffic for all three VLANs. The PCs and phones at the access layer in Figure 3-5 have been configured with default gateways that correspond to the HSRP addresses for each of the HSRP groups. Devices in voice VLANs 110 and 120 are pointing to 10.100.10.1 and 10.100.20.1, respectively, as the default gateways, which correspond to the HSRP addresses for the VLAN 110 and 120 interfaces on both switches. Devices in data VLAN 10 are pointing to 64.100.10.1 as the default gateway, which corresponds to the HSRP address of the VLAN 10 interface on both switches. Note that, while traffic flowing from the access layer to the distribution layer will be distributed between the two switches (as long as there are no failures), no mechanism exists to ensure distribution on the return path. Traffic returning from the core layer and destined for the access layer will follow the shortest and/or least costly routed path. Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x)OL-16394-07 3-11

Chapter 3 Network Infrastructure LAN InfrastructureFigure 3-5 HSRP Network Configuration Example with Standby Preempt and Standby Track PCs/Data Phones (Group B) Access layer Vlan: 10 Vlan: 120 Default GW: 64.100.10.1 Default GW: 10.100.20.1 IP IP IP IP IP Phones (Group A) IP Vlan: 110Default GW: 10.100.10.1 IP Distribution layer Vlan 10, 120 Vlan 110 6500-SW1 6500-SW2 Vlan 200 Vlan 200 Core layer 114399 Example 3-1 and Example 3-2 list the configurations for the two Catalyst 6500 switches shown in Figure 3-5. Example 3-1 Configuration for 6500-SW1 interface Vlan 10 description Data VLAN 10 ip address 64.100.10.11 255.255.255.0 standby preempt standby ip 64.100.10.1 standby track Vlan 200 interface Vlan110 description Voice VLAN 110 ip address 10.100.10.11 255.255.255.0 standby preempt standby ip 10.100.10.1 standby track Vlan 200 standby priority 95 interface Vlan120 description Voice VLAN 120 ip address 10.100.20.11 255.255.255.0 standby preempt standby ip 10.100.20.1 standby track Vlan 200 Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) 3-12 OL-16394-07

Chapter 3 Network Infrastructure LAN Infrastructure Example 3-2 Configuration for 6500-SW2 interface Vlan 10 description Data VLAN 10 ip address 64.100.10.12 255.255.255.0 standby preempt standby ip 64.100.10.1 standby track Vlan 200 standby priority 95 interface Vlan110 description Voice VLAN 110 ip address 10.100.10.12 255.255.255.0 standby preempt standby ip 10.100.10.1 standby track Vlan 200 interface Vlan120 description Voice VLAN 120 ip address 10.100.20.11 255.255.255.0 standby preempt standby ip 10.100.20.1 standby track Vlan 200 standby priority 95 How quickly HSRP converges when a failure occurs depends on how the HSRP hello and hold timers are configured. By default, these timers are set to 3 and 10 seconds respectively, which means that an hello packet will be sent between the HSRP standby group devices every 3 seconds and that the standby device will become active when an hello packet has not been received for 10 seconds. You can lower these timer settings to speed up the failover or preemption; however, to avoid increased CPU usage and unnecessary standby state flapping, do not set the hello timer below one (1) second or the hold timer below 4 seconds. Note that, if you are using the HSRP tracking mechanism and the tracked link fails, then the failover or preemption occurs immediately regardless of the hello and hold timers.Routing Protocols Configure Layer 3 routing protocols, such as Open Shortest Path First (OSPF) and Enhanced Interior Gateway Routing Protocol (EIGRP), at the distribution layer to ensure fast convergence, load balancing, and fault tolerance. Use parameters such as routing protocol timers, path or link costs, and address summaries to optimize and control convergence times as well as to distribute traffic across multiple paths and devices. Cisco also recommends using the passive-interface command to prevent routing neighbor adjacencies via the access layer. These adjacencies are typically unnecessary, and they create extra CPU overhead and increased memory utilization because the routing protocol keeps track of them. By using the passive-interface command on all interfaces facing the access layer, you prevent routing updates from being sent out on these interfaces and, therefore, neighbor adjacencies are not formed.Campus Core Layer The core layer of the Campus LAN includes the portion of the network from the distribution routers or Layer 3 switches to one or more high-end core Layer 3 switches or routers. Layer 3-capable Catalyst 6000 switches are the typical core layer devices, and these core switches can provide connectivity between numerous campus distribution layers. Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) OL-16394-07 3-13

Chapter 3 Network Infrastructure LAN Infrastructure At the core layer, it is again very important to provide the following types of redundancy to ensure high availability: • Redundant link or cable paths Redundancy here ensures that traffic can be rerouted around downed or malfunctioning links. • Redundant devices Redundancy here ensures that, in the event of a device failure, another device in the network can continue performing tasks that the failed device was doing. • Redundant device sub-systems This type of redundancy ensures that multiple power supplies and Supervisor engines are available within a device so that the device can continue to function in the event that one of these components fails. Routing protocols at the core layer should again be configured and optimized for path redundancy and fast convergence. There should be no STP in the core because network connectivity should be routed at Layer 3. Finally, each link between the core and distribution devices should belong to its own VLAN or subnet and be configured using a 30-bit subnet mask. Data Center and Server Farm Typically, Cisco Unified Communications Manager (Unified CM) cluster servers, including media resource servers, reside in a data center or server farm environment. In addition, centralized gateways and centralized hardware media resources such as conference bridges, DSP or transcoder farms, and media termination points are located in the data center or server farm. Because these servers and resources are critical to voice networks, Cisco recommends distributing all Unified CM cluster servers, centralized voice gateways, and centralized hardware resources between multiple physical switches and, if possible, multiple physical locations within the campus. This distribution of resources ensures that, given a hardware failure (such as a switch or switch line card failure), at least some servers in the cluster will still be available to provide telephony services. In addition, some gateways and hardware resources will still be available to provide access to the PSTN and to provide auxiliary services. Besides being physically distributed, these servers, gateways, and hardware resources should be distributed among separate VLANs or subnets so that, if a broadcast storm or denial of service attack occurs on a particular VLAN, not all voice connectivity and services will be disrupted.Network Services The deployment of an IP Communications system requires the coordinated design of a well structured, highly available, and resilient network infrastructure as well as an integrated set of network services including Domain Name System (DNS), Dynamic Host Configuration Protocol (DHCP), Trivial File Transfer Protocol (TFTP), and Network Time Protocol (NTP).Domain Name System (DNS) DNS enables the mapping of host names and network services to IP addresses within a network or networks. DNS server(s) deployed within a network provide a database that maps network services to hostnames and, in turn, hostnames to IP addresses. Devices on the network can query the DNS server and receive IP addresses for other devices in the network, thereby facilitating communication between network devices. Complete reliance on a single network service such as DNS can introduce an element of risk when a critical Unified Communications system is deployed. If the DNS server becomes unavailable and a network device is relying on that server to provide a hostname-to-IP-address mapping, communication Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) 3-14 OL-16394-07

Chapter 3 Network Infrastructure LAN Infrastructure can and will fail. For this reason, in networks requiring high availability, Cisco recommends that you do not rely on DNS name resolution for any communications between Unified CM and the Unified Communications endpoints. For standard deployments, Cisco recommends that you configure Unified CM(s), gateways, and endpoint devices to use IP addresses rather than hostnames. For endpoint devices, Cisco does not recommend configuration of DNS parameters such as DNS server addresses, hostnames, and domain names. During the initial installation of the publisher node in a Unified CM cluster, the publisher will be referenced in the server table by the hostname you provided for the system. Before installation and configuration of any subsequent subscribers or the definition of any endpoints, you should change this server entry to the IP address of the publisher rather than the hostname. Each subscriber added to the cluster should be defined in this same server table via IP address and not by hostname. Each subscriber should be added to this server table one device at a time, and there should be no definitions for non-existent subscribers at any time other than for the new subscriber being installed. During installation of the publisher and subscriber, Cisco recommend that you do not select the option to enable DNS unless DNS is specifically required for system management purposes. If DNS is enabled, Cisco still highly recommend that you do not use DNS names in the configuration of the IP Communications endpoints, gateways, and Unified CM servers. Even if DNS is enabled on the servers in the cluster, it is never used for any intra-cluster server-to-server communications and is used only for communications to devices external to the cluster itself. Cisco Unified CM 5.0 and later releases do not permit the manual configuration of HOSTS or LHOSTS files. A local version of the HOSTS table is automatically built by the publisher in each cluster and distributed to all subscriber nodes via a secure communications channel. This local table is used for managing secure intra-cluster communications and does not contain addresses or names of any endpoints other than the Unified CM servers themselves. LMHOSTS files do not exist and are not used by Cisco Unified CM 5.0 and later releases. Deploying Unified CM with DNS There are some situations in which configuring and using DNS might be unavoidable. For example, if Network Address Translation (NAT) is required for communications between the IP phones and Unified CM in the IP Communications network, DNS is required to ensure proper mapping of NAT translated addresses to network host devices. Likewise, some IP telephony disaster recovery network configurations rely on DNS to ensure proper failover of the network during failure scenarios by mapping hostnames to secondary backup site IP addresses. If either of these two situations exists and DNS must be configured, you must deploy DNS servers in a geographically redundant fashion so that a single DNS server failure will not prevent network communications between IP telephony devices. By providing DNS server redundancy in the event of a single DNS server failure, you ensure that devices relying on DNS to communicate on the network can still receive hostname-to-IP-address mappings from a backup or secondary DNS server. Note Hostname resolution within the cluster via either the local HOSTS file or DNS queries is performed only at subsystem initialization (that is, when a server is booted up). As a result, in order for a server within the cluster to resolve a DNS name that has been changed in either the HOSTS file or the DNS server, the Cisco CallManager Service must be restarted on all servers within the cluster. Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x)OL-16394-07 3-15

Chapter 3 Network Infrastructure LAN Infrastructure Unified CM can use DNS to: • Provide simplified system management • Resolve fully qualified domain names to IP addresses for trunk destinations • Resolve fully qualified domain names to IP addresses for SIP route patterns based on domain name • Resolve service (SRV) records to host names and then to IP addresses for SIP trunk destinations When DNS is used, Cisco recommends defining each Unified CM cluster as a member of a valid sub-domain within the larger organizational DNS domain, defining the DNS domain on each Cisco MCS server, and defining the primary and secondary DNS server addresses on each MCS server. shows an example of how DNS server could use A records (Hostname-to-IP-address resolution), Cname records (aliases), and SRV records (service records for redundancy and load balancing) in a Unified CM environment. Table 3-3 Example Use of DNS with Unified CM Host Name Type TTL Data CUCM-Admin.cluster1.cisco.com Host (A) 12 Hours 182.10.10.1 CUCM1.cluster1.cisco.com Host (A) Default 182.10.10.1 CUCM2.cluster1.cisco.com Host (A) Default 182.10.10.2 CUCM3.cluster1.cisco.com Host (A) Default 182.10.10.3 CUCM4.cluster1.cisco.com Host (A) Default 182.10.10.4 TFTP-server1.cluster1.cisco.com Host (A) 12 Hours 182.10.10.11 TFTP-server2.cluster1.cisco.com Host (A) 12 Hours 182.10.10.12 www.CUCM-Admin.cisco.com Alias (CNAME) Default CUCM-Admin.cluster1.cisco.com _sip._tcp.cluster1.cisco.com. Service (SRV) Default CUCM1.cluster1.cisco.com _sip._tcp.cluster1.cisco.com. Service (SRV) Default CUCM2.cluster1.cisco.com _sip._tcp.cluster1.cisco.com. Service (SRV) Default CUCM3.cluster1.cisco.com _sip._tcp.cluster1.cisco.com. Service (SRV) Default CUCM4.cluster1.cisco.comDynamic Host Configuration Protocol (DHCP) DHCP is used by hosts on the network to obtain initial configuration information, including IP address, subnet mask, default gateway, and TFTP server address. DHCP eases the administrative burden of manually configuring each host with an IP address and other configuration information. DHCP also provides automatic reconfiguration of network configuration when devices are moved between subnets. The configuration information is provided by a DHCP server located in the network, which responds to DHCP requests from DHCP-capable clients. You should configure IP Communications endpoints to use DHCP to simplify deployment of these devices. Any RFC 2131 compliant DHCP server can be used to provide configuration information to IP Communications network devices. When deploying IP telephony devices in an existing data-only network, all you have to do is add DHCP voice scopes to an existing DHCP server for these new voice devices. Because IP telephony devices are configured to use and rely on a DHCP server for IP configuration information, you must deploy DHCP servers in a redundant fashion. At least two DHCP servers should be deployed within the telephony network such that, if one of the servers fails, the other can continue to answer DHCP client requests. You should also ensure that DHCP server(s) are configured with enough IP subnet addresses to handle all DHCP-reliant clients within the network. Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) 3-16 OL-16394-07

Chapter 3 Network Infrastructure LAN Infrastructure DHCP Option 150 IP telephony endpoints can be configured to rely on DHCP Option 150 to identify the source of telephony configuration information, available from a server running the Trivial File Transfer Protocol (TFTP). In the simplest configuration, where a single TFTP server is offering service to all deployed endpoints, Option 150 is delivered as a single IP address pointing to the systems designated TFTP server. The DHCP scope can also deliver two IP addresses under Option 150, for deployments where there are two TFTP servers within the same cluster. The phone would use the second address if it fails to contact the primary TFTP server, thus providing redundancy. To achieve both redundancy and load sharing between the TFTP servers, you can configure Option 150 to provide the two TFTP server addresses in reverse order for half of the DHCP scopes. Note If the primary TFTP server is available but is not able to grant the requested file to the phone (for example, because the requesting phone is not configured on that cluster), the phone will not attempt to contact the secondary TFTP server. Cisco highly recommends using a direct IP address (that is, not relying on a DNS service) for Option 150 because doing so eliminates dependencies on DNS service availability during the phone boot-up and registration process. Note Even though IP phones support a maximum of two TFTP servers under Option 150, you could configure a Unified CM cluster with more than two TFTP servers. For instance, if a Unified CM system is clustered over a WAN at three separate sites, three TFTP servers could be deployed (one at each site). Phones within each site could then be granted a DHCP scope containing that sites TFTP server within Option 150. This configuration would bring the TFTP service closer to the endpoints, thus reducing latency and ensuring failure isolation between the sites (one sites failure would not affect TFTP service at another site). Phone DHCP Operation Following a Power Recycle If a phone is powered down and comes back up while the DHCP server is still offline, it will attempt to use DHCP to obtain IP addressing information (as normal). In the absence of a response from a DHCP server, the phone will re-use the previously received DHCP information to register with Unified CM. DHCP Lease Times Configure DHCP lease times as appropriate for the network environment. Given a fairly static network in which PCs and telephony devices remain in the same place for long periods of time, Cisco recommends longer DHCP lease times (for example, one week). Shorter lease times require more frequent renewal of the DHCP configuration and increase the amount of DHCP traffic on the network. Conversely, networks that incorporate large numbers of mobile devices, such as laptops and wireless telephony devices, should be configured with shorter DHCP lease times (for example, one day) to prevent depletion of DHCP-managed subnet addresses. Mobile devices typically use IP addresses for short increments of time and then might not request a DHCP renewal or new address for a long period of time. Longer lease times will tie up these IP addresses and prevent them from being reassigned even when they are no longer being used. Cisco Unified IP Phones adhere to the conditions of the DHCP lease duration as specified in the DHCP servers scope configuration. Once half the lease time has expired since the last successful DHCP server acknowledgment, the IP phone will request a lease renewal. This DHCP client Request, once acknowledged by the DHCP server, will allow the IP phone to retain use of the IP scope (that is, the IP address, default gateway, subnet mask, DNS server (optional), and TFTP server (optional)) for another Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x)OL-16394-07 3-17

Chapter 3 Network Infrastructure LAN Infrastructure lease period. If the DHCP server becomes unavailable, an IP phone will not be able to renew its DHCP lease, and as soon as the lease expires, it will relinquish its IP configuration and will thus become unregistered from Unified CM until a DHCP server can grant it another valid scope. In centralized call processing deployments, if a remote site is configured to use a centralized DHCP server (through the use of a DHCP relay agent such as the IP Helper Address in Cisco IOS) and if connectivity to the central site is severed, IP phones within the branch will not be able to renew their DHCP scope leases. In this situation, branch IP phones are at risk of seeing their DHCP lease expire, thus losing the use of their IP address, which would lead to service interruption. Given the fact that phones attempt to renew their leases at half the lease time, DHCP lease expiration can occur as soon as half the lease time since the DHCP server became unreachable. For example, if the lease time of a DHCP scope is set to 4 days and a WAN failure causes the DHCP server to be unavailable to the phones in a branch, those phones will be unable to renew their leases at half the lease time (in this case, 2 days). The IP phones could stop functioning as early as 2 days after the WAN failure, unless the WAN comes back up and the DHCP server is available before that time. If the WAN connectivity failure persists, all phones see their DHCP scope expire after a maximum of 4 days from the WAN failure. This situation can be mitigated by one of the following methods: • Set the DHCP scope lease to a long duration (for example, 8 days or more). This method would give the system administrator a minimum of half the lease time to remedy any DHCP reachability problem. Long lease durations also have the effect of reducing the frequency of network traffic associated with lease renewals. • Configure co-located DHCP server functionality (for example, run a DHCP server function on the branchs Cisco IOS router). This approach is immune to WAN connectivity interruption. One effect of such an approach is to decentralize the management of IP addresses, requiring incremental configuration efforts in each branch. (See DHCP Network Deployments, page 3-18, for more information.) Note The term co-located refers to two or more devices in the same physical location, with no WAN or MAN connection between them. DHCP Network Deployments There are two options for deploying DHCP functionality within an IP telephony network: • Centralized DHCP Server Typically, for a single-site campus IP telephony deployment, the DHCP server should be installed at a central location within the campus. As mentioned previously, redundant DHCP servers should be deployed. If the IP telephony deployment also incorporates remote branch telephony sites, as in a centralized multisite Unified CM deployment, a centralized server can be used to provide DHCP service to devices in the remote sites. This type of deployment requires that you configure the ip helper-address on the branch router interface. Keep in mind that, if redundant DHCP servers are deployed at the central site, both servers IP addresses must be configured as ip helper-address. Also note that, if branch-side telephony devices rely on a centralized DHCP server and the WAN link between the two sites fails, devices at the branch site will be unable to send DHCP requests or receive DHCP responses. Note By default, service dhcp is enabled on the Cisco IOS device and does not appear in the configuration. Do not disable this service on the branch router because doing so will disable the DHCP relay agent on the device, and the ip helper-address configuration command will not work. Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x)3-18 OL-16394-07

Chapter 3 Network Infrastructure LAN Infrastructure • Centralized DHCP Server and Remote Site Cisco IOS DHCP Server When configuring DHCP for use in a centralized multisite Unified CM deployment, you can use a centralized DHCP server to provide DHCP service to centrally located devices. Remote devices could receive DHCP service from a locally installed server or from the Cisco IOS router at the remote site. This type of deployment ensures that DHCP services are available to remote telephony devices even during WAN failures. Example 3-3 lists the basic Cisco IOS DHCP server configuration commands. Example 3-3 Cisco IOS DHCP Server Configuration Commands ! Activate DHCP Service on the IOS Device service dhcp ! Specify any IP Address or IP Address Range to be excluded from the DHCP pool ip dhcp excluded-address <ip-address>|<ip-address-low> <ip-address-high> ! Specify the name of this specific DHCP pool, the subnet and mask for this ! pool, the default gateway and up to four TFTP ip dhcp pool <dhcp-pool name> network <ip-subnet> <mask> default-router <default-gateway-ip> option 150 ip <tftp-server-ip-1> ... ! Note: IP phones use only the first two addresses supplied in the option 150 ! field even if more than two are configured. Unified CM DHCP Sever (Standalone versus Co-Resident DHCP) Typically DHCP servers are dedicated machine(s) in most network infrastructures, and they run in conjunction with the DNS and/or the Windows Internet Naming Service (WINS) services used by that network. In some instances, given a small Unified CM deployment with no more than 1000 devices registering to the cluster, you may run the DHCP server on a Unified CM server to support those devices. However, to avoid possible resource contention such as CPU contention with other critical services running on Unified CM, Cisco recommends moving the DHCP Server functionality to a dedicated server. If more than 1000 devices are registered to the cluster, DHCP must not be run on a Unified CM server but instead must be run on a dedicated or standalone server(s). Note The term co-resident refers to two or more services or applications running on the same server.Trivial File Transfer Protocol (TFTP) Within a Cisco Unified CM system, endpoints such as IP phones rely on a TFTP-based process to acquire configuration files, software images, and other endpoint-specific information. The Cisco TFTP service is a file serving system that can run on one or more Unified CM servers. It builds configuration files and serves firmware files, ringer files, device configuration files, and so forth, to endpoints. The TFTP file systems can hold several file types, such as the following: • Phone configuration files • Phone firmware files • Certificate Trust List (CTL) files Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) OL-16394-07 3-19

Chapter 3 Network Infrastructure LAN Infrastructure • Tone localization files • User interface (UI) localization and dictionary files • Ringer files • Softkey files • Dial plan files for SIP phones The TFTP server manages and serves two types of files, those that are not modifiable (for example, firmware files for phones) and those that can be modified (for example, configuration files). A typical configuration file contains a prioritized list of Unified CMs for a device (for example, an SCCP or SIP phone), the TCP ports on which the device connects to those Unified CMs, and an executable load identifier. Configuration files for selected devices contain locale information and URLs for the messages, directories, services, and information buttons on the phone... When a devices configuration changes, the TFTP server rebuilds the configuration files by pulling the relevant information from the Unified CM database. The new file(s) is then downloaded to the phone once the phone has been reset. As an example, if a single phones configuration file is modified (for example, during Extension Mobility login or logout), only that file is rebuilt and downloaded to the phone. However, if the configuration details of a device pool are changed (for example, if the primary Unified CM server is changed), then all devices in that device pool need to have their configuration files rebuilt and downloaded. For device pools that contain large numbers of devices, this file rebuilding process can impact server performance. Note Prior to Cisco Unified CM 6.1, to rebuild modified files, the TFTP server pulled information from the publishers database. With Unified CM 6.1 and later releases, the TFTP server can perform a local database read from the database on its co-resident subscriber server. Local database read not only provides benefits such as the preservation of user-facing features when the publisher in unavailable, but also allows multiple TFTP servers to be distributed by means of clustering over the WAN. (The same latency rules for clustering over the WAN apply to TFTP servers as to servers with registered phones.) This configuration brings the TFTP service closer to the endpoints, thus reducing latency and ensuring failure isolation between the sites. When a device requests a configuration file from the TFTP server, the TFTP server searches for the configuration file in its internal caches, the disk, and then alternate Cisco file servers (if specified). If the TFTP server finds the configuration file, it sends it to the device. If the configuration file provides Unified CM names, the device resolves the name by using DNS and opens a connection to the Unified CM. If the device does not receive an IP address or name, it uses the TFTP server name or IP address to attempt a registration connection. If the TFTP server cannot find the configuration file, it sends a "file not found" message to the device. A device that requests a configuration file while the TFTP server is rebuilding configuration files or while it is processing the maximum number of requests, will receive a message from the TFTP server that causes the device to request the configuration file later. The Maximum Serving Count service parameter, which can be configured, specifies the maximum number of requests that can be concurrently handled by the TFTP server. (Default value = 500 requests.) Use the default value if the TFTP service is run along with other Cisco CallManager services on the same server. For a dedicated TFTP server, use the following suggested values for the Maximum Serving Count: 1500 for a single-processor system or 3000 for a dual-processor system. Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x)3-20 OL-16394-07

Chapter 3 Network Infrastructure LAN Infrastructure An Example of TFTP in Operation Every time an endpoint reboots, the endpoint will request a configuration file (via TFTP) whose name is based on the requesting endpoints MAC address. (For a Cisco Unified IP Phone 7961 with MAC address ABCDEF123456, the file name would be SEPABCDEF123456.cnf.xml.) The received configuration file includes the version of software that the phone must run and a list of Cisco Unified CM servers with which the phone should register. The endpoint might also download, via TFTP, ringer files, softkey templates, and other miscellaneous files to acquire the necessary configuration information before becoming operational. If the configuration file includes software file(s) version numbers that are different than those the phone is currently using, the phone will also download the new software file(s) from the TFTP server to upgrade itself. The number of files an endpoint must download to upgrade its software varies based on the type of endpoint and the differences between the phones current software and the new software. For example, Cisco Unified IP Phones 7961, 7970, and 7971 download five software files under the worst-case software upgrade. TFTP File Transfer Times Each time an endpoint requests a file, there is a new TFTP transfer session. For centralized call processing deployments, the time to complete each of these transfers will affect the time it takes for an endpoint to start and become operational as well as the time it takes for an endpoint to upgrade during a scheduled maintenance. While TFTP transfer times are not the only factor that can affect these end states, they are a significant component. The time to complete each file transfer via TFTP is predictable as a function of the file size, the percentage of TFTP packets that must be retransmitted, and the network latency or round-trip time. At first glance, network bandwidth might seem to be missing from the previous statement, but it is actually included via the percentage of TFTP packets that must be retransmitted. This is because, if there is not enough network bandwidth to support the file transfer(s), then packets will be dropped by the network interface queuing algorithms and will have to be retransmitted. TFTP operates on top of the User Datagram Protocol (UDP). Unlike Transmission Control Protocol (TCP), UDP is not a reliable protocol, which means that UDP does not inherently have the ability to detect packet loss. Obviously, detecting packet loss in a file transfer is important, so RFC 1350 defines TFTP as a lock-step protocol. In other words, a TFTP sender will send one packet and wait for a response before sending the next packet (see Figure 3-6). Figure 3-6 Example of TFTP Packet Transmission Sequence Round Trip Time = 10ms Read Request Time = 10ms Data Packet Acknowledgement Time = 20ms Data Packet Acknowledgement 191938 Time = 30ms Data Packet If a response is not received in the timeout period (4 seconds by default), the sender will resend the data packet or acknowledgment. When a packet has been sent five times without a response, the TFTP session fails. Because the timeout period is always the same and not adaptive like a TCP timeout, packet loss can significantly increase the amount of time a transfer session takes to complete. Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x)OL-16394-07 3-21

Chapter 3 Network Infrastructure LAN Infrastructure Because the delay between each data packet is, at a minimum, equal to the network round-trip time, network latency also is a factor in the maximum throughput that a TFTP session can achieve. In Figure 3-7, the round-trip time has been increased to 40 ms and one packet has been lost in transit. While the error rate is high at 12%, it is easy to see the effect of latency and packet loss on TFTP because the time to complete the session increased from 30 ms (in Figure 3-6) to 4160 ms (in Figure 3-7). Figure 3-7 Effect of Packet Loss on TFTP Session Completion Time Round Trip Time = 40ms Read Request Time = 40ms Data Packet Acknowledgement Time = 80ms Data Packet Acknowledgement 4 second timeout (Packet loss) Acknowledgement 191939 Time = 4 sec + 120ms = 4120ms Data Packet Use the following formula to calculate how long a TFTP file transfer will take to complete: FileTransferTime = FileSize ∗ [(RTT + ERR ∗ Timeout) / 512000] Where: FileTransferTime is in seconds. FileSize is in bytes. RTT is the round-trip time in milliseconds. ERR is the error rate, or percentage of packets that are lost. Timeout is in milliseconds. 512000 = (TFTP packet size) ∗ (1000 millisecond per seconds) = (512 bytes) ∗ (1000 millisecond per seconds) Table 3-4 and Table 3-5 illustrate the use of this equation to calculate transfer times for the software files for various endpoint device types, protocols, and network latencies.Table 3-4 TFTP File Transfer Times for SCCP Devices Firmware Size Time to Complete Transfer (1% error rate)Device Type (Cisco (bytes, roundedUnified IP Phone) up to next 100k) 40 ms RTT 80 ms RTT 120 ms RTT 160 ms RTT 200 ms RTT7985 15,000,000 39 min 3 sec 58 min 35 sec 78 min 7 sec 97 min 39 sec 117 min 11 sec7921 9,700,000 25 min 15 sec 37 min 53 sec 50 min 31 sec 63 min 9 sec 75 min 46 sec7975 6,300,000 16 min 24 sec 24 min 36 sec 32 min 48 sec 41 min 0 sec 49 min 13 sec7970 or 7971 6,300,000 16 min 24 sec 24 min 36 sec 32 min 48 sec 41 min 0 sec 49 min 13 sec7965 or 7945 6,300,000 16 min 24 sec 24 min 36 sec 32 min 48 sec 41 min 0 sec 49 min 13 sec Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) 3-22 OL-16394-07

Chapter 3 Network Infrastructure LAN InfrastructureTable 3-4 TFTP File Transfer Times for SCCP Devices (continued) Firmware Size Time to Complete Transfer (1% error rate)Device Type (Cisco (bytes, roundedUnified IP Phone) up to next 100k) 40 ms RTT 80 ms RTT 120 ms RTT 160 ms RTT 200 ms RTT7962 or 7942 6,200,000 16 min 8 sec 24 min 13 sec 32 min 17 sec 40 min 21 sec 48 min 26 sec7941 or 7961 6,100,000 15 min 53 sec 23 min 49 sec 31 min 46 sec 39 min 42 sec 47 min 39 sec7931 6,100,000 15 min 53 sec 23 min 49 sec 31 min 46 sec 39 min 42 sec 47 min 39 sec7911 or 7906 6,100,000 15 min 53 sec 23 min 49 sec 31 min 46 sec 39 min 42 sec 47 min 39 sec7935 2,100,000 5 min 28 sec 8 min 12 sec 10 min 56 sec 13 min 40 sec 16 min 24 sec7920 1,200,000 3 min 7 sec 4 min 41 sec 6 min 15 sec 7 min 48 sec 9 min 22 sec7936 1,800,000 4 min 41 sec 7 min 1 sec 9 min 22 sec 11 min 43 sec 14 min 3 sec7940 or 7960 900,000 2 min 20 sec 3 min 30 sec 4 min 41 sec 5 min 51 sec 7 min 1 sec7910 400,000 1 min 2 sec 1 min 33 sec 2 min 5 sec 2 min 36 sec 3 min 7 sec7912 400,000 1 min 2 sec 1 min 33 sec 2 min 5 sec 2 min 36 sec 3 min 7 sec7905 400,000 1 min 2 sec 1 min 33 sec 2 min 5 sec 2 min 36 sec 3 min 7 sec7902 400,000 1 min 2 sec 1 min 33 sec 2 min 5 sec 2 min 36 sec 3 min 7 secTable 3-5 TFTP File Transfer Times for SIP Devices Firmware Size Time to Complete Transfer (1% error rate)Device Type (Cisco (bytes, roundedUnified IP Phone) up to next 100k) 40 ms RTT 80 ms RTT 120 ms RTT 160 ms RTT 200 ms RTT7975 6,600,000 17 min 11 sec 25 min 46 sec 34 min 22 sec 42 min 58 sec 51 min 33 sec7970 or 7971 6,700,000 17 min 26 sec 26 min 10 sec 34 min 53 sec 43 min 37 sec 52 min 20 sec7965 or 7945 6,600,000 17 min 11 sec 25 min 46 sec 34 min 22 sec 42 min 58 sec 51 min 33 sec7962 or 7942 6,500,000 16 min 55 sec 25 min 23 sec 33 min 51 sec 42 min 19 sec 50 min 46 sec7941 or 7961 6,500,000 16 min 55 sec 25 min 23 sec 33 min 51 sec 42 min 19 sec 50 min 46 sec7911 or 7906 6,400,000 16 min 40 sec 25 min 0 sec 33 min 20 sec 41 min 40 sec 50 min 0 sec7940 or 7960 900,000 2 min 20 sec 3 min 30 sec 4 min 41 sec 5 min 51 sec 7 min 1 sec7912 400,000 1 min 2 sec 1 min 33 sec 2 min 5 sec 2 min 36 sec 3 min 7 sec7905 400,000 1 min 2 sec 1 min 33 sec 2 min 5 sec 2 min 36 sec 3 min 7 sec The values in Table 3-4 and Table 3-5 are the approximate times to download the necessary firmware files to the phone. This is not an estimate of the time that it will take for a phone to upgrade to the new firmware and become operational. Cisco Unified IP Phone Firmware Releases 7.x have a 10-minute timeout when downloading new files. If the transfer is not completed within this time, the phone will discard the download even if the transfer completes successfully later. If you experience this problem, Cisco recommends that you use a local TFTP server to upgrade phones to the 8.x firmware releases, which have a timeout value of 61 minutes. Because network latency and packet loss have such an effect on TFTP transfer times, a local TFTP Server can be advantageous. This local TFTP server may be a Unified CM subscriber in a deployment with cluster over the WAN or an alternative local TFTP "Load Server" running on a Cisco Integrated Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) OL-16394-07 3-23

Chapter 3 Network Infrastructure LAN Infrastructure Services Router (ISR), for example. Newer endpoints (which have larger firmware files) can be configured with a Load Server address, which allows the endpoint to download the relatively small configuration files from the central TFTP server but use a local TFTP Server (which is not part of the Unified CM cluster) to download the larger software files. An alternative local TFTP Load Server is supported by the Cisco Unified IP Phones 7911, 7921, 7925, 7937, 7941, 7942, 7945, 7961, 7962, 7965, 7970, 7971, and 7975. Note The exact process each phone goes through on startup and the size of the files downloaded will depend on the phone model, the signaling type configured for the phone (SCCP, MGCP, or SIP) and the previous state of the phone. While there are differences in which files are requested, the general process each phone follows is the same, and in all cases TFTP is used to request and deliver the appropriate files. The general recommendations for TFTP server deployment do not change based on the protocol and/or phone models deployed. TFTP Server Redundancy Option 150 allows up to two IP addresses to be returned to phones as part of the DHCP scope. The phone tries the first address in the list, and it tries the subsequent address only if it cannot establish communications with the first TFTP server. This address list provides a redundancy mechanism that enables phones to obtain TFTP services from another server even if their primary TFTP server has failed. TFTP Load Sharing Cisco recommends that you grant different ordered lists of TFTP servers to different subnets to allow for load balancing. For example: • In subnet 10.1.1.0/24: Option 150: TFTP1_Primary, TFTP1_Secondary • In subnet 10.1.2.0/24: Option 150: TFTP1_Secondary, TFTP1_Primary Under normal operations, a phone in subnet 10.1.1.0/24 will request TFTP services from TFTP1_Primary, while a phone in subnet 10.1.2.0/24 will request TFTP services from TFTP1_Secondary. If TFTP1_Primary fails, then phones from both subnets will request TFTP services from TFTP1_Secondary. Load balancing avoids having a single TFTP server hot-spot, where all phones from multiple clusters rely on the same server for service. TFTP load balancing is especially important when phone software loads are transferred, such as during a Unified CM upgrade, because more files of larger size are being transferred, thus imposing a bigger load on the TFTP server. Centralized TFTP Services In multi-cluster systems, it is possible to have a single subnet or VLAN containing phones from multiple clusters. In this situation, the TFTP servers whose addresses are provided to all phones in the subnet or VLAN must answer the file transfer requests made by each phone, regardless of which cluster contains the phone. In a centralized TFTP deployment, a set of TFTP servers associated with one of the clusters must provide TFTP services to all the phones in the multi-cluster system. In order to provide this single point of file access, each clusters TFTP server must be able to serve files via the central proxy TFTP server. With Cisco Unified CM 5.0 and later releases, this proxy arrangement is accomplished by configuring a set of possible redirect locations in the central TFTP server, pointing to each of the other clusters’ TFTP servers. This configuration uses a HOST redirect statement in the Alternate File Locations on the centralized TFTP server, one for each of the other clusters. Each of the redundant TFTP servers in the centralized cluster should point to one of the redundant servers in each of the child clusters. It is not necessary to point the centralized server to both redundant servers in the Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x)3-24 OL-16394-07

Chapter 3 Network Infrastructure LAN Infrastructure child clusters because the redistribution of files within each individual cluster and the failover mechanisms of the phones between the redundant servers in the central cluster provide for a very high degree of fault tolerance. Figure 3-8 shows an example of the operation of this process. A request from a phone registered to Cluster 3 is directed to the centralized TFTP server configured in Cluster 1 (C1_TFTP_Primary). This server will in turn query each of the configured alternate TFTP servers until one responds with a copy of the file initially requested by the phone. Requests to the centralized secondary TFTP server (C1_TFTP_Secondary) will be sent by proxy to the other clusters’ secondary TFTP servers until either the requested file is found or all servers report that the requested file does not exist. Figure 3-8 Centralized TFTP Servers M M M M C2_TFTP_Primary M M M M C3_TFTP_Primary M M Proxy requests to alternate TFTP hosts M M M C1_TFTP_Primary M M C1_TFTP_Secondary TFTP request to Cisco Unified CM 153371 TFTP server identified via DHCP Option 150 IP Centralized TFTP in a Mixed Environment, with Servers Running Different Releases of Cisco Unified CM During migration from an older Unified CM release to Unified CM 5.0 and later releases, it is likely that a large centralized TFTP environment will have to operate in a mixed mode. Prior to Unified CM 5.0, the centralized TFTP servers did not request files from the child servers but rather had the TFTP directories of each of those clusters remotely mounted to the central server, which in turn was able to search all of the local and remote directories for the requested file. During a period of migration, it is necessary to provide a centralized TFTP server that can operate in both modes (mixed mode): remote mount for releases prior to Unified CM 5.0 and proxy request for Unified CM 5.0 and later releases. Because the servers for Unified CM 5.0 and later releases do not support remotely mounted file systems in a mixed environment, it is necessary to position Cisco Unified CM 4.1(3)SR3a or a later Windows OS-based release of Unified CM as the centralized mixed-mode TFTP cluster. Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x)OL-16394-07 3-25

Chapter 3 Network Infrastructure LAN Infrastructure Note Cisco Unified CM Release 4.1(3)SR3a (and subsequent Unified CM releases for the Windows OS platform) contain an upgrade to the cTFTP server daemon that allows it to support mixed-mode centralized TFTP designs. With these releases, the centralized TFTP server supports both remote mount and proxy request as methods for reaching Alternate TFTP Files servers in other clusters. When configuring the mixed-mode TFTP server, it is necessary to specify the servers for Unified CM 5.0 and later releases via the HOST proxy request and to specify any servers prior to Unified CM 4.1(3)SR3a by using the remote mount configuration process, as shown in Figure 3-9. (See below for details on the remote mount configuration.) Any child cluster supporting mixed mode can be configured as either a remote mount or as a proxy cluster. For centralized TFTP configurations, ensure that the main TFTP server exists in the cluster that runs the highest version of Cisco Unified Communications Manager. For example, if you are using a centralized TFTP server between a compatible Cisco Unified CM 4.x (mixed mode) cluster and a Unified CM 7.0 cluster, ensure that the central TFTP server exists in the Cisco Unified CM 7.0 cluster. If the centralized TFTP server exists in the cluster that runs the lower version of Cisco Unified Communications Manager, all phones use the locale files from this centralized TFTP server. These older locale files can create display issues for phones registered to clusters running a higher version of Cisco Unified CM because the newer localized phrases are not included in the locale files that are served from the main clusters TFTP server. Figure 3-9 Dual-Mode Configuration Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x)3-26 OL-16394-07

Chapter 3 Network Infrastructure LAN Infrastructure Centralized Configuration for Remote-Mount Servers Prior to Cisco Unified CM 4.1(3)SR3r If a TFTP server receives a request for a file that it does not have (such as a configuration file created and maintained by the TFTP server of a different cluster), it will search for that file in a list of alternate file locations. To support an environment prior to Unified CM 4.1(3)SR3, the centralized TFTP server must be configured to search through remotely mounted subdirectories associated with the other clusters. Example 3-4 Alternate TFTP FIle Locations A large campus system is deployed using three clusters, and each cluster contains a TFTP server. TFTP1, the TFTP server for Cluster1, is configured as the centralized TFTP server for the campus. The other clusters and TFTP servers are named in sequence as TFTP2 for Cluster2 and TFTP3 for Cluster3. In all subnets, the DHCP scope provides TFTP1s IP address as Option 150. First, TFTP2 and TFTP3 are configured to write their configuration files to TFTP1s drive, each in a different subdirectory, as follows: • TFTP2s alternate file location is set to: TFTP1_IPProgram FilesCiscoTFTPpathTFTP2 • TFTP3s alternate file location is set to: TFTP1_IPProgram FilesCiscoTFTPpathTFTP3 Second, TFTP1 is configured to search in the alternate file locations as follows: • Alternate File Location 1: c:Program FilesCiscoTFTPpathTFTP2 • Alternate File Location 2: c:Program FilesCiscoTFTPpathTFTP3 Note In this example, TFTP1_IP represents the IP address of TFTP1. Also, TFTP1 requires that Windows NT subdirectories be created manually for TFTP2 and TFTP3. Cisco recommends that you use Universal Naming Convention (UNC) paths (in the form at <IP_address><Full_path_to_folder>) to point a TFTP server to alternate file locations. Cisco does not recommend creating non-default NT "shares" or using DNS names. Also, ensure that all clusters meet the proper login ID, password, and security privileges (workgroup, domain, or directory-based) for the Cisco TFTP service. With Cisco Unified CM Release 3.2 and later, Cisco TFTP servers cache the IP phone configuration files in RAM by default. For those files to be written to a centralized TFTP server, you must disable (turn off) file caching by setting the following service parameters as indicated on each TFTP server configured to write to the centralized TFTP server: • Enable Caching of Configuration Files: False (required) • Enable Caching of Constant and Bin Files at Startup: False (recommended) Note Beginning with Cisco Unified CM Release 5.1, the Enable Caching of Configuration Files service parameter is no longer available and configuration files are always cached in memory (rather than written to disk).Network Time Protocol (NTP) NTP allows network devices to synchronize their clocks to a network time server or network-capable clock. NTP is critical for ensuring that all devices in a network have the same time. When troubleshooting or managing a telephony network, it is crucial to synchronize the time stamps within all Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) OL-16394-07 3-27

Chapter 3 Network Infrastructure LAN Infrastructure error and security logs, traces, and system reports on devices throughout the network. This synchronization enables administrators to recreate network activities and behaviors based on a common timeline. Billing records and call detail records (CDRs) also require accurate synchronized time. Unified CM NTP Time Synchronization Time synchronization is especially critical on Unified CM servers. In addition to ensuring that CDR records are accurate and that log files are synchronized, having an accurate time source is necessary for any future IPSec features to be enabled within the cluster and for communications with any external entity. Unified CM 5.0 and later releases automatically synchronize the NTP time of all subscribers in the cluster to the publisher. During installation, each subscriber is automatically configured to point to an NTP server running on the publisher. The publisher considers itself to be a master server and provides time for the cluster based on its internal hardware clock unless it is configured to synchronize from an external server. Cisco highly recommends configuring the publisher to point to a Stratum-1, Stratum-2, or Stratum-3 NTP server to ensure that the cluster time is synchronized with an external time source. With Unified CM 5.0 and later releases, Cisco recommends synchronizing Unified CM with a Cisco IOS or Linux-based NTP server. Using Windows Time Services as an NTP server is not recommended or supported because Windows Time Services often use Simple Network Time Protocol (SNTP), and Linux-based Unified CM cannot successfully synchronize with SNTP. The external NTP server specified for the primary node should be NTP v4 (version 4) to avoid potential compatibility, accuracy, and network jitter problems. External NTP servers must be NTP v4 if IPv6 addressing is used. Note Manual configuration of the NTP.conf file is no longer possible, and any changes made to the file will be automatically replaced by the system configuration. For additional information about NTP time synchronization in a Cisco Unified Communications environment, refer to the Cisco IP Telephony Clock Synchronization: Best Practices white paper, available at http://www.cisco.com/en/US/products/sw/voicesw/ps556/products_white_paper0900aecd8037fdb 5.shtml Cisco IOS and CatOS NTP Time Synchronization Time synchronization is also important for other devices within the network. Cisco IOS routers and Catalyst switches should be configured to synchronize their time with the rest of the network devices via NTP. This is critical for ensuring that debug, syslog, and console log messages are time-stamped appropriately. Troubleshooting telephony network issues is simplified when a clear timeline can be drawn for events that occur on devices throughout the network. Example 3-5 illustrates the configuration of NTP time synchronization on Cisco IOS and CatOS devices. Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x)3-28 OL-16394-07

Chapter 3 Network Infrastructure LAN Infrastructure Example 3-5 Cisco IOS and CatOS NTP Configuration Cisco IOS configuration: ntp server 64.100.21.254 CatOS configuration: set ntp server 64.100.21.254 set ntp client enable To ensure proper NTP time synchronization on routers and switches, it might be necessary to configure time zones using the clock timezone command (in Cisco IOS) and/or the set timezone command (in CatOS).Power over Ethernet (PoE) PoE (or inline power) is 48 Volt DC power provided over standard Ethernet unshielded twisted-pair (UTP) cable. Instead of using wall power, IP phones and other inline powered devices (PDs) such as the Aironet Wireless Access Points can receive power provided by inline power-capable Catalyst Ethernet switches or other inline power source equipment (PSE). Inline power is enabled by default on all inline power-capable Catalyst switches. Deploying inline power-capable switches with uninterrupted power supplies (UPS) ensures that IP phones continue to receive power during power failure situations. Provided the rest of the telephony network is available during these periods of power failure, then IP phones should be able to continue making and receiving calls. You should deploy inline power-capable switches at the campus access layer within wiring closets to provide inline-powered Ethernet ports for IP phones, thus eliminating the need for wall power. Cisco PoE is delivered on the same wire pairs used for data connectivity (pins 1, 2, 3, and 6). If existing access switch ports are not capable of inline power, you can use a power patch panel to inject power into the cabling. (In this case pins 4, 5, 7, and 8 are used.) Additionally, power injectors may be used for specific deployment needs. Caution The use of power injectors or power patch panels can damage some devices because power is always applied to the Ethernet pairs. PoE switch ports automatically detect the presence of a device that requires PoE before enabling it on a port-by-port basis. In addition to Cisco PoE inline power, Cisco now supports the IEEE 802.3af PoE standard. Currently, only some access switches and phones comply with 802.3af. Over time, all phones and switches will support 802.3af PoE. The Catalyst 6500, 4500, and 3750 are currently capable of supporting 802.3af. For information about which Cisco Unified IP Phones support the 802.3af PoE standard, see the Endpoint Features Summary, page 20-47. Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) OL-16394-07 3-29

Chapter 3 Network Infrastructure LAN InfrastructureCategory 3 Cabling The use of Category 3 cabling is supported for IP Communications under the following conditions: • Phones with a PC port and a PC attached to it (Cisco Unified IP Phones 7975, 7971, 7970, 7965, 7962, 7961, 7960, 7945, 7942, 7941, 7940, 7911, and 7910+SW) should be set to 10 Mb, full-duplex. This setting requires hard-coding the upstream switch port, the phone switch and PC ports, and the PC NIC port to 10 Mb, full-duplex. No ports should be set to AUTO negotiate. If desired, you can hard-code the phones PC port to 10 Mb half-duplex, thereby forcing the PCs NIC to negotiate to 10 Mb half-duplex (assuming the PCs NIC is configured to AUTO negotiate). This configuration is acceptable as long as the uplink between the phone and the upstream switch port is set to 10 Mb full-duplex. • Phones with no PC ports and with 10 Mb switch ports (Cisco Unified IP Phones 7902, 7905, and 7910) should be allowed to auto-negotiate to 10 Mb, half-duplex. Because these phones support only 10 Mb Ethernet and their ports cannot be manually configured, the upstream switch port should be set to either AUTO negotiate or 10 Mb, half-duplex. In both cases, these phones will negotiate to 10 Mb, half-duplex. • Phones with a PC port but no PC attached to it (Cisco Unified IP Phones 7975, 7971, 7970, 7965, 7962, 7961, 7960, 7945, 7942, 7941, 7940, 7912, 7911, and 7910+SW) can be allowed to negotiate to 10 Mb, half-duplex. If you leave these phones with the default switch port configuration of AUTO negotiate and configure the upstream switch port to 10 Mb, half-duplex, these phones will revert to 10Mb, half-duplex. Note The Cisco Unified IP Phone 7912 should not be used with Category 3 cable when a PC is attached because the switch and PC ports on this phone cannot be forced to 10 Mb, full duplex.IBM Type 1A and 2A Cabling The use of IBM Cabling System (ICS) or Token Ring shielded twisted-pair type 1A or 2A cabling is supported for IP Communications under the following conditions: • Cable lengths should be 100 meters or less. • Adapters without impedance matching should be used for converting from universal data connector (UDC) to RJ-45 Ethernet standard. Note There are only two twisted pairs in the Token Ring cables. Therefore, inline power for IP phones can be supported, but mid-span power insertion cannot (with Cisco Inline Power and 802.3af) because it requires more than two pairs. Note Gigabit Ethernet is not supported over IBM Cabling Systems because 1000 BASE-T requires four twisted pairs. Where an IBM Cabling System is used in conjunction with the 10/100/1000 BASE-T Ethernet interfaces on Cisco IP Phones, only speeds of 10 Mbps and 100 Mbps are supported. Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) 3-30 OL-16394-07

Chapter 3 Network Infrastructure LAN Infrastructure Running data over the network is not always a sufficient test of the quality of the cable plant because some non-compliance issues might not be apparent. Therefore, customers might want to perform a cable plant survey to verify that their type 1A and 2A cabling installation is compliant with Ethernet standards.LAN Quality of Service (QoS) Until recently, quality of service was not an issue in the enterprise campus due to the asynchronous nature of data traffic and the ability of network devices to tolerate buffer overflow and packet loss. However, with new applications such as voice and video, which are sensitive to packet loss and delay, buffers and not bandwidth are the key QoS issue in the enterprise campus. Figure 3-10 illustrates the typical oversubscription that occurs in LAN infrastructures. Figure 3-10 Data Traffic Oversubscription in the LAN Core Si Si Typical 4:1 Instantaneous Data Over- Interface subscription Congestion Distribution Si Si Typical 20:1 Data Over- subscription Access IP IP IP IP IP IP IP IP IP IP IP IP 114469 Data Voice This oversubscription, coupled with individual traffic volumes and the cumulative effects of multiple independent traffic sources, can result in the egress interface buffers becoming full instantaneously, thus causing additional packets to drop when they attempt to enter the egress buffer. The fact that campus switches use hardware-based buffers, which compared to the interface speed are much smaller than those found on WAN interfaces in routers, merely increases the potential for even short-lived traffic bursts to cause buffer overflow and dropped packets. Applications such as file sharing (both peer-to-peer and server-based), remote networked storage, network-based backup software, and emails with large attachments, can create conditions where network congestion occurs more frequently and/or for longer durations. Some of the negative effects of recent worm attacks have been an overwhelming volume of network traffic (both unicast and broadcast-storm based), increasing network congestion. If no buffer management policy is in place, loss, delay, and jitter performance of the LAN may be affected for all traffic. Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) OL-16394-07 3-31

Chapter 3 Network Infrastructure LAN Infrastructure Another situation to consider is the effect of failures of redundant network elements, which cause topology changes. For example, if a distribution switch fails, all traffic flows will be reestablished through the remaining distribution switch. Prior to the failure, the load balancing design shared the load between two switches, but after the failure all flows are concentrated in a single switch, potentially causing egress buffer conditions that normally would not be present. For applications such as voice, this packet loss and delay results in severe voice quality degradation. Therefore, QoS tools are required to manage these buffers and to minimize packet loss, delay, and delay variation (jitter). The following types of QoS tools are needed from end to end on the network to manage traffic and ensure voice quality: • Traffic classification Classification involves the marking of packets with a specific priority denoting a requirement for class of service (CoS) from the network. The point at which these packet markings are trusted or not trusted is considered the trust boundary. Trust is typically extended to voice devices (phones) and not to data devices (PCs). • Queuing or scheduling Interface queuing or scheduling involves assigning packets to one of several queues based on classification for expedited treatment throughout the network. • Bandwidth provisioning Provisioning involves accurately calculating the required bandwidth for all applications plus element overhead. The following sections discuss the use of these QoS mechanisms in a campus environment: • Traffic Classification, page 3-32 • Interface Queuing, page 3-34 • Bandwidth Provisioning, page 3-34 • Impairments to IP Communications if QoS is Not Employed, page 3-35Traffic Classification It has always been an integral part of the Cisco network design architecture to classify or mark traffic as close to the edge of the network as possible. Traffic classification is an entrance criterion for access into the various queuing schemes used within the campus switches and WAN interfaces. The IP phone marks its voice control signaling and voice RTP streams at the source, and it adheres to the values presented in Table 3-6. As such, the IP phone can and should classify traffic flows. Table 3-6 lists the traffic classification requirements for the LAN infrastructure.Table 3-6 Traffic Classification Guidelines for Various Types of Network Traffic Layer-3 Classification Layer-2 Classification Differentiated ServicesApplication IP Precedence (IPP) Per-Hop Behavior (PHB) Code Point (DSCP) Class of Service (CoS)Routing 6 CS6 48 6Voice Real-Time 5 EF 46 5Transport Protocol(RTP) Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) 3-32 OL-16394-07

Chapter 3 Network Infrastructure LAN InfrastructureTable 3-6 Traffic Classification Guidelines for Various Types of Network Traffic (continued) Layer-3 Classification Layer-2 Classification Differentiated ServicesApplication IP Precedence (IPP) Per-Hop Behavior (PHB) Code Point (DSCP) Class of Service (CoS)Videoconferencing 4 AF41 34 4Streaming video 4 CS4 32 4 1Call signaling 3 CS3 (currently) 24 (currently) 3 AF31 (previously) 26 (previously)Transactional data 2 AF21 18 2Network management 2 CS2 16 2Scavenger 1 CS1 8 1Best effort 0 0 0 01. The recommended DSCP/PHB marking for call control signaling traffic has been changed from 26/AF31 to 24/CS3. A marking migration is planned within Cisco to reflect this change, however many products still mark signaling traffic as 26/AF31. Therefore, in the interim, Cisco recommends that both AF31 and CS3 be reserved for call signaling. For more information about traffic classification, refer to the Enterprise QoS Solution Reference Network Design (SRND), available at http://www.cisco.com/go/designzone Traffic Classification for Video Telephony The main classes of interest for IP Video Telephony are: • Voice Voice is classified as CoS 5 (IP Precedence 5, PHB EF, or DSCP 46). • Videoconferencing Videoconferencing is classified as CoS 4 (IP Precedence 4, PHB AF41, or DSCP 34). • Call signaling Call signaling for voice and videoconferencing is now classified as CoS 3 (IP Precedence 3, PHB CS3, or DSCP 24) but was previously classified as PHB AF31 or DSCP 26. Cisco highly recommends these classifications as best practices in a Cisco Unified Communications network. QoS Marking Differences Between Video Calls and Voice-Only Calls The voice component of a call can be classified in one of two ways, depending on the type of call in progress. A voice-only telephone call would have its media classified as CoS 5 (IP Precedence 5 or PHB EF), while the voice channel of a video conference would have its media classified as CoS 4 (IP Precedence 4 or PHB AF41). All the Cisco IP Video Telephony products adhere to the Cisco Corporate QoS Baseline standard, which requires that the audio and video channels of a video call both be marked as CoS 4 (IP Precedence 4 or PHB AF41). The reasons for this recommendation include, but are not limited to, the following: • To preserve lip-sync between the audio and video channels • To provide separate classes for audio-only calls and video calls Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) OL-16394-07 3-33

Chapter 3 Network Infrastructure LAN Infrastructure The signaling class is applicable to all voice signaling protocols (such as SCCP, MGCP, and so on) as well as video signaling protocols (such as SCCP, H.225, RAS, CAST, and so on). These protocols are discussed in more detail in the section on Software-Based Endpoints, page 20-37. Given the recommended classes, the first step is decide where the packets will be classified (that is, which device will be the first to mark the traffic with its QoS classification). There are essentially two places to mark or classify traffic: • On the originating endpoint — the classification is then trusted by the upstream switches and routers • On the switches and/or routers — because the endpoint is either not capable of classifying its own packets or is not trustworthy to classify them correctly QoS Enforcement Using a Trusted Relay Point (TRP) A Trusted Relay Point (TRP) can be used to enforce and/or re-mark the DSCP values of media flows from endpoints. This feature allows QoS to be enforced for media from endpoints such as softphones, where the media QoS values might have been modified locally. A TRP is a media resource based upon the existing Cisco IOS media termination point (MTP) function. Endpoints can be configured to "Use Trusted Relay Point," which will invoke a TRP for all calls. For QoS enforcement, the TRP uses the configured QoS values for media in Unified CMs Service Parameters to re-mark and enforce the QoS values in media streams from the endpoint. TRP functionality is supported by Cisco IOS MTPs and transcoding resources. (Use Unified CM to check "Enable TRP" on the MTP or transcoding resource to activate TRP functionality.)Interface Queuing After packets have been marked with the appropriate tag at Layer 2 (CoS) and Layer 3 (DSCP or PHB), it is important to configure the network to schedule or queue traffic based on this classification, so as to provide each class of traffic with the service it needs from the network. By enabling QoS on campus switches, you can configure all voice traffic to use separate queues, thus virtually eliminating the possibility of dropped voice packets when an interface buffer fills instantaneously. Although network management tools may show that the campus network is not congested, QoS tools are still required to guarantee voice quality. Network management tools show only the average congestion over a sample time span. While useful, this average does not show the congestion peaks on a campus interface. Transmit interface buffers within a campus tend to congest in small, finite intervals as a result of the bursty nature of network traffic. When this congestion 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. For this reason, Cisco recommends always using a switch that has at least two output queues on each port and the ability to send packets to these queues based on QoS Layer 2 and/or Layer 3 classification. Cisco Catalyst 6000 Series, 4000 Series, 3750, 3500 Series, and 2950 switches all support two or more output queues per port.Bandwidth Provisioning In the campus LAN, bandwidth provisioning recommendations can be summarized by the motto, Over provision and under subscribe. This motto implies careful planning of the LAN infrastructure so that the available bandwidth is always considerably higher than the load and there is no steady-state congestion over the LAN links. Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) 3-34 OL-16394-07

Chapter 3 Network Infrastructure WAN Infrastructure The addition of voice traffic onto a converged network does not represent a significant increase in overall network traffic load; the bandwidth provisioning is still driven by the demands of the data traffic requirements. The design goal is to avoid extensive data traffic congestion on any link that will be traversed by telephony signaling or media flows. Contrasting the bandwidth requirements of a single G.711 voice call (approximately 86 kbps) to the raw bandwidth of a FastEthernet link (100 Mbps) indicates that voice is not a source of traffic that causes network congestion in the LAN, but rather it is a traffic flow to be protected from LAN network congestion.Impairments to IP Communications if QoS is Not Employed If QoS is not deployed, packet drops and excessive delay and jitter can occur, leading to impairments of the telephony services. When media packets are subjected to drops, delay, and jitter, the user-perceivable effects include clicking sound, harsh-sounding voice, extended periods of silence, and echo. When signaling packets are subjected to the same conditions, user-perceivable impairments include unresponsiveness to user input (such as delay to dial tone), continued ringing upon answer, and double dialing of digits due to the users belief that the first attempt was not effective (thus requiring hang-up and redial). More extreme cases can include endpoint re-initialization, call termination, and the spurious activation of SRST functionality at branch offices (leading to interruption of gateway calls). These effects apply to all deployment models. However, single-site (campus) deployments tend to be less likely to experience the conditions caused by sustained link interruptions because the larger quantity of bandwidth typically deployed in LAN environments (minimum links of 100 Mbps) allows for some residual bandwidth to be available for the IP Communications system. In any WAN-based deployment model, traffic congestion is more likely to produce sustained and/or more frequent link interruptions because the available bandwidth is much less than in a LAN (typically less than 2 Mbps), so the link is more easily saturated. The effects of link interruptions can impact the user experience, whether or not the voice media traverses the packet network, because signaling traffic between endpoints and the Unified CM servers can also be delayed or dropped.WAN Infrastructure Proper WAN infrastructure design is also extremely important for normal IP telephony operation on a converged network. Proper infrastructure design requires following basic configuration and design best practices for deploying a WAN that is as highly available as possible and that provides guaranteed throughput. Furthermore, proper WAN infrastructure design requires deploying end-to-end QoS on all WAN links. The following sections discuss these requirements: • WAN Design and Configuration, page 3-36 • WAN Quality of Service (QoS), page 3-39 • Resource Reservation Protocol (RSVP), page 3-46 • Bandwidth Provisioning, page 3-58 Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) OL-16394-07 3-35

Chapter 3 Network Infrastructure WAN InfrastructureWAN Design and Configuration Properly designing a WAN requires building fault-tolerant network links and planning for the possibility that these links might become unavailable. By carefully choosing WAN topologies, provisioning the required bandwidth, and approaching the WAN infrastructure as another layer in the network topology, you can built a fault-tolerant and redundant network. The following sections examine the required infrastructure layers and network services: • Deployment Considerations, page 3-36 • Guaranteed Bandwidth, page 3-37 • Best-Effort Bandwidth, page 3-38Deployment Considerations WAN deployments for voice networks may be hub-and-spoke or an arbitrary topology. A hub-and-spoke topology consists of a central hub site and multiple remote spoke sites connected into the central hub site. In this scenario, each remote or spoke site is one WAN-link hop away from the central or hub site and two WAN-link hops away from all other spoke sites. An arbitrary topology may contain multiple WAN links and any number of hops between the sites. In this scenario there may be many different paths to the same site or there may be different links used for communication with some sites compared to other sites. The simplest example is three sites, each with a WAN link to the other two sites, forming a triangle. In that case there are two potential paths between each site to each other site. Topology-unaware call admission control requires the WAN to be hub-and-spoke, or a spoke-less hub in the case of MPLS VPN. This topology ensures that call admission control, provided by Unified CMs locations or a gatekeeper, works properly in keeping track of the bandwidth available between any two sites in the WAN. In addition, multiple hub-and-spoke deployments can be interconnected via WAN links. Topology-aware call admission control may be used with either hub-and-spoke or an arbitrary WAN topology. This form of call admission control requires parts of the WAN infrastructure to support Resource Reservation Protocol (RSVP). For details, see Resource Reservation Protocol (RSVP), page 3-46, and Call Admission Control, page 9-1. For more information about centralized and distributed multisite deployment models as well as Multiprotocol Label Switching (MPLS) implications for these deployment models, see the chapter on Unified Communications Deployment Models, page 2-1. WAN links should, when possible, be made redundant to provide higher levels of fault tolerance. Redundant WAN links provided by different service providers or located in different physical ingress/egress points within the network can ensure backup bandwidth and connectivity in the event that a single link fails. In non-failure scenarios, these redundant links may be used to provide additional bandwidth and offer load balancing of traffic on a per-flow basis over multiple paths and equipment within the WAN. Topology-unaware call admission control normally requires redundant paths to be over-provisioned and under-subscribed to allow for failures that reduce the available bandwidth between sites without the call admission control mechanism being aware of those failures or the reduction in bandwidth. Topology-aware call admission control is able to adjust dynamically to many of the topology changes and allows for efficient use of the total available bandwidth. Voice and data should remain converged at the WAN, just as they are converged at the LAN. QoS provisioning and queuing mechanisms are typically available in a WAN environment to ensure that voice and data can interoperate on the same WAN links. Attempts to separate and forward voice and data over different links can be problematic in many instances because the failure of one link typically forces Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) 3-36 OL-16394-07

Chapter 3 Network Infrastructure WAN Infrastructure all traffic over a single link, thus diminishing throughput for each type of traffic and in most cases reducing the quality of voice. Furthermore, maintaining separate network links or devices makes troubleshooting and management difficult at best. Because of the potential for WAN links to fail or to become oversubscribed, Cisco recommends deploying non-centralized resources as appropriate at sites on the other side of the WAN. Specifically, media resources, DHCP servers, voice gateways, and call processing applications such as Survivable Remote Site Telephony (SRST) and Cisco Unified Communications Manager Express (Unified CME) should be deployed at non-central sites when and if appropriate, depending on the site size and how critical these functions are to that site. Keep in mind that de-centralizing voice applications and devices can increase the complexity of network deployments, the complexity of managing these resources throughout the enterprise, and the overall cost of a the network solution; however, these factors can be mitigated by the fact that the resources will be available during a WAN link failure. When deploying voice in a WAN environment, Cisco recommends that you use the lower-bandwidth G.729 codec for any voice calls that will traverse WAN links because this practice will provide bandwidth savings on these lower-speed links. Furthermore, media resources such as MoH should be configured to use multicast transport mechanism when possible because this practice will provide additional bandwidth savings. Where calls are made over best-effort networks with no QoS guarantees for voice, consider using Internet Low Bit Rate Codec (iLBC), which enables graceful speech quality degradation and good error resilience characteristics in networks where frames can get lost. See Table 3-9 for details of bandwidth consumption based on codec type and sample size. Finally, recommendation G.114 of the International Telecommunication Union (ITU) states that the one-way delay in a voice network should be less than or equal to 150 milliseconds. It is important to keep this in mind when implementing low-speed WAN links within a network. Topologies, technologies, and physical distance should be considered for WAN links so that one-way delay is kept at or below this 150-millisecond recommendation. For deployments that use clustering over the WAN, the maximum one-way delay between any two Unified CM 6.0 servers should not exceed 20 msec, or 40 msec round-trip time (RTT). Beginning with Cisco Unified CM Release 6.1, the maximum one-way delay between two Unified CM servers can be up to 40 msec, or 80 msec round-trip time. (For more infomation, see Clustering Over the IP WAN, page 2-21.).Guaranteed Bandwidth Because voice is typically deemed a critical network application, it is imperative that bearer and signaling voice traffic always reaches its destination. For this reason, it is important to choose a WAN topology and link type that can provide guaranteed dedicated bandwidth. The following WAN link technologies can provide guaranteed dedicated bandwidth: • Leased Lines • Frame Relay • Asynchronous Transfer Mode (ATM) • ATM/Frame-Relay Service Interworking • Multiprotocol Label Switching (MPLS) • Cisco Voice and Video Enabled IP Security VPN (IPSec V3PN) These link technologies, when deployed in a dedicated fashion or when deployed in a private network, can provide guaranteed traffic throughput. All of these WAN link technologies can be provisioned at specific speeds or bandwidth sizes. In addition, these link technologies have built-in mechanisms that help guarantee throughput of network traffic even at low link speeds. Features such as traffic shaping, Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) OL-16394-07 3-37

Chapter 3 Network Infrastructure WAN Infrastructure fragmentation and packet interleaving, and committed information rates (CIR) can help ensure that packets are not dropped in the WAN, that all packets are given access at regular intervals to the WAN link, and that enough bandwidth is available for all network traffic attempting to traverse these links.Dynamic Multipoint VPN (DMVPN) Spoke-to-spoke DMVPN networks can provide benefits for Cisco Unified Communications compared with hub-and-spoke topologies. Spoke-to-spoke tunnels can provide a reduction in end-to-end latency by reducing the number of WAN hops and decryption/encryption stages. In addition, DMVPN offers a simplified means of configuring the equivalent of a full mesh of point-to-point tunnels without the associated administrative and operational overhead. The use of spoke-to-spoke tunnels also reduces traffic at the hub, thus providing bandwidth and router processing capacity savings. Spoke-to-spoke DMVPN networks, however, are sensitive to the delay variation (jitter) caused during the transition of RTP packets routing from the spoke-hub-spoke path to the spoke-to-spoke path. This variation in delay during the DMVPN path transition occurs very early in the call and is generally unnoticeable, although a single momentary audio distortion might be heard if the latency difference is above 100 ms. For information on the deployment of multisite DMVPN WANs with centralized call processing, refer to the Cisco Unified Communications Voice over Spoke-to-Spoke DMVPN Test Results and Recommendations, available at http://www.cisco.com/go/designzone.Best-Effort Bandwidth There are some WAN topologies that are unable to provide guaranteed dedicated bandwidth to ensure that network traffic will reach its destination, even when that traffic is critical. These topologies are extremely problematic for voice traffic, not only because they provide no mechanisms to provision guaranteed network throughput, but also because they provide no traffic shaping, packet fragmentation and interleaving, queuing mechanisms, or end-to-end QoS to ensure that critical traffic such as voice will be given preferential treatment. The following WAN network topologies and link types are examples of this kind of best-effort bandwidth technology: • The Internet • DSL • Cable • Satellite • Wireless In most cases, none of these link types can provide the guaranteed network connectivity and bandwidth required for critical voice and voice applications. However, these technologies might be suitable for personal or telecommuter-type network deployments. At times, these topologies can provide highly available network connectivity and adequate network throughput; but at other times, these topologies can become unavailable for extended periods of time, can be throttled to speeds that render network throughput unacceptable for real-time applications such as voice, or can cause extensive packet losses and require repeated retransmissions. In other words, these links and topologies are unable to provide guaranteed bandwidth, and when traffic is sent on these links, it is sent best-effort with no guarantee that it will reach its destination. For this reason, Cisco recommends that you do not use best-effort WAN topologies for voice-enabled networks that require enterprise-class voice services and quality. Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) 3-38 OL-16394-07

Chapter 3 Network Infrastructure WAN Infrastructure Note There are some new QoS mechanisms for DSL and cable technologies that can provide guaranteed bandwidth; however, these mechanisms are not typically deployed by service providers, and these services are still significantly oversubscribed.WAN Quality of Service (QoS) Before placing voice and video traffic on a network, it is important to ensure that there is adequate bandwidth for all required applications. Once this bandwidth has been provisioned, voice priority queuing must be performed on all interfaces. This queuing is required to reduce jitter and possible packet loss if a burst of traffic oversubscribes a buffer. This queuing requirement is similar to the one for the LAN infrastructure. Next, the WAN typically requires additional mechanisms such as traffic shaping to ensure that WAN links are not sent more traffic than they can handle, which could cause dropped packets. Finally, link efficiency techniques can be applied to WAN paths. For example, link fragmentation and interleaving (LFI) can be used to prevent small voice packets from being queued behind large data packets, which could lead to unacceptable delays on low-speed links. The goal of these QoS mechanisms is to ensure reliable, high-quality voice by reducing delay, packet loss, and jitter for the voice traffic. Table 3-7 lists the QoS features and tools required for the WAN infrastructure to achieve this goal.Table 3-7 QoS Features and Tools Required to Support IP Telephony for each WAN Technology and Link SpeedWAN Technology Link Speed: 56 kbps to 768 kbps Link Speed: Greater than 768 kbpsLeased Lines • Multilink Point-to-Point Protocol (MLP) • LLQ • MLP Link Fragmentation and Interleaving (LFI) • Low Latency Queuing (LLQ) • Optional: Compressed Real-Time Transport Protocol (cRTP)Frame Relay (FR) • Traffic Shaping • Traffic Shaping • LFI (FRF.12) • LLQ • LLQ • Optional: VATS • Optional: cRTP • Optional: Voice-Adaptive Traffic Shaping (VATS) • Optional: Voice-Adaptive Fragmentation (VAF)Asynchronous Transfer • TX-ring buffer changes • TX-ring buffer changesMode (ATM) • MLP over ATM • LLQ • MLP LFI • LLQ • Optional: cRTP (requires MLP) Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) OL-16394-07 3-39

Chapter 3 Network Infrastructure WAN InfrastructureTable 3-7 QoS Features and Tools Required to Support IP Telephony for each WAN Technology and Link SpeedWAN Technology Link Speed: 56 kbps to 768 kbps Link Speed: Greater than 768 kbpsFrame Relay and ATM • TX-ring buffer changes • TX-ring buffer changesService Inter-Working • MLP over ATM and FR • MLP over ATM and FR(SIW) • MLP LFI • LLQ • LLQ • Optional: cRTP (requires MLP)Multiprotocol Label • Same as above, according to the interface technology • Same as above, according to theSwitching (MPLS) interface technology • Class-based marking is generally required to remark flows according to service provider specifications • Class-based marking is generally required to remark flows according to service provider specifications The following sections highlight some of the most important features and techniques to consider when designing a WAN to support both voice and data traffic: • Traffic Prioritization, page 3-40 • Link Efficiency Techniques, page 3-42 • Traffic Shaping, page 3-43Traffic Prioritization In choosing from among the many available prioritization schemes, the major factors to consider include the type of traffic involved and the type of media on the WAN. For multi-service traffic over an IP WAN, Cisco recommends low-latency queuing (LLQ) for all links. This method supports up to 64 traffic classes, with the ability to specify, for example, priority queuing behavior for voice and interactive video, minimum bandwidth class-based weighted fair queuing for voice control traffic, additional minimum bandwidth weighted fair queues for mission critical data, and a default best-effort queue for all other traffic types. Figure 3-11 shows an example prioritization scheme. Figure 3-11 Optimized Queuing for VoIP over the WAN Layer 3 queuing subsystem Layer 2 queuing subsystem Packets in Low latency queuing Link fragmentation and interleave 1 1 1 1 PQ Voice Police 2 2 PQ Voice Packets out TX 3 3 Class = X Interleave 0 4 3 2 1 1 ring 4 4 4 Class = Y CBWFQ Fragment Packets out 0 0 0 0 WFQ Default 77295 Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) 3-40 OL-16394-07

Chapter 3 Network Infrastructure WAN Infrastructure Cisco recommends the following prioritization criteria for LLQ: • The criterion for voice to be placed into a priority queue is the differentiated services code point (DSCP) value of 46, or a per-hop behavior (PHB) value of EF. • The criterion for video conferencing traffic to be placed into a priority queue is a DSCP value of 34, or a PHB value of AF41. However, due to the larger packet sizes of video traffic, these packets should be placed in the priority queue only on WAN links that are faster than 768 Kbps. Link speeds below this value require packet fragmentation, but packets placed in the priority queue are not fragmented, thus smaller voice packets could be queued behind larger video packets. For links speeds of 768 Kbps or lower, video conferencing traffic should be placed in a separate class-based weighted fair queue (CBWFQ). Note One-way video traffic, such as the traffic generated by streaming video applications for services such as video-on-demand or live video feeds, should always use a CBWFQ scheme because that type of traffic has a much higher delay tolerance than two-way video conferencing traffic • As the WAN links become congested, it is possible to starve the voice control signaling protocols, thereby eliminating the ability of the IP phones to complete calls across the IP WAN. Therefore, voice control protocols, such as H.323, MGCP, and Skinny Client Control Protocol (SCCP), require their own class-based weighted fair queue. The entrance criterion for this queue is a DSCP value of 24 or a PHB value of CS3. Note Cisco has begun to change the marking of voice control protocols from DSCP 26 (PHB AF31) to DSCP 24 (PHB CS3). However many products still mark signaling traffic as DSCP 26 (PHB AF31); therefore, in the interim, Cisco recommends that you reserve both AF31 and CS3 for call signaling. • In some cases, certain data traffic might require better than best-effort treatment. This traffic is referred to as mission-critical data, and it is placed into one or more queues that have the required amount of bandwidth. The queuing scheme within this class is first-in-first-out (FIFO) with a minimum allocated bandwidth. Traffic in this class that exceeds the configured bandwidth limit is placed in the default queue. The entrance criterion for this queue could be a Transmission Control Protocol (TCP) port number, a Layer 3 address, or a DSCP/PHB value. • All remaining traffic can be placed in a default queue for best-effort treatment. If you specify the keyword fair, the queuing algorithm will be weighted fair queuing (WFQ). Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x)OL-16394-07 3-41

Chapter 3 Network Infrastructure WAN InfrastructureLink Efficiency Techniques The following link efficiency techniques improve the quality and efficiency of low-speed WAN links. Compressed Real-Time Transport Protocol (cRTP) You can increase link efficiency by using Compressed Real-Time Transport Protocol (cRTP). This protocol compresses a 40-byte IP, User Datagram Protocol (UDP), and RTP header into approximately two to four bytes. cRTP operates on a per-hop basis. Use cRTP on a particular link only if that link meets all of the following conditions: • Voice traffic represents more than 33% of the load on the specific link. • The link uses a low bit-rate codec (such as G.729). • No other real-time application (such as video conferencing) is using the same link. If the link fails to meet any one of the preceding conditions, then cRTP is not effective and you should not use it on that link. Another important parameter to consider before using cRTP is router CPU utilization, which is adversely affected by compression and decompression operations. cRTP on ATM and Frame Relay Service Inter-Working (SIW) links requires the use of Multilink Point-to-Point Protocol (MLP). Note that cRTP compression occurs as the final step before a packet leaves the egress interface; that is, after LLQ class-based queueing has occurred. Beginning in Cisco IOS Release 12.(2)2T and later, cRTP provides a feedback mechanism to the LLQ class-based queueing mechanism that allows the bandwidth in the voice class to be configured based on the compressed packet value. With Cisco IOS releases prior to 12.(2)2T, this mechanism is not in place, so the LLQ is unaware of the compressed bandwidth and, therefore, the voice class bandwidth has to be provisioned as if no compression is taking place. Table 3-8 shows an example of the difference in voice class bandwidth configuration given a 512-kbps link with G.729 codec and a requirement for 10 calls. Note that Table 3-8 assumes 24 kbps for non-cRTP G.729 calls and 10 kbps for cRTP G.729 calls. These bandwidth numbers are based on voice payload and IP/UDP/RTP headers only. They do not take into consideration Layer 2 header bandwidth. However, actual bandwidth provisioning should also include Layer 2 header bandwidth based on the type WAN link used. Table 3-8 LLQ Voice Class Bandwidth Requirements for 10 Calls with 512 kbps Link Bandwidth and G.729 Codec Cisco IOS Release With cRTP Not Configured With cRTP Configured Prior to 12.2(2)T 240 kbps 240 kbps1 12.2(2)T or later 240 kbps 100 kbps 1. 140 kbps of unnecessary bandwidth must be configured in the LLQ voice class. It should also be noted that, beginning in Cisco IOS Release 12.2(13)T, cRTP can be configured as part of the voice class with the Class-Based cRTP feature. This option allows cRTP to be specified within a class, attached to an interface via a service policy. This new feature provides compression statistics and bandwidth status via the show policy interface command, which can be very helpful in determining the offered rate on an interface service policy class given the fact that cRTP is compressing the IP/RTP headers. For additional recommendations about using cRTP with a Voice and Video Enabled IPSec VPN (V3PN), refer to the V3PN documentation available at http://www.cisco.com/go/designzone Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) 3-42 OL-16394-07

Chapter 3 Network Infrastructure WAN Infrastructure Link Fragmentation and Interleaving (LFI) For low-speed links (less than 768 kbps), use of link fragmentation and interleaving (LFI) mechanisms is required for acceptable voice quality. This technique limits jitter by preventing voice traffic from being delayed behind large data frames, as illustrated in Figure 3-12. The two techniques that exist for this purpose are Multilink Point-to-Point Protocol (MLP) LFI (for Leased Lines, ATM, and SIW) and FRF.12 for Frame Relay. Figure 3-12 Link Fragmentation and Interleaving (LFI) Before Voice Data 214-ms serialization delay for 1500-byte frame at 56 kbps After 77296 Data Data Voice Data Voice-Adaptive Fragmentation (VAF) In addition to the LFI mechanisms mentioned above, voice-adaptive fragmentation (VAF) is another LFI mechanism for Frame Relay links. VAF uses FRF.12 Frame Relay LFI; however, once configured, fragmentation occurs only when traffic is present in the LLQ priority queue or when H.323 signaling packets are detected on the interface. This method ensures that, when voice traffic is being sent on the WAN interface, large packets are fragmented and interleaved. However, when voice traffic is not present on the WAN link, traffic is forwarded across the link unfragmented, thus reducing the overhead required for fragmentation. VAF is typically used in combination with voice-adaptive traffic shaping (see Voice-Adaptive Traffic Shaping (VATS), page 3-45). VAF is an optional LFI tool, and you should exercise care when enabling it because there is a slight delay between the time when voice activity is detected and the time when the LFI mechanism engages. In addition, a configurable deactivation timer (default of 30 seconds) must expire after the last voice packet is detected and before VAF is deactivated, so during that time LFI will occur unnecessarily. VAF is available in Cisco IOS Release 12.2(15)T and later.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 and several branch sites are typically aggregated to a single router interface at the central site. Figure 3-13 illustrates the main reasons why traffic shaping is needed when transporting voice and data on the same IP WAN. Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) OL-16394-07 3-43

Chapter 3 Network Infrastructure WAN Infrastructure Figure 3-13 Traffic Shaping with Frame Relay and ATM Central Site Traffic Shaping: Why? 1 Line speed mismatch 1. 2. Remote to central site over- 2 subscription 3 To prevent bursting above 3. Committed Rate (CIR T1 Frame Relay or ATM CIR = 64 kbps 64kbps T1 T1 T1 1 2 3 77297 Remote Sites Figure 3-13 shows three different scenarios: 1. Line speed mismatch While the central-site interface is typically a high-speed one (such as T1 or higher), smaller remote branch interfaces may have significantly lower line speeds, such as 64 kbps. If data is sent at full rate from the central site to a slow-speed remote site, the interface at the remote site might become congested and degrade voice performance. 2. Oversubscription of the link between the central site and the remote sites It is common practice in Frame Relay or ATM networks to oversubscribe bandwidth when aggregating many remote sites to a single central site. For example, there may be multiple remote sites that connect to the WAN with a T1 interface, yet the central site has only a single T1 interface. While this configuration allows the deployment to benefit from statistical multiplexing, the router interface at the central site can become congested during traffic bursts, thus degrading voice quality. 3. Bursting above Committed Information Rate (CIR) Another common configuration is to allow traffic bursts above the CIR, which represents the rate that the service provider has guaranteed to transport across its network with no loss and low delay. For example, a remote site with a T1 interface might have a CIR of only 64 kbps. When more than Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x)3-44 OL-16394-07

Chapter 3 Network Infrastructure WAN Infrastructure 64 kbps worth of traffic is sent across the WAN, the provider marks the additional traffic as "discard eligible." If congestion occurs in the provider network, this traffic will be dropped with no regard to traffic classification, possibly having a negative affect on voice quality. Traffic shaping provides a solution to these issues by limiting the traffic sent out an interface to a rate lower than the line rate, thus ensuring that no congestion occurs on either end of the WAN. Figure 3-14 illustrates this mechanism with a generic example, where R is the rate with traffic shaping applied. Figure 3-14 Traffic Shaping Mechanism without Traffic Shaping Line Rate with Traffic Shaping R 77298 Voice-Adaptive Traffic Shaping (VATS) VATS is an optional dynamic mechanism that shapes traffic on Frame Relay permanent virtual circuits (PVCs) at different rates based on whether voice is being sent across the WAN. The presence of traffic in the LLQ voice priority queue or the detection of H.323 signaling on the link causes VATS to engage. Typically, Frame Relay shapes traffic to the guaranteed bandwidth or CIR of the PVC at all times. However, because these PVCs are typically allowed to burst above the CIR (up to line speed), traffic shaping keeps traffic from using the additional bandwidth that might be present in the WAN. With VATS enabled on Frame Relay PVCs, WAN interfaces are able to send at CIR when voice traffic is present on the link. However, when voice is not present, non-voice traffic is able to burst up to line speed and take advantage of the additional bandwidth that might be present in the WAN. When VATS is used in combination with voice-adaptive fragmentation (VAF) (see Link Fragmentation and Interleaving (LFI), page 3-43), all non-voice traffic is fragmented and all traffic is shaped to the CIR of the WAN link when voice activity is detected on the interface. As with VAF, exercise care when enabling VATS because activation can have an adverse effect on non-voice traffic. When voice is present on the link, data applications will experience decreased throughput because they are throttled back to well below CIR. This behavior will likely result in packet drops and delays for non-voice traffic. Furthermore, after voice traffic is no longer detected, the deactivation timer (default of 30 seconds) must expire before traffic can burst back to line speed. It is important, when using VATS, to set end-user expectations and make them aware that data applications will experience slowdowns on a regular basis due to the presence of voice calls across the WAN. VATS is available in Cisco IOS Release 12.2(15)T and later. For more information on the Voice-Adaptive Traffic Shaping and Fragmentation features and how to configure them, refer to the documentation at http://www.cisco.com/en/US/docs/ios/12_2t/12_2t15/feature/guide/ft_vats.html Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x)OL-16394-07 3-45

Chapter 3 Network Infrastructure WAN InfrastructureResource Reservation Protocol (RSVP) The Resource Reservation Protocol (RSVP) is the first significant industry-standard protocol for dynamically setting up end-to-end QoS across a heterogeneous network. RSVP, which runs over IP, was first introduced by the IETF in RFC 2205, and it enables an application to reserve network bandwidth dynamically. Using RSVP, applications can request a certain level of QoS for a data flow across a network. Because of its distributed and dynamic nature, RSVP is capable of reserving bandwidth across any network topology, therefore it can be used to provide topology-aware call admission control for voice and video calls. This section focuses on the RSVP protocol principles and its interactions with the WAN infrastructure, specifically the QoS aspects, while the motivation and the mechanisms for call admission control based on RSVP are described in the chapter on Call Admission Control, page 9-1. This section covers the following specific topics: • RSVP Principles, page 3-46 • RSVP in MPLS Networks, page 3-49 • RSVP and QoS in WAN Routers, page 3-52 • RSVP Application ID, page 3-56 • RSVP Design Best Practices, page 3-58RSVP Principles RSVP performs resource reservations for a given data flow across a network. RSVP reservations are unidirectional. Therefore, for a single audio call that contains two RTP streams, two RSVP reservations are generated, one for each RTP stream. The resource reservation is created by exchanging signaling messages between the source and destination devices for the data flow, and the messages are processed by intermediate routers along the path. The RSVP signaling messages are IP packets with the protocol number in the IP header set to 46, and they are routed through the network according to the existing routing protocols. Not all routers on the path are required to support RSVP because the protocol is designed to operate transparently across RSVP-unaware nodes. On each RSVP-enabled router, the RSVP process intercepts the signaling messages and interacts with the QoS manager for the routers outbound interface involved in the data flow in order to "reserve" bandwidth resources. When the available resources are not sufficient for the data flow anywhere along the path, the routers signal the failure back to the application that originated the reservation request. The principles of RSVP signaling can be explained by using the example shown in Figure 3-15. In this diagram, an application wishes to reserve network resources for a data stream flowing from Device 1, whose IP address is 10.10.10.10, to Device 2, whose IP address is 10.60.60.60. Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) 3-46 OL-16394-07

Chapter 3 Network Infrastructure WAN InfrastructureFigure 3-15 Example of RSVP Path and Resv Message Flow RSVP RSVP-aware RSVP-aware RSVP-unaware RSVP-aware RSVP Sender Router Router Router Router Receiver 10.10.10.10 10.20.20.20 10.30.30.30 10.40.40.40 10.50.50.50 10.60.60.60 OK OK OK P Hop = P Hop = P Hop = P Hop =Device 10.10.10.10 10.20.20.20 10.30.30.30 10.50.50.50 Device 1 2 PATH Dest: 10.60.60.60 P Hop: 10.10.10.10 PATH Dest: 10.60.60.60 P Hop: 10.20.20.20 PATH PATH Dest: 10.60.60.60 Dest: 10.60.60.60 P Hop: 10.30.30.30 P Hop: 10.30.30.30 PATH Dest: 10.60.60.60 P Hop: 10.50.50.50 RESV Dest: 10.50.50.50 RESV RESV N Hop: 10.60.60.60 Dest: 10.30.30.30 Dest: 10.30.30.30 RESV N Hop: 10.50.50.50 N Hop: 10.50.50.50 Dest: 10.20.20.20 RESV N Hop: 10.30.30.30 Dest: 10.10.10.10 N Hop: 10.20.20.20 141853 Legend: = RSVP processing occurs OK = Bandwidth reserved on interface The following steps describe the RSVP signaling process for as single data flow, as shown by the example in Figure 3-15: 1. The application residing on Device 1 originates an RSVP message called Path, which is sent to the same destination IP address as the data flow for which a reservation is requested (that is, 10.60.60.60) and is sent with the "router alert" option turned on in the IP header. The Path message contains, among other things, the following objects: – The "session" object, consisting of destination IP address, protocol number, and UDP/TCP port, which is used to identify the data flow in RSVP-enabled routers. – The "sender T-Spec" (traffic specification) object, which characterizes the data flow for which a reservation will be requested. The T-Spec basically defines the maximum IP bandwidth required for a call flow using a specific codec. The T-Spec is typically defined using values for the data flows average bit rate, peak rate, and burst size. Details of the T-Spec are discussed later in this chapter. – The "P Hop" (or previous hop) object, which contains the IP address of the router interface that last processed the Path message. In this example, the P Hop is initially set to 10.10.10.10 by Device 1. 2. By means of the "router alert" option, the Path message is intercepted by the CPU of the RSVP-aware router identified as 10.20.20.20 in Figure 3-15, which sends it to the RSVP process. RSVP creates a path state for this data flow, storing the values of the session, sender Tspec, and P Hop objects contained in the Path message. Then it forwards the message downstream, after having replaced the P Hop value with the IP address of its outgoing interface (10.20.20.20 in this example). Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) OL-16394-07 3-47

Chapter 3 Network Infrastructure WAN Infrastructure 3. Similarly, the Path message is intercepted by the CPU of the following RSVP-aware router, identified as 10.30.30.30 in Figure 3-15. After creating the path state and changing the P Hop value to 10.30.30.30, this router also forwards the message downstream. 4. The Path message now arrives at the RSVP-unaware router identified as 10.40.40.40 in Figure 3-15. Because RSVP is not enabled on this router, it just routes this message according to the existing routing protocols like any other IP packet, without any additional processing and without changing the content of any of the message objects. 5. Therefore, the Path message gets to the RSVP-aware router identified as 10.50.50.50, which processes the message, creates the corresponding path state, and forwards the message downstream. Notice that the P Hop recorded by this router still contains the IP address of the last RSVP-aware router along the network path, or 10.30.30.30 in this example. 6. The RSVP Receiver at Device 2 receives the Path message with a P Hop value of 10.50.50.50, and it can now initiate the actual reservation by originating a message called Resv. For this reason, RSVP is known as a receiver-initiated protocol. The Resv message carries the reservation request hop-by-hop from the receiver to the sender, along the reverse paths of the data flow for the session. At each hop, the IP destination address of the Resv message is the IP address of the previous-hop node, obtained from the path state. Hence, in this case Device 2 sends the Resv message with a destination IP address of 10.50.50.50. The Resv message contains, among other things, the following objects: – The "session" object, which is used to identify the data flow. – The "N Hop" (or next hop) object, which contains the IP address of the node that generated the message. In this example, the N Hop is initially set to 10.60.60.60 by Device 2. 7. When RSVP-aware router 10.50.50.50 receives the Resv message for this data flow, it matches it against the path state information using the received session object, and it verifies if the reservation request can be accepted based on the following criteria: – Policy control — Is this user and/or application allowed to make this reservation request? – Admission control — Are there enough bandwidth resources available on the relevant outgoing interface to accommodate this reservation request? 8. In this case, we assume that both policy and admission control are successful on 10.50.50.50, which means that the bandwidth provided by the Tspec in the path state for this session is reserved on the outgoing interface (in the same direction as the data flow, that is from Device 1 to Device 2), and a corresponding "reservation state" is created. Now router 10.50.50.50 can send a Resv message upstream by sending it as a unicast IP packet to the destination IP address stored in the P Hop for this session, which was 10.30.30.30. The N Hop object is also updated with the value of 10.50.50.50. 9. The Resv message now transits through the RSVP-unaware router identified as 10.40.40.40, which will route it toward its destination of 10.30.30.30 like any other IP packet. This mechanism allows RSVP signaling to work across a heterogeneous network where some nodes are not RSVP-enabled. 10. The RSVP-aware router identified as 10.30.30.30 receives the Resv message and processes it according to the mechanisms described in steps 7 and 8. Assuming policy and admission control are successful also at this hop, the bandwidth is reserved on the outgoing interface and a Resv message is sent to the previous hop, or 10.20.20.20 in this example. 11. After a similar process within the router identified as 10.20.20.20, the Resv finally reaches the RSVP sender, Device 1. This indicates to the requesting application that an end-to-end reservation has been established and that bandwidth has been set aside for this data flow in all RSVP-enabled routers across the network. This example shows how the two main RSVP signaling messages, Path and Resv, travel across the network to establish reservations. Several other messages are defined in the RSVP standard to address error situations, reservation failures, and release of resources. In particular, the ResvErr message is used Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x)3-48 OL-16394-07

Chapter 3 Network Infrastructure WAN Infrastructure to signal failure to reserve the requested resources due to either policy control or admission control somewhere along the network. If, for example, admission control had failed at node 10.50.50.50 in Figure 3-15, this node would have sent a ResvErr message back to Device 2, specifying the cause of the failure, and the application would have been notified. Another important aspect of the RSVP protocol is that it adopts a soft-state approach, which means that for each session both the path state and the reservation state along the network need to be refreshed periodically by the application by sending identical Path and Resv messages. If a router does not receive refresh messages for a given session for a certain period of time, it deletes the corresponding state and releases the resources reserved. This allows RSVP to react dynamically to network topology changes or routing changes due to link failures. The reservations simply start flowing along the new routes based on the routing protocol decisions, and the reservations along the old routes time-out and are eventually deleted.RSVP in MPLS Networks In some MPLS service-provider networks, the IP addresses used on the links between the customer edge (CE) and the provider edge (PE) are not distributed to the rest of the MPLS network, thus ensuring that the subnets stay local to the PE and are not advertised beyond the PE (because they are not unique and are being reused elsewhere). This creates a situation where RSVP is not able to forward RSVP messages because the P Hop (Previous Hop) value of the RSVP message is unknown in the network. Figure 3-16 illustrates this type of situation. Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) OL-16394-07 3-49

Chapter 3 Network Infrastructure WAN InfrastructureFigure 3-16 RSVP Over MPLS Without P Hop Overwrite These P addresses are not advertised beyond PE 1 Enterprise Service Provider Enterprise CE 1 PE 1 PE 1 CE 2 A1 (RSVP-Aware) (RSVP-Aware) (RSVP-Aware) (RSVP-Aware) A210.10.10.10 10.10.10.1 171.71.32.1 171.71.32.2 10.20.20.20 171.70.48.5 10.20.20.1 MPLS P Hop = 171.70.48.6 P Hop = P Hop = 10.10.10.10 171.70.48.5 10.20.20.1 PATH Dest: 10.20.20.20 P Hop: 10.10.10.10 PATH PATH Dest: 10.20.20.20 Dest: 10.20.20.20 P Hop: 171.70.48.5 P Hop: 171.70.48.5 PATH Dest: 10.20.20.20 P Hop: 10.20.20.1 RESV RESV Dest: 10.20.20.1 RESV Dest: 171.70.48.5 PE 2 does not know how to reach 271567 the 171.70.48.x subnet! = RSVP enabled on interface Figure 3-16 shows an enterprise network and a service provider MPLS network. CE1 and CE2 are RSVP-aware, and PE1 and PE2 are RSVP-unaware. The RSVP Path message contains a P Hop object. This object is rewritten at every RSVP hop. Its purpose is to enable an RSVP router (for example, CE1) to send a Path message to the next RSVP router (for example, CE2) to indicate that it (CE1) is the previous RSVP hop (or P Hop). This information is used by CE2 to forward the corresponding Resv message upstream hop-by-hop toward the sender. In Cisco IOS, the RSVP Router always sets the P Hop address to the IP address of the egress interface onto which it transmits the Path message. There are situations where, although some IP addresses of CE1 are reachable, the IP address of its egress interface is not reachable from a remote RSVP Router CE2. The result is that the corresponding Resv message generated by CE2 never reaches CE1, thus the reservation is never established. When a call is made from A1 to A2, A1 tries to set up an RSVP session and starts by sending a Path message to CE1. A1 will populate the P Hop object in the Path message of its outgoing interface IP (in this case, 10.10.10.10). CE1 will then receive the Path message, process it, create the corresponding path state, update the P Hop field of the message with its egress interface IP address (171.70.48.5), which is not a routable IP address, and forward the Path message downstream. This Path message will be tunneled across the service provider network and will be processed by CE2. Upon reception of the Path message, CE2 records the IP address of the P Hop object (CE1s egress interface IP address) and forwards the Path message downstream to A1. A1 will record and process the Path message and initiate an RSVP message Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) 3-50 OL-16394-07

Chapter 3 Network Infrastructure WAN Infrastructure to CE2. CE2 will process the RSVP message and send its own RSVP message upstream to CE1. However, when CE2 replies with this Resv message, it will try to send it to the IP address that it had recorded earlier from the Path message received from CE1. Since this IP address (171.70.48.5) is not routable from CE2, the Resv message will fail, thus causing the reservation attempt to fail. To resolve this behavio, r a feature called Previous Hop Overwrite has been introduced in Cisco IOS Release 12.4.(20)T. P Hop Overwrite is a mechanism whereby the CE populates the Hop object in the Path message with an IP address from another interface on the router that is reachable in the customer VPN. In this way, the Resv message can find its way back toward the sender and reservations can be established. The P Hop Overwrite mechanism is illustrated in Figure 3-17.Figure 3-17 RSVP P Hop Overwrite Feature in Cisco IOS 12.4(20)T New IOS CLI instructs RSVP to use loopback address 10.10.10.11 as PHOP address on this interface Enterprise Service Provider Enterprise CE 1 PE 1 PE 1 CE 2 A1 (RSVP-Aware) (RSVP-Aware) (RSVP-Aware) (RSVP-Aware) A210.10.10.10 10.10.10.1 171.70.48.5 171.71.32.1 171.71.32.2 10.20.20.20 10.20.20.1 MPLS P Hop = 171.70.48.6 P Hop = P Hop = 10.10.10.10 171.70.48.5 10.20.20.1 PATH Dest: 10.20.20.20 P Hop: 10.10.10.10 PATH PATH Dest: 10.20.20.20 Dest: 10.20.20.20 P Hop: 10.10.10.11 P Hop: 10.10.10.11 PATH Dest: 10.20.20.20 P Hop: 10.20.20.1 RESV RESV RESV Dest: 10.20.20.1 Dest: 10.10.10.11 Dest: 10.10.10.11 RESV Dest: 10.10.10.10 271568 = RSVP enabled on interfaceDescribing Data Flow Characteristics in RSVP (TSpec) RSVP was designed to support requesting Quality of Service (QoS) for any traffic flow, not just voice or video, across a wide range of Layer 2 technologies. To accomplish this, RSVP must be able to describe in detail the traffic flow for which it is requesting QoS, so that the intermediate routers can make admittance decisions correctly. Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) OL-16394-07 3-51

Chapter 3 Network Infrastructure WAN Infrastructure The bandwidth requirements for data flows for an RSVP session are characterized by senders in the TSpec (traffic specification) contained in Path messages and are mirrored in the RSpec (reservation specification) sent by receivers in Resv messages. The TSpec gets transported through the network to all intermediary routers and to the destination endpoint. The intermediate routers do not change this object, and the object gets delivered unchanged to the ultimate receiver(s). The TSpec object contains the following elements: • AverageBitRate (kbps) • BurstSize (bytes) • PeakRate (kbps) Audio TSpec For audio flows, the TSpec calculations specify the following measurements: • AverageBitRate (kbps) — Including IP overhead • BurstSize (bytes) — This value is calculated as the size of the packet times the number of packets in a burst. For audio flows, the burst usually specifies 1 to 2. • PeakRate (bytes) — The peak rate, in bytes, refers to the maximum bytes per second that the endpoint transmits at any given time. If the burst is small, as is the case in audio streams, the peak rate can be calculated as 1.1 (or 1.2) times the tokenRate. To avoid adjusting the bandwidth reservation upward when the call gets answered, Cisco Unified CM reserves the maximum bandwidth for each region codec at call setup time. Unified CM then modifies or adjusts the bandwidth based on the media capability of the connected parties when the call gets answered. For more information on RSVP for Unified Communications, refer to the Cisco Unified Communications Manager System Guide, availabel at http://www.cisco.com/en/US/products/sw/voicesw/ps556/prod_maintenance_guides_list.html Note This section focuses on providing an overview of RSVP principles and mechanisms. For more information on protocol behavior and extensions, complete message formats, and interactions with other protocols, refer to the numerous RFC documents related to RSVP, available at http://www.ietf.org.RSVP and QoS in WAN Routers RSVP has been supported in Cisco routers for many years, however most configurations recommended in this document are based on the RSVP Scalability Enhancements feature, which was first introduced in Cisco IOS Release 12.2(2)T. By issuing the following Cisco IOS command in interface configuration mode on each Cisco IOS router interface, you can enable RSVP and define the maximum amount of bandwidth that it can control: ip rsvp bandwidth [interface-kbps] [single-flow-kbps] The interface-kbps parameter specifies the upper limit of bandwidth that RSVP can reserve on the given interface, while the single-flow-kbps parameter provides an upper bandwidth limit for each individual reservation (so that flows with higher bandwidth requests will be rejected even if there is bandwidth available on the interface). Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) 3-52 OL-16394-07

Chapter 3 Network Infrastructure WAN Infrastructure Note When RSVP is enabled on a router interface, all other interfaces in the router will drop RSVP messages unless they are also enabled for RSVP. To avoid dropping RSVP messages, enable RSVP on all interfaces through which you expect RSVP signaling to transit. If call admission control is not desired on an interface, set the bandwidth value to 75% of the interface bandwidth. Within Cisco IOS, RSVP can be configured to operate according to two different models: the Integrated Services (IntServ) model, described in RFC 2210, or the Integrated Services/Differentiated Services (IntServ/DiffServ) model, described in RFC 2998. Both RFC documents are available on the IETF website at http://www.ietf.org Figure 3-18 shows the difference between these two approaches from the perspective of a Cisco IOS router.Figure 3-18 The Two RSVP Operation Models: IntServ and IntServ/DiffServ IntServ Model IntServ/DiffServ Model No No R SRSVP signaling ? Yes RSVP signaling ? Yes V P Call Admission Control Call Admission Control Control Plane R Control Plane S Data Plane V Data Plane P L L Data Data Q 126674 Scheduling + Policing Scheduling + PolicingThe IntServ Model As shown on the left side of Figure 3-18, RSVP in the IntServ model involves both the control plane and the data plane. In the control plane, RSVP admits or denies the reservation request. In the data plane, it classifies the data packets, polices them based on the traffic description contained in the RSVP messages, and queues them in the appropriate queue. The classification that RSVP performs is based on the 5-tuple consisting of the source IP address, source port, destination IP address, destination port, and protocol number. In this model, all data packets transiting through the router must be intercepted by RSVP so that RSVP can inspect the 5-tuple and look for a match among the established reservations. If a match is found, the packets are scheduled and policed by RSVP according to the reservations traffic specification. Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) OL-16394-07 3-53

Chapter 3 Network Infrastructure WAN Infrastructure As shown in Figure 3-19, when you combine the IntServ model with Low Latency Queuing (LLQ), the usable bandwidth is divided between RSVP and the predefined LLQ queues. RSVP controls the entrance criteria to the RSVP reserved bandwidth, while policy maps control the entrance criteria for the predefined queues. Figure 3-19 Combining the IntServ Model with LLQ 100% RSVP flows admitted or Reserved RSVP flows assigned to priority queue based on rejected based on actual conformance to ‘ip rsvp bandwidth left available pq-profile’ Priority 75% for RSVP flows Bandwidth bandwidth Total Link Bandwidth Available ‘ip rsvp bandwidth’ should be set to total bandwidth jp rsvp Priority "Usable" Bandwidth (75%) available to RSVP 50% Priority Assigned to LLQ Classes Packets assigned to LLQ classes/queues based on class maps (typically, Bandwidth DSCP) 25% Bandwidth reserved for LLQ/ CBWFQ classes based on 141854 policy maps and service policy 0% To use the IntServ operation model on a Cisco IOS router, use the following commands in interface configuration mode: ip rsvp resource-provider wfq [interface | pvc] no ip rsvp data-packet classification When these commands are active, RSVP admits or rejects new reservations, not only based on the upper bandwidth limit defined within the ip rsvp bandwidth command, but also based on the actual bandwidth resources available. For example, if there are LLQ classes with bandwidth statements, these amounts are deducted from the bandwidth pool that can be assigned to RSVP reservations. While LLQ classes statically allocate bandwidth at configuration time, RSVP does not allocate any amount until a reservation request is received. Therefore, it is important to ensure that an appropriate percentage of the available interface bandwidth is not allocated to LLQ classes, so that it can be used by RSVP as reservation requests are received. Because the total maximum bandwidth that can be assigned to QoS mechanisms on a link is equal to 75% of the link speed, if you want to reserve 33% of the link bandwidth for RSVP-admitted flows, you have to make sure that the bandwidth assigned to LLQ classes does not exceed (75 - 33) = 42% of the link bandwidth. Because RSVP is in control of assigning packets to the various queues within this model, it is possible to define a mechanism for RSVP to know whether or not to place flows in the Priority Queue (PQ) based on the data flows T-Spec values by using the following Cisco IOS command in interface configuration mode: ip rsvp pq-profile [r [b [p-to-r]]] Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x)3-54 OL-16394-07

Chapter 3 Network Infrastructure WAN Infrastructure Cisco IOS RSVP uses the RSVP TSpec parameters r, b, and p-to-r to determine if the flow being signaled for is a voice flow that needs PQ treatment. These parameters represent the following values: • r = the average traffic rate in bytes per second • b = the maximum burst of a flow in bytes • p-to-r = the ratio of peak rate to average rate, expressed as a percentage If the traffic characteristics specified by the RSVP TSpec messages for a certain flow are less than or equal to the parameters in the Cisco IOS command, then RSVP will direct the flow into the PQ. If no parameters are provided with the command, the following values, representing the largest of the commonly used voice codecs (G.711), are used as default: • r = 12288 bytes per second • b = 592 bytes • p-to-r = 110%The IntServ/DiffServ Model As shown on the right side of Figure 3-18, RSVP in the IntServ/DiffServ model involves only the control plane performing admission control but does not involve the data plane. This means that the call admission control function is separate from the scheduling and policing functions, which can be performed by the Low Latency Queuing (LLQ) algorithm according to predefined class maps, policy maps, and service policies. With the IntServ/DiffServ model, it is therefore possible to add RSVP call admission control to a network that is already using a Differentiated Services approach to QoS. RSVP admits or rejects calls based on a preconfigured bandwidth amount, but the actual scheduling is based on the pre-existing LLQ criteria such as the DSCP value of each packet. The entire usable bandwidth (75% of the link speed) can be assigned to LLQ classes, as shown in Figure 3-20, as it normally is today. The policy maps define the traffic that is admitted into each queue. RSVP is typically configured to admit flows up to the amount of bandwidth defined for priority traffic, but keep in mind that RSVP in this model does not adjust the scheduling, so any traffic admitted by RSVP in excess of the predefined priority queue may be dropped or remapped to other lower-priority queues. If all applications that send priority traffic are RSVP-enabled, you may configure the RSVP bandwidth to match the size of the priority queue. If, on the other hand, there are non-RSVP applications that also need to send priority traffic (such as Unified CM static locations or a gatekeeper), as shown in Figure 3-20, the priority queue is divided into priority traffic that is controlled by non-RSVP mechanisms and priority traffic that is controlled by RSVP. The combined non-RSVP and RSVP admission control mechanisms must not use more bandwidth than is allocated to ensure that the priority queue is never over-subscribed. Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) OL-16394-07 3-55

Chapter 3 Network Infrastructure WAN Infrastructure Figure 3-20 LLQ Bandwidth Allocation with RSVP RSVP flows assigned to priority queue based on 100% LLQ classes(typically, Reserved DSCP) RSVP flows admitted or rejected based on ip rsvp bandwidth only 75% bandwidth RSVP jp rsvp Total Link Bandwidth Priority "Usable" Bandwidth (75%) Assigned to LLQ Classes If there are non-RSVP non real-time applications, provision priority 50% Bandwidth queue accordingly Packets assigned to LLQ classes/queues based on class maps (typically, 25% DSCP) Bandwidth reserved for LLQ/ CBWFQ classes based on 141855 policy maps and service policy 0% To use the IntServ/DiffServ operation model on a Cisco IOS router, use the following commands in interface configuration mode: ip rsvp resource-provider none ip rsvp data-packet classification none When these commands are active, RSVP admits or rejects new reservations uniquely based on the upper bandwidth limits defined within the ip rsvp bandwidth command, independently from the actual bandwidth resources available on the interface. Once admitted, the RSVP flows are subject to the same scheduling rules as all other non-RSVP traffic (for example, LLQ class and policy maps). Therefore, it is important to ensure that the RSVP-enabled traffic is marked with the appropriate DSCP value and that the bandwidth of the corresponding PQ or CBWFQ queues is provisioned to accommodate both RSVP-enabled traffic and all other traffic. In this operating model, the ip rsvp pq-profile command is inactive because RSVP does not control the scheduling function.RSVP Application ID An application identity (app-id) is an RSVP object that can be inserted into the policy element of an RSVP message. This object is described in RFC 2872. This policy object helps to identify the application and associate it with the RSVP reservation request, thus allowing routers along the path to make appropriate decisions based on the application information. The need for an app-id arises because RSVP is used to support multiple applications such as voice and video. Without using an app-id, there is only one bandwidth value that is configurable per interface in RSVP. RSVP will admit requests until this bandwidth limit is reached. It does not differentiate between the requests and is not aware of the type of application for which the bandwidth is requested. As a result of Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) 3-56 OL-16394-07

Chapter 3 Network Infrastructure WAN Infrastructure this, it is quite possible for RSVP to exhaust the allowed bandwidth by admitting requests representing just one type of application, thus causing all subsequent requests to be rejected due to unavailable bandwidth. In this way, a few video calls could prevent all or most of the voice calls from being admitted. For example, if an organization allocates 1000 units to RSVP, RSVP might exhaust a majority of this amount by admitting two 384-kbps video calls, thus leaving very little bandwidth for voice calls. The solution to this problem is to configure separate bandwidth limits for individual applications or classes of traffic. Limiting bandwidth per application requires that an RSVP local policy matching the application bandwidth limit be applied to the router interface and that each reservation request flag the application to which it belongs so that it may be admitted against the appropriate bandwidth limit. The app-id is not a single piece of information but multiple variable-length strings. As is described in RFC 2872, the object may include the following attributes: • An identifier of the application (APP). This attribute is required. • Global unique identifier (GUID). Optional. • Version number of the application (VER). This attribute is required. • Sub-application identifier (SAPP). An arbitrary number of sub-application elements can be included. Optional. For example: • APP = AudioStream • GUID = CiscoSystems • VER = 5.0.1.0 • SAPP = (not specified)How Unified CM Uses the Application ID To support RSVP Application ID functionality, Unified CM has two cluster-wide service parameters that define the Application ID used to tag audio and video call reservations using RSVP: • RSVP Audio Application ID (Default is "AudioStream") • RSVP Video Application ID (Default is "VideoStream") It is possible to change these service parameters, but Cisco recommend that you leave them at their default values. Leaving the Applications IDs at their default values allows multiple clusters to share reservations across the same link. Using different Application IDs per cluster enables you to differentiate one clusters reservations from another clusters reservations over the same link. How Voice Calls are Tagged When a voice call is made between locations with an RSVP policy, the resulting reservations for the audio stream will be tagged with the RSVP Audio Application ID. How Video Calls are Tagged When a video call is made between locations with an RSVP policy, the resulting reservations for the audio stream will be tagged with the RSVP Audio Application ID and the reservations for the video stream will be tagged with the RSVP Video Application ID.Application ID Call Admission Control Model As mentioned in the chapter on Call Admission Control, page 9-1, the call admission control model supported by Application ID differs from the one supported by "static" locations. Because the audio stream of a video call is marked with the RSVP Audio Application ID, it is possible to guarantee a Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) OL-16394-07 3-57

Chapter 3 Network Infrastructure WAN Infrastructure minimum number of voice calls and allow them to take over the entire available bandwidth reserved for the audio streams of voice and video calls. In other words, video calls are allowed up to a certain maximum bandwidth, based on the configured bandwidth for the Video Application ID (for video streams) and the configured available bandwidth for the Audio Application ID (for the audio streams of voice calls and video calls). If the entire Audio Application ID bandwidth is consumed by voice calls that were established first, then video calls will be denied.RSVP Design Best Practices When deploying RSVP in the IP WAN in conjunction with Unified CM, observe the following design best practices: • Cisco recommends that you use the IntServ/DiffServ model if either of the following statements is true: – The only traffic destined for the Priority Queue (PQ) in the IP WAN interfaces is RSVP-enabled traffic. – All the non-RSVP traffic destined for the PQ can be deterministically limited to a certain amount by an out-of-band call admission control mechanism (such as Unified CM locations or a Cisco IOS gatekeeper). • If all the PQ traffic is RSVP-enabled, the value specified in the ip rsvp bandwidth command and the priority command should match once Layer 2 overhead of the priority queue bandwidth has been taken into account. • If RSVP is enabled on one or more interfaces of a router, all interfaces through which you expect RSVP signaling to transit should also be enabled for RSVP to ensure that RSVP messages do not get dropped. If call admission control is not desired on an interface, set the bandwidth value to 75% of the interface bandwidth. • If some PQ traffic is not RSVP-enabled, you must ensure that the sum of the values specified in the ip rsvp bandwidth command and in the out-of-band call admission control mechanism do not exceed the bandwidth value specified in the priority command. • Enable RSVP Application ID support if you need to limit the maximum amount of bandwidth used by video calls. Application ID Support is introduced in Cisco IOS Release 12.4(6)T. For more information, see RSVP Application ID, page 3-56. • Enable RSVP at the edge of the network, including the router WAN interfaces on both sides of the WAN link. • Enable RSVP at all possible WAN congestion points, including redundant links of different speeds. • Ensure symmetric routing on load-balanced MPLS WAN links. • RSVP is currently not available on Bundle Interfaces, including MLPPP, ATM-IMA, and FRF.16. • RSVP is currently not available on Tunnel Interfaces. • RSVP is currently not available on most Catalyst Switching Platforms.Bandwidth Provisioning Properly provisioning the network bandwidth is a major component of designing a successful IP network. You can calculate the required bandwidth by adding the bandwidth requirements for each major application (for example, voice, video, and data). This sum then represents the minimum bandwidth Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) 3-58 OL-16394-07

Chapter 3 Network Infrastructure WAN Infrastructure requirement for any given link, and it should not exceed approximately 75% of the total available bandwidth for the link. This 75% rule assumes that some bandwidth is required for overhead traffic, such as routing and Layer 2 keep-alives. Figure 3-21 illustrates this bandwidth provisioning process.Figure 3-21 Link Bandwidth Provisioning Voice Video Voice/Video Data Routing Control etc. 0.75 x link capacity Reserved Link capacity 77291 In addition to using no more than 75% of the total available bandwidth for data, voice, and video, the total bandwidth configured for all LLQ priority queues should typically not exceed 33% of the total link bandwidth. Provisioning more than 33% of the available bandwidth for the priority queue can be problematic for a number of reasons. First, provisioning more than 33% of the bandwidth for voice can result in increased CPU usage. Because each voice call will send 50 packets per second (with 20 ms samples), provisioning for large numbers of calls in the priority queue can lead to high CPU levels due to high packet rates. In addition, if more than one type of traffic is provisioned in the priority queue (for example, voice and video), this configuration defeats the purpose of enabling QoS because the priority queue essentially becomes a first-in, first-out (FIFO) queue. A larger percentage of reserved priority bandwidth effectively dampens the QoS effects by making more of the link bandwidth FIFO. Finally, allocating more than 33% of the available bandwidth can effectively starve any data queues that are provisioned. Obviously, for very slow links (less than 192 kbps), the recommendation to provision no more than 33% of the link bandwidth for the priority queue(s) might be unrealistic because a single call could require more than 33% of the link bandwidth. In these situations, and in situations where specific business needs cannot be met while holding to this recommendation, it may be necessary to exceed the 33% rule. From a traffic standpoint, an IP telephony call consists of two parts: • The voice and video bearer streams, which consists of Real-Time Transport Protocol (RTP) packets that contain the actual voice samples. • The call control signaling, which consists of packets belonging to one of several protocols, according to the endpoints involved in the call (for example, H.323, MGCP, SCCP, or (J)TAPI). Call control functions are, for instance, those used to set up, maintain, tear down, or redirect a call. Bandwidth provisioning should include not only the bearer traffic but also the call control traffic. In fact, in multisite WAN deployments, the call control traffic (as well as the bearer traffic) must traverse the WAN, and failure to allocate sufficient bandwidth for it can adversely affect the user experience. Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) OL-16394-07 3-59

Chapter 3 Network Infrastructure WAN Infrastructure The next three sub-sections describe the bandwidth provisioning recommendations for the following types of traffic: • Voice and video bearer traffic in all multisite WAN deployments (see Provisioning for Bearer Traffic, page 3-60) • Call control traffic in multisite WAN deployments with centralized call processing (see Provisioning for Call Control Traffic with Centralized Call Processing, page 3-67) • Call control traffic in multisite WAN deployments with distributed call processing (see Provisioning for Call Control Traffic with Distributed Call Processing, page 3-72)Provisioning for Bearer Traffic The section describes bandwidth provisioning for the following types of traffic: • Voice Bearer Traffic, page 3-60 • Video Bearer Traffic, page 3-63Voice Bearer Traffic As illustrated in Figure 3-22, a voice-over-IP (VoIP) packet consists of the voice payload, IP header, User Datagram Protocol (UDP) header, Real-Time Transport Protocol (RTP) header, and Layer 2 Link header. When Secure Real-Time Transport Protocol (SRTP) encryption is used, the voice payload for each packet is increased by 4 bytes. The link header varies in size according to the Layer 2 media used. Figure 3-22 Typical VoIP Packet VoIP Packet Voice RTP UDP IP Link 77292 payload Header Header Header Header X bytes 12 bytes 8 bytes 20 bytes X bytes The bandwidth consumed by VoIP streams is calculated by adding the packet payload and all headers (in bits), then multiplying by the packet rate per second, as follows: Layer 2 bandwidth in kbps = [(Packets per second) ∗ (X bytes for voice payload + 40 bytes for RTP/UDP/IP headers + Y bytes for Layer 2 overhead) ∗ 8 bits] / 1000 Layer 3 bandwidth in kbps = [(Packets per second) ∗ (X bytes for voice payload + 40 bytes for RTP/UDP/IP headers) ∗ 8 bits] / 1000 Packets per second = [1/(sampling rate in msec)] ∗ 1000 Voice payload in bytes = [(codec bit rate in kbps) ∗ (sampling rate in msec)] / 8 Table 3-9 details the Layer 3 bandwidth per VoIP flow. Table 3-9 lists the bandwidth consumed by the voice payload and IP header only, at a default packet rate of 50 packets per second (pps) and at a rate of 33.3 pps for both non-encrypted and encrypted payloads. Table 3-9 does not include Layer 2 header overhead and does not take into account any possible compression schemes, such as compressed Real-Time Transport Protocol (cRTP). You can use the Service Parameters menu in Unified CM Administration to adjust the codec sampling rate. Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) 3-60 OL-16394-07

Chapter 3 Network Infrastructure WAN Infrastructure Table 3-9 Bandwidth Consumption for Voice Payload and IP Header Only Voice Payload Packets per Bandwidth per CODEC Sampling Rate in Bytes Second Conversation G.711 and G.722-64k 20 ms 160 50.0 80.0 kbps G.711 and G.722-64k (SRTP) 20 ms 164 50.0 81.6 kbps G.711 and G.722-64k 30 ms 240 33.3 74.7 kbps G.711 and G.722-64k (SRTP) 30 ms 244 33.3 75.8 kbps iLBC 20 ms 38 50.0 31.2 kbps iLBC (SRTP) 20 ms 42 50.0 32.8 kbps iLBC 30 ms 50 33.3 24.0 kbps iLBC (SRTP) 30 ms 54 33.3 25.1 kbps G.729A 20 ms 20 50.0 24.0 kbps G.729A (SRTP) 20 ms 24 50.0 25.6 kbps G.729A 30 ms 30 33.3 18.7 kbps G.729A (SRTP) 30 ms 34 33.3 19.8 kbps A more accurate method for provisioning is to include the Layer 2 headers in the bandwidth calculations. Table 3-10 lists the amount of bandwidth consumed by voice traffic when the Layer 2 headers are included in the calculations.Table 3-10 Bandwidth Consumption with Layer 2 Headers Included Header Type and Size ATM 53-Byte Cells Ethernet PPP with a 48-Byte Frame Relay MLPPP MPLS WLANCODEC 14 Bytes 6 Bytes Payload 4 Bytes 10 Bytes 4 Bytes 24 BytesG.711 and G.722-64k 85.6 kbps 82.4 kbps 106.0 kbps 81.6 kbps 84.0 kbps 81.6 kbps 89.6 kbpsat 50.0 ppsG.711 and G.722-64k 87.2 kbps 84.0 kbps 106.0 kbps 83.2 kbps 85.6 kbps 83.2 kbps N/A(SRTP) at 50.0 ppsG.711 and G.722-64k 78.4 kbps 76.3 kbps 84.8 kbps 75.7 kbps 77.3 kbps 75.7 kbps 81.1 kbpsat 33.3 ppsG.711 and G.722-64k 79.5 kbps 77.4 kbps 84.8 kbps 76.8 kbps 78.4 kbps 76.8 kbps N/A(SRTP) at 33.3 ppsiLBC at 50.0 pps 36.8 kbps 33.6 kbps 42.4 kbps 32.8 kbps 35.2 kbps 32.8 kbps 40.8 kbpsiLBC (SRTP) at 38.4 kbps 35.2 kbps 42.4 kbps 34.4 kbps 36.8 kbps 34.4 kbps 42.4 kbps50.0 ppsiLBC at 33.3 pps 27.7 kbps 25.6 kbps 28.3 kbps 25.0 kbps 26.6 kbps 25.0 kbps 30.4 kbpsiLBC (SRTP) at 28.8 kbps 26.6 kbps 42.4 kbps 26.1 kbps 27.7 kbps 26.1 kbps 31.5 kbps33.3 ppsG.729A at 50.0 pps 29.6 kbps 26.4 kbps 42.4 kbps 25.6 kbps 28.0 kbps 25.6 kbps 33.6 kbps Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) OL-16394-07 3-61

Chapter 3 Network Infrastructure WAN InfrastructureTable 3-10 Bandwidth Consumption with Layer 2 Headers Included (continued) Header Type and Size ATM 53-Byte Cells Ethernet PPP with a 48-Byte Frame Relay MLPPP MPLS WLANCODEC 14 Bytes 6 Bytes Payload 4 Bytes 10 Bytes 4 Bytes 24 BytesG.729A (SRTP) at 31.2 kbps 28.0 kbps 42.4 kbps 27.2 kbps 29.6 kbps 27.2 kbps 35.2 kbps50.0 ppsG.729A at 33.3 pps 22.4 kbps 20.3 kbps 28.3 kbps 19.7 kbps 21.3 kbps 19.8 kbps 25.1 kbpsG729A (SRTP) at 23.5 kbps 21.4 kbps 28.3 kbps 20.8 kbps 22.4 kbps 20.8 kbps 26.2 kbps33.3 pps While it is possible to configure the sampling rate above 30 ms, doing so usually results in very poor voice quality. As illustrated in Figure 3-23, as sampling size increases, the number of packets per second decreases, resulting in a smaller impact to the CPU of the device. Likewise, as the sample size increases, IP header overhead is lower because the payload per packet is larger. However, as sample size increases, so does packetization delay, resulting in higher end-to-end delay for voice traffic. The trade-off between packetization delay and packets per second must be considered when configuring sample size. While this trade-off is optimized at 20 ms, 30 ms sample sizes still provide a reasonable ratio of delay to packets per second; however, with 40 ms sample sizes, the packetization delay becomes too high. Figure 3-23 Voice Sample Size: Packets per Second vs. Packetization Delay Trade off 50 120 45 100 40 35 Packetization Delay (ms) 80 Packets per second 30 25 60 20 40 15 10 20 5 0 0 10 ms 20 ms 30 ms 40 ms Sample Size 114470 Packetization Delay Packets per second Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) 3-62 OL-16394-07

Chapter 3 Network Infrastructure WAN InfrastructureVideo Bearer Traffic For audio, it is relatively easy to calculate a percentage of overhead per packet given the sample size of each packet. For video, however, it is nearly impossible to calculate an exact percentage of overhead because the payload varies depending upon how much motion is present in the video (that is, how many pixels changed since the last frame). To resolve this inability to calculate the exact overhead ratio for video, Cisco recommends that you add 20% to the call speed regardless of which type of Layer-2 medium the packets are traversing. The additional 20% gives plenty of headroom to allow for the differences between Ethernet, ATM, Frame Relay, PPP, HDLC, and other transport protocols, as well as some cushion for the bursty nature of video traffic. (See Table 3-11.) Table 3-11 Recommended Bandwidth for Various Video Call Speeds Call Speed Requested by Endpoint Actual Layer-2 Bandwidth Required 128 kbps 153.6 kbps 256 kbps 307.2 kbps 384 kbps 460.8 kbps 512 kbps 614.4 kbps 768 kbps 921.6 kbps 1.5 Mbps 1.766 Mbps 2.048 Mbps 2.458 Mbps 7 Mbps 8.4 Mbps Note that the values in Table 3-11 represent the maximum burst speed of the call, with some additional amount for a cushion. The average speed of the call is typically much less than these values. The concepts of media channels and bandwidth usage are critical to understanding what values to use when configuring call admission control.Calculating RSVP Bandwidth Values for Use with Unified CM At the time Unified CM instructs the Cisco RSVP Agent to make the initial reservation for the call flow, the endpoints that are involved in the call have not fully exchanged their codec capabilities. Without this information, Unified CM must rely on the region settings to determine how to describe the traffic flow. The size of the traffic flow is a function of two things, the codec bit-rate and the sampling rate (or packets per second). The region settings contain the maximum codec bit rate but do not describe the sampling rate. The preferred sampling rates for audio codecs are defined in the following cluster-wide service parameters: • Preferred G722 millisecond packet size: 20 ms by default • Preferred G711 millisecond packet size: 20 ms by default • Preferred G729 millisecond packet size: 20 ms by default However, the codec type and codec sampling rate are negotiated for every call and might not be the preferred settings because they are not supported on one or more of the endpoints. To avoid having to increase the reservation size once the capabilities are fully exchanged, possibly causing a post-ring failure, this initial reservation is for the worst-case scenario (the largest codec bit rate using the smallest packet size) for that codec. Once media capabilities have been exchanged between the endpoints, then the reservation is revised to the correct bandwidth allocation. In most cases, the default sampling rate is used, resulting in the reservation being reduced. Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) OL-16394-07 3-63

Chapter 3 Network Infrastructure WAN Infrastructure Note Unified CM does not include the SRTP overhead or the Layer 2 overhead in the RSVP Reservation. When compared to the RSVP T Spec bandwidth value, the Layer 3 IP RSVP bandwidth statement must take into account any SRTP traffic, and the Layer 2 priority queue value must also be over-provisioned if SRTP traffic is present. (See Table 3-10 and Table 3-11.) Voice Bearer Traffic Inter-region call with audio codec maximum set to G729, connecting using G.729: • Initial request: 40 kbps using a 10 ms worst-case scenario • Updated request: 24 kbps using the preferred sample size of 20 ms Inter-region call with audio codec maximum set to G.728/iLBC, connecting using iLBC: • Initial request: 48 kbps using a G.728 10 ms worst-case scenario • Updated request: 31.2 kbps using iLBC with a preferred sample size of 20 ms Inter-region call with audio codec set to G711, connecting using G.711: • Initial request: 96 kbps using a 10 ms worst-case scenario • Updated request: 80 kbps using the preferred sample size of 20 ms Video Bearer Traffic As with the audio stream, the initial reservation for the video stream will rely on the region settings because the endpoint codec capabilities will not be fully negotiated at the time of the reservation. The region settings for video calls include the bandwidth for the audio stream. (See IP Video Telephony, page 16-1, for more information.) Because the audio stream has its own reservation, the final reservation for the video stream will be the region setting minus the audio codec bit-rate. However, because these codecs have not been fully negotiated, the video stream reservation will be for the worst-case scenario, which assumes no audio stream. Once media capabilities have been exchanged between the endpoints, then the reservation will be revised to the correct bandwidth allocation. Because video is inherently bursty, it is necessary to add some overhead to the stream requirements. (See Video Bearer Traffic, page 3-63, for more information.) Unified CM uses the stream bandwidth to determine how to calculate the overhead, as follows: • If the stream is < 256 kbps, then the overhead will be 20% • If the stream is >= 256 kbps, then the overhead will be 7% Inter-region video call, with G.729 audio codec and video setting of 384 kbps: • Initial request: 384 ∗ 1.07 = 410 kbps • Updated request: (384 - 8) ∗ 1.07 = 402 kbps Inter-region video call, with G.711 audio codec and video setting of 384 kbps: • Initial request: 384 ∗ 1.07 = 410 kbps • Updated request: (384 - 64) ∗ 1.07 = 342 kbps Configuration Recommendation Because the initial reservation will be larger than the actual packet flow, over-provisioning the RSVP and LLQ bandwidth is required to ensure that the desired number of calls can complete. When provisioning the RSVP bandwidth value for N calls, Cisco recommends that the Nth value be the worst-case bandwidth to ensure that the Nth call gets admitted. Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x)3-64 OL-16394-07

Chapter 3 Network Infrastructure WAN Infrastructure For example: • To provision four G.729 streams: (3 ∗ 24) + 40 = 112 kbps • To provision four G.711 streams: (3 ∗ 80) + 96 = 336 kbps • To provision four 384 kbps video streams (G.729 audio) (3 ∗ (384 - 8) + 384) ∗ 1.07 = 1618 kbps • To provision four 384 kbps video streams (G.711 audio) (3 ∗ (384 - 64) + 384) ∗ 1.07 = 1438 kbpsConfiguring Cisco IOS Application ID Support RSVP Application ID feature support was introduced in Cisco IOS Release 12.4(6)T, and that is the minimum release required for the following examples. Combined Priority Queue To utilize the functionality allowed in Unified CM’s implementation of Application ID support (that is, allowing voice calls to consume all the bandwidth available in the priority queue), we must modify the previous recommendations that voice and video priority queues be kept separate. (See Application ID Call Admission Control Model, page 3-57.) To use this functionality, you should combine both the voice and video match criteria into one class-map. Because the requirements are to match either voice traffic or video traffic, be sure to make the class-map match criteria match-any instead of match-all, as follows: class-map match-any IPC-RTP match ip dscp ef match ip dscp af41 af42 Configure the priority queue to support both the voice and video traffic. The following example configuration allocates 33% of the link bandwidth to the priority queue: policy-map Voice-Policy class IPC-RTP priority percent 33 Mapping Application ID to RSVP Policy Identities The RSVP Local Policy provides the mechanism for controlling a reservation based on an Application ID. Application IDs are mapped to RSVP Local Policies through the ip rsvp policy identity command. RSVP Local Policy identities are defined globally and are available to each interface for policy enforcement. Each identity can have one policy locator defined to match an Application ID. To give the user as much flexibility as possible in matching application policy locators to local policies, the RSVP local policy command line interface (CLI) accepts application ID match criteria in the form of Unix-style regular expressions for the policy locator. Regular expressions are already used in the CLI for existing Cisco IOS components such as Border Gateway Protocol (BGP). Refer to the follow documentation for more information on how regular expressions are used in Cisco IOS: • Access and Communication Servers Command Reference http://www.cisco.com/en/US/docs/ios/11_0/access/command/reference/arbook.html Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) OL-16394-07 3-65

Chapter 3 Network Infrastructure WAN Infrastructure • Using Regular Expressions in BGP http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080094a92.shtml • Regex Engine Performance Enhancement http://www.cisco.com/en/US/docs/ios/12_3t/12_3t4/feature/guide/gt_rexpe.html RSVP Policy Identities for Matching the Default Unified CM Application IDs ip rsvp policy identity rsvp-video policy-locator .*VideoStream.* ip rsvp policy identity rsvp-voice policy-locator .*AudioStream.* Interface RSVP Local Policies Whether configuring Application ID support or not, for an interface to support RSVP, you must configure the ip rsvp bandwidth <value> command on that interface. This value cannot be exceeded by any one RSVP reservation or the sum of RSVP reservations on that interface, regardless of Application ID support. In fact, if a reservation passes the local policy check, it still must pass the interface RSVP bandwidth check before it is reserved. Local policies based on Application ID are applied to an interface using the ip rsvp policy local identity command. For reservations that match its policy locator value, a local policy has the ability to perform the following functions: • Define the maximum amount of bandwidth the reservations can reserve as a group or as a single sender • Forward or not forward RSVP messages • Accept or not accept RSVP messages • Define the maximum bandwidth the group or sender can reserve For example, to limit the amount of video bandwidth to 384 kbps on a Serial T1, use the following commands: interface Serial0/0/1:0 ip rsvp bandwidth 506 ip rsvp policy local identity rsvp-video maximum bandwidth group 384 forward all There is also a catch-all local policy called the default local policy. This local policy will match any RSVP reservation that did not match the other RSVP local policies configured on the link. The default local policy can be used to match reservations that are not tagged with an Application ID or reservations that are tagged with an Application ID that you want to treat as untagged traffic. Example The following example supports both voice and video calls using the model discussed in How Unified CM Uses the Application ID, page 3-57. The voice calls are guaranteed 352 kbps of bandwidth while video calls are limited to 154 kbps of bandwidth. Voice calls can use all of the available RSVP bandwidth. interface Serial0/0/1:0 ip address 10.2.101.5 255.255.255.252 service-policy output Voice-Policy ip rsvp bandwidth 506 ip rsvp data-packet classification none ip rsvp resource-provider none ip rsvp policy local identity rsvp-voice Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x)3-66 OL-16394-07

Chapter 3 Network Infrastructure WAN Infrastructure maximum bandwidth group 506 forward all ip rsvp policy local identity rsvp-video maximum bandwidth group 154 forward all ip rsvp policy local default no accept all ! Will not show in the configuration no forward all! Will not show in the configuration In this example, if an RSVP reservation is received that does not have an Application ID or its Application ID does not match the two configured options, the reservation will fail. This configuration works if RSVP traffic originates only from Cisco RSVP Agents controlled by Unified CM. However, if there is intercluster RSVP traffic via an IP-IP gateway or if RSVP messages from a controller other than Unified CM are traversing this link, then the default local policy should be configured to accept and forward the reservations and a maximum bandwidth value should be configured on the policy. Note that it is possible to oversubscribe the RSVP bandwidth via the use of multiple RSVP local policies (if the sum of the policies is greater than the RSVP interface bandwidth), but reservations then become first-come, first-serve.Provisioning for Call Control Traffic with Centralized Call Processing In a centralized call processing deployment, the Unified CM cluster and the applications (such as voicemail) are located at the central site, while several remote sites are connected through an IP WAN. The remote sites rely on the centralized Unified CMs to handle their call processing. The following considerations apply to this deployment model: • Each time a remote branch phone places a call, the control traffic traverses the IP WAN to reach the Unified CM at the central site, even if the call is local to the branch. • The signaling protocols that may traverse the IP WAN in this deployment model are SCCP (encrypted and non-encrypted), SIP (encrypted and non-encrypted), H.323, MGCP, and CTI-QBE. All the control traffic is exchanged between a Unified CM at the central site and endpoints or gateways at the remote branches. • If RSVP is deployed within the cluster, the control traffic between the Unified CM cluster at the central site and the Cisco RSVP Agents at the remote sites uses the SCCP protocol. As a consequence, you must provision bandwidth for control traffic that traverses the WAN between the branch routers and the WAN aggregation router at the central site. The control traffic that traverses the WAN in this scenario can be split into two categories: • Quiescent traffic, which consists of keep-alive messages periodically exchanged between the branch endpoints (phones, gateways, and Cisco RSVP Agents) and Unified CM, regardless of call activity. This traffic is a function of the quantity of endpoints. • Call-related traffic, which consists of signaling messages exchanged between the branch endpoints and the Unified CM at the central site when a call needs to be set up, torn down, forwarded, and so forth. This traffic is a function of the quantity of endpoints and their associated call volume. To obtain an estimate of the generated call control traffic, it is necessary to make some assumptions regarding the average number of calls per hour made by each branch IP phone. In the interest of simplicity, the calculations in this section assume an average of 10 calls per hour per phone. Note If this average number does not satisfy the needs of your specific deployment, you can calculate the recommended bandwidth by using the advanced formulas provided in Advanced Formulas, page 3-69. Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) OL-16394-07 3-67

Chapter 3 Network Infrastructure WAN Infrastructure Given the assumptions made, and initially considering the case of a remote branch with no signaling encryption configured, the recommended bandwidth needed for call control traffic can be obtained from the following formula: Equation 1A: Recommended Bandwidth Needed for SCCP Control Traffic without Signaling Encryption. Bandwidth (bps) = 265 ∗ (Number of IP phones and gateways in the branch) Equation 1B: Recommended Bandwidth Needed for SIP Control Traffic without Signaling Encryption. Bandwidth (bps) = 538 ∗ (Number of IP phones and gateways in the branch) If a site features a mix of SCCP and SIP endpoints, the two equations above should be employed separately for the quantity of each type of phone used, and the results added. Equation 1 and all other formulas within this section include a 25% over-provisioning factor. Control traffic has a bursty nature, with peaks of high activity followed by periods of low activity. For this reason, assigning just the minimum bandwidth required to a control traffic queue can result in undesired effects such as buffering delays and, potentially, packet drops during periods of high activity. The default queue depth for a Class-Based Weighted Fair Queuing (CBWFQ) queue in Cisco IOS equals 64 packets. The bandwidth assigned to this queue determines its servicing rate. Assuming that the bandwidth configured is the average bandwidth consumed by this type of traffic, it is clear that, during the periods of high activity, the servicing rate will not be sufficient to "drain" all the incoming packets out of the queue, thus causing them to be buffered. Note that, if the 64-packet limit is reached, any subsequent packets are either assigned to the best-effort queue or are dropped. It is therefore advisable to introduce this 25% over-provisioning factor to absorb and smooth the variations in the traffic pattern and to minimize the risk of a temporary buffer overrun. This is equivalent to increasing the servicing rate of the queue. If encryption is configured, the recommended bandwidth is affected because encryption increases the size of signaling packets exchanged between Unified CM and the endpoints. The following formula takes into account the impact of signaling encryption: Equation 2A: Recommended Bandwidth Needed for SCCP Control Traffic with Signaling Encryption. Bandwidth with signaling encryption (bps) = 415 ∗ (Number of IP phones and gateways in the branch) Equation 2B: Recommended Bandwidth Needed for SIP Control Traffic with Signaling Encryption. Bandwidth with signaling encryption (bps) = 619 ∗ (Number of IP phones and gateways in the branch) If we now take into account the fact that the smallest bandwidth that can be assigned to a queue on a Cisco IOS router is 8 kbps, we can summarize the values of minimum and recommended bandwidth for various branch office sizes, as shown in Table 3-12. Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x)3-68 OL-16394-07

Chapter 3 Network Infrastructure WAN InfrastructureTable 3-12 Recommended Layer 3 Bandwidth for Call Control Traffic With and Without Signaling EncryptionBranch Office Size Recommended Recommended Recommended Recommended(Number of Bandwidth for SCCP Bandwidth for SCCP Bandwidth for SIP Bandwidth for SIPIP Phones and Control Traffic (no Control Traffic (with Control Traffic (no Control Traffic (withGateways) encryption) encryption) encryption) encryption)1 to 10 8 kbps 8 kbps 8 kbps 8 kbps20 8 kbps 9 kbps 11 kbps 12 kbps30 8 kbps 13 kbps 16 kbps 19 kbps40 11 kbps 17 kbps 22 kbps 25 kbps50 14 kbps 21 kbps 27 kbps 31 kbps60 16 kbps 25 kbps 32 kbps 37 kbps70 19 kbps 29 kbps 38 kbps 43 kbps80 21 kbps 33 kbps 43 kbps 49 kbps90 24 kbps 38 kbps 48 kbps 56 kbps100 27 kbps 42 kbps 54 kbps 62 kbps110 29 kbps 46 kbps 59 kbps 68 kbps120 32 kbps 50 kbps 65 kbps 74 kbps130 35 kbps 54 kbps 70 kbps 80 kbps140 37 kbps 58 kbps 75 kbps 87 kbps150 40 kbps 62 kbps 81 kbps 93 kbps Note Table 3-12 assumes 10 calls per hour per phone, and it does not include RSVP control traffic. To determine the RSVP-related bandwidth to add to the values in this table, see Considerations for Calls Using RSVP, page 3-70. Note If an RSVP-based locations policy is used for inter-site calls, the values of Table 3-12 must be increased to compensate for the control traffic of the Cisco RSVP Agent. For example, if 10% of the calls go over the WAN, multiply the value from Table 3-12 by 1.1. Advanced Formulas The previous formulas presented in this section assume an average call rate per phone of 10 calls per hour. However, this rate might not correspond to your deployment if the call patterns are significantly different (for example, with call center agents at the branches). To calculate call control bandwidth requirements in these cases, use the following formulas, which contain an additional variable (CH) that represents the average calls per hour per phone: Equation 3A: Recommended Bandwidth Needed for SCCP Control Traffic for a Branch with No Signaling Encryption. Bandwidth (bps) = (53 + 21 ∗ CH) ∗ (Number of IP phones and gateways in the branch) Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) OL-16394-07 3-69

Chapter 3 Network Infrastructure WAN Infrastructure Equation 3B: Recommended Bandwidth Needed for SIP Control Traffic for a Branch with No Signaling Encryption. Bandwidth (bps) = (138 + 40 ∗ CH) ∗ (Number of IP phones and gateways in the branch) Equation 4A: Recommended Bandwidth Needed for SCCP Control Traffic for a Remote Branch with Signaling Encryption. Bandwidth with signaling encryption (bps) = (73.5 + 33.9 ∗ CH) ∗ (Number of IP phones and gateways in the branch) Equation 4B: Recommended Bandwidth Needed for SIP Control Traffic for a Remote Branch with Signaling Encryption. Bandwidth with signaling encryption (bps) = (159 + 46 ∗ CH) ∗ (Number of IP phones and gateways in the branch) Note Equations 3A and 4A are based on the default SCCP keep-alive period of 30 seconds, while equations 3B and 4B are based on the default SIP keep-alive period of 120 seconds. Considerations for Calls Using RSVP In systems where call admission control uses RSVP, there is additional SCCP call control traffic between Unified CM and the Cisco RSVP Agents located at the branch when IP calls are placed across the WAN. To compute the associated bandwidth, use the following equation: Equation 5: Recommended Bandwidth Needed for SCCP Control Traffic for Cisco RSVP Agents. Bandwidth (bps) = (21 ∗ CHW) ∗ (Number of IP phones and gateways in the branch) Where CHW represents the number of calls placed across the IP WAN per hour per phone, including calls between IP phones at different branches as well as calls made through gateways located in a different site. For example, in a site where 20 phones each make 10 calls per hour, if 20% of the calls are placed across the IP WAN, then CHW = 2. The equation thus yields: (21∗2)∗20 = 840 bps. The bandwidth calculated by Equation 5 should be added to the required bandwidth for phone call control. Considerations for Shared Line Appearances Calls placed to shared line appearances, or calls sent to line groups using the Broadcast distribution algorithm, have two net effects on the bandwidth consumed by the system: • Because all the phones on which the line is configured ring simultaneously, they represent a load on the system corresponding to a much higher calls-per-hour (CH) value than the CH of the line. The corresponding bandwidth consumption is therefore increased. The network infrastructures bandwidth provisioning requires adjustments when WAN-connected shared line functionality is deployed. The CH value employed for Equations 3 and 4 must be increased according to the following formula: CHS = CHL ∗ (Number line appearances) / (Number of lines) Where CHS is the shared-line calls per hour to be used in Equations 3 and 4, and CHL is the calls-per-hour rating of the line. For example, if a site is configured with 5 lines making an average of 6 calls per hour but 2 of those lines are shared across 4 different phones, then: Number of lines = 5 Number of line appearances = (2 lines appear on 4 phones, and 3 lines appear on only one phone) = (2∗4) + 3 = 11 line appearances Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x)3-70 OL-16394-07

Chapter 3 Network Infrastructure WAN Infrastructure CHL = 6 CHS = 6 ∗ (11 / 5) = 13.2 • Because each of the ringing phones requires a separate signaling control stream, the quantity of packets sent from Unified CM to the same branch is increased in linear proportion to the quantity of phones ringing. Because Unified CM is attached to the network through a 100 Mbps interface, it can instantaneously generate a very large quantity of packets that must be buffered while the queuing mechanism is servicing the signaling traffic. The servicing speed is limited by the WAN interfaces effective information transfer speed, which is typically two orders of magnitude smaller than 100 Mbps. This traffic may overwhelm the queue depth of the central sites WAN router. By default, the queue depth available for each of the classes of traffic in Cisco IOS is 64. In order to prevent any packets from being dropped before they are queued for the WAN interface, you must ensure that the signaling queues depth is sized to hold all the packets from at least one full shared-line event for each shared-line phone. Avoiding drops is paramount in ensuring that the call does not create a race condition where dropped packets are retransmitted, causing system response times to suffer. Therefore, the quantity of packets required to operate shared-line phones is as follows: – SCCP protocol: 13 packets per shared-line phone – SIP protocol: 11 packets per shared-line phone For example, with SCCP and with 6 phones sharing the same line, the queue depth for the signaling class of traffic must be adjusted to a minimum of 78. Table 3-13 provides recommended queue depths based on the quantity of shared line appearances within a branch site. Table 3-13 Recommended Queue Depth per Branch Site Number of Shared Line Queue Depth (Packets) Appearances SCCP SIP 5 65 55 10 130 110 15 195 165 20 260 220 25 325 275 When using a Layer 2 WAN technology such as Frame Relay, this adjustment must be made on the circuit corresponding to the branch where the shared-line phones are located. When using a Layer 3 WAN technology such as MPLS, there may be a single signaling queue servicing multiple branches. In this case, adjustment must be made for the total of all branches serviced. Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x)OL-16394-07 3-71

Chapter 3 Network Infrastructure Wireless LAN InfrastructureProvisioning for Call Control Traffic with Distributed Call Processing In distributed call processing deployments, several sites are connected through an IP WAN. Each site contains a Unified CM cluster and can follow either the single-site model or the centralized call processing model. A gatekeeper may be used for call admission control between sites. The following considerations apply to this deployment model: • The signaling protocol used to place a call across the WAN is H.323 or SIP. • Control traffic is exchanged between the Cisco IOS gatekeeper and the Unified CM clusters at each site, as well as between the Unified CM clusters themselves. Therefore, bandwidth for control traffic must be provisioned on the WAN links between Unified CMs as well as between each Unified CM and the gatekeeper. Because the topology is limited to hub-and-spoke, with the gatekeeper typically located at the hub, the WAN link that connects each site to the other sites usually coincides with the link that connects the site to the gatekeeper. The control traffic that traverses the WAN belongs to one of the following categories: • Quiescent traffic, which consists of registration messages periodically exchanged between each Unified CM and the gatekeeper • Call-related traffic, which in turn consists of two types of traffic: – Call admission control traffic, exchanged between the Unified CMs and the call admission control device (such as a gatekeeper or Cisco RSVP Agent) before a call can be set up and after it has been torn down. – Signaling traffic associated with a media stream, exchanged over an intercluster trunk when a call needs to be set up, torn down, forwarded, and so on. Because the total amount of control traffic depends on the number of calls that are set up and torn down at any given time, it is necessary to make some assumptions about the call patterns and the link utilization. The WAN links that connect each of the spoke sites to the hub site are normally provisioned to accommodate different types of traffic (for example, data, voice, and video). Using a traditional telephony analogy, we can view the portion of the WAN link that has been provisioned for voice as a number of virtual tie lines. Assuming an average call duration of 2 minutes and 100 percent utilization of each virtual tie line, we can derive that each tie line carries a volume of 30 calls per hour. This assumption allows us to obtain the following formula that expresses the recommended bandwidth for call control traffic as a function of the number of virtual tie lines. Equation 6: Recommended Bandwidth Based on Number of Virtual Tie Lines. Recommended Bandwidth (bps) = 116 ∗ (Number of virtual tie lines) If we take into account the fact that 8 kbps is the smallest bandwidth that can be assigned to a queue on a Cisco IOS router, we can deduce that a minimum queue size of 8 kbps can accommodate the call control traffic generated by up to 70 virtual tie lines. This amount should be sufficient for most large enterprise deployments.Wireless LAN Infrastructure Wireless LAN infrastructure design becomes important when IP telephony is added to the wireless LAN (WLAN) portions of a converged network. With the addition of wireless IP telephony endpoints such as the Cisco Unified Wireless IP Phones 7920, 7921G, and 7925G, voice traffic has moved onto the WLAN and is now converged with the existing data traffic there. Just as with wired LAN and wired WAN Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) 3-72 OL-16394-07

Chapter 3 Network Infrastructure Wireless LAN Infrastructure infrastructure, the addition of voice in the WLAN requires following basic configuration and design best-practices for deploying a highly available network. In addition, proper WLAN infrastructure design requires understanding and deploying QoS on the wireless network to ensure end-to-end voice quality on the entire network. The following sections discuss these requirements: • WLAN Design and Configuration, page 3-73 • WLAN Quality of Service (QoS), page 3-79 For more information about WLAN and Voice over WLAN (VoWLAN) design, refer to the latest version of the Voice over Wireless LAN Design Guide, available at http://www.cisco.com/go/designzoneWLAN Design and Configuration Properly designing a WLAN requires, first and foremost, ensuring that the existing wired network is deployed in a highly available, fault-tolerant and redundant manner. Next, an understanding of wireless technology is required. Finally, by configuring and deploying wireless access points (APs) and wireless telephony endpoints in an effective way, you can build a flexible, secure, redundant, and highly scalable network. The following sections examine the WLAN infrastructure layers and network services: • Wireless Infrastructure Considerations, page 3-73 • Wireless AP Configuration and Design, page 3-76 • Wireless Security, page 3-77Wireless Infrastructure Considerations The following sections provide guidelines and best practices for designing the WLAN infrastructure: • VLANs, page 3-73 • Roaming, page 3-74 • Wireless Channels, page 3-74 • Wireless Interference, page 3-75 • Multicast on the WLAN, page 3-76 VLANs Just as with a wired LAN infrastructure, when deploying voice in a wireless LAN, you should enable at least two virtual LANs (VLANs) at the Access Layer. The Access Layer in a wireless LAN environment includes the access point (AP) and the first-hop access switch. On the AP and access switch, you should configure both a native VLAN for data traffic and a voice VLAN (under Cisco IOS) or Auxiliary VLAN (under CatOS) for voice traffic. This voice/auxiliary VLAN should be separate from all the other wired voice VLANs in the network. In addition, as with voice endpoints on wired LANs, wireless voice endpoints should be addressed using RFC 1918 private subnet addresses. When deploying a wireless infrastructure, Cisco also recommends configuring a separate management VLAN for the management of WLAN APs. This management VLAN should not have a WLAN appearance; that is, it should not have an associated service set identifier (SSID) and it should not be directly accessible from the WLAN. Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) OL-16394-07 3-73

Chapter 3 Network Infrastructure Wireless LAN Infrastructure Roaming When devices roam at Layer 3, they move from one AP to another AP across native VLAN boundaries. When the WLAN network infrastructure consists of autonomous APs, the Cisco Catalyst 6500 Series Wireless Services Module (WiSM) allows the Cisco Unified Wireless IP Phone to keep its IP address and roam at Layer 3 while still maintaining an active call. Seamless Layer 3 roaming occurs only when the client is roaming within the same mobility group. For details about the Cisco WiSM and Layer 3 roaming, refer to the Cisco WiSM product documentation available at http://www.cisco.com Seamless Layer 3 roaming for clients across a lightweight access point infrastructure is accomplished by WLAN controllers that use dynamic interface tunneling. Cisco Unified Wireless IP Phones that roam across WLAN controllers and VLANs can keep their IP address when using the same SSID and therefore can maintain an active call. Note In dual-band WLANs (those with 2.4 GHz and 5 GHz bands), it is possible to roam between 802.11b/g and 802.11a with the same SSID, provided the client is capable of supporting both bands. However, this can cause gaps in the voice path. In order to avoid these gaps, use only one band for voice. Note If Cisco Catalyst 4000 Series switches are used as Layer 3 devices at the distribution layer, a minimum of a Supervisor Engine 2+ (SUP2+) or Supervisor Engine 3 (SUP3) module is required. The Supervisor Engine 1 or 2 (SUP1 or SUP2) modules can cause roaming delays. The Cisco Catalyst 2948G, 2948G-GE-TX, 2980G, 2980G-A, and 4912 switches are also known to introduce roaming delays. Cisco does not recommend using these switches in a wireless voice network. Wireless Channels Wireless endpoints and APs communicate via radios on particular channels. When communicating on one channel, wireless endpoints typically are unaware of traffic and communication occurring on other non-overlapping channels. Optimal channel configuration for 2.4 GHz 802.11b and 802.11g requires a minimum of five-channel separation between configured channels to prevent interference or overlap between channels. In North America, with allowable channels of 1 to 11, channels 1, 6, and 11 are the three usable non-overlapping channels for APs and wireless endpoint devices. However, in Europe where the allowable channels are 1 to 13, multiple combinations of five-channel separation are possible. Multiple combinations of five-channel separation are also possible in Japan, where the allowable channels are 1 to 14. Optimal channel configuration for 5 GHz 802.11a requires a minimum of one-channel separation to prevent interference or overlap between channels. In North America, there are 20 possible non-overlapping channels: 36, 40, 44, 48, 52, 56, 60, 64, 100, 104, 108, 112, 116, 132, 136, 140, 149, 153, 157, and 161. In Europe, the same non-overlapping channels are allowed. However, many countries do not support the use of channel 40, so there are only 19 possible overlapping channels. In Japan, only 8 non-overlapping channels are supported: 36, 40, 44, 48, 52, 56, 60, and 64. Because of the larger set of non-overlapping channels, 802.11a allows for more densely deployed WLANs. Note that the 802.11a band does require support for Dynamic Frequency Selection (DFS) and Transmit Power Control (TPC) on some channels in order to avoid interference with radar (military, satellite, and weather). Regulations require that channels 52 to 64, 100 to 116, and 132 to 140 support DFS and TPC. TPC ensures that transmissions on these channels are not powerful enough to cause interference. DFC monitors channels for radar pulses and, when it detects a radar pulse, DFC stops transmission on the channel and switches to a new channel. Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x)3-74 OL-16394-07

Chapter 3 Network Infrastructure Wireless LAN Infrastructure AP coverage should be deployed so that no (or minimal) overlap occurs between APs configured with the same channel. Same channel overlap should typically occur at 19 dBm separation. However, proper AP deployment and coverage on non-overlapping channels require a minimum overlap of 20%. This amount of overlap ensures smooth roaming for wireless endpoints as they move between AP coverage cells. Overlap of less than 20% can result in slower roaming times and poor voice quality. Deploying wireless devices in a multi-story building such as an office high-rise or hospital introduces a third dimension to wireless AP and channel coverage planning. Both the 2.4 GHz and 5.0 GHz wave forms of 802.11 can pass through floors and ceilings as well as walls. For this reason, not only is it important to consider overlapping cells or channels on the same floor, but it is also necessary to consider channel overlap between adjacent floors. With only three channels, proper overlap can be achieved only through careful three-dimensional planning. Note Careful deployment of APs and channel configuration within the wireless infrastructure are imperative for proper wireless network operation. For this reason, Cisco requires that a complete and thorough site survey be conducted before deploying wireless networks in a production environment. The survey should include verifying non-overlapping channel configurations, AP coverage, and required data and traffic rates; eliminating rogue APs; and identifying and mitigating the impact of potential interference sources. Wireless Interference Interference sources within a wireless environment can severely limit endpoint connectivity and channel coverage. In addition, objects and obstructions can cause signal reflection and multipath distortion. Multipath distortion occurs when traffic or signaling travels in more than one direction from the source to the destination. Typically, some of the traffic arrives at the destination before the rest of the traffic, which can result in delay and bit errors in some cases. You can reduce the affects of multipath distortion by eliminating or reducing interference sources and obstructions, and by using diversity antennas so that only a single antenna is receiving traffic at any one time. Interference sources should be identified during the site survey and, if possible, eliminated. At the very least, interference impact should be alleviated by proper AP placement and the use of location-appropriate directional or omni-directional diversity radio antennas. Possible interference sources include: • Other APs on overlapping channels • Other 2.4 GHz appliances, such as 2.4 GHz cordless phones, personal wireless network devices, sulphur plasma lighting systems, microwave ovens, rogue APs, and other WLAN equipment that takes advantage of the license-free operation of the 2.4 GHz band • Metal equipment, structures, and other metal or reflective surfaces such as metal I-beams, filing cabinets, equipment racks, wire mesh or metallic walls, fire doors and fire walls, concrete, and heating and air conditioning ducts • High-power electrical devices such as transformers, heavy-duty electric motors, refrigerators, elevators, and elevator equipment Because Bluetooth-enabled devices use the same 2.4 GHz radio band as 802.11 b and g devices, it is possible that Bluetooth and 802.11 b or g devices can interfere with each other, thus resulting in connectivity issues. Due to the potential for Bluetooth devices to interfere with and disrupt 802.11 b and g WLAN voice devices (resulting in poor voice quality, deregistration, and/or call setup delays), Cisco recommends, when possible, that you deploy all WLAN voice devices on 802.11a, which uses the 5 GHz radio band. By deploying wireless phones on the 802.11a radio band, you can avoid interference caused by Bluetooth devices. Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x)OL-16394-07 3-75

Chapter 3 Network Infrastructure Wireless LAN Infrastructure Multicast on the WLAN By design, multicast does not have the acknowledgement level of unicast. According to 802.11 specifications, the access point must buffer all multicast packets until the next Delivery Traffic Indicator Message (DTIM) period is met. The DTIM period is a multiple of the beacon period. If the beacon period is 100 ms (typical default) and the DTIM value is 2, then the access point must wait up to 200 ms before transmitting a single buffered multicast packet. The time period between beacons (as a product of the DTIM setting) is used by battery-powered devices to go into power save mode temporarily. This power save mode helps the device conserve battery power. Multicast on WLAN presents a twofold problem in which administrators must weigh multicast traffic quality requirements against battery life requirements. First, delaying multicast packets will negatively affect multicast traffic quality, especially for applications that multicast real-time traffic such as voice. In order to limit the delay of multicast traffic, DTIM periods should typically be set to a value of 1 so that the amount of time multicast packets are buffered is low enough to eliminate any perceptible delay in multicast traffic delivery. However, by setting the DTIM period to a value of 1, the amount of time that battery-powered WLAN devices are able to go into power save mode is shortened, and therefore battery life is shortened. In order to conserve battery power and lengthen battery life, DTIM periods should typically be set to a value of 2 or more. For WLAN networks with no multicast applications or traffic, the DTIM period should be set to a value of 2 or higher. For WLAN networks where multicast applications are present, the DTIM period should be set to a value of 2 whenever possible; however, if multicast traffic quality suffers or if unacceptable delay occurs, then the DTIM value should be lowered to 1. If the DTIM value is set to 1, administrators must keep in mind that battery life of battery-operated devices will be significantly shortened. Before enabling multicast applications on the wireless network, Cisco recommends testing these applications to ensure that performance and behavior are acceptable. For additional considerations with multicast traffic, see Music on Hold, page 7-1.Wireless AP Configuration and Design Proper AP selection, deployment, and configuration are essential to ensure that the wireless network handles voice traffic in a way that provides high-quality voice to the end users. AP Selection Cisco recommends the following APs for deploying wireless voice: • Aironet 500 Series Express APs • Aironet 1100, 1130, and 1140 Series APs • Aironet 1230, 1240, and 1250 Series APs • Aironet 1300 Series APs • Aironet 1510 and 1520 Series APs For these APs, Cisco IOS Release 12.3(4) JA or later is recommended. AP Deployment When you use Cisco access points (APs) for voice deployments, Cisco recommends that you do not associate more than 15 to 25 devices to a single 802.11b or 802.11b/g AP at any given time. For 802.11a or 802.11a/g APs, Cisco recommends that you do not associate more than 45 to 50 devices to a single AP. These numbers will vary depending on usage profiles and the enabled data rates. The number of Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) 3-76 OL-16394-07

Chapter 3 Network Infrastructure Wireless LAN Infrastructure devices on an AP affects the amount of time each device has access to the medium. As the number of devices increases, the traffic contention increases. Associating more devices than specified above can result in poor AP performance and slower response times for associated devices. While there is no specific mechanism to ensure that only a limited number of devices are associated to a single AP, system administrators can manage device-to-AP ratios by conducting periodic site surveys and analyzing user and device traffic patterns. If additional devices and users are added to the network in a particular area, additional site surveys should be conducted to determine whether additional APs are required to handle the number of endpoints that need to access the network. AP Configuration When deploying wireless voice, observe the following specific AP configuration requirements: • Enable Address Resolution Protocol (ARP) caching. ARP caching is required on the AP because it enables the AP to answer ARP requests for the wireless endpoint devices without requiring the endpoint to leave power-save or idle mode. This feature results in extended battery life for the wireless endpoint devices. • Enable Dynamic Transmit Power Control (DTPC) on the AP. This ensures that the transmit power on the AP and on the voice endpoints match. Matching transmit power helps eliminate the possibility of one-way audio traffic. Voice endpoints adjust their transmit power based on the Limit Client Power (mW) setting of the AP to which they are associated. • Assign a Service Set Identifier (SSID) to each VLAN configured on the AP. SSIDs enable endpoints to select the wireless VLAN they will use for sending and receiving traffic. These wireless VLANs and SSIDs map to wired VLANs. For voice endpoints, this mapping ensures priority queuing treatment and access to the voice VLAN on the wired network. • Enable QoS Element for Wireless Phones on the AP. This feature ensures that the AP will provide QoS Basic Service Set (QBSS) information elements in beacons. The QBSS element provides an estimate of the channel utilization on the AP, and Cisco wireless voice devices use it to help make roaming decisions and to reject call attempts when loads are too high. Beginning with Cisco IOS Release 12.3(7)JA, the AP also provides 802.11e clear channel assessment (CCA) QBSS in beacons. The CCA-based QBSS values reflect true channel utilization. • Configure two QoS policies on the AP, and apply them to the VLANs and interfaces. Configure a voice policy and a data policy with default classifications for the respective VLANs to ensure that voice traffic is given priority queuing treatment. (See Interface Queuing, page 3-80, for more information).Wireless Security Another important consideration for a wireless infrastructure is security. Wireless endpoints, including wireless phones, can connect to the wireless network using one of the following security mechanisms: • Extensible Authentication Protocol-Flexible Authentication via Secure Tunneling (EAP-FAST) A standards-based security protocol that first requires the establishment of an authenticated tunnel between the wireless client and an Authentication, Authorization, and Accounting (AAA) server using a Protected Access Credential (PAC). Next the wireless endpoint authenticates across the tunnel using a user name and password to authenticate with the network via 802.1X. Once this authentication occurs, traffic to and from the wireless device is encrypted using TKIP or WEP. Using Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) OL-16394-07 3-77

Chapter 3 Network Infrastructure Wireless LAN Infrastructure the 802.1X authentication method requires an EAP-compliant Remote Authentication Dial-In User Service (RADIUS) authentication server such as the Cisco Secure Access Control Server (ACS), which provides access to a user database for authenticating the wireless devices. • Extensible Authentication Protocol-Transport Layer Security (EAP-TLS) This method allows the Cisco Unified Wireless IP Phone to be authenticated to the AP via 802.1X with a user name and password once a secure authenticated tunnel is established between the client and the authentication server using the TLS protocol with a public key infrastructure (PKI). Upon authentication, traffic to and from the wireless device is encrypted using TKIP or WEP. TLS provides the ability to use certificates for both user and server authentication and for dynamic session key generation. The certificate used for authentication can be either the Manufacturing Installed Certificate (MIC) or a user installed certificate. • Protected Extensible Authentication Protocol (PEAP) This method allows the Cisco Unified Wireless IP Phone to be authenticated to the AP via 802.1X with a user name and password over an encrypted SSL/TLS tunnel between the client and the authentication server. The encrypted SSL/TLS tunnel is created using server-side public key certificates, ensuring that exchange of authentication information is encrypted using Version 2 of Microsoft’s Challenge Handshake Authentication Protocol (MS-CHAP) and that user credentials are safe from eavesdropping. Upon authentication, traffic to and from the wireless device is encrypted using TKIP or WEP. • Wi-Fi Protected Access (WPA) A standards-based security protocol requires the wireless endpoint to provide a user name and password to authenticate with the network. Once this authentication occurs using either 802.1X or WPA Pre-Shared Key (WPA-PSK), traffic to and from the wireless device is encrypted using Temporal Key Integrity Protocol (TKIP). Using the 802.1X authentication method requires an EAP-compliant Remote Authentication Dial-In User Service (RADIUS) authentication server such as the Cisco Secure Access Control Server (ACS), which provides access to a user database for authenticating the wireless devices. • Wi-Fi Protected Access 2 (WPA2) This is the 802.11i enhanced version of WPA. It is a standards-based security protocol that requires the wireless endpoint to provide a user name and password to authenticate with the network. Once this authentication occurs using either 802.1X or Pre-Shared Key (WPA2-PSK), traffic to and from the wireless device is encrypted using Advanced Encryption Standards (AES). Using the 802.1X authentication method requires an EAP-compliant Remote Authentication Dial-In User Service (RADIUS) authentication server such as the Cisco Secure Access Control Server (ACS), which provides access to a user database for authenticating the wireless devices. • Cisco LEAP Cisco LEAP requires the wireless endpoint to provide a user name and password to authenticate with the network. Once this authentication occurs, a dynamic key is generated, and traffic to and from the wireless device is encrypted. This method requires an EAP-compliant Remote Authentication Dial-In User Service (RADIUS) authentication server such as the Cisco Secure Access Control Server (ACS), which provides access to a user database for authenticating the wireless devices. • Static Wired Equivalent Privacy (WEP) Static WEP requires the exchange of a statically configured 40-bit or 128-bit character key between the wireless endpoint and the AP. If the keys match, the wireless device is given access to the network. Be aware that there are known weaknesses in the WEP encryption algorithm. These weaknesses, coupled with the complexity of configuring and maintaining static keys, can make this security mechanism undesirable in many cases. Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x)3-78 OL-16394-07

Chapter 3 Network Infrastructure Wireless LAN Infrastructure Authentication and ACS Deployment Models Extensible Authentication Protocol (EAP) is the preferred method of wireless device authentication (especially voice devices) because it provides the most secure and robust mechanism for access to the network and voice VLAN(s). Because an EAP-compliant RADIUS server is required, Cisco recommends the use of Cisco Secure ACS for Windows Server Version 3.1 or later. When deploying EAP-FAST, WPA, or Cisco LEAP for wireless authentication and encryption, carefully consider the placement of the ACS within the network, and select one of the following ACS deployment models: • Centralized ACS ACS server or servers are located in a centralized place within the network and are used to authenticate all wireless devices and users within the network. • Remote ACS In networks where remote locations are separated from the central site by low-speed or congested WAN links, an ACS server can be located at the remote site and remote wireless devices or users can be authenticated by this server locally, thus eliminating the potential for delayed authentication via a centralized ACS across the WAN link. • Local and fallback RADIUS server on the Cisco AP In networks where remote locations are separated from a central site by low-speed WAN links, local wireless devices can authenticate against local Cisco IOS APs. APs running Cisco IOS Release 12.2(11)JA or later can authenticate users and devices locally without relying on an external ACS. A single AP can support up to 50 users with this functionality. This feature can be used in lieu of a centralized or local ACS, or in the case of a WAN or ACS failure in which the remote site users are unable to contact a local ACS or the central site ACS. When choosing a deployment model for the ACS, it is imperative to make authentication services redundant so that the ACS does not become a single point of failure when wireless devices attempt to access the network. For this reason, each ACS server should replicate its database to a secondary server. Furthermore, it is always a good idea to provide a local ACS or an on-AP RADIUS server at remote sites to ensure that remote wireless devices can still authenticate in the event of a WAN failure. In addition to ACS server placement, it is also important to consider the implications of user database location in relation to the ACS server. Because the ACS server must access the user database to authenticate wireless devices, the location of the user database affects the amount of time the authentication will take. If the user database is a Microsoft Active Directory (AD) server located on the network, the ACS must send an authentication request to the AD server and wait for a response. To ensure the fastest response times for wireless voice endpoints attempting to authenticate to the network, Cisco recommends defining users locally on the ACS server. Remote databases have unknown response times and can adversely affect authentication times.WLAN Quality of Service (QoS) Just as QoS is necessary for LAN and WAN wired network infrastructure in order to ensure high voice quality, QoS is also required for wireless LAN infrastructure. Because of the bursty nature of data traffic and the fact that real-time traffic such as voice is sensitive to packet loss and delay, QoS tools are required to manage wireless LAN buffers, limit radio contention, and minimize packet loss, delay, and delay variation. Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) OL-16394-07 3-79

Chapter 3 Network Infrastructure Wireless LAN Infrastructure However, unlike most wired networks, wireless networks are a shared medium, and wireless endpoints do not have dedicated bandwidth for sending and receiving traffic. While wireless endpoints can mark traffic with 802.1p CoS, DSCP, and PHB, the shared nature of the wireless network means limited admission control and access to the network for these endpoints. Wireless QoS involves the following main areas of configuration: • Traffic Classification, page 3-80 • Interface Queuing, page 3-80 • Bandwidth Provisioning, page 3-81Traffic Classification As with wired network infrastructure, it is important to classify or mark pertinent wireless traffic as close to the edge of the network as possible. Because traffic marking is an entrance criterion for queuing schemes throughout the wired and wireless network, marking should be done at the wireless endpoint device whenever possible. Marking or classification by wireless network devices should be identical to that for wired network devices, as indicated in Table 3-6. In accordance with traffic classification guidelines for wired networks, the Cisco Wireless IP Phone 7920 marks voice media traffic or RTP traffic with DSCP 46 (or PHB EF) and voice signaling traffic (SCCP) with DSCP 24 (or PHB CS3). Once this traffic is marked, it can be given priority or better than best-effort treatment and queuing throughout the network. All wireless voice devices should be capable of marking traffic in this manner. All other traffic on the wireless network should be marked as best-effort or with some intermediary classification as outlined in wired network marking guidelines.Interface Queuing Once traffic marking has occurred, it is necessary to enable the wired network APs and devices to provide QoS queuing so that voice traffic types are given separate queues to reduce the chances of this traffic being dropped or delayed as it traverses the wireless LAN. Queuing on the wireless network occurs in two directions, upstream and downstream. Upstream queuing concerns traffic traveling from the wireless endpoint up to the AP and from the AP up to the wired network. Downstream queuing concerns traffic traveling from the wired network to the AP and down to the wireless endpoint. For upstream queuing, devices that support Wi-Fi Multimedia (WMM) are able to take advantage of queueing mechanisms, including priority queueing. However, devices that do not support WMM are unable to take advantage of this queueing mechanism. The Cisco Wireless IP Phones 7921G and 7925G do support WMM. The Cisco Wireless IP Phone 7920 does not support WMM; however, it can provide queuing upstream as the packets leave the device, but there is no mechanism in place to provide queuing among all clients on the wireless LAN because wireless networks are a shared medium. As for downstream QoS, Cisco APs currently provide up to eight queues for downstream traffic being sent to wireless clients. The entrance criterion for these queues can be based on a number of factors including DSCP, access control lists (ACLs), and VLAN. Although eight queues are available, Cisco recommends using only two queues when deploying wireless voice. All voice media and signaling traffic should be placed in the highest-priority queue, and all other traffic should be placed in the best-effort queue. This ensures the best possible queuing treatment for voice traffic. In order to set up this two-queue configuration for autonomous APs, create two QoS policies on the AP. Name one policy Voice, and configure it with the class of service Voice < 10 ms Latency (6) as the Default Classification for all packets on the VLAN. Name the other policy Data, and configure it with the class of service Best Effort (0) as the Default Classification for all packets on the VLAN. Then assign the Data policy to the incoming and outgoing radio interface for the data VLAN(s), and assign Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) 3-80 OL-16394-07

Chapter 3 Network Infrastructure Wireless LAN Infrastructure the Voice policy to the incoming and outgoing radio interfaces for the voice VLAN(s). With the QoS policies applied at the VLAN level, the AP is not forced to examine every packet coming in or going out to determine the type of queuing the packet should receive. For lightweight APs, the WLAN controller has built-in QoS profiles that can provide the same queuing policy. Voice VLAN or voice traffic is configured to use the Platinum policy, which sets priority queueing for the voice queue. Data VLAN or data traffic is configured to use the Silver policy, which sets best-effort queuing for the Data queue. These policies are then assigned to the incoming and outgoing radio interfaces based on the VLAN. The above configurations ensure that all voice media and signaling are given priority queuing treatment in a downstream direction.Bandwidth Provisioning Based on wireless voice network testing, Cisco has determined that an 802.11b-only AP with 802.11b clients and a data rate of 11 Mbps can support a maximum of seven active G.711 voice streams or eight G.729 streams. AP rates set lower than 11 Mbps will result in a lower call capacity per AP. With 802.11a at a data rate of 54 Mbps, the maximum number of active voice streams increases to between 14 and 18 per AP. For 802.11g environments with a data rate of 54 Mbps, in theory the maximum number of active voice streams also increases to between 14 and 18 per AP. However, because most 802.11g environments are mixed and include 802.11b clients (and therefore 11 Mbps data rates) as well as 802.11g clients, capacity is typically significantly lower, with a maximum of 8 to 12 active voice streams per AP. Note A call between two phones associated to the same AP counts as two active voice streams. To prevent these limits from being exceeded, some form of call admission control is required. Cisco APs and wireless voice clients have two mechanisms that are used for call admission control: • QoS Basic Service Set (QBSS) QBSS is the beacon information element that enables the AP to communicate channel utilization information to the wireless IP phone. This QBSS value helps wireless phones to determine whether they should roam to another AP. A lower QBSS value indicates that the AP is a good candidate to roam to, while a higher QBSS value indicates that the device should not roam to this AP. While this QBSS information is useful, it is not a true call admission control mechanism because it does not guarantee that calls will retain proper QoS or that there is enough bandwidth to handle the call. When a Cisco Unified Wireless IP Phone is associated to an AP with a high QBSS, the AP will prevent a call from being initiated or received by rejecting the call setup and sending a Network Busy message to the initiating device. However, once a call is set up between a wireless IP phone and another endpoint, the phone may roam and associate with an AP with a high QBSS, thus resulting in oversubscription of the available bandwidth on that AP. • Wi-Fi Multimedia Traffic Specification (WMM TSPEC) WMM TSPEC is the QoS mechanism that enables WLAN clients to provide an indication of their bandwidth and QoS requirements so that APs can react to those requirements. When a client is preparing to make a call, it sends an Add Traffic Stream (ADDTS) message to the AP with which it is associated, indicating the TSPEC. The AP can then accept or reject the ADDTS request based on whether bandwidth and priority treatment are available. If the call is rejected, the phone will receive a Network Busy message. When roaming, mid-call clients supporting TSPEC will send a ADDTS Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) OL-16394-07 3-81

Chapter 3 Network Infrastructure Wireless LAN Infrastructure message to the new AP as part of the association process to ensure that there is available bandwidth for priority treatment. If there is not enough bandwidth, the roam can be load-balanced to a neighboring AP if one is available. The Cisco Unified Wireless IP Phone 7920 supports only QBSS, so this is the only mechanism that can be used for call admission control with these devices. However, the Cisco Unified Wireless IP Phones 7921G and 7925G support both QBSS and TSPEC. (TSPEC takes precedence over QBSS.) Therefore call admission control with the Cisco Unified Wireless IP Phone 7921G or 7925G, when using TSPEC, is more accurate and eliminates the possibility of exceeding AP call capacities. Note Beginning with Cisco IOS Release 12.3(7)JA, the AP sends 802.11e CCA-based QBSS. These QBSS values represent true channel utilization for a particular AP. The QBSS information element is sent by the AP only if QoS Element for Wireless Phones has been enable on the AP. (Refer to Wireless AP Configuration and Design, page 3-76.) Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x)3-82 OL-16394-07

CH A P T E R 4 Gateways Last revised on: September 18, 2009 Gateways provide a number of methods for connecting an IP telephony network to the Public Switched Telephone Network (PSTN), a legacy PBX, or key systems. Gateways range from specialized, entry-level and stand-alone voice gateways to high-end, feature-rich integrated router and Cisco Catalyst gateways. This chapter explains important factors to consider when selecting a Cisco gateway to provide the appropriate protocol and feature support for your IP Telephony network. The main topics discussed in this chapter include: • Traffic Patterns and Gateway Sizing, page 4-2 • TDM and VoIP Trunking Gateways, page 4-7 • Understanding Cisco Gateways, page 4-7 • Gateway Selection, page 4-8 • QSIG Support, page 4-26 • Fax and Modem Support, page 4-27 • Gateways for Video Telephony, page 4-39Whats New in This Chapter Table 4-1 lists the topics that are new in this chapter or that have changed significantly from previous releases of this document. Table 4-1 New or Changed Information Since the Previous Release of This Document New or Revised Topic Described in: Bearer capabilities Bearer Capabilities of Voice Gateways, page 4-48 Cisco 2900 and 3900 Series Integrated Services Gateway Selection, page 4-8 Routers (ISRs) Cisco VGD-1T3, VG202, and VG204 Gateways Gateway Protocols, page 4-9 Site-Specific Gateway Requirements, page 4-18 H.320 video channel bonding ISDN B-Channel Binding, Rollover, and Busy Out, page 4-45 Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) OL-16394-07 4-1

Chapter 4 Gateways Traffic Patterns and Gateway Sizing Table 4-1 New or Changed Information Since the Previous Release of This Document New or Revised Topic Described in: TDM gateways TDM and VoIP Trunking Gateways, page 4-7 Videoconferencing gateways Gateways for Video Telephony, page 4-39 Voice gain and attenuation settings Tuning Gateway Gain Settings, page 4-8Traffic Patterns and Gateway Sizing This section presents a high-level discussion of the differences between various traffic models or patterns and how they can affect voice gateway selection. The emphasis is on traffic patterns and gateway sizing for traffic-intensive deployments.Definitions and Terminology This section uses the following terms and definitions: • Simultaneous calls The number of calls that are all active in the system at the same time. • Maximum simultaneous calls The maximum number of simultaneous calls in active (talk) state that the system can handle. The number of calls expected to be active simultaneously during the busy hour of the day should not exceed this number. • Calls per second (cps) The call arrival rate, described as the number of calls that arrive (that is, new call setup attempts) in one second. Call arrival rates are also often quoted in calls per hour, but this metric is looser in the sense that 100 calls arriving in the last five seconds of an hour provides an average call arrival rate of 100 calls per hour (which is an extremely low rate for a communications system), while it also provides an arrival rate of 20 calls per second (which is a high rate). Sustaining 20 calls per second for an entire hour would result in 72,000 calls per hour. Therefore calls-per-hour is not a very useful metric for ascertaining a systems ability to handle bursty call arrival traffic patterns. • Busy Hour Call Attempts (BHCA) The number of calls attempted during the busiest hour of the day (the peak hour). This is the same as the calls-per-second rating for the busiest hour of the day, but it is expressed over a period of an hour rather than a second. For example, 10 cps would be equal to 3600 calls per hour. There is also a metric for Busy Hour Call Completions (BHCC), which can be lower than the BHCA (call attempts) under the assumption that not all calls are successful (as when a blocking factor exists). This chapter assumes 100% call completions, so that BHCA = BHCC. • Bursty traffic Steady arrival means the call attempts are spaced more or less equally over a period of time. For example, 60 calls per hour at a steady arrival rate would present one call attempt roughly every minute (or approximately 0.02 cps). With bursty arrival, the calls arriving over a given period of time (such as an hour) are not spaced equally but are clumped together in one or more spikes. In the worst case, an arrival rate of 60 calls per hour could offer all 60 calls in a single second of the hour, thus averaging 0 cps for most of the hour with a peak of 60 cps for that one second. This kind of traffic is extremely stressful to communications systems. Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) 4-2 OL-16394-07

Chapter 4 Gateways Traffic Patterns and Gateway Sizing • Hold time This is the period of "talk time" on a voice call; that is, the period of time between call setup and call teardown when there is an open speech path between the two parties. A hold time of 3 minutes (180 seconds) is an industry average used for traffic engineering of voice systems. The shorter the hold time on the average call, the greater the percentage of system CPU time spent on setting up and tearing down calls compared to the CPU time spent on maintaining the speech path.PSTN Traffic Patterns Traffic, when used in the context of voice communication systems, refers to the volume of calls being sent and/or received. Of particular importance is the traffic carried by external circuits such as the public switched telephone network (PSTN). Traffic is measured in Erlangs, and an Erlang is defined as one call lasting for one hour. This section does not go into any further detail on Erlangs other than to say that there are mathematical tables (Erlang-B and Erlang-C) that are used to calculate how many circuits are required for a given amount of offered traffic. The amount of traffic received and generated by your business determines the size of the external circuits required. However; many customers typically continue to use the same number of circuits for their IP-based communications system as they previously used for a TDM-based system. While this sizing method might work if no issues are encountered, the process of ongoing system traffic analysis should be part of any routine maintenance practices. Traffic analysis can show that the system is over-provisioned for the current levels of traffic (and, therefore, the customer is paying for circuits that are not needed) or, conversely, that the system is under-provisioned and may be suffering from occasional blocked and/or lost calls, in which case increasing the number of circuits will remedy the situation.Normal Business Traffic Profile Most customers have a normal traffic profile, which means that they typically have two busy hours per day, one occurring during the morning from 10:00 to 11:00 and the other in the afternoon from 14:00 to 15:00. These busy-hour patterns can often be attributed to such things as employees starting the work day or returning from a lunch break. The calls themselves tend to have longer hold times and they tend to arrive and leave in a steady manner. A generally accepted industry average holding time to use for traffic calculations is 3 minutes. Assuming that the communications system is engineered with the busy-hour traffic in mind, no issues should arise. Engineering a system below these levels will result in blocked and/or lost calls, which can have a detrimental effect on business.Contact Center Traffic Profile Contact centers present somewhat different patterns of traffic in that these systems typically handle large volumes of calls for the given number of agents or interactive voice response (IVR) systems available to service them. Contact centers want to get the most out of their resources, therefore their agents, trunks, and IVR systems are kept busy all the while they are in operation, which usually is 24 hours a day. Call queuing is typical (when incoming call traffic exceeds agent capacity, calls wait in queue for the next available agent), and the agents are usually dedicated during their work shifts to taking contact center calls. Call holding times in contact centers are often of a shorter average duration than normal business calls. Contributing to the shorter average call holding time is the fact that many calls interact only with the IVR system and never need to speak to a human agent (also termed self-service calls). A representative Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) OL-16394-07 4-3

Chapter 4 Gateways Traffic Patterns and Gateway Sizing holding time for self-service calls is about 30 seconds, while a call that talks to an agent has an average holding time of 3 minutes (the same as normal business traffic), making the overall average holding time in the contact center shorter than for normal business traffic. The goal of contact centers to optimize resource use (including IVR ports, PSTN trunks, and human agents), combined with the fact that contact centers are systems dedicated to taking telephone calls, also presents the system with higher call arrival rates than in a typical business environment. These call arrival rates can also peak at different times of day and for different reasons (not the usual busy hour) than normal business traffic. For example, when a television advertisement runs for a particular holiday package with a 1-800 number, the call arrival rate for the system where those calls are received will experience a peak of traffic for about 15 minutes after the ad airs. This call arrival rate can exceed the average call arrival rate of the contact center by an order of magnitude.Gateway Sizing for Contact Center Traffic Short call durations as well as bursty call arrival rates impact the PSTN gateways ability to process the traffic. Under these circumstances the gateway needs more resources to process all calls in a timely manner, as compared to gateways that receive calls of longer duration that are presented more uniformly over time. Because gateways have varying capabilities to deal with these traffic patterns, careful consideration should be given to selecting the appropriate gateway for the environment in which it will operate. Some gateways support more T1/E1 ports than others, and some are more able than others to deal with multiple calls arriving at the same time. For a traffic pattern with multiple calls arriving in close proximity to each other (that is, high or bursty call arrival rates), a gateway with a suitable rating of calls per second (cps) is the best fit. Under these conditions, using calls with 15-second hold times, the Cisco AS5400XM Universal Gateway can maintain 20 cps (with 310 calls active at once), the Cisco 3845 Integrated Services Router can maintain 17 cps (with 255 calls active at once), and the Cisco Catalyst 6500 Communication Media Module can maintain 7 cps (with 130 calls active at once). The performance of the Cisco AS5350XM Universal Gateway is identical to that of the AS5400XM in terms of calls per second. For traffic patterns with a steady arrival rate, the maximum number of active calls that a gateway can handle is generally the more important consideration. Under these conditions, using calls with 180-second hold times, the Cisco AS5400XM Universal Gateway can maintain 630 simultaneously active calls (with a call arrival rate of up to 3.5 cps), the Cisco 3845 Integrated Services Router can maintain 504 simultaneously active calls (with a call arrival rate of up to 3 cps), and the Cisco Catalyst 6500 Communication Media Module can maintain 240 simultaneously active calls (with a call arrival rate of up to 1.3 cps). These numbers assume that all of the following conditions apply: • CPU utilization does not exceed 75%. • PSTN gateway calls are made with ISDN PRI trunks using H.323. • Real Time Control Protocol (RTCP) timer is set to the default value of 5 seconds. • Voice Activity Detection (VAD) is off. • G.711 uses 20 ms packetization. • Cisco IOS Release 12.4.11T or later is used. • Dedicated voice gateway configurations are used, with ethernet (GE) egress and no QoS features. (Using QoS-enabled egress interfaces or non-ethernet egress interfaces, or both, will consume additional CPU resources.) Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) 4-4 OL-16394-07

Chapter 4 Gateways Traffic Patterns and Gateway Sizing • No supplementary call features or services are enabled – such as general security (for example, access control lists or firewalls), voice-specific security (TLS, IPSec and/or SRTP), AAA lookups, gatekeeper-assisted call setups, VoiceXML or TCL-enabled call flows, call admission control (RSVP), and SNMP polling/logging. Such extra call features will use additional CPU resources.Voice Activity Detection (VAD) VAD is a digital signal processing feature that suppresses the creation of most of the IP packets during times when the speech path in a particular direction of the call is perceived as being silent. Typically only one party on a call speaks at a time, so that packets need flow in only one direction, and packets in the reverse (or silent) direction need not be sent except as an occasional keepalive measure. VAD can therefore provide significant savings in the number of IP packets sent for a VoIP call, and thereby save considerable CPU cycles on the gateway platform. While the actual packet savings that VAD can provide varies with the call flow, the application, and the nature of speaker interactions, it tends to use 10% to 30% fewer packets than would be sent for a call made using a VAD-off configuration. VAD is most often turned off in endpoints and voice gateways deployed in Unified CM networks; VAD is most often turned on in voice gateways in other types of network deployments.Codec Both G.711 and G.729A use as their default configuration a 20 ms sampling time, which results in a 50 packets per second (pps) VoIP call in each direction. While a G.711 IP packet (200 bytes) is larger than a G.729A packet (60 bytes), this difference has not proven to have any significant effect on voice gateway CPU performance. Both G.711 and G.729 packets qualify as "small" IP packets to the router, therefore the packet rate is the salient codec parameter affecting CPU performance.Performance Overload Cisco IOS is designed to have some amount of CPU left over during peak processing, to handle interrupt-level events. The performance figures in this section are designed with the processor running at an average load of approximately 75%. If the load on a given Cisco IOS gateway continually exceeds this threshold, the following will result: • The deployment will not be supported by Cisco Technical Assistance Center (TAC). • The Cisco IOS Gateway will display anomalous behavior, including Q.921 timeouts, longer post-dial delay, and potentially interface flaps. Cisco IOS Gateways are designed to handle a short burst of calls, but continual overloading of the recommended call rate (calls per second) is not supported. Note With any gateway, you might be tempted to assign unused hardware ports to other tasks, such as on a CMM gateway where traffic calculations have dictated that only a portion of the ports can be used for PSTN traffic. However, the remaining ports must remain unused, otherwise the CPU will be driven beyond supported levels.Performance Tuning The CPU utilization of a Cisco IOS Voice gateway is affected by every process that is enabled in a chassis. Some of the lowest level processes such as IP routing and memory defragmentation will occur even when there is no live traffic on the chassis. Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) OL-16394-07 4-5

Chapter 4 Gateways Traffic Patterns and Gateway Sizing Lowering the CPU utilization can help to increase the performance of a Cisco IOS Voice Gateway by ensuring that there are enough available CPU resources to process the real-time voice packets and the call setup instructions. Some of the techniques for decreasing CPU utilization are described in Table 4-2.Table 4-2 Techniques for Reducing CPU UtilizationTechnique CPU Savings DescriptionEnable Voice Activity Detection Up to 20% Enabling VAD can result in up to 45% fewer voice packets in(VAD) typical conversations. The difficultly is that, in scenarios where voice recognition is used or there are long delays, a reduction in voice quality can occur. Voice appears to "pop" in at the beginning and "pop" out at the end of talk spurts.Disable Real Time Control Protocol Up to 5% Disabling RTCP results in less out-of-band information being sent(RTCP) between the originating and terminating gateways. This results in lower quality of statistics displayed on the paired gateway. This can also result in the terminating gateway having a call "hang" for a longer period of time if RTCP packets are being used to determine if a call is no longer active.Disable other non-essential functions Up to 2% Any of these processes, when not required, can be disabled and willsuch as: Authentication, result in lower CPU utilization by freeing up the CPU to provideAuthorization, and Accounting faster processing of real-time traffic.(AAA); Simple Network ManagementProtocol (SNMP); and loggingChange call pattern to increase the Varies This can be done by a variety of techniques such as including alength of the call (and reduce the long(er) introduction prompt played at the beginning of a call ornumber of calls per second) adjusting the call script at the call center.Additional Information For more information on Cisco Voice Gateway capabilities and call center traffic analysis, refer to the following sources: • Cisco Voice Gateway Router Interoperability with Cisco Unified CallManager data sheet (Table 7): http://www.cisco.com/en/US/prod/collateral/routers/ps259/product_data_sheet0900aecd8057f2e0. pdf • Cisco AS5400XM Universal Gateway data sheet (Table 9): http://www.cisco.com/en/US/products/hw/univgate/ps505/products_data_sheet0900aecd802efc92. html • How to Order a Cisco AS5400XM Universal Gateway: http://www.cisco.com/en/US/products/hw/univgate/ps505/prod_brochure0900aecd802f6ece.html • Various voice traffic calculators, including Erlang calculators: http://www.erlang.com/calculator/ Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) 4-6 OL-16394-07

Chapter 4 Gateways TDM and VoIP Trunking GatewaysTDM and VoIP Trunking Gateways Until approximately 2006, the only choice for an enterprise to connect its internal VoIP network to voice services outside the enterprise was via TDM gateways to the traditional PSTN. Cisco offers a full range of TDM gateways with analog and digital connections to the PSTN as well as to PBXs and key systems. TDM connectivity covers a wide variety of low-density analog (FXS and FXO), low density digital (BRI), and high-density digital (T1, E1, and T3) interface choices. Starting around 2006, new voice service options to an enterprise started to become available from service providers, most often referred to as SIP trunk services. Using a SIP trunk for connecting to PSTN and other destinations outside the enterprise involves an IP-to-IP connection at the edge of the enterprises VoIP network. The same functions traditionally fulfilled by a TDM gateway are still needed at this interconnect point, including demarcation, call admission control, ensuring QoS, a troubleshooting boundary, security checks, and so forth. For SIP trunking connections, the Cisco Unified Border Element fulfils these functions as a session border controller (SBC) at the interconnect point between the enterprise and the service provider network. Cisco Unified Border Element also performs protocol translation functions to interconnect H.323 and SIP equipment, or to interconnect SIP equipment using different variations of SIP implementations. Cisco Unified Border Element can also perform transcoding. If used for one of these functions, Cisco Unified Border Element may also be used internal to the enterprise network at interconnect points between equipment that cannot interoperate without a protocol translation or transcoding service. TDM gateway platforms are discussed in detail in the remainder of this chapter. Cisco Unified Border Element is discussed in greater detail in the chapter on Cisco Unified CM Trunks, page 5-1. Both functions can be enabled on the same Cisco Integrated Services Router (ISR) platform at the same time.Understanding Cisco Gateways Cisco access gateways enable Cisco Unified Communications Manager (Unified CM) to communicate with non-IP telecommunications devices. There are two types of Cisco access gateways, analog and digital.Cisco Access Analog Gateways There are two categories of Cisco access analog gateways, trunk gateways and station gateways. • Access analog station gateways Analog station gateways connect Unified CM to Plain Old Telephone Service (POTS) analog telephones, interactive voice response (IVR) systems, fax machines, and voice mail systems. Station gateways provide Foreign Exchange Station (FXS) ports. • Access analog trunk gateways Analog trunk gateways connect Unified CM to PSTN central office (CO) or PBX trunks. Trunk gateways provide Foreign Exchange Office (FXO) ports for access to the PSTN, PBXs, or key systems, and E&M (recEive and transMit, or ear and mouth) ports for analog trunk connection to a legacy PBX. Whenever possible, use digital gateways to minimize any answer and disconnect supervision issues. Analog Direct Inward Dialing (DID) and Centralized Automatic Message Accounting (CAMA) are also available for PSTN connectivity. Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) OL-16394-07 4-7

Chapter 4 Gateways Gateway SelectionCisco Access Digital Trunk Gateways A Cisco access digital trunk gateway connects Unified CM to the PSTN or to a PBX via digital trunks such as Primary Rate Interface (PRI), Basic Rate Interface (BRI), or T1 Channel Associated Signaling (CAS). Digital T1 PRI trunks may also be used to connect to certain legacy voice mail systems.Tuning Gateway Gain Settings Connecting a Cisco Unified Communications network to the PSTN through gateways requires that you properly address voice quality issues arising from echo and signal degradation due to power loss, impedance mismatches, delay, and so forth. For this purpose, you must establish a Network Transmission Loss Plan (NTLP), which provides a complete picture of signal loss in all expected voice paths. Using this plan, you can identify locations where signal strength must be adjusted for optimum loudness and effective echo cancellation. Note that not all carriers use the same loss plan, and that the presence of cellular networks adds further complexity in creating the NTLP. Cisco does not recommend adjusting input gain and output attenuation on gateways without first completing such an NTLP. For more information, refer to Echo Analysis for Voice Over IP, available at http://www.cisco.com/en/US/docs/ios/solutions_docs/voip_solutions/EA_ISD.pdfGateway Selection When selecting an IP telephony gateway, consider the following factors: • Core Feature Requirements, page 4-8 • Gateway Protocols, page 4-9 • Gateway Protocols and Core Feature Requirements, page 4-11 • Site-Specific Gateway Requirements, page 4-18Core Feature Requirements Gateways used in IP telephony applications must meet the following core feature requirements: • Dual tone multifrequency (DTMF) relay capabilities DTMF relay capability, specifically out-of-band DTMF, separates DTMF digits from the voice stream and sends them as signaling indications through the gateway protocol (H.323, SCCP, MGCP, or SIP) signaling channel instead of as part of the voice stream or bearer traffic. Out-of-band DTMF is required when using a low bit-rate codec for voice compression because the potential exists for DTMF signal loss or distortion. • Supplementary services support Supplementary services are typically basic telephony functions such as hold, transfer, and conferencing. • Fax/modem support Fax over IP enables interoperability of traditional analog fax machines with IP telephony networks. The fax image is converted from an analog signal and is carried as digital data over the packet network. For more information, see Fax and Modem Support, page 4-27 Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) 4-8 OL-16394-07

Chapter 4 Gateways Gateway Selection • Unified CM redundancy support Cisco Unified Communications is based on a distributed model for high availability. Unified CM clusters provide for Unified CM redundancy. The gateways must support the ability to “re-home” to a secondary Unified CM in the event that a primary Unified CM fails. Redundancy differs from call survivability in the event of a Unified CM or network failure. Refer to the gateway product documentation to verify that any IP Telephony gateway you select for an enterprise deployment can support the preceding core requirements. Additionally, every IP Telephony implementation has its own site-specific feature requirements, such as analog or digital access, DID, and capacity requirements (see Site-Specific Gateway Requirements, page 4-18).Gateway Protocols Cisco Unified CM (Release 3.1 and later) supports the following gateway protocols: • H.323 • Media Gateway Control Protocol (MGCP) Cisco Unified CM Release 4.0 and later supports Session Initiation Protocol (SIP) on the trunk side. The SIP trunk implementation has been enhanced in Cisco Unified CM releases 5.0 through 7.x to support more features. Protocol selection depends on site-specific requirements and the installed base of equipment. For example, most remote branch locations have Cisco 2600XM, 2800, 3700, or 3800 Series routers installed. These routers support SIP, H.323, and MGCP 0.1 with Cisco IOS Release 12.2.11(T) and Cisco Unified CM Release 3.1 or later. For gateway configuration, MGCP might be preferred over H.323 or SIP due to simpler configuration. On the other hand, H.323 or SIP might be preferred over MGCP because of the robustness of the interfaces supported. Simplified Message Desk Interface (SMDI) is a standard for integrating voice mail systems to PBXs or Centrex systems. Connecting to a voice mail system via SMDI and using either analog FXS or digital T1 PRI would require either SCCP or MGCP protocol because H.323 or SIP devices do not identify the specific line being used from a group of ports. Use of H.323 or SIP gateways for this purpose means the Cisco Message Interface cannot correctly correlate the SMDI information with the actual port or channel being used for an incoming call. In addition, the Unified CM deployment model being used can influence gateway protocol selection. (Refer to the chapter on Unified Communications Deployment Models, page 2-1.) Table 4-3 shows which gateways support a given protocol. Each of these protocols follows a slightly different methodology to provide support for the core gateway requirements. Gateway Protocols and Core Feature Requirements, page 4-11, describes how each protocol provides these feature requirements. Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) OL-16394-07 4-9

Chapter 4 Gateways Gateway SelectionTable 4-3 Supported Gateway Protocols and Cisco Unified Communications GatewaysCisco Gateway MGCP 0.1 H.323 SCCP SIPCisco 2900 Yes, beginning with Cisco IOS Yes, beginning with Yes, beginning Yes, Release 15.0.1M Cisco IOS with Cisco IOS SIP trunk Supported with: Release 15.0.1M Release 15.0.1M Supported with: Supported with: • FXS ports • FXS ports • FXS ports • Conferencing and transcoding DSP resources • Conferencing and • Conferencing transcoding DSP and resources transcoding DSP resourcesCisco 3900 Yes, beginning with Cisco IOS Yes, beginning with Yes, beginning Yes, Release 15.0.1M Cisco IOS with Cisco IOS SIP trunk Supported with: Release 15.0.1M Release 15.0.1M Supported with: Supported with: • FXS ports • Conferencing and • FXS ports • FXS ports transcoding DSP resources • Conferencing and • Conferencing transcoding DSP and resources transcoding DSP resourcesCisco 3800 Yes, beginning with Cisco IOS Yes, beginning with Yes for DSP Yes, Release 12.3.11T Cisco IOS Release resources, SIP trunk Supported with: 12.3.11T beginning with Cisco IOS Release • Analog FXS/FXO 12.3.11T. • T1 CAS (E&M Wink Start; For FXS, use Delay Dial only) Cisco IOS Release • T1/E1 PRI 12.4.9.T or later.Cisco 2800 Yes, beginning with Cisco IOS Yes, beginning with Yes for DSP Yes, Release 12.3.8T4 Cisco IOS Release resources, SIP trunk Supported with: 12.3.8T4 beginning with Cisco IOS Release • Analog FXS/FXO 12.3.11T. • T1 CAS (E&M Wink Start; For FXS, use Delay Dial only) Cisco IOS Release • T1/E1 PRI 12.4.9.T or later.Cisco 3700 Yes Yes DSP farm in Yes, Supported with: Cisco IOS Release SIP trunk 12.2.13T • Analog FXS/FXO • T1 CAS (E&M Wink Start; Delay Dial only) • T1/E1 PRI Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) 4-10 OL-16394-07

Chapter 4 Gateways Gateway SelectionTable 4-3 Supported Gateway Protocols and Cisco Unified Communications Gateways (continued)Cisco Gateway MGCP 0.1 H.323 SCCP SIPCommunication Media Yes Yes No Yes,Module (CMM) SIP trunk Supported with: • T1 CAS FXS • T1/E1 PRI • FXSVGD-1T3 T3 with Cisco IOS Yes Yes Yes Release 12.4.22TVG224 Yes Yes, FXS only Yes, beginning Yes, with Cisco IOS FXS only FXS, conferencing, and Release 12.4(2)T transcoding.VG248 No No Yes1 NoCisco ATA 188 Yes, FXS only Yes, FXS only Yes, FXS only Yes, third-party SIP phoneCisco AS5350XM No Yes No Yes, SIP trunkCisco AS5400XMVG202 and VG204 Yes, FXS only beginning with Yes, FXS only Yes, FXS only Yes, FXS Cisco IOS Release 12.4(9th)T beginning with beginning with only Cisco IOS Cisco IOS Release beginning Release 12.4(9th)T 12.4(9th)T with Cisco IOS Release 12.4(9th)T1. The VG248 is not a true gateway in that it uses Skinny Client Control Protocol (SCCP) instead of H.323, MGCP, or SIP. Note Prior to deployment, check the Cisco IOS software release notes to confirm feature or interface support.Gateway Protocols and Core Feature Requirements This section describes how each protocol (SCCP, H.323, MGCP, and SIP) supports the following gateway feature requirements: • DTMF Relay, page 4-12 • Supplementary Services, page 4-13 • Unified CM Redundancy, page 4-16 Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) OL-16394-07 4-11

Chapter 4 Gateways Gateway SelectionDTMF Relay Dual-Tone Multifrequency (DTMF) is a signaling method that uses specific pairs of frequencies within the voice band for signals. A 64 kbps pulse code modulation (PCM) voice channel can carry these signals without difficulty. However, when using a low bite-rate codec for voice compression, the potential exists for DTMF signal loss or distortion. An out-of-band signaling method for carrying DTMF tones across a Voice over IP (VoIP) infrastructure provides an elegant solution for these codec-induced symptoms.SCCP Gateways The Cisco VG248 carries DTMF signals out-of-band using Transmission Control Protocol (TCP) port 2002. Out-of-band DTMF is the default gateway configuration mode for the VG248.H.323 Gateways The H.323 gateways, such as the Cisco 3800 series products, can communicate with Unified CM using the enhanced H.245 capability for exchanging DTMF signals out-of-band. The following is an example out-of-band DTMF configuration on a Cisco IOS gateway: dial-peer voice 100 voip destination-pattern 555…. session target ipv4:10.1.1.1 CODEC g729ar8 dtmf-relay h245-alphanumeric preference 0MGCP Gateway The Cisco IOS-based platforms use MGCP for Unified CM communication. (See Table 4-3 for a list of the Cisco gateway platforms that support MGCP.) Within the MGCP protocol is the concept of packages. The MGCP gateway loads the DTMF package upon start-up. The MGCP gateway sends symbols over the control channel to represent any DTMF tones it receives. Unified CM then interprets these signals and passes on the DTMF signals, out-of-band, to the signaling endpoint. The global configuration command for DTMF relay is: mgcp dtmf-relay CODEC all mode out-of-band You must enter additional configuration parameters in the Unified CM MGCP gateway configuration interface. DTMF relay is enabled by default and does not need additional configuration. Note Use the fm-package command to enable DTMF via RFC 2833, available as of Cisco IOS Release 12.4(6)T.SIP Gateway The Cisco IOS-based platforms can use SIP for Unified CM communication. (See Table 4-3 for a list of the Cisco gateway platforms that support SIP.) They support various methods for DTMF, but only the following methods can be used to communicate with Unified CM: • Named Telephony Events (NTE), or RFC 2833 • Unsolicited SIP Notify (UN) • Key Press Markup Language (KPML) Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) 4-12 OL-16394-07

Chapter 4 Gateways Gateway Selection The following example shows a configuration for NTE: dial-peer voice 100 voip destination-pattern 555…. session target ipv4:10.1.1.1 session protocol sipv2 dtmf-relay rtp-nte The following example shows a configuration for UN: dial-peer voice 100 voip destination-pattern 555…. session target ipv4:10.1.1.1 session protocol sipv2 dtmf-relay sip-notify For more details on DTMF method selection, see the chapter on Media Resources, page 6-1.Supplementary Services Supplementary services provide user functions such as hold, transfer, and conferencing. These are considered fundamental requirements of any voice installation. Each gateway evaluated for use in an IP telephony network should provide support for supplementary services natively, without the use of a software media termination point (MTP).SCCP Gateways The Cisco SCCP gateways provide full supplementary service support. They also support FXS SCCP ports with Cisco IOS Release 12.4.9T. The SCCP gateways use the Gateway-to-Unified CM signaling channel and SCCP to exchange call control parameters. (See Table 4-3 for a list of the Cisco gateway platforms that support SCCP.)H.323 Gateways H.323v2 implements Open/Close LogicalChannel and the emptyCapabilitySet features. The use of H.323v2 by H.323 gateways, beginning in Cisco IOS Release 12.0(7)T and Cisco Unified CM Release 3.0 and later, eliminates the requirement for an MTP to provide supplementary services. With Unified CM Release 3.1 and later, a transcoder is allocated dynamically only if required during a call to provide access to G.711-only devices while still maintaining a G.729 stream across the WAN. Full support for H.323v2 is available in Cisco IOS Release 12.1.1T. Once an H.323v2 call is set up between a Cisco IOS gateway and an IP phone, using the Unified CM as an H.323 proxy, the IP phone can request to modify the bearer connection. Because the Real-Time Transport Protocol (RTP) stream is directly connected to the IP phone from the Cisco IOS gateway, a supported voice codec can be negotiated. Figure 4-1 and the following steps illustrate a call transfer between two IP phones: 1. If IP Phone 1 wishes to transfer the call from the Cisco IOS gateway to Phone 2, it issues a transfer request to Unified CM using SCCP. 2. Unified CM translates this request into an H.323v2 CloseLogicalChannel request to the Cisco IOS gateway for the appropriate SessionID. 3. The Cisco IOS gateway closes the RTP channel to Phone 1. 4. Unified CM issues a request to Phone 2, using SCCP, to set up an RTP connection to the Cisco IOS gateway. At the same time, Unified CM issues an OpenLogicalChannel request to the Cisco IOS gateway with the new destination parameters, but using the same SessionID. Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) OL-16394-07 4-13

Chapter 4 Gateways Gateway Selection 5. After the Cisco IOS gateway acknowledges the request, an RTP voice bearer channel is established between Phone 2 and the Cisco IOS gateway. Figure 4-1 H.323 Gateway Supplementary Service Support Cisco Unified CM Step 1 M Step 2 Phone 1 IP PSTN V Phone 2 IP H.323 gateway Cisco Unified CM M Step 4 Step 3 Phone 1 IP PSTN V Phone 2 IP Step 5 H.323 gateway Skinny Client Control Protocol (SCCP) H.323v2 77299 Voice/RTP pathMGCP Gateway The MGCP gateways provide full support for the hold, transfer, and conference features through the MGCP protocol. Because MGCP is a master/slave protocol with Unified CM controlling all session intelligence, Unified CM can easily manipulate MGCP gateway voice connections. If an IP telephony endpoint (for example, an IP phone) needs to modify the session (for example, transfer the call to another endpoint), the endpoint would notify Unified CM using SCCP. Unified CM then informs the MGCP gateway, using the MGCP User Datagram Protocol (UDP) control connection, to terminate the current RTP stream associated with the Session ID and to start a new media session with the new endpoint information. Figure 4-2 illustrates the protocols exchanged between the MGCP gateway, endpoints, and Unified CM. Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) 4-14 OL-16394-07

Chapter 4 Gateways Gateway Selection Figure 4-2 MGCP Gateway Supplementary Service Support Direct call from MGCP gateway to IP phone. MTP is not required. Cisco Unified CM M Phone 1 IP PSTN V Phone 2 IP MGCP gateway Cisco Unified CM M Phone 1 IP PSTN V IP MGCP Phone 2 gateway The MGCP gateway supports supplementary services such as call transfer. Skinny Client Control Protocol 77300 MGCP Voice pathSIP Gateway The Unified CM SIP trunk interface to Cisco IOS SIP gateways supports supplementary services such as hold, blind transfer, and attended transfer. The support for supplementary services is achieved via SIP methods such as INVITE and REFER. For more details, refer to the following documentation: • Cisco Unified Communications Manager System Guide, available at http://www.cisco.com/en/US/products/sw/voicesw/ps556/prod_maintenance_guides_list.html • Cisco IOS SIP Configuration Guide, available at http://www.cisco.com/en/US/docs/ios/voice/sip/configuration/guide/12_4t/sip_12_4t_book.html Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) OL-16394-07 4-15

Chapter 4 Gateways Gateway SelectionUnified CM Redundancy An integral piece of the IP telephony architecture is the provisioning of 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 Unified CMs. Even in its most simplistic form (a two-system cluster), a secondary Unified CM should be able to pick up control of all gateways initially managed by the primary Unified CM.SCCP Gateways Upon boot-up, the Cisco VG224, VG248, and ATA 188 gateways are provisioned with Unified CM server information. When these gateways initialize, a list of Unified CMs is downloaded to the gateways. This list is prioritized into a primary Unified CM and secondary Unified CM. In the event that the primary Unified CM becomes unreachable, the gateway registers with the secondary Unified CM.H.323 VoIP Call Preservation for WAN Link Failures H.323 VoIP call preservation enhancements for WAN link failures sustain connectivity for H.323 topologies where signaling is handled by an entity that is different from the other endpoint, such as a gatekeeper that provides routed signaling or a call agent (such as the Cisco BTS 10200 Softswitch, Cisco PGW2200 Softswitch, or Cisco Unified CM) that brokers signaling between the two connected parties. Call preservation is useful when a gateway and the other endpoint (typically a Cisco Unified IP Phone) are located at the same site but the call agent is remote and therefore more likely to experience connectivity failures. H.323 call preservation covers the following types of failures and connections. Failure Types: • WAN failures that include WAN links flapping or degraded WAN links. • Cisco Unified CM software failure, such as when the ccm.exe service crashes on a Unified CM server. • LAN connectivity failure, except when a failure occurs at the local branch. Connection Types: • Calls between two Cisco Unified CM controlled endpoints under the following conditions: – During Unified CM reloads. – When a Transmission Control Protocol (TCP) connection used for signaling H.225.0 or H.245 messages between one or both endpoints and Unified CM is lost or flapping. – Between endpoints that are registered to different Unified CMs in a cluster, and the TCP connection between the two Unified CMs is lost. – Between IP phones and the PSTN at the same site. • Calls between a Cisco IOS gateway and an endpoint controlled by a softswitch, where the signaling (H.225.0, H.245 or both) flows between the gateway and the softswitch and media flows between the gateway and the endpoint: – When the softswitch reloads. – When the H.225.0 or H.245 TCP connection between the gateway and the softswitch is lost, and the softswitch does not clear the call on the endpoint. – When the H.225.0 or H.245 TCP connection between softswitch and the endpoint is lost, and the softswitch does not clear the call on the gateway. Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) 4-16 OL-16394-07

Chapter 4 Gateways Gateway Selection • Call flows involving a Cisco Unified Border Element (formerly, Cisco Multiservice IP-to-IP Gateway) running in media flow-around mode that reload or lose connection with the rest of the network. Note that, after the media is preserved, the call is torn down later when either one of the parties hangs up or media inactivity is detected. In cases where there is a machine-generated media stream, such as music streaming from a media server, the media inactivity detection will not work and the call might hang. Cisco Unified CM addresses such conditions by indicating to the gateway that such calls should not be preserved, but third-party devices or the Cisco Unified Border Element would not do this. Flapping is defined for this feature as the repeated and temporary loss of IP connectivity, which can be caused by WAN or LAN failures. H.323 VoIP calls between a Cisco IOS gateway and Cisco Unified CM may be torn down when flapping occurs. When Unified CM detects that the TCP connection is lost, it clears the call and closes the TCP sockets used for the call by sending a TCP FIN, without sending an H.225.0 Release Complete or H.245 End Session message. This is called quiet clearing. The TCP FIN sent from Unified CM could reach the gateway if the network comes up for a short duration, and the gateway will tear down the call. Even if the TCP FIN does not reach the gateway, the TCP keepalives sent from the gateway could reach Unified CM when the network comes up. Unified CM will send TCP RST messages in response to the keepalives because it has already closed the TCP connection. The gateway will tear down H.323 calls if it receives the RST message. Configuration of H.323 VoIP call preservation enhancements for WAN link failures involves configuring the call preserve command. If you are using Cisco Unified Communications Manager, you must enable the Allow Peer to Preserve H.323 Calls parameter from the Service Parameters window. The call preserve command causes the gateway to ignore socket closure or socket errors on H.225.0 or H.245 connections for active calls, thus allowing the socket to be closed without tearing down calls using those connections. Example of H.323 VoIP Call Preservation for All Calls The following configuration example enables H.323 VoIP call preservation for all calls: voice service voip h323 call preserveMGCP Gateway MGCP gateways also have the ability to fail over to a secondary Unified CM in the event of communication loss with the primary Unified CM. When the failover occurs, active calls are preserved. Within the MGCP gateway configuration file, the primary Unified CM is identified using the call-agent <hostname> command, and a list of secondary Unified CM is added using the ccm-manager redundant-host command. Keepalives with the primary Unified CM are through the MGCP application-level keepalive mechanism, whereby the MGCP gateway sends an empty MGCP notify (NTFY) message to Unified CM and waits for an acknowledgement. Keepalive with the backup Unified CMs is through the TCP keepalive mechanism. If the primary Unified CM becomes available at a later time, the MGCP gateway can “re-home,” or switch back to the original Unified CM. This re-homing can occur either immediately, after a configurable amount of time, or only when all connected sessions have been released. This is enabled through the following global configuration commands: ccm-manager redundant-host <hostname1 | ipaddress1 > <hostname2 | ipaddress2> [no] call-manager redundancy switchback [immediate|graceful|delay <delay_time>] Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) OL-16394-07 4-17

Chapter 4 Gateways Gateway SelectionSIP Gateway Redundancy with Cisco IOS SIP gateways can be achieved similarly to H.323. If the SIP gateway cannot establish a connection to the primary Unified CM, it tries a second Unified CM defined under another dial-peer statement with a higher preference. By default the Cisco IOS SIP gateway transmits the SIP INVITE request 6 times to the Unified CM IP address configured under the dial-peer. If the SIP gateway does not receive a response from that Unified CM, it will try to contact the Unified CM configured under the other dial-peer with a higher preference. Cisco IOS SIP gateways wait for the SIP 100 response to an INVITE for a period of 500 ms. By default, it can take up to 3 seconds for the Cisco IOS SIP gateway to reach the backup Unified CM. You can change the SIP INVITE retry attempts under the sip-ua configuration by using the command retry invite <number>. You can also change the period that the Cisco IOS SIP gateway waits for a SIP 100 response to a SIP INVITE request by using the command timers trying <time> under the sip-ua configuration. One other way to speed up the failover to the backup Unified CM is to configure the command monitor probe icmp-ping under the dial-peer statement. If Unified CM does not respond to an Internet Control Message Protocol (ICMP) echo message (ping), the dial-peer will be shut down. This command is useful only when the Unified CM is not reachable. ICMP echo messages are sent every 10 seconds. The following commands enable you to configure Unified CM redundancy on a Cisco IOS SIP gateway: sip-ua retry invite <number> timers trying <time> dial-peer voice 101 voip destination-pattern 2... session target ipv4:10.1.1.101 preference 0 monitor probe icmp-ping session protocol sipv2 dial-peer voice 102 voip destination-pattern 2... session target ipv4:10.1.1.102 preference 1 monitor probe icmp-ping session protocol sipv2Site-Specific Gateway Requirements Each IP Telephony implementation has its own site-specific requirements. The following questions can help you with IP Telephony gateway selection: • Is the PSTN (or PBX) access analog or digital? • What type of analog (FXO, FXS, E&M, DID, CAMA) or digital (T1, E1, CAS, CCS) interface is required for the PSTN or PBX? • If the PSTN access is digital, what type of signaling is required (T1 CAS, Q.931 PRI, E1 CAS, or R2)? Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) 4-18 OL-16394-07

Chapter 4 Gateways Gateway Selection • What type of signaling does the PBX currently use? – FXO or FXS: loop start or ground start – E&M: wink-start, delay-start, or immediate-start – E&M: type I, II, III, IV, or V – T1: CAS, Q.931 PRI (User-Side or Network-Side), QSIG, DPNSS, or Proprietary d-channel (CCS) signaling – E1: CAS, R2, Q.931 PRI (User-Side or Network-Side), QSIG, DPNSS, Proprietary d-channel (CCS) signaling • What type of framing (SF, ESF, or G.704) and line encoding (B8ZS, AMI, CRC-4, or HDB3) does the PBX currently use? • Does the PBX require passing proprietary signaling? If so, which time slot is the signaling passed on, and is it HDLC-framed? • What is the required capacity of the gateway; that is, how many channels are required? (Typically, if 12 or more voice channels are required, then digital is more cost effective than an analog solution.) • Is Direct Inward Dialing (DID) required? If so, specify analog or digital. • Is Calling Line ID (CLID) needed? • Is Calling Name needed? • What types of fax and modem support are required? • What types of voice compression are required? • What types of supplementary services are required? • Will the PBX provide clocking, or will it expect the Cisco gateway to provide clocking? • Is rack space available for all needed gateways, routers, and switches? Note Direct Inward Dial (DID) refers to a private branch exchange (PBX) or Centrex feature that permits external calls to be placed directly to a station line without use of an operator. Note Calling Line Identification (CLI, CLID, or ANI) refers to a service available on digital phone networks to display the calling number to the called party. The central office equipment identifies the phone number of the caller, enabling information about the caller to be sent along with the call itself. CLID is synonymous with Automatic Number Identification (ANI). Cisco Unified Communications gateways are able to inter-operate with most major PBX vendors, and they are EIA/TIA-464B compliant. The site-specific and core gateway requirements are a good start to help narrow the possible choices. Once you have defined the required features, you can make a gateway selection for each of the pertinent configurations, whether they are single-site enterprise deployments of various sizes and complexities or multisite enterprise deployments. The following tables summarize the features and interface types supported by the various Cisco gateway models. Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x)OL-16394-07 4-19

Chapter 4 Gateways Gateway Selection Note In the following tables, the Cisco IOS and Unified CM release numbers refer to the minimum release that can support the listed feature on a particular gateway platform. For more information about Cisco IOS features, refer to the Cisco Feature Navigator located at http://tools.cisco.com/ITDIT/CFN/jsp/index.jsp. Cisco Analog Gateways Table 4-4 lists supported interface types for Cisco analog gateways using H.323 or Session Initiation Protocol (SIP), and Table 4-5 lists supported interface types for Cisco analog gateways using Media Gateway Control Protocol (MGCP).Table 4-4 Supported Analog H.323 and SIP Features Interface Type FXO, BatteryCisco Gateway FXS FXO E&M Reversal Analog DID CAMA 9113900 Series Yes Yes Yes Yes Yes Yes2900 Series Yes Yes Yes Yes Yes YesVG202 and VG204 Yes No No No No No8800 Series Yes Yes No Yes No No3800 Series Yes Yes Yes Yes Yes Yes2800 Series Yes Yes Yes Yes Yes Yes 13700 Series Yes Yes Yes Yes Yes YesCommunication Media Yes N/A N/A N/A N/A N/AModule (CMM) 24FXSCMM-6T1/E1 N/A N/A N/A N/A N/A N/AVG224 Yes N/A N/A N/A N/A N/AVG248 No No No No No NoAnalog Telephone Adapter Yes No No No No No(ATA)17x00 family N/A N/A N/A N/A N/A N/A1. These models have reached End of Sale (EOS). Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) 4-20 OL-16394-07

Chapter 4 Gateways Gateway SelectionTable 4-5 Supported Analog MGCP Features Interface Type FXO, BatteryCisco Gateway FXS FXO E&M Reversal Analog DID CAMA 9113900 Series Yes Yes No Yes No No2900 Series Yes Yes No Yes No NoVG202 and VG204 Yes No No No No No8800 Series Yes Yes No Yes No No3800 Series Yes Yes No Yes No No2800 Series Yes Yes No Yes No No 13700 Series Yes Yes No Yes No NoCommunication Media Yes N/A N/A N/A N/A N/AModule (CMM) 24FXSCMM-6T1/E1 N/A N/A N/A N/A N/A N/AVG224 Yes No No No No NoVG248 No No No No No NoAnalog Telephone Adapter Yes N/A N/A N/A N/A N/A(ATA)17x00 family N/A N/A N/A N/A N/A N/A1. These models have reached End of Sale (EOS). Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) OL-16394-07 4-21

Chapter 4 Gateways Gateway Selection Cisco Digital Gateways Table 4-6 through Table 4-9 list supported interface types for Cisco digital gateways using H.323 or Session Initiation Protocol (SIP). Table 4-10 lists supported interface types for Cisco digital gateways using Media Gateway Control Protocol (MGCP).Table 4-6 Supported Digital H.323 and SIP Features for BRI, T1 CAS, T1 FGB, T1 FGD, and T1 QSIG Interface Type BRI (NT, T1 CAS BRI (TE, Network BRI QSIG BRI (RobbedCisco Gateway User side) side) (Net3) Phones bit) T1 FGB T1 FGD T1 QSIG3900 Series Yes Yes Yes No Yes No Yes Yes2900 Series Yes Yes Yes No Yes No Yes Yes3800 Series Yes Yes Yes No Yes No Yes Yes2800 Series Yes Yes Yes No Yes No Yes Yes3700 Series1 Yes Yes Yes No Yes No Yes Yes5400XM No No No No Yes Yes Yes YesCommunication Media N/A N/A N/A N/A N/A N/A N/A N/AModule (CMM) 24FXSCMM-6T1/E1 N/A N/A N/A N/A Yes No No YesVG224 N/A N/A N/A N/A N/A N/A N/A N/AVG248 No No No No No No No NoAnalog Telephone Adapter No No No No No No No No(ATA)17x00 family N/A N/A N/A N/A Yes No Yes Yes1. These models have reached End of Sale (EOS). Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) 4-22 OL-16394-07

Chapter 4 Gateways Gateway SelectionTable 4-7 Supported Digital H.323 and SIP Features for T1 PRI SL-1, 4ESS, and 5ESS Interface Type T1 PRI T1 PRI T1 PRI T1 PRI (User, (Network, T1 PRI (User, (Network, T1 PRI (User, (Network,Cisco Gateway DMS-100) SL-1) 4ESS) 4ESS) 5ESS) 5ESS)3900 Series Yes No Yes Yes Yes Yes2900 Series Yes No Yes Yes Yes Yes3800 Series Yes No Yes Yes Yes Yes2800 Series Yes No Yes Yes Yes Yes 13700 Series Yes No Yes No Yes No5400XM Yes No Yes Yes Yes YesCommunication Media N/A N/A N/A N/A N/A N/AModule (CMM) 24FXSCMM-6T1/E1 Yes Yes Yes Yes Yes YesVG224 N/A N/A N/A N/A N/A N/AVG248 No No No No No NoAnalog Telephone Adapter No No No No No No(ATA)17x00 family Yes No Yes No Yes No1. These models have reached End of Sale (EOS). Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) OL-16394-07 4-23

Chapter 4 Gateways Gateway SelectionTable 4-8 Supported Digital H.323 and SIP Features for T1 PRI NI2, NFAS, and Network Specific Facilities (NSF) Service Interface Type T1 PRI T1 PRI NFAS T1 PRI T1 PRI (User, (Network, (User, T1 PRI NFAS T1 PRI NFAS (Megacom orCisco Gateway NI2) NI2) DMS-100) (User, 4ESS) (User, 5ESS) SDN, 4ESS)3900 Series Yes Yes Yes Yes Yes Yes2900 Series Yes Yes Yes Yes Yes Yes3800 Series Yes Yes Yes Yes Yes Yes2800 Series Yes Yes Yes Yes Yes Yes 13700 Series Yes Yes Yes Yes Yes Yes5400XM Yes Yes Yes Yes Yes YesCommunication Media N/A N/A N/A N/A N/A N/AModule (CMM) 24FXSCMM-6T1/E1 Yes Yes Yes Yes Yes NoVG224 N/A N/A N/A N/A N/A N/AVG248 No No No No No NoAnalog Telephone Adapter No No No No No No(ATA)17x00 family Yes Yes No No No No1. These models have reached End of Sale (EOS).Table 4-9 Supported Digital H.323 and SIP Features for E1 and J1 Interface Type E1 PRI E1 PRI (User (NetworkCisco Gateway E1 CAS E1 MELCAS E1 R2 side, Net5) side, Net5) E1 QSIG J113900 Series Yes Yes Yes Yes Yes Yes No2900 Series Yes Yes Yes Yes Yes Yes No3800 Series Yes Yes Yes Yes Yes Yes Yes2800 Series Yes Yes Yes Yes Yes Yes Yes 23700 Series Yes Yes Yes Yes Yes Yes YesCommunication Media N/A N/A N/A N/A N/A N/A N/AModule (CMM) 24FXSCMM-6T1/E1 No No Yes Yes Yes Yes N/AVG224 N/A N/A N/A N/A N/A N/A N/AVG248 No No No No No No NoAnalog Telephone Adapter No No No No No No No(ATA)27x00 family Yes No Yes Yes Yes Yes No Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) 4-24 OL-16394-07

Chapter 4 Gateways Gateway Selection1. This interface type has reached End of Sale (EOS).2. These models have reached End of Sale (EOS).Table 4-10 Supported Digital MGCP Features Interface Type T1 CAS T1 CASCisco Gateway BRI1 (E&M) Hookflash T1 PRI T1 QSIG E1 PRI E1 QSIG T3 2 2 2 2 23900 Series 15.0.1M Yes Yes Yes Yes Yes Yes No 2 2 2 2 22900 Series 15.0.1M Yes Yes Yes Yes Yes Yes No 2 2 2 2 23800 Series 12.4(2)T Yes Yes Yes Yes Yes Yes No 2 2 2 2 22800 Series 12.4(2)T Yes Yes for Yes Yes Yes Yes No 2811, 2821, 28513700 Series3 12.4(2)T Yes2 Yes Yes2 Yes2 Yes2 Yes2 NoVGD-1T3 No No No No No No No YesCommunication Media N/A N/A Yes N/A N/A N/A N/A NoModule (CMM) 24FXSCMM-6T1/E1 N/A Yes Yes Yes Yes Yes Yes NoVG224 N/A N/A N/A N/A N/A N/A N/A NoVG248 N/A N/A N/A N/A N/A N/A N/A NoAnalog Telephone Adapter N/A N/A N/A N/A N/A N/A N/A No(ATA)37x00 family N/A No N/A No No No No No1. Cisco IOS Release 12.4(2)T supports BRI MGCP with the following hardware: NM-HDV2, NM-HD-XX and on-board H-WIC slots. BRI MGCP is also supported on older Cisco IOS releases with NM-1V/2V hardware.2. AIM-VOICE-30 modules require Cisco IOS Release 12.2.13T to support MGCP.3. These models have reached End of Sale (EOS). Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) OL-16394-07 4-25

Chapter 4 Gateways QSIG SupportQSIG Support QSIG is a suite of international standards designed to provide flexibility in connecting PBX equipment to a corporate network. Among its other features, QSIG provides an open, standards-based method for interconnecting PBX equipment from different vendors. ECMA QSIG is currently supported in H.323 gateways in PBX-to-PBX mode. The H.323 gateways provide full QSIG feature transparency for QSIG information elements. Basic call setup and teardown are supported using H.323 QSIG gateways, as summarized in Table 4-11. Table 4-11 QSIG Support on H.323 Gateways Minimum Cisco IOS Software Platform Media Release Required Cisco 3900 Series BRI and T1/E1 QSIG 15.0.1M Cisco 2900 Series BRI and T1/E1 QSIG 15.0.1M Cisco 3800 Series BRI and T1/E1 QSIG 12.3.11T Cisco 2800 Series BRI and T1/E1 QSIG 12.3.8T4 1 Cisco 3700 T1/E1 QSIG 12.2.8T Cisco AS5350XM T1/E1 12.2.2T Cisco AS5400XM 1. These models have reached End of Sale (EOS). For more information on QSIG support on Cisco IOS gateways, refer to the documentation at http://www.cisco.com/en/US/docs/ios/12_1t/12_1t2/feature/guide/dt_qsig.html Prior to Cisco Unified CM Release 3.3, basic PRI functionality is all that is provided whenever a PBX is connected to a gateway using QSIG via H.323 and calls are made between phones on the PBX and IP phones attached to the Unified CM. This basic functionality, which includes only the Calling Line Identifier (CLID) and Direct Inward Dialed (DID) number, is provided by the gateway terminating the QSIG protocol rather than by Unified CM. For Unified CM to support QSIG functionality, QSIG must be back-hauled directly to Unified CM. This support is provided in Cisco Unified CM 3.3 and later releases, in conjunction with all MGCP T1/E1 ISDN gateways. Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) 4-26 OL-16394-07

Chapter 4 Gateways Fax and Modem SupportFax and Modem Support This section describes the fax and modem support available with Unified CM and Cisco voice gateways. This section first presents brief overviews of fax and modem support on Cisco voice gateways, followed by a listing of supported platforms and example configuration files.Gateway Support for Fax Passthrough and Fax Relay Fax over IP enables interoperability of traditional analog fax machines with IP Telephony networks. The fax image is converted from an analog signal and is carried digitally over the packet network. In its original form, fax data is digital and is contained in High-Level Data Link Control (HDLC) frames. However, to transmit across a traditional PSTN, these digital HDLC frames are modulated onto an analog carrier. While this analog carrier is necessary for effective faxing in PSTN environments, it is not ideal for the type of digital transport used by IP packet networks. Therefore, specific transport methods have been devised for successful transport of fax transmissions over an IP infrastructure. The two main methods for transporting fax over IP are passthrough and relay. Passthrough is the simplest method, and it works by sampling and digitizing the analog fax signal just like a voice codec does for human speech. While there are a number of codecs available, passthrough always uses the G.711 codec for carrying fax information because it offers the least distortion of the analog fax signals. If a high-compression codec is being used by the original voice call, then passthrough uses an upspeed feature to change the codec to G.711. Passthrough is also commonly referred to as Voice Band Data (VBD), and Cisco provides two versions of passthrough: modem passthrough and fax passthrough. Modem passthrough uses Cisco proprietary Named Signaling Event (NSE) packets to switch the call from voice mode to passthrough mode. This switchover from voice mode to passthrough is an important concept for passthrough and relay as well. Every call on a Cisco voice gateway starts out as a voice call, and the proper switchover occurs only when the gateway determines that the call is truly a fax call. While modem passthrough uses NSE packets for its switchover, other fax and modem transport methods may implement different mechanisms. Despite its name, modem passthrough is also widely used for fax calls. Modem passthrough is also referred to as NSE-based passthrough, and you can activate it in the Cisco IOS command line interface (CLI) by using the modem passthrough command. Fax passthrough is also referred to as protocol-based passthrough because it relies on the underlying call control protocol to switch the call from voice mode to passthrough. Fax passthrough works only with the call control protocols of H.323 and SIP. Because fax passthrough utilizes the call control protocol for its switchover, this is the only passthrough solution that can work with third party devices. Figure 4-3 highlights the two different passthrough implementations employed by Cisco voice gateways for fax calls. Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) OL-16394-07 4-27

Chapter 4 Gateways Fax and Modem Support Figure 4-3 Cisco Passthrough Implementations for Fax Calls Voice Mode NSE-based Protocol-based Switchover Switchover Modem Fax Passthrough Passthrough 270425 Fax Passthrough Relay is the other main method for transporting fax over IP, and its implementation is a bit more complicated than passthrough. Relay strips off the analog carrier from the fax signal in a process known as demodulation to expose the fax HDLC data frames. The pertinent information in these HDLC frames is then removed and efficiently packaged in a fax relay protocol to be transported to the gateway on the other side. Once received on the other side, the fax information is pulled from the relay protocol, reconstructed back into fax HDLC frames, and modulated onto an analog carrier for transmission to a fax machine. Cisco supports two versions of fax relay, T.38 and Cisco fax relay. An ITU standard, T.38 allows Cisco gateways to interoperate with third-party devices that also support the T.38 specification. In most scenarios, T.38 fax relay uses the call control protocol to switch from voice mode to T.38 fax relay mode, and this is referred to as protocol-based T.38 fax relay. However, it is also possible to configure T.38 fax relay to switch over using Cisco proprietary NSEs in what is termed NSE-based T.38 fax relay. In order to ensure third-party interoperability, protocol-based T.38 must be utilized. Cisco fax relay is a pre-standard implementation, and it is proprietary to Cisco voice gateways. It is also the default fax transport configuration on nearly all Cisco voice gateways. Unlike the NSE or protocol-based methods used by T.38 fax relay and passthrough, Cisco fax relay transitions from voice to relay mode utilizing specific RTP dynamic payload types (PT). Figure 4-4 illustrates the Cisco fax relay methods. Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x)4-28 OL-16394-07

Chapter 4 Gateways Fax and Modem Support Figure 4-4 Cisco Relay Implementations for Fax Calls Voice Mode Protocol-based NSE-based RTP PT Switchover Switchover Switchover T.38 T.38 Cisco Fax Relay Fax Relay Fax Relay 270426 Fax Relay Fax relay mode, and more specifically T.38, is the preferred method to transport fax traffic. However, if T.38 fax relay is not supported, then Cisco fax relay or passthrough can be used as an alternative.Best Practices The following recommendations and guidelines can assist you in best implementing fax support on Cisco voice gateways: • When using QoS, make every effort to minimize the following: – Packet loss – Delay – Delay variation (jitter) Fax transmissions are extremely sensitive to packet loss. Even minimal packet loss can cause fax failures. If packet loss is a problem in your network, then the redundancy feature in T.38 fax relay should be used. Also, ensure that constant packet delay on the network does not exceed 1 second and that delay variation (jitter) does not exceed 300 milliseconds. For detailed information about implementing QoS in a Cisco Unified Communications network, refer to the Enterprise QoS Solution Reference Network Design Guide, available at http://www.cisco.com/go/designzone • The following tips can help ensure the integrity of the fax calls: – Use call admission control (CAC) to ensure that calls are not admitted if they exceed the specified total bandwidth limit. – Disable call waiting on all dedicated modem and fax ports. • T.38 fax relay provides the best fax performance based on network considerations and is the recommended transport method for fax traffic. To insure interoperability with other vendors T.38 products, use protocol-based T.38. NSE-based T.38 must be used for communicating with certain Cisco voice gateways, such as the Cisco VG248 and any Cisco IOS SCCP gateways. Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) OL-16394-07 4-29

Chapter 4 Gateways Fax and Modem Support In Unified CM scenarios where T.38 is to be deployed among gateways running a variety of call signaling protocols, protocol-based T.38 should be the first choice. Beginning with Cisco Unified CM Release 6.0, Unified CM supports protocol-based T.38 with H.323, SIP, and MGCP call control protocols. If protocol-based T.38 is not supported in your installed version of Cisco Unified CM or if SCCP gateways are involved, then NSE-based T.38 should be used. To verify if your version of Unified CM supports protocol-based T.38, refer to the Cisco Unified Communications Manager release notes available at http://www.cisco.com/en/US/products/sw/voicesw/ps556/prod_release_notes_list.html • T.38 fax relay is supported on most of the current Cisco voice gateways, especially those running Cisco IOS. Notable exceptions are the Cisco Analog Telephone Adaptors (ATAs) and legacy products such as the Cisco 6608, 6624, and DT-24/DE-30+. Most Cisco voice gateways support Cisco fax relay, and it is the default fax transport method. Notable exceptions with regard to the support of Cisco fax relay are the Cisco AS5350 and AS5400 with Nextport DSP cards, the Cisco ATA, and the Cisco DT-24/DE-30+. Another exception is that the Cisco 2900 and 3900 Series gateways with the PVDM3 DSPs do not support Cisco fax relay. Unlike T.38 fax relay, which uses an Unnumbered Datagram Protocol Transport Layer (UDPTL) header, Cisco fax relay utilizes the standard RTP header, which makes Cisco fax relay capable of secure fax transactions using Secure Real-Time Transport Protocol (SRTP). Modem passthrough is supported by all current Cisco voice gateways, including the Cisco ATA as well as most legacy voice gateways. Because modem passthrough uses a Cisco proprietary NSE-based switchover, it is not compatible with other vendors equipment. However, fax passthrough with its protocol-based switchover should interoperate with most third-party devices if a passthrough solution is necessary. Fax passthrough is supported only on Cisco IOS voice gateways that use the H.323 and SIP protocols. • Most fax machines appear to accept packet drop in the range of 0.4% to 0.6% without slowing down to the next speed. However, in a network with packet drop in the range of 0.8% to 1%, you should disable Error Correction Mode (ECM). • You can disable ECM on the gateway itself rather than disabling it on multiple fax machines. However, if packet drops occur, the fax image quality might deteriorate. Therefore, you should disable ECM only after considering whether you want to risk compromising image quality rather than experiencing longer call durations or dropped calls. You should also monitor and evaluate the network to identify and resolve the cause of the dropped packets.Super-Group 3 Fax Support Cisco IOS gateways with Cisco IOS Release 12.4.4T support Super-Group 3 (SG3) fax; however, only Group 3 speeds are negotiated. Beginning with Cisco IOS Release 15.0.1M, SG3 fax is supported natively. For more information on this feature, refer to Fax Relay Support for SG3 Fax Machines at G3 Speeds, available at http://www.cisco.com/en/US/products/ps6441/products_feature_guide09186a00805138e5.html If it is necessary to transport SG3 high-speed faxes at their native speeds, then modem passthrough must be used. Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) 4-30 OL-16394-07

Chapter 4 Gateways Fax and Modem SupportGateway Support for Modem Passthrough and Modem Relay In general, there are three mechanisms for supporting modem sessions over an IP network using voice gateways: • Modem passthrough • Cisco Modem Relay • Secure Modem Relay (Secure Communication Between STE Endpoints) Each of these mechanisms can transport modem calls, but the relay methods are restrictive in that only certain modem modulations are supported. Modem passthrough, on the other hand, can handle any modulation. An important concept to understand when dealing with the transport of modem signals across IP networks is the switchover that must occur on the gateway. Every call on a Cisco gateway begins as a voice call initially. Even if the call is between modems, the call will be set up as a voice call first. Then, once the gateway is sure that the call is truly a modem call, a switchover occurs that converts the gateway from voice call mode to a modem passthrough or modem relay mode. There are various switchover methods to transition a call from voice mode to modem passthrough or relay. As discussed previously in the section on Gateway Support for Fax Passthrough and Fax Relay, page 4-27, modem passthrough uses proprietary NSE packets to switch a voice call into passthrough mode. When modem signals are detected, the gateways use these NSE messages to inform each other of the impending modem call. The gateways then make adjustments to better handle the transport of the modem signals. These adjustments include upspeeding the voice codec to G.711, disabling Voice Activity Detection (VAD), and disabling the echo cancellers if necessary. Because modem passthrough simply samples the analog modem signal using the G.711 codec, it should handle any modem modulation, but not always at the highest speeds. Cisco Modem Relay is a proprietary implementation that efficiently transports V.34 modem calls over an IP network. V.90 calls are also supported, but they are forced to train down to V.34 speeds. As with modem passthrough, NSE packets are used to handle the switchover to Cisco Modem Relay from voice mode. Secure modem relay, which is also referred to as Secure Communication Between STE Endpoints, allows for the transport of secure telephone calls over an IP infrastructure. Special devices known as Secure Terminal Equipment (STE) transmit encrypted voice using the V.32 modulation. Secure modem relay is designed to handle the transport of information between STEs in Unified CM environments with SCCP and MGCP gateways. Secure modem relay is not compatible with Cisco Modem Relay. One of the main reasons is that the switchover for secure modem relay does not use NSEs but instead uses V.150.1-based State Signaling Event (SSE) messages. Secure modem relay is designed specifically for transporting STE signals and is almost never used outside of government or defense-related deployments. In most cases, Cisco Modem Relay or modem passthrough should be used for transporting modem calls. For more information on secure modem relay, refer to Secure Communication Between IP-STE Endpoint and Line-Side STE Endpoint, available at http://www.cisco.com/en/US/products/ps6441/products_feature_guide09186a0080513c09.html Figure 4-5 summarizes the Cisco modem transport implementations. Modem relay should be used whenever possible because it offers the most bandwidth efficiency and tolerance for network impairments when compared to modem passthrough. The disadvantage of modem relay is that it is quite restrictive on the modulations supported, while modem passthrough can handle any modem modulation. Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) OL-16394-07 4-31

Chapter 4 Gateways Fax and Modem Support Figure 4-5 Cisco Passthrough and Relay Implementations for Modem Calls Voice Mode NSE-based SSE-based Switchover NSE-based Switchover Switchover Modem Cisco Secure Passthrough Modem Relay Modem Relay 270427 Modem Passthrough and RelayBest Practices Observe the following recommended best practices to ensure optimum performance of modem traffic transported over an IP infrastructure: • Ensure that the IP network is enable for Quality of Service (QoS) and that you adhere to all of the recommendations for providing QoS in the LAN, MAN, and WAN environments. Every effort should be made to minimize the following parameters: – Packet loss — Fax and modem traffic requires an essentially loss-free transport. A single lost packet will result in retransmissions. – Delay – Delay variation (jitter) For more information, refer to the Enterprise QoS Solution Reference Network Design Guide, available at http://www.cisco.com/go/designzone • Use call admission control (CAC) to ensure that calls are not admitted if they exceed the specified total bandwidth limit. • Use modem relay whenever possible. Modem passthrough should be used for any modulations not supported by modem relay. • Do not use the IP network to connect modems that will be used to troubleshoot or diagnose problems with the IP network. In this case, the modems used to troubleshoot the devices that compose the IP infrastructure should be connected to a plain old telephone service (POTS). • Because of the NSE switchover utilized by Cisco modem relay and modem passthrough, gateways using different call control protocols can easily communicate with one another. For example, an MGCP gateway and an H.323 gateway connected to Unified CM can successfully negotiate Cisco modem relay or modem passthrough because the NSE switchover occurs within the RTP voice media stream that has already been set up by Unified CM. • Disable call waiting on all dedicated modem and fax ports. Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) 4-32 OL-16394-07

Chapter 4 Gateways Fax and Modem SupportV.90 Support Currently, Cisco equipment supports only V.34 modems. Although V.90 modems will function on existing hardware, and speeds higher than V.34 speeds can be achieved, full V.90 support cannot be guaranteed.Supported Platforms and Features The following Cisco platforms support fax and modem features: • Cisco IOS Gateways support: – Modem passthrough – Fax passthrough for the H.323 and SIP protocols – T.38 fax relay. Both NSE and protocol-based switchovers for T.38 are supported, except in the case of SCCP where only NSE-based T.38 fax relay is supported. – Cisco fax relay. The Cisco AS5350, AS5400, and AS5850 using Nextport DSP cards do not support Cisco fax relay, and neither do the Cisco 2900 and 3900 Series using PVDM3 DSPs. – Cisco modem relay • Cisco non-IOS gateways: – The Cisco VG248 supports modem passthrough, NSE-based T.38 fax relay, and Cisco fax relay. – The Cisco 6608 and 6624 support only modem passthrough and Cisco fax relay. – The Cisco ATAs support modem passthrough for fax calls only. Using modem passthrough with an ATA for modem calls is not officially supported. Note The fax and modem support information presented here is valid beginning with Cisco IOS Release 12.4(9)T for the Cisco IOS gateways and Release 1.3.1 of the Cisco VG248 Analog Phone Gateway.Platform Protocol Support Common call control protocols used today in enterprise solutions include H.323, Session Initiation Protocol (SIP), Media Gateway Control Protocol (MGCP), and Skinny Client Control Protocol (SCCP). Not all Cisco voice platforms support all of these protocols or all of the fax and modem features, thus raising interoperability issues. Additional interoperability issues occur when mixing Cisco IOS gateways, such as the Cisco 2800 Series or the Cisco 3800 Series, with non-IOS gateways such as the VG248. This section lists the combinations of gateways that provide support for interoperability of fax, modem, and protocol features. Some of the common combinations of protocols in a network include: MGCP and H.323; SCCP and H.323; SCCP and SIP; MGCP and SIP; H.323 and SIP; and SCCP and MGCP. Common voice gateways included the Cisco VG224, VG248, 2600XM, 2800, 3700, 3800, and Catalyst 6000. Table 4-12 lists the protocol combinations that currently support fax and modem interoperability. Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) OL-16394-07 4-33

Chapter 4 Gateways Fax and Modem SupportTable 4-12 Fax and Modem Features Supported with Various Combinations of Call Control Protocols Modem Cisco Fax FaxProtocol Combinations Modem Relay Passthrough1 T.38 Fax Relay Relay PassthroughUnified CM using MGCP combined Yes Yes Yes2 Yes Yeswith Unified CM using H.323 or SIPUnified CM using MGCP combined Yes Yes Yes2 Yes Yeswith Unified CM using MGCPSCCP combined with Unified CM Yes Yes Yes3 Yes Yesusing H.323 or SIPSCCP combined with Unified CM Yes Yes Yes3 Yes Yesusing MGCPUnified CM using H.323 combined Yes Yes Yes2 Yes Yeswith H.323 or SIPUnified CM using SIP combined with Yes Yes Yes2 Yes YesH.323 or SIP1. Modem passthrough works for both modem and fax passthrough calls.2. NSE-based T.38 fax relay works, but protocol-based T.38 fax relay depends on the version of Unified CM. For version information, refer to the Cisco Unified Communications Manager release notes available at http://www.cisco.com/en/US/products/sw/voicesw/ps556/prod_release_notes_list.html.3. SCCP protocol works only with NSE-based T.38 fax relay. Note Table 4-12 is a general reference. You should be aware that specific products might have limitations that are not listed in this table. For example, the Cisco ATA supports H.323, SIP, and SCCP call control protocols, but only modem passthrough is supported no matter which call control protocol is used.Gateway Configuration Examples This section provides a quick configuration overview for fax and modem support on Cisco gateways. More detailed configuration information can be found in the Cisco IOS Fax and Modem Services over IP Application Guide, which is available to Cisco employees and partners (with appropriate login authentication) at http://www.cisco.com/en/US/partner/products/sw/iosswrel/ps5207/products_configuration_guide_ book09186a0080762024.html Cisco fax relay is enabled by default on all voice gateways that support it. It must be disabled explicitly or it will attempt to transport any fax call that is detected by the voice gateway. If a feature such as modem passthrough is going to be used to transport fax calls, then Cisco fax relay can be disabled on Cisco IOS gateways by configuring fax protocol none under the dial-peer or globally under voice service voip. In many cases, however, it might be optimal to keep Cisco fax relay enabled to handle fax calls while configuring modem passthrough to handle high-speed modem calls and SG3 fax calls. Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) 4-34 OL-16394-07

Chapter 4 Gateways Fax and Modem SupportCisco IOS Gateway Configuration for Modem Passthrough Modem passthrough can be enabled for H.323 and MGCP gateways as shown in the following examples. SIP gateways use the same command as shown in the H.323 example. Also, for both H.323 and SIP voice gateways, modem passthrough can be enabled globally for all dial peers under voice service voip. H.323 ! ! Cisco fax relay is ON by default !(except for 5350/5400, where Cisco fax relay is not supported) ! dial-peer voice 1000 voip destination-pattern 1T session target ipv4:10.10.10.1 modem passthrough mode nse codec g711ulaw ! ! MGCP ! ccm-manager mgcp mgcp mgcp call-agent 10.10.10.1 service-type mgcp version 0.1 mgcp modem passthrough voip mode nse mgcp fax t38 inhibit ! dial-peer voice 100 pots application mgcpapp port 1/0/0 !Cisco VG248 Configuration for Modem Passthrough The Cisco VG248 also handles both Cisco fax relay and modem passthrough, with Cisco fax relay being enabled by default. Cisco fax relay can be enabled or disabled from the "Port specific parameters" section of the VG248s telephone configuration. When configuring modem passthrough on the VG248, two important parameters need to be configured. First, under Port specific parameters, the Passthrough mode must be set to default: automatic. Second, under the Telephony Advanced settings, the Passthrough signalling must be set to IOS mode, as shown below. ----------------------------------------------------------- | Cisco VG248 (VGC10d8002407) | ----- ----------------------------------------------------- | Advanced settings | |-----------------------------------------------------| | Allow last good configuration (enabled) | | SRST policy (disabled) | | SRST provider () | | Call preservation (enabled: no timeout) | | Media receive timeout (disabled) | | Busy out off hook ports (disabled) | | DTMF tone dur ------------------------ 100ms) | | Echo cancelli| Passthrough signalling |e: use DSP) | | Passthrough s|------------------------|) | | Hook flash ti| legacy | default>) | Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) OL-16394-07 4-35

Chapter 4 Gateways Fax and Modem Support | Hook flash re| IOS mode | | | Fax relay max ------------------------ 14400 bps) | | Fax relay playout delay (default: 300) | ----------------------------------------------------- ------------------------------------------------- ----------------------------------------------------------- | Cisco VG248 (VGC10d8002407) | ----- ----------------------------------------------------- | Advanced settings | |-----------------------------------------------------| | Allow last good configuration (enabled) | | SRST policy (disabled) | | SRST provider () | | Call preservation (enabled: no timeout) | | Media receive timeout (disabled) | | Busy out off hook ports (disabled) | | DTMF tone duration (default: 100ms) | | Echo cancelling policy (alternate: use DSP) | | Passthrough signalling (IOS mode) | | Hook flash timer (<country default>) | | Hook flash reject period (none) | | Fax relay maximum speed (default: 14400 bps) | | Fax relay playout delay (default: 300) | ----------------------------------------------------- -------------------------------------------------Clock Sourcing for Fax and Modem Passthrough The clock signal plays a critical role in allowing fax and modem transmissions to work correctly. The gateway clock must synchronize with the PSTN clock, where Stratum clocking is provided. Without this clock synchronization, fax and modem communications will not work. To synchronize the clocks correctly, enter the following configuration for the T1 controller in a Cisco IOS gateway. (In this example, the T1 controller is the voice gateway that connects to the PSTN.) ! controller T1 0 framing esf linecode b8zs clock source line channel-group 1 timeslots 1-24 speed 64 ! Also enter this configuration in all other interfaces connected to the PSTN.T.38 Fax Relay T.38 fax relay is not supported on Cisco ATA 188, 6608, and 6624 gateways, but it is supported on the Cisco IOS voice platforms and the VG248. You can configure T.38 fax relay in the following ways: • Named Service Event (NSE) T.38 Fax Relay, page 4-37 • Protocol-Based T.38 Fax Relay, page 4-37 Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) 4-36 OL-16394-07

Chapter 4 Gateways Fax and Modem SupportNamed Service Event (NSE) T.38 Fax Relay The configuration of NSE-based T.38 fax relay for H.323 and SIP can be accomplished at the dial-peer level or globally under voice service voip for Cisco IOS gateways. The following example is for an H.323 dial-peer configuration, but the same command syntax is applicable to SIP dial peers as well. H.323 ! dial-peer voice 1000 voip destination-pattern 1T session target ipv4:10.10.10.1 modem passthrough mode nse codec g711ulaw fax protocol t38 nse ! ! MGCP For Cisco IOS MGCP gateways, NSE-based T.38 fax relay is often referred to as gateway controlled T.38 mode because the gateways control the T.38 switchover through the NSE messages. Gateway-controlled T.38 fax relay is enabled with the command no mgcp fax t38 inhibit. ! ccm-manage mgcp mgcp mgcp call-agent 10.10.10.1 service-type mgcp version 0.1 mgcp modem passthrough voip mode nse no mgcp fax t38 inhibit ! dial-peer voice 100 pots application mgcpapp port 1/0/0 ! ! For SCCP gateways (either Cisco IOS gateways or the VG248), NSE-based T.38 fax relay must be used. Make sure that the command fax protocol t38 nse is configured under voice service voip if you want NSE-based T.38 fax relay to work on Cisco IOS SCCP gateways. In situations where gateways are using different call control protocols, the NSE switchover might have to be "forced". When the same call control protocol is being used, the gateways will notify one another during the call setup that NSE-based T.38 fax relay is supported. When different call protocols are used, such as one gateway using H.323 and the other gateway using MGCP, this NSE-based T.38 fax relay verification might not get passed between the gateways. Therefore, the gateways must be programmed to force the NSE negotiation even though a notification of NSE-based T.38 support has not been received. For H.323 and SIP voice gateways, this is simply accomplished by adding the force option to the existing t38 configuration command fax protocol t38 nse force. For MGCP, use the command mgcp fax t38 gateway force.Protocol-Based T.38 Fax Relay With protocol-based T.38 fax relay, the switchover to T.38 from voice mode occurs within the call control protocol. The call control protocols supported by protocol-based T.38 fax relay are H.323, SIP, and MGCP. For H.323 and SIP, protocol-based T.38 can be configured at the dial peer level or globally under voice service voip. The command syntax is the same as for NSE-based T.38 fax relay, except that the nse keyword is omitted. Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) OL-16394-07 4-37

Chapter 4 Gateways Fax and Modem Support An additional fallback option may also be specified for both NSE-based and protocol-based T.38 fax relay for the H.323 and SIP call control protocols. This option allows the gateway to attempt another switchover method or even an entirely different transport method if the initial fax transport selection fails to negotiate. The following example illustrates the configuration of protocol-based T.38 fax relay along with the fallback option for an H.323 dial peer. The command syntax is the same for SIP dial peers and for global configurations under voice service voip. H.323 ! dial-peer voice 1000 voip destination-pattern 1T session target ipv4:10.10.10.1 modem passthrough mode nse codec g711ulaw ! ! To enable T.38 fax relay and fall back to Cisco fax relay when ! T.38 fax negotiation fails. This is the default case. fax protocol t38 fallback cisco ! dial-peer voice 1001 voip destination-pattern 2T session target ipv4:10.10.10.2 modem passthrough mode nse codec g711ulaw ! ! To enable T.38 fax relay and fall back to fax passthrough when ! T.38 fax negotiation fails. fax protocol t38 nse fallback pass-through ! dial-peer voice 1002 voip destination-pattern 3T session target ipv4:10.10.10.3 modem passthrough mode nse codec g711ulaw ! ! This CLI is needed when talking to MGCP endpoint where CA/GK ! doesnt support T.38 fax relay such as CCM. fax protocol t38 nse force fallback none ! ! MGCP Protocol-based T.38 fax relay for MGCP voice gateways is commonly referred to as CA-controlled T.38 mode because the call agent (CA) handles the T.38 fax relay switchover. As shown in the following examples, you must make sure that T.38 fax relay is enabled for MGCP and that the two fxr-package commands are also configured. ! ccm-manage mgcp mgcp mgcp call-agent 10.10.10.1 service-type mgcp version 0.1 mgcp modem passthrough voip mode nse no mgcp fax t38 inhibit mgcp package-capability fxr-package mgcp default-package fxr-package ! dial-peer voice 100 pots application mgcpapp port 1/0/0 ! ! Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x)4-38 OL-16394-07

Chapter 4 Gateways Gateways for Video Telephony Because protocol-based T.38 fax relay directly involves Unified CM, make sure that your version of Unified CM supports T.38 fax relay within your gateways call control protocol. To determine if your version of Cisco Unified CM supports T.38 fax relay with specific call control protocols, refer to the Cisco Unified Communications Manager release notes available at http://www.cisco.com/en/US/products/sw/voicesw/ps556/prod_release_notes_list.html In topologies that employ the Cisco 6608 or 6624 voice gateways in addition to other Cisco voice gateways that support T.38 fax relay, use the following Cisco IOS commands: fax protocol t38 [nse [force]] fallback [cisco | none] modem passthrough nse codec {g711ulaw|g711alaw} These two commands enable Cisco IOS gateways to interoperate with the Cisco 6608 and 6624 gateways for Cisco fax relay and modem passthrough, as well as with other Cisco IOS gateways for T.38 fax relay and modem passthrough.Gateways for Video Telephony Video gateways terminate video calls into an IP telephony network or the PSTN. Deployments can consider separate gateways for voice calls and video calls, or they can have integrated gateways that route both voice and video calls. Cisco offers voice gateway functionality in a variety of forms, such as standalone devices, modules that integrate into Cisco IOS Routers, or line cards that integrate into Cisco Catalyst Ethernet Switches. These gateways support multiple VoIP protocols (such as H.323, MGCP, SIP, and SCCP), multiple port interface types (such as FXS, FXO, E&M, T1/E1-CAS, T1/E1-PRI, ISDN BRI, and so on), and a myriad of advanced VoIP features. They also offer a rich set of management and troubleshooting interfaces. Cisco IOS routers also support H.320 gateway functionality and can be used as Integrated Voice and Video gateways. Deployments that would like to leverage their existing voice infrastructure by adding video to it can do so by using the Cisco family of video-capable gateways from the Cisco Unified Videoconferencing 3500 Series portfolio. The Unified Videoconferencing gateways, while excellent for video calls, do not support all of the features that Cisco Voice Gateways offer. The Unified Videoconferencing gateways have the following characteristics: • They support only H.323 and H.320. • They are standalone devices that cannot be integrated into Cisco IOS Routers or Cisco Catalyst Switches. • They support only T1/E1-PRI and ISDN BRI. • They support only G.711, G.722, G.722.1, G.723.1 and G.728; they do not support G.729 audio. • They support the H.245 Empty Capabilities Set (ECS). • They do not support many of the manageability and troubleshooting capabilities inherent in Cisco Voice Gateways. As a result of these differences in the products, Cisco Unified Videoconferencing 3500 Series gateways are not recommended as replacements for Cisco Voice Gateways. IP Telephony customers who want to add video to their communications environment should deploy both types of gateways and use the Cisco Voice Gateways for all voice calls and use the Cisco Unified Videoconferencing 3500 Series gateways for video calls only. Customers might also have to procure separate circuits for voice and video from their PSTN service provider, depending on which model of Cisco IOS Gateway is deployed. Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x)OL-16394-07 4-39

Chapter 4 Gateways Gateways for Video Telephony With separate voice and video gateways (see Figure 4-6), the route plans must also be separate for both inbound and outbound calls. For inbound calls, there is no way to have a single Direct Inward Dial (DID) extension for a user who wants to be able to receive both voice and video calls. Typically, each user will already have a DID for voice calls. When you introduce video into the scenario, users will have to be dialed some other way, such as via a second DID number or by dialing the main number of the video gateway and then entering the users video extension when prompted by the Interactive Voice Response (IVR). For outbound calls, there is no way to have a single PSTN access code for both voice and video calls. Typically, users will already have a well-known access code for voice (such as 9 in most US enterprises), but when you introduce video into the scenario, they will have to dial some other access code to place outbound video calls. Figure 4-6 Unified CM System with Separate PSTN Lines for Voice and IP Video Telephony M M M IP PSTN M M V IP SCCP MGCP 119507 H.323 ISDN or other TDM interface Another consideration for deploying two types of gateways is the placement of those gateways. Typically, enterprises have many PSTN gateway resources consolidated at their central site(s), and each branch office has some local gateway resources as well. For instance, Cisco Catalyst 6500 gateways may be deployed at the central site with several T1/E1 circuits connected to them, while Cisco Integrated Services Routers (ISRs) may be deployed at each branch office with either analog or digital trunks to the local CO. When video is introduced into this scenario, the customer must also determine the number of PSTN circuits they will need for video and where the video gateways will be placed. For instance, will they deploy only a few IP/VC 3500 Series gateways at the central site, or will they also deploy them at each branch office? Finally, consider how calls will be routed across the IP network to a remote gateway for the purpose of providing toll bypass, and how calls will be re-routed over the PSTN in the event that the IP network is unavailable or does not have enough bandwidth to complete the call. More specifically, do you want to invoke automated alternate routing (AAR) for video calls?Routing Inbound Calls from the PSTN Use one of the following methods to route inbound calls from the PSTN: • Assign at least two different directory numbers to each video-enabled device in the Unified CM cluster, with one line for audio and another line for video. With this method, the outside (PSTN) caller must dial the correct number to enable video. Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) 4-40 OL-16394-07

Chapter 4 Gateways Gateways for Video Telephony • For video calls, have outside callers dial the main number of the video gateway. Cisco Unified Videoconferencing gateways offer an integrated IVR that prompts the caller to enter the extension number of the party they are trying to reach. Unified CM will then recognize that it is a video call when ringing the destination device. This method relieves the caller from having to remember two different DID numbers for each called party, but it adds an extra step to dialing an inbound video call. Note The outside video endpoints must support DTMF in order to enter the extension of the called party at the IVR prompt. The following example illustrates the second method: A user has a Cisco Unified IP Phone 7960 attached to a PC running Cisco Unified Video Advantage. The extension of the IP Phone is 51212, and the fully qualified DID number is 1-408-555-1212. To reach the user from the PSTN for a voice-only call, people simply dial the DID number. The CO sends calls to that DID number through T1-PRI circuit(s) connected to a Cisco Voice Gateway. When the call is received by the gateway, Unified CM knows that the gateway is capable of audio only, so it negotiates only a single audio channel for that call. Conversely, for people to reach the user from the PSTN for a video call, they must dial the main number of the video gateway and then enter the user’s extension. For example, they might dial 1-408-555-1000. The CO would send calls to that number through the T1-PRI circuit(s) connected to a Cisco Unified Videoconferencing 3500 Series video gateway. When the call is received by the gateway, an IVR prompt asks the caller to enter the extension of the person they are trying to reach. When the caller enters the extension via DTMF tones, Unified CM knows that the gateway is capable of video, so it negotiates both audio and video channels for that call. Gateway Digit Manipulation The Cisco Unified Videoconferencing 3500 Series Gateways cannot manipulate digits for calls received from the PSTN. It takes the exact number of digits passed to it in the Q.931 Called Party Number field and sends them all to Unified CM. Therefore, Unified CM must manipulate the digits in order to match the directory number (DN) of the destination device. For instance, if the circuit from the CO switch to the gateway is configured to pass 10 digits but the extension of the called party is only five digits, Unified CM must strip off the leading five digits before attempting to find a matching DN. You can implement this digit manipulation in one of the following ways: • By configuring the Significant Digits field on the H.323 gateway device or on the H.225 gatekeeper-controlled trunk that carries the incoming calls from the IP/VC gateway This method enables you to instruct Unified CM to pay attention to only the least-significant N digits of the called number. For example, setting the Significant Digits to 5 will cause Unified CM to ignore all but the last 5 digits of the called number. This is the easiest approach, but it affects all calls received from that gateway. Thus, if you have variable-length extension numbers, this is not the recommended approach. • By configuring a translation pattern and placing it in the calling search space of the H.323 gateway device or of the H.225 gatekeeper-controlled trunk that carries the incoming calls from the IP/VC gateway This method enables Unified CM to match calls to the full number of digits received, to modify the called number, and then to continue performing digit analysis on the resulting modified number. This approach is slightly more complex than the preceding method, but it is more flexible and enables you to use a finer granularity for matching calls and for specifying how they will be modified. Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x)OL-16394-07 4-41

Chapter 4 Gateways Gateways for Video TelephonyRouting Outbound Calls to the PSTN Use one of the following methods to route outbound calls to the PSTN: • Assign different access codes (that is, different route patterns) for voice and video calls. For example, when the user dials 9 followed by the PSTN telephone number they are trying to reach, it could match a route pattern that directs the call out a voice gateway. Similarly, the digit 8 could be used for the route pattern that directs calls out a video gateway. • Assign at least two different directory numbers on each video-enabled device in the Unified CM cluster, with one line for audio and another line for video. The two lines can then be given different calling search spaces. When users dial the access code (9, for example) on the first line, it could be directed out a voice gateway, while dialing the same access code on the second line could direct the call out a video gateway. This method alleviates the need for users to remember two different access codes but requires them to press the correct line on their phones when placing calls. Gateway Service Prefixes The Cisco Unified Videoconferencing Gateways use service prefixes to define the speed for outbound calls. When you configure a service prefix in the gateway, you must choose one of the following speeds: • Voice-only • 128 kbps • 256 kbps • 384 kbps • 768 kbps • Auto (dynamically determined; supports any call speed in the range of 128 kbps to 768 kbps) Note Each of the above speeds represents a multiple of 64 kbps. For 56-kbps dialing, there is a check-box on the service prefix configuration page to restrict each channel to 56 kbps. Therefore, a 128-kbps service with restricted mode enabled would result in a 112-kbps service; a 384 kbps service with restricted mode enabled would result in a 336-kbps service; and so on. Calls from an IP endpoint toward the PSTN must include the service prefix at the beginning of the called number in order for the gateway to decide which service to use for the call. Optionally, you can configure the default prefix to be used for calls that do not include a service prefix at the beginning of the number. This method can become quite complex because users will have to remember which prefix to dial for the speed of the call they wish to make, and you would have to configure multiple route patterns in Unified CM (one for each speed). Fortunately, the Auto speed enables you to minimize this effort. If the majority of your calls are made using 64 kbps per channel (for example, 128 kbps, 384 kbps, 512 kbps, 768 kbps, and so on), you could use the Auto service in that case. You would then need to create only one other service for the rare case in which someone makes a call using 56 kbps per channel (for example, 112 kbps, 336 kbps, and so on). Cisco recommends that you always use a # character in your service prefixes because the gateway recognizes the # as an end-of-dialing character. By placing this character in the service prefix, you block people from attempting to use the gateway for toll fraud by dialing the main number of the gateway, reaching the IVR, and then dialing out to an off-net number. The # can either be at the beginning (recommended) or the end of the service prefix. For example, if your access code to reach the PSTN is 8 for video calls, Cisco recommends that you configure the service prefix as #8 or 8#. Or, if you have two service prefixes as described above, you might use #80 for the Auto 64-kbps service and #81 for the Auto 56-kbps service. Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) 4-42 OL-16394-07

Chapter 4 Gateways Gateways for Video Telephony The ramification of using a service prefix is that Unified CM must prepend the service prefix to the called number when sending calls to the IP/VC gateway. Because forcing users to dial the # would not be very user-friendly, Cisco recommends that you configure Unified CM to prepend the # to the dialed number. For example, if the access code to dial a video call to the PSTN is 8, you could configure a route pattern as 8.@ in Unified CM, and in the route pattern configuration you would configure the called number translation rule to prepend #8 whenever that route pattern is dialed. Or, if you have two service prefixes as described above, you might use 80.@ for the Auto 64-kbps service (prefixing # to the called number) and 81.@ for the Auto 56-kbps service (prefixing # to the called number).Automated Alternate Routing (AAR) When the IP network does not have enough bandwidth available to process a call, Unified CM uses its call admission control mechanism to determine what to do with the call. As described in the chapter on IP Video Telephony, page 16-1, Unified CM performs one of the following actions with the call, depending on how you have configured it: • Fail the call, playing busy tone to the caller and displaying a Bandwidth Unavailable message on the caller’s screen • Retry the video call as an audio-only call • Use automated alternate routing (AAR) to re-route the call over an alternative path, such as a PSTN gateway The first two options are covered in the chapter on IP Video Telephony, page 16-1, and this section covers the AAR option. To provide AAR for voice or video calls, you must configure the calling and called devices as members of an AAR group and configure an External Phone Number Mask for the called device. The External Phone Number Mask designates the fully qualified E.164 address for the user’s extension, and the AAR group indicates what digits should be prepended to the External Phone Number Mask of the called device in order for the call to route successfully over the PSTN. For example, assume that user A is in the San Jose AAR group and user B is in the San Francisco AAR group. User Bs extension is 51212, and the External Phone Number Mask is 6505551212. The AAR groups are configured to prepend 91 for calls between the San Jose and San Francisco AAR groups. Thus, if user A dials 51212 and there is not enough bandwidth available to process the call over the IP WAN between those two sites, Unified CM will take user Bs External Phone Number Mask of 6505551212, prepend 91 to it, and generate a new call to 916505551212 using the AAR calling search space for user A. This same logic applies to video calls as well, with one additional step in the process. For video-capable devices, there is field called Retry Video Call as Audio. As described in the chapter on IP Video Telephony, page 16-1, if this option is enabled (checked), Unified CM does not perform AAR but retries the same call (that is, the call to 51212) as a voice-only call instead. If this option is disabled (unchecked), Unified CM performs AAR. By default, all video-capable devices in Unified CM have the Retry Video Call as Audio option enabled (checked). Therefore, to provide AAR for video calls, you must disable (uncheck) the Retry Video Call as Audio option. Additionally, if a call admission control policy based on Resource Reservation Protocol (RSVP) is being used between locations, the RSVP policy must be set to Mandatory for both the audio and video streams. Furthermore, Unified CM looks at only the called device to determine whether the Retry Video Call as Audio option is enabled or disabled. So in the scenario above, user Bs phone would have to have the Retry Video Call as Audio option disabled in order for the AAR process to take place. Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) OL-16394-07 4-43

Chapter 4 Gateways Gateways for Video Telephony Finally, devices can belong to only one AAR group. Because the AAR groups determine which digits to prepend, AAR groups also influence which gateway will be used for the rerouted call. Depending on your choice of configuration for outbound call routing to the PSTN, as discussed in the previous section, video calls that are rerouted by AAR might go out a voice gateway instead of a video gateway. Therefore, carefully construct the AAR groups and the AAR calling search spaces to ensure that the correct digits are prepended and that the correct calling search space is used for AAR calls. While these considerations can make AAR quite complex to configure in a large enterprise environment, AAR is easier to implement when the endpoints are strictly of one type or the other (such as IP Phones for audio-only calls and systems such as the Tandberg T-1000 dedicated for video calls). When endpoints are capable of both audio and video calls (such as Cisco Unified Video Advantage or a Cisco IP Video Phone 7985G), the configuration of AAR can quickly become unwieldy. Therefore, Cisco recommends that large enterprise customers who have a mixture of voice and video endpoints give careful thought to the importance of AAR for each user, and use AAR only for select video devices such as dedicated videoconference rooms or executive video systems. Table 4-13 lists scenarios when it is appropriate to use AAR with various device types.Table 4-13 When to Use AAR with a Particular Device TypeDevice Type Device is used to call: Enable AAR? CommentsIP Phone Other IP Phones and Yes Even when calling a video-capable device, the video-capable devices source device is capable of audio-only, thus AAR can be configured to route calls out a voice gateway.IP Phone with Other video-capable Yes Because the device is used strictly for videoCisco Unified Video devices only calls, you can configure the AAR groupsAdvantage, or Cisco IP accordingly.Video Phone 7985G IP Phones and other No It will be difficult to configure the AAR groups video-capable devices to route audio-only calls differently than video calls.Sony or Tandberg Other video-capable Yes Because the device is used strictly for videoSCCP endpoint devices only calls, you can configure the AAR groups accordingly. IP Phones and other No It will be difficult to configure the AAR groups video-capable devices to route audio-only calls differently than video calls.H.323 or SIP client Other video-capable Yes Because the device is used strictly for video devices only calls, you can configure the AAR groups accordingly. IP Phones and other No It will be difficult to configure the AAR groups video-capable devices to route audio-only calls differently than video calls Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) 4-44 OL-16394-07

Chapter 4 Gateways Gateways for Video TelephonyLeast-Cost Routing Least-cost routing (LCR) and tail-end hop-off (TEHO) are very popular in VoIP networks and can be used successfully for video calls as well. In general, both terms refer to a way of configuring the call routing rules so that calls to a long-distance number are routed over the IP network to the gateway closest to the destination, in an effort to reduce toll charges. (For Cisco Unified CM Release 4.1, LCR basically means the same thing as TEHO.) Unified CM supports this feature through its rich set of digit analysis and digit manipulation capabilities, including: • Partitions and calling search spaces • Translation patterns • Route patterns and route filters • Route lists and route groups Configuring LCR for video calls is somewhat more complicated than for voice calls, for the following reasons: • Video calls require their own dedicated gateways, as discussed previously in this chapter • Video calls require much more bandwidth than voice calls With respect to dedicated gateways, the logic behind why you might or might not decide to use LCR for video calls is very similar to that explained in the section on Automated Alternate Routing (AAR), page 4-43. Due to the need to have different types of gateways for voice and video, it can become quite complex to configure all the necessary partitions, calling search spaces, translation patterns, route patterns, route filters, route lists, and route groups needed for LCR to route voice calls out one gateway and video calls out another. With respect to bandwidth requirements, the decision to use LCR depends on whether or not you have enough available bandwidth on your IP network to support LCR for video calls to/from a given location. If the current bandwidth is not sufficient, then you have to determine whether the benefits of video calls are worth the cost of either upgrading your IP network to make room for video calls or deploying local gateways and routing calls over the PSTN. For example, suppose you have a central site with a branch office connected to it via a 1.544-Mbps T1 Frame Relay circuit. The branch office has twenty video-enabled users in it. A 1.544-Mbps T1 circuit can handle at most about four 384-kbps video calls. Would it really make sense in this case to route video calls up to the central site in order to save on toll charges? Depending on the number of calls you want to support, you might have to upgrade your 1.544-Mbps T1 circuit to something faster. Is video an important enough application to justify the additional monthly charges for this upgrade? If not, it might make more sense to deploy an IP/VC video gateway at the branch office and not bother with LCR. However, placing local IP/VC gateways at each branch office is not inexpensive either, so ultimately you must decide how important video-to-PSTN calls are to your business. If video is not critical, perhaps it is not worth upgrading the bandwidth or buying video gateways but, instead, using the Retry Video Call as Audio feature to reroute video calls as voice-only calls if they exceed the available bandwidth. Once a call is downgraded to voice-only, local gateway resources and bandwidth to perform LCR become more affordable and easier to configure.ISDN B-Channel Binding, Rollover, and Busy Out There are two H.320 video channel bonding techniques, px64 and p*64 (ISO-13871). Cisco video equipment uses px64 for all calls, while other video equipment such as Polycom or Tandberg uses px64 for two-channel calls (128 kbps video) and ISO-13871 for anything higher than two channels (such as 192 kbps to 1 Mbps video). With Cisco IOS Release 12.4.20T, Cisco IOS H.320 gateways support the Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) OL-16394-07 4-45

Chapter 4 Gateways Gateways for Video Telephony ISO-13871 bonding technique, which supports video calls at speeds up to 1 Mbps for video calls. With this functionality the Cisco IOS router can be used as an integrated gateways for both voice and video calls. H.320 video uses multiple ISDN channels bound together to achieve the speeds needed to pass full-motion video. One of the problems with this bonding mechanism is that, when an inbound ISDN video call is received, the gateway does not know how many channels will be requested for that call until after it accepts the call and the source device indicates how many additional channels are required. If there are not enough B-Channels to satisfy the request, the call is disconnected. Therefore, careful traffic engineering is required to minimize the possibility that this situation will occur. Essentially, you want to ensure that there are always enough B-Channels available to handle the next call that might come in. This B-Channel issue occurs in two cases: • Inbound calls from the PSTN to the IP network • Outbound calls from the IP network to the PSTNInbound Calls For inbound calls, consider the following scenario: A company has a Cisco 3526 IP/VC Gateway with an ISDN PRI circuit connecting it to a central office (CO) switch. The ISDN PRI circuit in this case offers 23 B-Channels. A video call is received from the PSTN at 384 kbps. This call takes six B-Channels, leaving 17 available. A second and third 384-kbps call are received on the line while the first one is still active. These each take an additional six channels, leaving five channels available. When the fourth 384-kbps call is received, the gateway will answer the call but, recognizing that it does not have enough B-Channels available (it only has five left but the call requires six), it will disconnect (by sending a Q.931 RELEASE COMPLETE with "16: Normal Call Clearing" as the reason). The caller attempting to make the fourth call will not know why the call failed and might redial the number repeatedly, trying to make the call work. On Cisco Unified Videoconferencing gateways, you can minimize your chances of running into this issue by configuring the gateway to send a request to the CO to busy-out the remaining B-Channels (in this example, five channels) whenever the gateway reaches a certain threshold of utilization (configured as a percentage of total bandwidth). In addition, you can have the CO provision multiple ISDN circuits in a trunk group. When the first circuit reaches the busy-out threshold, calls will roll over to the next PRI in the group. The Cisco 3540 IP/VC Gateway offers two ISDN PRI connections and supports bonding channels across both ports. For example, port 1 might have only five channels available while port 2 is sitting idle and, therefore, has 23 channels available. By taking the five channels from port 1 and one channel from port 2 and bonding them together, the fourth 384-kbps call can succeed. This leaves 22 channels available on controller 2, and at some point additional inbound calls would reach the busy-out threshold again. At that point the remaining channels on port 2 will be busied out, and all further inbound calls will be rejected with cause code "Network Congestion." Cisco Unified Videoconferencing gateways cannot bound channels across different gateways or across different Cisco 3540 gateway models in the same Cisco 3544 chassis, so two ports is the maximum that you can bond together. The CO switch can still roll calls over to a third or forth PRI in the trunk group (most COs support trunk groups of up to 6 circuits), but you cannot bond channels between PRI number one and PRI number three, for example, as you can between PRI number one and PRI number two. The busy-out logic described above depends on the assumption that all calls take place at the same speed. Suppose, for example, that two 384-kbps calls are active on a port and a 128-kbps call came in. This call would take only two channels, using a total of 14 channels for the three calls (6+6+2 = 14) and leaving nine channels available on the circuit. However, if the busy-out threshold is set at 18 channels (assuming that all calls would take place at 384-kbps), only four channels are still available under this busy-out Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) 4-46 OL-16394-07

Chapter 4 Gateways Gateways for Video Telephony threshold. If another 384 kbps call comes in at this point, the call will fail because the remaining four channels are not enough to support the call. Also, because the busy-out threshold of 18 channels has not been reached yet (only 14 channels are used), the circuit is not busied out and calls will not roll over to the next circuit. This condition will persist until one of the existing calls is disconnected. To avoid such situations, it is important to try to standardize on a single call speed for all calls.Outbound Calls Outbound calls encounter the same potential situations as inbound calls, but the way in which the busy-out occurs is different. The Cisco 3500 Series IP/VC Gateways support messages called Resource Availability Indicator and Resource Availability Confirm (RAI/RAC). The RAI/RAC messages are defined under the H.225 RAS specification and are used by the gateways to tell the gatekeeper that they are full and to no longer route any more calls to them. When the gateway reaches the busy-out threshold, it sends an RAI message with a status of True to the gatekeeper. True means "Do not send me any more calls;" False means "I am available." The gateway sends an RAI=False as soon as it is no longer at its busy-out threshold. The busy-out threshold for outbound calls is separate from the busy-out threshold for inbound calls, and you can configure them differently so that inbound calls will roll over to the next available circuit but outbound calls will still be accepted, or vice versa. For example, you could configure the RAI threshold to 12 channels but the ISDN busy-out threshold to 18 channels. When two 384 kbps are active, outbound calls will roll over to the next available gateway, but a third 384-kbps inbound call could still be received. An equally efficient method of achieving outbound call busy-out failover is to use Unified CMs route group and route list construct, as described in the following section, instead of the RAI/RAC method.Configuring the Gateways in Unified CM You can configure a Unified Videoconferencing gateway in either of the following ways in Unified CM: • Configure it as an H.323 gateway, and Unified CM will route calls directly to the gateway. • Configure an H.225 gatekeeper-controlled trunk to the gatekeeper, and route calls to the gateway through the gatekeeper. If you have only one gateway, it is probably easier to configure it directly in Unified CM instead of going through a trunk to get to it. If you have multiple gateways for load balancing and redundancy, you can either configure them all in Unified CM and place them into a route group(s) and route list, or configure an H.225 trunk to the gatekeeper and rely on RAI/RAC between the gateways and the gatekeeper to tell Unified CM which gateway it should send a given call to. For inbound calls from the PSTN to Unified CM, the Cisco Unified Videoconferencing gateways can either register with a gatekeeper or be configured with the IP addresses of up to three Unified CM servers to which they should send all inbound call requests. This method is known as peer-to-peer mode. Either way, the goal is have all inbound calls received by the gateways sent to Unified CM so that Unified CM can decide how to route the calls. See Gatekeepers, page 16-22, for more details on how to configure the gatekeeper to route calls from the gateways to Unified CM.Call Signaling Port Numbers By default, the Cisco Unified Videoconferencing Gateways listen on TCP port 2720 instead of the well-known port 1720. However, also by default, Unified CM sends H.323 calls to port 1720. You can change the port that the gateway listens on or you can change the port that Unified CM sends to in the H.323 gateway device configuration in Unified CM. Either way, both sides have to match in order for outbound calls to the gateway to succeed. Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) OL-16394-07 4-47

Chapter 4 Gateways Gateways for Video Telephony In the inbound direction, when configured to operate in peer-to-peer mode, the Cisco Unified Videoconferencing Gateways will send the call to Unified CM on port 1720. When configured to register with a gatekeeper, Unified CM uses a randomly generated port number for all gatekeeper-controlled trunks. This method enables Unified CM to have multiple trunks to the same gatekeeper. This port number is included in the Registration Request (RRQ) from Unified CM to the gatekeeper, so the inbound H.225 setup message from the gateway to Unified CM will be sent to this port number. However, if the gateway is configured directly in Unified CM as an H.323 gateway device, Unified CM will ignore the fact that the call came in on the TCP port of the H.225 trunk and will instead match the source IP address to the H.323 gateway device configured in its database. If it does not find a matching device, Unified CM will treat the call as if it came in on the trunk. In the outbound direction, if Unified CM uses a gatekeeper-controlled H.225 trunk to reach the gateway, the gatekeeper will tell Unified CM which TCP port to use to reach the gateway. If the gateway is configured in Unified CM as an H.323 gateway device (that is, peer-to-peer mode), then Unified CM must be configured to send calls either to port 2720 (default) or to 1720 (if the listening port on the gateway has been modified).Call Signaling Timers Due to the delay inherent in H.320 bonding, video calls can take longer to complete than voice calls. Several timers in Unified CM are tuned, by default, to make voice calls process as fast as possible, and they can cause video calls to fail. Therefore, you must modify the following timers from their default values in order to support H.320 gateway calls: • H.245TCSTimeout • Media Exchange Interface Capability Timer • Media Exchange Timer Cisco recommends that you increase each of these timers to 25 by modifying them under the Service Parameters in Unified CM Administration. Note that these are cluster-wide service parameters, so they will affect calls to all types of H.323 devices, including voice calls to existing H.323 Cisco Voice Gateways.Bearer Capabilities of Voice Gateways H.323 calls use the H.225/Q.931 Bearer Capabilities Information Element (bearer-caps) to indicate what type of call is being made. A voice-only call has its bearer-caps set to "speech" or "3.1 KHz Audio" while a video call has its bearer-caps set to "Unrestricted Digital Information." Some devices do not support Unrestricted Digital Information bearer-caps. Calls to these devices might fail if Unified CM attempts the call as a H.323 video call. Unified CM decides which bearer-caps to set, based on the following factors: • Whether the calling and/or called devices are video-capable • Whether the region in Unified CM is configured to allow video for calls between those devices Unified CM supports retrying the video call as audio, and this feature can be enabled through configuration. When Unified CM makes a video call with bearer-caps set to "Unrestricted Digital" and the call fails, Unified CM then retries the same call as an audio call with the bearer-caps set to "speech." When using H.323, Cisco IOS gateways can service calls as voice or video, based on the bearer capabilities it receives in the call setup. When using SIP, the gateway translates the ISDN capabilities into SDP for call negotiations. Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) 4-48 OL-16394-07

Chapter 4 Gateways Gateways for Video Telephony If the Cisco voice gateway uses MGCP to communicate with Unified CM, the problem will not occur because Unified CM does not support video on its MGCP protocol stack and because, in MGCP mode, Unified CM has complete control over the D-Channel signaling to the PSTN. Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x)OL-16394-07 4-49

Chapter 4 Gateways Gateways for Video Telephony Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x)4-50 OL-16394-07

CH A P T E R 5 Cisco Unified CM Trunks Last revised on: September 18, 2009 Cisco Unified Communications Manager (Unified CM, formerly Cisco Unified CallManager) supports several different types of IP trunks for connectivity with external devices. There are three types of trunks that can be configured in the Unified CM: H.225 (H.323), SIP, and intercluster trunks. This chapter describes the general capabilities and functions of these trunks. More discussion on specific applications of Unified CM trunks can be found in other pertinent chapters of this document. This chapter discusses the following topics: • A Comparison of H.323 and SIP Trunks, page 5-2 • H.323 Trunks, page 5-7 • SIP Trunks, page 5-17 • Cisco Unified CM Trunks and Emergency Services, page 5-25 For more details on the applications of Unified CM trunks, refer to their respective sections in the following chapters: • Unified Communications Deployment Models, page 2-1 • Media Resources, page 6-1 • Call Admission Control, page 9-1 • IP Video Telephony, page 16-1 • Cisco Unified Presence, page 22-1Whats New in This Chapter Table 5-1 lists the topics that are new in this chapter or that have changed significantly from previous releases of this document. Table 5-1 New or Changed Information Since the Previous Release of This Document New or Revised Topic Described in: Calling party number normalization Calling Party Number Normalization and SIP Trunks, page 5-23 Cisco Unified SIP Proxy Cisco Unified SIP Proxy, page 5-6 Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) OL-16394-07 5-1

Chapter 5 Cisco Unified CM Trunks A Comparison of H.323 and SIP Trunks Table 5-1 New or Changed Information Since the Previous Release of This Document New or Revised Topic Described in: Codec type selection Codec Selection Over IP Trunks, page 5-24 Design recommendations Design Recommendations for Deploying IP Trunks, page 5-25 Enhancements for SIP trunks Overview of SIP Trunks, page 5-4 Load balancing outbound calls when Load Balancing Outbound Calls, page 5-12 route lists are used SRTP and SIP trunks SRTP in SIP Trunks, page 5-23 Video codec support over H.323 and Table 5-2 SIP trunksA Comparison of H.323 and SIP Trunks Cisco Unified CM trunk connections support both H.323 and SIP. In many cases, the decision to use H.323 or SIP is driven by the unique feature(s) offered by each protocol. There are also a number of external factors that can affect the choice of trunk protocol, such as customer preference or the protocols maturity and degree of interoperability offered between various vendors products. For trunk connections between Cisco devices, this decision is relatively straightforward. For trunk connections to other vendors products and to service provider networks, it is important to understand which features are required by the customer and the extent of interoperability between any two vendors products. Table 5-2 compares some of the features offered over H.323 and SIP trunks between Unified CM clusters.Table 5-2 Comparison of H.323 and SIP Features on Cisco Unified CM TrunksFeature H.323 QSIG over H.323 SIPCalling Line (Number) Identification Presentation Yes Yes YesCalling Line (Number) Identification Restriction Yes Yes YesCalling Name Identification Presentation Yes Yes YesCalling Name Identification Restriction Yes Yes YesConnected Line (Number) Identification Presentation Yes Yes YesConnected Line (Number) Identification Restriction Yes Yes YesConnected Name Identification Presentation Yes Yes YesConnected Name Identification Restriction Yes Yes YesAlerting Name No Yes YesCall Transfer (Blind/Attended) Yes/Yes Yes/Yes Yes/YesCall Forward All Yes Yes YesCall Forward Busy Yes Yes YesCall Forward No Reply Yes Yes YesCall Completion to Busy Subscriber No Yes No Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) 5-2 OL-16394-07

Chapter 5 Cisco Unified CM Trunks A Comparison of H.323 and SIP TrunksTable 5-2 Comparison of H.323 and SIP Features on Cisco Unified CM Trunks (continued)Feature H.323 QSIG over H.323 SIPCall Completion No Reply No Yes NoSubscribe/Notify, Publish – Presence No No YesMessage Waiting Indication (MWI: lamp ON, lamp OFF) No Yes YesPath Replacement No Yes NoCall Hold/Resume Yes Yes YesMusic On Hold (unicast and multicast) Yes Yes YesDTMF-relay H.245 Out Of Band H.245 Out Of Band RFC 2833, KPML (OOB)1 (OOB)1 (OOB), Unsolicited Notify (OOB)SIP Early Offer N/A N/A Yes – Requires MTP for outbound callsSIP Delayed Offer N/A N/A YesH.323 Fast Start Yes – MTP required Yes – MTP required N/A for Outbound Fast for Outbound Fast Start StartH.323 Slow Start Yes Yes N/AAudio codecs G.711, G.722, G.711, G.722, G.711, G.722, G.723, G.729, G722 G.723, G.729, G722 G.723, G.729, G722, iLBC, AACCodecs with MTP G.711, G.722, G.711, G.722, G.711, G.729 G.723, G.729 G.723, G.729Video Yes Yes YesVideo codecs H.261, H.263, H.261, H.263, H.261, H.263, H.263+, H.264 AVC H.263+, H.264 AVC H.263+, H.264 AVCT.38 Fax Yes Yes YesSignaling Authentication No No Digest, TLSSignaling Encryption No No TLSMedia Encryption SRTP SRTP SRTP1. H.323 trunks support signaling of RFC 2833 for certain connection types.Overview of H.323 Trunks The H.323 trunk provides connectivity to other Unified CM clusters and other H.323 devices such as gateways. H.323 trunks support most of the audio and video codecs that Unified CM supports for intra-cluster communications, with the exception of wideband audio and wideband video. H.323 trunks use the Empty Capabilities Set (ECS) to provide supplementary call services such as hold/resume and transfer. This method is a standard H.245 mechanism to stop or close a media stream (or channel) and start or open it to the same or a different endpoint address. This method allows Unified CM to keep a call active while still being able to control the source and destination of the media streams on the fly. Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) OL-16394-07 5-3

Chapter 5 Cisco Unified CM Trunks A Comparison of H.323 and SIP Trunks For example, consider a call between two clusters (A and B) using the H.323 trunk. When a user in cluster A places a user in cluster B on hold, the media streams between the two users are closed and the user in cluster B is connected to a music on hold (MoH) server in cluster A. The MoH server is instructed to send media (the music file) to the user. When the user in cluster A resumes the call, the MoH stream is closed and the two-way media streams are reopened between the two users. (Unified CM does not support H.450 for supplementary call services.) In this case, MoH is an example of an ECS operation. Starting with Cisco Unified CM 7.1(2), H.323 trunks support multicast MoH, therefore the media resource group list (MRGL) for the H.323 trunks can contain both unicast and milticast MoH sources. (For details, see Music on Hold, page 7-1.) The bandwidth used for calls on H.323 trunks can be controlled by the use of regions configured in Unified CM and assigned to each trunk. A region limits the amount of bandwidth allocated for calls by specifying the audio codec type and video bandwidth per call for that region. Calls between that region and another region must be within the specified bandwidth limit. If the device making the call over the H.323 trunk is in a more restrictive region or does not support a particular codec such as video, then it is a subset of codecs that are allowed for that call. The H.323 trunk supports DTMF signaling for both out-of-band DTMF using H.245 and in-band DTMF using RTP Named Telephone Events (RFC-2833). There are no configuration options. For an explanation of when the H.323 trunk uses which method, refer to the chapter on Media Resources, page 6-1.Overview of SIP Trunks SIP trunks provide connectivity to other SIP devices such as gateways, proxies, voicemail systems, and other Unified CM clusters. Cisco Unified CM 5.x and later releases provide major enhancements for SIP trunks and remove the limitations in Cisco Unified CM 4.x, such as single codec support, lack of video support, and the mandatory media termination point (MTP) for RFC 2833 DTMF support. The main enhancements to SIP trunks in Cisco Unified CM 6.x are the support for the iLBC and AAC codecs and SIP PUBLISH. By providing improved performance, SIP PUBLISH provides the preferred mechanism for Cisco Unified CM 6.x to send IP phone presence information to Cisco Unified Presence over a SIP trunk. Major enhancements to SIP trunks in Cisco Unified CM 7.x include: • Support for offering the G.729 codec in outgoing initial SIP INVITE requests • Usage of Privacy, P-Asserted-Identity, and P-Preferred-Identity headers to signal the content and whether to display or restrict calling and called party names and numbers • Encryption of media using Secure Real-Time Transport Protocol (SRTP) • Support for normalization of calling party numbers For the complete list of new enhancements for SIP trunks, refer to the Cisco Unified Communications Manager product release notes available at http://www.cisco.com/en/US/products/sw/voicesw/ps556/prod_release_notes_list.html When used for intercluster trunking, SIP trunks do not support QSIG Tunneling using Annex M1. As in H.323 trunks, the codec selected for use for calls over a SIP trunk is determined by the capabilities of the remote endpoint as learned from the SIP call setup messages, capabilities of the local endpoint, and the inter-region codec settings between the trunk and the local endpoint regions. Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) 5-4 OL-16394-07

Chapter 5 Cisco Unified CM Trunks A Comparison of H.323 and SIP Trunks Note A higher-quality codec such as G.722 or G.711 will be selected over a lower-quality codec such as G.729, if possible. An exception to this rule is if the link between the regions is marked as lossy. In this case the iLBC codec, if available, will be used.IP PSTN and IP Trunks to Service Provider Networks With support for both H.323 and SIP trunks in Cisco Unified CM, service providers are starting to offer non-TDM PSTN connections to enterprise customers. Apart from the obvious benefit of the cost savings from deploying non-TDM interfaces, in many case these IP-based PSTN connections also offer additional voice features over traditional PSTN interfaces. The choice of H.323 or SIP as the IP trunking protocol often depends on the service provider, although SIP-based services are now beginning to dominate the available offerings. This is mainly due to the increasing popularity of SIP within the enterprise and the promise of additional capabilities such as Presence and support for many multimedia applications (such as instant messaging). SIP will probably become the more widely deployed Unified Communications protocol in the long term. Because both the SIP and H323 standard are open to a degree of interpretation (there are many optional as well as mandatory requirements), the degree of interoperability between vendors is often something that improves over time as the protocols mature. To this end, the Cisco Unified Border Element (formerly Cisco Multiservice IP-to-IP Gateway Software) offers a number of interoperability features as well as a natural demarcation point as a Session Border Controller when connecting to other vendors’ H323 and SIP networks.Cisco Unified Border Element The Cisco Unified Border Element (formerly Cisco Multiservice IP-to-IP Gateway Software) provides a wide range of signalling and media functionality between the enterprise and service-provider Cisco Unified Communications networks. Cisco Unified Border Element provides a network-to-network interface point for: • Address and port translations (privacy and topology hiding) • Signaling interworking (H.323 and SIP) • Media interworking (DTMF, fax, modem, and codec transcoding) • QoS and bandwidth management (QoS marking using ToS, DSCP, and bandwidth enforcement using RSVP and codec filtering) • Billing and CDR normalization The Cisco Unified Border Element is a licensed Cisco IOS application that is available on the Cisco 2800 and 3800 Series Integrated Service Routers (ISR), the Cisco AS5350XM and AS5400XM Media Gateways, and the Cisco 7200VXR and Cisco 7301 Series router and gateway platforms. Cisco recommends the use of Cisco Unified Border Element for any IP PSTN deployment. Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) OL-16394-07 5-5

Chapter 5 Cisco Unified CM Trunks A Comparison of H.323 and SIP TrunksCisco Unified SIP Proxy The Cisco Unified SIP Proxy provides SIP proxy functionality on a Cisco NME-522 network module that can be plugged into a network module slot on the Cisco 3800 Series Integrated Services Routers (ISRs). This ISR does not need to be dedicated to hosting the network module and running the proxy alone, but can be used simultaneous for other network functions such as to run the Cisco Unified Border Element described above. The Cisco Unified SIP Proxy brings the following benefits to a network using Unified CM SIP trunks: • Aggregation and routing The Unified SIP Proxy is capable of connecting several SIP servers to each other without each of the servers connecting to every other one in a full-mesh configuration • Scalability The Unified SIP Proxy can be used to terminate calls to and from the enterprise and IP-PSTN service providers. The proxy, in turn, distributes the calls across a pool of Unified Border Elements. More Unified Border Elements may be added to increase capacity. • Availability and load balancing The Unified SIP Proxy distributes calls over the pool of available Unified Border Elements and monitors the status of each Unified Border Element to ensure reliable call completion. • Message normalization The Unified SIP Proxy serves to hide differences in SIP protocol messaging by providing the means to manipulate headers and contents of the messages as they pass through the Unified SIP Proxy. The following design considerations should be taken into account when deploying the Cisco Unified SIP Proxy with the Cisco Unified Border Element: • Use the Unified SIP Proxy when a scalable connection is desired. Adding capacity is as easy as adding a new Unified Border Element. • Configure a load balancing scheme on the Unified SIP Proxy so that none of the attached Unified Border Elements is overloaded. • Set up trunk monitoring in the Unified SIP Proxy so that it can detect and act on any failure of the Unified CM or Unified Border Element Figure 5-1 shows the call flow using the Cisco Unified SIP Proxy with Cisco Unified Border Element. Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) 5-6 OL-16394-07

Chapter 5 Cisco Unified CM Trunks H.323 Trunks Figure 5-1 Call Flow for Cisco Unified SIP Proxy with Cisco Unified Border Element Service Provider IP ISR Cisco Unified SIP Proxy Firewall M SIP-SIP Cisco Unified Border Element-1 M M M M SIP-SIP Cisco Unified CM Cisco Unified Border Element-2 Signaling path 251633 SIP-SIP Media path Cisco Unified Border Element-3 Phone To originate a call to the service provider, Unified CM sends the call to the Unified SIP Proxy. The Unified SIP Proxy determines that the request came from Unified CM and forwards the call to a Unified Border Element. The Unified Border Element terminates and re-originates the call, and sends it back to the Unified SIP Proxy. The Unified SIP Proxy determines that the call came from a Unified Border Element, and this time forwards it to the service provider. Media is then established directly from the originating phone to the service provider via the Unified Border Element. For details on installing and configuring the Cisco Unified SIP Proxy, please refer to the product documentation available at http://www.cisco.com/en/US/products/ps10140/tsd_products_support_model_home.htmlH.323 Trunks The following major types of H.323 trunks can be configured in a Unified CM: • Intercluster Trunk (Non-Gatekeeper Controlled), page 5-7 • Intercluster Trunk (Gatekeeper Controlled), page 5-8 • H.225 Trunk (Gatekeeper Controlled), page 5-8Intercluster Trunk (Non-Gatekeeper Controlled) This trunk is the simplest and is used for connecting to other Unified CM clusters in either a multi-cluster single campus or a distributed call processing deployment. This trunk does not use a gatekeeper for call admission control, although it may use locations configured in Unified CM if bandwidth control is required. When defining this type of trunk, you may define up to three remote Unified CM servers in the same destination cluster. The trunk will automatically load-balance across all defined remote Unified CM servers. In the remote cluster, it is important to configure a corresponding intercluster trunk Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) OL-16394-07 5-7

Chapter 5 Cisco Unified CM Trunks H.323 Trunks (non-gatekeeper controlled) that has a Unified CM Group containing the same servers that were defined as remote Unified CM servers in the first cluster. A similar configuration is required in each Unified CM cluster connected by the intercluster trunks. For example, if Cluster 1 has a trunk to Cluster 2 and Cluster 2 has a trunk to Cluster 1, the following configurations would be needed: • Cluster 1 – Servers B, C, and D are configured as members of the Unified CM Group defined in the device pool associated with the trunk to Cluster 2. – The non-gatekeeper controlled trunk has Cluster 2s remote servers D, E, and F configured. • Cluster 2 – Servers D, E, and F are configured as members of the Unified CM Group defined in the device pool associated with the trunk to Cluster 1. – The non-gatekeeper controlled trunk has Cluster 1s remote servers B, C, and D configured.Intercluster Trunk (Gatekeeper Controlled) The intercluster gatekeeper controlled trunk should be used instead of the non-gatekeeper controlled trunk for a larger number of clusters. The advantages of using the gatekeeper controlled trunk are mainly the overall administration of the cluster and failover times. Non-gatekeeper controlled trunks generally require that a full mesh of trunks be configured, which can become an administrative burden as the number of clusters increases. In addition, if a subscriber server in a cluster becomes unreachable, there will be a 5-second (default) timeout while the call is attempted. If an entire cluster is unreachable, the number of attempts before either call failure or rerouting over the PSTN will depend on the number of remote servers defined for the trunk and on the number of trunks in the route list or route group. If there are many remote servers and many non-gatekeeper controlled trunks, the call delay can become excessive. With a gatekeeper controlled trunk, you configure only one trunk that can then communicate via the gatekeeper with all other clusters registered to the gatekeeper. If a cluster or subscriber becomes unreachable, the gatekeeper automatically directs the call to another subscriber in the cluster or rejects the call if no other possibilities exist, thus allowing the call to be rerouted over the PSTN (if required) with little incurred delay. With a single Cisco gatekeeper, it is possible to have 100 clusters all registering a single trunk each, with all clusters being able to call each other. With non-gatekeeper controlled trunks, this same topology would require 99 trunks configured in each cluster. The gatekeeper controlled intercluster trunk should be used for communicating only with other Unified CMs because the use of this trunk with other H.323 devices might cause problems with supplementary services. In addition, a gatekeeper controlled intercluster trunk must be used for backward compatibility with Unified CM prior to Release 3.2.H.225 Trunk (Gatekeeper Controlled) The H.225 gatekeeper controlled trunk is essentially the same as the intercluster gatekeeper controlled trunk except that it has the capability of working with Unified CM clusters (Release 3.2 and later) as well as other H.323 devices such as gateways, conferencing systems, and clients. This capability is achieved through a discovery mechanism on a call-by-call basis. (See H.323 Operation in Unified CM, page 5-15, for details of this discovery process.) This type of trunk is the recommended H.323 trunk if all Unified CM clusters are at least Release 3.2. Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) 5-8 OL-16394-07

Chapter 5 Cisco Unified CM Trunks H.323 TrunksGatekeeper Trunk Redundancy, Resilience, and Load Balancing Redundancy can be achieved in several ways, depending on the requirements of the design. The simplest method is to configure a gatekeeper controlled trunk and assign up to three subscribers in the Unified CM Group associated with the device pool assigned to that trunk. This configuration will cause all servers to register with the same gatekeeper in the same zone with the same technology prefix. However, the H.323 trunk name that is used for the h323_id will have a suffix of "_n" where n is the node number in the cluster. This ID is automatically generated and cannot be changed. You configure a single trunk, but the gatekeeper registers multiple trunks, one from each subscriber in the Unified CM Group. If you have additional redundancy requirements, it is possible to configure another gatekeeper controlled trunk with a different name and different subscribers in the Unified CM Group, but with all the other parameters identical to the first trunk. This second trunk will cause additional subscribers to register with the gatekeeper. Cisco recommends assigning device pools that contain a Unified CM Group consisting of the two servers that make up the standard subscriber pair. (See Call Processing Subscriber, page 8-8, for more information on subscriber redundancy.) For complete redundancy in each full cluster, four trunks would be needed, using four different device pools and resulting in eight subscribers registering with the gatekeeper. (The same result could be achieved with three trunks and larger Unified CM Groups.) During registration, several parameters are passed between Unified CM and the gatekeeper. Unified CM uses an ephemeral User Datagram Protocol (UDP) port for gatekeeper Registration Admission Status (RAS) messages. This port would normally be UDP 1719. However, Unified CM must be able to identify precisely which H.323 daemon is the originator of a RAS message from a particular server; therefore it uses a range of UDP ports and assigns them dynamically. During the registration process, a trunk registers the following information for the other subscribers in its Unified CM Group: • H.225 call signaling port • h323_id • CanMapAlias support • Technology prefix • H.225 call signaling address If the recommended clustered gatekeepers are used, the gatekeeper will return a list of alternate gatekeeper addresses that may be used if the primary gatekeeper fails or does not have sufficient available resources. Figure 5-2 shows a cluster of gatekeepers that use Gatekeeper Update Protocol (GUP) to communicate. (See the chapter on Call Processing, page 8-1, for more information on gatekeepers.) Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) OL-16394-07 5-9

Chapter 5 Cisco Unified CM Trunks H.323 Trunks Figure 5-2 Gatekeeper Cluster Element 1 GK Element 2 Element 3 GK GK GK GK 132273 Element 4 Element 5 If an H.323 trunk has only a single subscriber in its Unified CM Group, there will be only one connection between the configured gatekeeper in Unified CM and the gatekeeper cluster, as illustrated in Figure 5-3. Figure 5-3 H.323 Trunk with a Single Unified CM Subscriber Element 1 GK Element 2 Element 3 M GK GK Unified CM GK GK 132274 Element 4 Element 5 If there are multiple subscribers in the Unified CM Group associated with the trunk, additional connections will be established between the Unified CM cluster and the gatekeeper cluster, as illustrated in Figure 5-4. Figure 5-4 H.323 Trunk with Multiple Unified CM Subscribers Element 1 M GK Element 2 Element 3 M M GK GK M M GK GK 132275 Element 4 Element 5 This approach provides redundancy for subscriber failures as well as gatekeeper failures after registration because the alternate gatekeeper is communicated when the trunk registers. This approach does not, however, provide redundancy if the configured gatekeeper is unavailable at initial registration Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x)5-10 OL-16394-07

Chapter 5 Cisco Unified CM Trunks H.323 Trunks or following a reset because the list of alternate gatekeepers is dynamic and not stored in the database. To provide an additional level of redundancy as well as load balancing, an additional gatekeeper from the gatekeeper cluster is configured in Unified CM. For example, if the original trunk is registered with Element 2, the additional gatekeeper could be configured as Element 4, as illustrated in Figure 5-5. Figure 5-5 Additional Gatekeeper Configured for Load Balancing and Additional Redundancy Element 1 A M GK Element 2 Element 3 M M GK GK B M M GK GK 132276 Element 4 Element 5 The Unified CM configuration for the example in Figure 5-5 would contain the following components: • Two gatekeepers for Element 2 and Element 4 • Two H.323 trunks defined with a Unified CM Group containing subscriber servers A and B Using this approach, the Unified CM cluster will still be able to register when either Element 2 or Element 4 is not reachable during initial registration (that is, during power-up or trunk reset). Load balancing of calls inbound to the Unified CM cluster is done automatic by default because the gatekeeper randomly selects one of the subscribers registered within the zone. If this is not the desired behavior, you can use the gw-priority configuration command in the gatekeeper to modify this default behavior, as illustrated in Example 5-1. Example 5-1 Using the gw-priority Command to Direct Calls to a Particular Trunk gatekeeper zone local SJC cisco.com 10.0.1.10 zone prefix SJC 1408....... gw-priority 10 sjc-trunk_2 zone prefix SJC 1408....... gw-priority 9 sjc-trunk_3 zone prefix SJC 1408....... gw-default-priority 0 gw-type-prefix 1#* default-technology arq reject-unknown-prefix no shutdown endpoint ttl 60 In Example 5-1, the H.323 trunk was configured as sjc-trunk in Unified CM, and the “_2” and “_3” suffixes are appended automatically by the Unified CM subscribers to indicate which node number they are in the cluster. Therefore, this example uses node 2 as the first choice, which should be the highest-priority Unified CM in the Unified CM Group for this trunk. Node 3 is the second choice in this case. The use of gw-default-priority 0 is optional. It was used in this example to disable the use of any other trunk that might accidentally be configured to register in this zone. Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x)OL-16394-07 5-11

Chapter 5 Cisco Unified CM Trunks H.323 Trunks Load Balancing Outbound Calls In the majority of cases, the standard method of assigning Unified CM Groups to devices is sufficient to handle the call distribution of outbound calls over IP trunks from call processing subscribers. IP trunk calls might appear to originate randomly from call processing subscribers, but the trade-off for this random call origination is reduced call processing and reduced Intra-Cluster Communication Signaling (ICCS) traffic within the cluster. Load balancing of outbound IP trunk calls across call processing servers, as described below, can be counter-productive because the advantages gained from predictable call origination within the cluster can be outweighed by the increase in ICCS traffic created by calls from phones registered to one subscriber extending their communication to another server within the cluster to originate the outgoing IP trunk call. Note In configurations where a route list is employed to help choose the outbound trunk, the selection of the subscriber may be different than that explained above. Instead of preferring the subscriber that has the calling endpoint registered to it and that also hosts the trunk, Unified CM may choose the subscriber that hosts both the route list and the trunk. For this reason, the selection of the outbound trunk might no longer minimize ICCS traffic between subscribers. To minimize ICCS traffic when route lists are used, Cisco recommends using a different set of subscribers in the Unified CM Group associated with the route list than the set of subscribers used in the Unified CM Group associated with the trunks. For the initiation of outbound calls over an H.323 trunk, the following key factors within a Unified CM cluster determine which server is selected: • Which Unified CM servers have an active H.323 daemon for the selected trunk • Whether the phone originating the call is registered to a Unified CM server with an active H.323 daemon for the selected trunk For IP trunks, the server selection process is not as intuitive as it is for H.323 connections to gateways where, for example, route lists and route groups can be used to select the gateway(s) used to originate the call to the PSTN and also to provide call distribution among multiple gateways. While the route list and route group process still operates for trunk selection and call distribution, a second process is also in operation to select the server from which the H.323 call will originate. In other words, after the route list and route group configuration selects the outgoing trunk, one server in the Unified CM Group for the selected trunk must be chosen to originate the H.323 call. For all IP trunks, this process of server selection for outgoing calls is as follows: • If there is an active H.323 daemon for the selected trunk on the Unified CM server to which the phone or device originating the call is registered (that is, if the server is one of those listed in the trunks Unified CM Group), then use this Unified CM server to originate the H.323 call. • If there is no active H.323 daemon for the selected trunk on the Unified CM server to which the phone or device originating the call is registered, then select a server on a round-robin basis from the Unified CM Group of the selected trunk. Note All servers defined in a trunks Unified CM Group will run an active H.323 daemon for that trunk. On each server defined within a trunks Unified CM Group, a unique H.323 daemon is created for each H.323 trunk. To provide predictable and deterministic load balancing for outgoing calls over IP trunks, you must consider the trunk selection behavior described above. Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x)5-12 OL-16394-07

Chapter 5 Cisco Unified CM Trunks H.323 Trunks Subscriber-based load balancing of outgoing IP trunk calls can be achieved as follows: • To load-balance outbound trunk calls across only a subset of the call processing servers in the cluster, define multiple trunks and assign only a single subscriber to the Unified CM Group of each trunk. • If you want subscriber redundancy within Unified CM Groups, the easiest way to provide predictable subscriber load balancing of outbound trunk calls is to ensure that the subscribers used to register phones are different from those initiating trunk calls. For example, to spread outbound trunk calls across four subscribers in the cluster, perform the following tasks: • Configure four H.323 trunks with four Unified CM Groups, all contained within a route group with circular call distribution. • Define Unified CM Groups as follows: – Group A: Subscriber A – Group B: Subscriber B – Group C: Subscriber C – Group D: Subscriber D With no backup subscribers defined, if the primary subscriber for the specified trunk fails, Unified CM will re-route outgoing calls to the next trunk in the route group. In the example above, backup subscribers can be defined within each Unified CM Group for each trunk provided, using subscribers A, B, C, and D as follows: • Group A: Subscriber A; Subscriber B • Group B: Subscriber B; Subscriber C • Group C: Subscriber C; Subscriber D • Group D: Subscriber D; Subscriber A However, to avoid subscriber selection for outgoing trunk calls based on phone registration and H.323 daemon subscriber co-location, all phones in the cluster should be registered to other call processing servers (for example, subscribers E, F, G, and H), with server redundancy as required using Unified CM Groups. To spread outbound trunk calls across all eight subscribers in a cluster, perform the flowering tasks: • Configure eight H.323 trunks with eight different Unified CM Groups, each containing only one subscriber and all contained within a circular route group. • Define Unified CM Groups as follows: – Subscriber A – Subscriber B – Subscriber C – Subscriber D – Subscriber E – Subscriber F – Subscriber G – Subscriber H Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x)OL-16394-07 5-13

Chapter 5 Cisco Unified CM Trunks H.323 Trunks with Media Termination PointsH.323 Trunks with Media Termination Points Media termination points (MTPs) are generally not required for normal operation of the H.323 trunk. They are, however, required for communication with devices that are H.323 Version 1, that do not support the Empty Capabilities Set (ECS) for supplementary services, or that require H323 FastStart. To test whether or not an MTP is required, use the following simple procedure: 1. Place a call from a phone via the H.323 trunk to the other device. This call should work normally. 2. Place the call on hold, then resume it. If the call drops, then it is highly likely that an MTP is required to ensure interoperability between Unified CM and the other device.H323 Outbound FastStart Call Connections Calls that are placed from IP phones over large WAN topologies can experience voice clipping when the called party goes off-hook to answer the call. When H.323 trunks or gateways are separated from the Unified CM server, significant delays can occur because of the many H.245 messages that are exchanged when a call is set up. With the FastStart feature, information that is required to complete a media connection between two parties gets exchanged during the H.225 portion of call setup, and this exchange eliminates the need for H.245 messages. The connection experiences one round-trip WAN delay during call setup, and the calling party does not experience voice clipping when the called party answers the call. Unified CM uses media termination points (MTP) for making an H.323 outbound FastStart call. Unified CM starts an outbound FastStart call by allocating an MTP and opening the receive channel. Next, the H.323 Fast Connect procedure sends the SETUP message with a FastStart element to the called endpoint. The FastStart element includes information about the receiving channel for the MTP.Other MTP Uses MTPs are very useful for terminating media streams from other devices that make calls over the H.323 trunk and for re-originating the media streams with the same voice payload; however, in such cases the IP address is changed to that of the MTP. With this fact in mind, you can utilize MTPs in the following scenarios: • If the phones, gateways, and other devices within your enterprise all use RFC 1918 private addresses, you might still want to connect to other systems on a public network without using Network Address Translation (NAT) for all your voice and video devices. If the Unified CM subscriber that communicates to the public network is using a public IP address, the signaling will be routed. If all MTPs are also using public addresses, the media from the devices with RFC 1918 addresses will be terminated on the MTP and then originated again, but this time with a public address that is routable on the public network. This approach allows tens of thousands of devices with RFC 1918 addresses to communicate with the public network. This same method can be used to conceal the real IP addresses of devices in an enterprise network when communicating with other enterprises or service providers. • Trust boundaries can be established to traverse firewalls or to allow access through an access control list (ACL). Normally, for media to traverse a firewall, you could either use an Application Layer Gateway (ALG) or fix-up to provide access dynamically for the media streams or you could allocate a wide range of addresses and ports for use by all voice devices that need to communicate across the firewall. All calls that use the H.323 trunk and traverse a firewall or ACL will have media that is sourced from the MTP(s), which may use either a single IP address or a small range of IP addresses. Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) 5-14 OL-16394-07

Chapter 5 Cisco Unified CM Trunks H.323 Operation in Unified CM With both of these methods, if the MTP Required box is checked, the default behavior is to allow calls on the H.323 trunks even if MTP resources are unavailable or exhausted. This default behavior might result in no voice path for the call, but the behavior can be changed by setting the Unified CM service parameter Fail Call if MTP allocation fails under the H.323 section to True.H.323 Operation in Unified CM This section provides information on how the H.323 protocol is used and implemented in Unified CM, and it explains how and why certain features work the way they do. The most important point to understand is which subscribers run the call signaling daemons. These daemons are pieces of code that make and receive H.323 calls. They are usually referred to as H.225 daemons, or H.225Ds. H.225 is part of the H.323 protocol and is mainly responsible for call control. H.245 is the other major component of H.323 that is responsible for the media control of a call. The subscribers listed in the Unified CM Group for a particular H.323 device determine which subscribers run the daemons and when. This point is a very important because calls sent to an incorrect subscriber might be rejected. For example, this situation would occur if a Cisco IOS H.323 gateway is configured with dial peers that send calls to subscriber C in a Unified CM cluster but the Unified CM Group for that gateway has only subscribers A and B in its list. In such a case, the call will fail or be handled by an H.323 trunk daemon if one happens to be configured on the subscriber. The following scenarios describe where and when H.225Ds are created on subscribers: • H.323 client The H.225D is active on only the highest-priority subscriber available in the Unified CM Group associated with the H.323 client. If the H.323 client is gatekeeper controlled, the RasAggregator device registers from only the highest-priority subscriber available in the Unified CM Group associated with the gatekeeper controlled H.323 client. The RasAggregator is a special device that registers in gatekeeper zones for the purpose of providing two specific features: – If H.323 clients use DHCP, they cannot be used with a Unified CM using DNS unless they support Dynamic DNS. With the RasAggregator, Unified CM can obtain the IP address of a specific H.323 client that is registered with the gatekeeper whenever a call is placed. The gatekeeper registration is done using standard RAS ARQ messages that contain the E.164 address of the H.323 client. The gatekeeper resolves the E.164 address and provides the IP address back to Unified CM in an ACF message. – The RasAggregator also ensures that all calls by the H.323 clients are made through Unified CM and not directly between the clients themselves, thus ensuring that dialing rules and codec restrictions are enforced. • H.323 gateway The H.225D is active on all subscribers in the Unified CM Group associated with the H.323 gateway. • H.323 trunks The H.225D is active on all subscribers in the Unified CM Group associated with the H.323 trunk. A RAS daemon registers the trunk with the gatekeeper from all subscribers in the associated Unified CM Group. Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) OL-16394-07 5-15

Chapter 5 Cisco Unified CM Trunks H.323 Operation in Unified CM When an incoming H.323 call is made to a subscriber in a Unified CM cluster, various decisions are made to determine if the call is accepted or rejected and which H.225D will receive the call if it is accepted. Figure 5-6 shows how this process works. Figure 5-6 Process for Determining if an H.323 Call is Accepted or Rejected Check H.225 TCP Inbound H.323 call connection peer IP Process call as if from address against Matchto Cisco Unified CM configured gateway subscriber configured H.323 or client gateways or clients for this subscriber No Match Check if Gatekeeper Equals Port 1720 Controlled Trunk Is the “Accept Unknown Reject Examine signaling No No has been configured TCP Connections” service H.225 TCP port number to used 1720 in the parameter set toTrue? connection service parameters Not equal to Port 1720 Yes Accept inbound Does the port number H225 TCP connection. match a dynamic port used No match for a configured Gatekeeper Controlled Trunk for this Wait for H.225 subscriber? setup message, then extract source Match signaling address Process call as an incoming Gatekeeper Controlled Process call, Trunk call Check H.225 signaling Match sourcing it address against configured as if from H.323 gateways configured gateway No match Send ARQ to gatekeeper; Process call using the H225ReleaseComplete IP peer address with cause IE - 132369 Call Rejected; User hears reorder tone Unified CM H.323 protocol includes the following additional features: • Protocol Auto Detect This feature provides the ability to determine, on a call-by-call basis, if the calling device is from Cisco Unified CM Release 3.2 or later. Whenever a call is received, Unified CM looks for an H.225 User-to-User Information Element (UUIE) that indicates if the other end is another Unified CM. If it is, it will always use the Intercluster Trunk Protocol. If no UUIE is found, it will use the configured protocol for that device. This feature enables an H.225 gatekeeper controlled trunk to switch between Intercluster Trunk Protocol and H.225 on a call-by-call basis, allowing a mixture of Unified CM clusters and other H.323 devices to use the gatekeeper. Intercluster Trunk Protocol is the same as H.225 except for several differences that enable specific features to work correctly between Unified CM clusters. Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x)5-16 OL-16394-07

Chapter 5 Cisco Unified CM Trunks SIP Trunks • Tunneled Q.SIG or H.323 Annex M1 With the release of Cisco Unified CM 4.1(3), this feature can be enabled on all H.323 trunks. It allows specific H.323 Annex M1 features to be implemented between Unified CM clusters and other verified systems that also support H.323 Annex M1. These features include: – Path replacement – Message waiting indication (MWI) – Callback • Alternate Endpoints When registering with a gatekeeper that supports this feature, such as a Cisco Multimedia Conference Manager (MCM) Gatekeeper, Unified CM can inform the gatekeeper of alternate destinations for calls to the H.323 trunk. These alternate endpoints or destinations are sent to the calling device by the gatekeeper when this H.323 trunk is called. They are the other subscribers listed in the Unified CM Group associated with the H.323 trunk that registers with the gatekeeper. • Alternate Gatekeeper When an H.323 trunk registers with a gatekeeper that supports this feature (for example, a Cisco gatekeeper cluster), Unified CM is dynamically informed about other gatekeepers that can process registrations, call admission requests, and other RAS functions in the event that this gatekeeper fails or exhausts its own resources. • CanMapAlias When an H.323 trunk sends an admission request (ARQ) to the gatekeeper, it might receive a different E.164 number in the admission confirmation message (ACF), indicating that the original called number should be replaced with this new one. This feature requires a route server using Gatekeeper Transaction Message Protocol (GKTMP) to communicate with Cisco gatekeepers. Note CanMapAlias is supported for the called number only. • Bandwidth Requests H.323 trunks can update the gatekeeper with bandwidth information to indicate a change in the requested bandwidth allocated to a specific call. This feature is disabled by default and is controlled by setting the Unified CM service parameter BRQ Enabled to True, under the H.323 section. This feature is especially important when video is used on an H.323 trunk because the original bandwidth request is for the maximum amount allowed. Enabling this feature ensures that call admission control uses the actual bandwidth negotiated during call setup.SIP Trunks As with H.323 trunks, there are several design considerations to be taken into account when deploying SIP trunks. This section describes those design considerations.General Deployment Considerations For SIP trunk connections to third-party devices, such as SIP-based PBXs or service-provider IP PSTN connections, Cisco recommends the use of Delayed Offer for outbound calls from Unified CM and either Delayed Offer or Early Offer for inbound calls to Unified CM. Using Delayed Offer for outbound calls Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) OL-16394-07 5-17

Chapter 5 Cisco Unified CM Trunks SIP Trunks removes the requirement to assign MTP resources to the SIP trunk, except in cases where a mismatch in DTMF transport types exists between the called and calling endpoints (in which case Unified CM will insert an MTP dynamically). As previously mentioned, Cisco also recommends the deployment of the Cisco Unified Border Element on any IP PSTN SIP trunk connection from Unified CM to a voice service provider. SIP Delayed Offer, Early Offer, and DTMF are discussed in more detail in the subsequent sections.DTMF Transport There are several methods of transporting DTMF information between SIP endpoints. In general terms, these methods can be classified as out-of-band (OOB) and in-band signaling. In-band DTMF transport methods send either raw or signaled DTMF tones within the RTP stream, and they need to be handled and interpreted by the endpoints that generate and/or receive them. Out-of-band (OOB) signaling methods transport DTMF tones outside of the RTP path, either directly to and from the endpoints or via a call agent such as Cisco Unified CM, which interprets and/or forwards these tones as required. Out-of-band (OOB) SIP DTMF signaling methods include Unsolicited Notify (UN), Information (INFO), and Key Press Markup Language (KPML). While KPML (RFC 4730) is the OOB signaling method preferred by Cisco, KPML is not widely used in the market place at this time. Currently, the only known products supporting KPML are Cisco Unified CM, Cisco IOS Gateways (Release 12.4 and later), and some models of Cisco IP Phones. Unsolicited Notify is a nonstandard method and is used only on Cisco IOS Gateways (Release 12.2 and later). INFO is not supported by Unified CM. In-band DTMF transport methods send DTMF tones as either raw tones in the RTP media stream or as signaled tones in the RTP payload using RFC 2833. Among SIP product vendors, RFC 2833 has become the predominant method of sending and receiving DTMF tones and is supported by the majority of Cisco voice products. Because in-band signaling methods send DTMF tones in the RTP media stream, the SIP endpoints in a session must either support the transport method used (for example, RFC 2833) or provide a method of intercepting this in-band signaling and converting it. If the two endpoints are using a back-to-back user agent (B2BUA) server for the call control (for example, Cisco Unified CM) and the endpoints negotiate different DTMF methods between each device and call control box, then the call control box determines how to handle the DTMF differences, either via MTP insertion or via OOB methods. With Unified CM, a DTMF transport mismatch (for example, in-band to out-of-band DTMF) is resolved by inserting a Media Termination Point (MTP), which terminates the RTP stream with in-band DTMF signaling (RFC 2833), extracts the DTMF tones from the RTP stream, and forwards these tones out-of-band to Unified CM, where they are then forwarded to the endpoint supporting out-of-band signaling. In this case, the MTP is always in the media path between the two endpoints because there is no MTP codec dependency for DTMF translation. In-band DTMF tones can also be transported as raw (audible) tones in the RTP media stream. This transport method is not widely supported by Cisco products and, in general, is not recommended as an end-to-end DTMF transport mechanism. In-band audio DTMF tones can generally be reproduced reliably only when using G.711 a-law or mu-law codecs, and they are not suitable for use with low-bandwidth codecs. In cases where in-band audio is the only available DTMF transport mechanism, the Cisco Unified Border Element can be used to translate the in-band audio DTMF signaling into RFC 2833 signaling. Over Unified CM SIP trunks, Cisco recommends configuring the DTMF Signaling Method to No Preference. This setting allows Unified CM to make an optimal decision for DTMF and minimize MTP allocation. Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) 5-18 OL-16394-07

Chapter 5 Cisco Unified CM Trunks SIP TrunksSIP Delayed Offer and Early Offer Cisco Unified CM uses the SIP Offer/Answer model for establishing SIP sessions, as defined in RFC 3264. In this context, an Offer is contained in the Session Description Protocol (SDP) fields sent in the body of a SIP message. The Offer typically defines the media characteristics supported by the device (media streams, codecs, directional attributes, IP address, and ports to use). The device receiving the Offer sends an Answer in the SDP fields of its SIP response, with its corresponding matching media streams and codec, whether accepted or not, and the IP address and port on which it wants to receive the media streams. Unified CM uses this Offer/Answer model to establish SIP sessions as defined in the key SIP standard, RFC 3261. RFC 3261 defines two ways that SDP messages can be sent in the Offer and Answer. These methods are commonly known as Delayed Offer and Early Offer, and support for both methods by User Agent Client/Servers is a mandatory requirement of the specification. In the simplest terms, an initial SIP Invite sent with SDP in the message body defines an Early Offer, whereas an initial SIP Invite without SDP in the message body defines a Delayed Offer. In an Early Offer, the session initiator (calling device) sends its capabilities (for example, codecs supported) in the SDP contained in the initial Invite (thus allowing the called device to choose its preferred codec for the session). In a Delayed Offer, the session initiator does not send its capabilities in the initial Invite but waits for the called device to send its capabilities first (for example, the list of codecs supported by the called device, thus allowing the calling device to choose the codec to be used for the session). Delayed Offer and Early Offer are the two media capabilities exchange options available to all standards-based SIP switches. Most vendors have a preference for either Delayed Offer or Early Offer, each of which has its own set of benefits and limitations. Note Unified CM can support Delayed Offer in one direction and Early Offer in the other direction. This capability can often be useful in situations where a SIP switch connecting to Unified CM via a SIP trunk wishes to control the codecs offered and selected for inbound and outbound calls (that is, where using Delayed Offer outbound from Unified CM and Early Offer inbound to Unified CM allows the service provider to send the Offer in all cases and, in doing so, to decide which codecs are offered for all calls.) Early Media In certain circumstances, a SIP session might require that a media path be set up prior to the finalization of the media capabilities exchange between the two SIP endpoints. To this end, the SIP protocol allows the establishment of Early Media after the initial Offer has been received by an endpoint. Some reasons for using Early Media include: • The called device might want to establish an Early Media RTP path to reduce the effects of audio cut-through delay (clipping) for calls experiencing long signaling delays or to provide a network-based voice message to the caller. • The calling device might want to establish an Early Media RTP path to access a DTMF or voice-driven IVR system. Unified CM supports Early Media for both Early Offer and Delayed Offer calls. Note The terms Early Offer and Early Media are often confused; they are not the same. Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) OL-16394-07 5-19

Chapter 5 Cisco Unified CM Trunks SIP TrunksMedia Termination Points Media Termination Points (MTPs) are generally not required for Delayed Offer calls from Unified CM SIP trunks. For this reason, Cisco recommends Delayed Offer as the call setup method for outbound calls from Unified CM SIP trunks. For outbound Early Offer calls from Unified CM, MTP resources are required (SIP Trunk MTP required box is checked and the desired codec to be offered is selected) and remain in the media path for the duration of the call. For calls inbound and outbound from Unified CM, endpoints can negotiate the use of RFC 2833 or an out-of-band DTMF method (for example, KPML) end-to-end. If a common DTMF method cannot be negotiated between the endpoints, Cisco Unified CM 5.x and later releases will insert an MTP dynamically. Cisco Unified CM 5.x and later releases support Delayed Offer (Invite without SDP) by default. Although Delayed Offer is a mandatory part of the SIP RFC 3261 specification, some SIP applications do not support it. In those cases, you must configure the SIP trunk to support Early Offer by pre-allocating an MTP under the SIP Trunk configuration. MTPs are available in three forms: • Software-based MTPs in Cisco IOS gateways — Available with any Cisco IOS T-train software release and scaling up to 500 sessions (calls) on the Cisco 3845 Integrated Services Router • Hardware-based MTPs in Cisco IOS gateways — Available with any Cisco IOS T-train software release, hardware MTPs use on-board DSP resources and scale calls according to the number of DSPs supported on the Cisco router platform • Software-based MTPs using the Cisco IP Voice Media Streaming Application on a Cisco Media Convergence Server (MCS) The following example configuration is for a Cisco IOS software-based MTP: ! sccp local Vlan5 sccp ccm 10.10.5.1 identifier 5 version 5.0.1 ! Communications Manager IP address (10.10.5.1) sccp ! sccp ccm group 5 bind interface Vlan5 associate ccm 5 priority 1 associate profile 5 register MTP000E83783C50 ! MTP name (MTP000E83783C50) … must match the Unified CM MTP name. ! dspfarm profile 5 mtp description software MTP codec g711ulaw codec pass-through maximum sessions software 500 associate application SCCP Note that either software or hardware MTPs in the Cisco IOS gateways must be used if the G.729 codec is selected for early offer. For more information on MTPs, see the chapter on Media Resources, page 6-1.SIP Trunk Transport Protocols SIP trunks can use either TCP or UDP as a message transport protocol. As a reliable, connection-orientated protocol that maintains the connection state, TCP is preferred because failover to an alternative trunk is nearly instantaneous on the failure of the destination device at the far end of the SIP trunk. UDP is not connection-orientated and therefore relies on the SIP protocol stack to determine if the destination device at the end of the SIP trunk is unavailable. For UDP-based SIP trunks, Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) 5-20 OL-16394-07

Chapter 5 Cisco Unified CM Trunks SIP Trunks Unified CM uses the values for the SIP Invite Retry count and SIP Trying timers to detect and respond to far-end device failures. By default, the failover time is approximately 64 seconds per call, but these timers can be tuned to reduce failover times to acceptable values. For more information on SIP trunk timer tuning, refer to the configuration example and technical notes at: http://www.cisco.com/en/US/products/sw/voicesw/ps556/products_configuration_example09186a 008082d76a.shtmlSIP Intercluster Trunks One of the main benefits of using SIP trunks for intercluster trunking is call survivability. However, as compared to H.323 trunks, SIP trunks do not support QSIG Tunneling using Annex M1. For outbound calls over SIP trunks using destination IP addresses rather than DNS, subscriber load balancing can be achieved in the same way as for H.323 trunk calls. (See the H.323 section on Load Balancing Outbound Calls, page 5-12.) Unlike H.323 trunks in Cisco Unified CM Release 3.3 and above, SIP trunks can point to only a single IP address or DNS Server (SRV) record. To provide failover and load balancing for intercluster SIP trunks that are not capable of DNS SRV, configure multiple SIP trunks. In addition, these SIP trunks must be members of route groups and route lists. Also, it is important to note that Unified CM accepts calls only from a SIP device whose IP address matches one of the destination addresses of the configured SIP trunks. In addition, the incoming port number of the SIP messages has to match the port number configured for that SIP trunk. As a consequence, Cisco recommends that you configure as many SIP trunks with destination addresses as needed to match all IP addresses of any far-end SIP devices that can potentially place an inbound call. This method is not desirable for deployments with more than two Unified CM clusters, and it is better to use SIP trunks with DNS SRV if there are more than two clusters. Figure 5-7 shows the call flow for an intercluster SIP trunk call using DNS SRV. Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) OL-16394-07 5-21

Chapter 5 Cisco Unified CM Trunks SIP TrunksFigure 5-7 Call Flow for Intercluster SIP Trunk Using DNS SRV DNS Server fo .c om 3 6 2. oo o.c DN 1 50 60 C o. om st r2 .fo 10 1 5 m S lu te r2 20 co SR CC M4 .c us te er .f -B .cl lusCluster1 Cluster2 V 60 C -A : c 0 Lo C CM upCluster FQDN: cluster1.foo.com Cluster FQDN: cluster2.foo.com ok .clu ster 60 C ok up 50 0 Lo M3 .clu C : c ter1 .foo 1 506 RV M lus 20 0 1 S CCM4 CCM-D s 1 NS ter M M D 1.f .com . .fo .co 2 oo 1 o .co CCM3 CCM-C m M M 4 . m S Src: IP invite CCM :8 3.clu 752200 ster1 1 CCM2 M .foo.c @cluster M CCM-B om D 2. st: C foo.com CM-A 5 .clus ter 2.foo CCM1 .com CCM-A M M Route Pattern: 8752XXXX SIP Trunk Dst: DSN SRV cluster2.foo.com Route Pattern: 8752XXXX SIP Trunk Dst: DSN SRV cluster2.foo.com 141884 1 IP IP Calls 87522001 8-645-3001 8-752-2001 Note: The DNS A Lookup has been removed from this call flow Figure 5-7 illustrates the following steps in the call flow: 1. The IP phone in Cluster1 calls 87522001. 2. The call matches a route pattern of 8752XXXX that is pointing to SIP Trunk with DNS SRV of cluster2.foo.com. CCM3 in Cluster1 is the node handling this call because the SIP trunk is registered to it. CCM3 sends a DNS SRV lookup for cluster2.foo.com 3. The DNS server replies with two records: CCM-A.cluster2.foo.com and CCM-B.cluster2.foo.com. Because CCM-A.cluster2.foo.com has a higher priority, the call is attempted to this Unified CM. Before sending the SIP invite, another DNS lookup is done for CCM-A.cluster2.foo.com. 4. CCM3 sends a SIP invite to [email protected] with destination address set to the IP address of CCM-A. 5. Unified CM interprets this call as a local call because the host portion of the uniform resource identifier (URI) matches the Cluster FQDN enterprise parameter. Cluster2 does not have any SIP trunk configured with a destination of CCM3, so it does a DNS SRV lookup for all domains configured under the SIP trunks with DNS SRV. In this case, the example shows a single trunk with a DNS SRV destination of cluster1.foo.com Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) 5-22 OL-16394-07

Chapter 5 Cisco Unified CM Trunks SIP Trunks 6. The DNS server returns two entries, and one of them matches the source IP address of the invite. The cluster accepts the call and extends it to extension 87522001.SRTP in SIP Trunks Secure RTP (SRTP) is supported over SIP trunks in Cisco Unified CM 7.0 and later releases. SRTP requires that the trunk be established using an encrypted TLS connection with the remote side. SRTP parameters are exchanged in the SIP SDP messages over this trunk. An MTP does not support SRTP; therefore, for SRTP, the MTP Required flag in the trunk configuration must be left unchecked. This implies that Unified CM will support SRTP with Delayed Offer calls only. However, if Unified CM dynamically inserts an MTP for reasons other than Early Offer, such as for a Trusted Relay Point or as an RSVP agent, then SRTP will be supported through the MTP. Note that dtmf-relay using MTP (where the MTP needs to convert between in-band and out-of-band DTMF signals) will not function for SRTP because it will be unable to decrypt the DTMF packets in the media stream.Calling Party Number Normalization and SIP Trunks Unified CM 7.0 introduces the capability to transform calling party numbers of calls inbound over gateways and trunks to a normalized format. Typically, you would want this format to be the globally routable, international representation of the number as per E.164 specifications. The process of normalization relies on receiving the number and the associated number-type of the incoming call. The number-type parameter can be used to select the appropriate digits to prefix to the calling number. Number-types can be one of four types: Unknown, Subscriber, National, or International. For more details and examples on how these number-types are used, refer to the chapter on Dial Plan, page 10-1. You can specify the prefix digits for each of the four number types in the H.323 trunk and H.323 gateway configuration pages in Unified CM. H.323 can transport these number types in its signaling. SIP, on the other hand, is unable to transport the number-type information in its signaling. Thus, a call coming in via a SIP gateway across a SIP trunk to Unified CM will not have any indication of whether the calling-party number is local, national, or international. Without the number-type information, Unified CM is unable to apply the correct prefix to the calling-party number. The inability of the SIP trunk to transport the number type implies that the normalization of the calling number must be performed before the call is presented to Unified CM. One place where the transformation can be performed is on the ingress SIP gateway. The following example configuration shows the translation rules that can be defined on a Cisco IOS gateway to accomplish this transformation: voice translation-rule 1 rule 1 // /+4940/ type subscriber subscriber rule 2 // /+49/ type national national rule 3 // /+/ type international international ... voice translation-profile 1 translate calling 1 ... Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) OL-16394-07 5-23

Chapter 5 Cisco Unified CM Trunks Codec Selection Over IP Trunks dial-peer voice 300 voip translation-profile outgoing 1 destination-pattern .T session protocol sipv2 session target ipv4:9.6.3.12 ... When configured as in the example above, a Cisco IOS gateway using SIP to communicate with Unified CM will send calling party information digits normalized to the E.164 format, including the + sign. The Unified CM configuration will receive all calls from this gateway with a numbering type of "unknown," and would not need to add any prefixes. For more details on configuring translation rules, please refer to the document Voice Translation Rules, available at http://www.cisco.com/en/US/tech/tk652/tk90/technologies_tech_note09186a0080325e8e.shtml Unified CM can set the calling party number of outgoing calls to the normalized global format. The number-type in outgoing calls from the SIP trunk will be unknown, and the Cisco IOS gateway should change it to International if no stripping is done, or perform a combination of stripping and numbering type change if required by the connected service provider.Codec Selection Over IP Trunks Before media between communicating entities can be established, both the entities must agree on the codec(s) that they want to use. This codec (or codecs in case of video) is derived from the intersection of codecs supported by entities involved and the configured policy in Unified CM. Policy in Unified CM is configured by region settings. The inter-region codec for audio and the inter-region bandwidth setting for video (that includes audio) determine the set of codecs that will be used between devices contained in the respective regions. Note that the codec setting indicates only the maximum bandwidth that is allowed for devices communicating across those regions and does not specify the exact codec that will be used for every call. If the entities share several codecs in common and the inter-region setting allows the selection of more than one codec, Unified CM will select the codec with the best quality. For example, if the inter-region audio codec setting between a trunk and an IP phone is set to G.729 (a low-bandwidth codec) and both endpoints indicate support for G.729, then that codec will be selected. However, if the inter-region codec is set to G.711 (a high-bandwidth codec) and both endpoints indicate support for G.711, G.722, and G.729, then Unified CM will choose G.722 because this codec will deliver the best audio quality. An exception to this rule is the selection of the iLBC codec. If both sides indicate support for the iLBC codec, if the use of the codec is enabled, and if the inter-region settings specify the Link Loss Type between the regions as lossy, then iLBC will be used and its choice will override the best-quality rule. Note If MTP Required is checked for the trunk, then the codec specified for the MTP will be used regardless of other settings. In this case, the inter-region codec settings must be configured appropriately to allow this codec. Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) 5-24 OL-16394-07

Chapter 5 Cisco Unified CM Trunks Cisco Unified CM Trunks and Emergency ServicesCisco Unified CM Trunks and Emergency Services IP trunks might be unable to deliver emergency 911 calls or, like centralized PSTN trunks, might be unable to deliver such calls to the appropriate Public Safety Answering Point (PSAP) for the callers location. Customers must investigate carefully the capabilities of the IP trunk service provider to deliver emergency 911 calls and caller locations to the appropriate PSAP. Cisco Emergency Responder may be used to provide the location-specific calling party number to the IP trunk service provider for emergency 911 calls. Centralized IP or PSTN trunks might also temporarily become unavailable for emergency 911 calls from remote locations due to WAN congestion or failure. For this reason, remote locations should always have local gateways to the PSTN that are capable of delivering emergency 911 calls. For more information, see Emergency Services, page 11-1.Design Recommendations for Deploying IP Trunks Use the following guidelines and best practices when deploying IP trunks from Cisco Unified CM: • Choose the trunk protocol. Decide between using an H.323 or SIP trunk, based on your system requirements and the desired features. For example, if Q.SIG tunneling is required when connecting with a PBX, use H.323. The choice might also be determined by the version of Unified CM you have deployed. SIP trunk capabilities have been greatly enhanced in Unified CM 5.1(2) and later releases, so SIP would be a good choice when using one of these versions. • SIP trunks in Unified CM 4.x always require an MTP for outbound calls and are limited to the G.711 codec for voice communication. Ensure that there are enough MTP resources for the expected number of simultaneous calls. • SIP trunks in Unified CM 5.x and later releases offer a choice of whether to allocate an MTP for each outgoing call, and an MTP is not used by default. If the remote end does not require Early Offer (Offer SDP in initial INVITE), optimize MTP resource usage by using Delayed Offer. • Voice clipping, if observed, can be minimized or eliminated by enabling PRACK on the trunk. This parameter can be enabled in the Service Parameters for the Cisco CallManager service (SIP Rel1XX Enabled). • Other operating parameters for security settings and the types of messages accepted over a SIP trunk can be enabled in the SIP Trunk Security Profile. Here you can set parameters not only for TLS and Digest Authentication, but also for whether or not the trunk will accept Presence Subscription, an out-of-dialog REFER message, Replaces header, or an unsolicited notification. • When connecting to service provider networks, Cisco recommends the use of the Cisco Unified Border Element. In addition to providing a demarcation point between the enterprise and service provider network, the Cisco Unified Border Element can also be used for enhancing SIP signaling interoperability between the two networks. • With Unified CM 7.x, the low bandwidth codec, G.729, is available in Early Offer in addition to G.711. However, only one of these codecs may be signaled in the Early Offer. Multiple codecs in the early offer, or transformation of a Delayed Offer call from Unified CM to an Early Offer call, can be accomplished by the Cisco Unified Border Elements Delayed Offer to Early Offer feature. • If you are using SRTP over the SIP trunk, Delayed Offer is the only mode supported from Unified CM. Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) OL-16394-07 5-25

Chapter 5 Cisco Unified CM Trunks Design Recommendations for Deploying IP Trunks Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x)5-26 OL-16394-07

CH A P T E R 6 Media Resources Last revised on: June 4, 2010 A media resource is a software-based or hardware-based entity that performs media processing functions on the data streams to which it is connected. Media processing functions include mixing multiple streams to create one output stream (conferencing), passing the stream from one connection to another (media termination point), converting the data stream from one compression type to another (transcoding), echo cancellation, signaling, termination of a voice stream from a TDM circuit (coding/decoding), packetization of a stream, streaming audio (annunciation), and so forth. Use this chapter to determine which of the media resources described below are needed for your deployment. Also determine whether the resources that are required can be provided by software-based features or whether it is necessary to provision digital signal processors (DSPs) to implement the resources. Although the resources are discussed in individual sections, the same basic resources (DSPs and Cisco IP Voice Media Streaming Application) may be shared to implement higher-level functions. This chapter focuses on the following features: • Voice Termination, page 6-2 • Audio Conferencing, page 6-10 • Video Conferencing, page 6-13 • Secure Conferencing, page 6-13 • Transcoding, page 6-15 • Media Termination Point (MTP), page 6-17 • SIP Trunk, page 6-20 • H.323 Trunks and Gateways, page 6-22 • Trusted Relay Point, page 6-25 • Annunciator, page 6-25 • Cisco RSVP Agent, page 6-27 • Cisco IP Voice Media Streaming Application, page 6-27 For more details about the following features, refer to their respective sections: • Music on Hold, page 7-1 • Unified CM RSVP-Enabled Locations, page 9-18 For details about the dependencies on hardware and software, see the section on Hardware and Software Capacities, page 6-28. Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x)OL-16394-07 6-1

Chapter 6 Media Resources Whats New in This Chapter You can control media resources on Cisco Unified Communications Manager (Unified CM) through the use of media resource groups and media resource group lists. You can create pools of resources to control the specific hardware or software that is used. Cisco recommends that you use pools to group resources based on physical location. For design guidelines based on the various call processing models, see the section on General Design Guidelines, page 6-31.Whats New in This Chapter Table 6-1 lists the topics that are new in this chapter or that have changed significantly from previous releases of this document. Table 6-1 New or Changed Information Since the Previous Release of This Document New or Revised Topic Described in: Capacities of WS-SVC-CMM-ACT and Audio Conferencing Resources, page 6-10 WS-6608-T1/WS-6608-E1 modules for audio conferences Cisco 2900 and 3900 Series Integrated Services Cisco 2900 and 3900 Series Platforms, page 6-29 Routers Generation 2 (ISR G2) Cisco IOS media resources Redundancy and Failover Considerations for Cisco IOS-Based Media Resources, page 6-9 MTP usage with a conference bridge MTP Usage with a Conference Bridge, page 6-24 PVDM3 DSPs Table 6-3 Table 6-8 Various sections throughout this chapter Recommended DSP profile configuration Transcoding Resources, page 6-16 Secure conferences Secure Conferencing, page 6-13 Trusted Relay Point (TRP) Trusted Relay Point, page 6-25 Usage of hardware DSP resources as MTP for MTP Resources, page 6-24 G.729 codec Video conferences Video Conferencing, page 6-13 Voice quality Media Functions and Voice Quality, page 6-32Voice Termination Voice termination applies to a call that has two call legs, one leg on a time-division multiplexing (TDM) interface and the second leg on a Voice over IP (VoIP) connection. The TDM leg must be terminated by hardware that performs coding/decoding and packetization of the stream. This termination function is performed by digital signal processor (DSP) resources residing in the same hardware module, blade, or platform. All DSP hardware on Cisco TDM gateways is capable of terminating voice streams, and certain hardware is also capable of performing other media resource functions such as conferencing or transcoding (see Audio Conferencing, page 6-10 and Transcoding, page 6-15). Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) 6-2 OL-16394-07

Chapter 6 Media Resources Voice Termination Table 6-4 through Table 6-9 show the number of calls that each hardware platform can support, which is determined by the type of DSP chipset and the number of DSPs on the hardware. The hardware has either fixed DSP resources that cannot be upgraded or changed, or it has modular DSP resources that can be upgraded. For modular (upgradeable) hardware, Table 6-4 through Table 6-9 also list the maximum number of DSPs per hardware module. The number of supported calls depends on the computational complexity of the codec used for a call and also on the complexity mode configured on the DSP. Cisco IOS enables you to configure a complexity mode on the hardware module. Some hardware platforms have two complexity modes, medium complexity and high complexity, while other hardware platforms have medium and high complexity as well as flex mode.Medium and High Complexity Mode To determine how many calls a module can support, locate the module in Table 6-4 through Table 6-9, and determine the number of DSPs it can provide as well as the desired codec type. For example, an NM-HD-2VE module with three C5510 DSPs configured in flex mode can support eight G.729 calls on each DSP, for a total of 24 calls using flex mode and G.729 codecs. Using G.711 codecs in flex mode, the same hardware could support 48 calls. As indicated in Table 6-2, if a codec is supported in medium complexity mode, it is also supported in high complexity mode, albeit with fewer supported calls. You can configure each DSP separately as either medium complexity, high complexity, or flex mode (C5510 only). The DSP treats all calls according to its configured complexity, regardless of the actual complexity of the codec of the call. A resource with configured complexity equal or higher than the actual complexity of the incoming call must be available, or the call will fail. For example, if a call requires a high-complexity codec but the DSP resource is configured for medium complexity mode, the call will fail. However, if a medium-complexity call is attempted on a DSP configured for high complexity mode, then the call will succeed and Cisco IOS will allocate a high-complexity mode resource. To determine the maximum number of calls supported, find the appropriate row in Table 6-4 through Table 6-9 that contains the desired hardware. For DSPs based on C5510, check the medium and high complexity columns in Table 6-2 to verify which complexity modes are capable of handling the desired codecs, then read the maximum number of supported calls for each DSP at the desired complexity mode. For PVDM3 DSPs, use Table 6-3, and note that the medium complexity mode of operation of the PVDM3 includes both the low and the medium complexity codecs listed in the table.Flex Mode Flex mode, available only on hardware platforms that use the C5510 chipset and on PVDM3 DSPs, eliminates the requirement to specify the codec complexity at configuration time. A DSP in flex mode accepts a call of any supported codec type, as long as it has available processing power. The overhead of each call is tracked dynamically via a calculation of processing power in millions of instructions per second (MIPS). Cisco IOS performs a MIPS calculation for each call received and subtracts MIPS credits from its budget whenever a new call is initiated. The number of MIPS consumed by a call depends on the codec of the call, as shown in the Flex Mode column of Table 6-2. The DSP will allow a new call as long as it has remaining MIPS credits greater than or equal to the MIPS required for the incoming call. The Flex Mode column of Table 6-2 groups the supported codecs by the number of MIPS for a single call (either 15, 30, or 40 MIPS per call) and shows the MIPS budget available for various hardware. Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) OL-16394-07 6-3

Chapter 6 Media Resources Voice Termination Similarly, PVDM3 DSP modules use a credit-based system. Each module is assigned a fixed number of "credits" that represent a measure of its capacity to process media streams. Each media operation, such as voice termination, transcoding, and so forth, is assigned a cost in terms of credits. As DSP resources are allocated for a media processing function, its cost value is subtracted from the available credits. A DSP module runs out of capacity when the available credits run out and are no longer sufficient for the requested operation. The credit allocation rules for PVDM3 DSPs are rather complex. For proper sizing, use the Cisco Unified Communications Sizing Tool (Unified CST), available to Cisco employees and partners with proper login authentication at http://tools.cisco.com/cucst. Flex mode has an advantage when calls of multiple codecs must be supported on the same hardware because flex mode can support more calls than when the DSPs are configured as medium or high complexity. However, flex mode does allow oversubscription of the resources, which introduces the risk of call failure if all resources are used. With flex mode it is possible to have fewer DSP resources than with physical TDM interfaces. For example, each DSP has a budget of 240 MIPS, for a total budget of 720 MIPS per NM-HD-2VE module. For an NM-HDV2 module, the budget per DSP is also 240 MIPS, but refer to Table 6-4 to determine the total number of MIPS available based on your choice and the number of PVDMs. Compared to medium or high complexity mode, flex mode has the advantage of supporting the most G.711 calls per DSP. In medium complexity mode a DSP can support 8 G.711 calls, while flex mode supports 16 G.711 calls.DSP Resources for Voice Termination Table 6-4 through Table 6-9, organized by DSP chipset, provide information on DSP support by platform, DSP density, and the number of voice terminations (or calls) supported per DSP. Table 6-2 and Table 6-3 list the codecs supported by the hardware modules in each complexity mode. Table 6-2 Codecs Supported by C5510 DSPs in Various Complexity Modes Medium Complexity High Complexity Flex Mode G.711 (a-law, mu-law) G.711 (a-law, mu-law) At 15 MIPS per call: Fax/modem passthrough Fax/modem passthrough • G.711 (a-law, mu-law) Clear channel Clear channel • Fax/modem passthrough G.726 (32K, 24K, 16K) G.726 (32K, 24K, 16K) • Clear channel Fax relay Fax relay At 30 MIPS per call: G.729 (a, ab) G.729 • G.726 (32K, 24K, 16K) G.729 (a, b, ab) • Fax relay G.728 • G.729 G.723.1 (32K, 24K, 16K) • G.729 (a, b, ab) G.723.1a (5.3K, 6.3K) At 40 MIPS per call: Modem relay • G.728 • G.723.1 (32K, 24K, 16K) • G.723.1a (5.3K, 6.3K) • Modem relay Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) 6-4 OL-16394-07

Chapter 6 Media Resources Voice Termination Table 6-3 Codecs Supported by PVDM3 DSPs in Various Complexity Modes Low Complexity Medium Complexity High Complexity Very High Complexity G.711 (a-law, mu-law) G.726 G.729 iSAC Fax Passthrough Fax Relay G.729B Modem Passthrough G.729A G.723 Clear channel G.729AB G.728 G.722 Modem Relay GSMFR iLBC GSMEFR Hardware based on the C5510 chipset supports medium and high complexity modes as well as flex mode, as indicated in Table 6-4.Table 6-4 DSP Resources on Cisco IOS Hardware Platforms with C5510 Chipset Maximum Number of Voice Terminations (Calls) per DSP and per ModuleHardware Module or Medium Complexity High Complexity Flex Mode1Chassis DSP Configuration (8 calls per DSP) (6 calls per DSP) (240 MIPS per DSP)VG-224 Fixed at 4 DSPs N/A 24 calls per platform N/A Supported codecs: • G.711 (a-law, mu-law) • G.729a 2NM-HD-1V Fixed at 1 DSP 4 calls per NM 4 calls per NM 240 MIPS per NMNM-HD-2V Fixed at 1 DSP 8 calls per NM 6 calls per NM 240 MIPS per NMNM-HD-2VE Fixed at 3 DSPs 24 calls per NM 18 calls per NM 720 MIPS per NMNM-HDV2 1 to 4 of: Calls per PVDM: Calls per PVDM: MIPS per PVDM: 3NM-HDV2-2T1/E1 PVDM2-8 (½ DSP) 4 3 120NM-HDV2-1T1/E1 PVDM2-16 (1 DSP) 8 6 240 PVDM2-32 (2 DSPs) 16 12 480 PVDM2-48 (3 DSPs) 24 18 720 PVDM2-64 (4 DSPs) 32 24 9602801 1 to 2 of: Calls per PVDM: Calls per PVDM: MIPS per PVDM: 32811 PVDM2-8 (½ DSP) 4 3 120 PVDM2-16 (1 DSP) 8 6 240 PVDM2-32 (2 DSPs) 16 12 480 PVDM2-48 (3 DSPs) 24 18 720 PVDM2-64 (4 DSPs) 32 24 960 Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) OL-16394-07 6-5

Chapter 6 Media Resources Voice TerminationTable 6-4 DSP Resources on Cisco IOS Hardware Platforms with C5510 Chipset (continued) Maximum Number of Voice Terminations (Calls) per DSP and per ModuleHardware Module or Medium Complexity High Complexity Flex Mode1Chassis DSP Configuration (8 calls per DSP) (6 calls per DSP) (240 MIPS per DSP)2821 1 to 3 of: Calls per PVDM: Calls per PVDM: MIPS per PVDM: 32851 PVDM2-8 (½ DSP) 4 3 120 PVDM2-16 (1 DSP) 8 6 240 PVDM2-32 (2 DSPs) 16 12 480 PVDM2-48 (3 DSPs) 24 18 720 PVDM2-64 (4 DSPs) 32 24 9603825 1 to 4 of: Calls per PVDM: Calls per PVDM: MIPS per PVDM: 33845 PVDM2-8 (½ DSP) 4 3 120 PVDM2-16 (1 DSP) 8 6 240 PVDM2-32 (2 DSPs) 16 12 480 PVDM2-48 (3 DSPs) 24 18 720 PVDM2-64 (4 DSPs) 32 24 9601. In flex mode, the maximum number of supported calls depends on the number of MIPS used per call (see Table 6-2).2. With the NM-HD-1V module, the number of voice terminations (calls) is limited by the number of physical ports on the module.3. The PVDM2-8 has a single half-capacity C5510. Hardware that is based on the C5421 chipset may have DSPs configured as either medium complexity or high complexity. Table 6-5 lists the call density per DSP, and Table 6-2 lists the codecs supported in each complexity mode.Table 6-5 DSP Resources on Cisco IOS Hardware Platforms with C5421 Chipset Maximum Number of Calls per DSP and per Module Medium Complexity High ComplexityHardware Module DSP Configuration (8 calls per DSP) (8 calls per DSP)NM-HDA-4FXS Fixed at 2 DSPs 16 calls per NM 8 calls per NM or Fixed at 1 of DSP-HDA-16 16 calls per NM 16 calls per NM (4 DSPs)AIM-VOICE-30 Fixed at 4 DSPs 30 or 60 calls per AIM 16 or 30 calls per AIMAIM-ATM-VOICE-30 Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) 6-6 OL-16394-07

Chapter 6 Media Resources Voice Termination Hardware that is based on the C549 chipset may have DSPs configured as either medium complexity or high complexity. Table 6-6 lists the call density per DSP, and Table 6-2 lists the codecs supported in each complexity mode.Table 6-6 DSP Resources on Cisco IOS Hardware Platforms with C549 Chipset Maximum Number of Calls per DSP and per Module Medium Complexity High ComplexityHardware Module DSP Configuration (4 calls per DSP) (2 calls per DSP)NM-HDV 1 to 5 of PVDM-12 12, 24, 36, 48, or 60 calls per NM 6, 12, 18, 24, or 30 calls per NM (3 DSPs per PVDM-12)NM-HDV-FARM17511 1 to 2 of: Calls per NM: Calls per NM:1760 PVDM-256K-4 (1 DSP) 4 or 8 2 or 4 PVDM-256K-8 (2 DSPs) 8 or 16 4 or 8 PVDM-256K-12 (3 DSPs) 12 or 24 6 or 12 PVDM-256K-16HD (4 DSPs) 16 or 32 8 or 16 PVDM-256K-20HD (5 DSPs) 20 10 Fixed at: Calls per PA: Calls per PA:PA-VXA-1TE1-24+ 7 DSPs 28 14PA-VXA-1TE1-30+ 8 DSPs 32 16PA-VXB-2TE1+ 12 DSPs 48 24PA-VXC-2TE1+ 30 DSPs 120 60 2PA-MCX-2TE1 Fixed (No on-board DSPs) Depends on PA-VX(x) Depends on PA-VX(x)2PA-MCX-4TE1PA-MCX-8TE11. The 1751 supports a maximum of 8 DSPs (32 channels), and you can order these modules in multiples of 2 PVDMs as long as the total is less than 32 channels. The part number indicates the number of channels.2. The multichannel port adaptors utilize unused DSPs from PA-VXAs, PA-VXBs, or PA-VXCs across the mix backplane. Hardware that is based on the C542 chipset supports the following codecs: • G.711 (a-law, mu-law) • Fax/modem passthrough • Clear channel • G.726 (32K, 24K, 16K) • Fax relay • G.729 • G.729 (a, b, ab) • G.728 • G.723.1 (32K, 24K, 16K) • G.723.1a (5.3K, 6.3K) • Modem relay Table 6-7 lists the call density per DSP. Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) OL-16394-07 6-7

Chapter 6 Media Resources Voice Termination Table 6-7 DSP Resources on Cisco IOS Hardware Platforms with C542 Chipset Maximum Number of Calls per DSP and per Hardware Module1 DSP Configuration Module NM-1V Fixed at 2 DSPs 1 call per DSP 2 calls per NM NM-2V Fixed at 4 DSPs 1 call per DSP 4 calls per NM 1. These modules do not have any complexity mode but support all codecs equally. Table 6-8 lists the call density per PVDM3 DSP.Table 6-8 Voice Termination on PVDM3 DSPs on Cisco IOS ISR G2 Platforms Maximum Number of Calls per DSPHardware Low Complexity Medium High Complexity Very HighPlatform1 DSP Configuration Codecs Complexity Codecs Codecs Complexity Codecs2901 1 to 2 of:2911 PVDM3-16 16 12 10 8 PVDM3-32 32 22 14 12 PVDM3-64 64 44 28 24 PVDM3-128 128 97 60 50 PVDM3-192 193 140 89 74 PVDM3-256 258 194 121 1012921 1 to 3 of:2951 PVDM3-16 16 12 10 8 PVDM3-32 32 22 14 12 PVDM3-64 64 44 28 24 PVDM3-128 128 97 60 50 PVDM3-192 193 140 89 74 PVDM3-256 258 194 121 1013925 1 to 4 of:3945 PVDM3-16 16 12 10 8 PVDM3-32 32 22 14 12 PVDM3-64 64 44 28 24 PVDM3-128 128 97 60 50 PVDM3-192 193 140 89 74 PVDM3-256 258 194 121 1011. The Cisco 2900 and 3900 Series Integrated Services Routers (ISRs) also support PVDM2 DSPs. The call capacity with various complexity modes on these DSPs is the same as for the Cisco 2800 and 3800 Series ISRs. An adaptor is required for inserting PVDM2 DSPs in DSP slots on the Cisco 2900 and 3900 Series ISR motherboards. Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) 6-8 OL-16394-07

Chapter 6 Media Resources Voice Termination Table 6-9 lists non-IOS hardware for DSP resources. All non-IOS hardware platforms have a fixed configuration of DSPs, as indicated in Table 6-9.Table 6-9 DSP Resources on Non-IOS Hardware PlatformsHardware Module or Maximum Number of CallsPlatform DSP Configuration per DSP and per Module Codecs SupportedWS-6608-T1 Fixed at 64 of C549 4 calls per DSP G.711 a-law, mu-lawWS-6608-E1 G.729a (8 DSPs per port, 8 ports per 256 calls per module1 card)WS-6624-FXS Fixed at 12 of C549 2 calls per DSP G.711 a-law, mu-law 24 calls per module G.729aVG-248 Fixed at 12 of C5409 4 calls per DSP G.711 a-law, mu-law G.729a 48 calls per platformWS-SVC-CMM-ACT Fixed at 4 of Broadcom 1500 32 calls per DSP G.711 (10-30 ms) G.729 (10-60 ms) 128 calls per module G.723 (30-60 ms)WS-SVC-CMM-6T1 Fixed at 12 of C5441 15 calls per DSP G.711 (10, 20, 30 ms) 144 calls per module G.729 (10, 20, 30, 40, 50, 60 ms)WS-SVC-CMM-6E1 Fixed at 12 of C5441 15 calls per DSP G.711 (10, 20, 30 ms) 180 calls per module G.729 (10, 20, 30, 40, 50, 60 ms)WS-SVC-CMM-24FXS Fixed at 3 of C5441 15 calls per DSP G.711 a-law, mu-law G.729 24 calls per module G.729aATA-1882 Fixed at 1 of Komodo 3880 2 calls per platform G.711 a-law, mu-law G.7291. A maximum of 192 calls are possible with T1 and 240 calls with E1, based on the number of physical ports. If none of the DSPs are configured for T1 or E1, then a maximum of 256 DSP resources are available.2. The ATA module does not define complexity. It supports G.711, G.729, and G.723 only.Redundancy and Failover Considerations for Cisco IOS-Based MediaResources A high availability design with media resources must include redundant media resources. When these resources are Cisco IOS-based, they can be distributed on more than one Cisco IOS platform to guard against failure of a single platform and can be registered to different primary Unified CM servers. Cisco IOS supports two modes of failover capability: graceful and immediate. The default failover method is graceful, in which the resources register to a backup Unified CM server only after all media activity has ceased. The immediate method, on the other hand, makes the resources register to the backup Unified CM server as soon as failure of the primary is detected. In situations where there is only one set of media resources with no redundancy, Cisco recommends use of the immediate failover method. Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) OL-16394-07 6-9

Chapter 6 Media Resources Audio ConferencingAudio Conferencing A conference bridge is a resource that joins multiple participants into a single call. It can accept any number of connections for a given conference, up to the maximum number of streams allowed for a single conference on that device. There is a one-to-one correspondence between media streams connected to a conference and participants connected to the conference. The conference bridge mixes the streams together and creates a unique output stream for each connected party. The output stream for a given party is the composite of the streams from all connected parties minus their own input stream. Some conference bridges mix only the three loudest talkers on the conference and distribute that composite stream to each participant (minus their own input stream if they are one of the talkers).Audio Conferencing Resources A hardware conference bridge has all the capabilities of a software conference bridge. In addition, some hardware conference bridges can support multiple low bit-rate (LBR) stream types such as G.729 or G.723. This capability enables some hardware conference bridges to handle mixed-mode conferences. In a mixed-mode conference, the hardware conference bridge transcodes G.729 and G.723 streams into G.711 streams, mixes them, and then encodes the resulting stream into the appropriate stream type for transmission back to the user. Some hardware conference bridges support only G.711 conferences. All conference bridges that are under the control of Cisco Unified Communications Manager (Unified CM) use Skinny Client Control Protocol (SCCP) to communicate with Unified CM. Unified CM allocates a conference bridge from a conferencing resource that is registered with the Unified CM cluster. Both hardware and software conferencing resources can register with Unified CM at the same time, and Unified CM can allocate and use conference bridges from either resource. Unified CM does not distinguish between these types of conference bridges when it processes a conference allocation request. The number of individual conferences that may be supported by the resource varies, and the maximum number of participants in a single conference varies, depending on the resource. The following types of conference bridge resources may be used on a Unified CM system: • Software Audio Conference Bridge (Cisco IP Voice Media Streaming Application), page 6-10 • Hardware Audio Conference Bridge (Cisco NM-HDV2, NM-HD-1V/2V/2VE, 2800 Series, and 3800 Series Routers), page 6-11 • Hardware Audio Conference Bridge (Cisco 2900 Series and 3900 Series Routers with PVDM3 DSPs), page 6-11 • Hardware Audio Conference Bridge (Cisco WS-SVC-CMM-ACT), page 6-12 • Hardware Audio Conference Bridge (Cisco NM-HDV and 1700 Series Routers), page 6-12 • Hardware Audio Conference Bridge (Cisco Catalyst WS-X6608-T1 and WS-X6608-E1), page 6-12 • Built-in Conference, page 6-12 • Video Conferencing, page 6-13 Software Audio Conference Bridge (Cisco IP Voice Media Streaming Application) A software unicast conference bridge is a standard conference mixer that is capable of mixing G.711 audio streams and Cisco Wideband audio streams. Any combination of Wideband or G.711 a-law and mu-law streams may be connected to the same conference. The number of conferences that can be supported on a given configuration depends on the server where the conference bridge software is Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) 6-10 OL-16394-07

Chapter 6 Media Resources Audio Conferencing running and on what other functionality has been enabled for the application. The Cisco IP Voice Media Streaming Application is a resource that can also be used for several functions, and the design must consider all functions together (see Cisco IP Voice Media Streaming Application, page 6-27). Hardware Audio Conference Bridge (Cisco NM-HDV2, NM-HD-1V/2V/2VE, 2800 Series, and 3800 Series Routers) DSPs that are configured through Cisco IOS as conference resources will load firmware into the DSPs that is specific to conferencing functionality only, and these DSPs cannot be used for any other media feature. The following guidelines and considerations apply to these DSP resources: • Based on the C5510 DSP chipset, the NM-HDV2 and the router chassis use the PVDM2 modules for providing DSPs. • DSPs on PVDM2 hardware are configured individually as either voice termination, conferencing, media termination, or transcoding, so that DSPs on a single PVDM may be used as different resource types. Allocate DSPs to voice termination first, then to other functionality as needed. • The NM-HDV2 has 4 slots that will accept PVDM2 modules in any combination. The other network modules have fixed numbers of DSPs. • A conference based on these DSPs allows a maximum of 8 participants. When a conference begins, all 8 positions are reserved at that time. Starting with Cisco IOS Release 12.4(15)T, this limit on the maximum number of participants has been increased to 32. • The PVDM2-8 is listed as having ½ a DSP because it has a DSP that has half the processing capacity of the PVDM2-16. For example, if the DSP on a PVDM2-8 is configured for G.711, it can provide (0.5 ∗ 8) bridges/DSP = 4 conference bridges. • Use Table 6-2 and Table 6-4 to determine how many DSPs may be provisioned with specific hardware. • A DSP farm configuration in Cisco IOS specifies which codecs may be accepted for the farm. A DSP farm that is configured for conferencing and G.711 provides 8 conferences. When configured to accept both G.711 and G.729 calls, a single DSP provides 2 conferences because it is also reserving its resources for performing transcoding of streams. • The I/O of an NM-HDV2 is limited to 400 streams, so ensure that the number of conference resources allocated does not cause this limit to be exceeded. If G.711 conferences are configured, then no more than 6 DSPs (total of 48 conferences with 8 participants each) should be allocated per NM because (48 ∗ 8) participants = 384 streams. If you configure all conferencing for both G.711 and G.729 codecs, then each DSP provides only 2 conferences of 8 participants each. In this case, it is possible to populate the NM fully and configure it with 16 DSPs so there would be 256 streams. • Conferences cannot natively accept calls utilizing the GSM codec. A transcoder must be provided separately for these calls to participate in a conference. • Any PVDM2-based hardware, such as the NM-HDV2, may be used simultaneously in a single chassis for voice termination but may not be used simultaneously for other media resource functionality. The DSPs based on PVDM-256K and PVDM2 have different DSP farm configurations, and only one may be configured in a router at a time. Hardware Audio Conference Bridge (Cisco 2900 Series and 3900 Series Routers with PVDM3 DSPs) The number of conferences supported by each DSP type is a function of the number of participants in each conference and the codec used for the conference. Each media processing function, including conferences hosted by the DSP, consumes some of its available credits. The number of credits consumed for a particular conference is a function of the number of participants and the codec used in the Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x)OL-16394-07 6-11

Chapter 6 Media Resources Audio Conferencing conference. For proper sizing, use the Cisco Unified Communications Sizing Tool (Unified CST), available to Cisco employees and partners with proper login authentication at http://tools.cisco.com/cucst. Hardware Audio Conference Bridge (Cisco WS-SVC-CMM-ACT) The following guidelines and considerations apply to this DSP resource: • DSPs on this hardware are configured individually as either voice termination, conferencing, media termination, or transcoding, so that DSPs on a single module may be used as different resource types. Allocate DSPs to voice termination first. • Each ACT Port Adaptor contains 4 DSPs that are individually configurable. Each DSP can support 32 conference participants. You can configure up to 4 ACT Port Adaptors per CMM Module. • This Cisco Catalyst-based hardware provides DSP resources that can provide conference bridges of up to 128 participants per bridge. A conference bridge may span multiple DSPs on a single ACT Port Adaptor; but conference bridges cannot span across multiple ACT Port Adaptors. • The G.711 and G.729 codecs are supported on these conference bridges without extra transcoder resources. However, transcoder resources would be necessary if other codecs are used. Hardware Audio Conference Bridge (Cisco NM-HDV and 1700 Series Routers) The following guidelines and considerations apply to these DSP resources: • This hardware utilizes the PVDM-256K type modules that are based on the C549 DSP chipset. • Conferences using this hardware provide bridges that allow up to 6 participants in a single bridge. • The resources are configured on a per-DSP basis as conference bridges. • The NM-HDV may have up to 5 PVDM-256K modules, while the Cisco 1700 Series Routers may have 1 or 2 PVDM-256K modules. • Each DSP provides a single conference bridge that can accept G.711 or G.729 calls. • The Cisco 1751 is limited to 5 conference calls per chassis, and the Cisco 1760 can support 20 conference calls per chassis. • Any PVDM2-based hardware, such as the NM-HDV2, may be used simultaneously in a single chassis for voice termination but may not be used simultaneously for other media resource functionality. The DSPs based on PVDM-256K and PVDM2 have different DSP farm configurations, and only one may be configured in a router at a time. Hardware Audio Conference Bridge (Cisco Catalyst WS-X6608-T1 and WS-X6608-E1) The following guidelines and considerations apply to these DSP resources: • This hardware has 8 DSPs that are physically associated to each port, and there are 8 ports per card. Configuration of the DSPs is at the port level, so that all DSPs associated to a port perform the same function. • Conference bridges may have up to 32 participants, and each port supports 32 conference bridges. • For conferences with G.711 or G.723 there may be 32 conferences per port. If G.729 calls are used, there may be 24 conferences per port. Built-in Conference Some phone models have a built-in conference resource that allows a three-way conference. This bridge is invoked only by the Barge feature and is not used as a general conferencing resource. For details on which phones have this bridge, see Unified Communications Endpoints, page 20-1. This bridge accepts only G.711 calls. Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x)6-12 OL-16394-07

Chapter 6 Media Resources Video ConferencingVideo Conferencing Video-capable endpoints provide the capability to conduct video conferences that function similar to audio conferences. Video conferences can be invoked as ad-hoc conferences from a Skinny Client Control Protocol (SCCP) device through the use of Conf, Join, or cBarge softkeys. The video portion of the conference can operate in either of two modes: • Voice activation In this mode, the video endpoints display the dominant participant (the one speaking most recently or speaking the loudest). In this way, the video portion follows or tracks the audio portion. This mode is optimal when one participant speaks most of the time, as with an instructor teaching or training a group. • Continuous presence In this mode, input from all (or selected) video endpoints is displayed simultaneously and continuously. The audio portion of the conference follows or tracks the dominant speaker. Continuous presence is more popular, and it is optimal for conferences or discussions between speakers at various sites. Videoconferencing resources are of two types: • Software videoconferencing bridges Software videoconferencing bridges process video and audio for the conference using just software. Cisco Unified MeetingPlace Express VT is a software videoconferencing bridge that can support ad-hoc video conferences. Cisco Unified MeetingPlace Express VT supports only voice activation mode for video conferences. • Hardware videoconferencing bridges Hardware videoconferencing bridges have hardware DSPs that are used for the video conferences. The Cisco 3500 Series Multipoint Control Units (MCUs) are this type of videoconferencing bridge. Most hardware videoconferencing bridges can also be used as audio-only conference bridges. Hardware videoconferencing bridges provide the following advantages: – Video transrating – Higher video resolution – Scalability Videoconferencing bridges can be configured in a manner similar to audio conferencing resources, with similar characteristics for media resource groups (MRGs) and media resource group lists (MRGLs) for the device pools or endpoints. Cisco Unified CM 7.x provides Intelligent Bridge Selection functionality, which enables Unified CM to allocate videoconferencing resources based on the use and availability of video endpoints in the conference. If there are no video endpoints in the conference, then an available audio conference bridge is chosen. For additional details on this functionality, see Intelligent Bridge Selection, page 16-18.Secure Conferencing Secure conferencing is a way to use regular conferencing to ensure that the media for the conference is secure and cannot be compromised. This is achieved by first authenticating the devices so that they are trusted devices, similarly authenticating the conferencing resource, and then encrypting the conference media so that every participant in the conference is authenticated and sends and receives encrypted Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x)OL-16394-07 6-13

Chapter 6 Media Resources Secure Conferencing media for that conference. There are various security levels that this conference can have, such as authenticated or encrypted. In most cases the security level of the conference will depend on the lowest security level of the participants in the conference. For example, if there is one participant who is not using a secure endpoint, then the entire conference will be non-secure. As another example, if one of the endpoints is authenticated but does not do encryption, then the conference will be in authenticated mode. Secure conferencing provides the following benefits: • It provides conferencing functionality at an enhanced security level. • It prevents unauthorized capture and decryption of conference calls. Consider the following factors when designing secure conferencing: • Security levels of devices (Phones and conferencing resources) • Security overhead for call signaling • Security overhead for SRTP media • Bandwidth impact if secure participants are across the WAN • Some intermediate devices (for example, NAT and firewalls) might not be able to support secure calls across them. Secure conferencing is subject to the following restrictions and limitations: • Some protocols may rely on IPSec to secure the call signaling. • Secure conference cannot be cascaded between Unified CM and Unified CM Express. • Secure conferencing is only for audio calls. • MTPs and transcoders do not support secure calls. Therefore, a conference might no longer be secure if any call into that conference uses an MTP or transcoder. • Elaborate security policy might be needed. • Secure conferencing might not be available for all codecs. Platforms and Network Modules The Media and Signaling Encryption (SRTP/TLS) on DSP Farm Conferencing feature is supported on the following platforms with on-board DSP modules or NM-HDV2 network modules: • Cisco 2600XM Series Multiservice Router • Cisco 2691 Multiservice Platform • Cisco 2801 Integrated Services Router • Cisco 2811 Integrated Services Router • Cisco 2821 Integrated Services Router • Cisco 2851 Integrated Services Router • Cisco 3725 Multiservice Access Router • Cisco 3745 Multiservice Access Router • Cisco 3825 Integrated Services Router • Cisco 3845 Integrated Services Router DSP modules support the maximum number of TI 5510 DSPs listed: • NM-HDV2: Up to 16 TI 5510 DSPs in 4 PVDM2s • Integrated Services Routers (ISRs) on-board PVDM2: Up to 8 TI 5510 DSPs in 2 PVDM2s Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x)6-14 OL-16394-07

Chapter 6 Media Resources Transcoding • Integrated Services Routers Generation 2 (ISR G2) on-board PVDM3: Up to 4 PVDM3-256 DSPs in a single router chassis Table 6-10 lists the maximum number of sessions and conferences, by codec type, supported by the various network modules (NMs). Table 6-10 Maximum Number of Sessions and Conferences Supported by Network Modules NM-HD-2VE NM-HD-1V and NM-HD-2V Codec Type NM-HDV2 (16 TI 5510 DSPs) (3 TI 5510 DSPs) (1 TI 5510 DSP) G.711 16 sessions, 64 conferences 12 sessions, 96 conferences 4 session, 32 conferences G.729 16 sessions, 16 conferences 3 sessions, 24 conferences 1 session, 8 conferencesTranscoding A transcoder is a device that converts an input stream from one codec into an output stream that uses a different codec. It may also connect two streams that utilize the same codec but with a different sampling rate. In a Unified CM system, the typical use of a transcoder is to convert between a G.711 voice stream and the low bit-rate compressed voice stream G729a. The following cases determine when transcoder resources are needed: • Single codec for the entire system When a single codec is configured for all calls in the system, then no transcoder resources are required. The G.711 codec is supported by all vendors. A single-site deployment usually has no need for conserving bandwidth, and a single codec can be used. In this scenario, G.711 is the most common choice. • Multiple codecs in use in the system, and all endpoints are capable of all codec types The most common reason for multiple codecs is to use G.711 for LAN calls to maximize the call quality and to use a low-bandwidth codec to maximize bandwidth efficiency for calls that traverse a WAN with limited bandwidth. Cisco recommends using G.729a as the low-bandwidth codec because it is supported on all Cisco Unified IP Phone models as well as most other Cisco Unified Communications devices, therefore it can eliminate the need for transcoding. Although Unified CM allows configuration of other low-bandwidth codecs between regions, the current phone models do not support those codecs and would require transcoders. They would require one transcoder for a call to a gateway and two transcoders if the call is to another IP phone. The use of transcoders is avoided if all devices support and are configured for both G.711 and G.729 because the devices will use the appropriate codec on a call-by-call basis. • Multiple codecs in use in the system, and some endpoints support or are configured for G.711 only This condition exists when G.729a is used in the system but there are devices that do not support this codec, or a device with G.729a support may be configured to not use it. In this case, a transcoder is also required. Devices from some third-party vendors may not support G.729. Another example where G.729 is supported but might not be configured is with Cisco Unity. Cisco Unity has support for accepting calls with G.729a, but the codec is implemented in software and is CPU-intensive. Because as few as 10 simultaneous calls can cause significant CPU utilization, many deployments choose to disable G.729 on Cisco Unity and off-load the transcoding function to a dedicated transcoding resource external to the Unity server. If your system includes Cisco Unity, determine whether Unity will accept G.729a calls or whether it will be configured for G.711 only. Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x)OL-16394-07 6-15

Chapter 6 Media Resources Transcoding Note Cisco Unified MeetingPlace Express prior to release 2.0 supported G.711 only. In an environment where G.729 is configured for a call into earlier versions of Cisco Unified MeetingPlace Express, transcoder resources are required. To finalize the design, it is necessary to know how many transcoders are needed and where they will be placed. If multiple codecs are needed, it is necessary to know how many endpoints do not support all codecs, where those endpoints are located, what other groups will be accessing those resources, how many maximum simultaneous calls these device must support, and where those resources are located in the network.Transcoding Resources DSP resources are required to perform transcoding. Those DSP resources can be located in the voice modules and the hardware platforms for transcoding that are listed in the following sections. Hardware Transcoder (Cisco NM-HDV2, NM-HD-1V/2V/2VE, 2800, and 3800 Series Routers) The following guidelines and considerations apply to these DSP resources: • Transcoding is available between G.711 mu-law or a-law and G.729a, G.729ab, G.722, iLBC, and GSM. Each DSP can support 8 sessions. Note If transcoding is not required between G.711 and G.722, Cisco recommends that you do not include G.722 in the Cisco IOS configuration of the dspfarm profile. This is to preclude Unified CM from selecting G.722 as the codec for a call in which transcoding is required. Because these DSP resources can transcode only between G.711 and other codecs, any attempt to use them for transcoding between G.722 and other codecs (except G.711) will fail. • Cisco Unified IP Phones use only the G.729a variants of the G.729 codecs. The default for a new DSP farm profile is G.729a/G.729ab/G.711u/G.711a. Because a single DSP can provide only one function at a time, the maximum sessions configured on the profile should be specified in multiples of 8 to prevent wasted resources. • Transcoding is also available between G.711mu-law/G.711a-law and G.729/G729b, but is not usually used in a Unified CM system. Each DSP can support 6 sessions. • Refer to the section on DSP Resources for Voice Termination, page 6-4, to determine numbers of DSPs available on a particular platform or network module. Hardware Transcoder (Cisco WS-SVC-CMM-ACT) The following guidelines and considerations apply to this DSP resource: • Transcoding is available between G.711 mu-law or a-law and G.729, G.729b, or G.723. • There are 4 DSPs per ACT that may be allocated individually to DSP pools. • The CCM-ACT can have 16 transcoded calls per DSP or 64 per ACT. The ACT reports resources as streams rather than calls, and a single transcoded call consists of two streams. Hardware Transcoder (Cisco NM-HDV and 1700 Series Routers) The following guidelines and considerations apply to these DSP resources: • This hardware utilizes the PVDM-256K type modules that are based on the C549 DSP chipset. Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) 6-16 OL-16394-07

Chapter 6 Media Resources Media Termination Point (MTP) • The NM-HDV may have up to 4 PVDM-256K modules, and the Cisco 1700 series routers may have 1 or 2 PVDM-256K modules. • NM-HDV and NM-HDV2 modules may be used simultaneously in a single chassis for voice termination but may not be used simultaneously for other media resource functionality. Only one type of DSP farm configuration may be active at one time (either the NM-HDV or the HM-HDV2) for conferencing, MTP, or transcoding. • Transcoding is supported from G.711 mu-law or a-law to any of G.729, G.729a, G.729b, or G.729ab codecs. • Each DSP can provide 2 transcoding sessions. • The Cisco 1751 has a chassis limit of 16 sessions, and the Cisco 1760 has a chassis limit of 20 sessions. Hardware Transcoder (Cisco WS-X6608) The following guidelines and considerations apply to this DSP resource: • DSPs are allocated to functions at a port level. Each port can provide 24 transcoding sessions. • There are 8 ports per blade. • Transcoding is available between G.711 mu-law or a-law and G.729a, G.729ab, G.729, or G.729b. A transcoder is also capable of performing the same functionality as a media termination point (MTP). In cases where transcoder functionality and MTP functionality are both needed, a transcoder is allocated by the system. If MTP functionality is required, Unified CM will allocate either a transcoder or an MTP from the resource pool, and the choice of resource will be determined by the media resource groups, as described in the section on Media Resource Groups and Lists, page 6-31. Hardware Transcoder (PVDM3 DSP) PVDM3 DSPs are hosted by Cisco 2900 Series and 3900 Series Integrated Services Routers, and they support both secure and non-secure transcoding from any and to any codec. As with voice termination and conferencing, each transcoding session debits the available credits for each type of PVDM3 DSP. The available credits determines the total capacity of the DSP. For proper sizing, use the Cisco Unified Communications Sizing Tool (Unified CST), available to Cisco employees and partners with proper login authentication at http://tools.cisco.com/cucst.Media Termination Point (MTP) A media termination point (MTP) is an entity that accepts two full-duplex media streams. It bridges the streams together and allows them to be set up and torn down independently. The streaming data received from the input stream on one connection is passed to the output stream on the other connection, and vice versa. MTPs have many possible uses, such as: • Re-Packetization of a Stream, page 6-18 • DTMF Conversion, page 6-18 • Protocol-specific usage – SIP Early Offer, page 6-20 – H.323 Supplementary Services, page 6-22 – H.323 Outbound Fast Connect, page 6-22 Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) OL-16394-07 6-17

Chapter 6 Media Resources Media Termination Point (MTP)Re-Packetization of a Stream An MTP can be used to transcode G.711 a-law audio packets to G.711 mu-law packets and vice versa, or it can be used to bridge two connections that utilize different packetization periods (different sample sizes). Note that re-packetization requires DSP resources in a Cisco IOS MTP.DTMF Conversion DTMF tones are used during a call to signal to a far-end device for purposes of navigating a menu system, entering data, or other manipulation. They are processed differently than DTMF tones sent during a call setup as part of the call control. There are several methods for sending DTMF over IP, and two communicating endpoints might not support a common procedure. In these cases, Unified CM may dynamically insert an MTP in the media path to convert DTMF signals from one endpoint to the other. Unfortunately, this method does not scale because one MTP resource is required for each such call. The following sections help determine the optimum amount of MTP resources required, based on the combination of endpoints, trunks, and gateways in the system. If Unified CM determines that an MTP needs to be inserted but no MTP resources are available, it uses the setting of the service parameter “Fail call if MTP allocation fails” to decide whether or not to allow the call to proceed. The default value of this setting is False, which lets the call continue. Named Telephony Events (RFC 2833) Named Telephony Events (NTEs) defined by RFC 2833 are a method of sending DTMF from one endpoint to another after the call media has been established. The tones are sent as packet data using the already established RTP stream and are distinguished from the audio by the RTP payload type field. For example, the audio of a call can be sent on a session with an RTP payload type that identifies it as G.711 data, and the DTMF packets are sent with an RTP payload type that identifies them as NTEs. The consumer of the stream utilizes the G.711 packets and the NTE packets separately. Key Press Markup Language (RFC 4730) The Key Press Markup Language (KPML) is defined in RFC 4730. Unlike NTEs, which is an in-band method of sending DTMF, KPML uses the signaling channel (out-of-band, or OOB) to send SIP messages containing the DTMF digits. KPML procedures use a SIP SUBSCRIBE message to register for DTMF digits. The digits themselves are delivered in NOTIFY messages containing an XML encoded body. Unsolicited Notify (UN) Unsolicited Notify procedures are used primarily by Cisco IOS SIP Gateways to transport DTMF digits using SIP NOTIFY messages. Unlike KPML, these NOTIFY messages are unsolicited, and there is no prior registration to receive these messages using a SIP SUBSCRIBE message. But like KPML, Unsolicited Notify messages are out-of-band. Also unlike KPML, which has an XML encoded body, the message body in these NOTIFY messages is a 10-character encoded digit, volume, and duration, describing the DTMF event. H.245 Signal, H.245 Alphanumeric H.245 is the media control protocol used in H.323 networks. In addition to its use in negotiating media characteristics, H.245 also provides a channel for DTMF transport. H.245 utilizes the signaling channel and, hence, provides an out-of-band (OOB) way to send DTMF digits. The Signal method carries more information about the DTMF event (such as its actual duration) than does Alphanumeric. Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) 6-18 OL-16394-07

Chapter 6 Media Resources Media Termination Point (MTP) Cisco Proprietary RTP This method sends DTMF digits in-band, that is, in the same stream as RTP packets. However, the DTMF packets are encoded differently than the media packets and use a different payload type. This method is not supported by Unified CM but is supported on Cisco IOS Gateways. Skinny Client Control Protocol (SCCP) The Skinny Client Control Protocol is used by Unified CM for controlling the various SCCP-based devices registered to it. SCCP defines out-of-band messages that transport DTMF digits between Unified CM and the controlled device.DTMF Between Endpoints The following rules apply to endpoints registered to Unified CM servers in the same cluster: • Calls between two non-SIP endpoints do not require MTPs. All Cisco Unified Communications endpoints other than SIP send DTMF to Unified CM via various signaling paths, and Unified CM forwards the DTMF between dissimilar endpoints. For example, an IP phone may use SCCP messages to Unified CM to send DTMF, which then gets sent to an H.323 gateway via H.245 signaling events. Unified CM provides the DTMF forwarding between different signaling types. • Calls between two Cisco SIP endpoints do not require MTPs. All Cisco SIP endpoints support NTE, so DTMF is sent directly between endpoints and no conversion is required. If all endpoints are Cisco SIP devices, then no MTPs are required for DTMF conversion. • A combination of a SIP endpoint and a non-SIP endpoint might require MTPs. To determine the support for NTE in your devices, see Table 6-11. Support of NTE is not limited to SIP and can be supported in devices with other call control protocols. For example, Cisco Unified IP Phones that run either an SCCP or SIP stack can support NTEs in both modes. Some devices support DTMF via multiple methods. (For example, a Cisco Unified IP Phone 7960 with an SCCP stack can send NTEs to the other device or SCCP to Unified CM.) Other devices such as the Cisco Wireless IP Phone 7920 can send only SCCP, and still others can send only NTE (such as the Cisco Unified IP Phone 7960 with a SIP stack). Unified CM has the ability to allocate MTPs dynamically on a call-by-call basis, based on the capabilities of the pair of endpoints. Use Table 6-11 to determine whether MTPs should be provisioned. Table 6-11 Endpoint Support for DTMF Methods Endpoint Protocol Stack: DTMF Method Endpoints SCCP NTE KPML1 SCCP Stack: Yes No No 7910, 7920, 7935, 7936 VG248 DPA-7610, DPA-7630 CTI Port, First Party Control Yes No Yes Cisco Unified Communications SRND (Based on Cisco Unified Communications Manager 7.x) OL-16394-07 6-19

Chapter 6 Media Resources SIP Trunk Table 6-11 Endpoint Support for DTMF Methods (continued) Endpoint Protocol Stack: DTMF Method Endpoints SCCP NTE KPML1 SCCP Stack: Yes Yes No VG224 7902, 7905, 7911,7912, 7931, 7937, 7940, 7941, 7942, 7945, 7960, 7961, 7962, 7965, 7970, 7971, 7975 Future new phone models SIP Stack: No Yes Yes for: 7911, 7941, 7942, 7945, 7961, 3911, 7905, 7911, 7912, 7940, 7941, 7942, 7962, 7965, 7970, 7971, 7975, 7945, and future new phone models 7960, 7961, 7962, 7965, 7970, 7971, 7975 No for: Future new phone models 3911, 7905, 7912, 7940, 7960 1. Key Press Markup Language (KPML)SIP Trunk A SIP trunk configuration is used to set up communication with a SIP User Agent such as another Cisco Unified CM cluster or a SIP gateway.SIP Early Offer SIP negotiates media exchange via Session Description Protocol (SDP), where one side offers a set of capabilities to which the other side answers, thus converging on a set of media characteristics. SIP allows the initial offer to be sent either by the caller in the initial INVITE message or, if the caller chooses not to, the called party can send the initial offer in the first reliable response. By default, Unified CM sends the INVITE without an initial offer, and it requires MTP resources to send the offer in the INVITE. Note that this initial offer is limited to the G.711 codec only. Also note that MTP resources are not required for incoming INVITE messages, whether or not they

Solution Reference Network Design Guide 7.X

by ashiesh0007 on Jun 11, 2012

Accessibility

Upload Details

Usage Rights

Statistics

Solution Reference Network Design Guide 7.X Document Transcript