sign in sign up
<<
Home , Conference call, Dial tone, Fax, Softphone, Telephony, Traffic classification

Cisco IP Video Solution Reference Network Design (SRND) Cisco CallManager Release 4.0 July 2004

Corporate Headquarters , Inc. 170 West Tasman Drive San Jose, CA 95134-1706 USA http://www.cisco.com Tel: 408 526-4000 800 553-NETS (6387) : 408 526-4100

Customer Order Number: 9562740406

THE SPECIFICATIONS AND INFORMATION REGARDING THE PRODUCTS IN THIS MANUAL ARE SUBJECT TO CHANGE WITHOUT NOTICE. ALL STATEMENTS, INFORMATION, AND RECOMMENDATIONS IN THIS MANUAL ARE BELIEVED TO BE ACCURATE BUT ARE PRESENTED WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED. USERS MUST TAKE FULL RESPONSIBILITY FOR THEIR APPLICATION OF ANY PRODUCTS.

THE LICENSE AND LIMITED WARRANTY FOR THE ACCOMPANYING PRODUCT ARE SET FORTH IN THE INFORMATION PACKET THAT SHIPPED WITH THE PRODUCT AND ARE INCORPORATED HEREIN BY THIS REFERENCE. IF YOU ARE UNABLE TO LOCATE THE SOFTWARE LICENSE OR LIMITED WARRANTY, CONTACT YOUR CISCO REPRESENTATIVE FOR A COPY.

The Cisco implementation of TCP header compression is an adaptation of a program developed by the University of California, Berkeley (UCB) as part of UCB’s public domain version of the UNIX operating system. All rights reserved. Copyright © 1981, Regents of the University of California.

NOTWITHSTANDING ANY OTHER WARRANTY HEREIN, ALL DOCUMENT FILES AND SOFTWARE OF THESE SUPPLIERS ARE PROVIDED “AS IS” WITH ALL FAULTS. CISCO AND THE ABOVE-NAMED SUPPLIERS DISCLAIM ALL WARRANTIES, EXPRESSED OR IMPLIED, INCLUDING, WITHOUT LIMITATION, THOSE 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, OR INCIDENTAL DAMAGES, INCLUDING, WITHOUT LIMITATION, LOST PROFITS OR LOSS OR DAMAGE TO DATA ARISING OUT OF THE USE OR INABILITY TO USE THIS MANUAL, EVEN IF CISCO OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

CCSP, the Cisco Square Bridge logo, Cisco Unity, Follow Me Browsing, FormShare, and StackWise are trademarks of Cisco Systems, Inc.; Changing the Way We Work, Live, Play, and Learn, and iQuick Study are service marks of Cisco Systems, Inc.; and Aironet, ASIST, BPX, Catalyst, CCDA, CCDP, CCIE, CCIP, CCNA, CCNP, Cisco, the Cisco Certified Internetwork Expert logo, Cisco IOS, Cisco Press, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Empowering the Generation, Enterprise/Solver, EtherChannel, EtherFast, EtherSwitch, Fast Step, GigaDrive, GigaStack, HomeLink, Internet Quotient, IOS, IP/TV, iQ Expertise, the iQ logo, iQ Net Readiness Scorecard, LightStream, , MeetingPlace, MGX, the Networkers logo, Networking Academy, Network Registrar, Packet, PIX, Post-Routing, Pre-Routing, ProConnect, RateMUX, Registrar, ScriptShare, SlideCast, SMARTnet, StrataView Plus, SwitchProbe, TeleRouter, The Fastest Way to Increase Your Internet Quotient, TransPath, and VCO are registered trademarks of Cisco Systems, Inc. and/or its affiliates in the and certain other countries.

All other trademarks mentioned in this document or Website are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (0406R)

Cisco IP Video Telephony Solution Reference Network Design (SRND) Copyright © 2004 Cisco Systems, Inc. All rights reserved.

CONTENTS

Preface vii New or Changed Information for This Release vii Revision History vii Obtaining Documentation viii Cisco.com viii Ordering Documentation viii Documentation Feedback viii Obtaining Technical Assistance ix Cisco Technical Support Website ix Submitting a Service Request ix Definitions of Service Request Severity ix Obtaining Additional Publications and Information x

CHAPTER 1 Introduction 1-1 IP Video Telephony Solution Components 1-1 Video Enhancements in Cisco CallManager 4.0 1-2 Protocols 1-2 Administration 1-4 Video Capabilities Per Device 1-4 Video Per Call 1-6 Video Bandwidth Per Location 1-6 Video Conference Bridge Resources 1-7 Serviceability 1-7

CHAPTER 2 Deployment Models 2-1 Single-Site Model 2-1 Multisite Model with Centralized Call Processing 2-2 Multisite Model with Distributed Call Processing 2-4

Cisco IP Video Telephony SRND 9562740406 iii Contents

CHAPTER 3 Endpoints 3-1 SCCP Endpoints 3-1 Cisco VT Advantage 3-1 Supported by VT Advantage 3-3 PC Requirements 3-3 SCCP Endpoints (T-1000 and T-550 Models) 3-4 H.323 Clients 3-5 Addressing for H.323 Clients 3-7 IP Address Matching for H.323 Clients 3-7

CHAPTER 4 Call Admission Control 4-1 Bandwidth Requirements 4-1 Channels 4-1 Bandwidth Used Per Call 4-2 Call Admission Control Within a Cluster 4-4 Regions 4-4 Locations 4-6 Call Admission Control Between Clusters 4-7 Non-Gatekeeper Controlled Intercluster Trunks 4-7 Gatekeeper-Controlled Intercluster Trunks 4-9 H.225 Gatekeeper-Controlled Trunks 4-9 Gatekeeper Bandwidth Values 4-9 Bandwidth Requests (BRQ) Enabled/Disabled 4-10 Retry Video Call as Audio 4-10 Wait for Far-End to Send TCS 4-12

CHAPTER 5 5-1 and Trust 5-2 Scheduling or Queuing 5-4 Queuing in the Campus 5-4 Queuing in the WAN 5-5 Bandwidth Provisioning 5-5 Traffic Shaping 5-5 Compressed RTP (cRTP) 5-5 Link Fragmentation and Interleaving (LFI) 5-6

Cisco IP Video Telephony SRND iv 9562740406 Contents

Endpoint QoS Classification 5-6 Cisco VT Advantage with a Cisco IP Phone 5-6 Tandberg SCCP Endpoints 5-7 H.323 Video Endpoints 5-7 ACL and Policing Support 5-8

CHAPTER 6 Gateways 6-1 Routing Inbound Calls from the PSTN 6-3 Routing Outbound Calls to the PSTN 6-4 Automated Alternate Routing (AAR) 6-5 Least-Cost Routing 6-7 ISDN B-Channel Binding, Rollover, and Busy Out 6-7 Inbound Calls 6-8 Outbound Calls 6-9 Configuring the Gateways in Cisco CallManager 6-9 Call Signaling Port Numbers 6-10 Call Signaling Timers 6-10 Voice Gateways Compatibility 6-10

CHAPTER 7 Multipoint Conferencing 7-1 SCCP MCU Resources 7-3 Media Resource Groups and Lists 7-4 H.323 MCU Resources 7-5 Service Templates and Prefixes 7-6 Gatekeeper Registration and Call Routing 7-7 Sizing the MCU 7-7 IVR for Dial-In Conference 7-8

CHAPTER 8 Gatekeepers 8-1 Endpoint Gatekeepers 8-2 Zone Definitions 8-2 Zone Prefixes and Technology Prefixes 8-3 Zone Subnets 8-4 Disabling the Use of Proxy 8-5 Intercluster Trunk Gatekeeper 8-5 Zone Definition and Prefixes 8-5 Bandwidth Management 8-6

Cisco IP Video Telephony SRND 9562740406 v Contents

Supported Gatekeeper Platforms 8-6 Gatekeeper Redundancy 8-7

CHAPTER 9 Applications 9-1 CTI Applications 9-1 Cisco Emergency Responder 9-1 Cisco IP Manager Assistant 9-2 Cisco IP Interactive Voice Response and Cisco IP Contact Center 9-2 Cisco Attendant Console 9-2 Cisco Personal Assistant 9-2 Cisco IP 9-3 Collaboration Solutions 9-3 T.120 Application Sharing 9-3 Cisco MeetingPlace 9-3 Networking Solutions 9-3 Cisco Aironet 802.11b Networking Solutions 9-3 Cisco Wireless IP Phone 7920 9-4 XML Services 9-4

CHAPTER 10 Security 10-1 Separating the Voice and Data VLANs 10-1 IP Phone Security Settings 10-2 Network Address Translation 10-2 Firewalls 10-3 Protecting the Video Infrastructure 10-3 Blocking Unauthorized Video Calls 10-3

I NDEX

Cisco IP Video Telephony SRND vi 9562740406

Preface

This document provides design considerations and guidelines for implementing Cisco IP Video Telephony solutions based on the Cisco Architecture for Voice, Video, and Integrated Data (AVVID). This document builds upon ideas and concepts presented in the Cisco IP Telephony Solution Reference Network Design (SRND), which is available online at http://cisco.com/go/srnd This document assumes that you are already familiar with the basic terms and concepts presented in the Cisco IP Telephony SRND. To review any of those terms and concepts, refer to the documentation at the preceding URL.

New or Changed Information for This Release

Unless stated otherwise, the information in this document applies specifically to Cisco CallManager Release 4.0. Table 1 lists the topics that are new in the current release of this document or that have changed significantly from previous releases of Cisco CallManager.

Table 1 New or Changed Information for Cisco CallManager Release 4.0

Topic Described in: IP Video Telephony features and capabilities Video Enhancements in Cisco CallManager 4.0, page 1-2

Revision History

This document may be updated at any time without notice. You can obtain the latest version of this document online at http://cisco.com/go/srnd 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 most recent online version at the preceding URL. The following table lists the revision history for this document.

Revision Date Comments July, 2004 Initial version of this document for Cisco CallManager Release 4.0.

Cisco IP Video Telephony SRND 9562740406 vii Preface Obtaining Documentation

Obtaining Documentation

Cisco documentation and additional literature are available on Cisco.com. Cisco also provides several ways to obtain technical assistance and other technical resources. These sections explain how to obtain technical information from Cisco Systems.

Cisco.com

You can access the most current Cisco documentation at this URL: http://www.cisco.com/univercd/home/home.htm You can access the Cisco website at this URL: http://www.cisco.com You can access international Cisco websites at this URL: http://www.cisco.com/public/countries_languages.shtml

Ordering Documentation

You can find instructions for ordering documentation at this URL: http://www.cisco.com/univercd/cc/td/doc/es_inpck/pdi.htm You can order Cisco documentation in these ways: • Registered Cisco.com users (Cisco direct customers) can order Cisco product documentation from the Ordering tool: http://www.cisco.com/en/US/partner/ordering/index.shtml • Nonregistered Cisco.com users can order documentation through a local account representative by calling Cisco Systems Corporate Headquarters (California, USA) at 408 526-7208 or, elsewhere in North America, by calling 800 553-NETS (6387).

Documentation Feedback

You can send comments about technical documentation to [email protected]. You can submit comments by using the response card (if present) behind the front cover of your document or by writing to the following address: Cisco Systems Attn: Customer Document Ordering 170 West Tasman Drive San Jose, CA 95134-9883 We appreciate your comments.

Cisco IP Video Telephony SRND viii 9562740406 Preface Obtaining Technical Assistance

Obtaining Technical Assistance

For all customers, partners, resellers, and distributors who hold valid Cisco service contracts, Cisco Technical Support provides 24-hour-a-day, award-winning technical assistance. The Cisco Technical Support Website on Cisco.com features extensive online support resources. In addition, Cisco Technical Assistance Center (TAC) engineers provide support. If you do not hold a valid Cisco service contract, contact your reseller.

Cisco Technical Support Website

The Cisco Technical Support Website provides online documents and tools for troubleshooting and resolving technical issues with Cisco products and technologies. The website is available 24 hours a day, 365 days a year at this URL: http://www.cisco.com/techsupport Access to all tools on the Cisco Technical Support Website requires a Cisco.com user ID and password. If you have a valid service contract but do not have a user ID or password, you can register at this URL: http://tools.cisco.com/RPF/register/register.do

Submitting a Service Request

Using the online TAC Service Request Tool is the fastest way to open S3 and S4 service requests. (S3 and S4 service requests are those in which your network is minimally impaired or for which you require product information.) After you describe your situation, the TAC Service Request Tool automatically provides recommended solutions. If your issue is not resolved using the recommended resources, your service request will be assigned to a Cisco TAC engineer. The TAC Service Request Tool is located at this URL: http://www.cisco.com/techsupport/servicerequest For S1 or S2 service requests or if you do not have , contact the Cisco TAC by telephone. (S1 or S2 service requests are those in which your production network is down or severely degraded.) Cisco TAC engineers are assigned immediately to S1 and S2 service requests to help keep your operations running smoothly. To open a service request by telephone, use one of the following numbers: Asia-Pacific: +61 2 8446 7411 (Australia: 1 800 805 227) EMEA: +32 2 704 55 55 USA: 1 800 553 2447 For a complete list of Cisco TAC contacts, go to this URL: http://www.cisco.com/techsupport/contacts

Definitions of Service Request Severity

To ensure that all service requests are reported in a standard format, Cisco has established severity definitions. Severity 1 (S1)—Your network is “down,” or there is a critical impact to your business operations. You and Cisco will commit all necessary resources around the clock to resolve the situation.

Cisco IP Video Telephony SRND 9562740406 ix Preface Obtaining Additional Publications and Information

Severity 2 (S2)—Operation of an existing network is severely degraded, or significant aspects of your business operation are negatively affected by inadequate performance of Cisco products. You and Cisco will commit full-time resources during normal business hours to resolve the situation. Severity 3 (S3)—Operational performance of your network is impaired, but most business operations remain functional. You and Cisco will commit resources during normal business hours to restore service to satisfactory levels. Severity 4 (S4)—You require information or assistance with Cisco product capabilities, installation, or configuration. There is little or no effect on your business operations.

Obtaining Additional Publications and Information

Information about Cisco products, technologies, and network solutions is available from various online and printed sources. • Cisco Marketplace provides a variety of Cisco books, reference guides, and logo merchandise. Visit Cisco Marketplace, the company store, at this URL: http://www.cisco.com/go/marketplace/ • The Cisco Product Catalog describes the networking products offered by Cisco Systems, as well as ordering and customer support services. Access the Cisco Product Catalog at this URL: http://cisco.com/univercd/cc/td/doc/pcat/ • Cisco Press publishes a wide range of general networking, training and certification titles. Both new and experienced users will benefit from these publications. For current Cisco Press titles and other information, go to Cisco Press at this URL: http://www.ciscopress.com • Packet magazine is the Cisco Systems technical user magazine for maximizing Internet and networking investments. Each quarter, Packet delivers coverage of the latest industry trends, technology breakthroughs, and Cisco products and solutions, as well as network deployment and troubleshooting tips, configuration examples, customer case studies, certification and training information, and links to scores of in-depth online resources. You can access Packet magazine at this URL: http://www.cisco.com/packet • iQ Magazine is the quarterly publication from Cisco Systems designed to help growing companies learn how they can use technology to increase revenue, streamline their business, and expand services. The publication identifies the challenges facing these companies and the technologies to help solve them, using real-world case studies and business strategies to help readers make sound technology investment decisions. You can access iQ Magazine at this URL: http://www.cisco.com/go/iqmagazine • Journal is a quarterly journal published by Cisco Systems for engineering professionals involved in designing, developing, and operating public and private and intranets. You can access the Internet Protocol Journal at this URL: http://www.cisco.com/ipj • World-class networking training is available from Cisco. You can view current offerings at this URL: http://www.cisco.com/en/US/learning/index.html

Cisco IP Video Telephony SRND x 9562740406

CHAPTER 1

Introduction

Cisco introduced its IP Video Telephony solution in Cisco CallManager Release 4.0. With this new solution, video is now fully integrated into Cisco CallManager, and there are also new endpoints available from Cisco and its strategic partners. Video is now just as easy to deploy, manage, and use as a Cisco IP Phone.

IP Video Telephony Solution Components

The Cisco IP Video Telephony solution consists of Cisco CallManager 4.0, Cisco IP/VC 3500 Series Multipoint Control Units (MCUs) for both H.323 and Skinny Client Control Protocol (SCCP) conference calls, Cisco IP/VC 3500 Series H.320 Gateways, Cisco IOS H.323 Gatekeeper, Cisco VT Advantage, Tandberg SCCP endpoint solutions, and the existing range of H.323-compliant products from partners such as , Tandberg, Sony, VCON, VTEL, and others. (See Figure 1-1.)

Figure 1-1 IP Video Telephony Components

H.323-based SCCP-based video endpoints video endpoints

H.320 gateways Cisco CallManager 4.0 Cisco VT Advantage M

M M H.323 IP gatekeeper M M

GK

SCCP- based H.323-based conference bridges conference bridges 119450

Cisco IP Video Telephony SRND 9562740406 1-1 Chapter 1 Introduction Video Enhancements in Cisco CallManager 4.0

Video Enhancements in Cisco CallManager 4.0

Cisco CallManager Release 4.0 has added enhancements in the following areas to support IP Video Telephony: • Protocols, page 1-2 • Administration, page 1-4 • Serviceability, page 1-7

Protocols

Cisco CallManager Release 4.0 adds support for video in both Skinny Client Control Protocol (SCCP) and the H.323 protocol. Cisco CallManager can now manage H.323 endpoints, Multipoint Control Units (MCUs), and gateways, providing the system administrator with PBX-style control over all call routing and bandwidth management for those devices. SCCP and H.323 endpoints have the following characteristics: • H.323 devices typically register with an H.323 gatekeeper (such as the Cisco IOS Gatekeeper). The H.323 gatekeeper maintains the registration state of each endpoint, but it directs all call requests to Cisco CallManager. SCCP devices register directly with Cisco CallManager. • H.323 devices send the complete dialed number all at once in their H.225 setup . SCCP devices send each dialed digit one-by-one as they are entered on the keypad. The difference is subtle but worth noting because it affects the user’s experience. Dialing on an H.323 device is much like dialing on a cell phone: the user types in the entire number and then presses the "Call" or "Dial" button to initiate the call. SCCP devices are more like a tradition telephone, in which the user goes off-hook, receives from Cisco CallManager, and then starts dialing digits. • H.323 devices are configured through the user interface of each endpoint. Changes to the configuration or software/firmware loads must be done locally on each endpoint (or, in some cases, through SNMP or other vendor-specific management applications). SCCP devices are centrally controlled and configured in Cisco CallManager Administration. The configuration and software/firmware loads are then pushed down to the endpoints via the Trivial (TFTP). One exception to this is the Tandberg SCCP devices, which receive their configurations via TFTP but software/firmware upgrades must be done manually (or through Tandberg’s management application(s). • H.323 devices advertise their capabilities to Cisco CallManager on a call-by-call basis. SCCP devices advertise their capabilities when they register with Cisco CallManager and whenever their capabilities change. Cisco CallManager then decides, on a call-by-call basis, which types of media channels are negotiated between the endpoints. • H.323 devices offer basic call capabilities; SCCP devices offer PBX-style features such Hold, Transfer, Conference, Park, Pickup, Group Pickup, and more. • For both types of endpoints, the signaling channels are routed by Cisco CallManager, but the media streams (audio and video channels) flow directly between the endpoints using the Real-Time Transport Protocol (RTP). • H.323 and SCCP endpoints can call one another. Cisco CallManager provides the signaling translation between the two protocols and negotiates common media capabilities (common codecs).

Cisco IP Video Telephony SRND 1-2 9562740406 Chapter 1 Introduction Video Enhancements in Cisco CallManager 4.0

SCCP endpoints can invoke supplementary services, such as placing the call on hold, transferring the call, conferencing with another party, and so forth. H.323 devices that support receiving EmptyCapabilitiesSet (ECS) messages may be the recipients of such features (that is, they may be placed on hold, transferred, or conferenced), but they cannot invoke those features. H.323-to-SCCP calls are not the only types of calls allowed by Cisco CallManager. Any device can call any other device, but video is supported only on SCCP and H.323 devices. Specifically, video is not supported in the following protocols in Cisco CallManager Release 4.0: • Telephony Integration (CTI) applications (TAPI and JTAPI) • Control Protocol (MGCP) • Session Initiation Protocol (SIP) Therefore, Cisco CallManager currently supports the types of calls listed in Table 1-1.

Table 1-1 Types of Calls Supported in Cisco CallManager Release 4.0

Calling Device Called Device Type Type SCCP H.323 MGCP TAPI/JTAPI SIP SCCP Audio and Audio and Audio only Audio only Audio only video video H.323 Audio and Audio and Audio only Audio only Audio only video video MGCP Audio only Audio only Audio only Audio only Audio only TAPI/JTAPI Audio only Audio only Audio only Audio only Audio only SIP Audio only Audio only Audio only Audio only Audio only

Table 1-2 lists the audio and video algorithms and protocols currently supported in Cisco CallManager.

Table 1-2 Capabilities Supported in Cisco CallManager Release 4.0

H.323 SCCP H.261 H.261 H.263+ H.263+ G.711 A-law and mu-law G.711 A-law and mu-law G.723.1 G.723.1 G.728 G.728 G.729, G.729a, G.729b, and G.729ab G.729, G.729a, G.729b, and G.729ab G.722 G.722 Far-end camera control Out-of- DTMF (H.245 alphanumeric) Out-of-band DTMF Cisco Cisco VT Camera Wideband Video

Cisco IP Video Telephony SRND 9562740406 1-3 Chapter 1 Introduction Video Enhancements in Cisco CallManager 4.0

Administration

Cisco CallManager provides the administrator with complete control over which devices can perform video calls, how much video bandwidth is allocated per call, how much video bandwidth is allocated per location, and who is allowed to call whom. These capabilities have been inherent in Cisco CallManager for audio since the early releases of that product. Cisco CallManager Release 4.0 adds video to each of these areas, thus enabling video to be managed in the same way as audio. In addition to the enhancements made specifically for video (described in the following sections), all other aspects of Cisco CallManager Administration and most of the features supported by Cisco CallManager for audio devices are inherently available for video now as well. This document does not address all of those features and settings but, in general, if the feature is available for an audio device, it is now available for a video device as well.

Video Capabilities Per Device

You can configure the following new video-related features at the device level for phones or H.323 clients: • Video Capabilities: Enabled/Disabled, page 1-4 • Retry Video Call as Audio, page 1-4 • Wait for Far-End to Send TCS, page 1-5

Video Capabilities: Enabled/Disabled

This drop-down box enables and disables VT Advantage on the Cisco IP Phones 7940, 7960, and 7970. (For more details on VT Advantage, see the chapter on Endpoints, page 3-1.) When this feature is enabled, an icon representing a camera appears in the bottom right-hand corner of the IP Phone display. By default, VT Advantage is disabled. You can also use the Bulk Administration Tool to modify this setting on many phones at once.

Retry Video Call as Audio

This check-box is available on all endpoint types that support video, including Cisco IP Phones 7940, 7960, and 7970, as well as Tandberg SCCP endpoints and all H.323 devices (clients, gateways and all types of H.323 trunks). When this option is activated (checked), if there is not enough bandwidth to reach the device (for example, if the Cisco CallManager regions or locations do not allow video for that call), then Cisco CallManager will retry the call as an audio-only call. When this option is deactivated (unchecked), Cisco CallManager will not retry the call as audio-only but instead will either fail the call or reroute the call by whatever automated alternate routing (AAR) path is configured. The Retry Video Call as Audio option takes effect only on the terminating (called) device, thus allowing the flexibility for the calling device to have different options (retry or AAR) for different destinations. If the video call fails due to bandwidth limitations but automated alternate routing (AAR) is enabled, Cisco CallManager will attempt to reroute the failed call as a video call to the AAR destination. If AAR is not enabled, the failed call will result in a busy tone and an error being sent to the caller. (See Figure 1-2.) Depending on the type of device that is calling, the failed call will result in one of the following conditions: • If the calling device is an SCCP endpoint with an LCD display screen (such as a Tandberg SCCP endpoint or a Cisco IP Phone model 7905, 7912, 7935, 7936, 7940, 7960, or 7970), the caller will hear busy tone and will see the message "Bandwidth Unavailable" displayed on the device.

Cisco IP Video Telephony SRND 1-4 9562740406 Chapter 1 Introduction Video Enhancements in Cisco CallManager 4.0

• If the calling device is an SCCP endpoint without an LCD display screen (such as a Cisco IP Phone 7902), the caller will hear busy tone. • If the calling device is an H.323 or SIP device or a PSTN device connected through a gateway, the caller will hear busy tone and Cisco CallManager will send the appropriate error message (such as a Q.931 cause code) back to the H.323, SIP, or MGCP device.

Note References to the various IP Phone models do not indicate that all of these models support video. The only SCCP endpoints that support video capabilities are the Tandberg SCCP devices and the Cisco IP Phone models 7940, 7960, and 7970. The other phone models are mentioned only with respect to their LCD screen capabilities and how those capabilities relate to the users’ experience when a call fails due to bandwidth constraints.

Figure 1-2 Possible Scenarios for a Video Call

Video call Ye s Enough bandwidth Video call initiated for video call?

No

“Retry Video as Audio” Ye s Audio-only enabled on terminating call device?

No

Video call No AAR configured Ye s Ye s Call fails and enabled on with AAR both devices? successful?

No 119462

See the chapter on Call Admission Control, page 4-1, for further details on the use of AAR. By default, this retry option is enabled (checked). It is not currently available in the Bulk Administration Tool (BAT), so to disable it you must uncheck it on each endpoint, gateway, and trunk device manually.

Wait for Far-End to Send TCS

This check-box is available only on H.323 devices, including H.323 clients, H.323 gateways, and H.225 gatekeeper-controlled trunks. When this option is enabled (checked), Cisco CallManager will wait to collect the Terminal Capabilities Set (TCS) of each endpoint before forwarding its own TCS to them. When this option is disabled (unchecked), Cisco CallManager will not wait but will immediately forward its own TCS to the endpoint.

Cisco IP Video Telephony SRND 9562740406 1-5 Chapter 1 Introduction Video Enhancements in Cisco CallManager 4.0

By default, the Wait for Far-End to Send TCS option is enabled (checked). However, you must uncheck (disable) it in the following circumstances: • When the H.323 device communicating with Cisco CallManager is also waiting for the far-end to send its TCS In this case, a stalemate occurs because neither side sends its TCS, and the H.245 connection times out after a few seconds. Examples of devices that also wait for the far-end to send TCS are some H.323 routed-mode gatekeepers, H.320 gateways, H.323 proxies (or IP-to-IP gateways) and some H.323 multi-point conference bridges. These devices wait for the far-end to send TCS for the same reason Cisco CallManager does: because they are waiting for both sides of the connection to send their TCS before forwarding them to the other side. • When communicating with another Cisco CallManager cluster over an intercluster trunk

Note For intercluster trunks and gatekeeper-controlled intercluster trunks, the Wait for Far-End to Send TCS option is always disabled and cannot be enabled.

The Wait for Far-End to Send TCS option is not currently available in the Bulk Administration Tool (BAT), so you must uncheck it manually on each endpoint, gateway, and trunk device for which you want to disable this feature.

Video Bandwidth Per Call

Cisco CallManager regions represent logical groupings of devices and enable you to define the maximum audio and video bandwidth allowed per call within a region and between that region and each other region. All types of devices belong to a region, including endpoints, gateways, trunks, transcoders, conference bridges, music-on-hold servers, and so forth. Regions have been available in previous releases of Cisco CallManager to control the audio bandwidth. What is new in Cisco CallManager Release 4.0 is the ability to control the amount of video bandwidth as well. There are now two separate fields configurable for each region: one for audio bandwidth and the other for video bandwidth. The audio setting applies to both audio-only calls and the audio channel of video calls, while the video bandwidth applies only to video calls. For more details, see Call Admission Control Within a Cluster, page 4-4.

Video Bandwidth Per Location

While regions define the amount of bandwidth allocated per call, locations define the amount of bandwidth allocated for all devices in a given location. More specifically, a location defines the aggregate bandwidth allocated for all calls between that location and all other locations. Calls between devices within the same location are not counted. When a call is placed between a device in a given location and a device outside that location, the bandwidth allotted to the two locations is decremented by the amount used by that call. When a location has no more bandwidth available, new calls to other locations are rejected. If a call is rejected due to the location bandwidth rules, the call will either fail (that is, busy tone is played and a "Bandwidth Unavailable" message is displayed) or AAR, if it is configured, will attempt to reroute the call. For more details, see the chapter on Call Admission Control, page 4-1. Beginning with Cisco CallManager Release 4.0, there are now two bandwidth pools, one for audio-only calls and the other for video calls. Unlike regions, where the bandwidth limit also affects the audio codec used for video calls, the audio bandwidth field configured for a location pertains only to audio calls. If the audio and video bandwidth were not allocated separately, audio could take all the bandwidth, leaving no room for any video calls, and vice versa.

Cisco IP Video Telephony SRND 1-6 9562740406 Chapter 1 Introduction Video Enhancements in Cisco CallManager 4.0

Note Different methods are used to calculate the values for the Audio Bandwidth and Video Bandwidth fields, so be careful to use the correct values when configuring those fields. For more details, see Locations, page 4-6.

Locations interact with regions as well as with the Retry Video Call as Audio feature. First, the audio codec and the video bandwidth set in the region define the maximum speed () of the video call. The combined video and audio bandwidth is then deducted from the location’s Video Bandwidth field. If the location does not have enough bandwidth to allow the video call, Cisco CallManager checks the setting of Retry Video Call as Audio to determine how to handle that call. If the feature is enabled, the call will continue as audio, with audio region and audio location checks being made. Otherwise, the call will either fail (with busy tone played and "Bandwidth Unavailable" message displayed to the user) or AAR will try to reroute the call.

Video Conference Bridge Resources

Cisco CallManager Administration has also been enhanced to add support for SCCP video conference bridge resources. Conference bridge resources are used when a phone user presses the Conf, Join, cBarge, or MeetMe softkeys. You can configure a Cisco IP/VC 3500 Series MCU (IPVC-35xx) as an SCCP video conference bridge resource in Cisco CallManager and assign it to a media resource group. When a user presses the Conf, Join, cBarge, or MeetMe softkey on a video-capable device, Cisco CallManager automatically invokes a video conference bridge resource for that call. Cisco CallManager applies the following criteria, in the order listed, to select which conference bridge resource to use: 1. The priority order in which the media resource groups (MRGs) are listed in the media resource group list (MRGL) 2. Within the selected MRG, the resource that has been used the least For example, Cisco CallManager selects the first MRG that has a conference bridge in it and then selects the conference bridge within that MRG that has been used the least. Therefore, in order for a video-capable device to invoke a video conference bridge resource, that resource must always be in the first MRG of the MRGL and must be the bridge that has been used the least within that MRG. However, this configuration can result in a video conference bridge being used for conferences in which all the participants are audio-only. For more details, see the chapter on Multipoint Conferencing, page 7-1.

Serviceability

Cisco CallManager has historically offered a multitude of serviceability features for IP Telephony networks, including trace files, performance monitor counters, Simple Network Management Protocol (SNMP) management information bases (MIBs), alarms and traps, system logs, real-time monitoring tools, quality reporting, call detail recording, bulk administration, and several application programmable interfaces (APIs). All of these tools have been leveraged in Cisco CallManager Release 4.0 to provide serviceability for video devices and video calls as well. Where necessary, these tools have been updated specifically to incorporate video, as follows: • All video-related aspects of device registration and management and call routing appear in Cisco CallManager trace files. For instance, H.225 and H.245 traces now show all of the video capabilities negotiated, and SCCP device traces now show all of the video-related messages added to the SCCP protocol for this release. For example, the SCCP message sent by Cisco CallManager

Cisco IP Video Telephony SRND 9562740406 1-7 Chapter 1 Introduction Video Enhancements in Cisco CallManager 4.0

to an audio device instructing it to open an RTP media channel for audio is StationOpenMediaChannel, whereas the same message used to instruct the device to open an RTP media channel for video is StationOpenMultiMediaChannel.

Caution Use trace files with caution. They can impact call processing and disk utilization.

• The following new counters have been added to the existing list of performance monitor (PerfMon) counters, and they can be viewed by using the Performance Monitor snap-in or the Real-Time Monitoring Tool (RTMT): – VideoCallsActive – VideoCallsCompleted – VideoOutOfResources – LocationsVideoBandwidthAvailable – LocationsVideoBandwidthMaximum – LocationsVideoOutOfResources – VCBConferencesActive – VCBConferencesAvailable – VCBConferencesCompleted – VCBConferencesTotal – VCBOutOfConferences – VCBOutOfResources – VCBResourceActive – VideoResourceAvailable – VideoResourceTotal • The following new video-related fields appear in all call detail records (CDRs): – origVideoCap_Codec – destVideoCap_Codec – origVideoCap_Bandwidth – destVideoCap_Bandwidth – origVideoCap_Resolution – destVideoCap_Resolution – origVideoTransportAddress_IP – origVideoTransportAddress_Port – destVideoTransportAddress_IP – destVideoTransportAddress_Port

Note If the call is not a video call, these fields will be left blank.

Cisco IP Video Telephony SRND 1-8 9562740406

CHAPTER 2

Deployment Models

Because video is simply an addition to Cisco CallManager's existing capabilities, all of the deployment models historically used for voice are applicable for video as well. Video deployments follow the same format and logic as existing voice deployments models. Therefore, this document assumes that the reader is already familiar with the Cisco IP Telephony deployment models and does not attempt to define them again. The review the full details of each deployment model, refer to the Cisco IP Telephony Solution Reference Network Design (SRND) for Cisco CallManager Release 4.0, available at http://cisco.com/go/srnd This chapter points out those areas of the deployment models that relate specifically to video telephony.

Single-Site Model

This deployment model represents a typical campus network design, where all of the Cisco CallManagers, gateways, gatekeepers, MCUs, endpoints, and applications are physically located at the same site. The single-site model has the following video-related design characteristics: • Single Cisco CallManager or Cisco CallManager cluster. • Maximum of 30,000 SCCP video endpoints (Cisco IP Phones or Tandberg endpoints running SCCP). • Maximum of 500 H.323 gateways, MCUs, and clients. • Cisco IOS Gatekeeper required for H.323 MCUs, clients, and H.323/H.320 gateways. Up to five gatekeepers can be clustered for 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 all devices. The Cisco VT Advantage Wideband Codec, operating at 7 Mbps, is also supported. Figure 2-1 illustrates the single-site model.

Cisco IP Video Telephony SRND 9562740406 2-1 Chapter 2 Deployment Models Multisite Model with Centralized Call Processing

Figure 2-1 Single-Site Deployment Model

MCU's Applications

Gatekeeper Cisco CallManager cluster cluster

M GK GK

M M

GK GK M M H.320 gateways

IP ISDN network

V IP Voice gateway 119459

Multisite Model with Centralized Call Processing

This deployment model represents a typical WAN network design, where all of the Cisco CallManagers, gateways, gatekeepers, MCUs, endpoints, and applications are physically located at the central site, and a QoS-enabled WAN connects the remote sites to the central site. The centralized multisite model has the following video-related design characteristics: • Single Cisco CallManager or Cisco CallManager cluster • Maximum of 30,000 SCCP video endpoints (Cisco IP Phones or Tandberg endpoints running SCCP) • Maximum of 500 H.323 gateways, MCUs, and clients • Cisco IOS Gatekeeper required for H.323 MCUs, clients, and H.323/H.320 gateways. Up to five gatekeepers can be clustered for 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.

Cisco IP Video Telephony SRND 2-2 9562740406 Chapter 2 Deployment Models Multisite Model with Centralized Call Processing

• 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 VT 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. • Cisco CallManager locations provide call admission control, and automated alternate routing (AAR) is also supported for video calls. • Maximum of 500 locations per Cisco CallManager cluster. • Survivable Remote Site Telephony (SRST) is not supported for video. If the WAN connection fails, video endpoints located at the remote sites become audio-only devices. An active video call will continue with both video and audio channels, but it will not be able to activate additional features such as call transfer. In SRST mode, new calls are always audio-only. Figure 2-2 illustrates the multisite model with centralized call processing.

Figure 2-2 Multisite Deployment Model with Centralized Call Processing

Gatekeeper Cisco CallManager IP cluster cluster H.320 M IP GK GK gateway M M

GK GK M M V H.320 Branch A Applications gateway ISDN network

MCU's IP

IP WAN V V

IP IP

PSTN IP Headquarters 119460 Branch B

Cisco IP Video Telephony SRND 9562740406 2-3 Chapter 2 Deployment Models Multisite Model with Distributed Call Processing

Multisite Model with Distributed Call Processing

This deployment model is used when a single Cisco CallManager cluster is not large enough to support the entire network, or when an enterprise requires multiple Cisco CallManager clusters for geographical or organizational reasons. This model consists of Cisco CallManager clusters connected to each other via H.323 intercluster trunks. Each cluster has its own Cisco CallManagers, gateways, gatekeepers, MCUs, endpoints, and applications, and a QoS-enabled WAN connects all the sites. The distributed multisite model has the following video-related design characteristics: • Multiple Cisco CallManager clusters connected to each other via H.323 intercluster trunks • Maximum of 30,000 SCCP video endpoints (Cisco IP Phones or Tandberg endpoints running SCCP) per cluster. • Maximum of 500 H.323 gateways, MCUs, and clients per cluster. • Cisco IOS Gatekeeper required for H.323 MCUs, clients, and H.323/H.320 gateways in each cluster. Up to five gatekeepers can be clustered for redundancy. Each cluster requires its own gatekeeper, and these gatekeepers must be separate from the one controlling the intercluster trunks. • 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 VT 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 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 Cisco IOS Gatekeepers for the intercluster trunks. Automated alternate routing (AAR) is also supported for video calls. Figure 2-3 illustrates the multisite model with distributed call processing.

Cisco IP Video Telephony SRND 2-4 9562740406 Chapter 2 Deployment Models Multisite Model with Distributed Call Processing

Figure 2-3 Multisite Deployment Model with Distributed Call Processing

GK GK

GK GK

M

M M

M M

Gatekeeper Cisco CallManager cluster cluster H.320 IP M gateway GK GK IP M M V M M GK GK Branch A H.320 gateway Applications H.320 ISDN gateway GK GK network

GK GK MCU's M

IP WAN M M V V M M

IP IP PSTN IP Headquarters

IP

Branch B 119461

Cisco IP Video Telephony SRND 9562740406 2-5 Chapter 2 Deployment Models Multisite Model with Distributed Call Processing

Cisco IP Video Telephony SRND 2-6 9562740406

CHAPTER 3

Endpoints

Cisco CallManager Release 4.0 supports the following types of video-enabled endpoints: • Cisco VT Advantage associated with a Cisco IP Phone 7940, 7960, or 7970 running Skinny CLient Control Protocol (SCCP) • Tandberg T-1000 or T-550 models running SCCP • H.323 clients (Tandberg, Polycom, PictureTel, Sony, VCON, VTEL, Microsoft NetMeeting, and others)

SCCP Endpoints

SCCP video endpoints register directly with Cisco CallManager and download their configurations via Trivial File Transfer Protocol (TFTP). They support many features and supplementary services, including hold, transfer, conference, park, pickup and group pickup, music on hold, shared appearances, mappable softkeys, (busy, no answer, and unconditional), and much more.

Cisco VT Advantage

Cisco VT Advantage is a Windows-based application and USB camera that you can install on a Windows 2000 or Windows XP . When the PC is physically connected to the PC port on a Cisco IP Phone 7940, 7960, or 7970, the VT Advantage application "associates" with the phone, thus enabling users to operate their phones as they always have, but now with the added benefit of video. The system administrator can control which IP Phones allow this association to take place by toggling the Video Capabilities: Enabled/Disabled setting on the IP Phone configuration page in Cisco CallManager Administration. When this feature is enabled, an icon representing a camera appears in the bottom right-hand corner of the IP Phone display. By default, VT Advantage is disabled. You can also use the Bulk Administration Tool to modify this setting on many phones at once. Note that the PC Port: Enabled/Disabled setting must also be enabled for VT Advantage to work; however, the PC Access to Voice VLAN setting does not have to be enabled. To achieve the association, VT Advantage installs a Cisco Discovery Protocol (CDP) driver into the interface of the PC. CDP enables the PC and the IP Phone to discover each other automatically, which means that the user does not have to configure anything on the PC or the IP Phone in order for VT Advantage to work. The user can, therefore, plug the PC into any IP Phone that is video-enabled and automatically associate with it. (See Figure 3-1.)

Cisco IP Video Telephony SRND 9562740406 3-1 Chapter 3 Endpoints SCCP Endpoints

Figure 3-1 Initiating a Cisco VT Advantage Call

Phone VLAN = 110 PC VLAN = 10 Campus Si IP CDP M IP Phone: VT Advantage 1 802.1Q/p 10.70.110.100 171.70.10.100

2 “I want to associate with you”

3 “Open video channel”3 “Open video channel”

4 Video packets

4 Audio packets

1 Phone and PC exchange CDP messages. Phone begins listening for PC association packets on TCP port 4224 from IP address of CDP neighbor.

2 PC initiates association messages to phone over TCP/IP. Association packets are routed up to Layer-3 boundary between VLANs. Firewalls and/or ACLs must permit TCP port 4224.

3 Phone acts as SCCP proxy between VT Advantage and Cisco CallManager. Cisco CallManager tells phone to open video channels per call, and phone proxies those messages to PC.

Phone sends/receives audio; PC sends/receives video. Audio and video marked DSCP AF41. 4 119453 Video on UDP port 5445.

When a call is made using VT Advantage, the audio is handled by the IP Phone while the video is handled by the PC. There is no synchronization mechanism between the two devices, so QoS is essential to minimize , , fragmented packets, and out-of-order packets. The IP Phone resides in the voice VLAN, while the PC resides in the data VLAN, which means that there must be a Layer-3 routing path between the voice and data VLANs in order for the associating to occur. If there are access control lists (ACLs) or firewalls between these VLANs, they must be configured to permit the association protocol (which uses TCP port 4224 in both directions) to pass. Cisco VT Advantage supports Code Point (DSCP) traffic classifications. Cisco CallManager specifies the DSCP value in the SCCP messages it sends to the phone. When the IP Phone makes an audio-only call, it marks its SCCP control traffic as DSCP CS3 and its audio RTP media traffic as DSCP EF. However, when the IP Phone makes a video call, it marks its SCCP control traffic as DSCP CS3 and its audio RTP media traffic as DSCP AF41, and the VT Advantage application marks its video RTP media traffic as DSCP AF41 as well. Both the IP Phone and the VT Advantage application mark their "association" protocol messages as DSCP CS3 because it is considered to be signaling traffic and is grouped with all other signaling traffic such as SCCP.

Note Cisco CallManager Release 4.0 added security features to the Cisco IP Phone 7970 to enable it to use (TLS) and Secure RTP (sRTP) to authenticate and encrypt signaling and audio media traffic. The association protocol does not use this or , nor are the video RTP media streams encrypted. However, the SCCP signaling and the audio RTP media streams are encrypted if they are so configured.

Cisco IP Video Telephony SRND 3-2 9562740406 Chapter 3 Endpoints SCCP Endpoints

Cisco VT Advantage, like any other application that runs on a PC, does have an impact on system performance, which you should take into consideration. VT Advantage supports two types of video codecs: H.263 and the Cisco VT Camera Wideband Video Codec. Of these two types, the Cisco VT Camera Wideband Video Codec places the least demands on the PC. Therefore, if your network has plenty of available bandwidth, you can use the Cisco VT Camera Wideband Video Codec and save on PC CPU and memory resources. The H.263 codec is more demanding on the PC system resources, but it requires less bandwidth. Therefore, if you want to use H.263 compressed video to save on bandwidth usage on the network, you should ensure that your PCs have plenty of available CPU and memory resources. The VT Advantage H.263 codec supports a range of speeds up to 1.5 Mbps. In summary, customers must balance PC performance with network utilization when deploying Cisco VT Advantage.

Codecs Supported by VT Advantage

Cisco VT Advantage supports the following types of audio and video codecs: • H.263 – Bandwidth: up to 1.5 Mbps – Resolution: Common Intermediate Format (CIF) and Quarter Common Intermediate Format (QCIF) – Frame Rate: up to 30 frames per second (fps) • Cisco VT Camera Wideband Video Codec – Bandwidth: 7 Mbps – Resolution: 320x240 – Frame Rate: up to 30 fps • G.711 – Bandwidth: 64 kbps (handled by the IP Phone) • G.729 – Bandwidth: 8 kbps (handled by the IP Phone) • Cisco Wideband Audio Codec – Bandwidth 256 kbps (handled by the IP Phone)

PC Requirements

PCs with the Cisco VT Advantage client connect to the PC port of video-enabled Cisco IP Phones. The IP Phones are configured to enable VT Advantage to associate with them through Cisco CallManager Administration. In this configuration, the following minimum requirements apply to Cisco CallManager, the IP Phones, and the PCs: • Cisco CallManager Release 4.0(1) Service Release 2 or greater • Cisco IP Phone 7940G running firmware version 6.0(4) or greater • Cisco IP Phone 7960G running firmware version 6.0(4) or greater • Cisco IP Phone 7970G running firmware version 6.0(2) or greater • PC with 1-GHz or higher Pentium III or compatible (support for Streaming SIMD Extensions is also required)

Cisco IP Video Telephony SRND 9562740406 3-3 Chapter 3 Endpoints SCCP Endpoints

• Microsoft Windows 2000 Professional (SP3 or later) or Windows XP Professional (SP1 or later) • 256 MB RAM minimum • 40 MB disk space • Video-capable graphics card at 800x600x16-bit or greater • One free USB 1.1 or 2.0 connection • 10/100 Base-T Ethernet interface • 256 kbps minimum bandwidth connectivity • Cisco IP/VC 3511 or 3540 MCU Release 3.2.113 (required only for multiparty conferences) • Cisco IP/VC 3526 or 3540 H.320 Gateway Release 2.0 or greater (required only for ISDN off-net calls)

Tandberg SCCP Endpoints (T-1000 and T-550 Models)

The Tandberg T-1000 and T-550 video endpoints currently support the Cisco Skinny Client Control Protocol (SCCP). SCCP on the Tandberg endpoints is modeled after SCCP on the Cisco IP Phone 7940. Most features found on the IP Phone 7940 user interface are also supported on the Tandberg T-1000 and T-550, including two line appearances, softkeys, buttons for Directories, Messages, Settings, and Services, and so forth. The Tandberg endpoints also support the Option 150 field in DHCP to discover the IP address of the TFTP , and they download their configurations from the TFTP server. However, software upgrades of the Tandberg endpoints are not done via TFTP. Instead, the customer must manually upgrade each endpoint via FTP or via Tandberg’s TMS management application. The Tandberg endpoint registers with up to three Cisco CallManager servers and will fail-over to its secondary or tertiary servers if its primary server becomes unreachable. Tandberg endpoints also support all of the softkey functionality of Cisco IP Phone 7940, 7960, or 7970, including: • Mappable softkey templates • Two lines • Four speed-dial buttons • Messages button • Directories (placed calls, received calls, missed calls, and corporate directory) • Settings and Services buttons • XML services; however, some XML services (such as Extension Mobility and Berbee's InformaCast) are not supported yet Because the Tandberg endpoints use SCCP, dialing a video call from an endpoint is similar to dialing an audio call from a Cisco IP Phone. If users are familiar with Cisco IP Phones, they should also find the Tandberg endpoints very intuitive to use. The main difference in the user interface is that the Tandberg endpoints do not have a button keypad or a handset like those on a phone. Instead, the remote control is used to access features and to dial numbers on the Tandberg endpoints.

Note Tandberg endpoints do not support the Cisco Discovery Protocol (CDP) or IEEE 802.Q/p.

Cisco IP Video Telephony SRND 3-4 9562740406 Chapter 3 Endpoints H.323 Clients

Codecs Supported by Tandberg SCCP Endpoints Tandberg endpoints running SCCP support the following types of audio and video codecs: • H.263 – Bandwidth: up to 768 bps – Resolution: Common Intermediate Format (CIF) and Quarter Common Intermediate Format (QCIF) – Frame Rate: up to 30 frames per second (fps) • H.261 – Bandwidth: up to 768 kbps • G.711

H.323 Clients

Cisco CallManager Release 4.0 supports most H.323v2-compliant clients. H.323 clients can be configured in Cisco CallManager any of the following ways: • As an H.323 client device, in which case the endpoint must use a static IP address. This is the preferred method of configuration. • As an H.323 gateway device, in which case the endpoint must use a static IP address. This method of configuration should be used only if the endpoint offers a built-in MCU function, in which case the device will require the ability to make and receive multiple calls. H.323 clients are permitted to make or receive only a single call at a time, so configuring the endpoint as an H.323 gateway is a viable workaround. Note, however, that H.323 gateways do not have all the same features as H.323 clients do, such as the ability to set call-forwarding behavior, a display name, a profile, and some other miscellaneous settings. • Through an H.225 gatekeeper-controlled trunk, in which case the endpoint can use a Dynamic Host Configuration Protocol (DHCP) IP address. Multiple endpoints can be accessed from a single trunk. Use the following criteria to decide how to configure your H.323 clients in Cisco CallManager: • Is DHCP required on the endpoint or can a static IP address be used? • Does the endpoint have built-in Multipoint Control Unit (MCU) capability? • Do you want to be able to set device-specific features such as call forwarding, calling search spaces, voicemail profiles, and so forth? (See Table 3-1.)

Table 3-1 Supported Device Features

Call Shared Line Gatekeeper DHCP Device Forwarding Appearances Voicemail Profile Required Allowed H.323 client Yes Yes Yes No No H.323 gatewayNoNoNoNoNo H.225 trunkNoNoNoYesYes

Cisco IP Video Telephony SRND 9562740406 3-5 Chapter 3 Endpoints H.323 Clients

Cisco CallManager Administration allows you to set the following properties on an H.323 client device, which are not available on H.323 gateway and H.225 trunk devices: • Shared line appearances • Call forwarding (busy, no answer, and unconditional) • Up to two unique directory numbers (DNs) • Shared line appearances with other H.323 clients or IP Phones • Internal calling name ID • User-to-device association (to allow users to set their own preferences) • Call pickup group membership • No-answer ring duration • External phone number mask Because of these additional features, Cisco recommends that you always configure H.323 endpoints as H.323 clients in Cisco CallManager, unless one of the other criteria forces you to do otherwise. The only reason to configure an H.323 endpoint as an H.323 gateway device is to allow support for multiple calls to be sent to and from the device. This capability is available only on certain H.323 endpoint models that offer an integrated MCU function and are, therefore, capable of dialing out to more than one participant at a time and bridging them together. Cisco CallManager permits only a single active call on H.323 clients, so you must use an H.323 gateway instead if support for multiple calls is desired. Note, however, that you must still use a static IP address when configuring the endpoint as an H.323 gateway, and you loose all of the endpoint-specific features list previously.

H.225 Gatekeeper-Controlled Trunks An H.225 trunk to the gatekeeper is necessary for inbound calling to work, regardless of how you configure your endpoints in Cisco CallManager. This gatekeeper-controlled trunk is required because most H.323 endpoints on the market, as well as some gateways and MCUs, are incapable of routing calls directly to Cisco CallManager. Instead, they must be configured to register with a gatekeeper and, when an E.164 address is dialed, they query the gatekeeper to determine how they should route the call. The gatekeeper matches the dialed E.164 address to Cisco CallManager's H.225 trunk and respond to the endpoint with an Admission Confirm instructing the endpoint to route its call to Cisco CallManager. One exception to this rule is the Tandberg H.323 release E3.4, which allows you to configure the IP address of one Cisco CallManager directly into the Tandberg endpoint instead of using a gatekeeper. This option makes it easier to integrate the Tandberg endpoint because you do not need a gatekeeper in place, but it should be noted that this method eliminates any redundancy because the Tandberg endpoint can be configured to point to only a single Cisco CallManager IP address. If that Cisco CallManager server is unavailable, the endpoint will not be able to call any E.164 addresses. Therefore, regardless of which endpoint is configured in Cisco CallManager, an H.225 trunk must be in place to route inbound calls. Once the call is routed to the Cisco CallManager(s) by the gatekeeper, Cisco CallManager then performs the second step of determining who the device is.

Cisco IP Video Telephony SRND 3-6 9562740406 Chapter 3 Endpoints H.323 Clients

Addressing for H.323 Clients

When Cisco CallManager receives an H.225 setup message from a device, it searches its database to see if it knows what the device is. If the device is configured as either an H.323 client or an H.323 gateway, Cisco CallManager will recognize the source IP address and will apply the calling search space and other features applicable to that device. However, if the device’s source IP address is not found in the database, Cisco CallManager will apply the calling search space and other features applicable to the H.225 trunk on which the message was received. This latter case applies to endpoints that are configured with a DHCP IP address. Because they cannot be configured directly in Cisco CallManager as an H.323 client or an H.323 gateway, they must be treated as "anonymous devices" and given the calling permissions applied to the H.225 trunk. This treatment allows calls to work for endpoints configured to use DHCP but, as mentioned above, you lose the ability to set device-specific features and settings on the endpoints because they all receive the same treatment as configured on the H.225 trunk over which the calls came. One workaround for DHCP endpoints would be to configure them as H.323 clients and change the IP address in Cisco CallManager each time they lease a new IP address. While this is certainly a plausible workaround, it would obviously be an additional administrative burden.

IP Address Matching for H.323 Clients

A Cisco CallManager system typically consists of multiple servers operating together in a cluster. When you configure an H.225 trunk to register with the gatekeeper, you assign the H.225 trunk to a device pool. The device pool, in turn, defines which Cisco CallManager group the trunk will use. The Cisco CallManager group consists of one to three servers listed in priority order. Therefore, in a clustered environment, up to three Cisco CallManager servers may register with the gatekeeper for each H.225 trunk that is configured. This means that the gatekeeper will see all three Cisco CallManager servers registered to it and, by default, will randomly distribute calls across them. So when an H.323 device queries the gatekeeper for the route to a destination E.164 address, the gatekeeper might send the first call to Cisco CallManager 1, the second call to Cisco CallManager 2, the third call to Cisco CallManager 3, and so forth. This method provides redundancy and load-balancing for H.323 calls. However, there is a difference between the way Cisco CallManager handles calls from H.323 clients and the way it handles calls from H.323 gateways. When an H.323 gateway device is configured in Cisco CallManager, the H.225 handler (known as the H.225 daemon) associated with that logical device registers with every Cisco CallManager server in the cluster. The gateway device can therefore send its H.225 setup messages to any of the servers, and it will be recognized. With H.323 clients, however, the H.225 handler registers only with the primary Cisco CallManager server (that is, the server listed first in that device’s Cisco CallManager group). If the endpoint sends its H.225 setup messages to that primary server, it will be recognized. If the H.323 endpoint sends its H.225 setup messages to any of the other servers in the cluster, they will recognize it but will instead treat the call as if it came it from an anonymous device on the H.225 trunk. To work around this issue, the gatekeeper must be configured to always route calls to the primary Cisco CallManager. Only if that Cisco CallManager server goes down (and therefore becomes unregistered from the gatekeeper) should the calls be routed to the secondary Cisco CallManager, and so forth. To achieve this redundancy, the Cisco IOS Gatekeeper allows you to configure preferences for each gateway by using the gw-priority argument at the end of the zone prefix command. The preferences range in value from 0 to 10, with 10 being the highest priority and 0 meaning “never route to this gateway.” The default gw-priority is 10 unless otherwise configured.

Cisco IP Video Telephony SRND 9562740406 3-7 Chapter 3 Endpoints H.323 Clients

For example, assume a gatekeeper has two zones defined, one for the Cisco CallManager trunks and a second for all the endpoints. Cisco CallManager controls directory numbers in the range of 0 to 9999999999, and Example 3-1 show the configuration for the 10 zone prefixes applied to the Cisco CallManager zone.

Example 3-1 Defining Zone Prefixes

zone local callmanagers domain.com zone local endpoints domain.com zone prefix callmanager 0* zone prefix callmanager 1* zone prefix callmanager 2* zone prefix callmanager 3* zone prefix callmanager 4* zone prefix callmanager 5* zone prefix callmanager 6* zone prefix callmanager 7* zone prefix callmanager 8* zone prefix callmanager 9*

With the configuration in Example 3-1, any time an endpoint dials an E.164 address starting with the digits 0 through 9 followed by any number of other digits, the gatekeeper will match it to one of the 10 configured zone prefixes and randomly route the call to one of the Cisco CallManager servers registered in that zone. In this example, we have two Cisco CallManager servers registered in that zone (that is, two servers in the H.225 trunk’s Cisco CallManager group), and they are named callmanager_1 and callmanager_2. The callmanager_2 is listed first in the Cisco CallManager group and is therefore the primary server, while callmanager_1 is listed second and is the backup server. To configure the gatekeeper to prioritize callmanager_2 over callmanager_1, we use the gw-priority keyword with the zone prefix command, as shown in Example 3-2.

Example 3-2 Setting Gateway Priorities

zone local callmanagers domain.com zone local endpoints domain.com zone prefix callmanager 0* gw-priority 10 callmanager_2 gw-priority 9 callmanager_1 zone prefix callmanager 1* gw-priority 10 callmanager_2 gw-priority 9 callmanager_1 zone prefix callmanager 2* gw-priority 10 callmanager_2 gw-priority 9 callmanager_1 zone prefix callmanager 3* gw-priority 10 callmanager_2 gw-priority 9 callmanager_1 zone prefix callmanager 4* gw-priority 10 callmanager_2 gw-priority 9 callmanager_1 zone prefix callmanager 5* gw-priority 10 callmanager_2 gw-priority 9 callmanager_1 zone prefix callmanager 6* gw-priority 10 callmanager_2 gw-priority 9 callmanager_1 zone prefix callmanager 7* gw-priority 10 callmanager_2 gw-priority 9 callmanager_1 zone prefix callmanager 8* gw-priority 10 callmanager_2 gw-priority 9 callmanager_1 zone prefix callmanager 9* gw-priority 10 callmanager_2 gw-priority 9 callmanager_1

With the configuration in Example 3-2, the gatekeeper will always route calls matching the zone prefixes to callmanager_2 unless callmanager_2 becomes unregistered from the gatekeeper, at which point it will start routing calls to callmanager_1 instead. Note that there is still a potential for calls to be routed incorrectly under certain circumstances. The primary Cisco CallManager server has to be down (that is, the Cisco CallManager Service must be stopped or the server must be powered off completely) in order for the H.225 handler representing the H.323 client to fail-over to the backup server. If the Cisco CallManager Service is still running but Cisco CallManager has lost connectivity to the gatekeeper for some other reason, the gatekeeper will start routing all calls to the backup server but the H.225 handler will still be registered with the primary server.

Cisco IP Video Telephony SRND 3-8 9562740406

CHAPTER 4

Call Admission Control

Call admission control protects the network from over-subscription of available bandwidth by monitoring the number of active calls and rejecting calls that exceed the preconfigured limits. For IP Videoconferencing networks, call admission control has traditionally been implemented with gatekeeper zone bandwidth commands. For IP Telephony networks, there are two methods of call admission control: • Cisco CallManager locations — for calls between sites within the same cluster • Gatekeeper zone bandwidth commands — for calls between clusters Cisco CallManager Release 4.0 extends the locations-based call admission control feature to support video bandwidth controls, as described in the chapter on Video Enhancements in Cisco CallManager 4.0, page 1-2. For video calls between two clusters, Cisco CallManager Release 4.0 also supports gatekeeper-based call admission control. In addition, Cisco CallManager regions play a role in call admission control by defining how much bandwidth is allowed on a per-call basis between devices in the same region or between devices in different regions. If the region configuration does not permit video, or if it permits only a lower speed of video than what is requested by the endpoint for a given call, Cisco CallManager will either reject the call, negotiate the speed of the call to match the region configuration, or reject the video channel and retry the video call as an audio-only call instead. Before examining call admission control more closely, this chapter discusses bandwidth requirements and presents the recommended values to use in your call admission control configurations.

Bandwidth Requirements

This section describes the following main factors that influence bandwidth requirements for video calls: • Media Channels, page 4-1 • Bandwidth Used Per Call, page 4-2

Media Channels

A typical video call consists of two media channels, one for the video stream and one for the audio stream. These channels are referred to as logical channels in the H.323 protocol, and each logical channel is negotiated separately. For the call to succeed, Cisco CallManager checks that audio is successfully signalled.

Cisco IP Video Telephony SRND 9562740406 4-1 Chapter 4 Call Admission Control Bandwidth Requirements

The video channel can vary in speed, based upon the audio codec negotiated and the requested rate of the call. The actual speed of the video channel depends on the audio codec chosen for the audio channel, as shown by the examples in Table 4-1.

Table 4-1 Codec Selection and Channel Speed based on Requested Call Speed

Call Speed Audio Codec and Rate Video Codec and Rate 128 kbps G.711 at 64 kbps H.261 or H.263 at 64 kbps 128 kbps G.729 at 8 kbps H.261 or H.263 at 120 kbps 128 kbps G.728 at 16 kbps H.261 or H.263 at 112 kbps 384 kbps G.729 at 8 kbps H.261 or H.263 at 376 kbps 384 kbps G.711 at 64 kbps H.261 or H.263 at 320 kbps 768 kbps G.729 at 8 kbps H.261 or H.263 at 760 kbps 768 kbps G.711 at 64 kbps H.261 or H.263 at 704 kbps 1.5 Mbps (1.472 Mbps) G.729 at 8 kbps H.261 or H.263 at 1.464 Mbps 1.5 Mbps (1.472 Mbps) G.711 at 64 kbps H.261 or H.263 at 1.408 Mbps 7 Mbps G.729 at 8 kbps Wideband at 7 Mbps 7 Mbps G.711 at 64 kbps Wideband at 7 Mbps

Bandwidth Used Per Call

The actual bandwidth required is more than just the speed of the call. The speed of the call is just the payload, but the complete packet includes some amount of overhead for header information that encapsulates the payload into RTP segments, UDP frames, IP packets, and finally a Layer-2 transport medium (such as Ethernet frames, ATM cells, or Frame Relay frames). For details about voice packets and bandwidth consumption, refer to the Cisco IP Telephony Solution Reference Network Design (SRND), available at http://cisco.com/go/srnd 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 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 4-2.)

Cisco IP Video Telephony SRND 4-2 9562740406 Chapter 4 Call Admission Control Bandwidth Requirements

Table 4-2 Fields to Configure for Call Admission Control

Cisco CallManager Cisco CallManager Low Latency Queueing Call Type Region Location H.323 Gatekeeper (LLQ) Class Audio-only calls Audio Codec only Audio bit-rate + 2x the bit-rate1 Bit-rate + Layer-3 to configuration Layer-3 overhead Layer-7 overhead Video calls Audio Codec + Video Video Call Bandwidth 2x the bit-rate Bit-rate + 20% configuration Call Bandwidth overhead Example G.711 call G.711 80 kbps 128 kbps1 80 kbps Example 384-kbps G.711 audio codec and 384 kbps 768 kbps 460 kbps video call 384-kbps video bandwidth

1. This behavior changed in Cisco CallManager Release 3.2(2)c and IOS Release 12.2(2)XA. Prior to that, Cisco CallManager asked for bit-rate plus Layer-3 overhead, and Cisco IOS Gateways asked for 64 kbps no matter what type of call it was.

Incorporating this 20% margin, Table 4-3 shows the recommended bandwidth values to use for some of the more popular video call speeds.

Table 4-3 Recommended Bandwidth for Various 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 7 Mbps 8.4 Mbps

Note that the values in Table 4-3 represent the maximum burst speed of the call, with some additional amount for a cushion. The average speed of the call is 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. They are also important factors to consider when configuring Quality of Service, which is discussed in the chapter on Quality of Service, page 5-1.

Cisco IP Video Telephony SRND 9562740406 4-3 Chapter 4 Call Admission Control Call Admission Control Within a Cluster

Call Admission Control Within a Cluster

Cisco CallManager uses regions and locations to implement call admission control. Regions define the maximum bandwidth allowed per call, while locations define the maximum bandwidth allowed for all calls to and from a site.

Regions

When configuring a region, you set two fields in Cisco CallManager Administration: the Audio Codec and the Video Bandwidth. Note that the audio setting specifies a codec type while the video setting specifies the amount of bandwidth you want to allow. However, even though the notation is different, the Audio Codec and Video Bandwidth fields actually perform similar functions. The Audio Codec field defines the maximum bit-rate allowed for audio-only calls as well as for the audio channel in video calls. For instance, if you set the Audio Codec for a region to G.711, Cisco CallManager allocates 64 kbps as the maximum bandwidth allowed for the audio channel for that region. In this case, Cisco CallManager will permit calls using either G.711, G.728, or G.729. However, if you set the Audio Codec to G.729, Cisco CallManager allocates only 8 kbps as the maximum amount of bandwidth allowed for the audio channel, and it will permit calls using only G.729 because G.728, G.711, and G.722 all take more than 8 kbps.

Note The Audio Codec setting also applies to the audio channel of video calls.

The Video Bandwidth field defines the maximum bit-rate allowed for the video channel of the call. However, for historical continuity with the practices used in traditional videoconferencing products, the value used in this field also includes the bandwidth of the audio channel. For instance, if you want to allow calls at 384 kbps using G.711 audio, you would set the Video Bandwidth field to 384 kbps and not 320 kbps. In summary, the Audio Codec field defines the maximum bit-rate used for audio-only calls and for the audio channel of video calls, while the Video Bandwidth field defines the maximum bit-rate allowed for video calls and should include the audio portion of the call. Choosing the correct audio codec bandwidth limit is very important because each device supports only certain audio codecs, as shown in Table 4-4. (Please check individual product documentation for the most recent list of codecs supported by a particular endpoint.)

Table 4-4 Types of Audio Codecs Supported by Endpoint Devices

Cisco 7900 SCCP Tandberg Typical H.323 IP/VC 3500 Series IP/VC 3500 Series Codec Type Series IP Phones Endpoints Endpoints Gateways MCUs G.729 Yes No No No Yes (with transcoder) G.728 No No Yes Yes (with transcoder) Yes (with transcoder) G.711 Yes Yes Yes Yes Yes G.722 No No Yes Yes (with transcoder) Yes (with transcoder) Cisco Wideband YesNoNoNoNo Audio

Cisco IP Video Telephony SRND 4-4 9562740406 Chapter 4 Call Admission Control Call Admission Control Within a Cluster

As Table 4-4 illustrates, if you set the region to G.729, the only devices that can support this type of codec are Cisco VT Advantage clients (since the Cisco IP Phone handles the audio portion of the call) and Cisco IP/VC 3500 Series MCUs that have the optional audio transcoder module installed. In this case, calls between a Cisco VT Advantage endpoint and a Tandberg endpoint would fail and would require you to set the region to use G.711. However, a region set for G.711 would also use G.711 for audio calls between two IP phones, which you might not want due to the increased consumption of bandwidth over the WAN. If you want to use G.729 for audio-only calls to conserve bandwidth and G.711 for video calls, then you should configure one region to use G.711 for video endpoints that do not support G.729 and a separate region (or regions) to use G.729 for IP phones. (See Figure 4-1.) This method increases the number of regions needed but provides the desired codec and bandwidth allocations.

Figure 4-1 Using G.711 for Video Calls and G.729 for Audio-Only Calls

G.711 G.711-only Region G.711

IP IP G.729 IP IP IP IP Region A Region B San Jose Dallas 119465

Also note that there is currently no Cisco IOS or non-IOS transcoding resource capable of handling video. Therefore, if you configure the regions improperly and Cisco CallManager needs to invoke a transcoding resource, the video channel will not complete and the call will be connected as audio-only.

Tip It is possible to configure a pair of regions to prohibit video. If two video-capable devices in that region pair try to call each other, they will connect as audio-only unless Retry Video Call as Audio is not checked, in which case AAR rerouting logic will take over.

Table 4-5 lists some example configurations and their outcomes.

Table 4-5 Scenarios for Various Region Settings

Setting of Region Setting Retry Video as Audio Result Region allows video Enabled Video calls allowed Region allows video Disabled Video calls allowed Region does not allow video Enabled Video calls will proceed as audio Region does not allow video Disabled If AAR is not configured, video calls fail (with busy tone and "Bandwidth Unavailable" message displayed)

Cisco IP Video Telephony SRND 9562740406 4-5 Chapter 4 Call Admission Control Call Admission Control Within a Cluster

The Video Bandwidth field accepts values in the range of 1 to 8128 kbps.However, to allow for compatibility with H.323 and H.320 videoconferencing devices, Cisco recommends that you always enter values for this field in increments of either 56 or 64 kbps. Therefore, valid values for this field include 112 kbps, 128 kbps, 224 kbps, 256 kbps, 336 kbps, 384 kbps, and so forth. When the call speed requested by the endpoint exceeds the bandwidth value configured for the region, Cisco CallManager automatically negotiates the call down to match the value allowed in the region setting. For instance, assume that an H.323 endpoint calls another H.323 endpoint at 768 kbps, but the region is set to allow a maximum of 384 kbps. The incoming H.225 setup request from the calling party would indicate that the call speed is 768 kbps, but Cisco CallManager would change that value to 384 kbps in the outgoing H.225 setup message to the called party. Thus, the called endpoint would think that it was a 384-kbps call to begin with, and the call would be negotiated at that rate. The calling endpoint would show the requested bandwidth as 768 kbps, but the negotiated bandwidth would be 384 kbps. However, if you set the Video Bandwidth to "None" in the region, Cisco CallManager will either terminate the call (and send an H.225 Release Complete message back to the calling party) or will allow the call to pass as an audio-only call instead, depending on whether or not the called device has the Retry Video Call as Audio option enabled. (See Retry Video Call as Audio, page 4-10.)

Locations

When configuring locations, you also set two fields in Cisco CallManager Administration: the Audio Bandwidth and the Video Bandwidth. Unlike regions however, the Audio Bandwidth for locations applies only to audio-only calls, while the Video Bandwidth applies to both the audio and video channels of video calls. The audio and video bandwidth are kept separate because, if both types of calls shared a single bucket of bandwidth, then it is very likely that audio calls would take all the available bandwidth and leave no room for any video calls, or vice versa. Also, separate bandwidth pools for audio and video correspond to the way queues are configured in the switches and routers in the network, which typically have a for voice traffic and a separate priority queue or a Class-Based Weighted Fair Queue for video traffic. (See Quality of Service, page 5-1, for more details.) Both the Audio Bandwidth and the Video Bandwidth fields offer three options: None, Unlimited, or a field that accepts numeric values. However, the values entered in these fields use two different calculation models. For the Audio Bandwidth field, the values entered should include the Layers 3 to 7 overhead required for the call. For instance, if you want to permit a single G.729 call to or from a location, you would enter the value of 24 kbps. For a G.711 call, you would enter the value of 80 kbps. The Video Bandwidth field, by contrast, should be entered without the overhead included. For instance, for a 128-kbps call you would enter 128 kbps, and for a 384-kbps call you would enter 384 kbps. As with the values used in the Video Bandwidth field for regions, Cisco recommends that you always use increments of 56 kbps or 64 kbps for the Video Bandwidth field for locations as well. For example, assume that a company has a three-site network. The San Francisco location has a 1.544-Mbps T1 circuit connecting it to the San Jose main campus. The system administrator wants to allow four G.729 voice calls and one 384-kbps (or two 128-kbps) video calls to/from that location. The Dallas location has two 1.544-Mbps T1 circuits connecting it to the San Jose main campus, and the

Cisco IP Video Telephony SRND 4-6 9562740406 Chapter 4 Call Admission Control Call Admission Control Between Clusters

administrator wants to allow eight G.711 voice calls and two 384-kbps video calls to/from that location. For this example, the administrator would set the San Francisco and Dallas locations to the following values:

Number of Audio Calls Audio Bandwidth Field Number of Video Calls Video Bandwidth Location Desired Value Desired Field Value San Francisco 4 using G.729 96 kbps (4 ∗ 24 kbps) 1 at 384 kbps 384 kbps Dallas 8 using G.711 640 kbps (8 ∗ 80 kbps) 2 at 384 kbps 768 kbps

When the call speed requested by the endpoint exceeds the value configured for the location, Cisco CallManager will not automatically negotiate the call speed (as it does for regions) to match the value allowed in the location setting. Instead, the call will be rejected or will be retried as an audio-only call (if the Retry Video as Audio setting is enabled on the called device).

Call Admission Control Between Clusters

Calls between Cisco CallManager clusters use intercluster trunks (ICTs). Cisco CallManager Release 4.0 supports the following types of trunks: • Non-Gatekeeper Controlled Intercluster Trunks, page 4-7 • Gatekeeper-Controlled Intercluster Trunks, page 4-9 • H.225 Gatekeeper-Controlled Trunks, page 4-9 • SIP Trunks The H.225 gatekeeper-controlled trunk is designed for use with any H.323 device other than another Cisco CallManager cluster, although nothing prohibits the use of this trunk type with other Cisco CallManager clusters as well if it is configured properly. Gatekeeper-controlled intercluster trunks and non-gatekeeper controlled intercluster trunks are specifically designed for use with other Cisco CallManager clusters and should not be used for any other purpose. SIP trunks are designed for use with any SIP device, including other Cisco CallManager clusters, either directly or via a SIP Proxy Server. Because Cisco CallManager Release 4.0 does not support video over the SIP protocol, this document does not discuss SIP trunks.

Non-Gatekeeper Controlled Intercluster Trunks

This trunk type is specifically designed for communications between Cisco CallManager clusters and should not be used with other types of H.323 devices. The name implies that there is no gatekeeper between the clusters to regulate the bandwidth used between them. Thus, the only mechanism to provide call admission control for this type of trunk is Cisco CallManager locations. To provide call admission control for this type of trunk, you configure a Cisco CallManager location to represent the remote cluster and assign maximum audio and video bandwidth limits for it. You must also enter a corresponding configuration in the Cisco CallManager cluster at the other end of the trunk. Cisco CallManager then uses this configuration to regulate the bandwidth used by calls to or from the remote cluster. Note that the location bandwidth limits should be consistent on both sides of the trunk, as illustrated in Figure 4-2 and the following table.

Cisco IP Video Telephony SRND 9562740406 4-7 Chapter 4 Call Admission Control Call Admission Control Between Clusters

Location Parameter San Jose Configuration Dallas Configuration Location name Dallas San Jose Audio bandwidth 80 kbps 80 kbps Video bandwidth 384 kbps 384 kbps

Figure 4-2 Intercluster Trunk (Not Gatekeeper Controlled)

M M

M M ICT M M

M M M M

San Jose Dallas 119456

If the bandwidth limits are not consistent between the two clusters, one side will permit the call while the other side will reject it. Although this does not necessarily mean that the call will fail (there could be an alternate path), it could lead to confusion and should be avoided. Note that the Audio Bandwidth and the Video Bandwidth are independent of each other. See Locations, page 4-6, for more details. Likewise, the region configurations for the two clusters should also be consistent, as shown in the following table.

Region Parameter San Jose Configuration Dallas Configuration Region name Dallas San Jose Audio codec G.711 G.711 Video bandwidth 384 kbps 384 kbps

If the audio codec settings are not consistent between clusters, the call could fail or a transcoding resource could be invoked to convert the audio codec to the preferred type on the other end, thus resulting in an audio-only call. If the video bandwidth settings are not consistent, the Cisco CallManagers will negotiate the call speed to match the lower side. Note that the chosen audio codec also applies to the video call and that the video call bandwidth includes the audio portion of the call. See Bandwidth Requirements, page 4-1, for more details. Finally, if the region video bandwidth setting exceeds the maximum video bandwidth of the location, Cisco CallManager will either reject the call or allow the call to pass as an audio-only call, depending on whether the Retry Video Call as Audio setting is enabled or not. (See Retry Video Call as Audio, page 4-10.)

Cisco IP Video Telephony SRND 4-8 9562740406 Chapter 4 Call Admission Control Gatekeeper Bandwidth Values

Gatekeeper-Controlled Intercluster Trunks

This trunk type is specifically designed for communications between Cisco CallManager clusters and should not be used with other H.323 devices. The name implies that there is a gatekeeper between the clusters to regulate the bandwidth used between them. To provide call admission control, you configure an H.323 zone in the gatekeeper for each of the Cisco CallManager clusters and assign zone bandwidth limits to each zone. Whenever Cisco CallManager attempts to route a call to the remote cluster, it first sends an Admission Request (ARQ) to the gatekeeper to ask permission to do so. The ARQ includes the source and destination E.164 addresses (that is, the calling party number and the called party number, the source IP address of the calling cluster, and the amount of bandwidth being requested for the call, among other things). If the bandwidth requested does not exceed the zone bandwidth limits configured in the gatekeeper, the gatekeeper responds with an Admission Confirm (ACF). The ACF essentially echoes back the information contained in the ARQ, confirming that the calling device is permitted to make the call at the requested rate, and it also contains the destination IP address(es) of the remote cluster. Cisco CallManager then initiates an H.225 setup message to the destination cluster at the requested rate.

H.225 Gatekeeper-Controlled Trunks

This trunk type is designed for use with any H.323-compliant device, via a gatekeeper, and it can also be used in scenarios where you have a mixture of remote Cisco CallManager clusters and other H.323 devices that must be reached but you don't want to have to configure two different types of trunks. During the H.225 setup phase, Cisco CallManager passes some proprietary messages via the User-User Information to indicate that it is a Cisco CallManager device (and what version of Cisco CallManager it is). These messages enable Cisco CallManager to detect whether or not the remote device is another Cisco CallManager cluster. As the name implies, there is a gatekeeper controlling the amount of bandwidth allowed between devices, and Cisco CallManager will send an Admission Request (ARQ) to the gatekeeper before placing the call, as described in the preceding section.

Gatekeeper Bandwidth Values

This section pertains to all types of gatekeeper-controlled trunks. The bandwidth values used when programming the gatekeeper are different than those used when configuring Cisco CallManager locations. The H.323 specification states that the bandwidth value requested in the ARQ should be two times (2x) the bit-rate of the call. For instance, a G.711 audio-only call should be requested as 128 kbps and a 384-kbps video call should be requested as 768 kbps. This method differs from that used in Cisco CallManager locations and regions, described previously, where the Audio Bandwidth value is entered as the bit-rate plus Layer-3 overhead and the Video Bandwidth value is entered as the bit-rate (for example, 80 kbps for a G.711 audio-only call and 384 kbps for a 384-kbps video call). For more details, see Gatekeepers, page 8-1.

Cisco IP Video Telephony SRND 9562740406 4-9 Chapter 4 Call Admission Control Bandwidth Requests (BRQ) Enabled/Disabled

Bandwidth Requests (BRQ) Enabled/Disabled

This section pertains to all types of gatekeeper-controlled trunks. If an H.323 call is connected at a specified speed and a supplementary service (such as transfer, conference, call park or pickup) is invoked, the device to which the call is transferred might operate at a different speed than the original device. (For instance, an established audio-only call could be transferred to a video-capable device, or vice versa.) In such cases, the gatekeeper will continue to think the call is operating at its original speed unless Cisco CallManager sends the gatekeeper a Bandwidth Request (BRQ) to update the gatekeeper with the new rate of the call. By default, Cisco CallManager does not send BRQs. You can enable this feature under the Cisco CallManager Service Parameters, and the setting should be consistent on both sides of the trunk. If BRQs are not enabled, the supplementary service will be allowed but the gatekeeper will be unaware of the change in speed, which could lead to oversubscription of the bandwidth allotted to audio/video on the network and, hence, a loss of call admission control. If BRQs are enabled, there is a possibility that the gatekeeper will reject the BRQ because the new call speed exceeds the zone bandwidth limits, thus causing Cisco CallManager to reject the request for the supplementary service. For instance, if an audio-only call is transferred to a video-capable device but the gatekeeper rejects the BRQ, Cisco CallManager will play busy tone to the user initiating the transfer feature and will display a Bandwidth Unavailable message on the phone.

Retry Video Call as Audio

This section pertains to all H.323 calls over all types of gatekeeper-controlled and non-gatekeeper controlled trunks. As described previously (see Retry Video Call as Audio, page 1-4), you can configure the Retry Video Call as Audio feature on any video-capable devices, including: Cisco IP Phones 7940, 7960, and 7970 with Cisco VT Advantage; Tandberg SCCP video endpoints; H.323 clients; H.323 gateways; and all H.323 trunk types (both gatekeeper-controlled and non-gatekeeper controlled H.225 and intercluster trunks). The setting appears as a check-box in Cisco CallManager Administration, and by default it is enabled on all device types. This feature applies to the following scenarios only: • The region is configured not to allow video • The location is configured not to allow video, or the requested video speed exceeds the available video bandwidth for that location • The requested video speed exceeds the gatekeeper’s zone bandwidth limits When this option is checked (enabled), Cisco CallManager reacts to any of the above scenarios by retrying the call as an audio-only call. When the option is disabled (not checked), Cisco CallManager reacts to any of the above scenarios either by failing the call (that is, playing busy tone to the caller and displaying the Bandwidth Unavailable message on the initiating phone) or by attempting to reroute the call over an alternate path if automated alternate routing (AAR) is configured.

Note The called device is the one that determines the result. In other words, when one device calls another and any of the one of the above conditions applies, Cisco CallManager will look at the destination device to see whether or not the Retry Video Call as Audio option is enabled.

Cisco IP Video Telephony SRND 4-10 9562740406 Chapter 4 Call Admission Control Retry Video Call as Audio

Figure 4-3 illustrates the steps of a call between two clusters using non-gatekeeper controlled intercluster trunks.

Figure 4-3 Call Flow Between Two Clusters Using Non-Gatekeeper Controlled Intercluster Trunks

Cluster 1 Cluster 2 ICT Trunk 1 H.323 ICT Trunk 2 M M

Region X IP IP Calling phone Receiving phone

Region A Region B 119463

Phone A in region A of cluster1. ICT1 has ICT1 in region X of cluster1. “retry video” No Call fails due to Phone B in region B of cluster2. option enabled? insufficient bandwidth ICT2 in region X of cluster2.

Ye s Phone A calls phone B

Negotiated rate No exceeds the location bandwidth Inter-region of region B configured rate between phone A Ye s in cluster2? and ICT1 exceeds the location bandwidth of region A Ye s configured in cluster1? Phone B No has “retry video” Ye s option enabled?

Negotiated rate Ye s No exceeds the location bandwidth of region B configured in cluster2? Phone B has “retry video” No No option enabled?

Video at negotiated rate Ye s Audio-only 119464 call

Cisco IP Video Telephony SRND 9562740406 4-11 Chapter 4 Call Admission Control Wait for Far-End to Send TCS

Wait for Far-End to Send TCS

This section pertains to all H.323 calls over all types of gatekeeper-controlled and non-gatekeeper controlled trunks. As described previously (see Wait for Far-End to Send TCS, page 1-5), you can configure the Wait for Far-End to Send TCS feature on any H.323 devices, including H.323 clients, H.323 gateways, and H.225 gatekeeper-controlled trunks. The setting appears as a check-box in Cisco CallManager Administration, and by default it is enabled (checked) on all of these device types. For intercluster trunks (both gatekeeper-controlled and non-gatekeeper controlled), this setting is disabled (not checked) by default and cannot be enabled. This feature pertains to the H.245 capabilities-exchange phase of H.323 calls. When this feature is enabled, Cisco CallManager waits for the remote H.323 device to send its Terminal Capabilities Set (TCS) to Cisco CallManager before Cisco CallManager will send its TCS to the H.323 device. When the option is disabled, Cisco CallManager does not wait but sends its TCS to the remote H.323 device immediately. In many scenarios, Cisco CallManager performs the role of a software switch connecting two endpoint devices (such as two H.323 clients that are trying to call each other). In such cases, it is best if Cisco CallManager waits until both devices have sent their TCS messages so that it knows the capabilities of each device and can therefore make the most intelligent decision about what TCS to send back to each party (depending on region and location configurations, among other things). In these cases, the Wait for Far-End to Send TCS feature should be enabled. However, some other H.323 devices (such as an H.320 gateway, which connects an H.323 device to an H.320 device) also perform the function of connecting two or more parties together. The gateway also prefers to wait until both ends send their TCS messages, so that it can make the most intelligent choice about how to set up the call. A stalemate could result if Cisco CallManager and the gateway both wait for the other side to send their TCSs. To avoid this stalemate situation, disable (uncheck) the Wait for Far-End to Send TCS feature. For instance, consider the following call scenarios illustrated in Figure 4-4: • Scenario 1 — VT Advantage calls an H.320 endpoint • Scenario 2 — An H.323 client calls an H.320 endpoint In both of these scenarios, Wait for Far-End to Send TCS feature can be left at its default setting of enabled (checked)

Cisco IP Video Telephony SRND 4-12 9562740406 Chapter 4 Call Admission Control Wait for Far-End to Send TCS

Figure 4-4 Scenarios with the Wait for Far-End to Send TCS Feature Enabled (Checked)

Cisco CallManager Cluster H.320 M gateways H.323 ISDN M M network H.320 M M endpoint SCCP H.323

IP Cisco VT H.323 Advantage endpoint 119457

In Scenario 1 from Figure 4-4, Cisco CallManager already knows the capabilities of the VT Advantage client because SCCP devices provide Cisco CallManager with their media capabilities during registration. But Cisco CallManager does not know the capabilities of the H.320 gateway until the gateway sends its TCS to Cisco CallManager during the H.245 phase of the call. Likewise, the H.320 gateway does not know what TCS to send to Cisco CallManager until the H.320 endpoint sends its TCS to the gateway. In this case it is better to leave the Wait for Far-End to Send TCS feature enabled because the H.320 endpoint will send its TCS to the gateway, the gateway will send its TCS to Cisco CallManager, and Cisco CallManager will then have the TCS from both endpoints with which to make a decision. Figure 4-5 shows the following call scenarios, in which the call will fail unless the Wait for Far-End to Send TCS feature is disabled: • Scenario 1 — VT Advantage calls another VT Advantage in a remote cluster via the ISDN network • Scenario 2 — An H.323 client calls another H.323 client in the remote cluster via the ISDN network

Figure 4-5 Scenarios with the Wait for Far-End to Send TCS Feature Disabled (Unchecked)

Cisco CallManager Cisco CallManager H.320 H.320 M gateways gateways M H.323 ISDN H.323 M M network M M

M M M M SCCP SCCP H.323 H.323

IP IP Cisco VT H.323 Cisco VT H.323

Advantage endpoint Advantage endpoint 119458

In both scenarios from Figure 4-5, there will be a stalemate because both Cisco CallManagers will wait to receive the TCSs from the gateways, and the gateways will both wait to receive the TCS from the ISDN side as well. The call will time-out after a few seconds and fail. From the perspective of the users,

Cisco IP Video Telephony SRND 9562740406 4-13 Chapter 4 Call Admission Control Wait for Far-End to Send TCS

the caller will hear ringback tone indicating that the call is progressing and the called party will hear a ring indicating an incoming call. When the called party attempts the answer the call, the H.245 phase will fail due to the stalemate, and the call will then fail by hanging up on both parties. To work around this issue in scenarios such as these, Cisco recommends that you disable (uncheck) the Wait for Far-End to Send TCS option on the device representing the H.320 gateway in Cisco CallManager. This device could be an H.225 gatekeeper-controlled trunk or an H.323 gateway device, depending on how you have configured Cisco Callmanager to reach the H.320 gateway. However, if the Wait for Far-End to Send TCS option is disabled, there is a possibility that the initial capabilities exchanged will not work for the remote device. For instance, the Cisco CallManager region might be set to 768-kbps video but the H.320 device might only support 384 kbps, or the selected audio codec might not work for the remote party. In such cases, the initially negotiated logical channels might have to be torn down and reopened at the correct speed and codec. Many legacy H.323 and H.320 devices do not handle this situation well and will disconnect the call when Cisco CallManager sends a CloseLogicalChannel message to renegotiate the channel to a different value. Thus, you must be careful where and when you enable the Wait for Far-End to Send TCS option.

Cisco IP Video Telephony SRND 4-14 9562740406

CHAPTER 5

Quality of Service

Quality of Service (QoS) is just as critical for video telephony as it is for audio telephony. There are numerous excellent sources of information on QoS, so this document does not attempt to cover all aspects of the topic but, rather, focuses on those areas that pertain to IP Video Telephony. Here are some references for further reading: • Cisco IOS 12.0 Quality of Service (available through Cisco Press, ISBN: 1578701619) • Cisco Catalyst QoS (available through Cisco Press, ISBN: 1587051206) • Cisco AVVID Network Infrastructure Enterprise Quality of Service SRND (available at http://cisco.com/go/srnd) QoS is an end-to-end proposition. It is not limited to only one place in the network but occurs at each and every point as a packet traverses from the source, through the network, to the destination. Keeping this end-to-end approach in mind, consider the following questions when deploying QoS for IP Video Telephony: • At which point will the packets first be classified? Will they be classified by the originating device or by the first network device that the packets traverse? • Which classes should be used for audio and video packets? Are they the same or different for voice and video calls? • Which queues will hold the voice and video packets as they traverse the network? Are video packets placed into the same queue(s) as voice packets? • Are there other QoS measures already in place for audio, such as Compress RTP (cRTP), Link Fragmentation and Interleaving (LFI), traffic shaping, and Weighted Random Early Discard (WRED)? Should you leave those other features in place now that you have video traffic in addition to voice traffic, or should you turn them off? 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 latency, jitter, and . However, with new applications such as voice and video, which are sensitive to packet loss and delay, buffer management and not bandwidth is the key QoS issue. Everybody agrees that QoS is required in the WAN due to the restriction of bandwidth, however few are aware of the requirement within a campus environment. Endpoints on a network, especially data devices, are inherently bursty. With the advent of 100 Mbps or even 1000 Mbps to the desktop, bursts of data are increasingly shorter in time but contain the same quantity of packets. Imagine the effect of increasing the speed limit on an already busy toll road by a factor of ten without adding capacity at the toll stations. All the vehicles would arrive at a faster rate, causing congestion at the toll station. This oversubscription, coupled with individual traffic volumes and the cumulative effects of multiple independent traffic sources, can fill the egress interface buffers instantaneously, thus causing additional packets to drop when they attempt to enter the egress buffers.

Cisco IP Video Telephony SRND 9562740406 5-1 Chapter 5 Quality of Service Traffic Classification and Trust

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 (both peer-to-peer and server-based), remote networked storage, network-based backup software, and 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) that increased network congestion. If no buffer management policy is in place, loss, delay, and jitter performance of the LAN can be affected for all traffic. 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 and video, this packet loss and delay results in severe voice and video quality degradation. Cisco’s approach to QoS for IP Video Telephony consists of the following main functions: • Traffic Classification and Trust, page 5-2 • Scheduling or Queuing, page 5-4 • Bandwidth Provisioning, page 5-5

Traffic Classification and Trust

The first and probably most challenging QoS function is the classification of the packets. This classification should occur as close to the point of origin as possible. Once the packets are classified, the rest of the network will use this classification to provide the required level of service for the application. In an ideal network, all endpoints would mark the packets appropriately and the network would be able to trust the endpoint classification, hence the issue of trust. Generally, networks do not trust endpoints that are not under their direct control. These untrusted endpoints include most personal (PCs) because it is relatively easy to modify their QoS markings with the latest operating systems. For systems that are more static and/or cannot be easily modified, there is an option to trust the packet classifications as they enter the network. This option can be applied to dedicated video devices installed in conference rooms or individual offices. In general, the following options are available for establishing trusted packet classifications: • Do not trust the endpoint, but classify the traffic as it enters the network. (Trust is established at the network ingress port.) Advantages: – This method does not require the endpoint to mark any packets correctly. – Trust is under the control of the network administrator. Disadvantages: – Defining the access control list (ACL) to classify the packets can be challenging and requires in-depth knowledge of the protocols and the endpoints. – There is an additional administrative burden because the ACLs are endpoint-specific and must be updated as changes occur the network.

Cisco IP Video Telephony SRND 5-2 9562740406 Chapter 5 Quality of Service Traffic Classification and Trust

• Trust the IP Phone and not the PC attached to the PC port on the phone. (Extend trust to the IP Phone.) Advantages: – This method greatly simplifies the definition of the ACL because most of the traffic is already classified correctly. – Trust can be extended conditionally when an IP Phone is detected. Disadvantages: – This method does not provide QoS for any packets from the downstream PC, unless additional ACLs are configured. – Extending trust to IP Phones does not work in all cases, but it does work for all IP Phones that support Cisco VT Advantage. • Trust the endpoint attached to the network port. Advantages: – There are no ACLs to define. – This method is the simplest and easiest to implement. Disadvantages: – If the endpoints do not mark (or incorrectly mark) their traffic, the network and all other applications requiring QoS will be affected. The Cisco Architecture for Voice, Video, and Integrated Data (AVVID) also provides recommendation on how to classify the traffic. Table 5-1 lists the recommended classification values for the common types of traffic, as specified in the latest version of the Cisco AVVID Network Infrastructure Enterprise Quality of Service SRND (available at http://cisco.com/go/srnd).

Table 5-1 Recommended Traffic Classifications

Layer-3 Classification Layer-2 Classification Differentiated Services Application IP Precedence (IPP) Per-Hop Behavior (PHB) Code Point (DSCP) Class of Service (CoS) Routing 6 CS6 48 6 Voice 5 EF 46 5 Videoconferencing 4 AF41 34 4 Streaming video 4 CS4 32 4 Mission-critical data 3 25 3 Call signaling 3 CS3 (currently) 24 (currently) 3 AF31 (previously) 26 (previously) Transactional data 2 AF21 18 2 Network management 2 CS2 16 2 Bulk data 1 AF11 10 1 Scavenger 1 CS1 8 1 Best effort 0 0 0 0

Cisco IP Video Telephony SRND 9562740406 5-3 Chapter 5 Quality of Service Scheduling or Queuing

The main classes of interest for IP Video Telephony are: • Vo ic e 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 AVVID network. 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 (or normal) would have the media classified as CoS 5 (IP Precedence 5 or PHB EF), while the audio channel of a video conference would have the 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 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, among other things 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 Endpoint QoS Classification, page 5-6. 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

Scheduling or Queuing

The following sections briefly discuss traffic scheduling or queuing in the campus and the WAN.

Queuing in the Campus

All Cisco Ethernet Switches that are recommended for Cisco AVVID networks contain multiple queues. The number and types of queues, along with the number of drop thresholds per queue, vary by switch model, but in general there is a minimum of two queues. When QoS is enabled, the voice and video media streams are placed into a different queue from the other classes of traffic. This separation minimizes the possibility of congestion and, therefore, avoids any packet drops. It also allows for the priority scheduling of packets from this queue to the egress port, minimizing jitter and delay.

Cisco IP Video Telephony SRND 5-4 9562740406 Chapter 5 Quality of Service Bandwidth Provisioning

Queuing in the WAN

Cisco IOS Routers use a queuing scheme known as Low Latency Queuing (LLQ), which offers a Class-Based Weighted Fair Queue (CBWFQ) for all types of data and call signaling traffic, with an additional Priority Queue (PQ) for voice and video media. When deploying voice and video, you should define two separate policers, one for voice-only and one for the video calls. The entrance criteria to the policers should be based on the traffic classification. The video policer includes the voice channel component of the video call. Because voice and video are policed independently, voice calls will be protected from video calls, and vice versa.

Bandwidth Provisioning

To support interactive video, the minimum recommended link speed is 768 kbps. Below this speed, placing video into the same priority queue as voice will introduce jitter in the voice traffic due to the serialization delay inherent with output-scheduling a 1500- video frame onto the network because Link Fragmentation and Interleaving (LFI) is not active on a PQ. At link speeds greater than 768 kbps, the serialization delay is low enough that voice will not be adversely affected. The section on Bandwidth Requirements, page 4-1, explains how to calculate the amount of bandwidth actually required by video calls and how that amount compares to the bandwidth required for audio-only calls. Using that information, this section provides guidance on how to configure the queues in Cisco Catalyst Switches and IOS Routers to provide guaranteed bandwidth to these traffic classes.

Traffic Shaping

Traffic shaping helps to eliminate bottlenecks in the network by shaping traffic to conform to the Service Level Agreement (SLA) from your service provider. This agreement may include, for example, the Committed Information Rate (CIR) for a Frame Relay service. Traffic shaping helps ensure that a higher-speed head-end link does not send traffic faster than the lower-speed tail-end link can handle it, resulting in packets being queued or potentially dropped. Traffic shaping also ensures that head-end links are not oversubscribed when multiple tail-end links burst to their full capacity. These principles, which guide the use of traffic shaping for voice, also apply to video. It is not good practice to let the network drop video packets because some links burst above their CIR, or because multiple tail-end links burst and oversubscribe the head-end, or because the head-end sends traffic to the tail-end sites faster than they can handle it. If you are using Frame Relay, ATM, or MPLS as the transport layer protocol, you must ensure that the CIR from your carrier allows for the number of video calls you intend to transmit and that any existing traffic shaping configurations in place for voice are adjusted when video is added to the network.

Compressed RTP (cRTP)

cRTP saves bandwidth by compressing the RTP, UDP, IP headers of voice packets. This compression is especially useful when operating at link speeds less than 768 kbps. At link speeds greater than 768 kbps, the bandwidth savings is not significant enough to justify the additional CPU usage on the . In addition, while cRTP makes sense for voice because the voice payload is much smaller than the sum of the headers, there is no benefit in using cRTP for video because the payload sizes of the video packets are much larger (up to 1500 ). This is the second reason why 768 kbps is the recommended

Cisco IP Video Telephony SRND 9562740406 5-5 Chapter 5 Quality of Service Endpoint QoS Classification

minimum link speed for video. At less than 768 kbps, it might be useful to turn on cRTP to save bandwidth for voice traffic, but it is not useful to do so for video. Therefore, if video is present on the link, cRTP should not be used.

Link Fragmentation and Interleaving (LFI)

Links that require LFI (less than 768 kbps) are not recommended for support of interactive video. LFI is a technique to ensure that voice packets never have to wait for a large data packet to be transmitted. LFI fragments larger data packets in the CBWFQ into smaller chunks and interleaves the voice packets from the PQ with those data fragments. This technique minimizes the effects of jitter on voice media. Like cRTP, LFI is useful only with link speeds less than 768 kbps. At higher links speeds, the serialization delay is low enough to negate the need for LFI. Because video packets can be large (up to 1500 bytes), placing the video packets into the PQ at link speeds less than 768 kbps could cause serialization delay because the traffic from the PQ does not pass through any LFI mechanisms. However, if you place the video packets into the CBWFQ instead, then they will be subjected to LFI and will be fragmented, which could lead to poor video quality. This is the third reason why the minimum recommended link speed for video is 768 kbps, and at that speed or greater, LFI is no longer necessary.

Endpoint QoS Classification

In a perfect network, endpoints would classify their packets properly and the switches could be configured to trust these classifications. Unfortunately, in a typical network, many endpoints either are not capable of classifying their packets or they classify them incorrectly in many cases. (For details about how endpoint devices mark traffic, refer to the product documentation from your endpoint equipment vendor.) This section discusses traffic classification by the following types of endpoint devices: • Cisco VT Advantage with a Cisco IP Phone, page 5-6 • Tandberg SCCP Endpoints, page 5-7 • H.323 Video Endpoints, page 5-7

Cisco VT Advantage with a Cisco IP Phone

The Cisco VT Advantage application residing on the user’s PC supports the classification of video packets using DSCP and, therefore, only at Layer 3. The current best practices for Cisco IP Telephony design recommend that the upstream Ethernet switch to which the phone is attached should be configured to trust the 802.1p CoS from the phone. Because the PC packets are unlikely to have an 802.1Q tag, they are unable to support 802.1p CoS bits. This lack of 802.1p support from the PC leaves the following possible options for providing QoS for Cisco VT Advantage:

Option 1 If your current QoS model extends trust to the IP Phone, then the voice and signaling packets will be correctly marked as they ingress the network. With an additional ACL on the port to match UDP port 5445, the video media channel will also be classified to PHB AF41. Without this ACL, the video media would be classified Best Effort and would incur poor image quality and lip-sync issues. The same ACL could also be used to match the CAST connection between the VT Advantage PC and the IP Phone,

Cisco IP Video Telephony SRND 5-6 9562740406 Chapter 5 Quality of Service Endpoint QoS Classification

which uses TCP port 4224 (classifying it as CS3), although the benefit of doing so is minimal. The signaling packets from the PC, which is on the data VLAN, are returned over the same high-speed port onto the voice VLAN, therefore they are highly unlikely to encounter any congestion.

Option 2 The next version of the Cisco AVVID QoS Design Guide will institute an alternative set of recommendations. The alternative method recommends changing the port to trust the DSCP of incoming traffic instead of trusting CoS, and then running the incoming packets through a series of Per-Port/Per-VLAN Access Control Lists that match packets based on their TCP/UDP ports (along with other criteria) and police them to appropriate levels. For instance, VT Advantage will mark its video packets with DSCP AF41, with the switch port set to trust DSCP. The packet will run through an ACL that matches it based on the fact that it is using UDP port 5445, is marked with DSCP AF41, and is coming in on the data VLAN. This ACL will then be used in a class map or policy map to trust the DSCP and police the traffic to N kbps (where N is the amount of video bandwidth you want to allow per port). Similar ACLs and policers will be present for the voice and signaling packets from the IP Phone in the voice VLAN.

Tandberg SCCP Endpoints

Tandberg SCCP endpoints correctly mark their media and signaling packets at Layer 3 using DSCP. They do not, however, support 802.1Q and are therefore unable to classify using 802.1p CoS. If we used the UDP and TCP port-matching option, we would be able to classify the SCCP signaling correctly as CS3 and the video media as AF41, however we would be unable to tell when a UDP port is being used in a voice-only call and should therefore be classified as EF. In such a case, the call admission control mechanisms would not be able to account for the bandwidth correctly. To avoid this situation, there is only one viable option for how to classify and trust traffic from a Tandberg endpoint:

Option 1 Trust DSCP on the port used by the Tandberg endpoint. If the switch allows it, configure policers to limit the maximum amount of EF, AF41, and CS3 traffic that can be received on that port. Any other device plugged into that port should not necessarily be trusted, even if its packets are classified using DSCP. This option may be acceptable if the Tandberg system is a permanent installation in an office or small conference room. Because the Tandberg device does not support CDP, the VLAN placement of this endpoint requires manual modification if the requirement is to place it in the voice VLAN. The advantage of placing the endpoint directly in the voice VLAN is that it can be treated like any other IP Telephony endpoint in the system. The disadvantage is that the port might pose a security risk because it provides direct access to the voice VLAN. Alternatively, you can leave the Tandberg endpoint in the data VLAN, but you will have to provision access between the data and voice VLANs to permit SCCP signaling to Cisco CallManager and to allow the UDP media streams to pass between the data and voice VLANs during voice or video calls.

H.323 Video Endpoints

This type of endpoint is potentially the most challenging from a QoS perspective due to the wide range of H.323 video endpoints, the variation in implementations, and the feature sets. There are two main QoS options for these endpoints; the first relies on the H.323 video endpoint to correctly mark all the traffic, and the second relies on detailed knowledge of the TCP and UDP ports used.

Cisco IP Video Telephony SRND 9562740406 5-7 Chapter 5 Quality of Service ACL and Policing Support

Option 1 If the endpoint correctly marks the media and signaling traffic (signaling should include H.225, H.245, and RAS), you could trust the classifications. Because it is unlikely that the endpoint supports 802.1Q (and therefore 802.1p CoS), you will probably have to use IP Precedence or DSCP in this case. The choice of classification type depends on the specific vendor, model, and software version.

Note It is unlikely that a H.323 endpoint will mark the media packets of a voice-only call differently from the voice component of a video call. Therefore, you should consider this fact when provisioning the video queues to allow a little oversubscription so that voice-only calls can be made.

Option 2 Using a combination of either source, destination, or both TCP and UDP port numbers (possibly including IP addresses as well), you might be able to define an ACL that matches and classifies the traffic correctly. In addition, Cisco recommends that you also apply policers to limit the amount of each class of traffic that is admitted to the network. This option has the same potential as Option 1 for classifying voice-only calls incorrectly.

ACL and Policing Support

How you implement ACLs depends on which model and version of Cisco switch you are using. In general, the best practice is to classify your traffic as close to the source as possible. Thus, if you have Layer-3 switches in your access layer, you should place the ACLs there. If your access-layer switches are Layer-2 only, you should place the ACLs at the first Layer-3 boundary. In addition, the way in which you write the ACLs will depend on what generation of switch you are using. The latest generation of Layer-3 switches from Cisco offers the ability to classify traffic based on the following factors: • VLAN of the switch • TCP/UDP port numbers used by the switch • DSCP value currently marked in the switch by the endpoint This combination of ACL rules is known as Per-Port/Per-VLAN ACLs and is available on the Cisco 3550, 3750, Catalyst 4500 Supervisor III or greater, and Catalyst 6500 Supervisor IIa or greater, running the latest version of Cisco IOS or CatOS software. Consult the release notes of your switch model and version for more details. Older generation switches from Cisco (such as the Cisco 2900, 3500, and older Supervisor versions of the Catalyst 4500 and 6500 platforms) are not capable of Per-Port/Per-VLAN ACLs, so on those switches you would use only the TCP/UDP port numbers and possibly the DSCP values to classify the traffic. Note, however, that the ability to write these ACLs presumes that you know precisely which TCP/UDP port numbers will be used by the various packet types for each device. Unfortunately, every device uses different port numbers, even where there are standards that dictate a specific port range. For instance, RTP recommends the use of UDP port numbers 16,384 to 32,768, but many voice/video devices do not use that port range. In other cases, particularly for certain signaling protocols, the destination TCP port is well known while the source TCP port is randomly chosen from a huge range. In practice, it is very difficult and time-consuming to write an ACL to classify traffic based on TCP/UDP port numbers for all types of endpoints and protocols.

Cisco IP Video Telephony SRND 5-8 9562740406

CHAPTER 6

Gateways

Cisco offers two types of IP gateways to connect to the PSTN: • Cisco Voice Gateways • Cisco IP/VC 3500 Series Video Gateways Cisco Voice Gateways are available in multiple forms (such as standalone devices, modules that integrate into Cisco IOS Routers, or line cards that integrate into Cisco Catalyst Ethernet Switches); they 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; and they offer a rich set of management and troubleshooting interfaces (such as , SNMP, syslog, and much more). However, Cisco Voice Gateways do not support the H.320 protocol suite or the H.26x family of video codecs and, therefore, cannot be used for video calls. For this reason, Cisco offers a separate family of video-capable gateways under the IP/VC 3500 Series portfolio. The IP/VC gateways, while excellent for video calls, do not support all of the features that Cisco Voice Gateways offer The IP/VC gateways have the following characteristics: • Support only H.323 and H.320 • Standalone devices that cannot be integrated into Cisco IOS Routers or Cisco Catalyst Switches • Support only T1/E1-PRI, ISDN BRI, and V.35 interface types • Support only G.711, G.728, and G.722; do not support G.729 audio • Do not support many of the manageability and troubleshooting capabilities inherent in Cisco Voice Gateways (for example, no telnet CLI, limited SNMP support, limited syslog support, and so on) • Do not support H.245 Empty Capabilities Set or H.450; therefore, they do not support supplementary services such as hold, transfer, conference, park, and so forth As a result of these differences in the products, Cisco IP/VC 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 purchase both types of gateways and use the Cisco Voice Gateways for all voice calls but use the Cisco IP/VC 3500 Series gateways for video calls only. The customer must also procure separate voice and video circuits from their PSTN service provider. For example, you cannot have a single T1-PRI circuit from the Central Office (CO) and share that line for both voice and video calls. In the previous generation of H.320 videoconferencing, these lines were often shared, as depicted in Figure 6-1. With IP Video Telephony, PSTN lines can no longer be shared due to the need for separate voice and video gateways, as depicted in Figure 6-2.

Cisco IP Video Telephony SRND 9562740406 6-1 Chapter 6 Gateways

Figure 6-1 Traditional PBX Sharing PSTN Lines Between Voice and H.320 Videoconferencing

PSTN

Proprietary Handset Protocol

ISDN or other TDM interface 119506

Figure 6-2 Cisco CallManager System with Separate PSTN Lines for Voice and IP Video Telephony

M IP PSTN M M

M M

V IP SCCP MGCP H.323 119507 ISDN or other TDM interface

With separate voice and video gateways, the route plans must also be separate for both inbound and outbound calls. For inbound calls, there is no way to have a single (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 through an Interactive Voice Response (IVR) prompt. 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. 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 2600 Series IOS Routers 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?

Cisco IP Video Telephony SRND 6-2 9562740406 Chapter 6 Gateways Routing Inbound Calls from the PSTN

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 Cisco CallManager 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. • For video calls, have outside callers dial the corporate main number connected to the video gateway. This number can invoke an IVR service that prompts the caller to enter the extension number of the party they are trying to reach. Cisco CallManager will then recognize that it is a video call when 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 IP Phone 7960 attached to a PC running VT Advantage. The extension of the IP Phone is 51212, and the fully qualified E.164 address of that 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, Cisco CallManager 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 IP/VC 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, Cisco CallManager knows that the gateway is capable of video, so it negotiates both audio and video channels for that call.

Cisco IP Video Telephony SRND 9562740406 6-3 Chapter 6 Gateways Routing Outbound Calls to the PSTN

Gateway Digit Manipulation The Cisco IP/VC 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 Cisco CallManager. Therefore, Cisco CallManager 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 that gateway is configured to pass 10 digits but the extension of the called party is only five digits, Cisco CallManager 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 Cisco CallManager to pay attention to only the least-significant N digits of the called number. For example, setting the Significant Digits to 5 will cause Cisco CallManager 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, Cisco does not recommend this 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 Cisco CallManager 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.

Routing 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 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 the video gateway(s). • Assign at least two different directory numbers on each video-enabled device in the Cisco CallManager cluster, with one line for audio and another line for video. The two lines can then be placed in different partitions and given different calling search spaces. 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 IP/VC Gateways use service prefixes to define the speed for outbound calls. When you configure a service prefix in the gateway, choose one of the following speeds for all calls placed by that gateway: • Voice-only • 128 kbps • 256 kbps • 384 kbps

Cisco IP Video Telephony SRND 6-4 9562740406 Chapter 6 Gateways Automated Alternate Routing (AAR)

• 768 kbps • Auto (dynamically determined; supports any call speed in the range of 128 kbps to 768 kbps) Calls received from the IP network 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. 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#. The ramification of using a service prefix is that Cisco CallManager 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 Cisco CallManager to prepend the # to the dialed number. For example, if the access code to dial a video call to the PSTN is 8, you can configure a route pattern as 8.@ in Cisco CallManager. You would also have to strip the original 8 and then prepend #8 whenever that route pattern is dialed.

Automated Alternate Routing (AAR)

When the IP network does not have enough bandwidth available to process a call, Cisco CallManager uses its call admission control mechanism to determine what to do with the call. As described in the chapter on Call Admission Control, page 4-1, Cisco CallManager 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 (if the caller is on a Cisco IP Phone) • Retry the video call as an audio-only call • Use automated alternate routing (AAR) to re-route the call over the an alternative path, such as a PSTN gateway The first two options are covered in the chapter on Call Admission Control, page 4-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 to 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 B's 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, Cisco CallManager will take user B's 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 Call Admission Control, page 4-1, if this option is enabled (checked), Cisco CallManager 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

Cisco IP Video Telephony SRND 9562740406 6-5 Chapter 6 Gateways Automated Alternate Routing (AAR)

(unchecked), Cisco CallManager performs AAR. By default, all video-capable devices in Cisco CallManager 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. Furthermore, Cisco CallManager 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 B's phone would have to have this feature disabled in order for the AAR process to take place. 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, and if the AAR groups are configured to prepend 91 to the dialed number, 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 more 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 VT Advantage or a Tandberg T-1000 used to make audio-only calls), 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 6-1 lists scenarios when it is appropriate to use AAR with various device types.

Table 6-1 When to Use AAR with a Particular Device Type

Device Type Device is used to call: Enable AAR? Comments IP 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 video VT Advantage 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. Tandberg 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. H.323 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 IP Video Telephony SRND 6-6 9562740406 Chapter 6 Gateways Least-Cost Routing

Least-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 CallManager Release 4.0, LCR basically means the same thing as TEHO.) Cisco CallManager 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 • 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 6-5. 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 already 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 two to four video calls, depending on the speed of each call. 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, IP/VC gateways are 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

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 approach is that ISDN lines support a limited number of B-Channels. With H.320 protocol, when an inbound video call is received, the destination device 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

Cisco IP Video Telephony SRND 9562740406 6-7 Chapter 6 Gateways ISDN B-Channel Binding, Rollover, and Busy Out

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 PSTN

Inbound 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 IP/VC 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 controllers and supports bonding channels across both controllers. For example, controller 1 might have only five channels available while controller 2 is sitting idle and, therefore, has 23 channels available. By taking the five channels from controller 1 and one channel from controller 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 controller 2 will be busied out, and all further inbound calls will be rejected with cause code "Network Congestion." Cisco IP/VC gateways cannot bound channels across different gateways or across different Cisco 3540 gateway models in the same Cisco 3544 chassis, so two controllers is the maximum that you can bond together. You can still roll calls over to the third PRI in the trunk group, but you cannot bond channels between PRI number one and PRI number three, as you can between PRI number one and PRI number two. By configuring the busy-out threshold, you can force calls to roll over to the next available circuit in the trunk group. Most COs support trunk groups of up to 6 circuits. However, the busy-out logic 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 controller 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 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.

Cisco IP Video Telephony SRND 6-8 9562740406 Chapter 6 Gateways Configuring the Gateways in Cisco CallManager

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.

Configuring the Gateways in Cisco CallManager

You can configure an IP/VC gateway in either of the following ways in Cisco CallManager: • Configure it as an H.323 gateway, and Cisco CallManager 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 Cisco CallManager 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 Cisco CallManager 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 Cisco CallManager which gateway it should send a given call to. For inbound calls from the PSTN to Cisco CallManager, however, the IP/VC gateways must have a gatekeeper to tell them where to route the calls. The gateways cannot be configured to point directly at Cisco CallManager. Instead, no matter what number is received from the PSTN, the gateways must contact the gatekeeper with an Admission Request (ARQ), and the gatekeeper can then instruct the gateway to route that call to Cisco CallManager. See Gatekeepers, page 8-1, for more details on how to configure the gatekeeper to route calls from the gateways to Cisco CallManager. Therefore, regardless of whether you decide to configure the gateways as H.323 gateways or reach them via an H.225 trunk, the H.225 trunk must be there to receive inbound calls from the gateway. When the gatekeeper tells the gateway to send the call to the H.225 trunk of Cisco CallManager, Cisco CallManager will try to match the IP address of the remote dial peer to see if the device is configured in its database. If there is an H.323 gateway device with a matching IP address configured for that gateway, Cisco CallManager will treat the call as if it came in on that gateway device and will apply the calling search space and other settings of that H.323 gateway device. If the gateway is not configured directly in Cisco CallManager, Cisco CallManager will treat the call as if it came in on the trunk and will apply the calling search space and other settings of the trunk.

Cisco IP Video Telephony SRND 9562740406 6-9 Chapter 6 Gateways Configuring the Gateways in Cisco CallManager

Call Signaling Port Numbers

The Cisco IP/VC Gateways listen on TCP port 1820 instead of the well-known default port number of 1720. You can configure the port in the gateway itself or in the H.323 gateway device in Cisco CallManager. Either way, both sides have to match in order for outbound calls to the gateway to succeed. In the inbound direction, Cisco CallManager uses a randomly generated port number for all gatekeeper-controlled trunks. This method enables Cisco CallManager to have multiple trunks to the same gatekeeper. This port number is included in the Registration Request (RRQ) from Cisco CallManager to the gatekeeper, so the inbound H.225 setup message from the gateway to Cisco CallManager will be sent to this port number. Again, if the gateway is configured directly in Cisco CallManager as an H.323 gateway device, Cisco CallManager 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, Cisco CallManager will treat the call as if it came in on the trunk.

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 Cisco CallManager 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 Cisco CallManager Administration.

Voice Gateways Compatibility

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 sets the bearer-caps to “speech” or “3.1 KHz Audio,” while a video call sets it to "Unrestricted Digital Information." Cisco voice gateways, the majority of PBXs, and most cellular carriers do not support Unrestricted Digital Information bearer-caps. Therefore, calls to a voice gateway might fail if Cisco CallManager attempts the call as a video call. What type of bearer-caps to use depends on the following factors: • Whether the calling and/or called devices are video-capable • Whether the region in Cisco CallManager is configured to allow video for calls between those devices For example, consider a network in which a video-capable device (such as a Cisco IP Phone with a VT Advantage client associated to it) is configured in the same region as a Cisco voice gateway. When the user dials 9 to access an outside line, Cisco CallManager determines that the calling device is video-capable and that the region is set to allow 384 kbps of video bandwidth. Cisco CallManager then sets the bearer-caps to Unrestricted Digital Information for that call. But because the call is to a Cisco voice gateway, the gateway rejects the call with the cause code "Incompatible Destination." This problem will occur in any network that uses H.323 voice gateways and that has IP Phones associated with Cisco

Cisco IP Video Telephony SRND 6-10 9562740406 Chapter 6 Gateways Configuring the Gateways in Cisco CallManager

VT Advantage. From the user’s perspective, things will appear to work fine before installing VT Advantage, but calls to the PSTN will fail as soon as the user plugs a PC running VT Advantage into the IP Phone. This situation exists only on calls to H.323 voice gateways. If the Cisco voice gateway uses MGCP to communicate with Cisco CallManager, the problem will not occur because Cisco CallManager does not support video on its MGCP protocol stack and because, in MGCP mode, Cisco CallManager has complete control over the D-Channel signaling to the PSTN. Likewise, if the Cisco voice gateway uses SIP to communicate with Cisco CallManager, the problem will not occur then either because Cisco CallManager does not support video on its SIP protocol stack. To prevent this situation, configure the bearer-caps on the Cisco H.323 voice gateway by using the bearer-caps command under the voice-port configuration mode, as illustrated in the following example: gateway#configure terminal gateway(config)#voice-port 1/0:23 gateway(config-voiceport)#bearer-caps speech

Cisco IP Video Telephony SRND 9562740406 6-11 Chapter 6 Gateways Configuring the Gateways in Cisco CallManager

Cisco IP Video Telephony SRND 6-12 9562740406

CHAPTER 7

Multipoint Conferencing

Whenever three or more parties want to engage in the same video call together, a Multipoint Control Unit (MCU) is required. An MCU consists of the following main components: • Multipoint Controller (MC) • Multipoint Processor (MP) The MC handles all aspects of call setup and teardown for the conference, including media negotiation, call signaling, and choosing which MP to use for the call. The MP processes all the audio and video packets. The MC controls the MP, and one MC can control multiple MPs. The MP can be either software-based or hardware-based. Software-based MPs are typically not capable of advanced transcoding, transrating (multiple speeds), or composition features. Since 1999, Cisco has offered the IP/VC 3500 Series H.323 Multipoint Conference Units (MCUs). The first product in this family was the Cisco IP/VC 3510. This model is no longer available for sale, and is not compatible with Cisco CallManager. In 2002, Cisco introduced the IP/VC 3511 and 3540 models. These models offer significantly improved features and scalability unavailable on the older 3510 model. In 2003, Cisco introduced software version 3.2+ on the IP/VC 3511 and 3540 models, which adds support for the Skinny Client Control Protocol (SCCP). SCCP support is not available on the IP/VC 3510. In addition, there are three types of MPs available in the IP/VC MCUs: • A software-based MP built into each MCU • The Rate Matching (RM) module, a dedicated software-based module for the IP/VC 3540 chassis • The Enhanced Media Processor (EMP), a hardware-based solution available as a dedicated module for the IP/VC 3540 chassis or as an integrated component in the IP/VC 3511 model Cisco CallManager Release 4.0 supports the IP/VC 3511 and 3540 models in both SCCP and H.323 modes. Each protocol offers different features and is used for different reasons, so each of these MCUs is equipped to run both protocols. The IP/VC 3511 can be configured to run in either SCCP mode or H.323 mode, while the IP/VC 3540 model can be configured to run both protocols simultaneously and divide the total number of available MP resources between the two. Regardless of signaling protocol, the MCU provides the same basic function of receiving the audio and video streams from each participant and sending those streams back out to all other participants in some sort of combined view. There are two types of views in a multipoint video conference: • Voice activated (switched) • Continuous presence

Cisco IP Video Telephony SRND 9562740406 7-1 Chapter 7 Multipoint Conferencing

Voice Activation Voice-activated conferences take in the audio and video streams of all the participants, decide which participant is the dominant speaker, and send only the dominant speaker’s video stream back out to all other participants. The participants then see a full-screen image of the dominant speaker, but the current speaker sees the previous dominant speaker. The audio streams from all participants are mixed together, so everyone hears everyone else, but only the dominant speaker’s video is displayed. You can use any of the following methods to select the dominant speaker: • Enabling (VAD) Using this feature, the MCU selects the dominant speaker by determining which conference participant is speaking the loudest and the longest. To determine loudness, the MCU calculates the strength of the voice for each participant. As conditions change throughout the conversation, the MCU automatically selects a new dominant speaker and switches the video to display that participant. A hold timer prevents the video from switching too hastily. To become the dominant speaker, a participant has to speak for a specified number of seconds and be more dominant than all other participants. • Manually selecting the dominant speaker through the MCU’s web-based conference control user interface The conference controller (or chairperson) can log onto the MCU’s web page, highlight a participant, and select that person as the dominant speaker. This action disables voice activity detection, and the dominant speaker remains constant until the chairperson either selects a new dominant speaker or re-enables voice activity detection. • Configuring the MCU to cycle through the participant list automatically, one participant at a time With this method, the MCU stays on each participant for a configured period of time and then switches to the next participant in the list. The conference controller (or chairperson) can turn this feature on and off (re-enable voice activity detection) via the web interface.

Continuous Presence Continuous-presence conferences display some or all of the participants together in a composite view. The view can display from 2 to 16 squares (participants) in a variety of different layouts. Each layout offers the ability to make one of the squares voice-activated, which is useful if there are more participants in the conference than there are squares to display them all in the composite view. For instance, if you are using a four-way view but there are five participants in the call, only four of them will be displayed at any given time. You can make one of the squares in this case voice-activated so that two of the sites will switch in and out of that square, depending on who is the dominant speaker. The participants displayed in the other three squares are fixed, and all of the squares can be manipulated via the conference control web-based user interface.

MP Resources For both types of conferences, the type of MP resource determines which video formats, transrating, and transcoding abilities the MCU can support. If endpoints connect to the conference at different speeds, a transrating-capable MP is required. The RM and EMP modules are both capable of transrating between speeds. If a transrating-capable MP is not available, the MCU will send out flow-control messages to all the endpoints, instructing them to lower their transmit speed to match the maximum receive rate of the slowest endpoint. For example, if three participants are connected in a 384-kbps conference and a fourth participant joins at 128 kbps, the MCU will send flow-control messages to the other three participants instructing them to lower their transmit rates to match the 128-kbps participant. This method causes all participants to suffer degraded quality because one participant is less capable. A transrating-capable MP would, instead, convert the 128-kbps stream to 384 kbps, and vice versa, so that each participant can enjoy the best quality their connection allows.

Cisco IP Video Telephony SRND 7-2 9562740406 Chapter 7 Multipoint Conferencing SCCP MCU Resources

For continuous-presence conferences, a transrating-capable MP is also very important. The software-based MP built into the MCU combines all the input streams and sends the resulting combination back out to each participant. For instance, if four participants are connected in a continuous-presence conference at 384 kbps using G.711 audio, each participant will transmit 320 kbps of video and 64 kbps of audio into the MCU. The MCU will take these four input video streams and combine them into the four-way composite view. The MCU will then transmit 1280 kbps of video back to each endpoint, along with the mixed 64 kbps of audio, for a total of 1344 kbps per endpoint. This method is known as Asynchronous Continuous Presence, and it can have a negative impact on bandwidth requirements, call admission control mechanisms, and interoperability with certain devices. With the RM or EMP modules, the MCU is capable of transrating each input stream before combining them, so that the total output bandwidth matches the input bandwidth. For instance, if the MCU was using the four-quadrant layout and each participant transmits 320 kbps of video and 64 kbps of audio into the MCU, the MCU would essentially transrate each input stream down to 80 kbps, combine them so that the resulting four-quadrant view is 320 kbps of video (4 x 80 kbps), combine this video with the mixed 64 kbps audio, and transmit the final combination back to each participant. This method is known as Synchronous Continuous Presence.

SCCP MCU Resources

As stated previously, the Cisco IP/VC 3511 and 3540 MCUs both offer support for SCCP beginning with software version 3.2+ for those models and with Cisco CallManager Release 4.0. When configured in SCCP mode, Cisco CallManager provides the MC function while the MCU provides the MP function. The SCCP MCU is controlled completely by Cisco CallManager. Only the following events invoke SCCP MCU resources: • An SCCP endpoint (such as an IP Phone or a Tandberg endpoint) presses the Conf, Join, or cBarge softkeys to invoke an ad-hoc conference • An SCCP endpoint (such as an IP Phone or a Tandberg endpoint) presses the MeetMe softkey to invoke a reservationless meet-me conference. Participants in either of these types of conferences can include any type of endpoint (that is, video and non-video devices using any signaling protocol that Cisco CallManager supports via any supported gateway type); however, only SCCP endpoints can invoke the SCCP MCU resources. For ad-hoc conferences via the Conf, Join, or cBarge softkey, the signaling protocol used by the other endpoints must support the ability to be placed on hold and then have their audio and video channels redirected to the MCU. H.323 endpoints provide these functions using the Empty Capabilities Set (ECS). If the H.323 endpoint does not support ECS, it cannot be conferenced or joined by an SCCP device, and it will react by hanging up or possibly even crashing and/or rebooting. To work around this problem, you can enable (check) the "MTP Required" option on the H.323 device but assign it a media resource group list (MRGL) that does not contain any MTP devices, and then set the Cisco CallManager Service Parameter "Fail Call if MTP Allocation Fails" to False. This configuration will cause the softkeys to be greyed out on the phone, disabling the user from invoking an ad-hoc conference with that endpoint. For reservationless conferences via the MeetMe softkey, the signaling protocol used by the other endpoints does not have to support being placed on hold and transferred. For these types of conferences, each endpoint dials in itself instead of being transferred in by the initiator, as in a Conf, Join, or cBarge type of conference. Figure 7-1 illustrates how H.323 and SCCP endpoints can participate in the same SCCP conference. In this example, the conference was initiated by an SCCP endpoint using the Conf softkey to invite the three members.

Cisco IP Video Telephony SRND 9562740406 7-3 Chapter 7 Multipoint Conferencing SCCP MCU Resources

Figure 7-1 Ad-Hoc Conference Between SCCP and H.323 Endpoints

M

M M

M M

SCCP H.323 119508 IP RTP Media

SCCP conferences support voice-activated mode only; continuous presence is not supported for SCCP conferences. Furthermore, SCCP conferences support the integrated software-based MP of the MCU and the Rate Matching (RM) module, but the EMP module is not supported for SCCP conferences. The software MP does not provide transrating between different video bit-rates, so if you have endpoints in different regions connecting to the MCU at different speeds, the software MP will use flow-control messages to reduce the speeds to the maximum receive rate of the lowest-speed endpoint. The Rate Matching (RM) module supports transrating in the following cases only: • Between 128 kbps and 384 kbps • Between 384 kbps and 768 kbps Therefore, if you have an SCCP conference consisting of more than two different speeds (for instance, three different regions), the RM module will not be capable of transrating all of them.

Media Resource Groups and Lists

Cisco CallManager uses media resource groups (MRGs) and media resource group lists (MRGLs) to determine which specific conference bridge resource to use for a given endpoint. How you group the resources is completely at your discretion, but it is typically done either by geographical placement (so that all endpoints at a given site use the MCU closest to them) or by endpoint type (so that video-capable endpoints use a video-capable MCU while audio-only endpoints use a different conference bridge resource). When an SCCP device invokes the Conf, Join, or MeetMe softkey, Cisco CallManager uses the MRGL of the initiating endpoint to determine which conference bridge should be used. Cisco CallManager applies the following criteria, in the order listed, to select which conference bridge resource to use: 1. The priority order in which the media resource groups (MRGs) are listed in the media resource group list (MRGL) 2. Within the selected MRG, the resource that has been used the least Because of this selection process, the video-capable MCU must be at the top of the MRGL for the video-capable SCCP endpoint in order for that MCU to be selected when the user invokes the Conf, Join, or MeetMe softkey on that endpoint. However, some endpoints are not dedicated video endpoints. For example, the IP Phone used in conjunction with Cisco VT Advantage might be used for audio-only calls most of the time and for video calls only occasionally. Thus, if you place the MCU at the top of the

Cisco IP Video Telephony SRND 7-4 9562740406 Chapter 7 Multipoint Conferencing H.323 MCU Resources

MRGL for that phone, the MCU will always be chosen even for audio-only conferences that do not involve any other video-capable participants. In this scenario, the MCU resources might be wasted on audio-only conferences and not be available to satisfy the request for a video conference when it occurs. Therefore, Cisco recommends that you carefully select which users you want to give access to the video-capable MCU resources through MRGLs. The following considerations can help you make that selection: • Is the endpoint a dedicated video device (such as a Tandberg endpoint), or is it an IP Phone that will only occasionally have a VT Advantage client associated to it? • Does the user require video when invoking SCCP conferences, or will audio-only suffice? • How much are you willing to spend on MCU resources to outfit your network with enough resources to satisfy the SCCP conferencing requirements? The answers to these selection criteria will be different for every company. One company might deem multipoint video to be a critical feature and be willing to spend the money necessary to outfit their network with enough MCU resources so that, even if a few ports get wasted on audio-only conferences, there will still be resources available to satisfy all of their video conferences. Another company might choose to enable video resources only for their Tandberg endpoints and assign audio-only conference bridges to VT Advantage users who invoke SCCP conferences. A third company might choose to enable video resources for all Tandberg endpoints and for select VT Advantage users (perhaps managers and above), but allocate audio-only resources for the rest of the user population.

H.323 MCU Resources

When configured in H.323 mode, the MCU provides the MC function and behaves like an H.323 peer to Cisco CallManager. H.323 MCU conferences can be invoked in a number of different ways, but they all fall into two major categories: • Scheduled • Reservationless A scheduled conference uses a scheduling application to reserve the MCU resources in advance of the call. The scheduling function typically is provided through a web-based user interface such as Cisco MeetingPlace, MagicSoft VCWizard, RADVision VCS, Tandberg TMS, or FVC.COM Click to Meet. The scheduling application usually generates an invitation that provides the user with the date and time of the conference, the number of ports reserved for the conference, and the dial-in information. Alternatively, the scheduling system can be configured to dial out to some or all of the participants at the beginning of the conference. For a reservationless conference, the MCU has a certain number of resources that are available on demand. To create a conference, a user simply dials into the MCU at any time. If that user is the first participant to dial in, the MCU dynamically creates a new conference using the settings defined in the service template. Subsequent users who dial into the same conference number are joined to that conference. Any type of endpoint can create, and participate in, scheduled and reservationless conferences. For instance, an SCCP endpoint can dial into the MCU to create a reservationless conference just as well as an H.323 endpoint can. Figure 7-2 illustrates how H.323 and SCCP endpoints can participate in the same H.323 conference. In this example, the conference was initiated by an SCCP endpoint that dialed into the MCU to create a new reservationless conference, and the other two parties subsequently dialed into that conference.

Cisco IP Video Telephony SRND 9562740406 7-5 Chapter 7 Multipoint Conferencing H.323 MCU Resources

Figure 7-2 SCCP and H.323 Endpoints in a Reservationless Conference

M

M M

M M

SCCP H.323 119509 IP RTP Media

H.323 conferences support both voice-activated and continuous-presence modes. Furthermore, H.323 conferences support all of the MP types, including the integrated software-based MP of the MCU, the Rate Matching (RM) module, and the Enhanced Media Processor (EMP) module.

Service Templates and Prefixes

A service on the MCU defines the settings that pertain to each conference. You can have different services defined for the different types of conferences. For instance, you can have a service defined for high-quality conferences of large numbers of participants and another service defined for medium-quality conferences of three to four participants. Each service defines, at a minimum, the following settings: • Speed of the conference (the video bit-rate). This setting might include multiple speeds if a transrating MP is used. • Minimum and/or maximum number of participants. The minimum number defines how many ports will be reserved at the beginning of the call. The maximum number defines the maximum number of participants who can take part in the conference. • Video codec type (H.261 or H.263) • Frame rate (15 or 30 fps) • Resolution (QCIF or CIF) • MP resource (Auto, MP, RM, or EMP) • Video layout for the displayed (voice activated or continuous presence). A conference can include multiple layouts or even dynamic layouts that change as the number of participants in the conference increases. Each service is assigned a service prefix that is dialed by the endpoints to reach that particular service. The service prefix forms the leading digits of the conference number, and the trailing digits define the conference ID. This format allows multiple conferences to run simultaneously using the same service prefix. For instance, you can have a service prefix of 555, while the full dial string of the conference is seven digits. This scheme would allow for conference numbers in the range of 5550000 through 5559999, with four digits for the conference ID. The user must dial the full string to access the conference. When the call is received by the MCU, the MCU parses the dialed digits to try to match a service prefix. Once it determines which service prefix is being dialed, the MCU then uses the remaining

Cisco IP Video Telephony SRND 7-6 9562740406 Chapter 7 Multipoint Conferencing Sizing the MCU

digits as the conference ID. If the conference ID does not exist yet, the MCU creates a new reservationless conference with that ID. If the conference already exists, the user is added to that conference.

Gatekeeper Registration and Call Routing

Cisco IP/VC MCUs must be registered with a gatekeeper at all times. When the MCU is not registered with a gatekeeper, it displays a fault condition and continuously tries to register until it succeeds. For the gatekeeper to route calls from the MCU to Cisco CallManager, Cisco CallManager must also be registered to the gatekeeper via an H.225 gatekeeper-controlled trunk. These registrations give the gatekeeper the information it needs to route the calls correctly when the MCU dials out to the E.164 address of an endpoint. However, H.323 calls from Cisco CallManager to the MCU do not necessarily have to go through the gatekeeper. The MCU can be configured directly in Cisco CallManager as an H.323 gateway device. Cisco recommends this method of configuration because it provides the administrator with the flexibility to assign a unique calling search space and other properties to the MCU individually. In summary, an H.225 gatekeeper-controlled trunk is necessary to route calls from the MCU to Cisco CallManager, but calls from Cisco CallManager to the MCU can be configured to route to the gatekeeper via the trunk or directly to the MCU configured as an H.323 gateway device. Regardless of which method you choose to use, you route the calls to the MCU by configuring a route pattern that matches the service prefix of the MCU and then by pointing the route pattern either at the trunk or at the H.323 gateway device. The route pattern should be constructed to match the service prefix plus the conference ID. As a simple example, if the MCU’s service prefix is 555 and you want to use four digits for the conference ID, you should construct the route pattern as 555XXXX. More complex route patterns using additional wildcards and translation rules can also be used to meet the needs of your users.

Sizing the MCU

As mentioned previously, the current MCU models are the IP/VC 3511 and 3540. The IP/VC 3511 MCU supports a fixed number of ports, while the IP/VC 3540 MCU is a modular system that can accept various sizes of modules. When calculating the total number of ports available, you must also consider the number of sessions that the Audio Transcoder Daughter Card and the Rate Matching (RM) module or Enhanced Media Processor (EMP) module can support. Therefore, consider the following aspects when calculating the size of the MCU: • The number of ports that the MCU can support. This value depends on the speed of the conference; as the speed increases, the number of supported ports decreases. • The number of ports that the Audio Transcoding Daughter Card can support. This value depends on which audio codecs are used in the conference. • The number of conferences that the RM or EMP module can support. This value depends on how many participants need to be transrated and how many views are in use in the conference. For specific information about the number of ports supported, refer to the product documentation for your MCU hardware, available on Cisco.com.

Cisco IP Video Telephony SRND 9562740406 7-7 Chapter 7 Multipoint Conferencing IVR for Dial-In Conference

IVR for Dial-In Conference

Dial-in conferences typically use an interactive voice response (IVR) system to prompt users to enter the conference ID and the password (if one is configured) of the conference they want to join. You can use either of the following types of IVRs with the Cisco IP/VC 3500 Series MCUs: • The IVR built into the MCU • Cisco IP IVR The built-in IVR of the MCU has the following characteristics: • Can prompt only for the password of the conference; it cannot prompt the user for the conference ID first. • Supports both in-band and out-of-band DTMF. • Cannot be customized to provide more flexible menus or functionality. The only thing that can be customized is the recorded audio that is played to the user. Therefore, with the built-in IVR of the MCU, users cannot dial the main number of the MCU and have it prompt them for the conference ID they wish to join. Instead, the user must dial the conference ID directly, and then the IVR can prompt for a password if one is configured. If you want to have a single dial-in number and then prompt the user for the conference ID, you must use Cisco IP IVR in conjunction with the MCU. Cisco IP IVR has the following characteristics: • Can prompt for the conference ID and the password (among other things) • Supports only out-of-band DTMF • Can be highly customized to provide more flexible menus and other advanced functionality, such as verifying the users account against a back-end database

Note Because Cisco IP IVR supports only out-of-band signaling, it will not work with H.323 endpoints that use in-band DTMF tones.

With Cisco IP IVR, users dial a CTI route point that routes the call to the IP IVR server instead of dialing a route pattern that routes directly to the MCU. After collecting the DTMF digits of the conference ID, the IP IVR then transfers the call to the route pattern that routes the call to the MCU.

Cisco IP Video Telephony SRND 7-8 9562740406

CHAPTER 8

Gatekeepers

Prior to the introduction of Cisco CallManager Release 4.0, H.323 videoconferencing networks relied on gatekeepers to perform all device registration management, call routing, and bandwidth control. The Cisco IOS Gatekeeper, formerly known as the Conference Manager (MCM), provided these functions. Cisco CallManager Release 4.0 provides vastly superior call routing and bandwidth controls than gatekeepers do, so now it is much better to configure the H.323 devices in the network to route their calls through Cisco CallManager. The administrator can configure H.323 clients, Multipoint Control Units (MCUs), and gateways directly in Cisco CallManager Administration, enabling Cisco CallManager to signal directly to these endpoints without having to go through a gatekeeper for address resolution. However, except in a few cases, these devices cannot be configured to point directly to Cisco CallManager and must still register with a gatekeeper for address resolution. Therefore, a gatekeeper is still a required component of the IP Video Telephony network, but its role has changed from being the main call routing engine of the network to being an ancillary device working in conjunction with Cisco CallManager. In its new role, the Cisco IOS Gatekeeper performs the following critical functions: • Endpoint gatekeeper — configured as a registration place for H.323 clients, MCUs, and gateways, to direct calls from those devices to Cisco CallManager • Intercluster trunk gatekeeper — configured to perform address resolution and bandwidth management between Cisco CallManager clusters Figure 8-1 illustrates a network scenario with two Cisco CallManager clusters. Each cluster consists of SCCP endpoints and H.323 clients, MCUs, and gateways. Each cluster also contains an endpoint gatekeeper, and a separate intercluster trunk gatekeeper manages bandwidth between the clusters.

Cisco IP Video Telephony SRND 9562740406 8-1 Chapter 8 Gatekeepers Endpoint Gatekeepers

Figure 8-1 Two Cisco CallManager Clusters with Required Gatekeepers

M M

M M GK M M

M M M M

GK GK

SCCP 119510 IP H.323 IP

Endpoint Gatekeepers

The endpoint gatekeepers direct all H.323 calls into Cisco CallManager so that Cisco CallManager can then perform all call routing and bandwidth control. Therefore, you should configure the endpoint gatekeepers to route all calls to Cisco CallManager, no matter what digits are dialed. One endpoint gatekeeper can manage all H.323 clients, MCUs, and gateways for a single Cisco CallManager cluster. Each Cisco CallManager cluster, therefore, needs its own endpoint gatekeeper. An endpoint gatekeeper is required any time the cluster contains any H.320 gateways, H.323 MCUs, or H.323 clients. If none of these types of endpoints exist (for example, if all endpoints are SCCP and there are no MCUs or H.320 gateways), then an endpoint gatekeeper is not needed.

Zone Definitions

Zones are traditionally used in an H.323 gatekeeper to pool endpoints into groups, such as by geographical location. For an endpoint gatekeeper, zones are used to group endpoint types to restrict them from dialing each other directly without going through Cisco CallManager. For instance, you do not want an H.323 client to be able to dial an H.320 gateway directly. Instead, you want to configure the H.323 client to always route its calls through Cisco CallManager so that Cisco CallManager can enforce dialing restrictions, manage bandwidth, and generate call detail records (CDRs) for every call. Therefore, Cisco recommends that you create four zones on each endpoint gatekeeper: • Client Zone — A single zone is sufficient for all the H.323 clients in a cluster. • CallManager Zone — A single zone is sufficient for all the CallManager servers in a cluster. • Gateway Zone — A single zone is sufficient for all the H.320 gateways in a cluster. • MCU Zone — A single zone is sufficient for all the MCUs in a cluster. These zones enable you to configure the gatekeeper to block endpoints from calling MCUs and gateways directly and to block MCUs from calling gateways directly, and vice versa. All calls get routed to the CallManager Zone through the use of zone prefixes.

Cisco IP Video Telephony SRND 8-2 9562740406 Chapter 8 Gatekeepers Endpoint Gatekeepers

Zone Prefixes and Technology Prefixes

Zone prefixes enable the gatekeeper to route calls to the correct zone, while technology prefixes enable the gatekeeper to route calls to the correct gateway device. The gatekeeper considers Cisco CallManager to be a type of gateway. Therefore, you should configure the gatekeeper to route all calls to the CallManager Zone and then to the correct Cisco CallManager within that zone. Cisco recommends that you route all calls to the CallManager Zone by configuring ten zone prefixes (0 through 9) for that zone, as illustrated in the following example: zone prefix [callmanager_zone] 0* zone prefix [callmanager_zone] 1* zone prefix [callmanager_zone] 2* zone prefix [callmanager_zone] 3* zone prefix [callmanager_zone] 4* zone prefix [callmanager_zone] 5* zone prefix [callmanager_zone] 6* zone prefix [callmanager_zone] 7* zone prefix [callmanager_zone] 8* zone prefix [callmanager_zone] 9*

With the zone prefixes defined in this way, no matter what number an endpoint dials, the call will always be routed to Cisco CallManager. You must also configure an H.225 gatekeeper-controlled trunk in Cisco CallManager to register in the CallManager Zone. This trunk must register with a technology prefix, and Cisco recommends that you use technology prefix 1# for this purpose. You should also configure this technology prefix as the default technology prefix in the gatekeeper. The following command configures the technology prefix in the gatekeeper: gw-type-prefix 1# default-technology

When the gatekeeper matches the dialed number to a zone prefix, it then looks inside that zone to find a matching E.164 address. There will be no E.164 addresses registered in the CallManager Zone, so the gatekeeper will default to routing the call to a gateway that is registered with the default technology prefix in that zone, which in this case will be Cisco CallManager. As discussed in previous sections, when a gatekeeper routes a call to the H.225 trunk of Cisco CallManager, Cisco CallManager looks at the source IP address of the calling endpoint and tries to match that address to a device in its database. If it finds a matching IP address, Cisco CallManager applies that device’s calling search space and other relevant settings. If it does not find a match, Cisco CallManager applies the calling search space and other relevant settings of the trunk. For devices configured as H.323 gateways in Cisco CallManager (for example, H.320 gateways and MCUs would be configured as H.323 gateway devices), the H.225 handler representing that device in Cisco CallManager registers with every Cisco CallManager subscriber in the Cisco CallManager redundancy group defined for that device. For H.323 clients, the H.225 handler representing these devices registers with only the primary Cisco CallManager subscriber for that client’s device pool and Cisco CallManager group. Therefore, you must configure the gatekeeper to always route calls to the primary subscriber. If the primary subscriber goes down and unregisters from the gatekeeper, the gatekeeper should then route all calls to the secondary subscriber, and so on. To configure the gatekeeper to prioritize the routing of calls to the various Cisco CallManager subscribers in the cluster, use the gw-priority argument at the end of the zone prefix command, as illustrated in the following example: zone prefix [callmanager_zone] 0* gw-priority 10 [callmanager-1] zone prefix [callmanager_zone] 0* gw-priority 9 [callmanager-2] zone prefix [callmanager_zone] 0* gw-priority 8 [callmanager-3] zone prefix [callmanager_zone] 1* gw-priority 10 [callmanager-1] zone prefix [callmanager_zone] 1* gw-priority 9 [callmanager-2] zone prefix [callmanager_zone] 1* gw-priority 8 [callmanager-3]

Cisco IP Video Telephony SRND 9562740406 8-3 Chapter 8 Gatekeepers Endpoint Gatekeepers

zone prefix [callmanager_zone] 2* gw-priority 10 [callmanager-1] zone prefix [callmanager_zone] 2* gw-priority 9 [callmanager-2] zone prefix [callmanager_zone] 2* gw-priority 8 [callmanager-3] ... zone prefix [callmanager_zone] 9* gw-priority 10 [callmanager-1] zone prefix [callmanager_zone] 9* gw-priority 9 [callmanager-2] zone prefix [callmanager_zone] 9* gw-priority 8 [callmanager-3]

Zone Subnets

To configure the correct zones for the endpoints, use the zone subnet command in the gatekeeper to define which IP addresses or IP address ranges are permitted to register in each zone. You can specify either a particular host address or a subnet of addresses. For the Cisco CallManager, Gateway, and MCU zones, you can use specific host addresses, as illustrated in the following example: no zone subnet [callmanager_zone] default enable zone subnet [callmanager_zone] 10.1.1.101/32 enable zone subnet [callmanager_zone] 10.1.1.102/32 enable zone subnet [callmanager_zone] 10.1.1.103/32 enable ! no zone subnet [mcu_zone] default enable zone subnet [mcu_zone] 10.1.1.201/32 enable ! no zone subnet [gateway_zone] default enable zone subnet [gateway_zone] 10.1.1.301/32 enable zone subnet [gateway_zone] 10.1.1.302/32 enable

For the Client Zone, you do not have to explicitly allow the IP addresses of the endpoints. Instead, you can deny the IP addresses of all the Cisco CallManagers, MCUs, and gateways, and then use the default enable command to allow all other address ranges in that zone. For example: zone subnet [client_zone] default enable no zone subnet [client_zone] 10.1.1.101/32 enable no zone subnet [client_zone] 10.1.1.102/32 enable no zone subnet [client_zone] 10.1.1.103/32 enable no zone subnet [client_zone] 10.1.1.201/32 enable no zone subnet [client_zone] 10.1.1.301/32 enable no zone subnet [client_zone] 10.1.1.302/32 enable

In Cisco CallManager Release 4.0, you must use static IP addresses for all H.323 clients, MCUs, and gateways in order to define them in Cisco CallManager Administration. If this requirement is not suitable for your environment, you can support endpoints that use DHCP addresses by not configuring them in Cisco CallManager directly but instead defining a route pattern to point to the H.225 gatekeeper-controlled trunk in order to reach their specific E.164 addresses. However, if you use this method, you would have to modify the gatekeeper configuration so that it does not route all calls to Cisco CallManager. You could also deploy a second endpoint gatekeeper for these endpoints, if you prefer.

Cisco IP Video Telephony SRND 8-4 9562740406 Chapter 8 Gatekeepers Intercluster Trunk Gatekeeper

Disabling the Use of Proxy

The Cisco IOS Gatekeeper previously offered an H.323 Proxy function as part of the Multimedia Conference Manager (MCM) feature set. The MCM Proxy is not compatible with Cisco CallManager, so you must disable it. The Cisco IOS Gatekeeper, by default, is configured to use the MCM Proxy for inter-zone calls to and from H.323 clients. In other words, when you create a local zone on the Cisco IOS Gatekeeper, its default configuration is: use-proxy default [inbound-to | outbound-from] terminals

You must disable this function by using the following commands for each zone that has H.323 clients (terminals) registered in it: no use-proxy default inbound-to terminals no use-proxy default outbound-from terminals

Intercluster Trunk Gatekeeper

The intercluster trunk gatekeeper provides address resolution and bandwidth control between Cisco CallManager clusters. You can also use this gatekeeper to manage Voice over IP (VoIP) gateways for the purpose of toll bypass and tail-end hop-off (TEHO).

Zone Definition and Prefixes

On the intercluster trunk gatekeeper, you should configure a separate zone for each Cisco CallManager cluster in your enterprise, then apply a zone prefix to each zone to route calls to the correct Cisco CallManager cluster. In addition, configure a gatekeeper-controlled intercluster trunk to register in that zone using technology prefix 1#, and configure the gatekeeper to use 1# as the default technology prefix. The following example shows the gatekeeper configuration for a two-cluster network: zone local [cluster-1] [domain.com] zone local [cluster-2] [domain.com] zone prefix [cluster-1] 14085551… zone prefix [cluster-2] 19725551… gw-type-prefix 1# default-technology

Cisco IP Video Telephony SRND 9562740406 8-5 Chapter 8 Gatekeepers Supported Gatekeeper Platforms

Bandwidth Management

Use the bandwidth command to manage the number of calls between Cisco CallManager clusters. This command has several options, but the interzone and session options are the most relevant for intercluster trunks. The interzone option controls the amount of bandwidth for all calls in or out of a given zone, and the session option controls the amount of bandwidth per call. For example, suppose your network has two Cisco CallManager clusters connected via a DS-3 WAN link. Also assume that you want to allow twenty G.711 audio calls and five 384-kbps video calls and that you want all video calls to be restricted to 384 kbps. In this case, you can use the bandwidth interzone command to restrict the bandwidth for each zone to the total of twenty G.711 calls plus five 384-kbps video calls, and you can use the bandwidth session command to restrict each call to a maximum of 384 kbps, as shown in the following example: bandwidth interzone [cluster-1] 6400 bandwidth session [cluster-1] 768 bandwidth interzone [cluster-2] 6400 bandwidth session [cluster-2] 768

The bandwidth value is double the bit-rate of the call. For example, a G.711 audio call that uses 64 kbps would be denoted as 128 kbps in the gatekeeper, and a 384-kbps video call would be denoted as 768 kbps. Table 8-1 shows the bandwidth values for some of the most popular call speeds.

Table 8-1 Gatekeeper Bandwidth Settings for Various Call Speeds

Call Speed Gatekeeper Bandwidth Value G.711 audio call (64 kbps) 128 kbps G.729 audio call (8 kbps) 16 kbps 128-kbps video call 256 kbps 384-kbps video call 768 kbps 512-kbps video call 1024 kbps 768-kbps video call 1536 kbps

Supported Gatekeeper Platforms

The following platforms support the Cisco IOS Gatekeeper: • Cisco 7200 Series, 7301, and 7400 Series Routers • Cisco 3725 and 3745 Routers • Cisco 3640, 3640A, 3660 Routers • Cisco 2600XM Series and 2691 Routers The following platforms no longer support the Cisco IOS Gatekeeper: • Cisco 3620 Series Routers • Cisco 2600 (non-XM) Series Routers • Cisco 2500 Series Routers • Cisco 3810 Routers

Cisco IP Video Telephony SRND 8-6 9562740406 Chapter 8 Gatekeepers Gatekeeper Redundancy

Gatekeeper Redundancy

You can configure multiple gatekeepers of each type (endpoint and intercluster trunk) to provide redundancy. The Cisco IOS Gatekeeper offers two methods of configuring redundancy: • Standby Router Protocol (HSRP) • Gatekeeper clustering (alternate gatekeeper) HSRP is the older method and is supported by all types of endpoints. Gatekeeper clustering (also known as alternate gatekeeper) is a newer method that relies on a new field (Alt-GK) defined in H.323v3 to inform the endpoint of its alternate gatekeeper, and the gatekeepers use a protocol called Gatekeeper Update Protocol (GUP) to synchronize with each other. HSRP gatekeepers have the following characteristics (see Figure 8-2): • The fact that there are multiple gatekeepers is invisible to the endpoint, therefore all endpoint types support this method of redundancy. • The gatekeepers must all be located in the same IP subnet. • Only the active gatekeeper is aware of the state of the network (that is, which endpoints are registered and which calls are active). All other gatekeepers are essentially asleep until the active gatekeeper goes down.

Figure 8-2 Gatekeeper Redundancy Using HSRP

HSRP Synchronization

10.1.33.21 10.1.33.22

GK GK HSRP: 10.1.33.20 Campus network or

WAN 119466

Clustered (alternate) gatekeepers have the following characteristics (see Figure 8-3): • The endpoint must support the H.323v3 Alt-GK mechanism. • The gatekeepers can be located in different IP subnets. • All gatekeepers that are members of the cluster maintain active state through the GUP protocol.

Figure 8-3 Gatekeeper Redundancy Using Alternate (Clustered) Gatekeepers

Cluster Synchronization

10.1.33.21 10.1.47.23

GK GK Campus network or WAN 119467

Cisco IP Video Telephony SRND 9562740406 8-7 Chapter 8 Gatekeepers Gatekeeper Redundancy

Cisco IP Video Telephony SRND 8-8 9562740406

CHAPTER 9

Applications

Cisco IP Communications provides an expanding portfolio of applications that extend the features of Cisco CallManager and provide advanced capabilities and integration with other communication media. Many of these applications can be used in conjunction with IP Video Telephony devices, even if they do not specifically support video. For instance, Cisco CallManager Release 4.0 does not support the negotiation of video channels for CTI applications using the TAPI/JTAPI protocols, but that does not necessarily preclude using a CTI application in conjunction with a video call. This chapter reviews some of the Cisco and third-party applications and discusses whether or not they can be used to provide advanced call treatment for video calls.

CTI Applications

The following applications are based on the Computer Telephony Integration (CTI) interface.

Cisco Emergency Responder

Cisco Emergency Responder (CER) routes emergency (911) calls to the correct Public Safety Answering Point (PSAP). It also provides the PSAP with the correct calling line ID of the originating device so that the PSAP can respond to the correct physical location of the incident and call the party back in the event that the call is disconnected. CER uses JTAPI to integrate with Cisco CallManager. Emergency calls are routed to CER via a CTI route point, then CER decides which PSAP to forward the call to and what calling line ID to display. CER tracks each endpoint on the network to determine its physical location by using the Cisco Discovery Protocol (CDP) to discover the physical port and specific Cisco Catalyst Ethernet switch to which the endpoint is connected. CER then correlates this information with the physical location of the switch and stores the information in its database. Cisco VT Advantage works in conjunction with Cisco IP Phone models 7940, 7960, and 7970, and these phone models support CDP for the purpose of CER discovery. Therefore, if a VT Advantage user dials 911, CER is able to route the call to the correct PSAP. Because Tandberg SCCP endpoints do not support CDP, CER cannot track these endpoints if they are moved to a different Cisco Catalyst Ethernet switch. Therefore, Cisco recommends that users do not dial 911 from a Tandberg video endpoint. Because H.323 Videoconferencing clients do not support CDP, CER cannot track them if they are moved to a different Cisco Catalyst Ethernet switch. Therefore, Cisco recommends that users do not dial 911 from an H.323 video endpoint.

Cisco IP Video Telephony SRND 9562740406 9-1 Chapter 9 Applications CTI Applications

Cisco IP Manager Assistant

Cisco IP Manager Assistant (IPMA) enables administrative assistants to provide coverage for the managers with whom they are associated. IPMA uses JTAPI to integrate with CallManager. While IPMA is not specifically video-capable, there is nothing stopping IPMA from being used with phones that are video-enabled, because once IPMA has handled the call and the call is transferred to the final destination device, the two devices in the call communicate with each other directly, and could establish video channels at that point. For example, if a video-capable endpoint dialed the Directory Number of a Manager, and the Assistant covered the call using the IPMA application, there might not be any video established during the initial handling of the call, but once the Assistant transferred the caller to the Manager, CallManager could then negotiate video channels.

Cisco IP Interactive Voice Response and Cisco IP Contact Center

Like IPMA, Cisco IP Interactive Voice Response (IP IVR) and Cisco IP Contact Center (IPCC) use JTAPI to integrate with Cisco CallManager. If a video-capable device calls into an IVR application (such as a helpdesk), the communication is audio-only while the caller is connected to the application server (that is, while the caller browses the IVR menu or waits in queue for a helpdesk member to take the call). However, once the IVR application transfers the call to its final destination, video channels can be negotiated at that time. IVR applications often use DTMF tones to select options in the IVR menu. An alternative is , which enables the caller to speak commands to the IVR server instead of pressing keys on the phone. Because Cisco IP IVR and IPCC both use JTAPI to integrate with Cisco CallManager, they pass DTMF tones through out-of-band signaling messages. Many H.323 devices on the market today use in-band DTMF tones, and these H.323 clients would not be able to use DTMF to navigate an IP IVR or IPCC menu. However, these H.323 clients could use speech recognition if the IVR server is enabled for it. Video-capable devices such as Cisco VT Advantage, Tandberg SCCP devices, and any H.323 endpoint that uses H.245 alphanumeric out-of-band signaling for DTMF, can navigate the IVR menus using DTMF tones.

Cisco Attendant Console

Like IPMA, Cisco Attendant Console uses JTAPI to integrate with Cisco CallManager. The Attendant Console is used as a front-office device to handle incoming calls. Although Attendant Console does not specifically support video, video channels can be negotiated once the call is transferred to its final destination.

Cisco Personal Assistant

Cisco Personal Assistant (PA) provides two main functions: • Dialing assistance either through DTMF tones or voice commands • User-programmed call routing based on the time of day, caller ID information, and other factors For both of these functions, no video is established while the call is connected to the PA server, but video channels can be negotiated once PA transfers the call to its final destination.

Cisco IP Video Telephony SRND 9-2 9562740406 Chapter 9 Applications Collaboration Solutions

Cisco IP SoftPhone

Cisco IP SoftPhone uses JTAPI to integrate with Cisco CallManager and can be configured either as a standalone softphone or as a software interface to control an associated SCCP hardware phone. Cisco IP SoftPhone does not specifically support video, but it can be used in conjunction with an IP Phone that has a Cisco VT Advantage client associated to it. Cisco IP SoftPhone cannot be used to control a Tandberg SCCP device.

Collaboration Solutions

The following technologies can also be used to provide video communications between endpoints.

T.120 Application Sharing

Some videoconferencing endpoints use the T.120 protocol to share documents, whiteboards, and text among participants in a conference. Cisco CallManager Release 4.0 does not support negotiating a T.120 channel. Instead of T.120, Cisco recommends using web-based collaboration solutions such as Cisco MeetingPlace or other third-party collaboration solutions such as Placeware, Web-Ex, or IBM E-Collaborate.

Cisco MeetingPlace

Cisco MeetingPlace combines a high-end audio conferencing solution with a web-based front end for scheduling and participating in conferences. The in-conference web pages provide rich data collaboration capabilities such as application sharing, whiteboards, text sharing, and many more. Cisco MeetingPlace does not currently support video, but a future release of Cisco MeetingPlace will integrate with the Cisco IP/VC 3500 Series MCUs and provide the ability to include video endpoints in any meeting, scheduled or reservationless. Until then, video-capable endpoints can still participate in a MeetingPlace conference as audio-only.

Wireless Networking Solutions

Because video is so bandwidth intensive, Cisco does not recommend using a shared wireless medium such as 802.11b for transmitting video.

Cisco Aironet 802.11b Networking Solutions

The Tandberg T-1000 model endpoint offers a PCMCIA interface in which you can install a Cisco Aironet PCMCIA 802.11b Wireless Adapter. Tandberg does not currently support the Cisco LEAP protocol for authentication, but they do support static WEP keys. Take care to ensure that the video endpoints do not share the wireless bandwidth with any production IP Phones because video will consume much of the bandwidth and make it difficult to support video, audio, and data all on the same wireless medium.

Cisco IP Video Telephony SRND 9562740406 9-3 Chapter 9 Applications XML Services

Cisco VT Advantage relies on a physical Ethernet connection to the IP Phone with which it is associated. It is not uncommon for a user to have both a physical Ethernet interface and an Aironet 802.11b Wireless Adapter installed in the same PC. This configuration could cause problems for VT Advantage if the wireless interface happens to be the preferred path to the network because VT Advantage will not associate over that interface. Cisco recommends that you always make the physical Ethernet interface the preferred path. Also, when users connect to the PC port on the back of the IP Phone, instruct them to disable their Aironet Adapter to keep it from accidently taking precedence.

Cisco Wireless IP Phone 7920

The Cisco Wireless IP Phone 7920 does not support video.

XML Services

Currently there are no XML applications specifically written for the Cisco VT Advantage client solution or the Tandberg SCCP endpoints. Both types of endpoints, however, do support XML applications. VT Advantage uses a Cisco IP Phone 7940, 7960, or 7970, so any XML application supported on those phone models should also work with VT Advantage. The Tandberg SCCP endpoints support XML, but not all XML applications currently work on the Tandberg endpoints. For example, Cisco Extension Mobility and the Berbee InformaCast product are two popular XML applications that currently do not work on the Tandberg SCCP endpoints. Support for these applications will require firmware upgrades to the Tandberg endpoints as well as changes in Cisco CallManager Administration in some case.

Cisco IP Video Telephony SRND 9-4 9562740406

CHAPTER 10

Security

Security for communications over IP networks, and for the infrastructure that supports these communications, is an increasingly important topic for every type of enterprise. Cisco CallManager Release 4.0 offers many security-related enhancements to secure the servers and the communication streams. This release of Cisco CallManager is only one component of an overall security solution known as the Cisco SAFE Blueprint. SAFE provides a reference architecture for securing all aspects of the network, and it endorses the use of firewalls, access control lists, intrusion detection systems, and a myriad of other security tools available from Cisco. Customers should understand which elements of the SAFE Blueprint apply to video communications and which are applicable but not yet supported.

Separating the Voice and Data VLANs

Cisco recommends that you segment your voice and data endpoints into different VLANs to isolate the voice endpoints from attacks against data endpoints, and vise versa. You can also use access control lists and firewalls to restrict traffic between those VLANs. Cisco VT Advantage is a client application running on a PC, but it is also associated with an IP Phone. The PC will likely reside in the data VLAN while the phone will likely reside in the voice VLAN. To associate with the IP Phone, VT Advantage uses the Cisco Audio Session Tunnel (CAST) protocol, which operates over TCP/IP. In a typical environment, VT Advantage will have to communicate through whatever Layer-3 router is configured to route IP packets between the voice and data VLANs. If there are any access control lists or firewalls configured for that router, they will have to be modified to permit the CAST protocol to operate. CAST uses TCP port 4224 in both directions. VT Advantage communicates with the IP Phone but not with Cisco CallManager, except when VT Advantage periodically checks with the TFTP server (which could be coresident on one or more of the Cisco CallManager servers) to download any software updates. Therefore, you must also permit the TFTP protocol between the data VLAN and the TFTP server(s). Tandberg SCCP endpoints do not support Cisco Discovery Protocol (CDP) or 802.1Q VLAN ID tagging. Therefore, in a typical environment, the Tandberg devices will reside in the data VLAN, unless the port has been configured to use the voice VLAN as the native VLAN. The Tandberg endpoints communicate with the TFTP server to download their configurations, with Cisco CallManager for SCCP signaling, and with other phones for RTP audio/video media channels. Therefore, the TFTP protocol must be permitted between the data VLAN and the TFTP server(s), TCP port 2000 must be permitted between the data VLAN and the Cisco CallManager server(s), and UDP ports for RTP media must be permitted between the data and voice VLANs. H.323 clients, MCUs, and gateways communicate with Cisco CallManager using the H.323 protocol. Cisco CallManager H.323 trunks (such as H.225 and intercluster trunk variants) use a random port range rather than the well-known TCP port 1720. Therefore, you must permit a wide range of TCP ports

Cisco IP Video Telephony SRND 9562740406 10-1 Chapter 10 Security IP Phone Security Settings

between these devices and the Cisco CallManager servers. MCUs and gateways are considered infrastructure devices, and they typically reside within the datacenter adjacent to the Cisco CallManager servers. H.323 clients, on the other hand, typically reside in the data VLAN. Cisco IP/VC 3500 Series MCUs configured to run in SCCP mode communicate with the TFTP server(s) to download their configuration, with the Cisco CallManager servers for signaling, and with endpoints and gateways for RTP media traffic. Therefore, UDP port 69 must be permitted between the MCU and the TFTP server(s), TCP port 2000 must be permitted between the MCUs and the Cisco CallManager server(s), and UDP ports for RTP media must be permitted between the MCUs and the voice, data, and gateway VLANs. In addition, if the MCU will be placed on hold (and thus be the recipient of Music on Hold streams), UDP ports for RTP media must also permitted from the Music on Hold server(s) to the MCUs.

IP Phone Security Settings

You can set the following security-related parameters on the IP Phone configuration page of Cisco CallManager Administration: • PC Port: Enabled/Disabled • Settings Access: Enabled/Disabled • PC Voice VLAN Access: Enabled/Disabled • Video Capabilities: Enabled/Disabled • Ignore Gratuitous ARPs: Enabled/Disabled • Device Security Mode: Unsecure/Authenticated/Encrypted For VT Advantage to operate properly, the PC Port and Video Capabilities must both be enabled. The other settings can safely be disabled (or enabled in the case of Ignore Gratuitous ARPs). The Device Security Mode operates as specified, even when VT Advantage is in use, but VT Advantage itself does not support this features. When an IP Phone is in Authenticated mode, the SCCP signaling between the phone and Cisco CallManager will be authenticated, but the CAST signaling between the phone and VT Advantage will not be authenticated. Likewise, when a phone is in Encrypted mode, the audio stream between the phones will be encrypted, but the video streams between the VT Advantage clients will not be encrypted. Users should be notified that the video channel is not encrypted even though an icon on the phone appears to indicate that they are in an encrypted call.

Network Address Translation

Cisco Network Address Translation (NAT) solutions (such as PIX and Cisco IOS variants) do support H.323 audio and video. However, the SCCP protocol was revised in Cisco CallManager Release 4.0 to add video capabilities, and these NAT products have not yet incorporated support for this newer version of SCCP. Therefore, while SCCP audio is supported, SCCP video is not supported through NAT at this time.

Cisco IP Video Telephony SRND 10-2 9562740406 Chapter 10 Security Firewalls

Firewalls

Like NAT, Cisco solutions (such as PIX and NAT variants) support the stateful inspection of packets in order to open TCP/UDP ports dynamically. These firewalls support H.323 video and SCCP audio, but they do not yet support the newer revision of the SCCP protocol that allows for video. Therefore, SCCP video is not supported using traditional fix-up methods. If a firewall is in use, you must statically allow the TCP and UDP ports required, in the appropriate directions.

Protecting the Video Infrastructure

As with any infrastructure component of an IP Telephony deployment, you should protect the MCUs, gateways and gatekeepers from attack. Cisco IOS gatekeepers run the Cisco IOS software on standard Cisco router platforms. Therefore, follow best practices with respect to securing the router itself, including: TACACS+ and RADIUS authentication; turning off unnecessary services such as DHCP, TFTP, BOOTP, and HTTP; securing SNMP communications; and so forth. The IOS feature sets that provide the gatekeeper functionality (that is, the IP/H323 and Enterprise Plus/H323 MCU feature sets) support only Telnet and not Secure Shell (SSH). Cisco recommends that you use access control lists (ACLs) to control who is permitted to connect to the routers using Telnet, and that you always try to connect to the gatekeeper from a host that is in a secure segment of the network, because usernames and passwords are sent over Telnet in cleartext. Cisco IP/VC 3500 Series MCUs and gateways support the following forms of administrative access: • Telnet for viewing debug output • FTP for uploading new versions of software • HTTP for configuration and monitoring • SNMP for traps and alarms and some configuration and conference management functions These IP/VC devices do not support TACACS or RADIUS authentication, and only a limited number of administrative accounts can be configured locally in the device. Usernames and passwords are sent via cleartext in all Telnet, FTP, HTTP, and SNMP communications. Cisco recommends that you access these devices from a host that is in a secure segment of the network. You should also use firewalls, access control lists, Cisco Authentication Proxy, and other Cisco security tools to help protect these devices from unauthorized access.

Blocking Unauthorized Video Calls

One of the biggest challenges in securing H.323 videoconferencing is that, because H.323 is a peer-to-peer protocol, there is nothing stopping a user from typing an IP address and directly calling another H.323 device on the network, thus bypassing the Cisco CallManager and gatekeeper infrastructure put in place to manage access and bandwidth allocation. One very simple way to stop this unauthorized use is to deny H.323 clients the ability to initiate H.225 sessions with any device except Cisco CallManager. An access control list (ACL) can be an effective tool for managing this access. Because Cisco CallManager uses a random TCP port for H.225 trunks rather than the well-known default port of 1720, you could simply deny access to TCP port 1720 from the H.323 clients in the data VLAN, thereby blocking them from initiating H.225 sessions with each other

Cisco IP Video Telephony SRND 9562740406 10-3 Chapter 10 Security Blocking Unauthorized Video Calls

directly. The Cisco IP/VC 3500 Series MCUs listen on port 2720 by default, and the IP/VC 3500 Series gateways listen on port 1820 by default. Cisco recommends that you either change these devices to listen on port 1720 or add ACL rules to block H.323 clients from initiating connections to those ports directly.

Cisco IP Video Telephony SRND 10-4 9562740406

INDEX

consumption 4-2 Numerics for gatekeepers 4-9, 8-6 3500 Series Video Gateways 6-1 for video calls 1-6 7920 Wireless IP Phone 9-4 locations 1-6 802.1p 5-6 provisioning 5-5 802.1Q 5-6 request (BRQ) 4-10 requirements 4-1 bandwidth command 8-6 A B-Channel 6-7 AAR 1-4, 4-10, 6-5 Bearer Capabilities Information Element (bearer-caps) 6-10 access control list (ACL) 5-6, 5-8 bearer-caps command 6-10 ACF 4-9 binding of channels 6-7 ACL 5-6, 5-8 blocking unauthorized calls 10-3 additional information x BRQ 4-10 address resolution 3-7 bugs, reporting ix Admission Confirm (ACF) 4-9 busy-out channels 6-7 Admission Request (ARQ) 4-9 Aironet 9-3 alternate gatekeepers 8-7 C Alt-GK 8-7 applications 9-1 call admission control ARQ 4-9 described 4-1 assistance, obtaining ix gatekeeper zones 8-2, 8-5 Attendant Console 9-2 locations 1-6, 4-6 audio-only calls 1-4, 4-10 regions 4-4 automated alternate routing (AAR) 1-4, 4-10, 6-5 calling search space 3-5 CallManager (see Cisco CallManager) call processing B centralized 2-2 distributed 2-4 bandwidth calls allocation 4-1 audio-only 1-4, 4-10 call admission control 4-1 bandwidth consumed 4-2 call speed 4-2

Cisco IP Video Telephony SRND 9562740406 IN-1 Index

blocking 10-3 Class-Based Weighted Fair Queue (CBWFQ) 5-5 features supported 3-5 classification of traffic 5-2 flow between clusters 4-11 Class of Service (CoS) 5-2, 5-6 inbound 6-3, 6-8 clients 3-5 outbound 6-4, 6-9 clusters packet size 4-2 call admission control between clusters 4-7 routing 3-7, 6-3, 6-4, 7-7 call admission control within a cluster 4-4 scenarios 1-5 of gatekeepers 8-7 signaling 6-10 codecs 3-3, 3-5, 4-4 speed of 4-2, 4-3 collaboration solutions 9-3 types supported 1-3 Committed Information Rate (CIR) 5-5 capabilites of video devices 1-4 Common Intermediate Format (CIF) 3-3, 3-5 CAST 1-4, 10-1 components of IP Video Telephony 1-1 CBWFQ 5-5 compressed RTP (cRTP) 5-5 CDP 1-4, 3-1 Computer Telephony Integration (CTI) 1-2, 9-1 centralized call processing 2-2 conference resources 1-7, 7-1, 7-8 CER 9-1 console 9-2 changes for this release vii Contact Center 9-2 channels 4-1, 6-7 continuous-presence conference view 7-2 CIF 3-3, 3-5 CoS 5-2, 5-6 CIR 5-5 cRTP 5-5 Cisco.com viii CTI 1-2, 9-1 Cisco Aironet 9-3 customer support ix Cisco Audio Session Tunnel (CAST) protocol 1-4, 10-1 Cisco CallManager D Administration 1-4 current release vii data VLAN 10-1 enhancements for IP Video Telephony 1-2 deployment models new for this release vii described 2-1 redundant servers 3-7 multisite model with centralized call processing 2-2 Cisco Discovery Protocol (CDP) 1-4, 3-1 multisite model with distributed call processing 2-4 Cisco Emergency Responder (CER) 9-1 single site 2-1 Cisco IOS Gatekeeper 8-1 DHCP 3-5 Cisco IP SoftPhone 9-3 dial-in conferences 7-8 Cisco MeetingPlace 9-3 Differentiated Services Code Point (DSCP) 5-2 Cisco SAFE Blueprint 10-1 digit manipulation 6-4 Cisco Technical Assistance Center (TAC) ix distributed call processing 2-4 Cisco Wideband codecs 3-3 Cisco Wireless IP Phone 7920 9-4

Cisco IP Video Telephony SRND IN-2 9562740406 Index

documentation clustering 8-7 feedback viii described 8-1 obtaining viii, x for endpoints 8-2 ordering viii for intercluster trunks 8-5 related x IOS 8-1 DSCP 5-2 platforms supported 8-6 Dynamic Host Configuration Protocol (DHCP) 3-5 proxy 8-5 redundancy 8-7 registration 7-7 E required 2-1 ECS 1-2 routing calls 3-7 Emergency Responder 9-1 gatekeeper-controlled intercluster trunk 4-9 Empty Capabilities Set (ECS) 1-2 gatekeeper-controlled trunks 3-6, 4-9 enable/disable video 1-4 gateways endpoints automated alternative routing 6-5 capabilities 1-4 capabilities 6-10 classification of traffic 5-6 Cisco IP/VC 3500 Series Video Gateways 6-1 codecs supported 4-4 configuration in Cisco CallManager 6-9 described 3-1 described 6-1 features 3-5 digit manipulation 6-4 gatekeeper 8-2 prioritizing 3-8 H.323 3-5, 5-7 required 2-1 SCCP 3-1 service prefixes 6-4 Tandberg 3-4, 5-7 gw-priority command option 3-7 video 1-1 enhancements in Cisco CallManager Release 4.0 1-2 H

H.225 3-6, 4-9 F H.323 1-2, 3-5, 3-7, 5-7, 7-5 features supported by endpoints 3-5 history of revisions vii feedback on this document viii Hot Standby Router Protocol (HSRP) 8-7 firewalls 10-3 HSRP 8-7 flow of calls between clusters 4-11

I G ICT 2-4, 4-7, 8-5 gatekeeper inbound calls 6-3, 6-8 bandwidth 4-9, 8-6 interactive voice response (IVR) 7-8, 9-2

Cisco IP Video Telephony SRND 9562740406 IN-3 Index

intercluster trunk (ICT) 2-4, 4-7, 8-5 MCU 1-1, 7-1, 7-3, 7-5, 7-7 IOS Gatekeeper 8-1 media channels 4-1 IP/VC 3500 Series Video Gateways 6-1 Media Gateway Control Protocol (MGCP) 1-2 IP addresses 3-7 media resource group (MRG) 7-4 IPCC 9-2 media resource group list (MRGL) 7-4 IP Contact Center (IPCC) 9-2 MeetingPlace 9-3 IP IVR 7-8, 9-2 MGCP 1-2 IPMA 9-2 models for deployment (see deployment models) IP Manager Assistant (IPMA) 9-2 MP 7-1, 7-2 IPP 5-2 MRG 7-4 IP Precedence (IPP) 5-2 MRGL 7-4 IP SoftPhone 9-3 Multimedia Conference Manager (MCM) 8-1, 8-5 IP Video Telephony multipoint conferencing 7-1 components 1-1 Multipoint Controller (MC) 7-1 enhancements in Cisco CallManager 1-2 Multipoint Control Unit (MCU) 1-1, 7-1, 7-3, 7-5, 7-7 ISDN 6-7 Multipoint Processor (MP) 7-1, 7-2 IVR 7-8, 9-2 multisite deployment model with centralized call processing 2-2 multisite deployment model with distributed call J processing 2-4

JTAPI 1-2 N

L NAT 10-2 Network Address Translation (NAT) 10-2 LCR 6-7 new for this release vii least-cost routing (LCR) 6-7 non-gatekeeper controlled intercluster trunk 4-7 LFI 5-5, 5-6 Link Fragmentation and Interleaving (LFI) 5-5, 5-6 LLQ 5-5 O locations 1-6, 4-1, 4-6 outbound calls 6-4, 6-9 Low Latency Queuing (LLQ) 5-5

P M PA 9-2 Manager Assistant 9-2 packets marking traffic 5-2 queuing 5-4 MC 7-1 scheduling 5-4 MCM 8-1, 8-5 size 4-2

Cisco IP Video Telephony SRND IN-4 9562740406 Index

PC RTP 1-2 Access to Voice VLAN 3-1 SCCP 1-2, 3-1, 3-4, 7-3 port 3-1 SIP 1-2, 4-7 PerfMon 1-7 TAPI 1-2 performance monitor 1-7 TFTP 3-1, 10-1 per-hop behavior (PHB) 5-2 UDP 5-6 Per-Port/Per-VLAN ACLs 5-6, 5-7 provisioning bandwidth 5-5 Personal Assistant (PA) 9-2 proxy 8-5 PHB 5-2 phones Q security settings 10-2 with VT Advantage 1-1, 3-1 QCIF 3-3, 3-5 platforms that support a gatekeeper 8-6 QoS 5-1 policing traffic 5-8 Quality of Service (QoS) 5-1 ports Quarter Common Intermediate Format (QCIF) 3-3, 3-5 enable/disable 3-1 queuing of packets 5-4 for call signaling 6-10 for classifying traffic 5-6 R for VT Advantage 5-6

PC connection 3-1 Rate Matching (RM) module 7-3 PQ 5-5 Real-Time Monitoring Tool (RTMT) 1-7 precedence settings for video traffic 5-2 Real-Time Transport Protocol (RTP) 1-2 prefixes redundancy service 6-4, 7-6 for Cisco CallManager servers 3-7 technology 8-3, 8-5 for gatekeepers 8-7 zones 8-3, 8-5 regions 1-6, 4-4, 4-5 priority order for gateway selection 3-8 registering with the gatekeeper 7-7 priority queue (PQ) 5-5 releases of software vii problems, reporting ix request for technical service ix protocols Retry Video Call as Audio 1-4, 4-10 CAST 1-4, 10-1 revision history vii CDP 1-4, 3-1 RM 7-3 cRTP 5-5 rollover of channels 6-7 features supported 1-3 routing H.225 3-6, 4-9 calls 3-7, 7-7 H.323 1-2, 3-5, 3-7, 5-7, 7-5 inbound calls 6-3 HSRP 8-7 least-cost 6-7 JTAPI 1-2 outbound calls 6-4 MGCP 1-2

Cisco IP Video Telephony SRND 9562740406 IN-5 Index

RTMT 1-7 Survivable Remote Site Telephony (SRST) 2-2, 2-4 RTP 1-2

T S T.120 application sharing 9-3 SAFE 10-1 T-1000 3-4 SCCP 1-2, 3-1, 3-4, 7-3 T-550 3-4 scheduling of traffic 5-4 TAC ix security 10-1 Tandberg endpoints service classification of traffic 5-7 prefix 6-4, 7-6 described 1-1, 3-4 submitting a request ix TAPI 1-2 template 7-6 TCP/UDP ports 5-6 serviceability 1-7 TCS 1-5, 4-12 Service Level Agreement (SLA) 5-5 technical assistance ix Session Initiation Protocol (SIP) 1-2, 4-7 Technical Assistance Center (TAC) ix severity level of service request ix technology prefix 8-3, 8-5 shaping traffic 5-5 templates to define service settings 7-6 sharing applications 9-3 Terminal Capabilities Set (TCS) 1-5, 4-12 signaling 6-10 TFTP 3-1, 10-1 Simple Network Management Protocol (SNMP) 1-7 timers for call signaling 6-10 single-site deployment model 2-1 traffic SIP 1-2, 4-7 classification 5-2 sizing the MCU 7-7 policing 5-8 Skinny Client Control Protocol (SCCP) 1-2, 3-1, 3-4, 7-3 scheduling 5-4 SLA 5-5 shaping 5-5 SNMP 1-7 Trivial File Transfer Protocol (TFTP) 3-1 SoftPhone 9-3 trunks software versions vii gatekeeper 8-5 speed of calls 4-2, 4-3 gatekeeper-controlled 3-6 SRST 2-2, 2-4 gatekeeper-controlled intercluster trunk 4-9 subnets 8-4 H.225 3-6 support ix H.225 gatekeeper-controlled trunk 4-9 supported intercluster 2-4, 4-7 call features 3-5 non-gatekeeper controlled intercluster trunk 4-7 call types 1-3 SIP 4-7 codecs 3-3, 3-5, 4-4 trust of traffic classifications 5-2 protocol features 1-3 protocols 1-2

Cisco IP Video Telephony SRND IN-6 9562740406 Index

U Z

UDP 5-6 zone bandwidth command 4-1 (UDP) 5-6 zone prefix command 3-7 zones for a gatekeeper 8-2, 8-5 V prefixes 8-3, 8-5 VAD 7-2 subnets 8-4 versions of software vii video bandwidth 1-6 capabilities 1-4 devices 1-4 enable/disable 1-4, 3-1 endpoints 1-1, 1-4 packet size 4-2 video telephony (see IP Video Telephony) VLAN 5-6, 10-1 voice-activated conference view 7-2 voice activity detection (VAD) 7-2 voice VLAN 10-1 VT Advantage classification of traffic 5-6 described 3-1 phone settings for 1-4

W

Wait for Far-End to Send TCS 1-5, 4-12 wideband codecs 3-3 Wireless IP Phone 7920 9-4 wireless networking solutions 9-3

X

XML services 9-4

Cisco IP Video Telephony SRND 9562740406 IN-7 Index

Cisco IP Video Telephony SRND IN-8 9562740406