CCIE Voice v3.0 Quick Reference - داتیس آراد ...datis-arad.com/PDF/Cisco/Cisco Press CCIE Voice v3.0 Quick... · Several best practices are associated with these different

ptg999

ptg999

CCIE Voice v3.0 Quick Reference

Table of Contents

Chapter 1 Cisco Unified Communications Manager ....................................................3

Chapter 2 Understanding Quality of Service ...... 42

Chapter 3 Telephony Protocols ............................. 69

Chapter 4 Cisco Unity/Unity Connection ...........101

Chapter 5 IOS IP Telephony Skills ......................115

Chapter 6 IP Interactive Voice Response/ Unified Contact Center Express .......141

Chapter 7 UC Security .........................................151

Chapter 8 Infrastructure Protocols ....................163

Chapter 9 Application Protocols .........................167

Chapter 10 Operations and Network Management ........................................173

Mark Lewis

ciscopress.com

ptg999

[ 2 ]

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright. Please see page 178 for more details.


About the AuthorMark Lewis, CCIE No. 6280, is a consultant who specializes in next-generation/advanced network technologies and has extensive experience designing, deploying, and migrating large-scale data center, IP/MPLS networks, and unified communications solutions. He is an active participant in the IETF, a member of the IEEE, and a Certified Cisco Systems Instructor (CCSI).

Mark is the author of the Cisco Press titles Comparing, Designing, and Deploying VPNs (ISBN 1-58705-179-6) and Troubleshooting Virtual Private Networks (ISBN 1-58705-104-4). Mark can be contacted at [email protected].

About the Tech EditorJoshua Reola is a Systems Engineer with Cisco Systems specializing in Unified Communications, Video, and Digital Media Suite technologies. With 4 years working with Cisco, Joshua has also worked in various telecommunications fields and carried various IT positions for nearly 10 years. When not studying for the CCIE Voice Certification, Joshua enjoys traveling, volunteering, college football, basketball, and trying new things such as EMT training and photography.

ptg999

[ 3 ]



Chapter 1

Cisco Unified Communications Manager

Cisco Unified Communications Manager (CUCM) is an IP telephony call-processing solution. It provides distributed, scalable enterprise call processing and IP telephony features for IP phones, Voice over IP (VoIP) gateways, and multimedia applications and devices.

CUCM can be deployed using several different models, as shown in Figure 1-1:

■ Single site: In this model, CUCM provides call processing at a single site, with no telephony being implemented over an IP WAN.

■ Multisite WAN with centralized call processing: In this case, CUCM is deployed at a central site, and it provides call processing for a number of sites, with VoIP/IP telephony traffic being carried over an IP WAN between sites.

■ Multisite WAN with distributed call processing: When using this model, call-processing agents such as CUCM are deployed at multiple sites, with VoIP/IP telephony traffic being transported over an IP WAN between sites.

■ Clustering over the IP WAN: This involves deploying a single CUCM cluster with constituent CUCM servers spread across several sites connected by the WAN.

Several best practices are associated with these different types of deployment models.

Best practices for the single-site model include the following:

■ The single-site model is suited for enterprises where most calls are made to destinations within the same site or to the public switched telephone network (PSTN).

■ Deploy a highly available network infrastructure, with inline power, QoS, and security for phones.

[ 3 ]

ptg999

[ 4 ]


Chapter 1: Cisco Unified Communications Manager

■ Use the Media Gateway Control Protocol (MGCP) between CUCM and voice gateways (assuming H.323 functionality is not required).

■ Use the G.711 codec.

FIguRE 1-1CUCM Deployment Models

V

CiscoCallManager

PSTNV

CiscoCallManager

V

PSTN

V

WAN

CentralSite

Multisite WAN withCentralized Call Processing

Single Site

Remote Site

SRST SRST

Remote Site

V

CiscoCallManager

CiscoCallManager

CiscoCallManager

V

PSTN

V

WAN

CentralSite

Multisite WAN withDistributed Call Processing

Remote Site Remote Site

ptg999

[ 5 ]



Best practices for the multisite WAN with centralized call-processing model include the following:

■ Consider the factors that typically motivate the decision to deploy this model (or the multisite WAN with distributed call-processing model), including WAN bandwidth, delay limitations, scalability, management, cost, features, and so on.

■ Use CUCM locations for call admission control (CAC).

■ Consider deploying Survivable Remote Site Telephony (SRST). For Skinny Client Control Protocol (SCCP) phones, use SRST or Cisco Unified Communications Manager Express (CME) in SRST mode, and for Session Initiation Protocol (SIP) phones, use SIP SRST. If you are using MGCP phones, use MGCP gateway fallback.

■ Minimize delay between CUCM and remote sites as much as possible.

Best practices for the multisite WAN with distributed call-processing model include the following:

■ Follow general guidelines for the single-site and multisite WAN with centralized call-processing models, in addition to other specific best practices for this model.

■ Use H.323 gatekeepers for CAC and dial plan resolution. Alternatively, use SIP proxies for dial plan resolution.

■ Ensure high availability for gatekeepers by using mechanisms such as Hot Standby Router Protocol (HSRP) gatekeeper pairs, gatekeeper clustering, and redundancy using multiple gatekeepers. Similarly, if you are using SIP proxies, ensure that there is redundancy for these devices.

Best practices for clustering over the IP WAN include the following:

■ If you have between two and four sites, consider a local failover deployment model, with CUCM subscriber and backup servers at the same site with no WAN between them.

■ If you have up to eight sites, consider a remote failover deployment, with CUCM subscribers backed up by subscribers at another site.

■ Ensure that the maximum one-way delay between CUCM server does not exceed 40 milliseconds (80 milliseconds round-trip).

ptg999

[ 6 ]



■ Minimize jitter, congestion, and packet loss for Intra-Cluster Communication Signaling (ICCS).

■ Provision bandwidth between servers in accordance with expected call volume and device types/numbers.

During (at least) the initial deployment phase for CUCM, CUCM commonly must coexist with a traditional PBX infrastructure.

There are two common approaches to migration from a PBX infrastructure to IP telephony:

■ Phased migration: In this case, there is a small initial IP telephony deployment, and connectivity between CUCM and the PBX is provided via a VoIP gateway, using T1/E1 CAS/analog or T1/E1 PRI.

The signaling protocol chosen for connectivity can include regular PRI, QSIG PRI, SIP, or H.323. QSIG allows the greatest level of feature transparency between CUCM and PBX.

The migration itself takes place in several phases, with users being gradually moved over from the PBX to CUCM.

■ Parallel cutover: This migration approach involves the deployment of a complete, parallel IP telephony infrastructure, including the placement of a second (IP) phone on each user’s desk. The legacy PBX and infrastructure can be left in place until the IP telephony infrastructure is proven to operate correctly and users have developed a high degree of confidence in it.

Codecs and RegionsIn a VoIP network, calls typically have to transit both LAN links, where bandwidth is usually abundant, and WAN links, where it usually is not. Different codecs often have different associated bandwidth requirements, and in CUCM, it is possible to specify which type of audio and video codecs should be used when voice traffic transit links between different parts of the network using a mechanism called regions.

One method of implementing CAC with CUCM is to use locations. Locations CAC is dependent on regions because regions control the particular codec and the amount of bandwidth that needs to be allocated for a call when voice traffic crosses the network. Locations CAC is described in the section, “Call Admission Control,” later in this e-book.

ptg999

[ 7 ]



As shown in Figure 1-2, you can configure and modify regions within CUCM Administration by navigating to System, Region.

You use regions to specify the codec and maximum video bandwidth that can be used on calls between devices. Every device is in a region, and you assign a device to a region by specifying a region within a device pool and then assigning the device pool to a device.

The default codec for audio calls is G.711, so if this is the only codec used in a network, it is not necessary to configure regions.

FIguRE 1-2Region Configuration

ptg999

[ 8 ]



Redundancy: CuCM groups and Device PoolsTwo methods of configuring call-processing redundancy in Cisco CUCM deployments are CUCM groups and device pools. These concepts are explored in this section.

Cisco CuCM groupsCisco CUCM groups can specify a prioritized list of up to three CUCMs with which Cisco IP phones can register. It is possible for a CUCM server to be in more than one group.

The operation of the CUCM group is straightforward: During initialization, Cisco IP phones download a configuration file from a TFTP server, and this configuration file contains the prioritized list of CUCMs.

Cisco IP phones first attempt to register with the primary CUCM in the list, and if this fails, they attempt to register with the secondary CUCM. Finally, they attempt to register with the tertiary CUCM.

During normal operation, if a CUCM fails, Cisco IP phones fail over to (reregister with) the secondary/tertiary CUCMs in the group. Active calls are preserved, and Cisco IP phones reregister when existing calls are complete.

CUCM groups are associated with devices via a device pool. (Each device pool has an associated CUCM group, and each device is associated with a device pool.)

You can configure CUCM groups with Cisco CUCM Administration by navigating to System, Cisco Unified CM Group. Figure 1-3 shows the configuration of a CUCM group.

Note that the Auto-registration Cisco CUCM Group check box ensures that Cisco IP phones that autoregister receive the CUCM group assignment shown. Only one CUCM group can be used for autoregistration per cluster.

If a CUCM group is associated with a device pool, or if a CUCM group is used for autoregistration, it cannot be deleted.

ptg999

[ 9 ]



Device Pools and Common Device ConfigurationA device pool is a simple method of configuring the same parameters for a set of devices, such as Cisco IP phones. So, if you want to apply the same parameters for several Cisco IP phones, it is usually much easier to use a device pool to do this than to individually assign those parameters to each phone. Once you assign a device to a device pool, it inherits those parameters configured for the device pool.

You can configure device pools within Cisco CUCM Administration by navigating to System, Device Pool.

FIguRE 1-3Configuration of a Cisco CUCM Group

ptg999

[ 10 ]



Common device configuration consists of user-specific services and feature parameters. You can specify common device configuration parameters by navigating to Device, Device Settings, Common Device Configuration.

Numerous individual parameters can be configured within a device pool, including the following:

■ Device Pool Name: The name of the device pool.

■ Cisco CUCM Group: A prioritized list of CUCMs.

■ Calling Search Space for Auto-Registration: Defines calling restrictions for phones that autoregister with CUCM.

■ Adjunct CSS: Ensures that emergency dialing is supported when cross-cluster Extension Mobility is used.

■ Revert Call Focus Priority: Determines whether reverted or incoming calls are answered when a phone is answered.

FIguRE 1-4Configuration of a Device Pool

Figure 1-4 shows the configuration of a device pool.

ptg999

[ 11 ]



■ Local Route Group: Helps with the creation of dial plans when using multisite clusters.

■ Intercompany Media Services Enrolled Group: Used when the Intercompany Media Engine (IME) is implemented.

■ Date/Time Group: Specifies the time zone in which a device is located.

■ Region: Defines the codecs used when traffic transits between different parts of the network.

■ Media Resource Group List: Media resources, such as transcoding and conferencing resources, that are available to a device.

■ Location: Used with CAC.

■ Network Locale: Specifies the tones and cadences associated with a device.

■ Survivable Remote Site Telephony (SRST) Reference: The device with which phones should register if they are unable to communicate with CUCM.

■ Connection Monitor Duration: The length of time before a phone that is using SRST fails back to a CUCM after it has become available again.

■ Single Button Barge: Controls whether barge or cbarge is invoked when a single button is pressed.

■ Join Across Lines: Controls whether a user can add calls on separate lines into an ad-hoc conference.

■ Physical Location: Determines the physical location of a device.

■ Device Mobility Group: Specifies the device mobility group to which the device belongs.

■ Device Mobility Calling Search Space: When a device is roaming, this specifies the calling search that is used.

■ AAR Calling Search Space: Defines the automated alternate routing (AAR) calling search space (CSS).

■ AAR Group: The AAR group to which the device belongs.

■ Calling Party Transformation CSS: Can modify the number used as the caller ID.

ptg999

[ 12 ]



■ Called Party Transformation CSS: Allows you to change the number dialed.

■ Geolocation: Specifies a geolocation.

■ Geolocation Filter: Controls which fields are used to create a geolocation identifier.

■ Incoming Called Party Settings: Allows the addition or stripping of digits for national, international, and subscriber numbers.

Some additional parameters can be configured under Common Device Configuration:

■ Network Hold MoH Audio Source: Music audio that a device user hears when, for example, his call is transferred.

■ User Hold MoH Audio Source: Music audio that a device user hears when he presses the Hold button on a phone.

■ User Locale: Defines the language and fonts associated with a device.

■ MLPP Indication: Multi-Level Precedence and Preemption (MLPP) Indication specifies whether a tone is played when a device makes or receives a precedence call.

■ MLPP Preemption: Specifies whether a higher-precedence call can preempt a lower-precedence call.

■ MLPP Domain: The MLPP domain associated with the device pool.

Dial PlanA dial plan consists of a number of rules that CUCM uses to determine how it routes calls. A dial plan involves elements such as gatekeepers/gateways, SIP proxies, route patterns, route groups, route lists, digit manipulation, and digit analysis.

ptg999

[ 13 ]



gatekeeperThere are several methods of providing communication between CUCM clusters, the PSTN, PBXs, and other telephony networks, including the following:

■ Non-gatekeeper–controlled intercluster trunks

■ Gatekeeper-controlled intercluster trunks

■ Gatekeeper-controlled H.225 trunks

■ SIP trunks

Non-gatekeeper–controlled intercluster trunks are relatively straightforward. They are used in distributed networks where there are no gatekeepers, and involve the configuration of trunk connections between the local CUCM cluster and each remote CUCM cluster. The fact that separate trunks are required between the local CUCM cluster and each remote cluster when using non-gatekeeper–controlled intercluster trunks leads to a proliferation of trunks if there are a large number of clusters.

Gatekeeper-controlled intercluster trunks and gatekeeper-controlled H.225 trunks are described in this section, and SIP trunks are detailed in the next section.

The implementation of gatekeeper-controlled intercluster trunks is a more scalable method of provisioning intercluster communication than non-gatekeeper–controlled intercluster trunks, because separate trunk connections are not required for each remote CUCM cluster.

Gatekeepers are devices that can provide functions including admission control, bandwidth control, zone management, and address resolution. Gatekeeper-controlled communication can be implemented by configuring either of the following:

■ Gatekeeper-controlled intercluster trunks: Provide connectivity between CUCM clusters in a distributed call-processing network

■ Gatekeeper-controlled H.225 trunks: Provide connectivity to Cisco CUCM clusters and H.323 networks

ptg999

[ 14 ]



You can configure gatekeeper-controlled intercluster trunks in Cisco CUCM Administration by going to Device, Gatekeeper, adding a gatekeeper, and then navigating to Device, Trunk to configure an intercluster trunk. You must also configure the gatekeeper itself.

Figure 1-5 and Figure 1-6 show the configuration of a gatekeeper and gatekeeper-controlled trunk on a CUCM.

FIguRE 1-5Configuration of a Gatekeeper on CUCM

ptg999

[ 15 ]



The following example shows a basic configuration for a Cisco IOS gatekeeper:

gatekeeper zone local mjlgk mjlnet.com 10.1.1.1 zone prefix mjlgk 345* gw-type-prefix 1#* default-technology bandwidth total zone mjlgk 1024 bandwidth session zone mjlgk 128 no shutdown

In the example, the gatekeeper command is used to enter gatekeeper configuration mode.

FIguRE 1-6Configuration of a Gatekeeper-Controlled Trunk

ptg999

[ 16 ]



The zone local gatekeeper-name domain-name [ras-IP-address] command is then used to configure the zone controlled by the gatekeeper. In this example, the name of the domain served by the gatekeeper is mjlnet.com, the gatekeeper’s name is mjlgk, and 10.1.1.1 is a local address used as a source IP address for RAS packets.

Next, the zone prefix gatekeeper-name e164-prefix command is used to specify the gatekeeper’s name and add a prefix to the gatekeeper’s zone list. In this case, all prefixes beginning with digits 345 are associated with the gatekeeper mjlgk. Note that the asterisk (*) is a wildcard that represents one or more digits (0[nd]9). The dot (.) wildcard (not shown) can be used to match one digit (0[nd]9).

The gw-type-prefix type-prefix [default-technology] command specifies a default technology prefix (1#*), which is used to route calls if the called number does not correspond with a registered E.164 address.

After gw-type-prefix is the bandwidth total zone zone-name bandwidth-size command. This command configures the maximum aggregate bandwidth for H.323 traffic within the zone, which, in this case, is 1024 Kbps.

Next, the bandwidth session zone zone-name bandwidth-size command is used to configure the maximum bandwidth available for a session in the zone, which, in this example, is 128 Kbps.

Zone bandwidth can be calculated as follows:

Zone bandwidth = 2 * Total calls * Codec (payload) bandwidth

Finally, the no shutdown command activates the gatekeeper.

H.323 control messages used to facilitate CAC when using gatekeeper-control intercluster trunks are described in the section, “H.323: H.225, H.245, RAS,” later in this e-book.

Session Initiation Protocol ProxyThe Session Initiation Protocol (SIP) is a peer-to-peer signaling protocol described in many RFCs (most notably 3261) that allows the setup, modification, and termination of sessions between participants. SIP is described in more detail in the section, “SIP,” later in this e-book. This section describes only the integration of Cisco CUCM with SIP networks via SIP trunks.

ptg999

[ 17 ]



Beginning in Cisco CUCM version 4.x, SIP trunks can be used for connectivity with SIP networks and devices via SIP proxy servers. SIP proxy servers serve as intermediaries that route SIP requests, authenticate and authorize users, implement policies, and provide features.

To configure a SIP trunk in Cisco CUCM Administration, you must navigate to Device, Trunk, SIP Trunk. Figure 1-7 shows the configuration of a SIP trunk.

FIguRE 1-7SIP Trunk Configuration

ptg999

[ 18 ]



Route PatternsEssentially, call routing is the process of directing calls toward a destination.

A route pattern can consist of one or more digits and is a set of numbers (possibly including wildcards) that CUCM matches against a dialed number. For example, a route pattern could match 1234 or it could match 1XXX, where each X corresponds to any single digit (between 0 and 9).

A route pattern can point directly to a gateway, or it can point to a route list (route lists are described later in this section). It will match a specific dialed number or range of numbers and will direct calls with these dialed numbers to a gateway or route list. Alternatively, a route pattern can be configured to block calls with a specific dialed number or range of numbers.

You can configure route patterns by going to Route Plan, Route/Hunt, Route Pattern in Cisco CUCM Administration. Figure 1-8 shows the configuration of a route pattern.

FIguRE 1-8Route Pattern Configuration

ptg999

[ 19 ]



The following are the main elements of the Route Pattern Configuration page:

■ Pattern Definition

■ Calling Party Transformations

■ Connected Party Transformations

■ Called Party Transformations

■ ISDN Network-Specific Facilities Information Element

Specific configuration under the Pattern Definition heading includes the following:

■ Route Pattern: The route pattern itself.

Many wildcards can be used in the route pattern, including

X : Any single digit (0 to 9, * and #)

@ : North American Numbering Plan (NANP)

! : One or more digits (0 to 9, * and #)

[x-y] : Range between x and y

[^x-y] : Exclude range between x and y

. : Access code termination

# : Interdigit timeout termination

<wildcard>? : Zero or more occurrences of any digit that matches the wildcard

<wildcard>+ : One or more occurrences of any digit that matches the wildcard

\+ : The + character in a number

ptg999

[ 20 ]



■ Route Partition: The partition in which the route pattern is placed.

A partition specifies a grouping of directory numbers (DN) and route patterns, and it can restrict the access to those DNs and route patterns.

An associated concept, a calling search space, specifies an ordered list of partitions that a device, such as a Cisco IP phone, can call. (Digit analysis is permitted on DNs/route patterns within those partitions.)

■ Description: A description for the route pattern.

■ Numbering Plan: The relevant numbering plan.

■ Route Filter: A route filter that may be used to restrict number patterns.

Route filters allow you to limit the matches for route patterns that use the @ wildcard. The @ wildcard is a macro that adds route patterns corresponding to the complete numbering plan for a country to the call routing database (166 route patterns, assuming the NANP).

If you configure the route pattern 9.@, it is possible with a route filter to limit the matches on this pattern to those numbers that, for example, contain (or do not contain) an area code or a country code. It is also possible to be more specific. For example, you could use a route filter to specify that matches on the route pattern must not only contain an area code, but that the area code must be 555.

Route filters can be configured by going to Route Plan, Route Filter in Cisco CUCM Administration.

■ MLPP Precedence: Applicable Multi-Level Precedence and Preemption setting.

■ Resource Priority Namespace Network Domain: Here, you can choose a Resource Priority Namespace Network Domain from a drop-down box.

■ Gateway or Route List: The gateway or route list toward which calls matching this route pattern will be sent.

■ Route Option: Dictates whether to route or block calls matching this route pattern.

■ Call Classification: Specifies whether calls matching this pattern are OffNet or OnNet.

ptg999

[ 21 ]



■ Allow Device Override: If this box is checked, CUCM uses the Call Classification setting to determine whether an outgoing call is OffNet or OnNet.

■ Provide Outside Dial Tone: If this box is checked, an outside dial tone is provided.

■ Allow Overlap Sending: If this box is checked, when CUCM routes a call to the PSTN it relies on overlap sending in the PSTN to work out the number of digits to collect and where the call should be routed.

■ Urgent Priority: If this box is checked, interdigit timing can be interrupted and a call is routed immediately.

■ Require Forced Authorization Code: Enables the use of forced authorization codes with the route pattern.

■ Authorization Level: Determines the minimum authorization level that allows the successful routing of a call using this route pattern.

■ Require Client Matter Code: Enables the use of client matter codes with the route pattern.

Configuration under the Calling Party Transformations heading includes the following:

■ Use Calling Party’s External Phone Number Mask: Enables the use of the full external phone number as the calling line ID (CLID).

■ Calling Party Transform Mask: A transform mask value can be configured here for the calling party number.

■ Prefix Digits (Outgoing Calls): Prefix digits can be specified here.

■ Calling Line ID Presentation: Allows the selection of whether to allow or restrict the display of the calling party’s phone number.

■ Calling Name Presentation: Allows the selection of whether to allow or restrict the display of the calling party’s name.

■ Calling Party Number Type: Allows you to choose the format of the number type in the calling party’s directory numbers.

■ Calling Party Numbering Plan: Allows you to select the format of the numbering plan in the calling party’s directory numbers.

ptg999

[ 22 ]



Configuration under the Connected Party Transformations heading consists of the following:

■ Connected Line ID Presentation: Allows the selection of whether to allow or restrict the display of the connected party’s phone number.

■ Connected Name Presentation: Allows the selection of whether to allow or restrict the display of the connected party’s name.

Next, configuration under Called Party Transformations includes the following:

■ Discard Digits: Allows the selection of discard digit instructions for the route pattern. The type of discard digit instructions that are available depends on the numbering plan that was selected.

■ Called Party Transform Mask: A transform mask for the called party number can be configured here.

■ Prefix Digits (Outgoing Call): Prefix digits can be entered here.

■ Called Party Number Type: Here, select the format of the number type in the called party’s directory numbers.

■ Called Party Numbering Plan: Allows you to select the format of the numbering plan in the called party’s directory numbers.

Configuration under ISDN Network-Specific Facilities Information Element includes the following:

■ Carrier Identification Code: Allows the specification of a carrier identification code.

■ Network Service Protocol: An appropriate PRI protocol can be selected here.

■ Network Service: A suitable network service can be selected here.

■ Service Parameter Name: Displays the service parameter name associated with the network service.

■ Service Parameter Value: A suitable service parameter value can be configured here.

ptg999

[ 23 ]



Route groupsRoute groups are prioritized groupings of gateways through which calls can be routed.

You can configure route groups via Route Plan, Route/Hunt, Route Group in Cisco CUCM Administration (see Figure 1-9).

As shown in Figure 1-9, route group configuration options are as follows:

■ Route Group Name: The unique name for the route group.

■ Distribution Algorithm: The algorithm used to distribute calls via group members. There are two algorithms, top-down and circular, with the default algorithm being circular.

FIguRE 1-9Route Group Configuration

ptg999

[ 24 ]



After you select the route group name and distribution algorithm, it is possible to add devices (and ports) to the route group. It is also possible to change the priority of devices and remove devices that are already members of the route group.

Route ListsHaving examined the configuration of route patterns and route groups, it is now time to look at an associated concept: route lists.

Route lists are a method of configuring call routing via numerous route groups. So, route patterns can point to route lists, which in turn point to route groups. Route groups, as previously discussed, consist of gateways.

Figure 1-10 illustrates call routing via route patterns, route lists, route groups, and gateways.

FIguRE 1-10Call Routing via Route Patterns, Route Lists, Route Groups, and Gateways

Dialed Digits

Route Group 1

Route Group 2Route ListRoute Pattern

Route Group 3

ptg999

[ 25 ]



You can configure a route list via Route Plan, Route/Hunt, Route List. Figure 1-11 shows the Route List Configuration page.

FIguRE 1-11Route List Configuration

As shown in Figure 1-11, there are two configuration headings on the Route List Configuration page:

■ Route List Information: The route list name is configured here, along with a description and an associated CUCM group. The route list can either be enabled (the default) or disabled by checking or unchecking the provided box.

■ Route List Member Information: Under this heading, route groups can be added and be either associated or disassociated with the route list. Do this by selecting and moving them between the Selected Groups and Removed Groups boxes using the arrow buttons.

The route groups contained within the Selected Groups box are associated with the route list. Note that it is also possible to prioritize route groups associated with a route list by modifying the order in which they are displayed in the Selected Groups box by using the arrow buttons on the side.

ptg999

[ 26 ]



Digit ManipulationDigit manipulation is the process of modifying the called or calling party number. It can be configured in many different ways at the route pattern and route group level or by using the Translation Pattern Configuration screen in CUCM Administration.

Specific types of manipulation include the following:

■ Calling Party’s External Phone Mask: This modifies the calling party number (caller ID).

■ Calling Party Transform Mask: This can be used to further manipulate the digits for the calling party number (caller ID).

■ Prefix Digits: This can be used to prepend digits to a calling or called party number.

■ Discard Digits Instructions (DDI): This can be used to discard dialed digits, such as a leading 9 in outgoing calls.

■ Called Party Transform Mask: This can be used to change the called number.

Although digit manipulation can be done within a route group, it is applied when the route groups are added to a route list.

Although the configuration of digit manipulation at the route pattern and route group levels has already been discussed in earlier sections, note that you can also configure calling and called party transformation by navigating to Call Routing, Translation Patternwithin Cisco CUCM Administration.

Note that when digit manipulation is configured at both the route pattern and route group levels, the manipulation configured at the route group level has priority over that configured at the route pattern level because it is processed later.

Translation patterns have certain similarities to route patterns and can be used to manipulate the calling or called party numbers prior to call routing (matching a route pattern, DN, or even another translation pattern).

Translation patterns can also be used to modify other elements, such as calling search spaces.

ptg999

[ 27 ]



Digit AnalysisIf someone makes a call from a device registered with a CUCM, CUCM analyzes the dialed digits to correctly route the call.

As digits are dialed, CUCM matches the digits against the configured route patterns and determines a set of potential matches. These potential matches consist of route patterns that the digits dialed so far could potentially match.

If there are no potential matching route patterns for the dialed digits, the user receives a reorder tone, which indicates that the call cannot be routed.

CUCM attempts to match the dialed digits against the potential matches and, ultimately, against the closest matching route pattern.

If configured route patterns contain wildcards, it might sometimes be necessary for CUCM to wait for an interdigit timeout before routing a call. The wildcard ! in a route pattern indicates a variable-length string, and, therefore, CUCM is able to determine when the user has finished dialing a number only by waiting for a certain period to see whether the user will dial another digit. This period is known as the interdigit timeout.

In some situations, such as when users are dialing emergency services, it is not suitable to wait for the interdigit timeout to expire before routing a call. In this case, when you are configuring the route pattern corresponding to those numbers, you can check the box labeled Urgent Priority to ensure that the call is routed as soon as there is a match for these specific patterns.

Music on HoldMusic on Hold (MoH) is a feature that consists of streaming music provided when either a user presses the Hold button or softkey (this corresponds to the User Hold MoH Audio Source configuration), or when a user activates another feature, such as conference, transfer, or Call Park, that in turn causes call hold to be activated. (This corresponds to the Network Hold MoH Audio Source configuration.)

Media resources, including MoH servers, conference bridges, transcoders, and media termination points (MTP), can be added to media resource groups (MRG), and MRGs can then be specified according to priority in a media resource group list (MRGL). MRGs and MRGLs allow the sharing of resources across multiple CUCMs and the allocation of media resources to devices often on a geographic basis (local resources are used first, with remote resources used only as backup). Endpoints, such as Cisco IP phones, that

ptg999

[ 28 ]



require access to MoH servers (to hear an MoH stream) must have access to those MoH servers defined in MRGs/MRGLs.

MRGs can be configured by navigating to Media Resources, Media Resource Group in CUCM Administration. When configuring an MRG, you must define an MRG name and available media resources (such as MoH, MTP, and annunciator resources) for the MRG. You can also specify within the MRG configuration whether multicast can be used for MoH audio.

Media resources in an MRG are used in a round-robin fashion, with the exception of conference bridge resources, which are used based on the greatest number of resources available. It is possible to specify the same resource in more than one MRG.

Note that, by default, all media resources are placed in the null MRG, which is a MRG that exists even when no MRGs have been explicitly defined on the system.

MRGLs can be added by navigating to Media Resources, Media Resource Group List in CUCM Administration. When adding an MRGL, you must specify a name and add the required MRGs to the MRGL in the desired prioritized order. It is possible to assign the same MRG to more than one MRGL.

Once defined, MRGLs can be assigned to either devices or device pools.

MoH relies on the Cisco IP Voice Media Streaming Application. Cisco IP Voice Media Streaming Application also provides software annunciator, software conference bridge, and media termination point (MTP) resources. If the Cisco Media Streaming Application is running, these resources are automatically enabled.

Audio sources for MoH can be either live or recorded, and MoH streams can be either unicast or multicast in nature. A maximum of 51 audio sources can be configured within a CUCM cluster, and all MoH servers within the CUCM cluster rely on the same sources. There can be a total of 50 audio sources in the form of audio files, and 1 fixed audio source (audio source 51), which is usually a sound card installed in a server.

It is possible for MoH servers to support a maximum of 500 unicast MoH streams or 204 multicast audio streams. The exact number supported depends on factors such as the CPU and whether the server providing the MoH is a dedicated MoH server.

Multicast is often viewed as being an attractive method of transmitting MoH because of the reduced CPU overhead on the source device and reduced bandwidth consumption on the network.

ptg999

[ 29 ]



An MoH server can be either a publisher/subscriber or dedicated server within a CUCM cluster. MoH servers must register with CUCM, and they communicate with CUCM using SCCP.

Note that each multicast MoH stream relies on a separate audio source and that each audio source can supply a stream for the four codecs supported (G.711 mu-law, G.711 a-law, G.729, and wideband), giving the maximum number of multicast streams (204) from the maximum number of audio sources (51). When deploying MoH, it is important to ensure that endpoints can receive the codecs supported by the MoH server and that MoH streams using certain codecs are not inadvertently restricted because of the configuration of CUCM locations or regions.

You can add audio source files (in a WAV format) to a MoH server by navigating to Media Resources, Music on Hold Audio Source Files, and then clicking Add New, followed by Upload File.

You can configure a MoH server by navigating to Media Resource, Music on Hold Server, while MoH parameters, such as supported codecs, can be specified within the Service Parameters configuration.

The MoH audio file that an endpoint placed on hold hears is determined by the User Hold MoH Audio Source file of the device placing the call on hold, but the audio stream corresponding to that file is sourced from the MRGL resource or server of the endpoint placed on hold.

Conferencing: Audio and VideoConference bridges are software or hardware resources that allow the participation of multiple parties in a call.

CUCM can allocate registered software and hardware conference bridges when a conference is invoked by endpoints. Cisco audio conference bridges and certain IP/VC 3500 videoconference bridge models can communicate with CUCM using SCCP.

It is important to ensure that conference bridges are correctly specified in the appropriate MRG/MRGL so that they can be allocated as required by endpoints.

Hardware and software conference bridges can support ad-hoc conferences and MeetMe conferences. Ad-hoc conferences are those in which a user (the conference controller) calls other participants and adds them to the conference by pressing the Confrn softkey or pressing the Select softkey followed by the Join softkey on his Cisco IP phone.

ptg999

[ 30 ]



If participants cannot be added to an ad-hoc conference, this might be because of a number of issues, including that the phone in question is not associated with an MRGL, that the IP Voice Media Streaming Application service has not been started, or that the conference bridge is out of resources.

MeetMe conferences, in contrast, require a specific conference directory number (range) to be configured on CUCM in advance. The conference controller establishes the MeetMe conference by pressing the MeetMe button or softkey. Other participants in the MeetMe conference dial the number specified by the conference controller to join the conference.

Note that some Cisco IP phone models also have a built-in digital signal processor (DSP) and conference capability that allows conferencing with a maximum of three participants. This conferencing capability is enabled using the Barge softkey.

Hardware conference bridges enable conferencing by mixing participants’ audio streams using DSPs. They support a range of codecs, including G.711, G.729, and G.723. Hardware conference bridges that support multiple low-bit-rate codecs, such as G.729 or G.723, transcode between these codecs in a mixed-mode conference call.

Software conferences depend on CUCM’s Cisco IP Voice Media Streaming Application to mix participants’ audio streams, and they can support a smaller range of codecs, including G.711 and wideband codecs. If devices using other codecs want to participate in a conference call, a hardware transcoder is required to allow their participation.

The Cisco IP Voice Media Streaming Application on a standalone server supports up to 64 participants for ad-hoc conferences and up to 128 participants for a MeetMe conference.

Hardware conferences resources can include the following:

■ NM-HDV

■ NM-HDV2

■ NM-HD-1V/2V/2VE

■ PVDM/PVDM2/PVDM3

■ WS-SVC-CMM-ACT

ptg999

[ 31 ]



■ WS-X6608-T1/E1

■ IP/VC 3500 series (videoconference bridge)

Note that Cisco is constantly adding to its range of hardware conference resources.

Videoconference bridges support H.261, H.263, H.320, and so on. They can support a mix of users with video and audio endpoints. If the Cisco IP Voice Media Streaming Application service is running, no further configuration is necessary to take advantage of it as a conferencing resource.

Hardware conference bridges must be added via Cisco CUCM Administration by navigating to Media Resource, Conference Bridge.

TranscodingTranscoders enable devices using different codecs to communicate by converting a voice stream using one codec into a voice stream using another codec. If one device outputs and is able to process only a G.711 stream, and it has to communicate with another device that outputs and is able to process only a G.729 stream, this requires the use of a transcoder to convert between the G.711 and G.729 streams.

Cisco hardware transcoders can support several codecs, including G.711, G.723, G.729, and GSM. Cisco hardware transcoding resources include NM-HDV2, NM-HD-1V/2V/2VE, WS-SVC-CMM-ACT, NM-HDV, and WS-X6608.

You can configure transcoders in Cisco CUCM Administration by going to Media Resource, Transcoder.

Note that transcoders can also function as media termination points (MTP) and can provide supplementary services for H.323 endpoints where necessary. MTPs are described in the following section.

ptg999

[ 32 ]



Media Termination PointsAn MTP can bridge together two full-duplex voice streams, and (if necessary) convert between G.711 mu-law and a-law as well as different sample sizes. An MTP can also be used for dual-tone multifrequency (DTMF) conversion and for other specific protocol uses such as H.323 supplementary services, H.323 outbound fast connect, and SIP early offer.

Each of the voice streams that the MTP bridges together are set up and torn down independently of each other, thus allowing the H.323 supplementary services to be supported. If CUCM attempts to allocate an MTP but cannot, it attempts to directly connect the endpoints.

MTP can be used to provide supplementary service capabilities, such as hold, transfer, Call Park, and conferencing to H.323v1 devices that otherwise would not be able to support these features. H.323v1 devices cannot support these supplementary services natively because they lack support for the H323v2 OpenLogicalChannel and CloseLogicalChannel requests with Empty Capabilities Set (ECS).

Note that CUCM 4.x needs an RFC 2833-compliant MTP to make SIP calls using DTMF call signaling tones. An RFC 2833-compliant MTP translates between the out-of-band DTMF tones used by SCCP and SIP in-band (payload type) DTMF tones. CUCM 5.x and later remove the requirement for an MTP when supporting RFC 2833 DTMF. CUCM supports software MTPs using the Cisco IP Voice Media Streaming Application, Cisco IOS software MTPs, and hardware MTPs.

Software MTPs that are based on Cisco IP Voice Media Streaming Application support RFC 2833 DTMF relay and G.711; Cisco IOS software MTPs support G.711, G.729, G.729a, G.729b, G.729ab, and GSM, but with only one of these codecs configured at a time; and hardware MTPs support (depending on the specific hardware) G.711, G.729, and G.729b.

Software MTPs using the Cisco IP Voice Media Streaming Application support 48 MTP resources (by default), Cisco IOS software MTPs support 500 streams (250 transcoded sessions), and hardware MTPs support a variety of session totals, depending on specific hardware.

ptg999

[ 33 ]



Hardware MTPs include Cisco NM-HDV2, NM-HD-1V/2V/2VE (2800 and 3800 series routers), 2900 and 3900 with PVDM3, WS-SVC-CMM-ACT, and WS-X6608-T1/E1:

■ For NM-HDV2 and NM-HD-1V/2V/2VE (2800 and 3800 series routers), each DSP supports 16 G.711 sessions or 6 G.729, G.729b, or GSM sessions.

■ For 2900 and 3900 series routers with PVDM3, the PVDM3-16 supports 16 G.711 sessions, and the PVDM3-256 supports 256 G.711 sessions.

■ For WS-SVC-CMM-ACT, each DSP supports 256 G.711 sessions or 128 G.729, G.729b, or GSM sessions.

■ For WS-X6608-T1/E1, each MTP port supports 24 sessions (G.711, G.729, G.720b, or GSM).

You configure MTPs in CUCM Administration by navigating to Media Resource, Media Termination Point.

Depending on the type of CUCM deployment, MTP and transcoding resources might not be required.

In a single-site CUCM deployment, transcoding is not required, but MTP resources may be required if there are a large number of H.323v1 endpoints.

In a multisite WAN deployment with centralized CUCM call processing, MTP and transcoding resources are shared between CUCMs in the cluster at the central site using MRG/MRGLs. Placement of MTP and transcoding resources depends on where the endpoints that require these resources are located. Careful placement can ensure that media streams do not unnecessarily transit the WAN.

In a multisite WAN deployment with distributed CUCM call processing, MTP and transcoding resources are shared between CUCMs in the clusters using MRG/MRGLs. The use of MTP and transcoding resources is avoided and is used only when an application supports G.711 or there are H.323v1 endpoints.

CuCM FeaturesThis section describes CUCM features, including Extension Mobility, IP Manager Assistance (IPMA), Attendant Console, Call Park, and Pickup.

ptg999

[ 34 ]



Extension MobilityCUCM Extension Mobility enables users to log in to Cisco IP phones on which they want to make and receive calls. This capability ensures that users are not permanently tied to a specific phone, but can instead use any phone from which they can log in. When a user logs in to a phone, all user profile characteristics are assigned to that phone, including speed dialing, line appearance, calling privileges, message waiting indicator (MWI), and so on.

Extension Mobility is enabled using XML-based services, relies on the CUCM/Cisco Database Layer Monitor services, and runs as a Tomcat web service in order to function.

There are a number of steps involved in enabling Extension Mobility:

Step 1. Activate the Cisco Extension Mobility service in the Cisco CUCM Serviceability tool by going to Tools, Service Activation.

Step 2. Configure CUCM Extension Mobility service parameters, such as Maximum Login Time in CUCM Administration, by going to System, Service Parameters, selecting the server, and then selecting Cisco Extension Mobility from the Service drop-down list and clicking Save.

Step 3. Configure Extension Mobility service availability by going to Device, Device Settings, Phone Services.

Step 4. Create a user device profile and subscribe to the Extension Mobility service by going to Device, Device Settings, Device Profile. A user device profile consists of characteristics such as device type, phone button template, softkey

template, directory number, and login user ID. This profile information is used when a user logs in to a phone. Note that because the profile is specific to a device (phone) type, it will work only when a user logs in to that specific type of device.

Step 5. Associate the user with the profile by going to User Management, End User.

Step 6. Subscribe phones to the Extension Mobility service and configure Extension Mobility parameters by navigating to Device, Phone.

ptg999

[ 35 ]



IPMACisco IP Manager Assistance (IPMA) is an application that allows managers and assistants to work more efficiently together by allowing assistants to handle managers’ calls. When using IPMA, an assistant can manage calls and perform a variety of tasks, such as call transfer, answer, divert, and hold. An assistant uses a desktop client to monitor managers’ calls.

There are two different IPMA modes of operation: proxy-line support mode and shared-line support mode.

Proxy-line support mode is available in Cisco CallManager 3.3 and later. When using this mode, calls made to managers are intercepted and redirected to an assistant or targets based on call filters.

Proxy-line support mode requires the use of two call search spaces, three partitions, translation patterns, and route points, which can be configured using the Cisco IPMA Configuration Wizard. This wizard also creates templates for the IPMA manager phone, the IPMA assistant phone, and other phones using the Bulk Administration Tool (BAT).

CUCM 4.x supports additional functionality, such as barge, call join, and direct transfer.

Shared-line support mode is available in Cisco CUCM 4.0 and later. Shared-line support mode allows the manager and assistant to share a primary line (and directory number), and because of this, there is no requirement to configure call search spaces, partitions, translation patterns, and route points.

Call ParkCall Park is a relatively simple feature that enables one user to place a call on hold and another user to then retrieve that call.

To use Call Park, a user must press the Park softkey, a Call Park number is displayed, and a second user can then dial that number to retrieve the call.

You can configure Call Park by going to Call Routing, Call Park in Cisco CUCM Administration. It is possible to configure a single Call Park number or range of Call Park numbers.

ptg999

[ 36 ]



Call PickupCall Pickup allows several users to answer incoming calls as a group. If one member of a Call Pickup group receives a call, any member of that group can pick up the call.

There are several types of Call Pickup configuration, including the following:

■ Call Pickup: Allows users in a group to pick up calls received on any other phone within the group. Users press the Call Pickup button or PickUp softkey to take advantage of this feature.

■ Group Call Pickup: With this feature, users can accept calls from any call pickup group, including their own. Users press the Group Call Pickup button or Gpickup softkey and dial the group number to receive group calls.

■ Other Group Call Pickup: In this case, several groups are associated, and when a call is incoming, CUCM forwards the call to an associated group (assuming there is more than one associated group) in order of priority. Users press the OPickup softkey for other group Call Pickup.

You can configure a Call Pickup Group by going to Call Routing, Call Pickup Group in Cisco CUCM Administration.

Phone SettingsCisco CUCM supports a variety of phones. Their configuration and settings are described in this section.

Cisco IP PhonesCisco IP phones can be manually added in Cisco CUCM Administration (Device, Phone, Add New), they can be added using the Bulk Administration Tool (BAT), they can be added using the Tools for Autoregistration Phone Support (TAPS), or they can autoregister with CUCM.

ptg999

[ 37 ]



When configuring Cisco IP phones, it is possible to specify a large number of settings, including the following:

■ Device information (MAC address, calling search space, and so on)

■ Protocol specific information

■ Certificate authority proxy function (CAPF) information

■ Expansion module information

■ External data locations information

■ Extension information

■ Configuration file encryption symmetric key information

■ H.323 information

■ Gatekeeper information

■ Associated Mobility Identity

■ Associated Remote Destinations

■ MLPP information

■ Do not disturb (DND)

■ Secure Shell information

■ Associated information

■ Product-specific configuration layout

ptg999

[ 38 ]



Cisco IP CommunicatorCisco IP Communicator is an application that allows users to make and receive calls on their PC. To set up IP Communicator with CUCM 4.x, you must do the following (at a minimum):

Step 1. Ensure that CallManager/CUCM is at least version 4.0(1)sr2.

Step 2. Add a phone by going to Device, Phone, Add New in Cisco CUCM Administration. Select Cisco IP Communicator as the phone type.

Step 3. Specify required information, including items such as the MAC address. The MAC address is that of the NIC of the machine on which Cisco IP Communicator is installed.

Step 4. Add the directory number.

Step 5. Install Cisco IP Communicator software. Select audio devices, adjust the volume, choose the appropriate NIC, specify the IP address of the CUCM (TFTP server), and enter a username/password.

Directory NumbersDirectory numbers (DN) are assigned to phones and can be added and configured by navigating to Call Routing, Directory Number.

DN configuration includes the following:

■ DN information (number, partition, and so on)

■ DN settings (voicemail profile, calling search space, and so on)

■ AAR settings

■ Call forward and call pickup settings

■ MLPP alternate party settings

■ Line settings for all devices

ptg999

[ 39 ]



■ Line on device

■ Multiple call/call waiting settings on device

■ Forwarded call information on device

Softkey TemplatesSoftkeys add functionality to Cisco IP phones and are used with applications such as Cisco IPMA. Softkeys can be accessed by pressing buttons to the side and underneath the LCD on Cisco IP phones.

CUCM has a number of standard softkey templates, but it is also possible to create and assign nonstandard softkey templates by doing the following:

Step 1. Go to Device, Device Settings, Softkey Templates in Cisco CUCM Administration.

Step 2. Choose, copy, and rename a standard softkey template to use as the basis for the nonstandard softkey template.

Step 3. Configure the nonstandard softkey template by adding softkeys and modifying their positions.

Step 4. Assign the softkey template to a common device configuration and then assign the common device configuration to a phone, or assign the softkey template directly to the phone in phone configuration.

Computer Telephony Interface, Telephony Application Programming Interface, and Java Telephony Application Programming InterfaceComputer Telephony Interface/Integration (CTI) provides a connection between telephone systems and computers and allows them to take advantage of computer processing when managing phone calls. CTI integration with CUCM allows external applications to control call behavior.

ptg999

[ 40 ]



Telephony Application Programming Interface (TAPI) and Java Telephony Application Programming Interface (JTAPI) clients can interact with CUCM using CTI communication via CTIManager.

JTAPI is an object-oriented application programming interface (API) for Java-based telephony applications and supports telephony call control.

TAPI is a standard developed by Microsoft that allows Windows-based PCs to interface with telephony applications.

Cisco CTI applications include the following:

■ Cisco IP Auto-Attendant

■ Cisco CUCM Attendant Console

■ Cisco Softphone

■ Personal Assistant

■ Cisco WebDialer

Cisco Unity Express (CUE) also communicates with CUCM (but not Cisco Unified Communications Manager Express [CME]) using JTAPI and with CTI Quick Buffer Encoding (CTI-QBE) protocol. Other applications that rely on the CTIManager service include the Telephony Call Dispatcher (TCD) and the Tool for Auto-Registered Phones Support (TAPS).

CUCM uses TCP ports 2748 and 2789 for CTI/JTAPI communication.

CTIManager interfaces with applications, and communicates with CUCM using the System Distribution Layer (SDL). The CTIManager service relies on the Cisco Database Layer Monitor service.

CTIManager operates separately from CUCM, and it is possible to have more than one CTIManager active in a CUCM cluster, but only one instance on any given server. A JTAPI or TAPI application can have connectivity to more than one CTIManager but can use only one of those connections at a time.

If a CTIManager does fail, an application can fail over to another CTIManager assuming that the JTAPI application supports failover and, in the case of TAPI applications, the Cisco TAPI Service Provider is suitably configured.

ptg999

[ 41 ]



There are three different types of CTI control devices:

■ CTI ports: These virtual devices allow the creation of virtual lines.

■ CTI route points: These can receive many calls simultaneously for application-controlled redirection. They support numerous features, including answering calls, redirecting calls, holding calls, and dropping calls. Calls can be redirected to a CTI port or IP phone.

■ Cisco IP phones: A CTI application can control these phones.

CTI ports and route points are used by applications including Cisco Softphone, Cisco IP Interactive Voice Response (IVR), and Cisco Auto-Attendant. If a CTI device fails, media streams for calls that are already set up may be preserved, while calls that are in the process of being set up or modified are dropped.

ptg999

[ 42 ]



Chapter 2

Understanding Quality of Service

It is important to ensure that networks over which voice traffic is transported support tight quality of service (QoS) requirements in terms of delay, jitter, and packet loss.

There are many different types of delay, including the following:

■ Coder (or processing) delay: This is the time taken by a DSP to compress a block of PCM samples. Coder delay depends on the particular codec being used and processor speed.

■ Packetization delay: This is the time it takes to fill a voice packet payload with encoded or compressed speech and encapsulate it with Internet Protocol (IP), User Datagram Protocol (UDP), and Real-time Transport Protocol (RTP) headers.

■ Serialization delay: This is the time taken to send a frame out of a network interface.

■ Propagation delay: The time taken for a bit to traverse a network link (from one end to the other).

■ Queuing (buffer) delay: This is the delay experienced as a frame is queued waiting to be transmitted on a link.

■ Dejitter delay: This is the delay experienced as a dejitter buffer on a receiving device removes any variable delay (jitter) between packets before it plays out those packets.

QoS can be implemented using two different architectures: differentiated services (DiffServ, RFC 2475) or integrated services (IntServ, RFC 1633). The IntServ architecture implements flow-based guarantees and uses a signaling protocol to inform routers in the network path what level of service to provide for a particular flow. When deploying the IntServ architecture, the Resource Reservation Protocol (RSVP) can be used as the signaling protocol.

In the DiffServ architecture, packets are marked using a method that indicates to routers along the network path what level of service they should offer the packets. When deploying the DiffServ architecture, packets can be marked using fields such as the IP header

ptg999

[ 43 ]


Chapter 2: Understanding Quality of Service

Type of Service (ToS) Byte/Differentiated Service (DS) field, or the 802.1p bits in the 802.1Q Ethernet frame header.

To support tight QoS requirements, QoS tools and call admission control (CAC) mechanisms can be configured on Cisco network devices and CUCM servers.

QoS mechanisms and tools include those used for the following:

■ Link efficiency

■ Classification

■ Marking

■ Congestion management

■ Congestion avoidance

■ Traffic shaping

■ Traffic policing

CAC mechanisms include the following:

■ CUCM locations CAC

■ RSVP

■ Gatekeeper-controlled CAC

These tools and mechanisms are described in the following sections.

ptg999

[ 44 ]



Link EfficiencyLink efficiency mechanisms, such as link fragmentation and interleave (LFI) and compression, can alleviate issues involving excessive serialization delay for large data packets and issues involving scarcity of bandwidth on network links. In addition, a mechanism called Voice Activity Detection (VAD) can save bandwidth by ensuring that packets are not sent when a speaker is silent.

LFI, compression, and VAD are discussed in the following sections.

Link Fragmentation and InterleaveLFI mechanisms help ensure that voice packets are not unduly delayed by large data packets (because of the serialization delay incurred by those large packets) as they are transmitted across low-bandwidth links.

LFI reduces the delay experienced by smaller packets, such as voice, by breaking larger (data) packets into fragments and interleaving smaller voice packets with the fragments of these larger packets as they are queued for transmission on an interface. LFI is typically required on WAN links with bandwidths of 768 Kbps or less.

There are various methods of provisioning LFI, including Multilink PPP LFI and Frame Relay Forum 12 (FRF.12).

Multilink PPP LFI on Slow-Speed Leased Lines (768 Kbps or Less)Multilink PPP (MLP) LFI can be configured on either a single link or over several bundled links that are using Point-to-Point Protocol (PPP) encapsulation.

The following example shows a configuration for MLP LFI:

interface Multilink5 ip address 10.1.1.1 255.255.255.0 ppp multilink ppp multilink fragment delay 10 ppp multilink interleave ppp multilink group 5!interface serial 0/0

ptg999

[ 45 ]



bandwidth 256 no ip address encapsulation ppp load-interval 30 ppp multilink ppp multilink group 5

Important IOS commands shown in the example include the following

■ ppp multilink: Enables MLP

■ ppp multilink fragment delay: Configures the maximum packet size for MLP fragments (in units of time [milliseconds])

■ ppp multilink interleave: Enables interleaving of smaller packets with fragments of larger packets

■ ppp multilink group: Configures the interface to join the specified multilink group

Cisco recommends using MLP on links with bandwidth less than or equal to 768 Kbps, and you can optionally enable Compressed Real-time Transport Protocol (cRTP) using either the ip rtp header-compression command (under the multilink interface) or using the compress header ip rtp command, which is configured in a policy map that is then applied to the multilink interface, as shown in the following example:

policy-map slow-wan class voice-media priority percent 33 compress header ip rtp class call-signaling bandwidth percent 5!interface Multilink5 ip address 10.1.1.1 255.255.255.0 service-policy output slow-wan ppp multilink ppp multilink fragment delay 10 ppp multilink interleave ppp multilink group 5

ptg999

[ 46 ]



Frame Relay Forum 12 on Slow-Speed Frame Relay Links (768 Kbps or Less)Frame Relay Forum 12 (FRF.12) is similar to MLP LFI but operates on Frame Relay interfaces.

Cisco has a number of recommendations with regard to voice and Frame Relay:

■ Enable FRF.12 (fragment size for 10 ms) and cRTP for circuits less than or equal to 768 Kbps.

■ The committed information rate (CIR) should be set to 95 percent of the PVC contracted speed.

■ The committed burst (Bc) should be set to CIR/100 (nondistributed platforms) or CIR/125 (distributed platforms).

■ The excess burst (Be) should be set to 0.

The configuration of FRF.12 is quite different from that for MLP LFI, as shown in the following example (for a 768-Kbps circuit):

interface serial 1/0.10 point-to-point ip address 10.1.1.1 255.255.255.0 frame-relay interface-dlci 100 class frf-12!map-class frame-relay frf-12 frame-relay fragment 960

The frame-relay fragment command enables fragmentation and interleaving of Frame Relay frames and specifies the fragment size in bytes.

The following example uses the Modular QoS CLI (MQC), and is again for a 768-Kbps circuit:

policy-map fr-shaping class class-default shape average 729600 7296 0 service-policy slow-wan!map-class frame-relay slow-wan-class service-policy output fr-shaping frame-relay fragment 960

!interface Serial1/0 no ip address

ptg999

[ 47 ]



encapsulation frame-relay!interface Serial1/0.100 point-to-point ip address 10.1.1.1 255.255.255.0 frame-relay interface-dlci 100 class slow-wan-class

You can calculate the fragment size as follows:

Fragment size (bytes) = (PVC speed [Kbps] * Max allowed jitter [ms]) / 8

Using a maximum allowed jitter of 10 ms (the Cisco recommendation), the fragment size for a 768-Kbps PVC works out as 960 bytes.

Before finishing this section, note that MLP can also be used to enable fragmentation when deploying Frame Relay/ATM FRF.8 service interworking. In this case, Frame Relay and ATM networks are connected, and to help to ensure end-to-end QoS, packets can be sent across the connection using MLP over Frame Relay (MLPoFR) and MLP over ATM (MLPoATM).

MLPoFR and MLPoATM were introduced in IOS 12.1(5)T.

Compressed Real-Time Transport ProtocolcRTP compresses IP/UDP/RTP headers of packets as they are sent over low-speed links and therefore saves bandwidth. Cisco recommends enabling cRTP on low-speed WAN lines (less than or equal to 768 Kbps).

cRTP can be configured on an interface using the ip rtp header-compression command. cRTP must be enabled at both ends of the link.

cRTP can also be configured via the MQC using the compression header ip rtp command, as shown in the following example:

policy-map crtp-map class voice-traffic compression header ip rtp priority percent 30 class class-default fair-queue

More information about cRTP can be found in the section, “RTP and cRTP,” later in this e-book.

ptg999

[ 48 ]



Voice Activity DetectionDuring a normal telephone conversation, typically only one person speaks at a time, and occasionally, there will also be complete silence on the call (it usually constitutes between 35 percent to 50 percent of the call). Using VAD, when these periods of silence occur, instead of sending packetized silence across the network, no packets are sent.

As an average over a period of time, VAD can save up to 35 percent of bandwidth on a call volume of 24 calls or more.

One problem with VAD is that it can lead to a situation where participants in a call can come to believe that the call has been disconnected. This situation can be remedied by using comfort noise generation (CNG), which provides white noise and ensures that participants in a call do not believe that the call has been disconnected.

VAD can be enabled on a dial peer using the vad command (the default) and disabled using the no vad command.

It is possible to configure VAD in CUCM by navigating to Service, Service Parameters, selecting the publisher, and then choosing the CUCM service. The SilenceSuppressionSystemWide and SilenceSuppressionWithGateways parameters control VAD settings for SCCP endpoints and MGCP gateways, respectively.

Classification and MarkingClassification is the process by which routers, switches, or other devices identify packet or frame types. Classification can be based on a variety of criteria, such as protocol and port, and usually occurs (in depth) at the network edge (QoS trust boundary).

After packet types are identified, they can be given a marking so that other network devices do not have to reclassify them in depth. (They do not have to reexamine IP addresses, TCP/UDP ports, and so on.) Packets can be marked using fields such as the ToS Byte or Differentiated Services (DS) fields in the IP header, the 802.1p field in the 802.1Q tag, and so on. Marking typically also occurs at the network edge.

Routers and switches might offer preferential QoS treatment in terms of queuing, assignment of bandwidth, selective dropping, and so on based on packet and frame markings.

Figure 2-1 shows the 802.1Q tag and 802.1p field.

ptg999

[ 49 ]



FIguRE 2-1802.1Q Tag and 802.1p Field

802.1Q Preamble (8)Frame:

DestinationAddress (6)

SourceAddress (6)

TPID(2)

TCI(2)

Type/Length

(2)FCS (2)Data

UserPriority (3)

CFI(1)

VLAN ID(12)

As shown in Figure 2-1, the IEEE 802.1Q tag sits between the Source Address and Type/Length fields of the original Ethernet frame. The tag itself consists of Tag Protocol ID (TPID) and Tag Control Information (TCI) fields.

The TPID field is a 2-byte field and contains a fixed value of 0x8100 that indicates that this is a tagged (802.1Q) frame.

The TCI field is a 2-byte field that contains three subfields:

■ User Priority: Three bits in length and indicates the QoS priority of the frame. IEEE 802.1p defines the operation of this field.

■ Canonical Format Indicator (CFI): This 1-bit field indicates whether the information in this frame is carried in a canonical (Ethernet) or noncanonical (Token Ring) format.

■ VLAN ID: This 12-bit subfield indicates the VLAN.

Figure 2-2 shows the ToS byte and DS field, which are contained in the IP packet header.

7654321

Precedence

0

MBZ ToS

7654321

DS Field, DSCP

0

ECN Field

FIguRE 2-2ToS Byte and DS Field

ptg999

[ 50 ]



The fields in the ToS byte (RFC 1349) can be described as follows:

■ (IP) Precedence: This 3-bit field is used to specify the relative priority or importance of a packet.

■ Type of Service (ToS): A 4-bit field that defines how the network should make trade-offs between throughput, delay, reliability, and cost.

■ MBZ: Must be zero.

The use of the ToS byte has, to a great extent, been superseded in most networks by the DS field, which consists of a 6-bit differentiated code point (DSCP) field and a 2-bit explicit congestion notification (ECN) field.

The 6-bit DSCP field (described in RFC 2474) defines the per-hop behavior (PHB). A PHB is an externally observable forwarding behavior or QoS treatment performed by a network device, such as a router or a switch.

The four different DiffServ PHBs are Best Effort (BE), Class Selector (CS), Assured Forwarding (AF), and Expedited Forwarding (EF):

■ BE is indicated when all 6 bits of the DS field are zero, and it has no specific QoS treatment.

■ CS is used for backward compatibility with IP Precedence, and when using this PHB, the last 3 bits of the DSCP field are zero.

■ AF (defined in RFC 2597) specifies four different classes, along with three different drop precedences.

When using AF, the first 3 bits of the DS field define the queuing class (1 to 4), and the last 3 bits define the drop precedence (the likelihood of the packet being dropped [1 to 3]). AF PHB names are often written in the AFxy format, where x is the queuing class and y is the drop precedence.

■ EF (RFC 3246) specifies a low-delay, low-jitter, and low-packet-loss QoS treatment with a bandwidth guarantee.

The second (and final) field in the DS field is Explicit Congestion Notification (ECN, RFC 3168). This 2-bit field signals network congestion to hosts.

ptg999

[ 51 ]



The primary tool used on Cisco routers and switches for classification and marking is the Modular QoS CLI (MQC). Using the MQC, a class map can be used to classify traffic; a policy map can be used to specify QoS policy, such as marking, queuing, shaping, policing, and so on; and the QoS policy can then be applied to an interface or VC.

The order of class maps in a configuration file does not matter, but the order in which class maps are referenced within a policy map does. As with an access list, as soon as a match has been found via a referenced class map, other referenced class maps are ignored. If no explicitly configured class maps match the traffic in question, this traffic is matched by an implicit default class (class default).

The following example shows configuration of classification and marking using the MQC:

class-map voice-traffic match ip rtp 16384 16383

!policy-map mark-voice class voice-traffic set dscp ef!interface FastEthernet 0/0 ip address 192.168.1.1 255.255.255.0 service-policy input mark-voice

The class map (class map [match-all | match-any] class-map-name) called voice-traffic matches voice media traffic (match ip rtp 16384 16383). The policy map called mark-voice references the class map called voice-traffic (class {class-name | class-default}) and sets the DSCP field for traffic that matches that class map to EF (set dscp dscp-value). Finally, policy map mark-voice is applied to interface serial 0/0 in an input direction using the service-policy {input | output} policy-map-name command.

The match command can be used to match various frame or packet field settings, including DSCP values, IP Precedence values, CoS values, MPLS Experimental (EXP) bit values, MAC addresses, criteria specified in an access list, and so on.

The set command can be used to modify the settings of the DSCP field, IP Precedence bits, 802.1p/ISL CoS bits, MPLS EXP bits, Frame Relay Discard Eligibility (DE) bit, ATM Cell Loss Priority (CLP) bit, and so on.

The Frame Relay DE bit is used to indicate to Frame Relay switches which frames should be dropped first in the event of congestion. If the DE bit is set in a frame, this indicates that the frame should be dropped first (rather than a frame whose DE bit is not set). The ATM Cell Loss Priority (CLP) bit operates in a similar way in ATM networks.

ptg999

[ 52 ]



Another method of marking packets is to use the police command, as shown in the following example:

policy-map police-mark class class-default police 8000 1000 1000 conform-action transmit exceed-action set-dscp-transmit 0 violate-action drop

interface serial 1/0 service-policy output police-mark

In the example, within the policy map called police-mark, the class class-default command matches all traffic, and the police bps burst-normal burst-max conform-action action exceed-action action violate-action action command then specifies that any traffic that conforms to the rate limit will be transmitted unmodified, traffic that exceeds the rate limit will have its DSCP field set to zero, and any traffic that violates the normal and maximum burst sizes will be dropped. Finally, the service policy command is used to attach the policy map to interface serial 1/0 in an output direction.

You can find more information about the police command in the section, “Traffic Policing and Shaping,” later in this e-book.

The default QoS settings for Cisco IP phones (as set in CUCM Enterprise Parameters) are as follows:

■ Call signaling (SCCP or SIP): CoS 3 and DSCP CS3 (DSCP 24)

■ Voice media (RTP): CoS 5 and DSCP EF (DSCP 46)

Cisco has a set of recommendations with regard to classification, marking, and QoS configuration applicable to all types of traffic (including voice media and call signaling traffic) crossing a network. This set of recommendations is called the Cisco QoS baseline, and it is summarized in Table 2-1.

ptg999

[ 53 ]



TAblE 2-1 Cisco QoS Baseline

Application Type Classification Relevant Standard Recommended QoS Configuration

IP routing CS6 (DSCP 48) RFC 2474 Rate-based queuing + RED

Voice (bearer/media) EF (DSCP 46) RFC 3246 RSVP CAC + Priority queuingInteractive video AF41 (DSCP 34) RFC 2597 RSVP + Rate-based queuing + DSCP WRED

Streaming video CS4 (DSCP 32) RFC 2474 RSVP + Rate-based queuing + REDMission-critical data AF31 (DSCP 26) RFC 2597 Rate-based queuing + DSCP WREDCall signaling CS3 (DSCP 24) RFC 2474 Rate-based queuing + REDTransactional data (Interactive apps)

AF21 (DSCP 28) RFC 2597 Rate-based queuing + DSCP WRED

Network management CS2 (DSCP 16) RFC 2474 Rate-based queuing + REDBulk data (noninteractive applications)

AF11 (DSCP 10) RFC 2597 Rate-based queuing + DSCPapplications)

Scavenger (less than best effort service)

CS1 (DSCP 8) Internet 2 draft No bandwidth guarantee + RED

Best effort BE (DSCP 0) RFC 2474 Bandwidth guarantee Rate-based Queuing + RED

Note that rate-based queuing and priority queuing in Table 2-1 refer to class-based weighted fair queuing (CB-WFQ) and low-latency queuing (LLQ), respectively.

Note that Cisco modified its recommendation for the marking of call signaling traffic (SCCP, H.323, and so on) from AF31 to CS3 (which is reflected in Table 2-1). However, many Cisco devices might still mark call control traffic as AF31.

ptg999

[ 54 ]



Congestion Management: QueuingQueuing is a congestion-management mechanism that can ensure that during (transient) periods of congestion, traffic is appropriately buffered, prioritized, and reordered before subsequent transmission. Queuing mechanisms are active only when there is congestion. If there is no congestion, queuing mechanisms are not used.

Several queuing mechanisms are available on Cisco routers, including first-in, first-out (FIFO) queuing, weighted fair queuing (WFQ), priority queuing (PQ), custom queuing (CQ), IP RTP priority queuing, class-based weighted fair queuing (CBWFQ), and low-latency queuing (LLQ).

Older queuing mechanisms include PQ, CQ, and IP RTP priority queuing. These older mechanisms have been superseded, and to support voice together with data applications, CB-WFQ and LLQ are recommended.

Both CB-WFQ and LLQ provide class-based classification of traffic. CB-WFQ provides up to 256 classes (and queues), and LLQ provides a priority queue with CB-WFQ. Both CB-WFQ and LLQ can provide a bandwidth guarantee, but only LLQ can provide the latency guarantee that voice media traffic requires.

The following example contains a sample configuration of CB-WFQ:

! <class maps omitted for brevity>!policy-map cbwfq-policy class critical-apps bandwidth percent 30 class other-apps bandwidth percent 20 class class-default fair-queue!interface serial 2/0 ip address 192.168.2.1 255.255.255.0 service-policy output cbwfq-policy

The CB-WFQ policy in the example (cbwfq-policy) reserves a minimum of 30 percent of link bandwidth (bandwidth percent percentage) for critical apps and a minimum of 20 percent of link bandwidth for other apps, and then implements a fair queuing strategy (fair-queue) for all other traffic. Finally, the policy map is attached to interface serial 2/0.

ptg999

[ 55 ]



It is also possible to specify a minimum amount of bandwidth in kilobits per second for a particular class, as well as the percentage of remaining available bandwidth using the bandwidth kbps and bandwidth remaining percent percentage commands, respectively.

As mentioned, although CB-WFQ can offer minimum bandwidth guarantees, it cannot offer any latency guarantees; for that, LLQ is needed. A sample configuration for LLQ is shown in the following example:

! <class maps omitted for brevity>!policy-map llq-policy class voice priority percent 15 class video priority percent 10 class class-default fair-queue!interface serial 2/0 ip address 192.168.2.1 255.255.255.0 service-policy output llq-policy

In the example, the policy (llq-policy) specifies a priority queue for voice with a guaranteed allowed bandwidth of 15 percent of link bandwidth (priority percent percentage). A priority queue is also configured for video and assigned 10 percent of link bandwidth. Next, a fair queuing strategy is specified for all other traffic; this traffic is serviced only when the priority queues have first been serviced up to their assigned bandwidth. Finally, the policy map is attached to the interface.

Note that, in LLQ, there is an implicit ability to accommodate bursts of up to 200 ms of traffic. LLQ also includes an implicit policer that ensures that excess traffic assigned to priority queues is dropped (thus ensuring that traffic assigned to other queues can be serviced and that priority queues do not monopolize bandwidth).

Although queuing and scheduling mechanisms allow traffic to be buffered and transmitted, queues can sometimes overfill and traffic can be tail dropped from the back of queues or be selectively dropped before the queues are completely full.

Selective packet dropping allows congestion avoidance and can often allow better performance than tail dropping for data applications because TCP windowing mechanisms ensure that at any one time only those TCP senders whose traffic has been dropped will reduce their throughput. Congestion avoidance using selective packet dropping can be achieved on Cisco routers using a mechanism called weighted random early detection (WRED).

ptg999

[ 56 ]



The following example shows the configuration of WRED:

class class-default fair-queue random-detect dscp-based

The random-detect [dscp-based | prec-based] command is used in the example to configure RFC 2597–compliant DSCP-based WRED for all traffic assigned to class-default (all traffic not matched by other classes [not shown]). When using the dscp-basedkeyword, DSCP values are used to calculate drop probability, and when using the prec-based keyword, IP Precedence values are used to calculate drop probabilities.

Call Admission ControlThe congestion management and avoidance mechanisms discussed in previous sections can be essential in ensuring that voice traffic is protected from (excess) data traffic. But, although congestion management and avoidance mechanisms can protect voice from data, they cannot protect voice traffic from other voice traffic.

The function of CAC is to ensure that too many voice traffic flows are not sent across the network. That is, voice calls are admitted to the network only as long as the network can ensure sufficient quality of service (in terms of delay, jitter, and packet loss) for those voice calls. If the network is unable to ensure sufficient quality for a voice call, that voice call must not be admitted to the network.

CAC is needed for voice (and video) and not data traffic because voice traffic is particularly sensitive to delay, jitter, and packet loss, while data traffic typically is not. Similarly, data traffic can typically be retransmitted, while voice media traffic cannot (arrival of voice media is very time sensitive, so any retransmission would take too long).

There are three overall types of CAC:

■ Reservation-based CAC is based on the reservation or calculation of required resources before a call is admitted. Mechanisms that can be categorized as resource-based CAC mechanisms include the Resource Reservation Protocol (RSVP), gatekeeper zones, and CUCM locations.

■ Local CAC is based on a local determination on a device as to whether a call can be admitted to the network based on local information, such as the state of an outgoing interface or link.

ptg999

[ 57 ]



Mechanisms and configurations that can be categorized as using local CAC include max-connections, which allows a dial peer to enforce a maximum number of active connections, and local voice busyout (LVBO), which allows PBX (analog and CAS) trunks to be taken out of service when WAN conditions are not suitable for voice transport.

■ Measurement-based CAC is based on a determination of network state prior to admitting a call, and involves the use of (Cisco Service Level Agreement/Service Assurance Agent [SLA/SAA]) probes.

Mechanisms that fall into the category of measurement-based CAC include advanced voice busyout (AVBO), which is a feature based on LVBO that adds the capability to probe destinations using Cisco SLA/SAA.

CAC mechanisms can also be categorized according to whether they are topology aware or topology unaware:

■ Topology-aware mechanisms: These function based on communication between the call-processing agent and the network as to available network resources and can dynamically adjust to changes in topology. These mechanisms should be implemented in networks that do not correspond to a simple hub-and-spoke model.

■ Topology-unaware mechanisms: These require static configuration on the call-processing agent. These mechanisms are typically deployed only in comparatively simple network topologies, such as hub-and-spoke topologies.

CUCM locations can be implemented in a simple multisite WAN (hub-and-spoke) centralized call-processing network. Locations can also be used in a two-tier hub-and-spoke deployment (where CUCM clusters are located at first- and second-tier hub sites), with locations used for CAC on the links between the second-tier hub and the connected spoke sites. Gatekeeper zones can be used for CAC on links between first- and second-tier hub sites in a two-tier hub-and-spoke deployment.

When using CUCM locations, CUCM monitors the amount of bandwidth available for voice being used by calls into and out of each location, and then either allows or disallows new calls between locations, depending on whether there is available bandwidth. (CUCM attempts to allocate bandwidth from pools corresponding to the locations of the endpoints involved in the call.) It should also be mentioned that calls within a particular location are not tracked (no CAC is performed), and when using CUCM locations, CUCM is unaware of the topology of the network providing connectivity between locations.

When using Locations in a hub-and-spoke topology, devices at the hub site should be assigned to the <None> location.

ptg999

[ 58 ]



CUCM locations are associated with the configuration of CUCM regions. As previously described, CUCM regions can be used to control the codec used between devices (within a site or between sites). Note that CUCM takes into account the Layer 3 overhead when calculating the amount of bandwidth required for a call; so, for example, a G.711 call requires 80 Kbps.

You configure locations in Cisco CUCM Administration by going to System, Location and assigning devices to appropriate locations.

Figure 2-3 illustrates the configuration of CUCM locations.

FIguRE 2-3Configuration of CUCM Locations

RSVP and gatekeeper-controlled CAC are described in the following two sections.

ptg999

[ 59 ]



RSVPThe Resource Reservation Protocol (RSVP, RFC 2205) can be used in an integrated services architecture or a hybrid IntServ/DiffServ architecture. Specifically, RSVP can be used to ensure that voice or other flows receive adequate QoS end to end across a network by reserving resources on a hop-by-hop basis.

It is possible to specify different types of service via RSVP:

■ Controlled-load service (RFC 2211): Specifies a QoS level similar to that which would be received in an unloaded network

■ Guaranteed quality of service (RFC 2212): Specifies a QoS level that provides firm bounds on end-to-end queuing delays

On Cisco routers, it is possible to configure controlled-load, guaranteed-delay or best-effort service under a dial peer using the req-qos and acc-qos commands. The req-qos command specifies requested QoS, and the acc-qos command specifies an acceptable QoS.

If the requested QoS is best effort, no bandwidth reservation takes place. However, if an RSVP reservation is attempted but fails, the acceptable QoS is used to determine whether call setup goes ahead. If RSVP reservation fails, but acceptable QoS is set to best effort, call setup goes ahead without any bandwidth reservation in the network. If RSVP reservation fails and acceptable QoS is not set to best effort, call setup fails.

Other relevant RSVP IOS commands include the following:

■ ip rsvp bandwidth: Enables RSVP on a router or gateway interface.

■ call rsvp-sync: Enables synchronization between RSVP and voice signaling (for example, H.323).

■ call rsvp-sync resv-timer: Used to configure an RSVP reservation setup timer on the terminating voice gateway. The timer is 10 seconds by default and begins when the terminating gateway receives an indication of an incoming call. If this timer expires before RSVP setup is finished, the outcome of the call setup attempt depends on the configuration of the acceptable QoS under the dial peer.

■ ip rsvp resource-provider [wfq-interface | wfq-pvc]: Used to configure WFQ as the resource provider on the interface/PVC. This is used in an IntServ network architecture.

ptg999

[ 60 ]



■ no ip rsvp data-packet classification: Used to enable data packet classification. Used in an IntServ network architecture.

■ ip rsvp pq-profile: Used to specify the profile (criteria) used by RSVP to direct flows into the priority queue of LLQ. Used in an IntServ network architecture.

A predefined “voice-like” profile ensures that traffic from Cisco IOS devices and traffic from RSVP-enabled applications, such as Microsoft NetMeeting, is directed to the priority queue in LLQ.

Note, however, that there is no RSVP support for LLQ with Frame Relay and ATM PVCs; nor is there support for tunnels.

■ ip rsvp resource-provider none: Used to specify no resource provider. Used in an IntServ/DiffServ network architecture.

■ ip rsvp data-packet classification none: Used to disable RSVP data packet classification. Used in an IntServ/DiffServ network architecture.

For resources to be reserved across a network, an RSVP Path message, which contains a traffic specifier (Tspec) that specifies bandwidth characteristics for a flow, is sent hop by hop across the network toward the destination. The destination then responds with RSVP Resv, a message that constitutes a request for resources, and this travels hop by hop back across the network. (Any devices not RSVP enabled simply transparently forward RSVP messages.) RSVP reservations are unidirectional in nature, so for a voice/video call, two reservations are required.

Path and Resv messages are periodically retransmitted to maintain the resource reservation.

RSVP has two reservation types, distinct and shared, and several reservation styles, including Fixed Filter, Wildcard (Filter), and Shared Explicit.

Reservation types specify how reservations for different senders are handled:

■ Distinct: A traffic flow originates from one sender, and each receiver has its own reservation with the sender.

■ Shared: A traffic flow from one or more senders, and a single reservation is shared by the senders.

Reservation styles indicate the number of senders and the type of reservation:

■ Fixed Filter: Indicates distinct reservations and an explicit sender

ptg999

[ 61 ]



■ Wildcard (Filter): Implies a shared reservation and wildcard sender selection

■ Shared Explicit: Indicates shared reservation and explicit sender selection

gatekeepersAnother method of providing CAC is to use gatekeepers (GK). Gatekeepers provide CAC in H.323 networks (including those involving CUCM) by subtracting bandwidth from a bandwidth pool when a call is set up and returning the bandwidth to the pool when the call is disconnected. Gatekeepers use H.225 RAS signaling and are unaware of the network topology. Gatekeeper functions also include call routing, address translation, and zone management.

Gatekeeper CAC requires the static configuration of (pools of) available bandwidth. When gatekeepers subtract bandwidth from a configured pool, the amount of bandwidth subtracted is twice that codec bit rate. So, for example, 128 Kbps is subtracted for a (64-Kbps) G.711 call and 16 Kbps is subtracted for a (8-Kbps) G.729 call.

Gatekeeper CAC is reliant on zones. Zones include H.323 devices that have registered with a gatekeeper, and only one active gatekeeper is allowed in one zone. Devices that are registered with a gatekeeper are said to be in that gatekeeper’s local zone. Zones that are controlled by other (remote) gatekeepers are referred to as remote zones. Calls are forwarded between gatekeepers that control zones.

Gatekeepers can be used to provide CAC in CUCM multisite WAN (hub-and-spoke) distributed call-processing model networks. If a network does not conform to a hub-and-spoke topology, IP-to-IP gateways can be used to provide call routing and demarcation (and to allow CAC using RSVP).

The section, “Gatekeeper,” in Chapter 1, “Cisco Unified Communications Manager,” contains a sample configuration for an IOS gatekeeper and descriptions of some basic commands.

Other common IOS commands used to configure gatekeepers not described in Chapter 1 include the following:

■ zone remote: Used to statically configure a remote zone on the local gatekeeper. Configuration of this command includes specifying the name of the remote gatekeeper, the domain of the remote gatekeeper, and the IP address of the remote gatekeeper.

ptg999

[ 62 ]



■ bandwidth interzone: Used to specify the maximum amount of bandwidth for calls between a local zone and other zones.

■ bandwidth session: Controls the maximum bandwidth for a call within a local zone.

■ bandwidth total: Specifies the maximum total bandwidth for all calls within or into/out of a local zone.

■ bandwidth remote: Controls the total bandwidth for calls between the local gatekeeper and all remote zones.

■ arq reject-unknown-prefix: Configures a gatekeeper to reject admission requests for zone prefixes that are not configured. This command can be used to ensure that routing loops do not develop across redundant CUCM trunks.

Traffic Policing and ShapingPolicing is the process by which traffic is dropped, re-marked, or simply transmitted according to whether the traffic conforms to a contract. Policing typically takes place at the edge of a network and can be configured in an input or output direction on an interface.

Shaping involves the buffering of excess traffic during transient periods of network congestion. The buffered traffic is then transmitted when congestion abates. Shaping usually occurs at the edge of the network and can be applied to an interface in an output direction.

Both traffic policers and shapers rely on token-bucket algorithms. Tokens are periodically added (to a token bucket), and these tokens directly influence how much traffic can be sent, with each token allowing either a bit or byte to be sent. When a policer or shaper wants to decide whether traffic conforms to or exceeds configured contract rates, it checks the number of tokens remaining in the token bucket.

There are three types of class-based policer (configured using the MQC):

■ Single-rate, two-color policer: In this case, a single token bucket is used, and traffic simply either conforms to or exceeds the configured contract rate. Actions can be specified for traffic that conforms or exceeds the contract rate.

■ Single-rate, three-color policer (RFC 2697): Two token buckets are used, with tokens being periodically added to the first bucket and any “overspilled” tokens filling the second bucket.

ptg999

[ 63 ]



Traffic conforms to, exceeds (uses excess burst), or violates (is over and above the excess burst) the contract. Actions can be specified for traffic that conforms, exceeds, or violates the contract.

■ Two-rate, three-color policer (RFC 2698): Two token buckets are used, with tokens periodically added to both buckets.

Traffic conforms to the contract, exceeds the contract but still conforms to a second rate, or violates the contract.

The following example contains a sample single-rate, three-color policer:

policy-map 1rate-3color class class-default police cir 32000 bc 1500 be 1500 conform-action set-dscp-transmit af31 exceed-action set-dscp-transmit af32 violate-action drop

In the example, the police cir cir bc bc be be conform-action action exceed-action action violate-action action command configures a policer for traffic assigned to class-default, and specifies a committed information rate (CIR) of 32 Kbps, a committed burst (Bc) of 1500 bytes, and an excess burst (Be) of 1500 bytes. Packets that conform have their DSCP field set to AF31 and are transmitted; packets that exceed have their DSCP field set to AF32 and are transmitted; and packets that violate are dropped.

Note that when configuring a single-rate three-color policer, the CIR is configured in bits per second and the Bc and Be are configured in bytes.

The following example shows a sample configuration of a two-rate, three-color policer:

policy-map 2rate-3color class class-default police cir 20000 bc 10000 pir 40000 be 10000 conform-action transmit exceed-action set-dscp-transmit af33 violate-action drop

The police cir cir bc conform-burst pir pir be peak-burst conform-action action exceed-action action violate-action actioncommand configures a policer for traffic in class-default, and specifies a CIR of 20 Kbps, a Bc of 10,000 bytes, a peak information rate (PIR) of 40 Kbps, and a Be of 10,000 bytes. Packets that conform have their DSCP field set to AF31 and are transmitted; packets that exceed have their DSCP field set to AF32 and are transmitted; and packets that violate are dropped.

When configuring a two-rate three-color policer, the CIR and PIR are configured in bits per second, and the Bc and Be are configured in bytes.

ptg999

[ 64 ]



It is also possible to configure CIR and PIR values as a percentage using the percent keyword. In this case, burst sizes (Bc and Be) are configured in milliseconds.

Traffic shaping can be used at the edge of nonbroadcast, multiaccess (NBMA) networks, such as Frame Relay and ATM. It can be applied in an output direction and is useful in many situations, such as the following:

■ When policing is being performed inbound on a neighboring device

■ When there is a mismatch between link speeds at a central site and remote sites (the central site link speed is greater than that at the remote sites)

■ When there is the possibility of congestion at a central site because the aggregate link speed at remote sites is greater than that at the central site

The following is an example of the configuration of class-based Frame Relay traffic shaping:

policy-map fr-shape class class-defaultshape average 121600 1216 0service-policy voice!interface Serial 1/0.100 point-to-point ip address 10.1.1.1 255.255.255.0 frame-relay interface-dlci 100 class frame-map!map-class frame-relay frame-map service-policy output fr-shape frame-relay fragment 160

The class name command is used under the (sub)interface to link to the Frame Relay map class (called, in this example, frame-map).

The Frame Relay map class then links to the policy map called fr-shape using the service-policy output policy-map-name command.

The shape [average | peak] cir [bc] [be] command is used to specify the mean rate (CIR, in bps), the committed burst size (Bc, in bits), and excess burst (Be, in bits) within the policy map (which, in this example, is called fr-shape). Note that it is also possible to specify the average or peak rate as a percentage of the bandwidth on the interface by using the percent keyword with the shape command.

ptg999

[ 65 ]



Finally, the service-policy service-policy-name command links to another policy map (voice, not shown) that is used to configure LLQ for voice traffic.

LAN QoSAlthough bandwidth is usually plentiful in the LAN, it can still be important to configure switches to ensure that voice traffic receives required QoS. In particular, it is important to establish a trust boundary, appropriately classify/mark traffic as close to its source as possible, and police excess or unwanted traffic so that it does not cause problems in the network. It can also be important to configure QoS in the LAN because, in the absence of QoS configuration, voice quality will be affected even if there is momentary congestion.

The configuration of a trust boundary depends on what types of devices are connected at the access layer in a LAN; specifically, whether connected devices can be considered trusted endpoints, untrusted endpoints, or conditionally trusted endpoints:

■ Trusted endpoints: These are devices, such as analog gateways, that can appropriately mark traffic and re-mark any traffic that has been marked by any connected untrusted devices.

■ Untrusted endpoints: These are devices such as workstations, PCs, and servers.

■ Conditionally trusted endpoints: Cisco IP phones are trusted devices, but the PCs that might be connected to them via a PC port are not. Cisco IP phones also are often moved between ports on access switches, and therefore, it is an arduous task to statically configure ports to which IP phones are connected as being trusted.

Therefore, Cisco IP phones have the capability to exchange Cisco Discovery Protocol (CDP) messages with the Cisco switch to which they are connected and, on the basis of this exchange, the switch can extend trust to the phone and trust traffic received from the phone. The Cisco IP phone can re-mark any traffic received from a connected PC to CoS 0.

CDP is a Cisco proprietary protocol that was designed for neighbor discovery. It is a Layer 2 protocol that sends multicast advertisements (with the multicast destination address 01:00:0C:CC:CC:CC) using a Subnetwork Access Protocol (SNAP) encapsulation. These advertisements are sent by default every 60 seconds, and there is a default hold time of 180 seconds. (These timers can be modified using the cdp timer and cdp holdtime commands.) There are two versions of CDP—CDP Version 1 and CDP Version 2—with CDPv2 offering certain enhancements over CDPv1. CDP advertisements can contain information such as device

ptg999

[ 66 ]



ID, address, port ID, capabilities, version, platform, and native VLAN, with much of the information being represented in an ASCII format.

CDP messages are made up of Version, Time to Live (TTL), and Checksum fields, followed by a number of Type, Length, Values (TLV). These TLVs can include the following:

■ Device-ID (type 0x0001): This identifies the sending device.

■ Address (0x0002): The address of the interface sending the CDP update.

■ Port-ID (0x0003): The port from which the CDP update is sent.

■ Capabilities (0x0004): Device’s functional capabilities (for example, whether it is a router or switch).

■ Version (0x0005): Software version running on the device.

■ Platform (0x0006): The hardware platform.

■ VTP Domain (0x0009): The VTP domain.

■ Native VLAN (0x000a): The 802.1Q native VLAN.

■ Appliance VLAN-ID (0x000e): This contains one or more tuples. Each of these contains an appliance ID and a VLAN ID.

■ Power Consumption (0x0010): This indicates the maximum amount of power (milliwatts) that the device expects.

■ Extended Trust (0x0012): This indicates to a device, such as a Cisco IP phone, that the QoS trust should be extended to the PC port of the IP phone.

■ CoS for Untrusted Ports (0x0013): Specifies the CoS value that a device, such as a Cisco IP phone, should mark packets received on an untrusted port with.

By default, Cisco IP phones mark voice media frames with CoS(802.1p)/DSCP of 5/EF and call signaling frames with CoS(802.1p)/DSCP of 3/AF31 or CS3.

ptg999

[ 67 ]



As mentioned, certain Cisco IP phones also have a PC port to which it is possible to connect a workstation, and these Cisco IP phones can re-mark any traffic received from the workstation with CoS 0.

■ mls qos trust device cisco-phone: This command can be used to extend the trust boundary and trust CoS/DSCP values sent by connected Cisco IP phones.

QoS configuration on Cisco switches varies depending on particular requirements and specific hardware platforms. However, possible QoS policy for ports connected to conditionally trusted Cisco IP phones might be as follows:

■ Cisco switches are configured to conditionally trust Cisco IP phones using the mls qos trust device cisco-phone command.

A policy map is attached to switch ports that match voice media and call signaling traffic received on the voice VLAN using DSCP values, sets appropriate DSCP values, and polices that traffic to ensure that excess voice media traffic is dropped and excess call signaling traffic is marked down. Any other traffic received either on the voice VLAN or on the access VLAN is marked as DSCP 0 and policed, with any excess traffic being marked down to scavenger class.

■ The switchport priority extend trust command can be used to configure the IP phone’s access port to trust the priority received from a connected PC or other device.

■ The switchport priority extend cos value command can be used to configure the IP phone’s access port to override the priority on frames received from a connected PC or other device and set it to the specified value.

CuCM CAC and gK: Hub-and-Spoke/Fully Meshed MPLSWhen the underlying WAN is Multiprotocol Label Switching (MPLS) based, it is important to consider some important differences in how CAC should be provisioned over an MPLS WAN compared to how it is provisioned over more traditional (Layer 2) WANs.

First, although it is possible for service providers to configure a true hub-and-spoke customer routing topology over an MPLS Layer 3 VPN, most service providers instead provision an any-to-any routing and connectivity model over which customer traffic flows. The fact that all sites have direct connectivity can present a few challenges as far as CAC is concerned.

Customer edge (CE) routers in an MPLS Layer 3 VPN peer only with provider edge (PE) routers, not with each other. Also, PE routers use MP-BGP to advertise customer routes to each other (irrespective of any PE-CE routing protocol). So, the service provider

ptg999

[ 68 ]



MPLS network is invisible as far as customer routing is concerned. Although customer traffic is IP routed between CE and PE devices, it is label switched across the service provider’s MPLS backbone; so for all intents and purposes, the service provider MPLS backbone is invisible to customer routing and traffic (assuming careful configuration by the service provider). However, knowledge of the underlying service provider network topology is not required to provision CAC.

There are a number of considerations for deploying CAC with an MPLS WAN:

■ An MPLS WAN resembles a hub-and-spoke topology, with no hub site (or the WAN itself considered as the hub) and all the enterprise customer sites being, in effect, spoke sites.

■ From an enterprise IP routing perspective, each site is one hop away from the other sites.

■ In a multisite WAN with centralized call-processing deployments, CUCM locations should be used for CAC.

■ In a multisite WAN with distributed call-processing deployments without branch sites, a gatekeeper should be used to provide CAC, with each site being in its own zone.

■ In a multisite WAN with distributed call-processing deployments with branch sites, a gatekeeper can continue to be used for dial plan resolution, but not for CAC. Instead, CUCM locations can be used for CAC.

■ If RSVP is being used for CAC, CE routers must be enabled for RSVP. RSVP messages will transparently transit the MPLS WAN. Configuration of RSVP on the CE routers will ensure that the priority queue on the CE routers will not be overrun, but you must also make sure that media streams are the same size in both directions and that the media is symmetrically routed to ensure that the priority queue on the PE router is protected.

For more information on MPLS and other VPN technologies, see Comparing, Designing, and Deploying VPNs (Cisco Press, ISBN 1-587-05179-6), and Troubleshooting Virtual Private Networks (Cisco Press, ISBN 1-587-05104-4).

ptg999

[ 69 ]



Chapter 3Telephony Protocols

This chapter describes telephony protocols, including the Media Gateway Control Protocol (MGCP), the Session Initiation Protocol (SIP), H.323 (H.225, H.245, RAS), the Skinny Client Control Protocol (SCCP), and TDM/analog signaling protocols.

Skinny Client Control ProtocolSCCP is a Cisco proprietary master/slave protocol that CUCM and other call agents can use to communicate with devices and endpoints, such as Cisco IP phones. One advantage of SCCP is that it is flexible and allows features to be easily added.

SCCP uses TCP ports 2000 (SCCP) and 2443 (Secure SCCP [SCCPS]). Skinny gateway (analog) uses TCP port 2001 and skinny gateway (digital) uses TCP port 2002.

Figure 3-1 illustrates an SCCP call between two phones registered to the same CUCM.

ptg999

[ 70 ]


Chapter 3: Telephony Protocols

FIguRE 3-1SCCP Call Flow

Station Off Hook

Station Play Tone (Dial Tone)

Station Set Lamp (Steady)

Station Digit Dialed

Station Stop Tone (Dial Tone)



Station Call InformationStation Set Lamp (Blink)Station Set Ringer (On)

Station Call Info

Station Start Tone (Alerting)

Station Off HookStation Set Lamp (Steady)

Station Stop Tone

Station Set Ringer (Off)

Station Open Receive Channel

Station Open Receive Channel

Station Call Info

Station Start Media TransmissionStation Open Receive Channel Ack

Station Open Receive Channel AckStation Start Media Transmission

Station On HookStation Close Receive Channel

Station Set Lamp (Off) Station Stop Media Transmission

Station Close Receive Channel Station Set Lamp (Off)

Station Stop Media Transmission Station On Hook

Station On Hook

Phone#1 Phone#2CUCM

RTP RTP

In Figure 3-1, phone#1 goes off-hook and signals this event to the CUCM.

CUCM sends messages to phone#1 that trigger a dial tone and causes phone#1 to set its lamp state to on.

The user of phone#1 begins to dial a number, and the first digit is dialed (and sent to the CUCM), which causes the CUCM to indicate to phone#1 that the dial tone should no longer be played.

The user of phone#1 continues to dial the number, and these digits are sent to the CUCM.

ptg999

[ 71 ]



The CUCM performs digit analysis on the dialed digits, and finds a match for phone#2 (not shown in Figure 3-1).

The CUCM now sends information about the calling party to phone#2, such as calling party name, calling party number, and so on. The CUCM also indicates to phone#2 that it should blink its lamp and that it should ring.

The CUCM then sends an alerting (ringback) message to phone#1.

The user of phone#2 answers the phone, and an off-hook message is sent to the CUCM.

The CUCM responds by telling phone#2 to stop blinking its lamp (set it to a steady state) and to stop the ring tone.

The CUCM also informs phone#1 to end the ringback tone.

Next, the CUCM requests information regarding the Real-time Transport Protocol (RTP) (for example, the IP address to/from which RTP should be sent/received). Both phones respond, and the CUCM then informs each phone of the other’s RTP information.

RTP traffic now flows between the phones, and the users begin their conversation.

The user of phone#1 now ends the call, and phone#1 sends an on-hook message to the CUCM.

The CUCM notifies the phones to close the media channel and end media transmission. It also informs the phones to set their lamp states to off.

Finally, phone#2 sends an on-hook message to the CUCM.

SCCP can signal numerous call states, including the following:

1: Off Hook

2: On Hook

3: Ring Out

4: Ring In

5: Connected

ptg999

[ 72 ]



6: Busy

7: Line In Use

8: Hold

9: Call Waiting

10: Call Transfer

11: Call Park

12: Call Proceed

13: In Use Remotely

14: Invalid Number

CUCM uses SCCP to control media resources, such as conferencing resources, transcoding resources, media termination point (MTP) resources, Music on Hold (MoH) resources, and annunciator resources. SCCP can also be used to control FXS ports on certain IOS voice gateway platforms.

Call agent, device, and endpoint types that can communicate using SCCP include CUCM, CUCM Express, Cisco Unity (voicemail ports), routers running SRST, VG200 (DSP-farm), VG224, VG248, ATA186, ATA188, Cisco IP phones, Cisco IP Communicator, Tandberg and Sony video endpoints, Cisco 3800/3900 gateways, Cisco 2800/2900 gateways, Cisco 3700 gateways (DSP farm), Cisco 3640/3660 gateways (DSP farm), Cisco 2600/2600XM gateways (DSP farm), Cisco 1751/1760 (conferencing/transcoding), and WS-X6608-T1/E1.

Four steps are involved in configuring CUCM-controlled media resources:

Step 1. Enable DSP farm services.

Step 2. Configure a DSP farm profile.

Step 3. Configure SCCP.

Step 4. Specify media resources in CUCM.

ptg999

[ 73 ]



The next example shows a sample configuration of CUCM-controlled media resources (conference bridging) on an IOS gateway:

voice-card 0 dsp services dspfarm

dspfarm profile 1 conference maximum sessions 2 associate application sccp

sccp local FastEthernet0/0sccp ccm 10.1.1.1 identifier 1 version 4.1sccp

sccp ccm group 1 associate ccm 1 priority 1 associate profile 1 register CFB123456 bind interface FastEthernet0/0

The voice-card slot and dsp services dspfarm commands configure the voice card to support transcoding and conferencing.

Next, the dspfarm profile profile-identifier {conference | mtp [transcode ]} command creates a DSP farm profile for, in this example, conferencing.

Within the DSP farm profile, the maximum sessions number and associate application sccp commands specify the maximum number of sessions supported by the profile and associate the SCCP protocol with the profile, respectively.

The no shutdown command (not shown in this example) can be used to enable the DSP farm profile.

The sccp local interface-name command is then used to specify the interface that SCCP uses to register with CUCM, and the sccp ccm {ip-address | dns name} identifier identifier-number version cucm-version command is used to specify the IP address (or name), local identifier, and CUCM version of the CUCMs with which the gateway will register.

The sccp command is used to initialize SCCP on the gateway.

The SCCP CCM group is then configured using the sccp ccm group group-number command.

ptg999

[ 74 ]



Within the SCCP CCM group, the associate ccm identifier-number priority priority-number and associate profile profile-identifier register device-name commands are used to associate a CUCM and a DSP farm profile with the group, respectively. The bind interface interface-name command binds an interface with the group.

Other useful commands that can be used when configuring an SCCP CCM group on an IOS gateway include the following:

■ connect interval seconds: Specifies the time that a DSP farm profile waits before connecting to another CUCM.

■ connect retries number: Configures the number of times that the DSP farm tries to connect to a CUCM when the current CUCM fails.

■ keepalive retries number: Specifies the number of keepalive retries to the CUCM.

■ keepalive timeout seconds: Configures the number of seconds between keepalive messages.

■ registration retries retry-attempts: Specifies the number of retries that SCCP makes with CUCM when attempting to register.

■ registration timeout seconds: The number of seconds between registration message between the gateway and CUCM.

■ switchover method {graceful | immediate}: The method used for CUCM switchover when the active CUCM fails.

■ switchback method {graceful | guard [timeout-value] | immediate | uptime uptime-value}: The method used for switchback when the primary (higher priority) CUCM becomes active again.

■ switchback interval seconds: The number of seconds that the DSP farm waits before attempting to switch back to the primary CUCM.

Media resources can be configured in CUCM by navigating to Feature, Media Resource.

ptg999

[ 75 ]



RTP and cRTPThe Real-time Transport Protocol (RTP, RFC 3550) is used to transport voice and video media packets across a network. RTP uses User Datagram Protocol (UDP) as its transport protocol.

RTP uses UDP rather than TCP as its transport layer protocol mainly because TCP retransmission is not suitable (it takes too long), TCP congestion control/slow start mechanisms can lead to an inability to ensure sufficient packet rates, and TCP headers are larger than UDP headers. Finally, note that RTP/UDP is preferred over TCP for voice media transport because TCP does not provide required encoding and timestamp information.

RTP uses sequence numbers and timestamps to detect packet loss and ensure correct playout timing. RTP timestamps for each session begin with a random number, so time information provided by RTP is relative. (Absolute time, such as that provided by Network Time Protocol [NTP], is not required to run RTP.)

The Real Time Control Protocol (RTCP) provides out-of-band reporting of QoS statistics for RTP flows, including information relating to packet loss, jitter, and round-trip time. Although NTP is not required to run RTP, RTCP can make use of NTP.

The IP/UDP/RTP headers that encapsulate voice media packets total 40 bytes, and this overhead is significant when you consider that the voice media payload may, for example, be 20 bytes (G.729). So, IP/UDP/RTP headers make up a large proportion of total voice media packet size, and on slow speed links, it can be advantageous to compress these headers to save bandwidth.

Compression of the IP/UDP/RTP headers can be achieved using Compressed RTP (cRTP). According to RFC 2508 and 3545, the 40 bytes of IP/UDP/RTP headers can typically be compressed down to 2 to 4 bytes. The compressed header is 2 bytes when no UDP checksums are sent (the checksum is zero), and 4 bytes when (nonzero) checksums are sent.

The following sample calculation illustrates bandwidth savings that can be realized when using cRTP:

Bandwidth = (Layer 2 header + Layer 3 header + Layer 4 header + Voice payload in bytes) * 8 bits * Packets per second

So, let’s assume the G.711 codec (default 160 byte payload), with MLP (1 + 6 bytes overhead), at 50 pps:

Without cRTP

Bandwidth = ( [1 + 6] + 20 + 8 + 12 + 160) = 207 bytes * 8 = 1656 * 50 pps = 82,800 bps = 82.8 Kbps

ptg999

[ 76 ]



With cRTP

Bandwidth = ( [1 + 6] + 2 + 160) = 169 bytes * 8 = 1352 bits * 50 pps = 67,600 bps = 67.6 Kbps

Bandwidth savings

82,800 – 67,600 = 15,200 bps

(15,200 / 82,800) * 100 = 18.36 percent savings

Note that when calculating voice bandwidth, it is important to take into account these factors:

■ Layer 2 headers/overheadPPP/MLP = 7 bytes

HDLC = 7 bytesFrame Relay/FRF.12 = 7 bytesATM = 5 bytesMLP over Frame Relay = 14 bytesEthernet = 18 bytes, including CRC

■ Layer 3 and 4 headersIP header = 20 bytes

UDP header = 8 bytesRTP header = 12 bytes

cRTP (IP/UDP/RTP) header = 2 (or 4) bytes

■ Sample sizes

G.711 uses a sample size of 80 bytes/10 ms and has a default voice payload size of 160 bytes/20 ms (default payload includes 2 samples). If the payload is 240 bytes, this equates to 30 ms.

ptg999

[ 77 ]



G.711 requires a transmission rate of 50 packets per second (pps) with this payload size.

Note that G.711 has a codec bit rate of 64 Kbps, meaning that this (payload) bit rate that must be maintained.

The number of packets per second that must be transmitted per second to maintain a codec bit rate of 64 Kbps is given by the following formula:

Packets per second (pps) = Codec bit rate (bps) / Voice payload size (in bits)

So, for G.711, if the codec bit rate is 64 Kbps and the voice payload size is 1280 bits (160 bytes), the number of packets per second required is 50 pps.

G.729 uses a sample size of 10 bytes/10 ms and has a default voice payload size of 20 bytes/20 ms (default payload includes two samples). If the payload is 30 bytes, this equates to 30 ms.

G.729 requires a transmission rate of 50 pps with this payload size.

Note that G.729 has a codec bit rate of 8 Kbps.

Media gateway Control ProtocolMedia Gateway Control Protocol (MGCP) is defined in RFC 3435 (which obsoletes RFC 2705), and it specifies an application programming interface (API) and text-based master/slave protocol used by a media gateway controller (MGC) or call agent to control media gateways (MG). MGCP is based on two other (now obsolete) protocols: the Simple Gateway Control Protocol (SGCP) and Internet Protocol Device Control (IPDC).

MGCP MGCs and MGs can be described as follows:

■ MGC/call agent: This element possesses call control intelligence and controls MGs. An MGC/call agent could, for example, be a Cisco CUCM. MGCP allows the centralization of the dial plan on the call agent.

■ MG: This device provides translation between data packets and audio signals received over VoIP networks and other networks, such as the public switched telephone network (PSTN). A media gateway could, for example, be an IOS router with analog or digital voice ports.

ptg999

[ 78 ]



Media gateways can be classified depending on the connectivity they provide. For example, a media gateway that terminates trunks connecting to the telephone network can be referred to as a trunking gateway, and a media gateway that provides analog connections to phones can be referred to as a residential gateway.

MGCP specifies a connection model involving endpoints and connections:

■ Endpoint: MGCP media gateways contain endpoints, which are sources/destinations for data. Endpoints can be physical, such as interfaces terminating trunks connecting to a PSTN or interfaces terminating plain old telephone service (POTS) connections to PBXs, key systems, or telephones. Endpoints can also be virtual endpoints, such as audio content sourced from a server.

■ Connection: This is an association between endpoints for the purpose of transmitting data and can be either point-to-point or multipoint in nature.

MGCs/call agents and MGs use several commands and responses (or verbs) to communicate with each other:

■ EndpointConfiguration (EPCF): A call agent sends this message to a gateway to specify signal encoding that will be received by an endpoint. This message could, for example, be used to specify whether audio calls will be encoded using mu-law or a-law.

■ CreateConnection (CRCX): This creates a connection between two endpoints. The connection is created based on parameters included with the command, such as codec, allowable bandwidth, use of echo cancellation, silence suppression, gain control, and so on.

■ ModifyConnection (MDCX): This modifies the parameters associated with a connection that was previously created.

■ DeleteConnection (DLCX): The call agent can send this command to inform a gateway that it should terminate a connection, and a gateway can send this command to indicate that a connection can no longer be sustained. In response to a DeleteConnection command, a media gateway sends statistics associated with the connection.

■ NotificationRequest (RQNT): This is sent by a call agent to instruct a gateway to inform it when specific events occur in an endpoint. These events could, for example, be on-hook/off-hook status changes or the reception of certain tones.

■ Notify (NTFY): A media gateway uses this command to inform a Call Agent when requested events occur.

ptg999

[ 79 ]



■ AuditEndpoint (AUEP): The call agent sends the AuditEndpoint command to the gateway to audit the status of an endpoint. The call agent can, for example, find out signal status, event status, bearer information, and endpoint capabilities using this command.

■ AuditConnection (AUCX): The call agent sends this command to the gateway to find out the status of a connection. Connection status information that can be retrieved using this command includes call ID, connection mode, and connection parameters.

■ RestartInProgress (RSIP): The gateway sends this command to the call agent to inform the call agent that it is taking an endpoint or group of endpoints out of service or is returning an endpoint or group of endpoints to service.

Figure 3-2 illustrates a sample MGCP call flow between a CUCM (call agent) and an MGCP gateway.

NTFY (O:L/hd)

CUCM

RQNT (R:L/hu,D/[0-9*#] S:dl)

NTFY (O:4)

RQNT (R:L/hu,D/[0-9*#] S:)

NTFY (O:5)

CRCX

Ack

MDCX

MGCP Gateway

V

FIguRE 3-2Sample MGCP Call Flow

In Figure 3-2, the MGCP gateway sends a Notify message to the CUCM to inform it that a requested event has occurred. In this case, the observed event (O) is an off-hook event (hd) with the use of the line package (L). This could, for example, be caused by an FXS port going off-hook.

ptg999

[ 80 ]



Next, the CUCM sends a NotificationRequest to request (R) that the gateway inform it when an on-hook (hu) event occurs and request that the gateway collect digits 0 to 9, *, and #. The CUCM also sends a signaling request (S) asking the gateway to use the line package (L) and play a dial tone (dl).

The gateway then informs the CUCM of an observed event (O); the digit 1 has been pressed.

The CUCM now sends another NotificationRequest to request that the gateway again inform it when an on-hook (hu) event occurs, collect digits 0 to 9, *, and #, and turn off the dial tone.

The gateway informs the CUCM that the digit 2 has been pressed.

The CUCM sends a CreateConnection (CRCX) message to the gateway to ask it to create a connection and turn on the ring tone.

The gateway then sends an acknowledgment message to inform the CUCM that the CRCX was completed and to inform the CUCM of the gateway’s local RTP IP address and port.

Finally, the CUCM sends a ModifyConnection (MDCX) to inform the gateway of the remote peer’s RTP IP address and port.

Note that the signaling between the CUCM and the remote peer (such as an SCCP phone) is not shown in Figure 3-2.

MGCP messages are sent on UDP port 2427. However, TCP port 2428 is used to exchange keepalives between an MG and CUCM, and for MGCP PRI/BRI backhaul between a media gateway and CUCM.

MGCP PRI/BRI backhaul is used to transport ISDN Q.931 (D channel) signaling information from the gateway to the call agent (CUCM). ISDN Q.921 signaling is terminated on the gateway and is not backhauled to the call agent (only Q.931 is).

ptg999

[ 81 ]



FIguRE 3-3MGCP PRI/BRI Backhaul

Q.931/MGCP

CUCM(MGC/Call Agent)

Media Gateway(MG)

VPSTN

Q.921

Q.931

MGCP is a popular gateway control protocol for several reasons, including the following:

■ MG configuration is simplified because call control and dial plan are centralized on the MGC.

■ Dial plan management and administration is simplified because of its centralization on the MGC.

■ Cisco MGCP MG can be configured to switch over from a primary to backup CUCM in the event of a failure of the primary. (There can be two backups in addition to the primary.) Similarly, Cisco MGCP gateways can be configured to fall back to using H.323 for call control in case gateways are unable to communicate with any CUCMs.

■ Active calls are preserved when an MGCP gateway switches over to a backup CUCM.

■ Active analog and T1 CAS calls are preserved in the event of fallback to H.323. Any active PRI calls that are being backhauled to CUCM are not preserved during fallback.

When integrating an IOS MGCP gateway with CUCM, you can download the majority of the configuration from a CUCM.

To automatically download the configuration from a CUCM, you only need two commands:

■ ccm-manager config server {ip-address | dns-name}: Specifies the IP address or DNS name of the CUCM from which you want to download the configuration.

Figure 3-3 illustrates MGCP PRI/BRI backhaul.

ptg999

[ 82 ]



■ ccm-manager config: Enables the IOS gateway to download the configuration. After the configuration is downloaded, you must associate voice ports with MGCP, as shown here:

dial-peer voice 10 pots application MGCPAPP port 1/0/1

The dial-peer voice number pots command configures a POTS dial peer.

The application MGCPAPP command then associates MGCP with the dial peer, and finally, the port port-number command binds a voice port with the dial peer.

It is possible to configure the MGCP redundancy using the following commands:

■ ccm-manager redundant-host {ip-address | dns-name}: Enables you to configure the IP address or DNS name for one or more backup CUCMs to use when the primary CUCM is unavailable.

■ ccm-manager switchback mode {graceful | immediate | never | schedule-time hh:mm | uptime-delay minutes}: Use this command to specify how the MGCP gateway should switch back to the primary CUCM when it is available. Graceful mode allows switchback when the last active call ends; immediate switches back immediately; never never switches back, as long as the backup CUCM is up; schedule-time switches back at a specified time; and uptime-delay specifies how long the primary must be active before switchback.

■ ccm-manager fallback-mgcp: Enables CUCM fallback (when CUCM is unavailable).

Other useful MGCP commands include the following:

■ mgcp dtmf-relay voip codec {all | low-bit-rate} mode {cisco | nse | out-of-band}: Can specify dual-tone multifrequency (DTMF)-related parameters

■ ccm-manager music-on-hold: Enables MoH

■ ccm-manager music-on-hold bind interface: Binds the MoH feature to a particular interface

In CUCM, you can add an MGCP gateway by navigating to Device, Gateway.

ptg999

[ 83 ]



SIPSIP is a text-based, peer-to-peer, application layer control signaling protocol that is used for setting up, modifying, and tearing down multimedia sessions between participants. It is defined in RFC 3261 (which obsoletes RFC 2543) and takes advantage of elements of HTTP, SMTP, and the Session Description Protocol (SDP).

SIP uses SDP to negotiate media type and format, such as audio and video codecs, and transport protocol parameters, such as RTP and UDP parameters and ports. SDP operates in an offer/answer model such that the session initiating endpoint indicates desired session parameters (such as supported codecs), and the receiving endpoint replies with matching session parameters (excluding codecs that are not supported).

In the process of setting up and tearing down sessions, SIP supports the capability to determine a user’s location and the user’s willingness to communicate, and ascertain appropriate media parameters. By default, SIP uses port 5060 for TCP/UDP and port 5061 for TLS over TCP.

Various elements contribute to SIP’s capability to establish, manage, and terminate sessions, and these include the following:

■ User agent (UA): This endpoint can act as both a user agent client (UAC) and a user agent server (UAS). A UA could, for example, be a SIP IP phone.

■ UAC: This logical entity initiates and sends requests, such as those specifying the INVITE method. The UAC is a logical role, so it lasts only for the duration of a SIP transaction.

A transaction comprises all messages beginning with the initial request message and ending with the final response message.

■ UAS: This entity responds to a SIP request by accepting, rejecting, or redirecting the request. The UAS role lasts only for the duration of the transaction.

■ Redirect server: This is a (user agent) server that provides address translation and redirects clients to alternative destination addresses. It does this by sending 3xx responses to requests.

■ Proxy server: A SIP proxy server’s primary role is to provide routing, but it can also enforce policies, provide features, and authenticate and authorize users.

ptg999

[ 84 ]



■ Registrar server: This allows users to register their current locations. (This information is added to a location service.) Registrar servers use the information to provide a lookup service that allows SIP UAs to be located.

■ Location service: This is created by a registrar server and is populated with bindings of address-of-record ([AOR], a user’s “public” address) to contact addresses. The location service can be used by proxy or redirect servers to retrieve information relating to a called party’s possible locations.

■ Back-to-back user agent (B2BUA): This entity receives requests but, to process them, has itself to generate requests. Because it both processes and generates requests, its functionality is a combination of that of a UAC and a UAS. Note that it differs from a proxy server in that it must participate in all requests corresponding to dialogs that it has set up.

A dialog is a SIP peer-to-peer relationship between UAs that exists for some time.

■ Presence server: This physical device is aware of the willingness and capability of tracked parties (presentities) to communicate across a set of devices, and distributes this information to interested parties (watchers). Information about a tracked party’s willingness and capability to communicate is known as presence information.

CUCM functions as a B2BUA and a registrar server.

There are two SIP message types:

■ Request: This message is sent by a client to a server that is used to invoke certain operations or functions.

■ Response: This message is sent by a server to a client that indicates the status of the request received from the client.

As already mentioned, request messages can invoke certain functions on a server. These functions are known as methods. A method is specified in a request message sent by a client to a server, and they include the following:

■ INVITE: When a UAC wants to initiate a session, it sends an INVITE request to a server. When this arrives at a UAS (it may be forwarded by proxies), the UAS processes it and sends an appropriate type of response message.

■ ACK: This message is sent in reply to a final response message from a server.

■ BYE: Terminates a session.

ptg999

[ 85 ]



■ CANCEL: Terminates a pending request (a request for which a final response has not yet been received).

When a caller’s UA (UAC) wants to hang up when there has not yet been a final response to an INVITE, the session will still be pending, so a CANCEL is sent. In this case, the CANCEL constitutes a request to stop ringing.

■ REGISTER: This message is used to register contact information.

When a user wants to initiate a session with another user, SIP must locate the host at which the destination user is currently reachable. The location of the host is often determined by a proxy or redirect server because these servers will frequently receive requests that they are then responsible for forwarding to the destination user’s host.

To locate the destination user host, the server consults a location service, the purpose of which is to provide address bindings. These address bindings consist of URI to user agent at which a user is currently located.

Address bindings can be created using a process called registration. Registration entails sending REGISTER messages to an element called a registrar server. As previously mentioned, a registrar server is a front end for the location service that both reads and writes mappings based on REGISTER messages.

Cisco SIP phones send their MAC addresses and register their lines with the primary CUCM using REGISTER messages.

Cisco SIP phones also use REGISTER messages (with expires=0) as a keepalive with a secondary CUCM.

■ OPTIONS: A UA can query another UA or SIP server about its capabilities using an OPTIONS request. In this way, a client can find out such capabilities as supported methods, content types, codecs, and so on before, for example, sending an INVITE specifying required options.

■ INFO: This method is defined in RFC 2976 and can be used to carry session-related control information, such as ISUP or ISDN signaling information.

There are six different ranges of response:

■ 1XX: Responses in this range are provisional or informational.

■ 2XX: These indicate success.

ptg999

[ 86 ]



■ 3XX: These responses indicate redirection.

■ 4XX: These responses indicate client errors.

■ 5XX: These indicate server errors.

■ 6XX: These indicate global failures.

So, that’s the theory, but how does it work in practice? Figure 3-4 illustrates a typical SIP session established via a proxy server.

FIguRE 3-4SIP Session Established via a Proxy Server

INVITE

TRYING

RINGING

OK

ACK

RTP/RTCP

BYE

OK

INVITE

TRYING

RINGING

OK

Proxy Server

IP

UA #2UA #1

ptg999

[ 87 ]



It’s also a good idea to look at and understand the SIP call flows illustrated at the following URL:

http://www.cisco.com/en/US/docs/voice_ip_comm/cuipph/7960g_7940g/sip/8_0/english/administration/guide/sipaxb80.html

Configuration of SIP gateways consists of a number of elements, including

■ Dial peers

■ SIP voice service configuration

■ SIP UA configuration

The following example shows the configuration of a SIP dial peer:

dial-peer voice 10 voip session target ipv4:10.1.1.1 session protocol sipv2 destination-pattern 3333...

■ The dial-peer voice tag voip command configures a VoIP dial peer.

■ The session-target ipv4:destination-address command configures a dial IPv4 destination address.

■ Next, the session protocol sipv2 and destination-pattern string commands are used to specify that the dial peer should use SIP Version 2 and associate a prefix with the dial peer.

The following example shows an example configuration of the SIP voice service:

voice service voip sip session transport tcp bind all source-interface loopback0

■ The voice service voip command is used to enter voice service configuration mode, and the sip command is used to enter the SIP mode within voice service configuration.

http://www.cisco.com/en/US/docs/voice_ip_comm/cuipph/7960g_7940g/sip/8_0/english/administration/guide/sipaxb80.html

ptg999

[ 88 ]



■ The session transport {tcp | udp} and bind {all | control | media} source-interface interface command configures the gateway to use either TCP or UDP for SIP session transport and to source control traffic/media traffic from a particular interface.

A SIP UA configuration is shown here:

sip-ua registrar ipv4:10.1.1.1 tcp authentication username mark password cisco123

■ You can enter the SIP UA configuration mode by using the sip-ua command.

■ The registrar ipv4:ip-address tcp command configures the gateway to register E.164 numbers with a SIP registrar on behalf of (E)FXS ports and SCCP phones.

■ authentication username username password password is used to specify a username and password used for authentication.

■ You can configure a SIP trunk on a CUCM by navigating to Device, Trunk and clicking Add a New Trunk.

Before finishing this section, it’s worth looking at the transport of DTMF between SIP endpoints. Many methods can be categorized as being either in-band or out-of-band:

■ Unsolicited Notify (UN): Nonstandard, out-of-band method of carrying DTMF in SIP NOTIFY messages that is only supported on Cisco IOS gateways in IOS 12.2 and later releases.

■ INFO: This involves the out-of-band transport of DTMF tones in SIP INFO messages and is not supported in CUCM.

■ Key Press Markup Language (KPML): This out-of-band method of carrying DTMF tones is defined in RFC 4370 and is supported in CUCM, Cisco IOS gateways running IOS 12.4 and later, and some Cisco IP phones. KPML takes advantage of the SIP SUBSCRIBE and NOTIFY message types. SIP NOTIFY messages signal the DTMF, with the event specified in the NOTIFY as KPML and the actual DTMF tones carried in XML-formatted messages in the NOTIFY.

■ RFC 2833: RFC 2833 Named Telephony Events (NTE) are an in-band method of transporting DTMF tones. Payload types can be dynamically assigned, but the Cisco default is 101.

ptg999

[ 89 ]



■ Audible (raw) tones in the RTP stream: This in-band method involves the transport of audible DTMF tones in a RTP packet stream.

SIP typically sends DTMF digits in-band, whereas SCCP phones send only out-of-band digits. In CUCM versions prior to 5.0, you need an MTP to handle the conversion. In CUCM versions 5.0 and above, you no longer need to configure an MTP for SIP to SCCP calls.

H.323: H.225, H.245, RASH.323 is a framework developed within the ITU that describes interactive multimedia communications. The framework itself encompasses a number of protocols, standards, and procedures, including the following:

■ H.225 RAS (Registration, Admission, and Status): Facilitates communication between H.323 endpoints and gatekeepers. Gatekeepers provide a number of services, including call admission control (CAC), bandwidth management, address translation, dial plan resolution, and call routing. In H.323, the dial plan may be distributed, although gatekeepers can help to alleviate issues related to having a distributed dial plan.

■ H.225 call control and signaling: Establishes connections between H.323 endpoints, such as phones.

■ H.245: Endpoints use H.245 to communicate information relating to capabilities, establish logical channels for the transmission of media, and so on.

These protocols and standards are described more fully in the remainder of this section.

H.323 signaling is encoded using Abstract Syntax Notation One (ASN.1).

H.225 RAS is, as previously described, used for communication between H.323 endpoints and gatekeepers. UDP port 1719 is used for gatekeeper H.225 RAS communications, while UDP port 1718 is used for gatekeeper discovery via Gatekeeper Request (GRQ) messages. Multicast gatekeeper discovery uses IP destination address 224.0.1.41.

ptg999

[ 90 ]



There are many types of H.225 RAS messages:

■ Gatekeeper discovery: Used by endpoints to find a gatekeeper with which to register. Specific gatekeeper discovery messages include GRQ, Gatekeeper Confirm (GCF), and Gatekeeper Reject (GRJ).

■ Registration and unregistration: This process is used by endpoints and other devices to register their addresses with gatekeepers and join a zone. Registration and unregistration messages include Registration Request (RRQ), Registration Confirm (RCF), Registration Reject (RRJ), Unregister Request (URQ), Unregister Confirm (UCF), and Unregister Reject (URJ).

■ Admission control: These messages are used for CAC and bandwidth management. Specific message types include Admission Request (ARQ), Admission Confirm (ACF), and Admission Reject (ARJ).

■ Bandwidth control: These messages can be used to change the amount of bandwidth during a call. Messages include Bandwidth Request (BRQ), Bandwidth Confirm (BCF), and Bandwidth Reject (BRJ).

■ Endpoint location: Used to retrieve contact information. Messages include Location Request (LRQ), Location Confirm (LCF), and Location Reject (LRJ).

■ Status information: Used to retrieve status information. Specific messages include Information Request (IRQ), and Information Request Response (IRR).

Figure 3-5 illustrates H.225 RAS in relation to H.225 call control signaling and H.245 (assuming direct endpoint call signaling).

RTP/RTCP

H225 RASH225 RAS

H.245 Signaling

H.225 Call SetupH.323

Endpoint #2H.323

Endpoint #1

Gatekeeper

FIguRE 3-5H.225 RAS, H.225 Call Control, and H.245

ptg999

[ 91 ]



H.225 call control signaling takes place on TCP port 1720 and uses Q.931 messages to establish, maintain, and tear down calls. Q.931 messages used for H.225 call control include Setup, Setup Acknowledge, Call Proceeding, Progress, Alerting, Connect, User Information, Release Complete, Status Inquiry, Status, Information, and Notify.

Although H.225 call control signaling can be used for call setup, H.245 must be used to determine a master/slave relationship, exchange terminal capabilities, logical channel signaling, and DTMF relay. Figure 3-6 depicts an example of H.225 call setup and H.245 signaling between endpoints.

FIguRE 3-6H.225 Call Setup and H.245 Signaling Between Endpoints

3. H.225/Q.931 ALERTING

2. H.225/Q.931 PROCEEDING

1. H.225/Q.931 SETUP

6. H.245 Master/Slave Determination Request

5. H.245 Terminal Capability Set Request

4. H.225/Q.931 CONNECT

9. H.245 Terminal Capability Set Ack

8. H.245 Master/Slave Determination Request

7. H.245 Terminal Capability Set Request

12. H.245 Master/Slave Determination Ack

11. H.245 Terminal Capability Set Ack

10. H.245 Master/Slave Determination Ack

15. H.245 Open Logical Channel Ack

14. H.245 Open Logical Channel Request

13. H.245 Open Logical Channel Request

16. H.245 Open Logical Channel Ack

17. RTP/RTCP

H.323Endpoint 2

H.323Endpoint 1

ptg999

[ 92 ]



In Figure 3-6, H.225 call control signaling is used to set up a call between Endpoint 2 and Endpoint 1 (messages 1[nd]4). The Connect message is used to communicate the IP address and TCP port that will be used to set up a connection for H.245.

The two endpoints now negotiate terminal capabilities, such as DTMF relay, hookflash relay, and supported codecs using Terminal Capability Set and Terminal Capability Set Ack messages.

At this point, the endpoints also determine the master/slave relationship using Master Slave Determination and Master Slave Determination Ack messages. The endpoint that becomes the master controls the session.

After capabilities exchange and master/slave determination takes place, the next step is for the endpoints to begin logical channel establishment.

Logical channel establishment comprises the initiation of unidirectional RTP/RTCP streams between the endpoints. Logical channel establishment is initiated using the Open Logical Channel and Open Logical Channel Ack message types.

The Open Logical Channel messages specify media channel parameters, such as UDP ports for RTP/RTCP, codec, DTMF support, and so on. Open Logical Channel Ack is used to indicate that the endpoint will accept the media, as well as to confirm IP addresses and ports to use for RTP.

As you can see from Figure 3-6, regular call setup can be involved. Call setup can be expedited by using a method called H323 Fast Start (or Fast Connect), which involves carrying H.245 information in H.225 messages.

The following example shows the configuration of an IOS H.323 gateway that’s integrated with CUCM:

voice service voip h323 ccm-compatible!interface GigabitEthernet1/0 ip address 10.2.2.1 255.255.255.0 h323-gateway voip bind srcaddr 10.2.2.1!voice class h323 1 h225 timeout tcp establish 3!dial-peer voice 20 voip preference 1 destination-pattern 5...

ptg999

[ 93 ]



voice-class h323 1 session target ipv4:10.2.2.1 codec g711alaw!dial-peer voice 30 voip preference 2 destination-pattern 5... voice-class h323 1 session target ipv4:10.2.2.2 codec g711alaw

As previously discussed, the voice service voip command is used to enter voice service configuration mode.

Next, the h323 command enters the H.323 submode, and the ccm-compatible command configures the gateway for connectivity with a CUCM.

The h323-gateway voip bind srcaddr ip-address command is now used to configure the IP address used as a source IP address for messages sent to a CUCM.

The voice class h323 tag command is then used to configure an H.323 voice class. With the H.323 voice class, the h225 timeout tcpseconds command configures the H.225 TCP establish timeout.

VoIP dial peers are then configured pointing to redundant CUCMs, and the previously defined voice class is referenced within each VoIP dial peer.

H.323 gateways can be configured in CUCM by navigating to Device, Gateway.

Although most problems with H.323 gateways are caused by simple misconfiguration, before finishing this section, it is worth looking at some particular issues that can occur when deploying H.323 gateways in conjunction with CUCM. These issues result in no ringback tone being played when it should be. The following three conditions can occur:

■ No ringback tone on an IP phone when calling a destination in the PSTN: This issue occurs because of the way in which CUCM handles ringback when it is calling out via an H.323 gateway. It can be resolved by configuring the progress_ind alert enable 8 command under the appropriate POTS dial peer.

ptg999

[ 94 ]



This command ensures that the gateway treats the incoming (ISDN) Alerting message as if it contains a progress indicator of 8, which indicates that in-band information is available. (The PSTN does not actually include this progress indicator in the Alerting message in this situation [PI=0].)

■ No ringback tone on a phone in the PSTN when calling an IP phone: This occurs because the IOS gateway does not play a ringback tone to the phone on the PSTN because the Setup message received from the PSTN did not include a progress indicator (PI=0).

The gateway assumes the network is ISDN end to end and that playback tones will be handled by the PSTN, but in fact, that network is not ISDN end to end, and tones are therefore not handled by the PSTN. (The PSTN should have sent the Setup message with a progress indicator of 3.)

This issue can be resolved by configuring the progress_ind setup enable 3 command under VoIP dial peers that are used for the incoming call. This command forces the gateway to play an in-band ringback tone irrespective of the progress indicator in the Setup message.

■ No ringback tone is played to the phone on the PSTN when a call is transferred by an IP phone: This issue is caused because an IOS gateway tears down logical channels when transferring a call, so audio is not sent.

This issue can be solved by running IOS 12.2(3) and later, together with CUCM 3.0(8) and later, and setting the CUCM ToSendH225UserInfoMsg service parameter to True.

IOS H.323 gateways can send DTMF digits in a number of ways, including the following:

■ H.245 alphanumeric: In this case, digit tones are sent out-of-band via H.245 signaling, but this does not include tone duration. (Each digit is assumed to be 500 ms long.)

■ H.245 signal: This is similar to H.245 alphanumeric, but tone duration is sent.

■ RTP-NTE: Tones are sent in the RTP stream using NTE packets, with the payload type value being negotiated.

■ Cisco proprietary: Tones are sent in the RTP stream using payload type 121.

ptg999

[ 95 ]



Analog and TDM SignalingCisco voice gateways can connect to the PSTN and analog devices using a variety of interface and signaling types, including the following:

■ Foreign Exchange Office (FXO)

■ Foreign Exchange Station (FXS)

■ Ear & Mouth (E&M)

■ Direct Inward Dial (DID)

■ Centralized Automated Message Accounting (CAMA)

■ ISDN (BRI/PRI)

■ T1/E1 Channel Associated Signaling (CAS)

These interfaces and signaling types are discussed in the following sections.

FXOAn FXO interface is an RJ-11 connector that provides a connection to a PSTN central office (CO) or PBX interface.

An FXO interface can be configured to use either loop-start or ground-start signaling:

■ Loop-start signaling: This type of supervisory signaling allows the indication of on-hook and off-hook states. Loop-start signaling is vulnerable to a condition known as glare that involves two endpoints seizing a trunk at the same time.

■ Ground-start signaling: This is similar to loop-start signaling in that it is a supervisory signaling type that allows indication of on-hook and off-hook states. However, ground-start is preferred to loop-start on high-usage trunks because it uses current detection to help prevent glare.

ptg999

[ 96 ]



FXSAn FXS interface is an RJ-11 connector that connects to station equipment, including phones, faxes, and modems. In contrast to FXO interfaces, FXS interfaces provide dial tone and ring voltage.

FXS interfaces can be configured to use either loop-start or ground-start signaling. Loop-start signaling is typically used, but in the case of a connection to a PBX or key system, ground start may be necessary.

Analog E&ME&M can stand for Ear and Mouth, Earth and Magneto, or rEceive and transMit. E&M interfaces use an RJ-48 connector, and E&M trunks are often used to provide tie-line connectivity for PBXs.

There are five types of E&M interfaces (types I, II, III, IV, and V), and their main characteristics are as follows:

E&M type I:

■ Common in North America

■ Uses E and M leads for signaling

■ Does not offer ground isolation

■ Cannot be used in a back-to-back configuration

■ Supported on Cisco devices

E&M type II:

■ Uses E, M, Signal Battery (SB), and Signal Ground (SG) leads for signaling

■ Offers ground isolation

■ Can be used in a back-to-back configuration


ptg999

[ 97 ]



E&M type III:

■ Uses E, M, SB, and SG leads for signaling


■ Cannot be used in a back-to-back configuration


E&M type IV:

■ Uses E, M, SB, and SG leads for signaling



■ Not supported on Cisco devices

E&M type V:

■ Common outside North America

■ Uses E and M leads for signaling

■ Does not offer ground isolation



E&M start-dial supervision signaling types include wink-start, delay-start, immediate start, and tone start.

ptg999

[ 98 ]



DIDDID allows calls from the PSTN to be routed directly to extensions on PBXs or other systems, such as CUCM. When using DID, there is no need to use an operator or call attendant to forward calls to internal extensions. Instead, a certain number of dialed digits are forwarded to a PBX or voice gateway, and these digits allow the calls to be automatically routed to internal extensions.

CAMAThe Enhanced 911 (E911) telephone system is, to a great extent, separate from the regular PSTN in the United States, and CAMA is a protocol used to ensure that a call from a particular number is routed to the public service access point (PSAP) that is designated to handle calls from that number. The PSAP is responsible for dispatching emergency services.

CAMA is used for this purpose because it has the capability to send both calling and called party in-band, and the calling party number is used for call routing in the E911 telephone system.

ISDN (BRI/PRI)ISDN is a digital transport service that can support both telephony and data applications over existing telephone wires.

There are two ISDN access methods:

■ Basic Rate ISDN: Provides two 64-Kbps bearer channels and a 16-Kbps signaling channel (2B+D).

■ Primary Rate ISDN: PRI provides 23 or 30 64-Kbps bearer channels, depending on whether it is delivered as T1 or E1, together with a single 64-Kbps signaling channel (23B+D or 30B+D).

At Layer 2, ISDN signaling is provided by the Link Access Procedure on the D channel (LAPD). LAPD is specified in ITU-T Q.920/921.

At Layer 3, ISDN call control signaling and access to services is specified by ITU-T Q.931/932. As previously mentioned, Q.931 allows call setup, maintenance, and teardown.

ptg999

[ 99 ]



Q.931 messages used to establish a call include SETUP, CALL PROCEEDING, ALERTING, CONNECT, and CONNECT ACK. The SETUP message includes information such as bearer capability, transfer rate, calling party number, and called party number. Issues that occur with ISDN are often caused by misconfiguration. But, it is worth briefly looking at one or two issues that are not caused by misconfiguration.

One issue involves a user of an IP phone not hearing a busy signal when calling a busy destination on the PSTN. This occurs because the PSTN has disconnected the call with a normal call-clearing cause code instead of using the (appropriate) user busy cause code.

This issue can be remedied by configuring the voice call convert-discpi-to-prog command on the gateway. This command configures the gateway to change a Disconnect message with a progress indicator to a progress message with a progress indicator. (Audio cut-through will result, and the busy tone will be heard from the PSTN.)

Another issue can occur when using MGCP to backhaul ISDN Q.931 signaling to CUCM. In this case, there are certain cases in which ISDN numbering type and plan mismatches can occur. Usually, ISDN switches ignore numbering plan and numbering type fields in ISDN messages, but if they are configured to route calls partially on the basis of these fields, for example, problems can occur.

If CUCM is sending the proper digits, but calls are not being correctly routed, it might be a good idea to change the calling and called party numbering plan and numbering type to other values. If route patterns contain the @ wildcard, the numbering plan is national (or international if 011 is dialed) and the numbering type is ISDN. If route patterns do not contain the @ wildcard, the called party numbering plan and numbering type are both unknown.

T1/E1 CASIn CAS, signaling operates by “robbing” the least significant bit of information from voice channels and using this to send clocking and framing information. CAS is also known as robbed-bit signaling. So, unlike ISDN, T1 CAS uses in-band signaling.

There are several types of CAS signaling, including the following:

■ Loop-start

■ Ground-start

ptg999

[ 100 ]



■ E&M (wink-start [Feature Group B, FGB], wink-start with wink acknowledge or double wink [Feature Group D, FGD], Feature Group D Exchange Access North America [FGD-EANA], or immediate start)

E&M signaling is often the preferred option for CAS signaling because it avoids glare, it provides answer/disconnect supervision, it can receive automatic number identification (ANI) with FGD, and it can send ANI with FGD-EANA.

E1 R2 is a CAS system whose signaling specifications are defined in ITU-T Recommendations Q.400 to Q.490. One advantage of R2 is that is can provide ANI.

Signaling System 7The Cisco PGW 2200 PSTN gateway offers interconnection of Signaling System 7 (SS7) networks with H.323 and SIP networks.

SS7 was developed by the ITU in the 1970s and is a common channel signaling (CCS) system used in the PSTN that enables functionality including call control, database queries, network operations, and transactions.

As part of the PGW 2200 PSTN gateway, Cisco offers Signaling Link Terminals (SLT) and PGW 2200 hosts. The Cisco SLTs connect to the SS7 network via A or F links, and the SLT terminates Message Transfer Part (MTP) Layer 1 and 2.

Note that in an SS7 network, A-links provide connectivity between signal switching points/signal control points (SSP/SCP) and signal transfer points (STP), with each SSP/SCP typically having at least two A-links to STPs for redundancy. In contrast, F-links provide direct connectivity between signaling endpoints and are used when there are high traffic volumes or no STPs to provide intermediate connectivity.

ptg999

[ 101 ]



Chapter 4Cisco Unity/Unity Connection

There are many Cisco voice-messaging solutions, including the following:

■ Cisco Unity Express (CUE): This router-based platform supports voicemail and integrated messaging. More information on CUE can be found in Chapter 5, “IOS IP Telephony Skills.”

■ Cisco Unity Connection: Based on a Linux server, this platform supports voicemail and integrated messaging.

■ Cisco Unity: Based on Windows Server, this platform provides voicemail and integrated/unified messaging.

Cisco Unity Connection supports local message storage and supports active/active redundancy and directory synchronization. Other features include speech recognition, VPIM support, Cisco Fax server support, SMS message notification, and secure messaging.

Unity integrates with Cisco CUCM and a variety of legacy PBX systems. It can also integrate with other Unity systems and more traditional voicemail solutions. The capability to integrate with PBX and voicemail systems allows a relatively smooth transition to IP telephony.

Depending on the specific release, Unity can be installed on either a Windows 2000 or 2003 server, and it uses either Microsoft Exchange or Lotus Domino as its message store. Note, however, that Lotus Domino is not supported in Cisco Unity 8.0.

IntegrationIt is possible to integrate Unity with a variety of phone systems, including Cisco CUCM and traditional PBXs. Specific types of integration include the following:

■ Cisco CUCM

■ SIP

ptg999

[ 102 ]


Chapter 4: Cisco Unity/Unity Connection

■ Circuit switched (traditional PBX)

■ Circuit switched via PIMG/TIMG

These integration types are discussed in the following sections.

Cisco CuCMTwo overall types of configuration tasks are necessary when integrating CUCM with Unity:

■ CUCM configuration tasks

■ Unity configuration tasks

To configure CUCM for integration with Unity, you must complete the following steps (at a minimum):

Step 1. Configure voicemail ports either manually or using the wizard. The wizard can be accessed by navigating to Advanced Features, Voice Mail, Cisco Voice Mail Port Wizard. A voicemail port enables communication between CUCM and Unity.

Step 2. Create a hunt list by navigating to Call Routing, Route/Hunt, Hunt List.

Step 3. Create a hunt pilot by navigating to Call Routing, Route/Hunt, Hunt Pilot.

Step 4. Configure Message Waiting Indicator (MWI) settings. This can be accomplished by navigating to Advanced Features, Voice Mail, Message Waiting.

Step 5. Create a voicemail pilot by going to Advanced Features, Voice Mail, Voice Mail Pilot. The Voice Mail Pilot number determines the number that is dialed when users press the Message button on their phones.

Step 6. Finally, configure a voicemail profile by navigating to Advanced Features, Voice Mail, Voice Mail Profile. A voicemail profile is assigned to lines and control which voicemail pilot lines use.

ptg999

[ 103 ]



On Unity, you must complete the following steps (at a minimum):

Step 1. Open Cisco Unity Telephony Integration Manager (UTIM, Programs, Cisco Unity, Manage Integrations).

Step 2. Enter the Telephony Integration Setup Wizard (Integration, New) and select Cisco CUCM as the phone system type.

Step 3. Specify information relating to the integration, such as the integration name, CUCM cluster name, IP address/name of the CUCM server, the TCP port used for connection with Unity, MWI on/off extensions (these must match those specified on CUCM), the number of voice messaging ports connecting Unity to CUCM, and the device name prefix.

Step 4. Enter voice-messaging port settings for the integration by selecting whether particular ports should be used for answering calls, message notifications, dial-out MWI, and so on.

Figure 4-1 shows UTIM.

FIguRE 4-1UTIM

ptg999

[ 104 ]



Finally, to complete integration, you must perform the following tasks:

■ Manually configure or import Unity subscribers.

■ In Cisco CUCM Administration, specify a voicemail profile for directory numbers and configure directory numbers to forward calls to voicemail (the voicemail pilot number) as appropriate (no answer, busy, and so on).

Note that when subscribers are added in Unity, the subscriber phone extension must be specified. It is also possible to specify additional alternative extensions (often the subscriber’s cell phone number). The configuration of these extensions is important to ensure that Unity is able to route calls to the correct mailbox when someone calls that subscriber’s numbers, and to ensure that a subscriber is able to directly access his mailbox.

When a call is forwarded by CUCM to Unity, the following information is included:

■ Called party’s extension

■ Calling party’s extension or external phone number (assuming that caller ID is available, if the caller calls from an external phone)

■ The reason the call was forwarded to Unity (the extension is busy, there is no answer, or the extension is configured to forward all calls)

So when, for example, someone calls a subscriber’s phone and CUCM forwards the call to Unity, Unity can associate the call with the correct mailbox by matching the Unity subscriber extension to the extension information provided by CUCM.

Similarly, when a subscriber calls Unity, Unity is able to match the caller ID against the Unity subscriber extensions and, assuming a match, allow direct access to the subscriber’s mailbox. If Unity is unable to match the caller ID against a Unity subscriber’s extensions, Unity prompts the caller for his extension number and password (rather than just, perhaps, a password if the caller ID is recognized).

One of the most common issues with Unity and CUCM integration is with MWI. CUCM will turn on/off the MWI of the phone corresponding to the calling party number sent by Unity.

ptg999

[ 105 ]



It is important to remember, however, that the success or failure of the attempt to turn on/off the MWIs is determined by many factors, including the correct configuration of MWI directory numbers (DN) on Unity and CUCM (they must match) and the correct configuration of calling search spaces and partitions. In particular, the Unity voicemail ports must have a calling search space that allows them to dial the partition containing the MWI DNs, the MWI DNs must have appropriate calling search spaces (used to call subscriber phones), and if overlap in user DNs does exist, partitions must be appropriately ordered in the calling search space.

Another issue that can occur is that MWIs might not turn off when they should. In this case, the solution can be to resynchronize MWIs under the CUCM integration properties in UTIM.

Other issues that can affect MWI include the failure to otherwise properly configure voicemail ports correctly on either Unity or CUCM.

SIPUnity also can be configured to integrate with a SIP phone system via the UTIM and the Telephony Integration Setup Wizard.

As the name suggests, SIP integrations are reliant on SIP for communication (rather than SCCP, which is used for communication in a CUCM/Unity integration). Note, however, that SIP integration is reliant on a SIP proxy server and a SIP gateway.

In UTIM, you must configure the parameters such as integration and cluster names, IP addresses of SIP proxy servers, the number of voice messaging ports that will be used, the contact line number that Unity will register with the SIP proxy, the TCP port for SIP communications, a preferred codec, SIP authentication name and password (if required), and port settings.

When a proxy server forwards calls to Unity, it includes the following information (in the SIP message):

■ The called party extension included in the Diversion header

■ The reason why the call was forwarded in the Diversion header

■ The extension of the calling party (internal calls) or SIP URL of the calling party (external calls with caller ID) in the From header

Unity answers and routes calls on the basis of this information.

ptg999

[ 106 ]



Circuit Switched (Traditional PBX)This type of integration with a PBX relies on the installation of a voice board in the Unity server, and the use of the PBX IP Media Gateway (PIMG) or T1 IP Media Gateway (TIMG). Note that voice boards are no longer supported in Unity 8.0.

When configuring circuit-switched (traditional PBX) integration using a voice board via UTIM, you can choose various integration methods, including the following:

■ Serial: In this case, you can configure parameters such as phone system manufacturer settings, MWI on/off codes, serial integration packet settings, COM port settings, voice-messaging port configuration settings, and so on.

■ Analog: In this case, you can configure parameters such as phone system manufacturer settings, MWI on/off codes, voice-messaging port configuration settings, and so on.

When using a serial integration, there are several cabling configurations. Here are two common ones:

■ An RS-232 cable directly connects the Unity server and the phone system. Voice-messaging lines directly connect the Unity server and the phone system.

■ An RS-232 cable connects the Unity server and a PBXLink box, and digital lines connect the PBXLink box (or boxes, which emulate digital phones) and the phone system. Voice-messaging lines are directly connected between the Unity server and the phone system.

When using a PBXLink box, the phone system sends information including the called party extension, calling party extension (if available), and reason for forwarding to the PBXLink. The PBXLink communicates this information to the Unity server using Simplified Message Desk Interface (SMDI) packets. Also, Unity activates/deactivates MWIs using analog messaging ports (not the serial link, which are used for this in other serial integrations).

When using an analog integration, voice-messaging lines (analog lines) directly connect the Unity server and phone system, and they communicate using DTMF sequences.

ptg999

[ 107 ]



Circuit Switched via PIMgThe PIMG provides connectivity and integration between Unity and PBXs. PIMGs sit directly between Unity and PBXs and emulate digital or analog phones to connect with PBXs (it connects via a digital phone line), and use SIP to connect with Unity over an IP network.

Because a PIMG connects to Unity over an IP network, it is no longer necessary to install a voice card in the Unity server to integrate with a PBX, and it is even possible for a Unity server to be connected to a PIMG (and PBX) over an IP WAN.

MWI and SMDISMDI can be used over RS-232 to connect a PBX to a voicemail system (such as Unity). SMDI is an out-of-band signaling system, which necessitates voice and signaling information being carried on separate paths.

When integrating PBXs and legacy voicemail systems, they can be connected using an RS-232 connection, and automatic number identification (ANI) and Redirecting Dialed Number Identification Service (RDNIS) are used to indicate the calling party number and the original intended recipient (the recipient of the voicemail message), respectively.

SMDI can be used to transmit information about call types, including direct calls and forwarded calls, about MWI on and off states, and about error states. SMDI messages are comprised of ASCII characters and symbols.

SMDI Messages with Direct and Forwarded CallsThe format of SMDI messages with direct calls is as follows:

<CR><LF>MD md-num md-port fwd-type<0x20>src-num<0x20><CR><LF><^Y>

The components of this message are as follows:

■ <CR>: A carriage return

■ <LF>: A line feed

ptg999

[ 108 ]



■ MD md-num md-port: Message desk, message desk number (md-num, usually 001), message desk port (md-port, 0000 to 9999)

■ Fwd-Type: Indicates the forwarding type, D (direct call)

■ <0x20>: ASCII space

■ src-num: The number of the station from which the call originated (ANI)

■ <^Y>: Ctrl-Y

The format of SMDI messages with forwarded calls is as follows:

<CR><LF>MD md-num md-port fwd-type fwd-station<0x20>src-num<0x20><CR><LF><^Y>

The components of this SMDI message format have already been described, with the exception of the following:

■ fwd-type: As previously mentioned, this indicates the forwarding type, but in this case, the type will be A (forward all calls), B (forwarded on busy), N (forwarded on no answer), or U (forwarded for unknown reason).

■ fwd-station: The RDNIS (original called party number).

SMDI Messages with MWI On/OffThe format of SMDI messages used with MWI on is as follows:

OP:MWI<0x20>stn-num!<^D>

In this case, OP indicates that an MWI should be turned on for the specified station number, and the <^D> (Ctrl-D) indicates the end of transmission.

The format of SMDI messages used with MWI off is as follows:

RMV:MWI<0x20>stn-num!<^D>

ptg999

[ 109 ]



In this case, RMV is used to request that MWI should be turned off for the specified station number.

Note that one issue that can occur with SMDI on CallManager is that MWI is received but does not function correctly. In this case, it is a good idea to check that the MwiSearchSpace field in the Cisco Messaging Interface (CMI) specifies the partition that corresponds to the phone in question. (Partitions should be correctly configured—they are case sensitive—and separated by colons.)

SMDI Error MessagesSMDI error messages are sent using the following format:

<CR><LF>MWI stn-num!<0x20>error-code<CR><LF><^Y>

The error code can be one of the following:

■ INV: Indicates that the station number is invalid

■ BLK: Indicates a block condition

Call HandlersUnity uses call handlers to process and forward calls based on input from users.

Call handlers consist of a specific set of instructions or actions that enable Unity to answer calls, play a greeting, prompt callers, take messages, provide recorded information, and transfer calls.

Call handlers can be used for a number of simple or complex purposes, such as providing an auto-attendant, transferring calls, playing messages, receiving messages, and providing audio text applications. Unity subscribers also have associated call handlers.

There are several default call handlers in Unity (which are undeletable), including the following:

■ Opening greeting

ptg999

[ 110 ]



■ Operator greeting

■ Goodbye

The opening greeting is used for an auto-attendant (the default opening greeting provided by Cisco can be modified), the operator greeting call handler is used when calls are routed to an operator, and the goodbye call handler is used to play a goodbye message and close a call.

In addition, two types of call handlers are used for special purposes: directory call handlers and interview call handlers.

The directory call handler can be used to search for Unity subscribers using a name or an extension. It is also possible to create your own directory handlers. As the name suggests, interview call handlers can be used to conduct interviews with callers, consisting of up to 20 questions. Each question is played, and the caller then records an appropriate answer. Unity includes a sample interview call handler, by default.

You can create and modify call handlers by going to Call Management, Call Handlers in Unity system administration (SA). You can configure directory handlers and interview handlers by going to Call Management, Directory Handlers and Call Management, Interview Handlers, respectively.

Cisco Unity Greetings Administrator (CUGA) is a feature that allows owners of call handlers (subscriber or distribution list) to perform tasks such as rerecording call-handler greetings and enabling/disabling a call handler using Unity’s telephone user interface (TUI).

It is possible to configure CUGA by doing the following (at a minimum):

Step 1. Configure a phone number on the phone system to use for calling CUGA.

Step 2. Add a routing rule to forward calls from that phone number to CUGA. To do this, go to Call Management, Call Routing, Direct Calls, click Add, and then specify the phone number in the Dialed Number field of the new routing rule. Then, click Greetings Administrator in the Send To field.

Step 3. Assign a unique extension to the call handler. This can be achieved by going to Call Management, Call Handlers, Profile, selecting and viewing the call handler you want to allow access to via CUGA, and specifying the unique extension that you want to configure for the call handler in the Extension field.

ptg999

[ 111 ]



Call-handler owners can then access CUGA if they have the following information: phone number to dial for CUGA, the ID of the call-handler owner, the password of the call-handler owner, and the extension of the call handler.

Note that the RSA SecurID system cannot be used for subscribers who use CUGA.

Unified MessagingAs previously mentioned, Unity can not only provide voicemail, but can provide a comprehensive unified messaging solution, including voicemail, e-mail, faxes, text-to-speech support, and other applications. As a unified messaging solution, Unity uses a single message store to store voicemail, e-mail, and fax messages, and allows subscribers to retrieve these messages using either a phone or a PC.

To provide unified messaging, Unity interfaces with several elements, including a directory, a mail store, IIS, and SQL.

If the mail store is provided by Microsoft Exchange, Unity also integrates with Microsoft Active Directory (AD). Unity requires a schema extension to AD, and when the Cisco Unity schema is added to AD, it grows by as little as 10 percent. Unity extends three schema classes (User, Group, and Contact) and creates a new class (Unity Location).

An alternative to using Microsoft Exchange as the message store is to use Lotus Domino. When using Lotus Notes as the message store, another piece of software, called Domino Unified Communications Services (DUCS), is required.

Voice Profile for Internet MessagingBesides having the capability to integrate with different types of PBX, Unity can also integrate with different types of voicemail systems. Integration of Unity with other voicemail systems is referred to as Unity networking.

There are two overall categories of Unity networking:

■ Networking with other Unity systems: This can be implemented using digital networking, Simple Mail Transfer Protocol (SMTP) networking, or Voice Profile for Internet Mail (VPIMv2) networking, depending on Unity versions and particular networking requirements.

ptg999

[ 112 ]



■ Networking with traditional/non-Unity systems: This can be implemented using bridge networking, Audio Messaging Interchange Specification (AMIS) networking, or VPIM networking.

The specific methods of networking Unity can be described as follows:

■ Digital networking: This type of networking can be used to integrate Unity systems that share the same directory.

■ SMTP networking: This can be used to integrate Unity systems that do not share a directory, but that are connected via IP.

■ VPIM networking: This allows integrations of Unity with either other Unity systems or non-Unity systems over an IP network, such as the Internet. In this case of Unity-Unity system integration, VPIM networking can be used when the systems do not share a directory (AD forest).

■ Bridge networking: This can be used to integrate Unity with an Octel voicemail system, and requires the use of a bridge server.

■ AMIS networking: This allows Unity to integrate with non-Unity systems over analog lines.

VPIM is a standard that is used by messaging systems to communicate messages over the Internet or other IP networks. As already mentioned, Unity can be configured to use VPIM to integrate with other VPIM messaging systems, including other Unity systems or non-Unity systems.

VPIM is based on the SMTP and Multipurpose Internet Mail Extension (MIME) protocols. Because SMTP transport is used with VPIM, it is essential that the Exchange server used by a local Unity server be able to exchange e-mail with the e-mail system that the remote voicemail system is using.

A VPIM message sent between messaging systems consists of one or more MIME encoded parts, and it can contain MIME-encoded voice messages, text messages, fax messages, and so on. A message can also include the sender’s spoken name.

When voice messages are sent using VPIM, they are typically converted into G.726 (for non-Unity systems), and when fax messages are sent, they are encoded using a TIFF-F format.

Before messages can be sent between VPIM systems, they must be encoded as MIME messages, and with Unity, this task is handled by a component called the Cisco Unity Voice Connector for Exchange (formerly referred to as the Internet Voice Connector [IVC]).

ptg999

[ 113 ]



The Cisco Unity Voice Connector for Exchange is also responsible for handling incoming VPIM messages, in conjunction with a component called the VPIM Transport Event Sink.

Note that outbound messages are converted from a MAPI to a MIME format, the message To/From fields are properly formatted, the voice attachment is converted to G.726 (if appropriate), and the recorded voice name and/or vCard are attached (if appropriate).

For inbound messages, phone prefixes are removed from the To/From fields (if appropriate), the recipient of the message is validated, the message is converted from a MIME to a MAPI format, a directory update message is generated (if appropriate), and the message is delivered to the subscriber mailbox. It is also possible to specify whether incoming messages should be converted into G.711 (mu-law), GSM 6.10, or G.729a, or stored in the format in which they were received.

Configuration of VPIM in Unity consists of the following overall steps:

Step 1. Run ConfigMgr.exe to create the UVPIM account. This is necessary if you want to configure Unity to automatically update the VPIM subscriber directory.

Step 2. Customize the primary location profile settings (Network, Primary Location, Profile). This includes entering a name for the location and a Dial ID (this identifies the location to Unity), recording a voice name, specifying a dialing domain

(if appropriate), and configuring an SMTP domain name.

Step 3. Create delivery locations for each of the remote systems (Network, Delivery Locations, Profile). This involves entering a name and Dial ID, selecting VPIM, recording a voice name for the location, entering the SMTP domain name

of the remote (e-mail) system, indicating whether incoming messages should be converted to a different audio format, and so on.

Step 4. Create VPIM subscriber accounts (optional).

Step 5. Customize the delivery location settings that control VPIM directory updates (optional).

Step 6. Extend identified subscriber messaging to include VPIM subscribers (optional).

Before configuring VPIM networking on Unity, you must complete several preliminary tasks, including extending the AD schema and installing the voice connector. Extending the AD schema is also necessary when configuring bridge networking (but not digital or AMIS networking).

ptg999

[ 114 ]



Note that, as described in Step 2, it might be necessary to specify a dialing domain when customizing the primary location profile settings.

A dialing domain is a group of Unity servers that share the same directory and do not require subscribers to use any type of prefix when performing transfers and sending messages between the servers. (Extensions must be unique within the dialing domain.)

When configuring Step 2, consider that if the installation includes only one Unity server and you want to enable identified subscriber messaging to include VPIM subscribers, you should specify a dialing domain name. Also, if the installation includes more than one networked Unity server (integrated with the same phone system), you might have already added the server being configured into the dialing domain. If not, you should enter or select it during Step 2 (it is case sensitive).

ptg999

[ 115 ]



Chapter 5IOS IP Telephony Skills

The Cisco IP telephony product range includes IOS-based devices and mechanisms, including Survivable Remote Site Telephony (SRST), Cisco Unified Communications Manager Express (CME), and Cisco Unity Express (CUE).

Survivable Remote Site TelephonySurvivable Remote Site Telephony (SRST) is a feature that ensures that IP phones can continue to function even if they are unable to communicate with CUCM. During a failure, Cisco IP phones register with the local SRST router, which provides call processing and control. If Cisco IP phones detect that CUCM has come back online, they can fail back to that CUCM after a configurable interval (connection monitor duration). Cisco IP phones do not fail back immediately to ensure that the CUCM in question is back online and stable.

SRST is usual in deployments where Cisco IP phones at remote sites have to connect to CUCMs at a central site. In this case, SRST can be configured at the remote site to provide redundancy in the event of a failure of connectivity to CUCM at the central site.

Basic ConfigurationThe basic configuration of SRST is relatively straightforward. First, Cisco IP phones must be configured to fail over to the SRST router (this is achieved by specifying an SRST reference within Cisco CUCM Administration), and then the SRST router to which phones are configured to fail over must be configured for SRST.

The following example shows the minimal SRST router configuration (with SCCP):

call-manager-fallback ip source-address 10.1.1.1 port 2000 max-ephones 20 max-dn 40

ptg999

[ 116 ]


Chapter 5: IOS IP Telephony Skills

The call-manager-fallback command is used to enable SRST and enter call-manager-fallback configuration mode.

The ip source-address ip-address port port [any-match] [strict-match] command configures the router to receive (SCCP) messages on the specified IP address, using the specified port. In the example, the router is configured to receive messages on IP address 10.1.1.1 using the default port of 2000. The any-match keyword (the default) disables strict IP address checking for registration, and the strict-match keyword enables strict IP address checking.

Next, max-ephones max-phones is used to specify the maximum number of Cisco IP phones (ephones) that can be supported by the router.

The max-dn max-directory-numbers command is used to configure the maximum number of directory numbers (DN) supported by the router.

Another command that is optional but can be useful is limit-dn {7910 | 7935 | 7940 | 7960} max-lines. This command can limit the number of directory number lines on Cisco IP phones during SRST fallback. This can be useful if an SRST router cannot support all the multiline phones at a remote location, and you instead want to limit each phone to a certain (smaller than usual) number of lines.

An SRST reference must also be configured on CUCM for SRST to operate correctly. If the SRST router is the default gateway for remote site phones, it is possible to specify the default gateway as the SRST reference in the device pool (System, Device Pool). If the SRST router is not the default gateway, the SRST reference must be configured by navigating to System, SRST under Cisco CUCM Administration.

Note that if you are configuring SRST on an MGCP gateway, the call-manager fallback-mgcp and service [alternate | default] commands are necessary to enable the fallback feature and ensure that the MGCP gateway can provide call processing with SRST or other configured applications, and to load and configure a specific standalone application on a dial peer.

It is also possible to configure DHCP on the SRST router using the ip dhcp pool, network, option 150 ip, and default-routercommands to configure the DHCP pool name, pool address, DHCP option 150 (TFTP server address for phone image download), and the default router address, respectively.

Some useful commands to verify the correct operation of SRST are as follows:

■ debug ephone register: Displays the Cisco IP phone registration process in operation.

■ debug ephone keepalive: Displays keepalive debugging for Cisco IP phones.

ptg999

[ 117 ]



■ debug ephone state: Displays state debugging for Cisco IP phones.

■ debug ephone detail: Displays detailed debugging for Cisco IP phones.

■ debug ephone error: Debugs error conditions for Cisco IP phones.

■ debug ephone statistics: Debugs call statistics for Cisco IP phones.

■ debug ephone pak: Displays at a voice packet level (the contents of one in every 1024 packets are displayed).

■ debug ephone raw: Provides low-level protocol debugging for all Skinny Client Control Protocol (SCCP) messages.

■ show ephone: Shows the Cisco IP phones that have already registered.

Voicemail IntegrationIt is also possible to configure voicemail integration for phones at remote sites during a loss of direct connectivity to the central site CUCM.

Voicemail integration can be configured using the following steps:

Step 1. Specify the voicemail number.

Step 2. Configure call forwarding to voicemail.

The voicemail pilot number can be configured as follows:

call-manager-fallback voicemail 955512345678

The voicemail phone-number command is used to configure the number that is speed dialed when a user presses the Messages button on a Cisco IP phone. During normal operation, CUCM is configured with the voicemail pilot number, and this is used when the Messages button is pressed. But, when using SRST mode, the router must route calls to the central site voicemail system over the public switched telephone network (PSTN) using the number specified with the voicemail command.

ptg999

[ 118 ]



Next, you must configure call forwarding to voicemail using the call-forward command:

call-manager-fallback call-forward busy 955512345678 call-forward noan 955512345678 timeout 10

The call-forward busy directory-number command is used to specify the number to which calls will be forwarded if phones are busy. In this case, calls are forwarded to voicemail if phones are busy. (The number matches that configured using the voicemailcommand.)

The call-forward noan directory-number timeout seconds command similarly configures the number to which calls will be forwarded if there is no answer. (The call is forwarded after the configured timeout.) In this example, calls are forwarded to voicemail if there is no answer. (The configured number again matches that specified using the voicemail command.)

If there is ISDN connectivity to the PSTN and RDNIS/ANI is provided in ISDN Setup, the configuration given so far might be enough for forwarded calls to be correctly routed to the correct mailbox on the voicemail system. (The voicemail system uses RDNIS to identify the correct mailbox.) However, depending on the precise configuration, it might also be necessary to choose Redirecting Number IE Delivery – Outgoing on the central site CUCM gateway configuration page (Device, Gateway) to ensure that RDNIS/ANI is delivered to the voicemail system along with the call. If RDNIS/ANI is not delivered to the voicemail system, it won’t know which mailbox to deliver the call to, and the caller will hear the voicemail system’s opening greeting instead of the appropriate mailbox greeting.

If PSTN connectivity is analog/T1 CAS, DTMF tones are used to route calls to the appropriate mailboxes and additional configuration is necessary (see the following example):

call-manager-fallback voicemail 955512345678!vm-integration pattern direct * CGN pattern ext-to-ext busy # FDN #2 pattern ext-to-ext no-answer # FDN #2 pattern trunk-to-ext busy # FDN #2 pattern trunk-to-ext no-answer # FDN #2

ptg999

[ 119 ]



The vm-integration command is used to enable voicemail integration with DTMF and analog voicemail systems and enter voicemail integration mode.

Next, the pattern direct, pattern ext-to-ext, and pattern trunk-to-ext commands are used to configure the DTMF digit pattern forwarding that is necessary to interact with the voicemail system when

■ The user presses the Messages button on a Cisco IP phone (pattern direct).

■ An internal extension tries to connect to another extension, but that extension is busy or there is no answer (pattern ext-to-ext).

■ An external (trunk) caller tries to connect to an internal extension, but that extension is busy or there is no answer (pattern trunk-to-ext).

The busy and no-answer keywords are used with these commands to dictate the particular circumstance. (The called phone is busy or there is no answer from the called phone.)

When configuring the pattern direct, pattern ext-to-ext, or pattern trunk-to-ext commands, you must also specify combinations of alphanumeric strings (fewer than four digits in length), as well as the calling number (cgn), called number (cdn), or forwarding number (fdn) to be sent to the voicemail system.

Figure 5-1 shows the relationship between the calling number (CGN), called number (CDN), and forwarding number (FDN).

Voice MailPhone 1

(Ext: 1001)

Phone 2(Ext: 1002)

Busy or No Answer

Calling Number(CGN)

Forwarding Number(FDN)

Calling Number(CDN)

FIguRE 5-1Relationship Between CGN, CDN, and FDN

ptg999

[ 120 ]



So, the calling number (CGN) is the number of the call originator, the forwarding number is the number of the extension that forwarded the call to voicemail, and the called number is (in this example) the voicemail system.

Therefore, based on Figure 5-1 and the configuration example given previously, the command pattern ext-to-ext busy # FDN #2would cause 955512345678 to be dialed and the DTMF pattern #1002#2 to be sent when extension 1002 is called from an internal extension but it is busy. The number 955512345678 is the voicemail system number configured using the voicemail command, and DTMF digit patterns (tones) corresponding to #1002#2 are played to the voicemail system when it answers; this causes the voicemail system to route the call directly to the mailbox corresponding to extension 1002 and play the appropriate greeting. The precise DTMF digit patterns that are required depend on the voicemail system.

Note that the command pattern direct * CGN would cause 955512345678*1002 to be dialed if the Messages button was pressed on the phone corresponding to extension 1002. (There is no forwarding number in this case.)

Call TransferSRST routers support call transfer between Cisco IP phones that are registered with them by default. However, if call transfer to other destinations is required, the following two commands are required:

■ transfer-pattern: Specifies the destination phone numbers to which Cisco IP phones are allowed to transfer calls

■ transfer-system: Configures the method used for call transfer

The following keywords can be used with the transfer-system command to configure the call transfer method:

■ blind: When using this Cisco proprietary method, calls are transferred without the transferor first connecting to the destination. This method is not recommended. (full-blind or full-consult are recommended instead.)

■ full-blind: This specifies the H.450.2 standard for call transfer. Again, calls are transferred without the transferor first connecting to the destination.

■ full-consult: This again specifies the H.450.2 standard for call transfer but in this case, calls are transferred with the transferor first connecting to the destination. Two lines are required for this type of call transfer, and if a second line is not available, the full-blind method is used instead.

ptg999

[ 121 ]



■ local-consult: This also uses the H.450.2 standard for call transfer. This method is used only for local transfers, and calls are transferred with the transferor first connecting to the destination. Two lines are required for this type of call transfer, and calls fall back to the blind method for nonlocal consultation or nonlocal transfer target.

Note that the dual-line keyword can be used with the max-dn command to set all IP phones to one virtual port with two channels. (This can be useful if phones do not have two lines.) This command can be used to allow call transfer, call waiting, and conferencing by allowing two calls to occur simultaneously on one line.

The following is an example of the configuration of call transfer on an SRST router:

call-manager-fallback transfer-pattern 1234… transfer-system full-consult

The configuration in the example allows call transfer to destinations matching the pattern 1234.... using the full-consult method, where each dot represents a single digit from 0 to 9.

Call ForwardingAs with call transfer, call forwarding is enabled by default between Cisco IP phones that are registered with an SRST router. To enable H.450.3 call forwarding for nonlocal numbers, you must configure the call-forward pattern pattern command.

For example, the call-forward pattern .T command forwards all calls using H.450.3. (The pattern in this example matches all calling party numbers.) This means that if a directory number has forwarded its calls and an incoming call matches that number, an H.450.3 response is sent back to the calling party to ask that the call be placed again using the forward-to destination.

Other call forwarding commands include call-forward busy and call-forward noan, which were explained in the previous section.

Dial Plan ConsiderationsWhen Cisco IP phones register with the SRST router, the router associates the phones with a virtual dial peer, and this allows the locally registered phones to call each other. But, the dialplan-pattern tag pattern extension-length length command will probably be

ptg999

[ 122 ]



necessary to allow inbound calls to match the extensions of the local phones. This command also ensures that a full E.164 address is sent as the ANI in outbound calls.

The dialplan-pattern command causes the SRST router to create an additional virtual dial peer for local extensions corresponding to the pattern specified in the command. In this way, this command can be used to map the DNIS sent by the PSTN to a local extension.

So, for example, the SRST router might receive a call with the DNIS 5055512345, but the local extensions range might, for example, be from 340 to 350, so no match occurs and the call fails. But, if the dialplan pattern 1 5055512... extension-length 3 command is specified, the SRST router is able to match the DNIS 5055512345 with a local virtual dial for 5055512345 (the additional virtual dial peer created for extension 345), and the call succeeds.

Cisco Unified Communications Manager ExpressCisco Unified Communications Manager Express (CME) provides call processing and enterprise telephony features in a small to medium-size network environment.

Basic ConfigurationAfter CME software is installed, there are several basic configuration tasks to complete. These basic tasks include the following:

1. Configuring network settings

2. Setting CME parameters

3. Configuring phones

Network configuration consists of

■ Configuring DHCP

■ Configuring NTP

ptg999

[ 123 ]



■ Building the XML configuration files for Cisco IP phones

■ Specifying DTMF relay for H.323 networks (for multisite installations)

The configuration of DHCP is the same as that described in the section, “Survivable Remote Site Telephony,” with the exception that the TFTP server address configured using the option 150 ip command must be the CME router itself.

NTP can be configured using the clock timezone, clock summer-time, and ntp-server commands. This NTP configuration allows CME to synchronize its clock to a clock source.

If it’s a multisite installation, DTMF relay for H.323 networks must also be configured by using the dtmf-relay h245-alphanumericcommand, as shown in the following example:

dial-peer voice 200 voip destination-pattern 1000 session target ipv4:10.1.1.50 codec g711ulaw dtmf-relay h245-alphanumeric

The dtmf-relay h245-alphanumeric command is required by IP phones connected to CME systems, and it is used to specify that DTMF digits are transported as out-of-band H.245 messages (rather than in-band) from the voice RTP stream when they are sent over VoIP connections. This ensures that DTMF digits are not distorted, which can happen if they are transported in-band.

Although it’s not required in this particular scenario, the dtmf-relay command allows you to specify the Cisco proprietary (cisco-rtp), RTP-NTE (rtp-nte), and H.245 signal (h245-signal) methods of DTMF relay. The Cisco proprietary method uses RTP payload type 121 for DTMF relay, the RTP-NTE method uses the method defined in RFC 2833 using Named Telephony Event (NTE) packets, and the H.245 signal method uses the signal user input indication method.

Once network settings are configured, CME parameters can be set. Setting CME parameters includes

■ Setting values for telephony parameters

■ Rebuilding phone configuration files

■ Resetting phones to download new parameter values

ptg999

[ 124 ]



The tftp-server flash:filename command is used to allow access to firmware files for Cisco IP phones. (It must be configured for each phone firmware file required by phones at the site.)

As shown in the following example, the phone parameters must be configured in telephony service configuration mode:

telephony-service max-ephones 50 max-dn 250 load 7960-7940 P00303020209 ip source-address 10.1.1.1 port 2000 create cnf-files transfer-system full-consult

The telephony-service command is used to enter telephony service configuration mode.

The max-ephones max-phones command is used to specify the maximum number of Cisco IP phones that this CME system will support.

The maximum number of extensions on the CME system is configured next using the max-dn max-directory-numbers command.

The load phone-type firmware-file command is then used to identify the firmware file that will be used by particular phone types. In this example, file P00303020209 will be used by phone models 7940, 7940G, 7960, and 7960G.

ip source-address ip-address [port port] is used to configure the IP address and port (default, 2000) that will be used by the CME system for IP phone registration.

The create cnf-files command is used next to build XML configuration files for Cisco IP phones.

Call transfer is then configured using the transfer-system command. This command was described in the previous section, so is not described again here.

Finally, the reset command (not shown) can be used to restart phones associated with CME.

ptg999

[ 125 ]



After configuring CME parameters, phones must be configured, as shown in the following example:

ephone-dn 10 number 1001 name sales!ephone 5 mac-address 0009.E8FC.1B38 type 7960 button 1:10

The ephone-dn dn-tag [dual-line] command creates an ephone-dn and enters ephone-dn configuration mode. The optional dual-line keyword can be used to configure two voice channels on one voice port, which can be useful for call transfer, call waiting, and conferencing.

The number number and name name commands configure an extension number for this ephone and (optionally) specify a name used for caller ID and directory listing (this is automatically created). The directory entry command can used to manually add entries to the directory, and the service dnis dir-lookup command can be used to display the called name associated with each number configured using the directory entry command.

Next, the ephone phone-tag command is used to enter ephone configuration mode, and the mac-address [mac-address] command configures the MAC address associated with a phone.

Finally, the button button-number{separator}dn-tag command associates a phone button number and line characteristics with an extension (ephone-dn). In this example, phone button 1 will use a normal ring (denoted by the colon character) and will be associated with the extension previously created using the ephone-dn 25 command (1001).

Additional CME Features and FunctionalityA multitude of features can be configured on CME, and this section focuses on some of the more commonly configured ones, including the following:

■ Dial plan support

■ Call forwarding

ptg999

[ 126 ]



■ Call transfer

■ Call hunt and ephone hunt groups

■ Voicemail support

Dial Plan SupportThe following commands and mechanisms can be useful when integrating an internal numbering scheme with external numbering plans:

■ dialplan-pattern

■ Voice translation rules

The dialplan-pattern command has already been explained, but it is worth describing the use of the optional extension-pattern keyword here. The extension-pattern keyword allows the leading digits of an extension pattern to be stripped and replaced with corresponding leading digits of the dial plan pattern:

telephony-service dialplan-pattern 1 5551234500 extension-length 3 extension-pattern 2..

In this example, extensions in the range 2XX are mapped to numbers 55512345XX. Extension 299 would therefore be mapped to 5551234599.

If necessary, voice translation rules can be used to perform more extensive digit manipulation. Translation rules allow you to manipulate calling numbers, called numbers, numbering plan, numbering type, and so on.

The configuration and application of translation rules requires you to do the following:

1. Configure translation rules.

2. Configure the translation profile.

3. Apply the translation profile.

ptg999

[ 127 ]



The following example shows a translation rule:

translation-rule 1 rule 1 /^1234/ /5678/ rule 2 /^4321/ /8765/

In the example, the translation-rule name-tag command is used to specify the translation rule name and enter translation rule configuration mode.

Next, the rule precedence /match-pattern/ /replace-pattern/ [type {match-type replace-type} [plan {match-type replace-type}]] command is used to create a translation rule.

As the name suggests, the precedence parameter specifies the precedence of the translation rule (1 to 15). The precedence determines the order in which the rules are executed.

The match-pattern and replace-pattern parameters are used to match and replace Stream EDitor (SED) expressions. The / character is a delimiter.

So, in the example, call information beginning 1234 is translated into 5678, and call information beginning 4321 is translated into 8765. Note that the caret (^) character matches the beginning of a line. If you want to replace 1234 or 5678 wherever they appeared in a number pattern, on the other hand, you would not include the caret character. Any characters that are not matched and replaced by the translation rule are simply preserved in this example.

Having created translation rules, the next step is to configure translation profiles. The following example shows the configuration of a translation profile:

voice translation-profile mjlprofile translate calling 1 translate called 2 translate redirect-called 3

The voice translation-profile name command in the example configures the profile name and enters translation profile configuration mode.

ptg999

[ 128 ]



The translate {called | calling | redirect-called | redirect-target} translation-rule-number command is then used to associate translation rules with the profile. The called keyword associates a rule with called numbers; the calling keyword associates a rule with a calling number; the redirect-called keyword associates a rule with redirected called numbers; and the redirect-target keyword associates a rule with transfer-to numbers and call-forwarding final destination numbers.

Translation profiles can be applied to all VoIP calls, to a particular dial peer, ephone-dn, interface, trunk group, and so on.

The following example shows the assignment of a translation profile to a dial peer:

dial-peer voice 10 voip translation-profile incoming mjlprofile translation-profile outgoing mjlprofile

The translation-profile {incoming | outgoing} name command assigns the specified translation profile to the dial peer in the specified directions.

Translation rules can be complex, so it is a good idea to review a few more examples, which can be found in the document, “Voice Translation Rules” (document ID 61083):

www.cisco.com/en/US/tech/tk652/tk90/technologies_tech_note09186a0080325e8e.shtml

Another document worth looking at is, “Number Translation Using Voice Translation Profiles” (document ID 64020):

www.cisco.com/en/US/tech/tk652/tk90/technologies_configuration_example09186a00803f818a.shtml.

Call ForwardingCall forwarding commands for CME include the following:

■ call-forward pattern: Configures the H.450.3 standard for call forwarding

■ call-forward all: Forwards all calls to the specified number

■ call-forward busy: Forwards calls for a busy extension to the configured number

■ call-forward noan: Forwards all calls for an extension that does not answer to the specified number

www.cisco.com/en/US/tech/tk652/tk90/technologies_tech_note09186a0080325e8e.shtml

www.cisco.com/en/US/tech/tk652/tk90/technologies_configuration_example09186a00803f818a.shtml

ptg999

[ 129 ]



The call-forward pattern command can be configured in telephony service configuration mode, while the call-forward all, call-forward busy, and call-forward noan command can all be configured under ephone-dn configuration mode.

Call TransferCall transfer on CME is configured much like it is for SRST. The following is a sample CME configuration for call transfer:

telephony-service transfer-system full-consult transfer-pattern .T

The significant difference in the example is that the transfer-system and transfer-pattern commands can be configured under telephony service configuration mode with CME. Note that it is also possible to override the global call transfer type configuration (as shown in the example) for a particular ephone-dn by configuring the transfer-system {blind | consult} in ephone-dn configuration mode.

Call Hunt and Ephone Hunt groupsCall hunt allows a search among ephone-dn dial peers for an available ephone-dn to answer a call. The following example shows the configuration of call hunt:

ephone-dn 10 number 1001 no huntstop preference 1 call-forward noan 1501!ephone-dn 20 number 1001 preference 2 call-forward busy 1501 call-forward noan 1501!ephone 1 mac-address 0009.E8FC.1B38 button 1:10 2:20

In this example, two ephone-dns are configured with the same extension (1001). One of the DNs is assigned to button 1 of ephone 1, and the other DN is assigned to button 2 of ephone 1. The second of the two DNs provides call waiting notification for DN 1001 if the

ptg999

[ 130 ]



first line is busy. Because the no huntstop command is configured on ephone-dn 10, incoming calls can hunt to ephone-dn 20 if the first line is busy. (Huntstop is enabled by default.) Call forwarding to extension 1501 is used in this example to provide connectivity to voicemail if there is no answer on either line or both lines are busy. (The voicemail configuration is not shown.)

One important thing to note about the configuration of the ephone-dns 10 and 20 is the configuration of the preference command. This is used to control the order in which call hunt takes place, with lower numbers given higher preference.

A different type of hunt mechanism is ephone hunt groups. In this type of configuration, an incoming call to a hunt-group pilot number can be redirected to a group of ephone-dns. Ephone hunt group configuration is shown in the following example:

ephone-dn 10 number 1000!ephone-dn 20 number 1500!ephone-dn 30 number 2000!!ephone 5 mac-address 0009.E8FC.1111 button 1:10!ephone 6 mac-address 0009.E8FC.2222 button 1:20!ephone 7 mac-address 0009.E8FC.3333 button 1:30!!ephone-hunt 1 peer pilot 5000 list 1000, 1500, 2000 final 6000 timeout 10

ptg999

[ 131 ]



In this example, there are three ephones (5, 6, and 7), each with a single assigned DN (1000, 1500, and 2000).

The ephone-hunt hunt-tag {peer | sequential | longest-idle} command is used to begin the configuration of an ephone hunt group and specify that the call hunt pattern will be peer.

There are three call hunt patterns, as follows:

■ peer: Configures hunting in a circular manner among the hunt group member DNs, starting with the DN to the right of the last DN to ring.

■ sequential: Configures hunting in a sequential manner, left to right, starting with the leftmost DN configured in the list.

■ longest-idle: Specifies hunting based on how long DNs have been idle. In this case, the call will go to the DN that has been idle the longest.

Next, the pilot number command is used to specify the hunt group pilot number (that is, the number that callers dial to reach this hunt group). In this example, the hunt pilot number is 5000. The secondary keyword can optionally be used to associate a second phone number with the pilot. This second phone number can also include wildcards in the form of periods (.).

The members of the ephone hunt group are then defined using the list dn-number[, dn-number...] command; the members in this example are DNs 1000, 1500, and 2000.

The final final-number command is then used to configure the final number to call in the hunt group (in this example, 6000). The final number to call can be an ephone DN, a voicemail pilot number, a hunt group pilot, or an FXS number.

The following are some other useful ephone hunt group commands:

■ hops: Configures the number of hops that a call to the hunt group proceeds before it is sent to the final number.

■ timeout: Specifies the number of seconds after which an unanswered call is sent to the next member of the hunt group. The default is 180 seconds.

■ max-timeout: The maximum cumulative timeout for all ephone-dns in the group, after which the call is sent to the final number.

ptg999

[ 132 ]



Voicemail SupportCME can support several voicemail systems, including CUE, Cisco Unity, Cisco Unity Connection, and analog voicemail systems. Cisco Unity Express is discussed in the following section, but CME integration with Cisco Unity and analog voicemail systems is discussed in this section.

Integration with Cisco UnityCME can be deployed with Cisco Unity in two base configurations:

■ A standalone CME system with a Cisco Unity system

■ Multiple CME systems with a centralized Cisco Unity system

Figure 5-2 illustrates these two deployment options.

FIguRE 5-2CME/Unity Deployment Options

Multiple CMEs withCentralized Cisco Unity

Standalone CME with Cisco Unity

Central Site

Cisco Unity

CME(Remote Site)

CME

CME(Remote Site)

CME(Remote Site)

PSTN WAN

Cisco Unity

CME

PSTN

ptg999

[ 133 ]



Of the two CME/Unity deployment options, deploying multiple CME systems with a centralized Cisco Unity system often is the most sensible. This is because although Cisco Unity can support thousands of users, a single CME system can support only a couple hundred. Therefore, deploying a standalone CME system with Cisco Unity may be uneconomic, and deploying a centralized Cisco Unity system with multiple CME systems also makes voicemail administration and management much easier (compared to multiple distributed voicemail systems).

One thing to notice about the deployment of a centralized Cisco Unity system is that a CME system is also deployed at the central site. This central CME system serves to relay communications between the Cisco Unity system and the CME systems at the remote sites.

The following example contains a CME configuration for integration with Cisco Unity:

telephony-service voicemail 7777!ephone-dn 10 number 1001 call-forward busy 7777 call-forward no-an 7777 timeout 10!!ephone-dn 15 number 7780 mwi on!ephone-dn 16 number 7781 mwi off!!ephone-dn 20 number 7777 name “Voicemail 1” preference 0 no huntstop!ephone-dn 21 number 7777

ptg999

[ 134 ]



name “Voicemail 2” preference 1 no huntstop!ephone-dn 22 number 7777 name “Voicemail 3” preference 2 no huntstop!ephone-dn 23 number 7777 name “Voicemail 4” preference 3!!ephone 10 vm-device-id CiscoUM-VI1 button 1:20!ephone 11 vm-device-id CiscoUM-VI2 button 1:21!ephone 12 vm-device-id CiscoUM-VI3 button 1:22!ephone 13 vm-device-id CiscoUM-VI4 button 1:23

In the example, the telephony-service command is used to enter telephony service configuration mode, and the voicemail command is used to specify the voicemail pilot number, which, in this example, is 7777.

A directory number for a user is then specified using the ephone-dn and number commands. In this case, the DN is 1001. Importantly, the call-forward busy and call-forward noan commands are used to specify that calls should be forwarded to the voicemail (pilot) number, 7777, if this DN (1001) is either busy or there is no answer for 10 seconds.

ptg999

[ 135 ]



Two further DNs (15 and 16) are then configured that correspond to the MWI numbers that Unity dials to turn MWIs on and off.

In this example, DN 7780 is configured as the MWI on number, and DN 7781 is configured as the MWI off number using the mwi onand mwi off commands, respectively.

Next, the ephone-dn command is used to configure the directory number associated with each of the voicemail ports (in turn). In this example, four ephone-dns are configured to allow the routing of a maximum of four voicemail calls to the Unity system at one time.

Three things to notice about the configuration of the four voicemail ephone-dns is that each points to the same extension (7777), that they each have a different preference (0 to 3), and that the no huntstop command is configured (with the exception of the last ephone-dn).

The preference and no huntstop commands ensure that CME can hunt through the ephone-dns until it finds a free port.

An ephone is then associated with each voice port using the ephone and button commands.

Under each of the four ephones is the vm-device-id id-string command. This allows the Unity voicemail ports to register with the CME using a device ID instead of a MAC address. In this example, the device IDs that Unity must be configured with to register with CME are CiscoUM-VI1 to Cisco-UM-VI4.

In a deployment with multiple CMEs and a centralized Cisco Unity system, it is necessary to configure MWI relay between the CME system at the central site (which is directly integrated with Cisco Unity) and the CME systems at the remote sites. The following example shows configuration for MWI relay on the central site CME:

telephony-service ip source-address 10.1.1.1 mwi relay mwi expires 99999voicemail 7777

The mwi relay command configures CME to relay MWI notification to remote CME systems and IP phones, and the mwi expirescommand configures the expiration timers for registration for MWI client to server in seconds.

ptg999

[ 136 ]



The following example shows the configuration for MWI relay on a remote CME system:

telephony-service ip source-address 10.2.2.1 mwi sip-server 10.1.1.1 transport tcp!ephone-dn 10 number 1001 mwi sip call-forward noan 7777 timeout 10 call-forward busy 7777!dial-peer voice 200 voip destination-pattern 7777 session target ipv4:10.1.1.1 codec g711ulaw dtmf-relay h245-alphanumeric no vad

The sip-server command configures the CME system to subscribe to the SIP server on the central site CME system.

The mwi sip command is then configured for ephone-dns. This command configures the local CME system to allow MWI control using SIP notification from the central site CME system.

Finally, the dial peer is used to ensure that remote site users can dial the voicemail pilot number (7777, in this example), and that these calls are routed to the central site CME system.

DTMF Integration with Analog Voicemail SystemsThe configuration of DTMF integration with analog voicemail systems uses the same vm-integration, pattern direct, pattern ext-to-ext, and pattern trunk-to-ext commands that are used with SRST. Refer to the section, “Survivable Remote Site Telephony,” for more information about the configuration of these commands.

Cisco unity ExpressCisco Unity Express (CUE) is the voicemail solution suitable for small to medium-size deployments. It is the voicemail solution that Cisco recommends for use with CME.

ptg999

[ 137 ]



CUE not only functions as a voicemail solution, but also includes auto-attendant (AA) capability. Integration between CUE and CME is provided using a SIP interface, while integration with CUCM is offered through JTAPI.

CUE is supplied as either a Network Module (NM-CUE) or as an Advanced Integration Module (AIM-CUE).

The following two sections describe CUE deployment models and integration with CME.

CuE Deployment ModelsCUE offers three standard deployment models:

■ Standalone office: A single-site deployment. CUE typically is deployed with CME, although it is possible to deploy it with Cisco CUCM.

■ Multisite network with CME (distributed call processing/voicemail): A deployment in which there are multiple sites and CUE is deployed at each site in conjunction with CME.

■ Multisite network with CUCM (centralized call processing/distributed voicemail): In this type of deployment, Cisco CUCM is deployed at a central site to provide call processing for phones at all sites, and SRST is provided at remote sites. Voicemail is deployed in a distributed architecture, with Cisco Unity at the central site and CUE at the remote sites.

Figure 5-3 illustrates these three deployment options.

ptg999

[ 138 ]



FIguRE 5-3CUE Deployment Options

PSTN Internet

Multisite Networkwith CME

StandaloneOffice

CME/CUE

Multisite Networkwith CUCM

PSTN WAN

CME/CUE(Site 2)

CME/CUE(Site 3)

CME/CUE (Site 1)

PSTN WAN

SRST/CUE(Remote Site)

SRST/CUE(Remote Site)

Cisco CUCM/Cisco Unity

(Central Site)

Note that for CUE/CME deployments prior to CME 3.2 and CUE 2.0, CME and CUE had to be collocated in the same router chassis. In CME 3.2/CUE 2.0 and later, it is possible for CME and CUE to be located in different router chassis, and it is recommended that connectivity between the two should be provided over a LAN (not a WAN).

Similarly, prior to Cisco SRST release 3.2, CUE and the PSTN gateway had to be in the same router chassis, but from release 3.2, this restriction has been relaxed and the PSTN gateway can be in a separate chassis.

ptg999

[ 139 ]



CuE Integration with CMEBasic integration of CUE with CME can be achieved by following these steps:

Step 1. Configure a SIP dial peer for CUE.

Step 2. Configure MWI on/off extensions.

Step 3. Configure IP connectivity for CME/CUE.

The following example shows configuration of a SIP dial peer for CUE call routing:

dial-peer voice 1000 voip destination-pattern 777. session protocol sipv2 session target ipv4: 10.1.1.5 dtmf-relay sip-notify codec g711ulaw no vad

The destination-pattern command in the example matches the pattern 777. This corresponds to the voicemail pilot (7777) and the AA pilot (7778) numbers.

Next, the session protocol sipv2 command specifies that SIP should be used as the session protocol between CME and CUE.

The session target command is used to configure the IP address of the CUE module.

The dtmf-relay sip-notify, codec g711ulaw, and no vad commands are then used to specify the use of SIP Notify messages for DTMF relay, G.711 (u-law) as the codec, and no Voice Activity Detection (VAD).

MWI on/off number configuration is shown here:

ephone-dn 70 number 8000.... mwi on!ephone-dn 71 number 8001.... mwi off

ptg999

[ 140 ]



These ephone-dns correspond to the numbers that CUE dials to turn MWIs on and off. Notice that the numbers specify wildcards (8000...., 8001....); this allows CUE to call the number and append the extension whose MWI should be turned on or off.

For example, if a message is left for extension 1001, CUE dials 80001001 and that causes CME to turn MWI on for extension 1001. If all messages have been listened to and the MWI must be turned off, CUE dials 80011001 and CME turns the MWI off.

The following example shows the configuration of IP connectivity for CME/CUE:

interface Service-Engine1/0 ip unnumbered FastEthernet1/0 service-module ip address 10.1.1.5 255.255.0.0 service-module ip default-gateway 10.1.1.1!ip route 10.1.1.5 255.255.255.255 Service-Engine1/0

The ip unnumbered FastEthernet1/0 command configures an IP address on the CME router’s internal interface to CUE. In this example, the IP address is “borrowed” from interface Fast Ethernet 1/0 (10.1.1.1).

The service-module ip address command is then used to configure an IP address for the CUE module (10.1.1.5).

The next command is service-module ip default-gateway. This configures the default gateway (10.1.1.1) for the CUE module.

Finally, the ip route 10.1.1.5 255.255.255.0 Service-Engine1/0 command is used to configure a route from CME to CUE via interface Service Engine 1/0.

In a multisite environment, calls between the sites use H.323, but calls to CUE use SIP. This means that H.323 to SIP translation is needed on CME:

voice service voip allow-connections h323 to sip

The voice service voip command enters voice service configuration mode and specifies VoIP encapsulation.

The allow-connections h323 to sip command allows connections between H.323 and SIP endpoints (CME/CUE).

ptg999

[ 141 ]



Chapter 6IP Interactive Voice Response/Unified Contact Center Express

Cisco Unified Contact Center Express (UCCX) is a contact center solution that is deployed in an IP telephony environment. It provides Automatic Call Distribution (ACD), Interactive Voice Response (IVR), and Computer Telephony Integration (CTI).

UCCX was previously known as IP Contract Center Express (IPCC Express), and it is worth noting that you may see either name on the exam.

uCCX FunctionsThis section describes UCCX call flows, components, capabilities, functions, configuration, and troubleshooting.

uCCX Call FlowsUCXX Express is based on the Cisco Customer Response Solutions (CRS) platform, and it uses Cisco CUCM or CUCME for call processing. A complete UCCX solution also includes other elements, such as phones, voice gateways, routers, and switches.

Figure 6-1 illustrates a typical UCCX call flow.

ptg999

[ 142 ]


Chapter 6: IP Interactive Voice Response/Unified Contact Center Express

FIguRE 6-1Typical UCCX Express Call Flow

PSTN

UCCX

Agent’sPhones/PCs

Supervisor’sPhones/PCs

CiscoCUCM

V

1

2

3

4

5

6

7

The call flow shown in Figure 6-1 involves the following steps:

1. The voice gateway receives an incoming call from the PSTN.

2. The voice gateway routes the call depending on instructions from CUCM (using MGCP/H.323).

3. The dialed number for the call corresponds to a CTI route point associated with an UCCX/CRS JTAPI user, so a JTAPI route request is sent to UCCX.

4. UCCX selects a CTI port and responds to CUCM with the extension. CUCM then sends a setup message to UCCX, which corresponds to a script (which often specifies a greeting followed by a prompt). The script causes the call to be answered (Accept step in the script), and a RTP stream is established between the designated CTI port on UCCX and the port on the voice gateway.

ptg999

[ 143 ]



5. The call is now queued until an agent (suitably skilled) becomes available. (He or she logs in or completes a previous call.)

6. UCCX reserves the agent and initiates a call transfer to that agent’s phone, which causes the agent’s phone to ring. (This is based on CUCM to phone signaling.) At the same time, UCCX signals a CTI screen pop on the agent’s workstation desktop to supply call-related information to the agent.

7. The agent answers the call, the call transfer is completed, and a RTP stream is established between the agent’s phone and the port on the voice gateway.

uCCX/CRS Components, Subsystems, and CapabilitiesUCCX consists of several components, which provide numerous capabilities.

The following are the four UCCX components:

■ UCCX (CRS) engine: Executes applications using subsystems. Specific functionality provided to UCCX includes script execution, Cisco Agent Desktop (CAD) communication, CUCM/CTI manager JTAPI communication, and UCCX Administration interface.

■ Database: Consists of four data stores: Configuration (CDS), Repository (RDS), Agent (ADS), and Historical (HDS).

The CDS contains information relating to resources (agents), resource groups, skills, teams, and CSQs.

The RDS contains prompts, grammars, and documents.

The ADS contains logs, statistics, and pointers to recordings.

The HDS contains contact call detail records (CCDR).

■ Recording: Allows agent calls to be recorded.

■ Monitoring: Allows supervisors to monitor agents.

ptg999

[ 144 ]



As previously mentioned, UCCX has three main capabilities:

■ Interactive Voice Response (IVR): Involves providing recorded messages over the phone to users, in response to user input such as spoken input or DTMF tones.

■ Automatic Call Distribution (ACD): Allows the automatic routing of incoming calls to agents on the basis of their availability or how long they have been idle.

■ Computer Telephony Integration (CTI): In the case of UCCX, this includes the capability to provide screen pop to agent desktops during call transfer. Call information provided via screen pop can include number dialed, ANI, information input, and so on.

CTI also provides the capability to interact with other Windows applications.

Depending on the particular UCC package in question, precise IVR functionality includes

■ Prompting and collecting DTMF input from callers

■ Playing messages to callers

■ Support for auto-attendant

■ Real-time notification (e-mail and so on)

■ (Basic) XML document processing

■ HTTP triggers (events that initiate scripts)

■ Support for Java

■ Media Resource Control Protocol (MRCP) integration for automatic speech recognition (ASR)

■ MRCP integration for text-to-speech (TTS) conversion

■ Voice XML (VXML) 2.0 support for ASR, TTS, and DTMF

ptg999

[ 145 ]



■ Database integration

■ IVR port call recording

■ Remote silent monitoring

ACD functionality similarly depends on the UCC package, but can include the following:

■ Basic call routing and queuing, such as conditional routing and agent selection.

■ Routing based on skills and competencies.

■ Agent routing based on ready state.

■ Capability to dynamically modify and apply CSQ skills and competencies.

■ Prioritized queuing based on customer data.

■ Customizable scripting.

■ Historical reporting.

■ CAD: This is used by agents to log in to UCCX and perform tasks such as controlling ACD state, controlling calls, and displaying information and statistics.

■ IP Phone Agent (IPPA): This XML application runs on certain Cisco IP phone models and can be used by agents who do not have a Windows workstation.

■ Cisco Supervisor Desktop (CSD): This application allows supervisors to perform tasks such as viewing and changing agent states, monitoring calls, recording calls, intercepting calls, and sending messages.

To provide the previously mentioned capabilities and functionality, UCCX relies on several subsystems, which provide specific functions. UCCX (CRS) subsystems include the following:

ptg999

[ 146 ]



■ Cisco Media Termination (CMT): Configures CMT dialog groups (pools of channels) that handle prompt/response-based DTMF interactions with callers.

■ Core Real Time Reporting (RTR): Provides information and statistics for contacts, sessions, and applications.

■ Database: Allows connections between the server and database and provides ODBC support.

■ E-mail: Allows the UCCX engine to send e-mails.

■ Enterprise server: Transfers data required for Cisco Agent Desktop screen pops.

■ HTTP: Allows the UCCX engine to respond to HTTP requests.

■ MRCP ASR: Allows scripts to use voice input in addition to DTMF input.

■ MRCP TTS: Provides text-to-speech capability.

■ Resource Manager-Contact Manager (RmCm): Allows the monitoring of agent phones, routing/queuing of calls, control of agent states, and management of historical reporting.

■ Voice browser: Manages the voice browser (described elsewhere in this chapter). This subsystem is available only if Nuance ASR is enabled.

■ VoIP monitor: Allows remote recording and monitoring.

■ JTAPI: Ensures communication between the UCCX engine and CUCM/CTI Manager.

Configuring UCCXThe installation and configuration of IPCC Express with CUCM consists of the following steps (at a minimum):

Step 1. Configure CUCM and register Cisco IP phones.

Step 2. Install and configure the UCCX.

Step 3. Configure and load scripts.

ptg999

[ 147 ]



Note that UCCX communicates with CUCM using Java Telephony Application Programming Interface (JTAPI), and CUCM uses a JTAPI user ID and password to authenticate the request from UCCX to begin the communication session. The JTAPI user ID and password are automatically configured in CUCM during UCCX installation. Two JTAPI user IDs and passwords are required in a redundant configuration.

In a redundant/fault-tolerant configuration, UCCX is able to communicate with up to two CTIManagers (a CUCM subsystem that enables JTAPI communication) in a CUCM cluster. However, UCCX actively communicates with only one CTIManager at one time. If the active CTIManager fails, UCCX fails over to the redundant connection with the second CTIManager. At the time of failover, calls in progress survive, though phones that are registered with a failed CUCM must reregister with another CUCM when existing calls are complete.

Once the just described basic configuration of UCCX is complete, CAD and CSD can be installed.

TroubleshootingWhen troubleshooting UCCX, it can be useful to examine trace files. By default, UCCX sends information about subfacilities to trace files.

It is possible to modify trace defaults by going to System, Tracing in UCCX (CRS) Administration. Tracing produces log files that record UCCX component activity.

You can specify a trace level of debugging and/or alarm tracing (or no selection), along with a facility and subfacility. Facilities include MIVR (workflow application framework), MCVD (cluster framework), MADM (CRS Administration page), MEDT (editor), and MARC (Archive framework).

Subfacilities include, for example, SS_CMT (CMT subsystem), SS_DB (database subsystem), SS_HTTP (HTTP subsystem), SS_MRCP_ASR (MRCP ASR subsystem), SS_MRCP_TTS (MRCP TTS subsystem), SS_TEL (JTAPI subsystem), STEP_CALL_CONTROL (call control steps), STEP_SESSION (session steps), STEP_USER (user steps), STEPS_DB (database steps), STEPS_GENERAL (general steps), and so on.

JTAPI is a common cause of issues with UCCX. You can quickly verify the status of the JTAPI subsystem by going to System, Control Center.

ptg999

[ 148 ]



The JTAPI subsystem can be in several states:

■ In-service: Indicates that all the configured CTI ports, CTI route points, and associated applications have been successfully initialized.

■ Initializing: Indicates that the subsystem is initializing the CTI route points, ports, and associated applications.

■ Partial service: Indicates that the JTAPI subsystem was unable to initialize one or more CTI route points or ports. This is often due to misconfiguration; check that the route points/ports exist, are correctly configured, and are associated with the JTAPI user on CUCM.

■ Out-of-service: Indicates that none of the CTI route points and ports were correctly initialized. It can occur for a number of reasons, including if the JTAPI provider (CUCM) is down, if no CTI ports or CTI route points were configured, if the username or password is incorrect, if UCCX/CRS is unable to resolve the CUCM’s DNS name, or if there is no IP connectivity between UCCX/CRS and CUCM.

Database LookupsThe UCCX (CRS) Editor enables script designers to write scripts for UCCX. Within these scripts, a number of steps (programming units) can be used to read and write data or documents to database tables. These steps include the following:

■ DB Get: Can be used to assign specific variables to the results of the SQL query specified in the DB Read step

■ DB Read: Used to select a database and obtain data (using SQL statements)

■ DB Release: Closes a SQL query and releases resources after the DB Get or Write step

■ DB Write: Used to select a database and update an enterprise database (using SQL statements)

ptg999

[ 149 ]



Speech RecognitionTo facilitate speech recognition, UCCX (CRS) comes with a Media Resource Control Protocol (MRCP, RFC 4463) Automated Speech Recognition (ASR) component. This component, along with a separate ASR server provided by a third-party vendor, such as Nuance or Scansoft, can be used to enable speech recognition.

Figure 6-2 illustrates connectivity between an UCCX cluster and an ASR server.

PSTN

ASR Server(MRCP Server)

UCCX Cluster(MRCP Client)

MRCP/RTSP

Media Streams (RTP)

Agent’sPhones/PCs

Supervisor’sPhones/PCs

CiscoCUCM

V

FIguRE 6-2Connectivity Between an UCCX Cluster and an ASR Server

MRCP is a mechanism that allows a client device that requires audio stream processing to control processing resources, such as ASR and TTS servers, and instructs them to perform tasks such as speech recognition and text-to-speech conversion. MRCP relies on the Real Time Streaming Protocol (RTSP) or SIP as a control protocol, which is responsible for setting up and controlling sessions. RTSP/SIP is also responsible for setting up media streams between the client and server using RTP.

UCCX (CRS) supports ASR via the MRCP ASR subsystem.

ptg999

[ 150 ]



VXMLVoice Extensible Markup Language (VXML) is a World Wide Web Consortium (W3C) standard that allows voice-based interaction between human users and computer applications. VXML is used for applications and systems such as auto-attendant, voicemail, or IVR, with VXML scripts performing functions such as playing prompts, collecting user input (speech or DTMF tones), and routing calls.

VXML scripts can perform IVR functions similar to Tool Command Language (Tcl) scripts; the major difference is that whereas Tcl scripts are usually device memory resident or downloadable from a TFTP server, VXML scripts are usually interpreted by a voice browser after they are downloaded from a web server using HTTP. (VXML operates using a client/server model.)

UCCX supports VXML 2.0 applications.

ptg999

[ 151 ]



Chapter 7UC Security

When implementing an IP telephony network, it is essential to carefully consider security; otherwise, the network will be vulnerable to attack and voice communications may suffer disruption.

Several different tools and techniques can be used to protect the IP telephony networks, and some of these are covered in this chapter.

DHCP SnoopingSeveral different tools and techniques can help protect the network against both Layer 2 and Layer 3 threats. One such technique is DHCP snooping.

VoIP devices, such as IP phones, can use the Dynamic Host Configuration Protocol (DHCP) to obtain IP configuration parameters, such as IP address and TFTP server address. Therefore, if an attacker is able to interfere with DHCP, he might be able to conduct a denial-of-service (DoS) attack and prevent IP phones from operating correctly.

DHCP snooping works to prevent an attacker from interfering with DHCP operation by filtering malicious DHCP messages and creating a DHCP snooping binding table. The table contains information such as MAC addresses, IP addresses, DHCP lease times, and VLAN port information for clients on untrusted ports.

DHCP snooping involves trusted and untrusted switch ports. If a DHCP packet is received on a trusted port, the switch forwards it without validation. If a DHCP packet is received on an untrusted port, the switch checks to ensure that it is from a DHCP client and not a malicious packet sent by an attacker. Trusted ports connect to devices such as DHCP servers or DHCP relay agents.

ptg999

[ 152 ]


Chapter 7: UC Security

MCS Operating System HardeningCisco CallManager version 4.x runs on the Windows 2000 Server OS. For this reason, it is important to ensure that the underlying MCS operating system (Windows 2000 Server) is properly hardened so that it cannot easily be attacked and compromised.

One of the first things to ensure is that Cisco patches and updates are installed to protect against security threats. It is also important to ensure that Cisco CallManager servers are not used for any other services other than those provided by CallManager. So, for example, a Cisco CallManager should not be used for web browsing and should not be configured to provide file and print services.

It is important to ensure that file access is restricted, the number of Windows 2000 user accounts is kept to a minimum, accounts used by CallManager are not deleted or modified, and a secure password policy is implemented. Furthermore, it is a good idea to disable any services that are not required on the CallManager server.

Finally, it is recommended that only approved antivirus software and security software, such as Cisco Security Agent, is installed on a CallManager server.

Note that CallManager/CUCM 5.x and above run on security hardened Linux appliances. It is possible to install Cisco Security Agent (CSA) on CUCM 4.x, 5.x, 6.x, and 7.x. CSA provides intrusion detection and prevention.

Phone Authentication and EncryptionAlthough mechanisms such as DHCP snooping can help prevent certain types of DoS attacks, IP telephony systems are also vulnerable to other types of attack, such as interception and eavesdropping, as well as malicious insertion of packets into a voice signaling or media stream. Therefore, it is important to secure IP telephony networks, and Cisco CUCM and other devices can be configured to use encryption and authentication to protect against attacks.

Cisco CUCM, Cisco IP phones, and voice gateways can be configured to authenticate and encrypt voice signaling and media traffic, and Cisco IP phones can be configured to authenticate phone images and configuration files. These functions rely on a public key infrastructure (PKI) and the issuance of certificates.

ptg999

[ 153 ]



Managing Certificates in a Cisco IP Telephony NetworkTypically, in a PKI, there is a single certificate authority (CA) or hierarchy of CAs to issue certificates. In a Cisco IP telephony network, however, several elements have the capability to issue certificates:

■ Self-signed certificates: These are certificates self-signed by the CUCM, TFTP server, and Certificate Authority Proxy Function (CAPF).

■ Certificates signed by the CAPF or an external CA: These are issued as locally significant certificates (LSC) to Cisco IP phones.

■ Certificates signed by the Cisco CA: Certain Cisco IP phone models are shipped with manufacturing installed certificates (MIC).

All these certificate types are necessary to carry out functions such as authentication and encryption of voice signaling and media traffic, authentication of images, and authentication of configuration files. But, to ease the distribution of certain certificates to Cisco IP phones a Cisco Trust List (CTL) is created using a CTL Client. The CTL Client is a plug-in that can be installed on a Windows 2000 server or workstation.

A CTL is used to supply a list of trusted items signed by the Cisco Site Administrator Security Token (SAST, a hardware portable security module). Cisco IP phones can use this CTL to validate server certificates and security tokens and to enable secure communications and file authentication.

The CTL file consists of the following entries:

■ CUCM or Cisco TFTP

■ CUCM and Cisco TFTP on the same server

■ CAPF

■ Alternate Cisco TFTP

■ SAST

ptg999

[ 154 ]



The entries consist of server certificate, including public key, server function, IP address, and so on.

When Cisco IP phones boot, they are able to obtain the CTL file from a TFTP server.

Figure 7-1 illustrates how the CTL Client builds the CTL and how the CTL is distributed to Cisco IP phones.

FIguRE 7-1Method Used to Build and Distribute the CTL

Cisco IP Phones Retrievethe CTL When They Boot

CTL Client Buildsthe CTL

TFTPServer CAPF CCM

AlternateTFTP

SiteAdmin

SecurityToken

TFTPServer CAPF

CTLClient

CCMPublisher

TFTPServer CAPF

Certificate Trust List (CTL)

Certificate Trust List (CTL)

CCM

AlternateTFTP

SiteAdmin

SecurityToken

TFTPServer

ptg999

[ 155 ]



As already mentioned, some Cisco IP phone models come with MICs, but it is recommended that these be replaced by LSCs. LSCs can be issued either by the CAPF or via the CAPF from a separate CA. When LSCs are issued by a separate CA, the CAPF acts as a proxy when Cisco IP phones enroll with that CA.

Figure 7-2 illustrates how a Cisco IP phone can enroll and obtain a certificate directly from the CAPF or via the CAPF from an external CA.

FIguRE 7-2Cisco IP Phone Enrollment

4

3

CAPF Proxies CertificateEnrollment to External CA

Cisco IP Phone Enrolls andObtains Certificate Directly from CAPF

Cert forPhone

CAPF Issues Certto Cisco IP Phone

Cisco IPPhone Enrolls

CAPF CAPFExternal

CA

Cert forPhone

Cert forPhone

1 Cisco IPPhone Enrolls

1CAPF Sends Certto Cisco IP Phone

2

External CAIssues Cert

CAPF Proxies Enrollmentto External CA

2

Protecting Voice Media and Signaling TrafficCisco CUCM supports two security modes:

■ Mixed mode: In this mode, there are secure calls between devices that are security enabled, and nonsecure calls between devices when at least one of the devices is not security enabled.

■ Nonsecure mode: In this mode, all calls are nonsecure (the default).

ptg999

[ 156 ]



Cisco IP phones support the following security modes:

■ Nonsecure mode: In this mode, a Cisco IP phone does not support secure calls.

■ Authenticated mode: A Cisco IP phone does support authenticated calls.

■ Encrypted mode: A Cisco IP phone does support encrypted calls.

After authentication and encryption have been enabled in a Cisco IP telephony network, it is possible to secure voice signaling and media traffic.

To secure voice media traffic, it is also necessary to secure voice signaling because the keys that are used to secure voice media are exchanged using voice signaling messages.

Skinny Client Control Protocol (SCCP) and Session Initiation Protocol (SIP) messages sent between Cisco IP phones and Cisco CUCM can be authenticated and encrypted. And to protect voice media RTP packets, Secure RTP (SRTP, RFC 3711) can be used. SRTP provides a framework for encryption and authentication of RTP streams. SRTP takes advantage of cryptographic algorithms such AES and HMAC-SHA1.

Figure 7-3 illustrates how SCCP voice signaling and RTP media traffic can be secured using SCCP over Transport Layer Security (TLS) and SRTP.

FIguRE 7-3Securing Voice Signaling and Media Using SCCP over TLS and SRTP.

SCCPover TLS

SRTP

SCCPover TLS

V

CUCM

ptg999

[ 157 ]



It is also possible to protect voice media traffic between Cisco IP phones, secure MGCP gateways, secure CTI devices and route points, secure SIP trunks, secure H.323 gateways, secure conference bridges, and secure H.323/H.245/H.225 trunks if no media resources are used.

It is important to note that SRTP session keys are sent in clear text between CUCM and MGCP gateways, H.323 gateways, and H.323/H.245/H.225 trunks, and they are therefore vulnerable to discovery unless IPsec is configured between CUCM and IOS gateways.

Figure 7-4 shows how voice signaling between CUCM and MGCP gateways can be secured using IPsec, and how voice media can be secured between Cisco IP phones and MGCP gateways using SRTP.

FIguRE 7-4Securing MGCP Signaling Using IPsec and Voice Media Using SRTP

SRTP

MGCP Gateway(with MGCP

SRTP Package)

MGCP over IPsec(Master Encryption

Keys and Salt)

V

CUCM

ptg999

[ 158 ]



TCP/uDP Port ListWhen configuring firewalls and other devices in an IP telephony network, it is important to know which protocols and ports are used by Cisco CUCM and VoIP devices. Table 7-1 lists some of the protocols and ports used by Cisco CUCM 7.x.

TAblE 7-1 Protocols and Ports Used By Cisco CUCM 7.x

Port Purpose514 (UDP) System logging service.

1090, 1099 (TCP)Cisco AMC Service for RTMT performance monitors, data collection, logging, and alerting.

1500, 1501 (TCP) Database connection (1501 [TCP] is secondary connection).1515 (TCP) Database replication between nodes during installation.2552 (TCP) Allows subscribers to receive CUCM database change notification.

2551 (TCP)Intracluster communication between Cisco Extended Services for Active/Backup determination.

2555 (TCP) Real-time Information Services (RIS) database server.2556 (TCP) RIS database client for Cisco RIS.4040 (TCP) DRF Master Agent.5007 (TCP) SOAP monitor.5555 (TCP) License Manager to listen to license request.

Ephemeral (TCP)Cisco Trace Collection Tool Service (TCTS). This is the back-end service for RTMT Trace & Log Central (TLC).

7000 then Ephemeral (Linux) (TCP)Used for com munication between Cisco Trace Collection Tool Service and Cisco Trace Collection servlet.

7070 (TCP) Certificate Manager service.8001 (TCP) Client database change notification.8002 (TCP) Intracluster communication service.8003 (TCP) Intracluster communication service (to CTI).8004 (TCP) Intracluster communication between CUCM and CMI Manager.8005 (TCP) Internal listening port used by Tomcat shutdown scripts.8500 (TCP and UDP) Intracluster replication of system data by IPsec Cluster Manager.8888–8889 (TCP) RIS Service Manager status request and reply.

ptg999

[ 159 ]



Port Purpose22 (TCP) Secure FTP service, SSH access.Ephemeral (UDP) CUCM acting as a DNS server or DNS client.67 (UDP) CUCM acting as a DHCP server.68 (UDP) CUCM acting as a DHCP client.69, 6969, then Ephemeral (UDP) TFTP service to phones and gateways.123 (UDP) NTP.161 (UDP) SNMP service response (requests from management applications).199 (TCP) Native SNMP agent listening port for SMUX support.

6161 (UDP)Used for communication between Master Agent and Native Agent to process Native agent MIB requests.

6162 (UDP)Used for communication between Master Agent and Native Agent to forward notifications generated from Native Agent.

6666 (UDP) Netdump server.6970 (TCP) Centralized TFTP File Locator Service.7161 (TCP) Used for communication between SNMP Master Agent and subagents.7999 (TCP) CDP agent communicates with CDP executa ble.9050 (TCP) Service CRS requests through the TAPS residing on CUCM.

61441 (UDP)CUCM applications send out alarms to this port via UDP. CUCM MIB agent listens on this port and generates SNMP traps per CUCM MIB definition.

Ephemeral Provide trunk-based SIP services.Ephemeral (TCP) LDAP query to external directory (Active Directory, Netscape Directory).80, 8080 (TCP) HTTP.443, 8443 (TCP) HTTPS.80 (TCP) HTTP.69, then Ephemeral (UDP) TFTP used to download firmware and configuration files.

8080 (TCP)Phone URLs for XML applications, authentication, directories, services, and so on. You can configure these ports on a per-service basis.

2000 (TCP) SCCP.2443 (TCP) SCCPS.3804 (TCP) CAPF listening port for issuing LSCs to IP phones.5060 (TCP and UDP) SIP phone.

ptg999

[ 160 ]



Port Purpose5061 (TCP and UDP) Secure SIP (SIPS) phone.

16384–32767 (UDP)RTP, Secure RTP (SRTP) (Note: CUCM only uses 24576-32767, although other devices use the full range.)

47, 50, 51 GRE, ESP, AH. IP protocols numbers.500 (UDP) IKE.69, then Ephemeral (UDP) TFTP.1719 (UDP) Gatekeeper (H.225) RAS.1720 (TCP) H.225 signaling services for H.323 gateways and Intercluster Trunk (ICT).Ephemeral (TCP) H.225 signaling services on gatekeeper-controlled trunk.Ephemeral (TCP) H.245 signaling services for establishing voice, video, and data.2001 (TCP) Upgrade port for 6608 gateways with CUCM deployments.2002 (TCP) Upgrade port for 6624 gateways with CUCM deployments.2427 (UDP) MGCP gateway control.2428 (TCP) MGCP backhaul.5060 (TCP and UDP) SIP gateway and Intercluster Trunk (ICT).5061 (TCP and UDP) Secure SIP (SIPS) gateway and Intercluster Trunk (ICT).

16384 - 32767 (UDP)RTP, SRTP. CUCM only uses 24576-32767, although other devices use the full range.

2444 (TCP) CTL provider listening service in CUCM.2748 (TCP) CTI application server.2749 (TCP) TLS connection between CTI applications (JTAPI/TSP) and CTIManager.2789 (TCP) JTAPI application server.2912 (TCP) Cisco Unified Communications Manager Assistant server (formerly IPMA).

1103 -1129 (TCP)Cisco Unified Communications Manager Attendant Console (AC) JAVA RMI Registry server.

1101 (TCP) RMI server sends RMI callback messages to clients on these ports.

1102 (TCP)Attendant Console (AC) RMI server bind port. RMI server sends RMI messages on these ports.

ptg999

[ 161 ]



Port Purpose

3223 (UDP)Cisco Unified Communications Manager Attendant Console (AC) server line state port receives ping and registration message from, and sends line states to, the attendant console server.

3224 (UDP)Cisco Unified Communications Manager Attendant Console (AC) clients register with the AC server for line and device state information.

4321 (UDP)Cisco Unified Communications Manager Attendant Console (AC) clients register to the AC server for call control.

8443 (TCP)AXL/SOAP API for programmatic reads from or writes to the CUCM database that third parties, such as billing or telephony management applications, use.

2444 (TCP) CTL provider listening service in an ASA firewall.280 (TCP) HTTP port to HP SIM.2301 (TCP) HTTP port to HP agent2381 (TCP) HTTPS port to HP agent.25375, 25376, 25393 (UDP) COMPAQ Management Agent extension (cmaX).50000–50004 (TCP) HTTPS port to HP SIM.

Firewalls and Application Layer gatewaysFirewalls are commonly used to protect networks, including those that transport voice traffic. Firewalls inspect the headers and, in some cases, payload of packets to ascertain which traffic they should permit and which traffic they should block. Stateful firewalls also maintain state information so that they know which traffic forms part of permitted flows and should be allowed.

In the case of voice traffic, several protocols and ports must be permitted to ensure that voice operates correctly across firewalls. These protocols include MGCP, H.323, SIP, SCCP, RTP, and RTCP. In the case of RTP and RTCP, the number of ports that could potentially be used number in the thousands.

Table 7-1 in the section, “TCP/UDP Port List,” lists the protocols and ports that firewalls should permit for CUCM to operate correctly.

ptg999

[ 162 ]



Another important consideration is the placement of firewalls, in particular when VPN tunnels, such as IPsec tunnels, are used. If a VPN gateway is placed in front of the firewall, IPsec protection is added or removed after or before the “raw” (unprotected) traffic is inspected by the firewall. But if the VPN gateway is placed behind the firewall, the firewall will not be able to inspect the raw traffic. In this case, the firewall can be configured just to permit all IPsec traffic, but it will not be able to ensure that the traffic being transported over an IPsec tunnel is not malicious.

Furthermore, if the firewall is expected to perform Network Address Translation (NAT) on voice traffic, it is important that the firewall be placed in such a position that it can inspect and properly translate the header, and potentially information embedded in the payload of raw traffic; otherwise, voice might not operate as expected (or at all) in the network.

It is possible to configure IPsec tunnels directly between CUCM servers, but this does not allow inspection of traffic by firewalls and does not scale if there are more than a handful of CUCM servers.

Before finishing this section, note that application layer gateways (ALG) do not work with signaling encryption, and not all VoIP devices work with encrypted voice media.

Applications and traffic types that are not directly supported with Cisco firewalls/ALGs include Cisco Unity, IPCC Express, IPCC Enterprise, Attendant Console, and SCCP video, although it is possible to write access lists to allow them to function. The Cisco FWSM prior to version 3.0 does not function with SCCP fragmentation.

NATTo correctly identify and translate voice traffic flows, a NAT device must inspect Layer 3 and Layer 4 protocol and port information, and sometimes information embedded in the packet and protocol message payloads.

Cisco IOS NAT ALGs can support a number of voice signaling protocols, including H.323v2, H.225, H.245, RAS, SIP, and SCCP. If you modify the port used by SCCP in your network, however, you must explicitly configure the new port using the ip nat service skinny tcp port port-number command on the Cisco ALG.

Finally, note that NAT does not support voice signaling encryption.

ptg999

[ 163 ]



Chapter 8Infrastructure Protocols

Although voice signaling and media transport protocols, such as MGCP, H.323, SIP, SCCP, and RTP, are essential, other generic infrastructure protocols, such as DNS, TFTP, NTP, and Power over Ethernet (PoE), are also required in order for a telephony network to operate properly.

DNS, TFTP, NTP, and PoE are discussed in this chapter.

DNSCisco CUCM, Cisco IP phones, and other devices in a network can use DNS to resolve names to IP addresses. If the DNS server is down or inaccessible, or if the DNS entry is incorrect, failures can occur. For example, it is possible for Cisco IP phones to use DNS during registration, but registration will fail if they are unable to resolve the name of the CUCM.

Because DNS servers can be a point of failure in a network, it is a good idea to explicitly configure CUCM servers and other devices to use IP addresses whenever possible. To use IP addresses instead of DNS in a CUCM cluster, navigate to System, Server in Cisco CUCM Administration.

Although the use of DNS generally is not recommended for use in a Cisco CUCM environment, there are certain exceptions to this rule. For example, if a NAT device is between Cisco IP phones and the CUCM to which they are registered, DNS is required to ensure proper communication. Also, DNS can be used to provide disaster recovery for IP telephony in certain situations.

TFTPDevices such as Cisco IP phones require TFTP to retrieve configuration files and other information.

ptg999

[ 164 ]


Chapter 8: Infrastructure Protocols

TFTP is crucial to the correct operation of a CUCM network, so it is recommended that DHCP option 150 be used because it allows TFTP server redundancy to be configured. Cisco also recommends that option 150 be used to specify differently ordered lists of TFTP server addresses to hosts on different subnets to provide load balancing.

To better understand the importance of TFTP in a CUCM network and the significance of DHCP option 150, it is a good idea to examine Cisco IP phone initialization and registration.

Cisco IP phone initialization and registration involves the following:

1. Assuming that the phone is not using its own power supply, the phone powers itself using inline power. If the Cisco IP phone is connected to a switch that supports power over Ethernet (PoE), the switch detects the phone and applies power to the corresponding Ethernet port.

2. Next, the Cisco IP phone loads a locally stored software image using a bootstrap loader.

3. The Cisco IP phone now obtains VLAN information from the switch to which it is connected using CDPv2 packets.

4. Assuming that the information is not statically configured, the phone attempts to obtain an IP address and other information including TFTP server address by broadcasting a DHCP Discover message.

The DHCP server responds by sending information including an IP address, mask, TFTP server address, and default gateway address.

The TFTP server address can be specified by the DHCP server using one of two options:

■ Option 66: Specifies a TFTP server in the form of a hostname. However, it is possible to use an IP address with option 66, and a Cisco IP phone will correctly interpret the address.

■ Option 150: Specifies two TFTP server IP addresses.

5. After the phone obtains a TFTP server address, it retrieves its configuration from the TFTP server.

The phone requests a specific configuration file corresponding to its name (SEPmac_address.cnf.xml). If the phone is manually registered in CUCM, this file exists and the request will succeed. However, the request will fail if the phone is not manually registered.

ptg999

[ 165 ]



If the phone cannot obtain a specific configuration file because, for example, CUCM is using autoregistration, the phone requests a default configuration file (XMLDefault.cnf.xml). Information included in the configuration file requested from the TFTP server includes a list of up to three CUCMs in a CUCM group, phone load information, network and user locales, and URLs.

If the load information contained in the configuration file indicates that the phone is running an old image, it downloads the latest image from the TFTP server and reboots.

6. Finally, the phone registers with a Cisco CUCM.

After the phone obtains a configuration file from the TFTP server, it opens a connection to the CUCM server (the highest-priority server available in the CUCM group list contained in the configuration file). Assuming that the phone has been manually configured or autoregistration has been enabled, the CUCM server then supplies a DN and other information, including softkey template and phone button template information, and the phone becomes usable.

NTPIt is essential to synchronize time between CallManager/CUCM and other servers and devices to be able to troubleshoot problems in an IP telephony network. For example, if a problem occurs and you need to be able to examine events that occur across trace files on multiple servers, it might be impossible to accurately diagnose what is happening if those servers’ clocks are not synchronized.

The clocks for servers and other devices can be synchronized across a network using the Network Time Protocol (NTP).

It is possible to configure automatic synchronization on CallManager 4.x servers by ensuring that the Windows 2000 NetworkTimeProtocol service has its Startup Type set to automatic (via the Control Panel), configuring the ntp.conf file (found in C:\WINNT\) to point to the desired NTP servers or specifying the reception of NTP broadcasts, and finally stopping and starting the NetworkTimeProtocol service.

It is also possible to manually synchronize time on CUCM servers by stopping the NetworkTimeProtocol service, using the ntpdateserver_ip_address or ntpdate router_ethernet_i/f_address command, and then restarting the NetworkTimeProtocol service.

You can add a phone NTP reference in CUCM by navigating to System, Phone NTP Reference. You can then assign the NTP reference to a Date/Time group, and the Date/Time group is then assigned to a device pool.

ptg999

[ 166 ]



IOS devices can be configured for NTP using commands, such as the following:

■ clock timezone: Sets the time zone on IOS devices

■ ntp server: Configures an IOS device to synchronize its software clock to the specified NTP server

Inline Power: Cisco and 802.3afCisco IP phones can be supplied with power in a number of ways, including using

■ An external power supply unit (a power “brick”): An external power supply unit provides power directly to a phone from an electrical socket.

■ Power over Ethernet (PoE) from a switch: Switches can use PoE to supply power over an Ethernet cable to connected devices such as IP phones.

■ A midspan power injector/inline power patch panel: A midspan power injector is a device that sits between a switch and an IP phone and supplies power to the connected phone. An inline power patch panel is a patch panel that sits between a switch and multiple IP phones and supplies power to those phones.

Many Cisco switches can send power over Ethernet cables to connected devices such as Cisco IP phones. There are two methods of supplying PoE: using a Cisco proprietary method and using the IEEE 802.3af standard. Both the Cisco proprietary method and IEEE 802.3af provide power to connected devices over switch port pins 1, 2, 3, and 6.

Cisco proprietary and IEEE 802.3af methods involve detecting connected devices that require power in slightly different ways. When using the Cisco proprietary method, a switch sends a Fast Link Pulse (FLP) to the connected device, and the connected device loops the FLP back to the switch, thereby indicating that it requires power. When using IEEE 802.3af, on the other hand, the switch applies a voltage (–2.8 to –10 V), and if a resistance of 25K ohm is detected, it supplies power to the connected device.

When using midspan power injectors/inline power patch panels, power is sent to the connected device or devices using pins 4, 5, 6, and 7.

PoE can be configured on IOS switches that support it using the power inline command.

ptg999

[ 167 ]



Chapter 9Application Protocols

With the exception of traffic corresponding to active voice calls, other traffic that can be transported over telephony networks includes Music on Hold (MoH), video, fax, and modem traffic.

IP MulticastIP multicast can be used for a couple of different purposes in an IP telephony network. CUCM MoH can be sent across the network using multicast transport. In addition, if H.323 gatekeepers are being used in a network, endpoints can use multicast autodiscovery to locate these gatekeepers.

Multicast can be enabled in a campus-only environment, or it can be enabled in an interdomain environment. Protocols and mechanisms that are commonly used to enable multicast in a campus environment include Internet Group Management Protocol (IGMP), IGMP snooping, Cisco Group Management Protocol (CGMP), PIM Sparse-Mode (PIM-SM), and, to a lesser extent, PIM Dense-Mode (PIM-DM).

Protocols and mechanisms that are commonly used to enable multicast in an interdomain environment include Multiprotocol BGP (MBGP), Multicast Source Discovery Protocol with PIM Sparse-Mode (often configured in an Anycast-RP architecture), and PIM Source-Specific Multicast (PIM-SSM).

Protocols and mechanisms such as PIM-SM, PIM-DM, MBGP, MSDP, Anycast RP, Bidirectional PIM, and PIM-SSM help ensure that multicast traffic is forwarded between the routers closest to multicast sources and the routers closest to the multicast receivers.

IGMP is implemented to ensure that end hosts (multicast receivers) can join multicast groups, maintain membership of multicast groups, and leave multicast groups. This helps ensure that multicast traffic is delivered to end hosts as and when required. IGMP operates between end hosts and their local router, but a mechanism called IGMP snooping can be enabled on intervening switches to ensure optimal distribution of multicast traffic on switch ports. (Multicast traffic is flooded on switch ports, by default.)

ptg999

[ 168 ]


Chapter 9: Application Protocols

When IGMP snooping is enabled on a switch, IGMP Membership query, Membership report, and Leave packets are intercepted by the NMP or ASICs, and the switch then determines from those IGMP packets which ports it should send or stop sending what type (if any) of multicast traffic. IGMP snooping can impose a high processing overhead on low-end switches, however.

CGMP is a Cisco proprietary alternative to IGMP snooping that operates between a router and a switch, and it ensures that multicast traffic is optimally distributed on switch ports. It imposes a lower overhead on low-end switches than IGMP snooping.

VideoCisco CUCM supports video calls between SCCP, H.323, and SIP endpoints.

CUCM can support point-to-point video calls between endpoints, and it supports video conference calls by taking advantage of Cisco IP/VC 3500 multipoint control units (MCU) and Cisco IP/VC 3500 H.320 gateways. CUCM supports a variety of video endpoints including Cisco 9971 IP phones, Cisco Unified Video Advantage endpoints, Cisco Unified Personal Communicator, Tandberg video conferencing endpoints, H.323 enabled clients (Tandberg, Polycom, Sony, and so on), and certain SIP endpoints.

CUCM 7.x includes Intelligent Bridge Selection, which enables CUCM to select conferencing resources based on whether the endpoints involved in the conference are video enabled. If two or more of the endpoints are video enabled, videoconferencing resources are selected (assuming that they are available). If there are no video-enabled endpoints or videoconferencing resources are not available, an audio conferencing resource is chosen.

Intelligent Bridge selection also allows secure conferencing bridges to be selected based on device capabilities.

Numerous codecs can be used with video calls and conferences in CUCM, including H.261, H.263(+), H.264, and Cisco proprietary wideband. CUCM also support far-end camera control with H.224.

H.261 is an ITU standard designed to operate between 40 Kbps and 2 Mbps and supports Common Intermediate Format (CIF, a resolution of 352 * 288) and Quarter CIF (QCIF, 176 * 144).

H.263 is a low-bit-rate codec based on H.261 and MPEG-1 and MPEG-2. It was originally developed for H.324 PSTN and circuit-switched videoconferencing and telephony, but is now also used for H.323, H.320, RTSP, and SIP solutions.

ptg999

[ 169 ]



H.264 is a great improvement over H.263; it is also known as MPEG-4 Part 10 and Advanced Video Coding (AVC). H.264 allows the compression of video much more effectively, and therefore has the capability to provide good quality video at much lower rates than would have been required with previous standards. Furthermore, H.264 can be used in a wider range of applications than previous standards.

Fax and ModemIn addition to voice traffic, fax and modem traffic can be transported over an IP network.

Fax Transmission over IP NetworksThere are a number of fax standards, including the following:

■ T.30: Describes the handshaking between sending and receiving devices during fax transmission

■ T.4: Defines the encoding of the printed information send during fax transmission

There are a number of phases in a T.30 fax call, including the following:

■ Phase A: The call setup phase.

During this phase, the sending device sends a Calling Tone (CNG) to the receiving device. This identifies the sending device as a fax machine. The receiving device responds with a Called Station Identifier (CED) tone that identifies the receiving device as a fax machine.

■ Phase B: The premessage procedure used to identify and select facilities.

The receiving device sends a Digital Information Signal (DIS) that informs the sending device of its reception facilities including maximum page length, image resolution, and so on.

The sending device then responds with a Digital Command Signal (DCS) that informs the receiving device of which facilities to use for fax reception.

ptg999

[ 170 ]



The receiving device can then optionally send either a Called Subscriber Information (CSI) message that provides information as to the identity of the receiving device, or a Non-Standard Facilities (NSF) message that informs the sending device about additional features.

Next, the sending device can optionally send a Transmitting Subscriber Identification (TSI) message, or respond to an NSF message with a Non-Standard facilities Setup (NSS) message. The NSS can be used to select additional parameters.

The sending device then sends a Training Check (TCF) message, and the receiving device responds either with a Failure to Train (FTT) if the modulation speed is not acceptable or a Confirmation to Receive (CFR) if the speed is acceptable.

■ Phase C: Message transmission.

During this phase, the page data (T.4 data) is sent from the sending device to the receiving device.

The end of phase C is indicated by the sending device transmitting six End of Line (EOL) messages as T.4 data. These EOL messages are seen as a Return to Control (RTC) message and confirm the end of phase C.

Note that if Error Correction Mode (ECN) is requested during phase B then T.4 page data that is not received error free then a Partial Page Request (PPR) message can be sent to indicate that frames should be re-sent.

■ Phase D: Post-message procedure.

The sending device sends either a Partial Page Signal (PPS) or an End Of Procedure (EOP) message.

PPS is used if ECN is being used and this is acknowledged using a Message Confirmation (MCF) from the receiving device.

The EOP message indicates that pages have been sent, and the receiving device acknowledges with an MCF.

■ Phase E: Call release.

At this stage either the sending or receiving device can terminate the call using a Disconnect (DCN) message.

Fax can be transported over IP networks either in real time or using store-and-forward.

ptg999

[ 171 ]



Real-Time FaxReal-time fax over IP networks operates in a manner similar to regular fax transmissions: The fax machines involved in the transmission synch up, and then the fax data is sent between them over the intervening IP network. If the remote fax machine to which a transmission will be sent is busy, the local fax machine will receive a busy signal and can retry later.

There are two methods of transporting fax in real time across a network: fax-relay and fax passthrough.

When using fax-relay, the T.30 fax signal from a connected fax machine is demodulated by the sending voice/fax gateway (originating gateway [OGW]) and sent over the IP network to a remote voice/fax gateway (terminating gateway [TGW]). The remote voice/fax gateway then reconstructs the T.30 fax signal and sends it to a connected fax machine.

There are two fax-relay mechanisms: Cisco fax-relay and T.38 fax-relay.

Cisco fax-relay is an older method of transporting fax transmissions between fax machines connected to Cisco voice/fax gateways. When using this method, a voice/fax gateway terminates T.30 fax tones from a local fax machine, and then sends the fax data across an IP network by breaking the tones into HDLC frames, and then transmitting them using RTP. The remote voice/fax gateway then reverses the process, re-creates the T.30 fax tones, and sends them to a connected fax machine.

T.38 is an ITU standard that provides for real-time (fax-relay) transport of Group 3 fax over an IP network. T.30 fax signals received from a connected fax machine are demodulated at a local voice/fax gateway and encapsulated into IP packets for transport over a network to a remote voice/fax gateway. At the remote voice/fax gateway, the T.30 fax signal is then reconstructed and played out to the connected fax machine.

T.38 includes a mechanism by which a voice/fax gateway can inform a remote voice/fax gateway of its desire to change the media type from voice to data. T.38 also provides for the transport of fax over an IP network using either TCP or UDP, though the use of UDP is more prevalent.

When using fax passthrough, modulated fax data is sent in-band across the IP network by a voice/fax gateway using a voice codec (such as G.711 with no VAD or echo cancellation).

Also, when using fax passthrough, T.30 fax calls are not distinguished from regular voice calls; they are simply sent in-band over an IP network. In this case, a voice/fax gateway detects fax tones and switches to a high-bandwidth codec such as G.711 with no VAD (which prevents distortion of the fax signal). For this reason, fax messages sent using fax passthrough are relatively bandwidth

ptg999

[ 172 ]



hungry, and are sensitive to delay, jitter, and packet loss (packet redundancy can be used to mitigate this). Therefore, fax passthrough generally is not considered to be the most desirable method of transporting fax over an IP network, but it can be useful if a voice/fax gateway does not support T.38.

Store-and-Forward FaxStore-and-forward fax over IP networks operates like e-mail. A local fax machine sends a fax to a server, which sends it on to intermediate servers, and it is finally sent to the intended remote fax. Store-and-forward also allows delivery of faxes to PCs and other devices besides fax machines.

T.37 is an ITU standard for store-and-forward fax transmissions. When using this method of fax transmission, a voice/fax gateway receives a fax transmission from a connected Group 3 fax machine and converts it into a TIFF attachment for an e-mail message (this gateway is referred to as an on-ramp gateway). The e-mail message is then sent over the network, and the remote voice/fax gateway converts the e-mail message TIFF attachment back into a fax message and sends it to a connected fax machine. (This gateway is referred to as an off-ramp gateway.)

Modem Transmission over an IP NetworkOne method of transporting modem signals over an IP network is modem relay. In this case, a voice gateway demodulates signals sent by a connected modem and sends them over an IP network using the Simple Packet Relay Transport (SPRT) protocol. The remote voice gateway receives the SPRT protocol packets, reconstructs the modem signals, and sends them to a connected modem.

Modem passthrough is an alternative method of transporting modem signals over an IP network, and it is similar to fax passthrough. In this case, a voice gateway receives modem tones from a connected modem, switches to a high-bandwidth codec, such as G.711 with no VAD, and sends modem signals across the IP network to a remote voice gateway. The remote voice gateway reconstructs the modem signal and sends it to a connected modem. Like fax passthrough, modem passthrough is sensitive to delay, jitter, and packet loss in the IP network (although packet redundancy can be used to address packet loss).

ptg999

[ 173 ]



Chapter 10Operations and Network Management

IP telephony networks can be complex, and for that reason, it is essential to have a good grasp of the tools that can be used to manage and troubleshoot these networks.

A range of tools can be used to manage and troubleshoot IP telephony networks, including the following:

■ CDR Analysis and Reporting (CAR) tool: Allows the analysis of Call Detail Records (CDR). CDRs usually are used for accounting or billing, but they can help provide some pointers when troubleshooting.

CAR can be used to generate user, system, and device reports containing information on call volumes, quality of service (QoS), billing, gateways, and so on.

■ Dialed Number Analyzer (DNA): Can test dial plans for errors, and it allows the analysis of internal-to-internal and internal-to-external calls.

■ Quality Report Tool (QRT) Viewer: Can be used to view reports relating to call quality that are generated by Cisco IP phones. The generation of these reports requires that users press a softkey on their phones.

■ Real Time Monitoring Tool (RTMT): A plug-in that can be used on a remote workstation to view CUCM serviceability information in real time.

It is possible to view information relating to elements such as memory, CPU, phones, gateways, calls, CTI (TAPI and JTAPI) applications, voicemail, and so on.

■ System Diagnostic Interface (SDI) traces: Otherwise known as CCM traces, SDI traces provide detailed diagnostic information relating to CUCM call processing, including registration, digit analysis, and call flow. Trace files show devices, IP addresses, MGCP messages, SCCP messages, H.323 messages, and so on.

ptg999

[ 174 ]


Chapter 10: Operations and Network Management

■ Signal Distribution Layer (SDL) traces: Usually used by Cisco TAC engineers to examine processes at a code level in CUCM.

■ Command-line interface (CLI): It is possible to run a variety of troubleshooting commands from the CLI. You can access the CLI either via a directly connected monitor and keyboard or via a Secure Shell (SSH) session.

CUCM functionality relies on a number of services. When troubleshooting, it is useful to understand what these services are responsible for:

■ Cisco CallManager: Provides call processing and call control.

■ Cisco TFTP: Responsible for building and serving files for devices such as Cisco IP phones.

■ Cisco Messaging Interface: Used with voicemail systems that use SMDI.

■ Cisco Unified Voice Access Service: This service starts mobile voice access capabilities within Cisco Unified Mobility (an Interactive Voice Response [IVR] system).

■ Cisco IP Voice Media Streaming Application: Provides functionality underlying MoH, conferences, and MTP.

■ Cisco CTIManager: Provides an interface with JTAPI/TAPI applications.

■ Cisco Extension Mobility: Allows the definition of login settings used with the CUCM Extension Mobility feature.

■ Cisco Extended Functions: Provides support for features such as Cisco Call Back and QRT.

■ Cisco Dialed Number Analyzer: Supports the CUCM Dial Number Analyzer tool.

■ Cisco DHCP Monitor Service: Monitors IP address changes for IP phones.

■ Cisco CallManager/Unified Attendant Console Server: Allows call control and line state information for attendant console clients. It also provides redirection to hunt group directory numbers for pilot points. Note that the Attendant Console is now end-of-sale.

■ Cisco IP Manager Assistant: Allows managers and their assistants to work together more effectively.

ptg999

[ 175 ]



■ Cisco WebDialer Web Service: Allows users to make calls from web- and desktop-based applications.

■ Cisco AXL Web Service: Allows modification of database entries and execution of procedures from AXL client applications.

■ Cisco Bulk Provisioning Service: You can use the Bulk Administration Tool (BAT) to administer phones and users, and in order to use BAT, you must activate the Cisco Bulk Provisioning Service.

■ Cisco TAPS Service: The Auto-Register Phone Tool allows you to load customized configurations onto phones that are auto-registered when a user responds to IVR prompts. This service is needed if you want to support clusters. Note that the Auto-Register Phone Tool also requires Customer Response Solutions (CRS).

■ Cisco Serviceability Reporter: Responsible for generating daily reports.

■ Cisco CallManager SNMP Service: Used to implement the CISCO-CCM-MIB, which allows SNMP access to CUCM.

■ Cisco CTL Provider: Works with the CTL Client to change the security mode from nonsecure to secure.

■ Cisco Certificate Authority Proxy Function (CAPF): Issues locally significant certificates (LSC).

■ Cisco DirSync: Ensures that the CUCM database stores all user information.

■ Cisco CTIManager: Provides an interface with applications.

■ Cisco RIS Data Collector: Collects and distributes real-time information, such as the IP addresses of the phones. It is mainly used to update information for SNMP agents.

■ Cisco CallManager Serviceability RTMT: Supports RTMT.

■ Cisco RTMT Reporter Servlet: Allows you to publish RTMT reports.

■ Cisco Log Partition Monitoring Tool: The Log Partition Monitoring feature monitors disk usage of the log partition, and the Log Partition Monitoring Tool supports this feature.

■ Cisco Tomcat Stats Servlet: Allows monitoring of Tomcat perfmon counters by using RTMT or the CLI.

ptg999

[ 176 ]



■ Cisco RIS Data Collector: Allows applications access to information stored in the Real-Time Information Server (RIS). RIS maintains real-time information including performance counters, alarms, and so on.

■ Cisco AMC Service: Aids RTMT to extract real-time information on a server or servers in a cluster.

■ Cisco RISBean Library: Used by certain web applications to communicate with internal services.

■ Cisco DRF Master: Aids with scheduled backup and restorations.

■ Cisco DRF Local: Supports the Cisco DRF Local Agent.

■ Cisco CallManager Serviceability: Support Cisco Unified Serviceability.

■ Cisco CDP: Provides CDP advertisement for the application.

■ Cisco Trace Collection Servlet: Along with the Cisco Trace Collection Service, this servlet supports trace collection.

■ Cisco Trace Collection Service: Supports trace collection.

■ Cisco DB: Supports the Progres database engine.

■ Cisco Tomcat: Supports the web server.

■ Cisco SNMP Master Agent: Supports SNMP request in terms of authentication, authorization, access control, and other privacy functions.

■ MIB2 Agent: Provides access for SNMP to various variables.

■ Host Resources Agent: Provides SNMP access to information including storage resources, device information, and so on.

■ Native Agent Adapter: Allows you to forward SNMP requests to another SNMP agent that runs on the system.

■ System Application Agent: Provides access for SNMP to applications that are installed on the server.

■ Cisco CDP Agent: Provides access for SNMP to network connectivity information.

ptg999

[ 177 ]



■ Cisco Syslog Agent: Gathers syslog messages and implements the CISCO-SYSLOG-MIB.

■ Cisco Certificate Expiry Monitor: Checks whether certificates have expired.

■ A Cisco DB Replicator: Ensures database configuration and data synchronization between cluster members.

■ Cisco License Manager: Tracks licenses on the system. It is possible to detect conditions where more licenses are used than available (an overdraft, which can be up to 5 percent), situations when the license server is down, and situations where there are insufficient licenses.

■ Cisco Database Layer Monitor: Monitors the database layer.

■ Cisco SOAP-Real-Time Service APIs: Enable you to collect real-time device and CTI application information, and also provide APIs to activate, start, and stop services.

■ Cisco SOAP-Performance Monitoring APIs: Allows the use of performance monitoring counters for applications.

■ Cisco SOAP-Log Collection APIs: Allows collection of log files.

■ Cisco CallManager Personal Directory: Supports the Cisco Personal Directory.

■ Cisco Extension Mobility Application: Allows you to configure login settings for the Cisco Extension Mobility service.

■ Cisco CallManager Cisco IP Phone Services: Initializes the service URLs relating to configured IP phone services.

■ Cisco CDR Repository Manager: Maintains and moves CDRs that are obtained from the Cisco CDR Agent service.

■ Cisco CDR Agent: Responsible for transferring CDR and CMR files from the local server to the CDR repository server.

■ Cisco CAR Scheduler: Can be used to schedule CAR tasks.

■ Cisco CallManager Admin: Provides the web interface used to configure CUCM.

It is possible to activate or deactivate feature services in CUCM Serviceability by going to Tools, Service Activation. It is also possible to configure service parameters in Cisco CUCM Administration by going to Service, Service Parameters.

ptg999

[ 178 ]

© 2012 Pearson Education, Inc. All rights reserved. This publication is protected by copyright.


CCIE Voice v3.0 Quick ReferenceMark Lewis

Technical Editor: Joshua S. ReolaCopyright © 2012 Pearson Education, Inc.Published by:Cisco Press800 East 96th Street Indianapolis, IN 46240 USAAll rights reserved. No part of this book may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording, or by any information storage and retrieval system, without written permission from the publisher, except for the inclusion of brief quotations in a review.First Printing November 2011ISBN-10: 1-58714-301-1ISBN-13: 978-1-58714-301-4

Warning and DisclaimerThis book is designed to provide information about the CCIE Voice v3.0 written exam. Every effort has been made to make this book as complete and as accurate as possible, but no warranty or fitness is implied.The information is provided on an “as is” basis. The authors, Cisco Press, and Cisco Systems, Inc. shall have neither liability nor responsibility to any person or entity with respect to any loss or damages arising from the information contained in this book or from the use of the discs or programs that may accompany it.The opinions expressed in this book belong to the author and are not necessarily those of Cisco Systems, Inc

Trademark AcknowledgmentsAll terms mentioned in this ebook that are known to be trademarks or service marks have been appropriately capital-ized. Cisco Press or Cisco Systems, Inc. cannot attest to the accuracy of this information. Use of a term in this ebook should not be regarded as affecting the validity of any trademark or service mark.

Feedback InformationAt Cisco Press, our goal is to create in-depth technical ebooks of the highest quality and value. Each ebook is crafted with care and precision, undergoing rigorous development that involves the unique expertise of members of the professional technical community.Reader feedback is a natural continuation of this process. If you have any comments on how we could improve the quality of this ebook, or otherwise alter it to better suit your needs, you can contact us through email at [email protected]. Please be sure to include the ebook title and ISBN in your message.We greatly appreciate your assistance.

Corporate and Government SalesThe publisher offers excellent discounts on this ebook when ordered in quantity for bulk purchases or special sales, which may include electronic versions and/or custom covers and content particular to your business, training goals, marketing focus, and branding interests. For more information, please contact: U.S. Corporate and Government Sales 1-800-382-3419 [email protected] sales outside the United States please contact: International Sales [email protected]

Cisco has more than 200 offices worldwide. Addresses, phone numbers, and fax numbers are listed on the Cisco Website at www.cisco.com/go/offices.

CCDE, CCENT, Cisco Eos, Cisco HealthPresence, the Cisco logo, Cisco Lumin, Cisco Nexus, Cisco StadiumVision, Cisco TelePresence, Cisco WebEx, DCE, and Welcome to the Human Network are trademarks; Changing the Way We Work, Live, Play, and Learn and Cisco Store are service marks; and Access Registrar, Aironet, AsyncOS, Bringing the Meeting To You, Catalyst, CCDA, CCDP, CCIE, CCIP, CCNA, CCNP, CCSP, CCVP, Cisco, the

Cisco Certified Internetwork Expert logo, Cisco IOS, Cisco Press, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Cisco Unity, Collaboration Without Limitation, EtherFast, EtherSwitch, Event Center, Fast Step, Follow Me Browsing, FormShare, GigaDrive, HomeLink, Internet Quotient, IOS, iPhone, iQuick Study, IronPort, the IronPort logo, LightStream, Linksys, MediaTone, MeetingPlace, MeetingPlace Chime Sound, MGX, Networkers, Networking Academy, Network Registrar, PCNow, PIX, PowerPanels, ProConnect, ScriptShare, SenderBase, SMARTnet, Spectrum Expert, StackWise, The Fastest Way to Increase Your Internet Quotient, TransPath, WebEx, and the WebEx logo are registered trademarks of Cisco Systems, Inc. and/or its affiliates in the United States 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. (0812R)

Cisco has more than 200 offices worldwide. Addresses, phone numbers, and fax numbers are listed on the Cisco Website at www.cisco.com/go/offices.

CCDE, CCENT, Cisco Eos, Cisco HealthPresence, the Cisco logo, Cisco Lumin, Cisco Nexus, Cisco StadiumVision, Cisco TelePresence, Cisco WebEx, DCE, and Welcome to the Human Network are trademarks; Changing the Way We Work, Live, Play, and Learn and Cisco Store are service marks; and Access Registrar, Aironet, AsyncOS, Bringing the Meeting To You, Catalyst, CCDA, CCDP, CCIE, CCIP, CCNA, CCNP, CCSP, CCVP, Cisco, the Cisco Certified Internetwork Expert logo, Cisco IOS, Cisco Press, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Cisco Unity, Collaboration Without Limitation, EtherFast, EtherSwitch, Event Center, Fast Step, Follow Me Browsing, FormShare, GigaDrive, HomeLink, Internet Quotient, IOS, iPhone, iQuick Study, IronPort, the IronPort logo, LightStream, Linksys, MediaTone, MeetingPlace, MeetingPlace Chime Sound, MGX, Networkers, Networking Academy, Network Registrar, PCNow, PIX, PowerPanels, ProConnect, ScriptShare, SenderBase, SMARTnet, Spectrum Expert, StackWise, The Fastest Way to Increase Your Internet Quotient, TransPath, WebEx, and the WebEx logo are registered trademarks of Cisco Systems, Inc. and/or its affiliates in the United States 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. (0812R)

Americas HeadquartersCisco Systems, Inc.San Jose, CA

Asia Pacific HeadquartersCisco Systems (USA) Pte. Ltd.Singapore

Europe HeadquartersCisco Systems International BVAmsterdam, The Netherlands

Americas HeadquartersCisco Systems, Inc.San Jose, CA

Asia Pacific HeadquartersCisco Systems (USA) Pte. Ltd.Singapore

Europe HeadquartersCisco Systems International BVAmsterdam, The Netherlands

www.cisco.com/go/offices

Documents

CCIE Voice v3.0 Quick Reference - داتیس آراد ...datis-arad.com/PDF/Cisco/Cisco Press CCIE Voice v3.0 Quick... · Several best practices are associated with these different