Guest

Cisco Unified Communications Manager Session Management Edition

Cisco Unified Communications Manager Session Management Edition Deployment Guide Release 8.x

  • Viewing Options

  • PDF (10.5 MB)
  • Feedback
Cisco Unified Communications Manager Session Management Edition Deployment Guide Release 8.x

Table Of Contents

Cisco Unified Communications Manager Session Management Edition Deployment Guide Release 8.x

Purpose

Audience

Introduction

Scope of This Document

Unified CM Session Management Edition—Summary Description

When to Deploy Unified CM Session Management Edition

Differences between Unified CM Session Management Edition and Standard Unified CM Clusters

Unified CM Session Management Edition Licensing

Unified CM Session Management Edition Cluster Architectural Overview

Trunk Features of Unified CM Session Management Edition Release 8.5 and Later Releases

Route Local Rule for Single Trunks

Route Local Rule for Multiple Trunks Using Route Lists

Benefits of Run on All Unified CM Nodes and Multiple Trunk Destination IP Addresses

Leaf Unified CM Cluster Software Releases and Their Impact on Intercluster Trunk Types

SIP Delayed Offer Versus Early Offer, H.323 Slow Start Versus Fast Start

Using PRACK to Reduce Delay Before a Two-Way Media Connection Is Established on SIP Trunks

Unified CM Release 8.5 and Later Releases Early Offer Support for Voice and Video Calls (Insert MTP if Needed)

System-Wide Trunk Configuration Choices

System-Wide Trunk Configuration Guidance

SIP Early Offer for Voice and Video (Insert MTP if Needed)—Usage Guidance

End-to-End RSVP over SIP Trunks and SIP Early Offer/Delayed Offer

H.323 Gateways and H.323/H.225 Gatekeeper-Controlled Trunks

MGCP Gateways

Unified CM Session Management Edition—Call Routing, Call Rerouting and Cause Codes

Call Rejection from Destination UC Systems and Cause Codes

Note on Trunk Engagement and Call Rerouting

Stop Routing on Q.931 Disconnect Cause Code Service Parameter

How to Size a Unified CM Session Management Edition Cluster

Unified CM Session Management Edition Deployment Components

Unified CM Session Management Edition Clusters

Leaf Unified CM Clusters

IP-Based Third-Party Leaf UC Systems

TDM-Based Third-Party Leaf UC Systems

IP-PSTN and IP Trunks to Service Provider Networks

Session Border Control for IP-PSTN Connectivity

Centralized Applications

Applications That Unified CM Session Management Edition Supports

Applications That Must Connect to the Leaf Cluster

Unified CM Session Management Edition Deployment Models

Single Unified CM Session Management Edition Cluster Deployments

Call Distribution

Inbound Call Distribution

Outbound Call Distribution

Single Unified CM Session Management Edition Cluster with Clustering-Over-the-WAN

General Design Considerations with Clustering-Over-the-WAN Designs

Design Guidance for Leaf Cluster Trunk Connections to a Unified CM Session Management Edition Cluster Deployed with Clustering-Over-the-WAN

Design Guidance for Calls from Unified CM Session Management Edition Cluster Trunks in a Clustering-Over-the-WAN Deployment to Leaf UC Systems

Clustering-Over-the-WAN Bandwidth Calculations for Unified CM Session Management Edition

Intracluster Communication Signaling Bandwidth

Database Bandwidth Calculations

Unified CM Session Management Edition Clustering-Over-the-WAN Bandwidth Calculation

Multiple Distributed Unified CM Session Management Edition Clusters

Signaling and Media Delays over Long Distance Connections

Unified CM Session Management Edition Clusters with Registered IP Phones

Q.SIG Path Replacement over Intercluster Trunks

Notes on Q.SIG Deployments with Unified CM Session Management Edition

Unified CM Session Management Edition SAF CCD Deployments

Unified CM Session Management Edition and SAF with Centralized Call Routing

Advertising SAF CCD Routes to Leaf Clusters From/Through Unified CM Session Management Edition

Advertising SAF CCD Routes from Leaf Clusters to Unified CM Session Management Edition

Operational Considerations for Unified CM Session Management Edition and SAF CCD Deployments with Centralized Call Routing

Leaf Clusters Learning Their Own DN Ranges from Unified CM Session Management Edition

Routing Calls to the PSTN When IP Routes from Unified CM Session Management Edition to Leaf Clusters Are Not Available

Calls to Non-SAF UC Systems Over Static Unified CM Session Management Edition Trunks

PSTN Fallback for Calls to Non-SAF UC Systems

Unified CM Session Management Edition and SAF with Distributed Call Routing

Dial Plan Recommendations for Unified CM Session Management Edition Deployments

Global Numbering Plan

Digit-Manipulation Methods in Unified CM and Unified CM Session Management Edition Leaf Clusters

Number Normalization for Calls from Leaf Systems to Unified CM Session Management Edition

Number Normalization for Calls from Unified CM Session Management Edition to Leaf Systems

General Numbering-Plan Recommendations

Unified CM Session Management Edition/Unified CM Trunk Protocols and + Character Transport

Forwarded Calls and Diversion Information

Special Considerations for Normalization of Diversion Information

Diversion Information and Centralized Voicemail—Summary Recommendations

Centralized Tail-End Hop-Off with Decentralized PSTN Access

Call Admission Control Recommendations for Unified CM Session Management Edition Deployments

Unified CM Session Management Edition Management of the CAC Domain with Locations CAC

Leaf Clusters that Manage the CAC Domain with Locations CAC

Location-Based Call Admission Control over Intercluster Trunk

Q.SIG Path Replacement

Unified CM Session Management Edition with RSVP Deployments

Unified CM Session Management Edition Design with Leaf Clusters without RSVP SIP Precondition Support

Unified CM Session Management Edition Design with Leaf Clusters with RSVP SIP Precondition Support

Unified CM Session Management Edition Design with Mixed Leaf Clusters (with and without RSVP SIP Precondition Support)

Multiple Clusters Sharing a Single Platform for RSVP Agent

Trunk Security on Unified CM Session Management Edition Cluster Deployments

Secure SIP Trunks

Secure H.323 Trunks

Cisco Mobile Solutions and Unified CM Session Management Edition Deployments

Standard Leaf Cluster Mobility Deployments

Leaf Cluster Mobility Deployments with Unified CM Session Management Edition-Based PSTN Access

Mobility and Third-Party PBXs

Third-Party PBX Mobility/Single Number Reach Support with PSTN Access Through Unified CM Session Management Edition

Mobility Features Provided by Unified CM Session Management Edition for a Connected Third-Party PBX

Voicemail Applications on Unified CM Session Management Edition

Diversion Information and Centralized Voicemail—Summary Recommendations

Notes on RDNIS Delivery for Voicemail

Cisco TelePresence (Formerly Tandberg) VCS Integration with Unified CM Session Management Edition

Unified CM Session Management Edition Deployments with Cisco Unified Contact Center Enterprise

Unified CM Session Management Edition Trunk-to-Trunk SIP Header Transparency

Unified CM Session Management Edition Trunk-to-Trunk SIP Message Transparency

Supported Deployment Model

IPv6-Based Unified CM Session Management Edition Deployments

Summary IPv6 UC Design Guidance

Deploying Cross Cluster Extension Mobility with Unified CM Session Management Edition


Cisco Unified Communications Manager Session Management Edition Deployment Guide Release 8.x


Published: September 29, 2011

This document contains the following topics:

Purpose

Audience

Introduction

Scope of This Document

Unified CM Session Management Edition—Summary Description

When to Deploy Unified CM Session Management Edition

Differences between Unified CM Session Management Edition and Standard Unified CM Clusters

Unified CM Session Management Edition Licensing

Unified CM Session Management Edition Cluster Architectural Overview

Trunk Features of Unified CM Session Management Edition Release 8.5 and Later Releases

Route Local Rule for Single Trunks

Route Local Rule for Multiple Trunks Using Route Lists

Benefits of Run on All Unified CM Nodes and Multiple Trunk Destination IP Addresses

Leaf Unified CM Cluster Software Releases and Their Impact on Intercluster Trunk Types

SIP Delayed Offer Versus Early Offer, H.323 Slow Start Versus Fast Start

Using PRACK to Reduce Delay Before a Two-Way Media Connection Is Established on SIP Trunks

Unified CM Release 8.5 and Later Releases Early Offer Support for Voice and Video Calls (Insert MTP if Needed)

System-Wide Trunk Configuration Choices

System-Wide Trunk Configuration Guidance

SIP Early Offer for Voice and Video (Insert MTP if Needed)—Usage Guidance

End-to-End RSVP over SIP Trunks and SIP Early Offer/Delayed Offer

H.323 Gateways and H.323/H.225 Gatekeeper-Controlled Trunks

MGCP Gateways

Unified CM Session Management Edition—Call Routing, Call Rerouting and Cause Codes

Call Rejection from Destination UC Systems and Cause Codes

Note on Trunk Engagement and Call Rerouting

Stop Routing on Q.931 Disconnect Cause Code Service Parameter

How to Size a Unified CM Session Management Edition Cluster

Unified CM Session Management Edition Deployment Components

Unified CM Session Management Edition Clusters

Leaf Unified CM Clusters

IP-Based Third-Party Leaf UC Systems

TDM-Based Third-Party Leaf UC Systems

IP-PSTN and IP Trunks to Service Provider Networks

Session Border Control for IP-PSTN Connectivity

Centralized Applications

Unified CM Session Management Edition Deployment Models

Single Unified CM Session Management Edition Cluster Deployments

Call Distribution

Inbound Call Distribution

Outbound Call Distribution

Single Unified CM Session Management Edition Cluster with Clustering-Over-the-WAN

General Design Considerations with Clustering-Over-the-WAN Designs

Design Guidance for Leaf Cluster Trunk Connections to a Unified CM Session Management Edition Cluster Deployed with Clustering-Over-the-WAN

Design Guidance for Calls from Unified CM Session Management Edition Cluster Trunks in a Clustering-Over-the-WAN Deployment to Leaf UC Systems

Clustering-Over-the-WAN Bandwidth Calculations for Unified CM Session Management Edition

Intracluster Communication Signaling Bandwidth

Database Bandwidth Calculations

Unified CM Session Management Edition Clustering-Over-the-WAN Bandwidth Calculation

Multiple Distributed Unified CM Session Management Edition Clusters

Signaling and Media Delays over Long Distance Connections

Unified CM Session Management Edition Clusters with Registered IP Phones

Q.SIG Path Replacement over Intercluster Trunks

Notes on Q.SIG Deployments with Unified CM Session Management Edition

Unified CM Session Management Edition SAF CCD Deployments

Unified CM Session Management Edition and SAF with Centralized Call Routing

Advertising SAF CCD Routes to Leaf Clusters From/Through Unified CM Session Management Edition

Advertising SAF CCD Routes from Leaf Clusters to Unified CM Session Management Edition

Operational Considerations for Unified CM Session Management Edition and SAF CCD Deployments with Centralized Call Routing

Unified CM Session Management Edition and SAF with Distributed Call Routing

Dial Plan Recommendations for Unified CM Session Management Edition Deployments

Global Numbering Plan

Digit-Manipulation Methods in Unified CM and Unified CM Session Management Edition Leaf Clusters

Number Normalization for Calls from Leaf Systems to Unified CM Session Management Edition

Number Normalization for Calls from Unified CM Session Management Edition to Leaf Systems

General Numbering-Plan Recommendations

Unified CM Session Management Edition/Unified CM Trunk Protocols and + Character Transport

Forwarded Calls and Diversion Information

Centralized Tail-End Hop-Off with Decentralized PSTN Access

Call Admission Control Recommendations for Unified CM Session Management Edition Deployments

Unified CM Session Management Edition Management of the CAC Domain with Locations CAC

Leaf Clusters that Manage the CAC Domain with Locations CAC

Unified CM Session Management Edition with RSVP Deployments

Unified CM Session Management Edition Design with Leaf Clusters without RSVP SIP Precondition Support

Unified CM Session Management Edition Design with Leaf Clusters with RSVP SIP Precondition Support

Unified CM Session Management Edition Design with Mixed Leaf Clusters (with and without RSVP SIP Precondition Support)

Trunk Security on Unified CM Session Management Edition Cluster Deployments

Secure SIP Trunks

Secure H.323 Trunks

Cisco Mobile Solutions and Unified CM Session Management Edition Deployments

Standard Leaf Cluster Mobility Deployments

Leaf Cluster Mobility Deployments with Unified CM Session Management Edition-Based PSTN Access

Mobility and Third-Party PBXs

Third-Party PBX Mobility/Single Number Reach Support with PSTN Access Through Unified CM Session Management Edition

Mobility Features Provided by Unified CM Session Management Edition for a Connected Third-Party PBX

Voicemail Applications on Unified CM Session Management Edition

Diversion Information and Centralized Voicemail—Summary Recommendations

Notes on RDNIS Delivery for Voicemail

Cisco TelePresence (Formerly Tandberg) VCS Integration with Unified CM Session Management Edition

Unified CM Session Management Edition Deployments with Cisco Unified Contact Center Enterprise

Unified CM Session Management Edition Trunk-to-Trunk SIP Header Transparency

Unified CM Session Management Edition Trunk-to-Trunk SIP Message Transparency

Supported Deployment Model

IPv6-Based Unified CM Session Management Edition Deployments

Summary IPv6 UC Design Guidance

Deploying Cross Cluster Extension Mobility with Unified CM Session Management Edition

Purpose

This document provides conceptual information about Cisco Unified Communications Manager Session Management Edition (Unified CM Session Management Edition) and its components, as well as design considerations and guidelines for deploying Unified CM Session Management Edition.

Audience

This document provides information for network administrators and designers who are responsible for deploying the Unified CM Session Management Edition system. This document requires knowledge of Unified Communications and IP networking technology.

Introduction

As Unified Communications (UC) networks grow in size and increasing numbers of call control systems are deployed within enterprise networks, many UC managers must organize their UC infrastructure to simplify connectivity between multiple UC call control systems. Also, the growth in centralized IP-PSTN offerings from service providers and the administrative benefits gained from centralized UC applications are driving the need for a centralized UC aggregation platform. While you can use several single-protocol aggregation platforms, such as H.323 gatekeepers or SIP Proxy servers, for UC system aggregation, many customers operate in a multiprotocol UC environment. Furthermore, when aggregating UC systems that support hundreds of thousands of UC endpoints, powerful digit-manipulation tools that are easy to use and scale to support very large and complex dial plans are essential. Unified CM Session Management Edition provides a multiprotocol UC aggregation platform that can scale to support thousands of end UC systems and uses a web-based GUI to configure and manage extensive, complex dial plans and thousands of associated trunks.

Unified CM Session Management Edition is essentially a Cisco Unified Communications Manager (Unified CM) cluster, in which the majority of the devices connecting to the cluster use trunk connections rather than line-side connections. Unified CM Release 8.5 introduced a number of trunking features to deliver simplified call routing, interoperability, and availability for Unified CM Session Management Edition deployments.

Scope of This Document

Unified CM Session Management Edition uses the same software as Unified CM. The essential difference between a Unified CM Session Management Edition cluster and a Unified CM cluster is the way in which it is deployed. Typically, a Unified CM Session Management Edition cluster supports thousands of trunks, whereas a Unified CM cluster supports thousands of phones. This document discusses new design considerations and options for Unified CM Session Management Edition-based UC deployments, and is a supplementary document to the Cisco Unified Communications System Release 8.x SRND at http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/8x/uc8x.html.

Readers should be familiar with the contents of Cisco Unified Communications System Release 8.x SRND, because many of the chapters and design recommendations in Cisco Unified Communications System Release 8.x SRND have equal importance for both Unified CM Session Management Edition and Unified CM designs. Because Unified CM Session Management Edition clusters typically support far more trunk connections than endpoints (IP Phones), the reader of this document should, at a minimum, have read the Unified CM Trunks chapter in Cisco Unified Communications System Release 8.x SRND.

Unified CM Session Management Edition—Summary Description

UC deployments using Unified CM Session Management Edition are a variation of the multisite distributed call-processing deployment model (described in the Unified Communications Deployment Models chapter in Cisco Unified Communications System Release 8.x SRND at http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/8x/models.html#wp1043850). Typically, these deployments are used to interconnect large numbers of UC systems through a single front-end system, in this case the Unified CM Session Management Edition.

Unified CM Session Management Edition is essentially a Unified CM cluster with trunk interfaces only and generally no IP endpoints. It enables aggregation of multiple UC systems, referred to as leaf systems.

Typically, Unified CM Session Management Edition is used to interconnect multiple Unified CM clusters, third-party UC systems (IP- and TDM-based PBXs), PSTN connections, and centralized UC applications. (See Figure 1.)

Unified CM Session Management Edition deployments also can be used to migrate a deployment of multiple PBXs, and their associated phones, to a Unified CM cluster with IP Phones and relatively few trunks. That is, the Unified CM Session Management Edition cluster may start with a large number of trunks interconnecting many third-party PBXs, and migrate over time to a Unified CM cluster deployment with thousands of IP Phones.

Unified CM Session Management Edition supports the following trunk and call types:

H.323 Annex M1 intercluster trunks

SIP intercluster trunks

SIP trunks

H.323 trunks

MGCP trunks

Voice calls

Video calls

Encrypted calls

Fax calls

Figure 1

Multisite Deployment with Unified CM Session Management Edition

When to Deploy Unified CM Session Management Edition

Cisco recommends deploying Unified CM Session Management Edition to do any of the following:

Create and manage a centralized dial plan

Rather than configuring each UC system with a separate dial plan and trunks to connect to all other UC systems, Unified CM Session Management Edition allows you to configure the leaf UC systems with a simplified dial plan and trunks pointing to the Unified CM Session Management Edition cluster. Unified CM Session Management Edition holds the centralized dial plan and corresponding trunk routing information to all other UC systems.

Provide centralized PSTN access

Unified CM Session Management Edition can be used to aggregate PSTN access to one (or more) centralized IP-PSTN trunks. Centralized PSTN access is commonly combined with the reduction, or elimination, of branch-based PSTN circuits.

Centralize applications

Deploy Unified CM Session Management Edition to connect commonly used applications, such as voicemail, voice conferencing or video conferencing, directly to the Unified CM Session Management Edition cluster, thus reducing the overhead of managing multiple trunks to leaf systems.

Aggregate PBXs for migration to a UC system

Use Unified CM Session Management Edition as an aggregation point for multiple PBXs as part of the migration from legacy PBXs to a Unified CM system.

Differences between Unified CM Session Management Edition and Standard Unified CM Clusters

The Unified CM Session Management Edition software is exactly the same as Unified CM software. However, with Cisco Unified CM Release 8.5 (and later releases), the software has been enhanced to satisfy the requirements of this new deployment model. A Unified CM Session Management Edition cluster is designed to support a large number of trunk-to-trunk connections, and as such it is subject to the following design considerations:

Capacity

It is important that you correctly size the Unified CM Session Management Edition cluster based on the expected Busy Hour Call Attempts (BHCA) traffic load between leaf UC systems (for example, Unified CM clusters and PBXs) to and from any centralized PSTN connections and to any centralized applications. Determine the average BHCA and Call Holding Time for users of your UC system and share this information with your Cisco account systems engineer (SE) or Cisco partner to size your Unified CM Session Management Edition cluster correctly.

Trunks

Where possible, avoid the use of static media termination points (MTPs) on Unified CM trunks (that is, you must not enable MTP required on the SIP or H.323 trunks of leaf Unified CM or Unified CM Session Management Edition clusters). Trunks that do not use MTP required offer more codec choices; support voice, video, and encryption; and do not anchor trunk call-media to MTP resources. You can use dynamically inserted MTPs on trunks (for example, for DTMF translation from in-band to out-of-band). If a third-party UC system requires SIP Early Offer, use either the Early Offer support for voice and video calls (insert MTP if needed) feature on Unified CM SIP trunks or the Delayed Offer to Early Offer feature on Cisco Unified Border Element.

Unified CM releases

Cisco recommends Unified CM Release 8.6 or a later release for Unified CM Session Management Edition clusters and leaf clusters. You can deploy earlier releases of Unified CM in both the Unified CM Session Management Edition and leaf Unified CM clusters, but you might experience problems that can be resolved only if you upgrade your cluster to Unified CM Release 7.1(2) or a later release.

Interoperability

Even though most vendors do conform to standards, differences can and do exist between protocol implementations from various vendors. As with any standard Unified CM cluster, Cisco strongly recommends that you conduct end-to-end system interoperability testing with any unverified third-party UC system before you deploy the system in a production environment. The interoperability testing should verify call flows and features from Cisco and third-party leaf systems through the Unified CM Session Management Edition cluster. For more information about which third-party UC systems the Cisco interoperability team has tested, go to www.cisco.com/go/interoperability and select the link for Cisco Unified Communications Manager - Session Management Edition.

Load balancing for inbound and outbound calls

Configure trunks on the Unified CM Session Management Edition and leaf UC systems so that inbound and outbound calls are evenly distributed across the call-processing subscribers within the Unified CM Session Management Edition cluster.

Unified CM Session Management Edition Licensing

Unified CM Session Management Edition licenses are session-based and must be purchased for Unified CM Session Management Edition deployments. To determine the number of session licenses required for your Unified CM Session Management Edition deployment, work with your Cisco account team to correctly size your Unified CM Session Management Edition cluster. The number of sessions is the number of concurrent calls that are supported through your Unified CM Session Management Edition system.

You can purchase Unified CM Session Management Edition session licenses as part of the hardware and software purchasing process, or as part of a UC system upgrade. You can purchase and install additional session licenses at any time after the initial Unified CM Session Management Edition installation.

For information about ordering Unified CM Session Management Edition licenses, see Chapter 8 in the Cisco Unified Communications Solutions Ordering Guide at http://www.cisco.com/web/partners/downloads/partner/WWChannels/technology/ipc/downloads/uc_sol_og_ucl_final.pdf.

Unified CM Session Management Edition Cluster Architectural Overview

With few or no endpoints, Unified CM Session Management Edition essentially provides a multiprotocol trunk aggregation platform with sophisticated call-routing digit-manipulation features to manage large and very large centralized dial plans. Some of the key aspects of Unified CM Session Management Edition cluster design are as follows:

Availability of trunks and servers within the Unified CM Session Management Edition cluster

Load sharing of outbound trunk calls originating from nodes in the Unified CM Session Management Edition cluster

Load sharing of outbound calls over trunks to trunk destination addresses

Even distribution of inbound trunk calls to call-processing nodes in the Unified CM Session Management Edition clusters

How and when you configure these various trunk features depends largely upon the release of Unified CM software that you run in your leaf Unified CM clusters and Unified CM Session Management Edition cluster. Figure 2 shows typical trunk configurations for inbound and outbound calls through Unified CM and Unified CM Session Management Edition running Software Release 8.5 or later and Cisco Unified Border Element. Load balancing, trunk protocols, and features based on UC software releases are discussed in the following sections.

Figure 2

Typical Trunk Deployments with UC Software Release 8.5

Trunk Features of Unified CM Session Management Edition Release 8.5 and Later Releases

Most Unified CM Session Management Edition deployments are new cluster installations and Cisco recommends that you use the latest release of Unified CM. Unified CM Release 8.5 introduced a number of trunk features that improve load balancing and call distribution.

For SIP trunks, SIP intercluster trunks, and H.323 non-gatekeeper-controlled intercluster trunks the Run on All Unified CM Nodes feature and support for up to 16 destination addresses improve load balancing and call distribution. The Run on All Unified CM Nodes feature also improves load balancing and call distribution for route lists that are used with route groups and multiple trunks.

The Run on All Unified CM Nodes feature on trunks (and where applicable route lists) along with the route local rule provides deterministic node selection for calls outbound from Unified CM clusters and Unified CM Session Management Edition clusters. For more information about these features and their operation, see the Unified CM Trunks chapter in Cisco Unified Communications System Release 8.x SRND at http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/8x/trunks.html.

With SIP trunks, SIP intercluster trunks, and H.323 non-gatekeeper-controlled intercluster trunks you can use up to 16 destination addresses to eliminate the need for multiple intercluster trunks and provide even call distribution to the configured destination addresses.


Note H.323 intercluster trunks (ICTs) use round-robin distribution of calls to destination IP addresses. SIP trunks and SIP ICTs use random distribution of calls to destination IP addresses.


Figure 3 Unified CM Release 8.5 and Later—The Route Local Rule When Used in Conjunction with Run on All Unified CM Nodes and Multiple Destination IP Addresses with Single Trunks (No Route Lists)

Route Local Rule for Single Trunks

The route local rule operates in conjunction with the Run on All Unified CM Nodes feature enabled on the trunk, such that outbound trunk calls originate from the same node that the inbound call arrives on.

Figure 4 Unified CM Release 8.5 and Later—The Route Local Rule When Used in Conjunction with Run on All Unified CM Nodes and Multiple Destination IP Addresses with Multiple Trunks and Route Lists

Route Local Rule for Multiple Trunks Using Route Lists

The route local rule operates in conjunction with the Run on All Unified CM Nodes feature enabled on the route list and trunks, such that outbound trunk calls originate from the same node that the inbound call arrives on.

Benefits of Run on All Unified CM Nodes and Multiple Trunk Destination IP Addresses

The combined use of the Run on All Unified CM Nodes feature, multiple destination IP addresses per trunk, and the route local rule greatly simplifies call distribution between Unified CM and Unified CM Session Management Edition clusters, and other UC systems. For Unified CM or Unified CM Session Management Edition clusters that use these features, the node on which an inbound call arrives is used to establish the outbound trunk call. With multiple destination addresses for intercluster trunks (or by the use of multiple dial peers in IOS), calls can be evenly distributed across all nodes within a cluster and fewer intercluster trunks are required.

Leaf Unified CM Cluster Software Releases and Their Impact on Intercluster Trunk Types

With Unified CM Release 8.5 and later releases, SIP trunks have feature parity with H.323 Annex M1 intercluster trunks (ICTs) and also provide a range of additional trunk features. For a full comparison of SIP and H.323 ICT features, see the beginning of the Unified CM Trunks chapter in Cisco Unified Communications System Release 8.x SRND at http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/8x/trunks.html.

Some of the key SIP trunk features in Unified CM Release 8.5 and later releases are as follows:

SIP trunks can run on all Unified CM nodes*

Support for up to 16 destination IP addresses per trunk*

SIP OPTIONS ping keepalives

SIP Early Offer support for voice and video calls (insert MTP if needed)

Q.SIG over SIP**

SIP trunk normalization and transparency

Route lists can run on all Unified CM nodes*

*Also supported by Unified CM Release 8.5 and later H.323 non-gatekeeper-controlled ICTs.

**H.323 non-gatekeeper-controlled ICTs also support Q.SIG using Annex M1.

In deployments in which both the leaf Unified CM cluster and the Unified CM Session Management Edition cluster support Unified CM Release 8.5 or later releases, Cisco recommends SIP trunks because of the additional features that they support. (In particular, SIP OPTIONS Ping support, which overcomes the limitations of the per call time-out trunk destination failure detection mechanism that H.323 trunks use. SIP OPTIONS Ping sends Out of Dialog SIP OPTIONS Ping Requests to all trunk destination IP addresses to dynamically track trunk destination reachability.)

In deployments in which the leaf Unified CM cluster or the Unified CM Session Management Edition cluster supports Unified CM releases earlier than Release 8.5, Cisco recommends H.323 Annex M1 trunks because of the richer feature set that H.323 ICTs support compared with SIP ICTs. (For details, see the Unified CM Trunks chapter in Cisco Unified Communications Solution Reference Network Design (SRND) Based on Cisco Unified Communications Manager Release 7.x at http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/7x/trunks.html.)

With Unified CM releases earlier than Release 8.5, the key benefit that H.323-based ICTs offer is support for Q.SIG features, such as Path Replacement and Call Back using H.323 Annex M1. SIP trunks support only a single-destination IP address, whereas H.323 ICTs support up to three destination IP addresses per trunk, providing improved distribution of trunks and requiring fewer trunks.

SIP Delayed Offer Versus Early Offer, H.323 Slow Start Versus Fast Start

When you use SIP or H.323 trunks in Unified CM Session Management Edition deployments, you must choose one of two options for each trunk protocol type:

SIP Delayed Offer or SIP Early Offer

H.323 Slow Start or H.323 Fast Start

SIP Delayed Offer and H.323 Slow Start trunk configurations do not use static MTPs, but can require additional messages to be exchanged before two-way media is established.

H.323 Fast Start trunks and SIP trunks that use MTP Required for Early Offer use an MTP for every outbound call. These static MTPs impose a single codec limitation for trunk calls, that limits calls over these trunks to voice calls only using a single codec type (for example G711, G729). In comparison with H.323 Slow Start and SIP Delayed Offer trunks, H.323 Fast Start trunks and SIP Early Offer trunks generally exchange fewer messages before two-way media is established.

These trunk characteristics affect your choice of trunk configuration based on the media requirements of your UC deployment. The following are general guidelines:

Cisco recommends SIP Delayed Offer or H.323 Slow Start trunks if you require voice, video or encrypted calls between clusters, because these trunk types do not use static MTPs for every outbound call.

Although not generally an issue, if you encounter media clipping at the beginning of a call due to very long signaling delays between endpoints, SIP Early Offer or H.323 Fast Start can reduce the delay before two-way media is established. Note, however, that if you use H.323 Fast Start trunks or SIP trunks that use MTP Required for Early Offer, the single-codec limitation that is associated with the MTP that these trunk types use limits calls to voice only.

Certain UC applications, such as IVRs, try to establish a one-way media connection as early as possible during call setup. This IVR-to-caller media connection can be established as soon as the media characteristics (IP address, UDP port, codecs supported, and so forth) are sent to the IVR. For SIP Early Offer calls, the media characteristics of the caller are sent with the initial SIP INVITE, allowing the IVR to establish a media connection immediately. With SIP Delayed Offer, typically five SIP messages must be exchanged before a media connection from the IVR to the caller can be set up. Likewise, for H.323: H.323 Fast Start allows media to be established almost immediately after the first message is sent, whereas H.323 Slow Start involves the exchange of many more messages before a media connection can be established. If you encounter long signaling delays between the caller and the IVR, SIP Early Offer and H.323 Fast Start allow a one-way media connection from the IVR to be established more quickly.

Figure 5

SIP Early Offer Call

Using PRACK to Reduce Delay Before a Two-Way Media Connection Is Established on SIP Trunks

SIP defines two types of responses: final and provisional. Final responses convey the result of the processed request and are sent reliably (they are acknowledged). Provisional responses provide information about the progress of the request but are not sent reliably. That is, the sender of a provisional response does not know that it has been received. The Offer and Answer exchange for media negotiation during a SIP call setup must be sent reliably. SIP 1XX responses are provisional (not reliable) and for standard SIP calls this means that the Offer or Answer Session Description Protocol (SDP) body cannot be sent with these responses as part of the call setup. As can be seen in Figure 6, sending the SIP Offer or Answer in a 100 Trying or 180 Ringing message can reduce the number of SIP messages that must be exchanged before two-way media is established.

Figure 6

SIP Delayed Offer Call without PRACK

To send an Offer or Answer with a provisional 1XX response, these responses must be sent reliably. Provisional Acknowledgment (PRACK) is used to provide 1XX responses reliably.

Figure 7

SIP Delayed Offer Call Using PRACK to Send the SIP Offer in a 183 Response

The use of PRACK (also known as Early Media) can be enabled on both SIP Early Offer and Delayed Offer Unified CM trunks. For a SIP trunk to support Early Media cut-through, you must enable PRACK through the SIP Rel1XX Options feature in the SIP profile that is associated with the trunk.


Note Not all UC systems support PRACK.


Figure 8 SIP Early Offer Call Using PRACK to Send the SIP Answer in a 183 Response

Unified CM Release 8.5 and Later Releases Early Offer Support for Voice and Video Calls (Insert MTP if Needed)

As mentioned in Leaf Unified CM Cluster Software Releases and Their Impact on Intercluster Trunk Types, with Unified CM Release 8.5 (and later releases), Cisco recommends SIP trunks because they have feature parity with H.323 Annex M1 intercluster trunks and also provide a range of additional trunk features.

One SIP trunk feature that is introduced with Unified CM Release 8.5 is Early Offer support for voice and video calls (insert MTP if needed). This feature is designed to reduce MTP usage, and if an MTP is inserted into the call flow to overcome the single-voice-codec limitation of MTP Required Early Offer.

Unified CM does not need to insert an MTP to create an outbound Early Offer call over a SIP trunk if Unified CM receives the inbound call by any of the following means:

On a SIP trunk using Early Offer

On an H.323 trunk using Fast Start

On an MGCP trunk

From a SIP-based IP Phone registered to Unified CM

From newer SCCP-based Cisco Unified IP Phone models registered to Unified CM (For details, see the Endpoint Features Summary in the Unified Communications Endpoints chapter in Cisco Unified Communications System Release 8.x SRND at http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/8x/endpnts.html#wp1045087.)

For the preceding devices, Unified CM uses the media capabilities of the endpoint and applies codec filtering rules based on the region-pair of the calling device and outgoing SIP trunk to create the offer SDP for the outbound SIP trunk. In most cases, the offer SDP has the IP address and port number of the endpoint initiating the call. The preceding discussion assumes that Unified CM does not have to insert an MTP for other reasons such as a DTMF mismatch, TRP requirements, or a transcoder requirement when there is no common codec between the regions of the calling device and the SIP trunk.

When you configure Early Offer support for voice and video calls (insert MTP if needed) on the SIP profile of a trunk, calls from older SCCP-based phones, SIP Delayed Offer trunks, and H.323 Slow Start trunks cause Unified CM to allocate an MTP, if an MTP or transcoder is not already allocated for that call for another reason. The MTP is used to generate an offer SDP with a valid media port number and IP address. The MTP is allocated from the media resources that are associated with the calling device rather than from the media resources of the outbound SIP trunk. (This prevents the media path from being anchored to the MTP of the outbound SIP trunk.) If the MTP cannot be allocated from the Media Resource Group List (MRGL) of the calling device, the MTP allocation is attempted from the MRGL of the SIP trunk.

For calls from older SCCP-based phones registered to Unified CM, some of the media capabilities of the calling device (for example, supported voice codecs, video codecs, and encryption keys if supported) are available for media exchange through the SDP. (For a list of these phones, see the Endpoint Features Summary in the Unified Communications Endpoints chapter in Cisco Unified Communications System Release 8.x SRND at http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/8x/uc8x.html.) Unified CM will create a superset of the endpoint and MTP codec capabilities and apply the codec filtering based on the applicable region-pair settings. The outbound Offer SDP will use the IP address and port number of the MTP and can support voice, video, and encrypted media. Note that the IOS MTP should be configured to support the pass-through codec.

When Unified CM receives an inbound call on an H.323 Slow Start or SIP Delayed Offer trunk, the media capabilities of the calling device are not available when the call is initiated. In this case, Unified CM must insert an MTP and use its IP address and UDP port number to advertise all supported audio codecs (after region-pair filtering) in the Offer SDP of the initial INVITE sent over the outbound SIP trunk. When the Answer SDP is received on the SIP trunk, if it contains a codec that the calling endpoint supports, no additional offer-answer transaction is needed. In case of codec mismatch, Unified CM can either insert a transcoder to address the mismatch or send a Re-INVITE or UPDATE to trigger media negotiation. Calls from H.323 Slow Start or SIP Delayed Offer trunks support audio only in the initial call setup, but they can be upgraded mid-call to support video and SRTP if the call media is renegotiated (for example, after Hold/Resume).

System-Wide Trunk Configuration Choices

A large Unified CM Session Management Edition deployment may consist of hundreds or thousands of trunks connected to leaf Unified CM systems, IP PBXs, IP trunks to IOS gateways connected to TDM-based PBXs, PSTN connections and UC applications.

In many situations, the UC system that connects to Unified CM Session Management Edition predetermines the choice of protocol that is used on the trunk to Unified CM Session Management Edition (Unified CM Release 8.5 and later releases). For example,

IP-PSTN services tend to be SIP-based today.

For leaf Unified CM clusters that run Unified CM Release 8.5 and later releases, Cisco recommends SIP trunks.

For leaf Unified CM clusters that run Unified CM releases earlier than Release 8.5, Cisco recommends H.323 non-gatekeeper-controlled intercluster trunks.

IP PBXs tend to use SIP trunks today.

IOS gateways can use H.323, MGCP or SIP as a trunk protocol. With a Unified CM Session Management Edition cluster that uses Unified CM Release 8.5 or later releases, Cisco recommends SIP trunks.

After the trunk protocol from the leaf UC system to Unified CM Session Management Edition is determined, for SIP and H.323 trunks an additional configuration choice must be made. That is,

H.323 Slow Start or H.323 Fast Start

SIP Delayed Offer or SIP Early Offer

The benefits and drawbacks of each of these configuration options have been discussed in SIP Delayed Offer Versus Early Offer, H.323 Slow Start Versus Fast Start.

This Unified CM/Unified CM Session Management Edition trunk configuration affects outbound calls only. For inbound calls Unified CM/Unified CM Session Management Edition can accept SIP Early Offer and Delayed Offer (or H.323 Slow Start and Fast Start) calls on the same trunk. Therefore, the need to configure SIP Early Offer or H.323 Fast Start will typically be determined by the UC system that Unified CM Session Management Edition is connecting to.


Note For trunk calls in which an MTP is required, if MTP allocation fails (for example, because of a lack of MTP resources) the clusterwide default behavior is to proceed with the call without an MTP. That is, for a SIP Early Offer trunk, failure to allocate an MTP would result in a Delayed Offer being sent. To configure this behavior, use the Unified CM Service Parameter Fail Call if MTP Allocation Fails. Default value = False.


System-Wide Trunk Configuration Guidance

When you use Unified CM Session Management Edition to interconnect multiple UC systems, Cisco recommends SIP Delayed Offer or H.323 Slow Start trunks. SIP Delayed Offer and H.323 Slow Start trunks support voice, video or encrypted calls between clusters, because these trunk types do not use static MTPs for every outbound call (static MTPs limit calls to [single codec] voice calls only).

H.323-based leaf UC systems that must receive H.323 Fast Start are limited to (single codec) voice calls only, and Unified CM Session Management Edition uses an MTP for every outbound call.

For SIP-based leaf UC systems that must receive SIP Early Offer, with Unified CM Release 8.5 and later releases two options are available:

SIP Early Offer with MTP Required

SIP Early Offer for voice and video (insert MTP if needed)

SIP Early Offer trunks with MTP Required have the same limitations as H.323 Fast Start leaf UC systems. That is, calls are limited to (single codec) voice calls only and Unified CM Session Management Edition uses an MTP for every outbound call.

SIP Early Offer for Voice and Video (Insert MTP if Needed)—Usage Guidance

Using SIP Early Offer for voice and video (insert MTP if needed), can reduce MTP usage and can also allow voice, video and encrypted calls to be made. However, bear in mind, that the capabilities of an outbound call on this trunk type are determined by the characteristics of the inbound call. (For Unified CM clusters the inbound call will typically come from a phone, for Unified CM Session Management Edition clusters the inbound call will be received on a trunk.)

For single Unified CM clusters that deploy SIP trunks that use the SIP Early Offer for voice and video (insert MTP if needed) feature, calls from registered phones to this Early Offer trunk type support voice, video, and encryption, but older SCCP-based phones always use an MTP when calls are made over the SIP trunk.

For Unified CM Session Management Edition designs, if you need Early Offer, Cisco recommends that you use SIP Early Offer for voice and video (insert MTP if needed) rather than Early Offer with MTP Required, because MTP usage can be reduced. Bear in mind, however, that combining SIP Delayed Offer or H.323 Slow Start trunks on Unified CM Session Management Edition with SIP Early Offer trunks that use SIP Early Offer for voice and video (insert MTP if needed) can lead to situations where the benefit of reduced MTP usage is undermined. That is, calls from H.323 Slow Start or SIP Delayed Offer trunks to SIP Early Offer trunks use an MTP and support audio only in the initial call setup, but they can be upgraded mid-call to support video and SRTP if the call media are renegotiated (for example, after Hold/Resume).

An example of such a situation is a Unified CM Session Management Edition design with one or more leaf Unified CM clusters that run UC releases earlier than Unified CM Release 8.5. In this case, if you desire intercluster voice, video, and encrypted calls, you use a H.323 Slow Start trunk between the Unified CM cluster and Unified CM Session Management Edition. If the Unified CM Session Management Edition cluster also has a SIP trunk to an IP-PSTN service that must receive SIP Early Offer, you can use SIP Early Offer for voice and video (insert MTP if needed) on the SIP trunk toward the IP-PSTN. In this case an MTP is used for every call from the H.323 Slow Start trunk to the SIP IP-PSTN.

Or, as a preferred alternative, if a Cisco Unified Border Element Session Border Controller (SBC) is deployed as the enterprise/service provider border demarcation point SIP Delayed Offer can be configured on the Unified CM Session Management Edition trunk to the IP-PSTN, and the Cisco Unified Border Element Delayed Offer to Early Offer feature can be used to convert the Delayed Offer from Unified CM Session Management Edition to and Early Offer to the IP-PSTN.

The Cisco Unified Border Element Delayed Offer to Early Offer feature can be particularly useful in deployments that support large numbers (many thousands) of concurrent IP-PSTN calls. For example, Cisco Unified Border Element platforms such as the Aggregation Services Router (ASR) series can support up to 15,000 concurrent calls. When large volumes of concurrent calls need to be supported, avoiding the need to use an MTP for every outbound call can provide significant cost savings.

Figure 9 Unified CM Session Management Edition Designs—Trunk Configuration in Which Clusters Use Releases Earlier and Later Than Unified CM Release 8.5

Figure 10 Unified CM Session Management Edition Designs—Trunk Configuration in Which All Clusters Use Unified CM Release 8.5 or Later

End-to-End RSVP over SIP Trunks and SIP Early Offer/Delayed Offer

If End-to-End RSVP over SIP Trunks is enabled in the SIP profile of the trunk, Unified CM sends SIP Early Offer for every outbound call. End-to-End RSVP, MTP Required and SIP Early Offer for voice and video (insert MTP if needed) are mutually exclusive configurations. Only one of these configuration options can be enabled on a SIP trunk.

H.323 Gateways and H.323/H.225 Gatekeeper-Controlled Trunks

Other than H.323 non-gatekeeper-controlled intercluster trunks, all other H.323 trunks and H.323 gateways on Unified CM do not support the Run on All Unified CM Nodes feature introduced in Unified CM Release 8.5. These trunks and gateways continue to use Unified CM groups, such that calls can originate only from up to three nodes within a cluster per trunk. If you need to distribute outbound calls over more than three nodes, use multiple trunks in route lists and route groups. Also bear in mind that the route local rule applies to these trunks and gateways in route lists and route groups. For Unified CM clusters that use Release 8.5 and later releases, use the Run on All Unified CM Nodes feature on all route lists. For Unified CM clusters that use releases earlier than Release 8.5 (where the route list is active only on the primary node in its Unified CM group), do not select a node in the route list Unified CM group that is also used by the trunks that are associated with the route list (because the route local rule causes all calls to originate only from the node that the trunk and route list share).

If you need many H.323 gateways and H.323/H.225 gatekeeper-controlled trunks in your Unified CM Session Management Edition design, or if you expect very large call volumes over relatively few trunks of this kind, ensure that you evenly distribute outbound and inbound calls across the nodes within the cluster.

MGCP Gateways

MGCP is commonly used to interconnect IOS gateways and Unified CM clusters. The primary reason for the popularity of MGCP gateways is that the IOS gateway requires only a limited amount of configuration. (That is, you do not need to configure dial peers because the Q.931 signaling channel is backhauled to Unified CM.) With Unified CM Release 8.5 (and later releases), SIP-based gateways provide a range of feature enhancements that make SIP the preferred protocol when connecting to Unified CM/Unified CM Session Management Edition. If you chose to use MGCP, bear in mind that call signaling originates and terminates on a single node within the cluster (the primary Unified CM group node that terminates the Q.931 signaling channel). If you deploy many MGCP gateways in your Unified CM Session Management Edition design, ensure that you evenly distribute the gateways and call signaling across all nodes within the cluster.

Figure 11 IOS Gateway Features by Protocol

Unified CM Session Management Edition—Call Routing, Call Rerouting and Cause Codes

When Unified CM Session Management Edition receives an inbound call it uses its configured dial plan to attempt to route the call onward over an outbound trunk. If Unified CM Session Management Edition cannot route the call to the dialed destination, Unified CM Session Management Edition or the originating UC system can reroute the call.

Unified CM Session Management Edition and Unified CM use multiple trunks in route lists and route groups to reroute calls through an alternative media path.

Several events trigger rerouting of a call to an alternate trunk in a route list and route group. For example:

The trunk is marked as out of service (SIP trunks that use OPTIONS Ping)

A trunk connection (TCP/TLS) cannot be established for the attempted call

The trunk connection times out after a number of call attempts

The receipt of SIP response, H.323 message, or Q.931 cause code that indicates that the call cannot proceed through this trunk

Insufficient call admission control bandwidth

Call Rejection from Destination UC Systems and Cause Codes

When calls to destination UC systems cannot proceed, the called system generally returns an indication of the cause of the call rejection to its peer UC system. The method used to indicate the cause of a call failure is protocol dependent. Unified CM converts call-progress messages of this type that it receives over SIP, H.323, and MGCP trunks into their equivalent PSTN Q.931/Q.850 cause code, and determines how to proceed with the call.

The default operation of Unified CM/Unified CM Session Management Edition on receipt of various cause codes is as follows:

If the outbound trunk is not part of a route list or route group and the inbound call arrives on a trunk, any received cause code is returned to the calling UC system over the inbound trunk (using the trunk protocol Q.850 cause code equivalent message).

Figure 12 Call Rerouting with No Route Lists or Route Groups on Unified CM Session Management Edition

Figure 13 Call Rerouting with No Route Lists or Route Groups on Unified CM Session Management Edition

If the outbound trunk is part of a route list or route group:

If a cause code that indicates an Unallocated Number or User Busy is received from the called system, Unified CM/Unified CM Session Management Edition stops routing and does not attempt to reroute the call through another trunk in the route list.

If insufficient bandwidth is available on the selected media path to proceed with the call, Unified CM/Unified CM Session Management Edition does not stop routing and attempts to reroute the call through another trunk in the route list.

If any other cause code is received from the called system, Unified CM/Unified CM Session Management Edition does not stop routing and attempts to reroute the call through another trunk in the route list.

The Unified CM/Unified CM Session Management Edition Enterprise Parameters-Clusterwide Parameters (Route Plan) can be used to configure the above behavior. In particular, Unified CM/Unified CM Session Management Edition can be configured to stop routing when it receives a specific range of cause codes.

For a description of Q.850 cause codes and their mapping to SIP messages see the documentation at

http://www.cisco.com/en/US/docs/ios/12_2t/12_2t11/feature/guide/ftmap.html

and

http://www.cisco.com/en/US/docs/ios/12_2t/12_2t11/feature/guide/ftbibble.html


Note Unified CM uses the same SIP stack as IOS, so the mappings of Q.850 cause codes to SIP messages in the preceding documentation also generally apply to Unified CM SIP trunks.


Figure 14 Call Rerouting with Route Lists and Route Groups on Unified CM Session Management Edition

Figure 15 Call Rerouting with Route Lists and Route Groups on Unified CM Session Management Edition

Note on Trunk Engagement and Call Rerouting

When the system initially presents a call to a member of a route list, Unified CM reroutes for all cause codes other than User Busy and Unallocated Number.

The value of the associated service parameters for the Cisco Unified CM service determines the rerouting decision for those cause codes. The Clusterwide Parameters (Route Plan) grouping includes the Stop Routing on Out of Bandwidth flag, Stop Routing on User Busy flag, and Stop Routing on Unallocated Number flag service parameters. You can set each service parameter to True or False.

The default settings are shown in Figure 16. (Unified CM reroutes for all cause codes other than User Busy and Unallocated Number.)

Figure 16 Route Plan—Clusterwide Configuration Parameters—Stop Routing

After a route list locks onto a trunk and media negotiation begins, no rerouting occurs. The media-connect time of the endpoints and the stop routing service parameters determine when a route list stops hunting for the next route group. When media negotiation begins, Unified CM considers that the far-end device/user is reached. At this point routing is complete and the route list cannot reroute.

Stop Routing on Q.931 Disconnect Cause Code Service Parameter

Unified CM uses this service parameter to determine its routing behavior when a call that is routed to a remote site through a route list is released and a Q.931 cause code is sent to Unified CM. If the cause code that is encountered in the message matches a cause code that this parameter specifies, a local Unified CM stops routing the call. (The call is not sent to the next device in the route list.)

How to Size a Unified CM Session Management Edition Cluster

To correctly size a Unified CM Session Management Edition cluster, the number of concurrent calls and the frequency of calls through the Unified CM Session Management Edition cluster needs to be determined. Once these numbers have been calculated the number of Unified CM Session Management Edition call-processing server pairs can be determined based on the performance of the selected Unified CM Session Management Edition server platform.

To determine the Unified CM Session Management Edition cluster size, the following information needs to be provided by the customer:

Total number of users within the UC system

Average Busy Hour Call Attempts (BHCA) per user

The Average Call Holding Time (CHT) per user

The Unified CM Session Management Edition sizing tool (http://tools.cisco.com/cucst/faces/login.jsp > New Solutions > Individual Product Sizing) is available to Cisco partners and employees. The Unified CM Session Management Edition sizing tool allows you to define:

Leaf clusters/UC systems by the trunk protocol that they use to connect to Unified CM Session Management Edition

The percentage split of users across each leaf cluster type

The percentage of off-net calls

The percentage of on-net calls

The percentage of calls that stay within the cluster

Percentage expected growth

The output of the Unified CM Session Management Edition sizing tool provides details of the number of call-processing server pairs that are required in the Unified CM Session Management Edition cluster, the average calls per second per server, the average number of concurrent calls per server, and the number of session manager licenses that are required.


Note The sizing tool output does not include a dedicated Publisher server, which must be part of all Unified CM Session Management Edition cluster deployments.


Unified CM Session Management Edition Deployment Components

This section discusses the components of a Unified CM Session Management Edition deployment.

Unified CM Session Management Edition Clusters

Unified CM Session Management Edition cluster servers can be deployed on the following platforms:

Cisco Unified Computing System B200 M1/M2—B-series Blade Server

Cisco Unified Computing System C210 M1/M2—2U Rack-Mount Server

Cisco Media Convergence Server (MCS) 7845-I3 and HP DL380G6 servers

Each server can support up to 9000 concurrent calls. The calls-per-second performance of the servers is dependent on the platform type and trunk protocols in use. For example, SIP-trunk-to-SIP-trunk calls on the MCS 7845 I3 server are typically capable of 48 calls per second.


Note The Unified CM Session Management Edition sizing tool uses average calls-per-user and call-holding times to determine the size of the Unified CM Session Management Edition cluster and scales down the cluster size to account for call peaks. Likewise, trunk-to-trunk calls-per-second performance varies based on the trunk protocols used. The Unified CM Session Management Edition sizing tool takes into account these performance differences when it determines the Unified CM Session Management Edition cluster size.


Cisco generally recommends that you should deploy Unified CM Release 8.5 or a later release on the Unified CM Session Management Edition cluster, because these releases support a number of trunk-specific feature enhancements. If you deploy an earlier Unified CM release, Cisco recommends Unified CM Release 7.1(2) or later. You can deploy Unified CM releases earlier than Release 7.1(2) but you might experience problems that you can resolve only if you upgrade your cluster to Unified CM Release 7.1(2) or later.

Leaf Unified CM Clusters

You should deploy leaf Unified CM clusters with Unified CM Release 7.1(2) or a later release. (Cisco recommends Unified CM Release 8.5 or later.) You can deploy Unified CM releases earlier than 7.1(2), but you might experience problems that you can resolve only if you upgrade your cluster to Unified CM Release 7.1(2) or later.

IP-Based Third-Party Leaf UC Systems

In most cases, the third-party UC system capabilities (that is, support for SIP or H.323) determine the trunking protocol that is used to connect to Unified CM Session Management Edition. If an application supports both SIP and H.323 protocols, Cisco recommends that SIP trunks be used with Unified CM Release 8.5 or later Unified CM Session Management Edition clusters. For Unified CM Session Management Edition clusters running releases earlier than Release 8.5, you can use either SIP trunks or H.323-based gateways/trunks.

TDM-Based Third-Party Leaf UC Systems

TDM-based third-party leaf UC systems are typically PBXs or Key Systems. These third-party UC systems use an IOS voice gateway to connect to the Unified CM Session Management Edition. IOS gateways support Q.931 and Q.SIG based TDM interfaces (and analog interfaces, if required). The IP connection from the IOS gateway to Unified CM Session Management Edition can use SIP, H.323, or MGCP call-control protocols. In general, Cisco recommends SIP or Q.SIG-over-SIP trunk connections to Unified CM Session Management Edition, because they benefit from a number of new features in Unified CM Release 8.5. You can use H.323 and MGCP, but these protocols do not benefit from the same feature set as SIP trunks. The use of H.323- and MGCP-based trunks on Unified CM Session Management Edition is discussed in H.323 Gateways and H.323/H.225 Gatekeeper-Controlled Trunks and MGCP Gateways.

IP-PSTN and IP Trunks to Service Provider Networks

Service providers are increasing their offerings of non-TDM PSTN connections to enterprise customers. Apart from the key benefit of the cost savings if you deploy non-TDM interfaces, these IP-based PSTN connections can also offer reduced tariffs and additional voice features compared with traditional PSTN interfaces.

You can use Unified CM Session Management Edition to aggregate PSTN access through one (or more) centralized IP-PSTN trunks. Centralized PSTN access is commonly combined with the reduction, or elimination, of branch-based PSTN circuits.

Figure 17 Centralized PTSN

One or more trunks from the Unified CM Session Management Edition cluster can connect to the service provider (SP) IP-PSTN service through session border controllers (SBCs), such as the Cisco Unified Border Element. Typically, all PSTN calls to and from the enterprise use this set of trunks.

Although some H.323-based IP-PSTN services do exist today, the majority of IP-PSTN trunks from service providers use SIP as the enterprise-to-SP call control protocol.

Session Border Control for IP-PSTN Connectivity

Cisco Unified Border Element is a key component in the enterprise UC network and is deployed at the edge of the enterprise network for IP-PSTN connectivity to service providers. It provides a controlled demarcation point and a secure network-to-network interface. Cisco Unified Border Element is a licensed Cisco IOS application that is available on the following platforms:

Cisco Integrated Service Routers Generation 2 (ISR-G2s, such as 29xx, 39xx)

Cisco 1000 Series Aggregation Services Routers (ASRs)

Cisco Integrated Service Routers (ISRs, such as 28xx, 38xx)

Cisco AS5000XM Media gateways

Depending on the hardware platform, Cisco Unified Border Element can provide session scalability from four to 16,000 concurrent voice calls. Cisco Unified Border Element provides scalability and redundancy on the following platforms:

The ISR-G2 platforms, which can provide box-to-box redundancy with media preservation for stable active calls (Cisco Unified Border Element Release 8.5 in Cisco IOS Release 15.1.2T or later)

The ASR platforms, which can provide box-to-box or inbox redundancy with media and signaling preservation (stateful failover) for stable active calls (Release 3.2)

Centralized Applications

The deployment of Unified CM Session Management Edition enables commonly used applications, such as voicemail, voice conferencing or video conferencing, to connect directly to the Unified CM Session Management Edition cluster. This reduces the overhead of managing multiple trunks-to-leaf systems.

Figure 18 Centralized Applications

Applications That Unified CM Session Management Edition Supports

Unified CM Session Management Edition supports the following applications:

Cisco Unity and Cisco Unity Connection

Cisco Unified MeetingPlace and Cisco Unified MeetingPlace Express

SIP- and H.323-based video conferencing systems

Third-party voicemail systems

Fax servers

Cisco Unified Mobility

Applications That Must Connect to the Leaf Cluster

The following applications must connect to the leaf cluster:

Cisco Unified Contact Center and Cisco Unified Contact Center Express

Cisco Unified Presence Server

Cisco Unified Communications Manager Attendant Console

Cisco Emergency Responder (CER)

As a general guideline, those applications that rely only on number-based call routing to establish calls can connect to Unified CM Session Management Edition. Applications that require additional interfaces (for example, CTI) to track device state must connect to the leaf cluster.

If you deploy phones on the Unified CM Session Management Edition cluster, you can deploy any standard UC application to serve these phones.

Unified CM Session Management Edition Deployment Models

The deployment of a Unified CM Session Management Edition cluster in conjunction with multiple leaf Unified CM clusters and third-party UC systems is a variation on the multisite distributed call-processing deployment model described in Cisco Unified Communications System Release 8.x SRND at http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/8x/uc8x.html. Depending on the size of the enterprise UC network, your UC design may include one or more Unified CM Session Management Edition clusters. For example, a large European organization may have Unified CM clusters and third-party UC systems in several countries and use a Unified CM Session Management Edition cluster to interconnect these systems. Whereas, a large global organization may have a number of regionalized Unified CM Session Management Edition clusters (for example, Europe, Asia Pacific, North America, and so forth), where each Unified CM Session Management Edition cluster serves the leaf UC systems within a region and has direct connections to other Unified CM Session Management Edition clusters.


Note The discussion that follows assumes that the Unified CM Session Management Edition cluster supports trunks only.


Single Unified CM Session Management Edition Cluster Deployments

A single Unified CM Session Management Edition cluster can consist of up to eight call-processing subscribers (or up to 16 call-processing subscribers in a Unified CM Session Management Edition megacluster deployment). A standard Unified CM Session Management Edition cluster can support up to 36,000 concurrent calls with server redundancy. A dedicated Publisher server is required for the Unified CM Session Management Edition cluster and depending on the deployment, the following components may also be required:

TFTP services to serve files to MGCP-based gateways and IP Phones (if used)

Media termination points for SIP Early Offer, or to address DTMF transport mismatches

Transcoders

RSVP Agents


Note Music On Hold is not required on a Unified CM Session Management Edition cluster without phones, because the holding device invokes Music On Hold.


Call Distribution

In any Unified CM Session Management Edition design, even call distribution across all call-processing nodes within the cluster is desirable. Bear in mind the route local rule (discussed earlier) and the role that it plays with single trunks and with multiple trunks in route lists and route groups. Where possible, enable the Run on All Unified CM Nodes feature on trunks and route lists. Where this is not possible, ensure that you evenly distribute trunk instances across all nodes within the cluster. Also ensure that the primary node in the Unified CM group of a route list is not the same as any of the nodes that the trunks that are associated with this route list use.

Inbound Call Distribution

Inbound call distribution to nodes in the Unified CM Session Management Edition cluster is determined by the capabilities of the device/UC system that routes calls to Unified CM Session Management Edition, as described in the following sections:

Leaf Unified CM clusters that run Unified CM Release 8.5 or later releases

Leaf clusters that use SIP intercluster trunks (ICTs) with multiple destination addresses distribute calls randomly across all destinations.

Leaf clusters that use H.323 ICTs with multiple destination addresses distribute calls in a round-robin (circular) fashion across all destinations.

Leaf Unified CM clusters that run Unified CM releases earlier than Release 8.5

Leaf clusters that use H.323 non-gatekeeper intercluster trunks can use one or more trunks to originate calls from the leaf cluster. Each trunk can support up to three destination addresses.

Leaf clusters that use SIP intercluster trunks can use one or more trunks to originate calls from the leaf cluster. Each trunk can support a single destination address.

For IOS gateways that use SIP or H.323 as their trunk protocol to Unified CM Session Management Edition, you can configure multiple dial peers so that inbound calls to the Unified CM Session Management Edition cluster are evenly distributed across all call-processing servers.

For IOS gateways that use MGCP as the trunk protocol to Unified CM Session Management Edition, instead of dial peers, the Q.931/Q.SIG call signaling is backhauled to a single call-processing server in the Unified CM Session Management Edition cluster. If you use multiple MGCP gateways, ensure that you evenly distribute the backhauled call-signaling connections from each gateway across all call-processing servers in the Unified CM Session Management Edition cluster.

Outbound Call Distribution

Outbound call distribution from nodes in the Unified CM Session Management Edition cluster is determined by the outbound trunk type that is used and the route local rule. For single Unified CM Session Management Edition cluster designs, the desired design goal is that outbound calls originate from the same node that the inbound calls arrive on. In most cases Cisco recommends that Unified CM Release 8.5 or a later release is used.

For Unified CM Session Management Edition clusters that use SIP intercluster trunks (ICTs), enable the Run on All Unified CM Nodes feature on the trunk and configure one or more destination addresses. If you use multiple SIP trunks in route lists and route groups, enable the Run on All Unified CM Nodes feature on the route list. In this configuration (the route local rule operates and) outbound calls originate from the same node that the inbound call arrives on. Outbound calls are distributed randomly across all destinations. You should use the same approach to configure SIP trunk connections from Unified CM Session Management Edition to IOS gateways (or third-party UC systems).

For Unified CM Session Management Edition clusters that use H.323 ICTs, enable the Run on All Unified CM Nodes feature on the trunk and configure one or more destination addresses. If you use multiple H.323 trunks in route lists and route groups, enable the Run on All Unified CM Nodes feature on the route list. In this configuration, the route local rule operates and outbound calls originate from the same node that the inbound call arrives on. Outbound calls are distributed in a round-robin (circular) fashion across all destinations.

H.323 gateway connections from Unified CM Session Management Edition to IOS gateways or third-party UC systems do not support the Run on All Unified CM Nodes feature and only support a single destination address. If you require multiple H.323 connections to multiple gateways/third-party UC systems, ensure that the Unified CM groups of the H.323 gateways evenly use the nodes in the Unified CM Session Management Edition cluster. For multiple trunks in route lists and route groups, enable the Run on All Unified CM Nodes feature on route lists. Note that with outbound calls over H.323 gateway trunks, because these trunks do not support the Run on All Unified CM Nodes feature, the route local rule may not always apply. Therefore, the node in the Unified CM Session Management Edition cluster that the inbound call arrives on may not be the same node that is used for the outbound H.323 call. See Figure 19.

Figure 19 Route Local and Outbound Calls Over H.323 Gateway Trunks

MGCP connections from Unified CM Session Management Edition to IOS gateways do not support the Run on All Unified CM Nodes feature, and support only a single destination address. Because the call-signaling channel is backhauled to one node in the Unified CM Session Management Edition cluster, only a single node in the Unified CM group of the MGCP gateway is active at any one time (typically the primary node). If you use multiple MGCP gateways, ensure that you evenly distribute the backhauled call-signaling connections from each gateway across all call-processing servers in the Unified CM Session Management Edition cluster.

For multiple MGCP gateways in route lists and route groups, enable the Run on All Unified CM Nodes feature on route lists. Note that with outbound calls over MGCP gateways, because the gateway MGCP connection is active only on one node within the Unified CM Session Management Edition cluster feature, the route local rule may not always apply. Therefore, the node in the Unified CM Session Management Edition cluster that the inbound call arrives on may not be that same node that is used for the outbound MGCP call.

Single Unified CM Session Management Edition Cluster with Clustering-Over-the-WAN

Like Unified CM clusters, you may deploy a single Unified CM Session Management Edition cluster across multiple sites that connect by an IP WAN with QoS features enabled. In general, the rules that apply to standard Unified CM clusters, in terms of delay (maximum Round Trip Time (RTT) = 80 milliseconds), bandwidth and network QoS requirements between sites, also apply to Unified CM Session Management Edition clusters. For general clustering-over-the-WAN guidance, see Cisco Unified Communications System Release 8.x SRND at http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/8x/models.html#wp1043996. For Unified CM Session Management Edition-specific guidance on clustering-over-the-WAN deployments see the following sections.

When routing calls through a Unified CM Session Management Edition cluster that is distributed across multiple sites, a call that arrives at a Unified CM Session Management Edition node in a clustering-over-the-WAN site should, ideally, egress from this same node to its destination (that is, the route local rule should operate successfully on the inbound and outbound call), rather than be internally routed between Unified CM Session Management Edition nodes in different clustering-over-the-WAN sites. The benefits of routing calls using the route local rule are reduced internode traffic within the cluster and call distribution across the Unified CM Session Management Edition nodes being determined by the distribution of inbound calls into the Unified CM Session Management Edition cluster.

To most easily achieve this efficient method of call routing through the Unified CM Session Management Edition cluster, use Unified CM Release 8.5 or later releases with a combination of SIP trunks, SIP ICTs, H.323 non-gatekeeper-controlled ICTs, route lists, and local route groups. Local route groups allow a single clusterwide route pattern to select an outbound trunk that is local to (in the same clustering-over-the-WAN site as) the inbound trunk that the call arrives on. The SIP trunks, SIP ICTs and H.323 non-gatekeeper-controlled ICTs that support multiple destination addresses, standard Unified CM groups, or the Run on All Unified CM Nodes feature allow the route local rule to be applied to all calls.

General Design Considerations with Clustering-Over-the-WAN Designs

When considering leaf UC systems and Unified CM Session Management Edition clusters, SIP-trunk features such as OPTIONS Ping and scripting for normalization and transparency can be used as required and appropriate. SIP- and H.323-trunk features, such as Run on All Unified CM Nodes and multiple destination addresses should be used with consideration, primarily because of the mechanism that trunks use to identify and accept inbound calls. (A trunk will accept a call if the incoming source IP address matches one of the addresses defined as its destination IP address.)

Design Guidance for Leaf Cluster Trunk Connections to a Unified CM Session Management Edition Cluster Deployed with Clustering-Over-the-WAN

In each leaf cluster, create and prioritize multiple intercluster trunks in route lists to distribute calls to each group of Unified CM Session Management Edition nodes in each data center. If you use Unified CM Release 8.5 or a later release enable Run on All Unified CM Nodes on intercluster trunks and route lists and define destination IP addresses per trunk for geographic call distribution.

Figure 20 Calls from Leaf Clusters to Unified CM Session Management Edition

Design Guidance for Calls from Unified CM Session Management Edition Cluster Trunks in a Clustering-Over-the-WAN Deployment to Leaf UC Systems

In the Unified CM Session Management Edition cluster, create and prioritize multiple trunks in route lists so that calls can be onward routed from each group of Unified CM Session Management Edition nodes in each data center to the destination leaf cluster. If you use Unified CM Release 8.5 or a later release, use standard Unified CM groups for each trunk1 , define destination IP addresses and port numbers for every call-processing node in the leaf cluster, and enable Run on All Unified CM Nodes on all route lists.

For inbound trunk calls, use local route groups to route outbound calls over trunks in the same data center.

Figure 21 Calls from Unified CM Session Management Edition to Leaf Clusters

Depending on the trunk types and Unified CM releases that you use in your deployment, your trunk design may vary from the guidance described above. For example, if you use MGCP trunks in the Unified CM Session Management Edition cluster, because an MGCP trunk is active on only one Unified CM Session Management Edition node, the route local rule comes into play only occasionally and inbound calls are often routed to other nodes within the Unified CM Session Management Edition cluster before being onward routed to their destination.

Cisco generally recommends SIP trunks and SIP ICTs if you deploy Unified CM Release 8.5 or a later release in the Unified CM Session Management Edition cluster or leaf Unified CM cluster, because they offer a greater feature set (for example, OPTIONS Ping, SIP Normalization) than MGCP trunks, H.323 trunks, and H.323 gateways.

Clustering-Over-the-WAN Bandwidth Calculations for Unified CM Session Management Edition

The following discussion assumes that there are no or few (less than 150) phones registered to the Unified CM Session Management Edition cluster. If you have more than 150 phones registered to the Unified CM Session Management Edition cluster, use the guidelines on how to determine the clustering-over-the-WAN bandwidth in the Cisco Unified Communications System Release 8.x SRND at http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/8x/models.html#wp1043616.

Unified Communications System Release 8.x SRND discusses clustering-over-the-WAN support for two types of deployments: local failover, in which the backup node of a device resides within the same clustering-over-the-WAN site; and remote failover, in which the backup node of a device resides within a remote clustering-over-the-WAN site.

For trunks that use the Run on All Unified CM Nodes feature, the failure of one node does not cause the trunk process to reregister on another node (because the process exists on all nodes already). When one or more nodes in the cluster fails, the remainder of the active nodes within the cluster handle subsequent calls. For trunks that use standard Unified CM groups, you can localize the nodes in the Unified CM group of the trunk at one Unified CM Session Management Edition clustering-over-the-WAN site, or you can distribute them over two or three sites for geographical redundancy. Where you deploy trunks that use Unified CM groups, in most cases, you can achieve backup and redundancy if you configure multiple trunks in route lists and use local route groups to ensure that the primary path through the Unified CM Session Management Edition cluster uses nodes within the same Unified CM Session Management Edition clustering-over-the-WAN site.

In comparison with standard Unified CM clusters with thousands of registered phones, Unified CM Session Management Edition clusters have relatively few active devices within the cluster. A Unified CM Session Management Edition cluster can support a maximum of 2100 trunks, although in the majority of cases this number is likely to be less than 100 trunks for typical Unified CM Session Management Edition clusters, reaching 300 to 400 trunks for a small percentage of large Unified CM Session Management Edition deployments.

Follow the relevant guidelines such as WAN considerations, intracluster communications2 , replication of key services, and so forth in the clustering-over-the-WAN section of Unified Communications System Release 8.x SRND.

Use the following equation for WAN bandwidth calculations between Unified CM Session Management Edition clustering-over-the-WAN sites:

Total bandwidth required between the sites = Total intracluster communication signaling (ICCS) bandwidth + Total database bandwidth.

Intracluster Communication Signaling Bandwidth

You require a minimum of 1.544 Mb/s (T1) bandwidth for intracluster communication signaling (ICCS) for 10,000 Busy Hour Call Attempts (BHCA) between clustering-over-the-WAN sites. This call control traffic is classified as priority traffic. Priority ICCS traffic is marked with IP Precedence 3 (DSCP 24 or PHB CS3).

If you deploy the majority of your Unified CM Session Management Edition trunks so that the route local rule operates for transiting calls, calls are not routed to other cluster nodes and sites. In this case you can provision the minimum 1.544 Mb/s (T1) bandwidth for ICCS traffic between sites.

If you deploy MGCP trunks (which are active on one Unified CM Session Management Edition node), calls are likely to be routed between nodes within the cluster. Depending on the configuration of your trunks, Unified CM groups, route lists, and route groups, calls may or may not be routed between nodes in different Unified CM Session Management Edition clustering-over-the-WAN sites. If the BHCA for calls that are routed between sites under normal, or backup conditions, is greater than 10,000 use the following equation to calculate the bandwidth between sites:

Total ICCS bandwidth (Mb/s) = (BHCA between sites/10,000) * (1 + 0.006 * Delay), where Delay = Round Trip Time (RTT) delay in milliseconds


Note In all cases ICCS traffic requires a minimum bandwidth of 1.544 Mb/s.


To determine the BHCA per Unified CM Session Management Edition node, divide the total BHCA value for the Unified CM Session Management Edition cluster by the number of call-processing nodes in the Unified CM Session Management Edition cluster.


Note It is assumed that you evenly distribute calls across all call-processing nodes within the cluster.


After you calculate the per node BHCA, determine the expected BHCA between sites, and if this value is greater than 10,000 use this value in the preceding equation.

Database Bandwidth Calculations

In addition to the bandwidth required for intracluster communication signaling (ICCS) traffic, a minimum of 1.544 Mb/s (T1) bandwidth is required for database and other interserver traffic for every subscriber server remote to the publisher.

Total database bandwidth = (Number of servers remote to the publisher) * 1.544 Mb/s.

Unified CM Session Management Edition Clustering-Over-the-WAN Bandwidth Calculation

Use the following equation to calculate the bandwidth required between the sites:

Total bandwidth required between the sites = Total ICCS bandwidth + Total database bandwidth

Figure 22 Intracluster Call Routing with Route Local for SIP- and H.323-Based Trunks

With SIP and H.323 ICTs or trunks, you can design the Unified CM Session Management Edition cluster so that all calls into the Unified CM Session Management Edition cluster leave the cluster on the same node that the call arrived on (route local rule in operation). Deploying your Unified CM Session Management Edition cluster with SIP and H.323 trunks and configuring your trunks, route lists, and local route groups such that the route local rule operates, greatly reduces intracluster ICCS traffic (because calls are not routed intracluster between nodes in different sites).

Figure 23 Intracluster Call Routing to Destination UC Systems Using MGCP Trunks

With MGCP trunks, each trunk is active only on a single node within the cluster and likewise each MGCP-trunk connection from a gateway can connect only to a single Unified CM node (unlike connections from gateways over SIP or H.323 trunks, which can connect to multiple Unified CM nodes and which can also be included in Unified CM route lists and route groups). Therefore, as calls route through the Unified CM Session Management Edition cluster to MGCP gateways, calls are likely to be routed between nodes at different Unified CM Session Management Edition clustering-over-the-WAN sites, increasing ICCS traffic. If you use large numbers of MGCP gateways, account for this additional ICCS traffic when you calculate the clustering-over-the-WAN bandwidth requirements of your deployment.

Multiple Distributed Unified CM Session Management Edition Clusters

For global UC deployments with large numbers of regional leaf UC systems and endpoints, you can deploy multiple interconnected Unified CM Session Management Edition clusters to aggregate the trunks and dial plans of the leaf UC systems within each region.

Figure 24 Regionally Distributed Unified CM Session Management Edition Clusters

Signaling and Media Delays over Long Distance Connections

For calls between devices that are separated by a significant time delay and potentially many call-signaling legs (for example, consider a call from a phone in Asia Pacific to a phone in Europe in Figure 24), the one-way delay incurred on the media path between the two devices can affect the perceived call quality of the call's participants. ITU-T Recommendation G.114 recommends that you keep this media-transmission-path delay below 150 milliseconds, with an upper limit of 400 millisecond. Beyond this upper limit many users are dissatisfied with the quality of the call.

For call signaling, the delay incurred on the signaling path (which may pass through multiple call agents) between the calling and called device will not affect call quality once the call has been set up, but can affect the experience of the called and calling users at the beginning of the call.

Figure 25 shows some of the delays that can be experienced by the calling and called parties when a call is set up over a signaling path with a long delay.


Note Figure 25 is simplistic in the sense that it shows a very basic SIP Early Offer call. In a real environment, multiple call agents and protocols can be used (for example, SCCP, SIP, H323, MGCP). The protocol version or configuration may increase the number of messages that need to be exchanged at each stage (for example, H.323 Slow Start versus H.323 Fast start). Also vendors may implement their protocol stacks differently. For example, in Figure 25 two-way media is established after the receipt of the ACK; some vendors will establish two-way media after receiving the 200 OK with SDP Answer.


Figure 25 Effects of Call-Signaling Delay

The amount of time required to establish the two-way media path is ultimately a product of the number of signaling packets that must be exchanged and the delay as each of these packets traverses the network. This includes all call setup signaling-packet exchanges between each endpoint and the call-processing agent as well as any signaling packets exchanged between disparate call-processing agents should they exist (for example, in a distributed call-processing environment with multiple call-processing agents).

Unified CM Session Management Edition Clusters with Registered IP Phones

Typically, most Unified CM Session Management Edition deployments consist of trunks only. These Unified CM Session Management Edition clusters are used to aggregate many leaf UC systems and to provide large scale centralized dial plan management. Unified CM Session Management Edition clusters also support the registration of IP Phones and a Unified CM Session Management Edition cluster deployment can support several thousand phones and a large number of trunks. Unified CM Session Management Edition clusters can also be used during the migration of legacy UC systems to a Unified CM cluster as shown in Figure 26.

Figure 26 Staged Migration of Legacy UC Systems to a Single Unified CM Cluster

Q.SIG Path Replacement over Intercluster Trunks

In addition to providing features such as Call Back (on Busy/No Reply) between phones in leaf Unified CM clusters, Q.SIG also provides Path Replacement. The Path Replacement feature optimizes call signaling between clusters when, for example, a call is transferred back to its originating cluster. This signaling optimization also allows the return of unused bandwidth to the location-based call admission control bandwidth pools of the clusters.


Note Q.SIG-enabled trunks do not support geolocations and their associated logical partitioning feature.


Figure 27 Q.SIG Path Replacement Between Clusters—Initial Call

Figure 28 Q.SIG Path Replacement Between Clusters—Transferred Call

Figure 29 Q.SIG Path Replacement Between Clusters—Signaling Path Optimized

Notes on Q.SIG Deployments with Unified CM Session Management Edition

Called, calling, and diverting numbers that are sent in Q.SIG Application Protocol Data Units (APDUs) are not modified by translation and transformation patterns. For Unified CM Session Management Edition deployments that use Q.SIG-enabled trunks, numbers sent in Q.SIG APDUs (particularly dialled numbers—because the user dialing behavior may vary from cluster to cluster) can affect the delivery of Q.SIG-based features. Q.SIG features such as Call Back and Path Replacement can use the called and calling numbers for given calls to determine if and when these features can be invoked. To avoid the dependency of called and calling numbers for Q.SIG-feature invocation, use the following Q.SIG features Unified CM Service Parameter configuration values:

Clusterwide parameters (Feature—Path Replacement)

Because the Q.SIG protocol passes the extension number or directory number without applying number transformations, use Q.SIG features such as Path Replacement in a UC network with a uniform dial plan. When a UC network uses non-unique directory numbers in the dial plan (or variable user-dialing habits), you must reroute calls using a PINX ID. A PINX ID is a unique directory number for every PINX (that is, Q.SIG-capable UC system) in the UC network. The Path Replacement feature uses the PINX ID, if configured, instead of the called or calling party number to determine if path replacement should be invoked. To configure the PINX ID, perform the following tasks in Cisco Unified Communications Manager Administration:

Configure the PINX ID service parameters for the Path Replacement feature. (The Path Replacement feature uses the Cisco CallManager service.)

Create a call pickup group that includes only the PINX ID.

Unified CM provides the Path Replacement Calling Search Space service parameter, to configure the calling search space that the cooperating PINX uses to send the outbound SETUP message to the requesting PINX. If you do not specify a value for the Path Replacement Calling Search Space service parameter, the requesting PINX uses the calling search space of the end user that is involved in the call.

For more information about the Path Replacement feature over Q.SIG trunks, see

http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/admin/8_6_1/ccmsys/a08procl.html#wpmkr1174602.

Clusterwide parameters (Feature—Call Back)

The following Call Back (also know as Call Completion) services provide Cisco Call Back functionality over Q.SIG-enabled trunks:

Completion of Calls to Busy Subscribers (CCBS)—When a calling party receives a busy tone, the caller can request that the call complete when the user at the busy destination hangs up the phone and becomes available.

Completion of Calls on No Reply (CCNR)—When a calling party receives no answer at the destination, the calling party can request that the call complete after the activity occurs on the phone of the called party.

For Unified CM Session Management Edition deployments use the default Call Back Clusterwide Service Parameter settings for Connection Proposal Type (the default parameter is Connection Retention) and Connection Response Type (the default parameter is Default to Connection Retention). These default values allow the Q.SIG Call Back feature to be invoked without using the called and calling party numbers for a given call attempt.

For more information about the Q.SIG Call Back feature, see http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/admin/8_6_1/ccmsys/a08procl.html#wp1164947.

Figure 30 Clusterwide Q.SIG—Path Replacement and Call Back Features

Call diversion

Unified CM supports call diversion by rerouting and call diversion by forward switching. When call diversion by rerouting occurs, the originating PINX receives a request from the receiver of the call to divert the call to another user. The default Clusterwide Parameters (Feature—Forward) setting is to use Call Forward by Forward Switching (Forward By Reroute is disabled). As a general recommendation for Unified CM Session Management Edition deployments and if you do not use a uniform dial plan for your UC network, use call diversion by forward switching and path replacement to optimize the path between the originating and terminating users.

For more information about Q.SIG Call Diversion, see http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/admin/8_6_1/ccmsys/a08procl.html#wp1156053.

+ Character handling over Q.SIG trunks

Q.SIG trunks do not transport the + character in Q.SIG APDUs. The lack of support for + character transport does not affect the behavior of the Call Completion, Path Replacement and Call Diversion by Forward Switching Q.SIG features. The lack of support for + character transport in Q.SIG APDUs can affect calls diverted to a centralized voicemail system. Typically, to address this + character issue, define a primary number and an alternate number for the user voice mailbox in the voicemail system. These Q.SIG-related voicemail issues are discussed in detail in Voicemail Applications on Unified CM Session Management Edition.

Unified CM Session Management Edition SAF CCD Deployments

Unified CM Session Management Edition deployments provide internal dial-plan aggregation. Cisco Service Advertisement Framework (SAF) Call Control Discovery (CCD) deployments distribute both the internal dial plan and the corresponding external to-PSTN dial plan to participating SAF CCD UC systems.

You can combine Unified CM Session Management Edition and SAF in a number of ways to provide operational and dial plan management benefits to your UC deployment. The following two SAF and Unified CM Session Management Edition deployment models are discussed in the following sections:

Centralized Unified CM Session Management Edition call routing

With centralized Unified CM Session Management Edition call routing, all calls between leaf clusters over the IP WAN traverse the Unified CM Session Management Edition cluster and, on failure of the IP WAN path, calls are routed to a local PSTN gateway. With this deployment model, you can centrally manage the system dial plan on the Unified CM Session Management Edition cluster and distribute to-PSTN dial plan information to all clusters.

Distributed call routing

With distributed call routing, the leaf clusters use SAF to route calls directly between each other over the IP WAN and calls are not routed through Unified CM Session Management Edition. The Unified CM Session Management Edition cluster uses SAF to learn dial-plan information from the leaf clusters and can also advertise PSTN routes and directory number patterns on behalf of third-party UC systems.

Unified CM Session Management Edition and SAF with Centralized Call Routing

Combining Unified CM Session Management Edition and SAF CCD enables Unified CM Session Management Edition to act as the central session manager for all leaf UC systems, while also using SAF CCD to distribute both the internal and external to-PSTN dial plans to all SAF CCD participating leaf Unified CM clusters.

A Unified CM Session Management Edition and SAF hybrid deployment uses a specific configuration of SAF CCD to allow all calls between leaf clusters to be routed only through the Unified CM Session Management Edition cluster. The SAF configuration consists of two parts:

Advertising SAF CCD routes to leaf clusters from/through Unified CM Session Management Edition

Advertising SAF CCD routes from leaf clusters to Unified CM Session Management Edition


Note This discussion assumes that you have already configured your Cisco IOS SAF forwarders and basic SAF CCD configuration on Unified CM (that is, Advertising Service, Requesting Service, SAF-enabled trunks, and so forth). This design uses a single SAF autonomous system (AS).


Advertising SAF CCD Routes to Leaf Clusters From/Through Unified CM Session Management Edition

On the Unified CM Session Management Edition cluster, create the directory number (DN) patterns, DN groups, and corresponding to-DID rules for the internal number ranges and external to-PSTN numbers hosted by each SAF-enabled leaf cluster. Publish these DN patterns to the SAF AS by associating them with one or more SAF-enabled trunks and advertising services. These DN patterns and corresponding routes to Unified CM Session Management Edition are learned by all SAF-enabled leaf clusters. When Unified CM Session Management Edition is reachable through the IP WAN, all intercluster calls are routed through Unified CM Session Management Edition. When Unified CM Session Management Edition is unreachable, intercluster calls are routed through the local PSTN gateway of the leaf cluster after the called number has been modified using the to-DID rule of the learned DN pattern.

Advertising SAF CCD Routes from Leaf Clusters to Unified CM Session Management Edition

The purpose of advertising the hosted DN ranges of each leaf cluster to the SAF AS is to allow the Unified CM Session Management Edition cluster to learn about these DN ranges and leaf cluster reachability. These number ranges are also learned by all other leaf clusters. (See Figure 31.) To prevent direct leaf-to-leaf routes from being used, in each leaf cluster, block learned routes from all other leaf clusters. Routes can be blocked based on whether they match either the IP address of the SAF nodes in each of the leaf clusters, or (preferably) the Remote Call Control Entity Name for each leaf cluster. (This is the Unified CM cluster ID in the Unified CM Enterprise parameters menu.)

Figure 31 Advertising SAF CCD Routes in a Unified CM Session Management Edition Deployment

Operational Considerations for Unified CM Session Management Edition and SAF CCD Deployments with Centralized Call Routing

The following operational considerations apply to deployments of Unified CM Session Management Edition with SAF CCD.

Leaf Clusters Learning Their Own DN Ranges from Unified CM Session Management Edition

As can be seen in the SAF CCD routing tables in Figure 31, leaf clusters learn about the reachability of their own DN ranges from Unified CM Session Management Edition. These DN ranges can be blocked in the same way that intercluster DN ranges and routes are blocked. If these Unified CM Session Management Edition SAF CCD routes are not blocked, they are selected only for intracluster calls if the calling search space of the calling device has the SAF CCD learned-routes partition ordered above the internal DN partition. In most cases, the internal DN partition is ordered above the SAF CCD partition, so that intracluster calls are not routed through Unified CM Session Management Edition.

Routing Calls to the PSTN When IP Routes from Unified CM Session Management Edition to Leaf Clusters Are Not Available

Two configuration options are available when rerouting calls to the PSTN:

Reroute calls to the PSTN through a PSTN gateway associated with Unified CM Session Management Edition

If the Unified CM Session Management Edition cluster has PSTN access and you wish to reroute calls that are unreachable through an IP path from Unified CM Session Management Edition to the destination leaf cluster, ensure each leaf cluster advertises a to-DID rule for each advertised DN range or group to Unified CM Session Management Edition. Unified CM Session Management Edition uses this to-DID rule to modify the called number and to route the call through the Automated Alternate Routing (AAR) Calling Search Space (CSS) of the inbound trunk.

Reroute calls to the PSTN from the originating leaf cluster

If the Unified CM Session Management Edition cluster does not have PSTN access and you wish to reroute calls that are unreachable from Unified CM Session Management Edition to the destination leaf cluster through the PSTN at the originating leaf cluster, ensure each leaf cluster does not advertise a to-DID rule for each advertised DN range or group to Unified CM Session Management Edition. In this case, if a signaling path cannot be established from Unified CM Session Management Edition to the destination leaf cluster, Unified CM Session Management Edition signals the call failure to the originating leaf cluster. The originating leaf cluster in turn uses its to-DID rule (learned from Unified CM Session Management Edition) to modify the called number and route the call through the Automated Alternate Routing (AAR) Calling Search Space (CSS) of the calling device.

Calls to Non-SAF UC Systems Over Static Unified CM Session Management Edition Trunks

Unified CM Session Management Edition can use SAF CCD to advertise the DN ranges of non-SAF UC systems to all SAF-enabled leaf clusters. Calls from leaf clusters to non-SAF UC systems through the Unified CM Session Management Edition cluster use SAF trunks to reach Unified CM Session Management Edition. Unified CM Session Management Edition uses a configured route pattern and corresponding static (standard) trunk to reach the non-SAF UC system.

PSTN Fallback for Calls to Non-SAF UC Systems

There are two options for PSTN fallback if a non-SAF UC system is not reachable through a static trunk from Unified CM Session Management Edition:

Reroute calls to the PSTN from the originating leaf cluster

With this option, a single trunk is configured from Unified CM Session Management Edition to the destination UC system. If a signaling path cannot be established from Unified CM Session Management Edition to the destination UC system, Unified CM Session Management Edition signals the call failure to the originating leaf cluster. The originating leaf cluster in turn uses its to-DID rule (learned from Unified CM Session Management Edition) to modify the called number and route the call through the Automated Alternate Routing (AAR) Calling Search Space (CSS) of the calling device.

Reroute calls to the PSTN from Unified CM Session Management Edition

With this option, create two trunks as part of a route list and route group. Configure the first-choice trunk from Unified CM Session Management Edition to the destination UC system. Configure the second-choice trunk from Unified CM Session Management Edition to its local PSTN gateway. If a signaling path cannot be established from Unified CM Session Management Edition to the destination UC system, Unified CM Session Management Edition chooses the second-choice trunk to the PSTN. The route group that contains the PSTN trunk can be used to modify the internal called number to its PSTN equivalent.

Unified CM Session Management Edition and SAF with Distributed Call Routing

In this deployment model, the leaf clusters use SAF to route calls directly between each other over the IP WAN and calls are not routed through Unified CM Session Management Edition. The Unified CM Session Management Edition cluster uses SAF to learn dial-plan information from the leaf clusters and can also advertise PSTN routes and directory-number patterns on behalf of third-party UC systems. This deployment model is simpler than the centralized call routing model because it does not require the blocking of SAF routes between leaf systems.

Figure 32 Unified CM Session Management Edition and SAF with Distributed Call Processing

Dial Plan Recommendations for Unified CM Session Management Edition Deployments

Unified CM Session Management Edition cluster dial-plan designs vary from UC network to UC network based on a variety of factors: for example, the dial-plan and digit-manipulation capabilities of the leaf UC system, user dialing habits, and number-globalization/normalization requirements. While it is not possible to discuss all dial-plan variations, the following sections focus on dial-plan designs with globally unique numbers (+E.164, E.164, or 8XXXYYY numbers, or a mixture of these number formats). Called and calling number normalization can take place within the leaf UC system or Unified CM Session Management Edition cluster, although there may be cases where the leaf UC system does not support sophisticated digit-manipulation mechanisms and all called and calling number normalization takes place in the Unified CM Session Management Edition cluster. Some of these Unified CM Session Management Edition and UC system dial-plan designs are discussed in the following sections. However, for general dial-plan recommendations, see the Dial Plan chapter of the Cisco Unified Communications System Release 8.x SRND at http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/8x/dialplan.html.

As noted earlier, Unified CM Session Management Edition has exactly the same software code base as Unified CM. Hence the tools to implement an enterprise-wide dial plan are also the same. Call routing is implemented based on calling search spaces (CSSs), partitions, and patterns that are assigned to these partitions. In contrast to a call sourced from a regular phone where the effective CSS is the concatenation of line and device CSSs, for a call from a trunk the CSS defining the class of service for the incoming call is the CSS defined in the inbound calls section of the gateway or trunk.

Global Numbering Plan

The centralized dial plan that is managed by Unified CM Session Management Edition must be based on a numbering plan that uses globally unique numbers. The call routing in Unified CM Session Management Edition will be defined based on this globally unique numbering plan. The leaf systems that are attached to Unified CM Session Management Edition might use different numbering schemes; especially if Unified CM Session Management Edition is added to an existing deployment to centralize call routing for several already existing call controls.

Figure 33 shows a UC network with +E.164 numbering used for directory numbers, dialing habits, and Unified CM Session Management Edition dial plan. While this numbering plan and dial plan greatly reduce number-normalization requirements within a UC network, users within your UC network may already be using specific dialing habits (for example, 8XXXYYYY) or have non-E.164 directory numbers that may require you to adapt your numbering plan and dial plan to meet your users' requirements. Several other diagrams showing possible dial plan designs are shown throughout this section. (See Figure 34, Figure 35, and Figure 36.)

Figure 33 + E.164 Numbering and Dialing

Digit-Manipulation Methods in Unified CM and Unified CM Session Management Edition Leaf Clusters

Where leaf systems use numbering plans that differ from the globalized-numbering plan in the Unified CM Session Management Edition cluster, you have to implement a mapping from the numbering plans in the leaf systems to the global-numbering plan used for call routing in Unified CM Session Management Edition.

With Unified CM and Unified CM Session Management Edition, to achieve normalization of calling and called party information you can use the following mechanisms:

Transformation CSSs on the trunk or the device-pool level

Transformations on route patterns

Transformations on translation patterns

Transformations on route lists

Any of these mechanisms can be used to normalize called and calling numbers as they traverse Unified CM and Unified CM Session Management Edition clusters. The following discussion concentrates on using transformation CSSs and translation patterns at the trunk level to achieve inbound and outbound called and calling number normalization. If desired, any of the mechanisms in the preceding list can be used where appropriate.

Number Normalization for Calls from Leaf Systems to Unified CM Session Management Edition

Calling party normalization

If possible, normalize calling party information in the leaf systems. Calling party information sent from leaf systems to Unified CM Session Management Edition during call establishment must be transformed from the local format of the leaf system to the universal global format so that Unified CM Session Management Edition can use it for call routing.

Called party normalization

Called party information for calls from leaf systems to Unified CM Session Management Edition also should be normalized in the leaf system as much as possible. If the overall E.164-based dial plan also supports some form of abbreviated on-net dialing (for example, based on access code, site code, and DN) the normalization of this abbreviated on-net dialing habit cannot take place in the leaf system, because only Unified CM Session Management Edition will have the global mapping of all site codes to their respective equivalent E.164 numbers.

To perform this normalization on the outbound leaf Unified CM trunk use:

Outbound called party transformation CSSs

Outbound calling party transformation CSSs

Calling number transformations at the device/directory-number level

If normalization at the leaf level is not possible, Unified CM Session Management Edition can implement leaf-system-specific normalization of calling and called number information on the ingress trunk or gateway using:

Incoming calling party transformation CSSs, and

Incoming called party transformation CSSs (H.323 only), or

Translation patterns associated with the inbound CSS of the trunk


Note The inbound called party transformation CSS is not available on SIP trunks and MGCP gateways. For inbound called-number normalization on SIP trunks and MGCP gateways, use translation patterns associated with the inbound CSS of the trunk.


Number Normalization for Calls from Unified CM Session Management Edition to Leaf Systems

Called and calling party normalization

If the leaf system dial plan does not support the global-numbering plan that is defined for core routing on Unified CM Session Management Edition, calling and called party information that is sent to the leaf system must be normalized to a numbering format that is supported on the leaf system.

This normalization can be performed on the outbound Unified CM Session Management Edition trunk using:

Outbound called party transformation CSSs

Outbound calling party transformation CSSs

Or, this normalization can be performed on the inbound leaf-cluster trunk using:

Incoming calling party transformation CSSs, and

Incoming called party transformation CSSs (H.323 only), or

Translation patterns that are associated with the inbound CSS of the trunk


Note The inbound called party transformation CSS is not available on SIP trunks and MGCP gateways. For inbound called number normalization on SIP trunks and MGCP gateways, use translation patterns that are associated with the inbound CSS of the trunk.


Figure 34 UC Design Showing Number Normalization in Leaf Unified CM and Unified CM Session Management Edition Clusters

Figure 35 UC Design Showing Number Normalization in the Unified CM Session Management Edition Cluster Only

General Numbering-Plan Recommendations

Because multiple transformations of calling and called party information add to the overall complexity of the system, Cisco recommends that you define a single global numbering-plan based on E.164 numbers and create the dial plan in Unified CM Session Management Edition and also in the leaf systems based on +E.164 numbers. This eliminates the need for multiple calling and called party number transformations for interleaf calls through Unified CM Session Management Edition. In some situations number transformations may be unavoidable because the leaf system dial plan and user-dialing habits may differ from the number formats that are used in the Unified CM Session Management Edition dial plan.

Figure 36 +E.164 Numbering and E.164 Dialing

Unified CM Session Management Edition/Unified CM Trunk Protocols and + Character Transport

Cisco recommends the +E.164 format for called and calling numbers as they traverse a Unified CM Session Management Edition cluster. The ability of a Unified CM Session Management Edition trunk to carry the + character in called and calling numbers is protocol specific. For protocols that do not support the + character there are several simple workarounds to reinsert the + character after a number is received.

The following summarizes + character support by protocol type:

SIP trunks support the + character.

H.323 trunks do not support the + character (the + character is not supported in the H.323 specification).

MGCP Q.931 trunks do not support the + character (the + character is not supported in the Q.931 specification).

SIP trunks and the + character

The SIP protocol supports +E.164 numbers as calling and called party numbers; you can send +E.164 calling and called party numbers across SIP trunks without technology-specific adaptation.

The + character is also sent as part of the tunneled information element of calling and called party information sent in Q.SIG over SIP trunks.

Figure 37 Digit Manipulation on SIP Trunks

H.323 trunks and the + character

H.323 cannot transport +E.164 numbers; the + character is stripped when sent over an H.323 trunk. But, H.323 does support the concept of numbering plan and type per number. Based on this, you have two options to define number transport over H.323 trunks:

Send all numbers as +E.164 using a common numbering type, for example ISDN International. The + character is removed when sent and can be prefixed at the receiving side by configuring "+" as the prefix for chosen number type in the incoming called/calling party settings on the H.323 trunk, in the device pool, or in the service parameters. This approach works only if all numbers to be sent over the trunk are normalized to +E.164. If other number types also must be used over the trunk, use the following approach.

Using appropriate calling and called party transformation CSSs on the sending side ensures that the calling and called party information that is sent on the trunk has the correct numbering plan and type settings applied. Typically, you would send all full E.164s as plan ISDN and type international and all other numbers as plan unknown and type unknown. On the receiving side you only need to configure the + character as the prefix for international numbers in the incoming called/calling party settings on the trunk, in the device pool, or in the service parameters. For numbering type unknown, the incoming called and calling party transformation CSSs on the trunk or device pool level can be used to apply appropriate number transformations.

The + character is not sent as part of the tunneled information element of calling and called party information that is sent in Q.SIG over H.323 trunks.

Figure 38 Digit Manipulation on H.323 Trunks and Gateways

MGCP Q.931 trunks and the + character

MGCP cannot transport +E.164 numbers; the + character is stripped when sent over an MGCP trunk. Like H.323 trunks, MGCP trunks do support the concept of numbering plan and type mapping and transformation CSSs for inbound and outbound calling numbers.

Outbound called numbers also support numbering plan and type mapping and transformation CSSs. However, inbound called numbers do not support numbering plan and type mapping and transformation CSSs. For + character prefixing of inbound called numbers use the prefix-DN feature on MGCP trunks or translation patterns that are associated with the inbound CSS of the MGCP trunk.

The + character is not sent as part of the tunneled information element of calling and called party information sent in Q.SIG over MGCP trunks.

Figure 39 Digit Manipulation on MGCP Gateways

Forwarded Calls and Diversion Information

Number format considerations and normalization are generally required for called and calling numbers as they are routed within a UC system. Diversion information also needs to be considered in this context and is discussed in the following section.

Typically, UC systems send diversion information in two situations:

When a call is forwarded to another number using Call Forward All. For example, to the mobile phone number of the called party or another extension.

When a call is forwarded to a voicemail system, typically on Call Forward No Answer, or Call Forward On Busy.

To send and receive diversion information for forwarded calls over trunks and gateways:

Enable inbound and outbound Redirecting Number IE Delivery on MGCP gateways, H.323 gateways, and H.323 trunks.

Enable inbound and outbound Redirecting Diversion Header Delivery on SIP trunks.

Special Considerations for Normalization of Diversion Information

H.323 trunks and gateways

Diversion information that is sent in H.323 redirecting-number information elements (IEs) only picks up calling party transformations that are defined by the voice-mailbox mask of the voicemail profile that is assigned to the redirecting DN. Calling party transformations that are defined in route patterns, in route lists, or through outbound calling party transformation CSSs are not applied to the diversion information.

Diversion information that is in H.323 redirecting-number IEs will carry a + character if the voice-mailbox mask is defined as a +E.164 mask. Keep in mind that H.323 calling and called party IEs do not carry the + character.

SIP trunks

Diversion information that is sent in a SIP diversion header only picks up calling party transformations that are defined by the voice-mailbox mask of the voicemail profile that is assigned to the redirecting DN. Calling party transformations that are defined in route patterns, in route lists, or through outbound calling party transformation CSSs are not applied to the diversion information.

Diversion information that is in the SIP diversion header will carry a + character if the voice-mailbox mask is defined as a +E.164 mask. SIP trunks can also carry the + character calling and called party numbers.

MGCP trunks

Diversion information that is sent in MGCP redirecting-number IEs only picks up calling party transformations that are defined by the voice-mailbox mask of the voicemail profile that is assigned to the redirecting DN. Calling party transformations that are defined in route patterns, in route lists, or through outbound calling party transformation CSSs are not applied to the diversion information.

Diversion information that is in MGCP trunk redirecting number IEs will carry a + character if the voice mailbox-mask is defined as a +E.164 mask. Keep in mind that MGCP trunk calling and called party IEs do not carry the + character.

Q.SIG-enabled trunks

Diversion information that is sent in Q.SIG APDUs over Q.SIG-enabled trunks (MGCP, H.323, or SIP trunks) does not pick up any calling party modifications and also does not honor the voice mailbox-mask setting. Q.SIG diversion information that is sent by Unified CM is always sent to the redirecting DN without applying any transformations.

If you configure the redirecting DN as +E.164 the leading + character is removed and the Q.SIG diversion information carries only the E.164 number without the + character.

Consideration for all Q.SIG trunk types

On H.323, MGCP, and SIP trunks with Q.SIG tunneling enabled, all number information including calling, called, and redirecting-number information is always taken from the encapsulated Q.SIG message and not from the outer H.323 message or SIP headers. This Q.SIG-trunk operation can require specialized design considerations for a voicemail system centralized on Unified CM Session Management Edition and serving multiple leaf systems. This is discussed in Diversion Information and Centralized Voicemail—Summary Recommendations.

Diversion Information and Centralized Voicemail—Summary Recommendations

As a general recommendation, implement a uniform globally unique dial plan across all UC systems to enable a smooth end-to-end Q.SIG implementation.

Even when you implement a globally unique dial plan across all UC systems the numbering format may not be uniform across all leaf UC systems. An example of this is an implementation in which some leaf UC systems use E.164 numbering and other leaf UC systems use 8XXXYYYY numbering.

If you use Q.SIG on all trunks between leaf systems and the Unified CM Session Management Edition cluster, these redirecting E.164- and 8XXXYYY-based numbers cannot be normalized before they are sent to the centralized voicemail system. This limitation requires that the centralized voice-mailbox number for users in each leaf UC system should correspond to the number format of the directory numbers used in each leaf system.

For example:

Users with directory numbers of the format 8XXXYYYY—should have a corresponding voice-mailbox number that uses the same 8XXXYYYY format.

Users with directory numbers of the format E.164—should have a corresponding voice-mailbox number that uses the same E.164 format.

Users with directory numbers of the format +E.164—should have a corresponding voice-mailbox number that uses the same +E.164 format.

Note—Some voicemail systems, such as Cisco Unity, allow multiple numbers to be associated with a voice mailbox of a user. For example:

Primary VM box number: E.164

Alternate VM box number: +E.164

Primary VM box number: 8XXXYYYY

Alternate VM box number: +E.164.

Centralized Tail-End Hop-Off with Decentralized PSTN Access

You can use Unified CM Session Management Edition to implement a centralized Tail-End Hop-Off (TEHO) policy. Fundamentally, this means that the leaf systems must send all calls to Unified CM Session Management Edition that are not addressed to destinations local to the respective leaf system. This might even include national calls to the PSTN in which the leaf has gateways.

The dial plan on Unified CM Session Management Edition needs to be extended so that it does not hold only the prefixes that are known as local to leaves, but also holds the PSTN destinations that should egress at certain leaf systems. Finally, you must ensure that calls coming into the leaf clusters on the trunks from Unified CM Session Management Edition can egress to the PSTN. To achieve this the route patterns pointing to the local PSTN egress points (trunks or gateways) must be addressable by the incoming calls calling search space on the trunk from Unified CM Session Management Edition to the leaf cluster.

If different TEHO policies are required per leaf system, or even per site, the TEHO piece of the Unified CM Session Management Edition dial plan must be made leaf-system specific by either using the appropriate incoming calling search space on the trunk from that leaf, or the above mentioned TEHO piece of the dial plan has to combined with the ability of Unified CM Session Management Edition to route based on calling party information as described in the Cisco Communications Manager Features and Services Guide. For more information, see the Configuring Call Screening With Calling Party Number Routing section in the Hotline chapter of the Cisco Communications Manager Features and Services Guide at http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/admin/8_6_1/ccmfeat/fshotline.html#wp1422478.

Figure 40 Source-Specific TEHO Policy

You can implement two different approaches to ensure that calls to destinations that are not explicitly defined in the TEHO dial plan go back to the source cluster:

trunk-specific hairpinning

hair-pinning that uses Local Route Groups (LRGs)

Trunk-specific hairpinning

To implement trunk-specific hairpinning you require trunk-specific incoming CSSs and also a trunk-specific partition that holds an appropriate catchall route pattern (for example,"!") that directly points back to the specific trunk. This approach requires one CSS, one partition, and one route pattern per inbound trunk on Unified CM Session Management Edition.

Hairpinning that uses Local Route Groups (LRGs)

To simplify hairpinning you can:

Create a dedicated device pool per leaf trunk and put the trunks into their respective device pool.

Create a route group per trunk and set the trunk-specific route group as the LRG on the trunk-specific device pool.

Create a single catchall route pattern (for example, "!") that points to the LRG.

This approach ensures that every time the catchall route pattern is selected the call is routed to the LRG of the source trunk that points back to the same trunk. From the dial plan perspective this approach requires less configuration elements than the trunk-specific hairpinning configuration.

When you implement a centralized TEHO policy with decentralized PSTN-access because of the possibility that Unified CM Session Management Edition will route calls back to the leaf clusters, it is essential that you implement loop avoidance in the leaf clusters. To avoid routing loops, you have to ensure that the incoming calling search space on the trunk from Unified CM Session Management Edition on the leaf cluster can only address destinations local to the leaf cluster and the PSTN route patterns.

Call Admission Control Recommendations for Unified CM Session Management Edition Deployments

Unified CM Session Management Edition has two main forms of call admission control (CAC) available to it to admit trunk-to-trunk audio and video calling. One is locations CAC and the other is Resource Reservation Protocol (RSVP). This section covers design guidelines and best practices specific to Unified CM Session Management Edition deployments. It does not cover the basic functions of locations CAC, locations-based RSVP or RSVP SIP Preconditions. Cisco highly recommends familiarity with the Call Admission Control chapter of the Cisco Unified Communications System Release 8.x SRND at http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/8x/cac.html as a prerequisite to the following design guidelines.

The term "CAC domain" is used in this section to describe an area of the network that is managed by a single CAC mechanism such as locations CAC or RSVP. In cases involving locations CAC, the term CAC domain would also imply that locations CAC is managed by a single cluster, be it a leaf cluster or a Unified CM Session Management Edition cluster because locations CAC is only single cluster aware, meaning locations information is not communicated between clusters. There is a mechanism referred to as Location-Based Call Admission Control over Intercluster Trunk that allows clusters to communicate location information from cluster to cluster, but this is limited in scope and will be referred to specifically where it applies.

Unified CM Session Management Edition Management of the CAC Domain with Locations CAC

Unified CM Session Management Edition can leverage locations CAC to manage bandwidth on behalf of leaf clusters, third-party IP PBXs, and TDM gateways in a limited fashion. Locations CAC is a basic static CAC mechanism that tracks bandwidth for audio and video calls made between devices in different locations within a cluster. A location is equivalent to a physical site with a single WAN uplink. Locations CAC is not communicated across clusters, so it is only applicable within a given cluster. As such, there are a number of limitations to supporting a multi-cluster distributed Unified CM deployment with locations CAC. Unified CM Session Management Edition can, however, leverage locations CAC by associating a location to a trunk or set of trunks whose media originate from or terminate to leaf cluster devices that are located in a campus.

Figure 41 shows an example of Unified CM Session Management Edition management of the CAC domain for two campus sites. Two leaf clusters, collocated in the campus site on the left, manage endpoints and devices in that same physical campus. Another leaf cluster resides in another campus deployment. Any intersite and intercluster calling is sent to Unified CM Session Management Edition for handling. In this case the Unified CM Session Management Edition cluster has two locations configured: LOCATION 1, which is associated to the trunks for both Leaf Cluster 1 and 2, and LOCATION 2, which is associated to the trunk for Leaf Cluster 3.

In this design Unified CM Session Management Edition manages CAC for the campus sites WAN-edge uplinks by associating a location to the trunks that point to the leaf clusters in the respective campuses.

Figure 41 Unified CM Session Management Edition Managing CAC for Two Campus Sites

Any calls from Leaf 1 to Leaf 2 are not call admission controlled because both Leaf 1 and Leaf 2 trunks are in the same location in the Unified CM Session Management Edition configuration. Calls between Leaf 3 and Leaf 1 or 2 are deducted from the respective locations audio or video pools.

Leaf Clusters that Manage the CAC Domain with Locations CAC

In Unified CM Session Management Edition designs, leaf clusters can also maintain and manage their own CAC domain with locations CAC. In this case, Unified CM Session Management Edition is transparent to the admission control management of the leaf clusters. Follow these important guidelines to ensure that locations CAC functions correctly in each cluster:

Cisco recommends that not more than one cluster protect the bandwidth of a single WAN edge. This can occur in designs in which there are endpoints that are registered to different clusters, but reside in the same physical site and use the same WAN-edge uplink for intersite calling. If you use locations CAC in these cases, the bandwidth that is managed by each cluster is not communicated between clusters. The only way to effectively manage this scenario is to partition the WAN-edge bandwidth between clusters and each cluster manages its own portion of the WAN-edge bandwidth. This, however, can lead to bandwidth deductions for intercluster calls when the media do not traverse the WAN edge and remain on the LAN of the site. While this will not oversubscribe the WAN edge, it is an inefficient use of WAN-edge bandwidth and so Cisco does not recommend it.

For intercluster calls it is important that you avoid double bandwidth counting in cases of call forwarding or transfer. This is the case if a call is transferred or forwarded back to the origination leaf cluster and the origination location. In such call scenarios the signaling is hairpinned on the transferring/forwarding leaf cluster. Figure 42 and Figure 43 depict this scenario.

In Figure 42, a call is established between a device in Location B (Branch 1, Cluster 1) and Location F (Branch 2, Cluster 2). Cluster 1 has deducted 80k of bandwidth from Location B and Cluster 2 has deducted 80k of bandwidth from Location F (a G.711 audio call between clusters). Note that the intercluster trunks (ICT) to Unified CM Session Management Edition and from Unified CM Session Management Edition to the leaf clusters are located in the Hub_none Location where locations bandwidth is set to Unlimited (default—nonconfigurable). Unlike the signaling, the media connection is direct between the two branches and thus it is only important to protect each branch WAN edge with locations CAC.

Figure 42 Locations CAC Design

In Figure 43, the endpoint in Location F transfers the call to another endpoint in Location B (Branch 1, Cluster 1). At this point Cluster 2 removes the bandwidth deduction from Location F because that endpoint is no longer in the call-signaling process. However, the new call from Cluster 2 to Cluster 1 is hairpinned across the Cluster 2 trunk to Unified CM Session Management Edition and is treated as a new call by both Unified CM Session Management Edition and subsequently Cluster 1. So, in this case Cluster 1 deducts another 80k of bandwidth for the new call to the endpoint in Location B for a total of 160k of bandwidth deductions from Location B for a call between two devices in Location B. This inefficient call signaling path creates the situation in which Cluster 1 reserves CAC bandwidth for two separate calls established between an endpoint in Location B and the ICT to Unified CM Session Management Edition. In fact the media is not traversing the WAN edge because the two endpoints in Location B have their media established to one another. It just so happens that this is due to the call signaling being hairpinned on Cluster 2.

Figure 43 Locations CAC Design

There are two ways to work around this double bandwidth counting scenario when locations CAC is managed on the leaf clusters:

Location-Based Call Admission Control over Intercluster Trunk (also known as Phantom Location)

Q.SIG Path Replacement

Location-Based Call Admission Control over Intercluster Trunk

Previously, when a call was made across clusters through an ICT and is hairpinned back to the same location or site of the same cluster, although the media were exchanged between two endpoints in the same site or location, Unified CM locations CAC deducted location bandwidth twice, once for the outbound call and again for the inbound call. The result did not correctly reflect the bandwidth consumption, which eventually caused denial of a new call to or from the site or location when ample bandwidth still existed.

To resolve the bandwidth-calculation problem, the Location-Based Call Admission Control over Intercluster Trunk feature enables Unified CM to pass location information (the Primary Key ID [PKID] of the location record and location name) as a proprietary information element (IE) between the calling and called parties through an ICT, in either the H.323 or SIP protocol. Thus, each cluster is informed about the true location information of the party/endpoint, not the location information of the ICT (see Figure 44 and Figure 45 for examples).

A Unified CM location that is designated as the phantom location is created for the ICT for this type of application. The locations server does not deduct bandwidth for a device that is assigned to the phantom location. A device, such as the ICT, that is assigned to the phantom location uses the true location of the connected device across the cluster.

Figure 44 depicts the scenario for a call that is established between a device in Location B (Branch 1, Cluster 1) and Location F (Branch 2, Cluster 2). Cluster 1 has deducted 80k of bandwidth from Location B and Cluster 2 has deducted 80k of bandwidth from Location F (a G.711 audio call between clusters). When the call signaling is sent from Cluster 1 to Unified CM Session Management Edition, Location B information will be sent in an IE (Figure 44, Step 1) and this same information is then sent again from Unified CM Session Management Edition to Cluster 2 (Figure 44, Step 2). Information about the device in Location F is also sent from Cluster 2 to Cluster 1 through Unified CM Session Management Edition in the same manner. Even though only Location B information is illustrated for this example, this location-information exchange happens in both directions.

Note that the ICT to Unified CM Session Management Edition and from Unified CM Session Management Edition to leaf clusters are in the phantom location, where locations bandwidth is set to Unlimited (effectively not tracked for CAC) and where location information about the calling party in Location B is sent across the ICT.

At this point Cluster 2 knows that the call it received from Unified CM Session Management Edition is associated to Location B. Cluster 2 only uses this information to associate that specific call on its ICT to that location identifier and does not handle any bandwidth deductions itself for Location B.

Figure 44 Locations CAC Design

Figure 45 Locations CAC Design

In Figure 45, after the transfer Cluster 2 hairpins the call over the ICT and sends Cluster 1 (through Unified CM Session Management Edition; Steps 3 and 4) the Location B information that it originally received from Cluster 1 (through Unified CM Session Management Edition; Steps 1 and 2). This way Cluster 1 is informed that the incoming call it received from Cluster 2 was for a device originating in Location B in Cluster 1. This allows Cluster 1 to return the bandwidth that it deducted for the two calls that it has for the two endpoints in the same location.

For more information see the Location-Based Call Admission Control Over Intercluster Trunk section of the Call Admission Control chapter of the Cisco Unified Communications Manager System Guide at http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/admin/8_5_1/ccmsys/a02cac.html#wp1113777.

Q.SIG Path Replacement

The Q.SIG Path Replacement feature optimizes the call signaling path between leaf clusters where Q.SIG ICTs have been configured. When the call signaling path is optimized locations bandwidth is returned to the locations where the call signaling is released. For more information about how the Q.SIG Path Replacement feature functions, see the Q.SIG Path Replacement over Intercluster Trunks section.

Unified CM Session Management Edition with RSVP Deployments

Unified CM Session Management Edition can be deployed in a number of RSVP deployments, either with SIP Preconditions support between clusters or without it. For an overview of RSVP in UC designs and as a prerequisite to the following content, see the Unified Communications Architectures Using Resource Reservation Protocol (RSVP) section of the Call Admission Control chapter of Cisco Unified Communications System Release 8.x SRND at http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/8x/uc8x.html. That section includes detailed subsections on Unified CM RSVP-Enabled Locations and RSVP SIP Preconditions.

Unified CM Session Management Edition Design with Leaf Clusters without RSVP SIP Precondition Support

You can deploy Unified CM Session Management Edition with leaf clusters that maintain their own CAC support locally within the leaf cluster. In such deployments in which the leaf clusters manage their own CAC mechanism for their own devices in remote sites, or where those leaf clusters are in a campus deployment and do not require CAC for intracluster calls (calls that remain within the leaf cluster), you can leverage Unified CM Session Management Edition to manage CAC for audio and video calls between those leaf clusters (intercluster calls) with RSVP. In these cases Unified CM Session Management Edition leverages the RSVP Agents to handle CAC across the links between the leaf clusters, but does not manage CAC for the links that the leaf clusters manage for their intracluster calls.

The requirements for such deployments are as follows:

The leaf cluster CAC manages intracluster calls.

Unified CM Session Management Edition RSVP-enabled locations CAC manages intercluster calls.

Cisco highly recommends that the WAN bandwidth managed by Unified CM Session Management Edition for intercluster calls is not shared with the WAN bandwidth for intracluster calls managed by the leaf clusters. If the bandwidth from the same WAN links is managed by two separate CAC mechanisms, there is the potential for double bandwidth counting because the two separate CAC mechanisms are effectively unaware of each other.

Figure 46 depicts two leaf clusters that are deployed in different regional sites and use Unified CM Session Management Edition for intercluster connectivity. Leaf cluster 1 uses locations CAC to manage remote sites in its CAC domain, while Leaf cluster 2 uses RSVP to manage remote sites in its CAC domain. In this case Unified CM Session Management Edition uses remote RSVP Agents to leverage RSVP-enabled locations to manage the CAC domain between leaf clusters. Remote RSVP Agents are standard RSVP Agents that are registered with Unified CM Session Management Edition and are associated to the leaf cluster trunks through Media Resource Group and List (MRGL) functions. However, remote RSVP Agents are physically located at a campus site or collocated with the leaf cluster and are thus "remote" from the Unified CM Session Management Edition cluster. These RSVP Agents should be at a head-end network WAN that interconnects the leaf clusters and that is enabled to support RSVP.

Figure 46 Unified CM Session Management Edition Design with Leaf Clusters without SIP Precondition Support

In Figure 47, the call flow for a call setup between Leaf 1 and Leaf 2 works as follows:

1. Leaf 1 sets up a call to Unified CM Session Management Edition over an H.323 or SIP intercluster trunk. Q.SIG Path Replacement support is preferred, so use H.323 for Unified CM releases earlier than Release 8.5 and use SIP with Unified CM Release 8.5 and later releases.

2. Unified CM Session Management Edition receives the call from Leaf 1 and allocates two RSVP Agents (the RSVP Agents are associated to the trunks through the Media Resources Group and List [MGRL] functions; see Figure 46). After they are allocated, the RSVP Agents reserve the bandwidth over the path between them.

3. If the bandwidth request is successful the call is extended from Unified CM Session Management Edition to Leaf 2 over the SIP or H.323 intercluster trunk. If the reservation fails, the call is not extended to Leaf 2 and, depending on the configuration of call processing in Unified CM Session Management Edition, the call could be extended elsewhere or torn down from Leaf 1.

Figure 47 Unified CM Session Management Edition Design with Leaf Clusters without SIP Precondition Support


Note If the call is extended to Leaf 2 in Step 3, Leaf 2 can use locations CAC or RSVP as the call admission control for that call leg. If RSVP is used as in Figure 47, Leaf 2 associates an RSVP Agent to the SIP trunk that points to Unified CM Session Management Edition and an RSVP Agent is associated with the called party endpoint.



Note In cases in which the leaf cluster does RSVP locally and not with SIP Preconditions, the Unified CM Session Management Edition remote RSVP Agent and the leaf cluster RSVP Agent that is associated to the trunk to Unified CM Session Management Edition can be collocated on the same routing platform. See the section Multiple Clusters Sharing a Single Platform for RSVP Agent for further information.


Unified CM Session Management Edition Design with Leaf Clusters with RSVP SIP Precondition Support

You can deploy Unified CM Session Management Edition with leaf clusters that manage their CAC domain with RSVP and support RSVP SIP Preconditions. For details, see http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/8x/cac.html#wp1191628.

In this case Unified CM Session Management Edition enables its intercluster trunks with RSVP SIP Preconditions and passes the SIP Preconditions from leaf cluster to leaf cluster, allowing an end-to-end RSVP Agent deployment.

The requirements for such deployments are as follows:

clusters deploy Release 8.0 or later releases (preferably Release 8.6.1).

The leaf cluster uses Unified CM RSVP-enabled locations to manage intracluster calls. For more details, see http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/8x/cac.html#wp1190645.

Unified CM Session Management Edition manages intercluster calls with SIP ICTs that are configured to pass RSVP SIP Preconditions from leaf cluster to leaf cluster.

Q.SIG with path replacement should be enabled on all SIP ICTs to optimize call signaling for transferred and forwarded calls. (This requires Unified CM Release 8.5 or a later release.)

Figure 48 depicts the described solution in which leaf clusters have Unified CM RSVP-enabled locations for intracluster calls, and SIP ICT configured on both of the leaf clusters, and the Unified CM Session Management Edition is enabled with RSVP SIP Preconditions. Unified CM Session Management Edition passes the SIP Preconditions from leaf Unified CM to leaf Unified CM, which in turn pass those preconditions down to the branch RSVP Agents. This allows for an end-to-end RSVP reservation directly from branch to branch across multiple cluster boundaries.

Figure 48 Unified CM Session Management Edition Design with Leaf Clusters with SIP Precondition Support

Unified CM Session Management Edition Design with Mixed Leaf Clusters (with and without RSVP SIP Precondition Support)

Unified CM Session Management Edition can support a mixed environment in which: (i) on one trunk it supports RSVP SIP Preconditions on the trunk to a leaf cluster that supports RSVP locally and RSVP SIP Preconditions (for an example, see Figure 49, Leaf 2), and (ii) on another trunk Unified CM Session Management Edition associates an RSVP Agent and does RSVP locally to the trunk to a cluster that does not support RSVP SIP Preconditions (for an example, see Figure 49, Leaf 1).

Figure 49 Unified CM Session Management Edition Design with Mixed Leaf Clusters (with and without SIP Precondition Support)

Multiple Clusters Sharing a Single Platform for RSVP Agent

In some cases you might need to share a single router platform supporting RSVP Agent across multiple Unified CM clusters. To do so, you can configure a single router platform supporting RSVP Agent, such as a Cisco Integrated Services Router (ISR), with multiple RSVP Agents, with each agent registered to a separate Unified CM cluster with dedicated software sessions. See the RSVP Agent datasheet for the number of supported RSVP-Agent sessions per platform.

Figure 50 Unified CM Session Management Edition and Leaf Clusters—Multiple Clusters Sharing a Single Routing Platform for RSVP Agents

Trunk Security on Unified CM Session Management Edition Cluster Deployments

You can encrypt both trunk signaling and associated media in a Unified CM Session Management Edition deployment. You can enable media encryption for calls over SIP and H.323 trunks without encrypting the signaling. However, in this case the keys and other security-related information are sent unencrypted over the trunk connections. SIP trunks and H.323 trunks use different mechanisms for signaling encryption. These methods are discussed next.

Secure SIP Trunks

Securing SIP trunks involves two processes:

Configuring the trunk to encrypt media

Configuring the trunk to encrypt signaling

SIP trunk media encryption

Media encryption can be configured on SIP trunks by checking the SRTP allowed check box of the trunk. Be aware that enabling SRTP allowed causes the media for calls to be encrypted, but the trunk signaling will not be encrypted and therefore the session keys that are used to establish the secure media stream will be sent unencrypted. It is therefore important to ensure that signaling between Unified CM and its destination SIP trunk device is also encrypted so that keys and other security-related information do not get exposed during call negotiations.

SIP trunk signaling encryption

SIP trunks use TLS for signaling encryption. You configure TLS on the SIP security profile associated with the SIP trunk. TLS uses X.509 certificate exchanges to authenticate trunk devices and to enable signaling encryption.

Certificates can be either of the following:

Imported to each Unified CM node from every device that is required to establish a TLS connection to the SIP-trunk daemon of that node.

Signed by a Certificate Authority (CA), in which case there is no need to import the certificates of the remote devices. You need to import only the CA certificate.

Unified CM provides a bulk certificate import and export facility. However, for SIP trunks that use the Run on All Unified CM Nodes feature and up to 16 destination addresses, the use of a CA provides a centralized and less administratively burdensome approach to set up signaling encryption on SIP trunks.

Figure 51 SIP Intercluster Trunks Using TLS

Secure H.323 Trunks

Securing H.323 trunks involves two processes:

Configuring the trunk to encrypt media

Configuring the trunk to encrypt signaling

H.323 trunk media encryption

Media encryption can be configured on H.323 trunks by checking the SRTP allowed check box of the trunk. Be aware that checking the SRTP allowed check box will cause the media for calls to be encrypted but the trunk signaling will not be encrypted, therefore the session keys that are used to establish the secure media stream will be sent unencrypted. It is therefore important to ensure that signaling between Unified CM and its destination H.323 trunk device is also encrypted so that keys and other security-related information do not get exposed during call negotiations.

H.323 trunk signaling encryption

H.323 trunks use IPsec for signaling encryption. You may configure IPsec in the network infrastructure, or you may configure IPsec between Unified CM and the remote gateway or trunk. If you implement one method to set up IPsec, you do not need to implement the other method. Using IPsec on Unified CM servers can affect server performance significantly, therefore Cisco recommends that you provision IPsec in the network infrastructure rather than in Unified CM itself.

Figure 52 H.323 Intercluster Trunks Using Router-Based IPsec Tunnels

Cisco Mobile Solutions and Unified CM Session Management Edition Deployments

Cisco Unified Mobility refers to the native mobility functionality within Unified CM and includes the following features:

Mobile Connect (also known as SNR)

Mobile Voice Access (MVA)

Enterprise Feature Access (EFA)

Desk phone and Remote Destination pickup

Mid-call Supplementary Services (using DTMF feature access codes)

In addition there are a number of mobile client solutions that leverage Unified CM and Cisco Unified Mobility functionality:

Cisco Unified Mobile Communicator

Dual-mode phones and clients (example clients include Cisco Mobile 8.x for iPhone and Cisco Jabber 8.6 for Android)

Direct Connect Mobile clients (example clients include Cisco Mobile 8.5 for Nokia and all forthcoming Cisco Jabber mobile clients)

BlackBerry MVS

These features, solutions, and their operation are discussed in detail in the Mobile Unified Communications chapter of Cisco Unified Communications System Release 8.x SRND. (For details, see http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/8x/mobilapp.html#wp1244934.)

For Unified CM Session Management Edition-based UC designs, you can deploy Cisco Unified Mobility and mobility client solutions as follows:

Standard leaf Unified CM cluster mobility deployment with all mobility features and PSTN access provided on the leaf cluster

Leaf cluster mobility with Unified CM Session Management Edition-based PSTN access

Third-party PBX Mobility/Single Number Reach support with PSTN access through Unified CM Session Management Edition

Mobility features provided by Unified CM Session Management Edition for a connected third-party PBX

Figure 53 Unified CM Session Management Edition and Mobility Deployments

Standard Leaf Cluster Mobility Deployments

Standard leaf cluster mobility deployments are supported as described in Cisco Unified Communications System Release 8.x SRND at http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/8x/mobilapp.html.

Leaf Cluster Mobility Deployments with Unified CM Session Management Edition-Based PSTN Access

Leaf cluster mobility deployments with Unified CM Session Management Edition-based PSTN access support the following features and solutions:

Mobile Connect (also known as SNR)

Mobile Voice Access (MVA)

Desk phone pickup through hang-up at mobile device and resume at desk phone

Remote Destination pickup using Send Call to Mobile

Cisco Unified Mobile Communicator

Dual-mode phones and clients

Direct Connect Mobile clients

BlackBerry MVS


Note PSTN access can be TDM- or IP-based.


Leaf cluster mobility deployments with Unified CM Session Management Edition-based PSTN access do not support the following mobility features that use DTMF tones for feature invocation:

Enterprise Feature Access (EFA)

Desk phone and Remote Destination pickup

DTMF feature access code based Mid-call Supplementary Services

Mobility and Third-Party PBXs

Figure 54 depicts Unified CM Session Management Edition and Unified Mobility deployments with third-party PBXs. Third-party PBXs may or may not support mobility features; mobility deployments in both cases are discussed in the following sections.

Figure 54 Unified CM Session Management Edition and Unified Mobility Deployments—Third-Party PBXs

Third-Party PBX Mobility/Single Number Reach Support with PSTN Access Through Unified CM Session Management Edition

These deployments are supported because the Unified CM Session Management Edition cluster acts as a transit switch to route PBX calls to and from the PSTN and does not provide any native mobility functions.


Note Cisco cannot guarantee functionality or provide support for third-party PBX mobility features. You should test specific third-party PBX features prior to production deployment.


Mobility Features Provided by Unified CM Session Management Edition for a Connected Third-Party PBX

In this type of deployment, the third-party PBX does not natively support any mobility features, but uses the Unified CM Session Management Edition cluster as a proxy; and to leverage its mobility features creates a remote-destination profile and two or more remote-destination numbers/IDs per user. Configure the remote-destination profile at the line level with the enterprise-number of the user. Configure at least two remote-destination numbers and associate those numbers to the remote-destination profile. One remote-destination number is the directory number of the third-party PBX phone of the user and one additional remote-destination number is the mobile phone number of the user. To provide single-number-reach capabilities for PBX extensions you must configure each PBX-user enterprise number on the Unified CM Session Management Edition cluster (at the line level of the remote-destination profile), and you must route all inbound and outbound calls to and from the PBX through Unified CM Session Management Edition. In addition all calls originated from the third-party PBX and destined for single-number-reach-enabled PBX extensions must first be routed through the Unified CM Session Management Edition cluster. This typically will require either PBX extension renumbering for mobility-enabled PBX users or PBX dial plan translations such that calls to the single-number-reach-enabled PBX extensions are routed to the Unified CM Session Management Edition cluster initially in order to engage single number reach and ring back to the destination PBX extension as well as out to the mobile phone. The Unified CM Session Management Edition cluster can support a maximum of 15,000 remote destinations, and provide support for a maximum of 7500 mobility-enabled third-party PBX users (if you assume each user has only two remote destinations—one for the PBX extension and one for the mobile phone).

The preceding type of deployment supports the following mobility features:

Mobile Connect (also known as SNR)

Mobile Voice Access (MVA)


Note PSTN access can be TDM- or IP-based.


The following mobility features that use DTMF tones for feature invocation are not supported in the preceding type of Unified CM Session Management Edition deployment:

Enterprise Feature Access (EFA)

Desk phone and Remote Destination pickup

DTMF feature access code based Mid-call Supplementary Services

For further details, see http://www.cisco.com/en/US/solutions/collateral/ns340/ns414/ns728/ns832/962994.pdf.

Voicemail Applications on Unified CM Session Management Edition

Voicemail applications such as Cisco Unity Voice Mail can be connected to the Unified CM Session Management Edition cluster and provide a voicemail service to users on all leaf UC systems.

Figure 55 Unified CM Session Management Edition and Centralized Voicemail

On intercluster trunks between leaf clusters and Unified CM Session Management Edition and on trunk connections to your voicemail application, ensure that the Original Called Party/Redirecting number is sent with calls routed to voicemail.

For non-Q.SIG-enabled trunks—Original Called Party/Redirecting number transport can be enabled by:

Enabling inbound and outbound redirecting number IE delivery on MGCP gateways, H.323 gateways, and H.323 trunks

Enabling inbound and outbound redirecting diversion header delivery on SIP trunks

For Q.SIG-enabled SIP, MGCP and H.323 trunks—the original called party number is sent in Q.SIG diverting leg information APDUs.

Q.SIG-enabled trunks

Diversion information that is sent in Q.SIG APDUs over Q.SIG-enabled trunks (MGCP, H.323, or SIP trunks) does not pick up any calling party modifications and also does not honor the voice-mailbox mask setting. Q.SIG diversion information that is sent by Unified CM will always be set to the redirecting DN without applying any transformations.

If the redirecting DN is configured as +E.164 the leading + character will be removed so that the Q.SIG diversion information will carry only the E.164 number without the + character.

Consideration for all Q.SIG trunk types

On H.323, MGCP, and SIP trunks with Q.SIG tunneling enabled, all number information including calling, called, and redirecting number information is always taken from the encapsulated Q.SIG message and not from the outer H.323 message or SIP headers. This Q.SIG trunk operation can require specialized design considerations for a voicemail system centralized on Unified CM Session Management Edition and serving multiple leaf systems. This is discussed in Diversion Information and Centralized Voicemail—Summary Recommendations.

Diversion Information and Centralized Voicemail—Summary Recommendations

As a general recommendation, to enable a smooth end-to-end Q.SIG implementation a uniform globally unique dial plan should be implemented across all UC systems.

Even when a globally unique dial plan has been implemented across all UC systems the numbering format may not be uniform across all leaf UC systems. An example of this could be an implementation in which some leaf UC systems use E.164 numbering and others use 8XXXYYYY numbering.

If Q.SIG is used on all trunks between leaf systems and the Unified CM Session Management Edition cluster, these redirecting E.164- and 8XXXYYYY-based numbers cannot be normalized before they are sent to the centralized voicemail system. This limitation requires that the centralized voice-mailbox number for users in each leaf UC system should correspond to the number format of the directory numbers used in each leaf system.

For example:

Users with directory numbers of the format 8XXXYYYY—should have a corresponding voice-mailbox number using the same 8XXXYYYY format.

Users with directory numbers of the format E.164—should have a corresponding voice-mailbox number using the same E.164 format.

Users with directory numbers of the format +E.164—should have a corresponding voice-mailbox number using the same E.164 format.

Note—Cisco Unity Voicemail allows multiple numbers to be associated with the voice mailbox of a user. For example:

Primary VM box number: E.164

Alternate VM box number: +E.164

Primary VM box number: 8XXXYYYY

Alternate VM box number: +E.164

Notes on RDNIS Delivery for Voicemail

The Redirected Dialed Number Information Service (RDNIS) provides the number of the party that redirected a call during call setup. Voicemail systems use the information provided by this service to identify the user that redirected a call. This information is delivered to the voicemail system to be able to leave a message in the mailbox of the party that redirected the call. In PRI variants, the RDNIS information is delivered in the SETUP message in the Redirecting Number information element (IE), or, in some protocol implementations, the Original Called Number (OCN) IE. The Q.SIG protocol does not define these IEs and therefore the RDNIS service is not supported in the Unified CM Q.SIG implementation. When Q.SIG is enabled on Unified CM SIP or H.323 trunks, instead of using RDNIS, voicemail information is passed in DivertingLegInformation2 APDU as originalcalledPartyNumber.

Cisco TelePresence (Formerly Tandberg) VCS Integration with Unified CM Session Management Edition

Architectures to deploy Cisco TelePresence Video Communication Server (Cisco VCS) with Unified CM are discussed in the Cisco TelePresence Deployment Guide document: http://www.cisco.com/en/US/docs/telepresence/infrastructure/vcs/config_guide/Cisco_VCS_Cisco_Unified_Communications_Manager_Deployment_Guide_CUCM_6-1_7_8_and_X6.pdf.

Unified CM Session Management Edition Deployments with Cisco Unified Contact Center Enterprise

Unified CM Session Management Edition can be deployed in Cisco Unified Contact Center Enterprise (Unified CCE) designs, in which one or more leaf clusters are contact-center-enabled. Note that there are specific requirements for the architecture that is used in these scenarios. The primary deployment considerations for UC designs with Unified CM Session Management Edition and Unified CCE are as discussed in this section.

SIP protocol

Unified CCE is certified only to use SIP as the protocol interconnecting the solution components. This means that Unified CVP, Unified CM Session Management Edition and the clusters all must use SIP when communicating to each other. H.323 and other forms of intercluster trunks are not supported in the contact center call flows but may be used in other parts of the solution. External (service provider) trunks can use SIP or TDM, and phones can use any protocol that is supported by traditional Unified CCE designs.

DTMF transport

RFC2833 (in-band DTMF) is the preferred DTMF transport in Unified CCE, because it is the only method that is supported for self-service applications on Unified CVP. To eliminate the need for complex MTP provisioning on Unified CM Session Management Edition, cluster trunks should be configured with DTMF Signaling Method: RFC2833 (no special setting is required in the Unified CM Session Management Edition trunks themselves). Failure to take this step usually results in MTPs being required in Unified CM Session Management Edition for calls placed from the leaf clusters into Unified CVP (through Unified CM Session Management Edition). Note that MTP provisioning in the leaf clusters should still be performed as in a traditional Unified CCE design.

Unified CM Session Management Edition Trunk-to-Trunk SIP Header Transparency

Unified CCE and Unified CVP often use SIP headers to pass information between systems. By default, Unified CM Session Management Edition does not relay some of these SIP headers and payloads transparently from one trunk to another. However, if required, a transparency script could be applied to the Unified CM Session Management Edition trunk. Examples of these headers include the following (this list is not exhaustive):

Call-Info, which is used to provide the source of the call (that is, the IP address of the originating gateway) so that systems can apply call admission control (CAC) and interregion codec rules. This is only relevant when the leaf cluster needs to be informed of the ingress gateway location, which is not the case when Unified CM Session Management Edition is enforcing CAC or when all the gateways are centralized.

GTD (Generic Transparency Descriptor), which is a Multipurpose Internet Mail Extensions (MIME) payload to SIP messages that Cisco TDM gateways can use to pass ISDN information elements (when configured appropriately).Technically, GTD is not a SIP header, but is listed here for completion. The most common uses for GTD are to pass ISDN user-to-user data to and from Unified CVP, and to move ISDN information between an ingress and an egress gateway. Unified CM does not use GTD, so Unified CM Session Management Edition transparency for GTD is not commonly required.

Custom headers, which Unified CCE and Unified CVP administrators may create to meet specific customer needs.

Unified CM Session Management Edition relays the Cisco-Guid header transparently by default. This header contains a universal call identifier that enables end-to-end tracking for troubleshooting, reporting, and recording.

Unified CM Session Management Edition Trunk-to-Trunk SIP Message Transparency

In addition to headers, Unified CVP sometimes uses different SIP messages that Unified CM Session Management Edition is not configured to handle by default. Examples of these messages include the following:

REFER-based transfers: Unified CVP can be configured to use SIP REFER to transfer calls. By default Unified CM will digest an inbound SIP REFER message and send a Re-INVITE message in its place to transfer the call. By sending a Re-INVITE instead of a REFER message, call signaling is maintained through the Unified CM cluster for the duration of the call. Some contact center customers prefer to release both the call media and signaling in this type of to-PSTN call-transfer scenario. To achieve this, create a Lua transparency script that allows the REFER message to be transparently sent from the inbound SIP trunk to the outbound SIP trunk. In this case, the REFER request is forwarded over the outbound SIP Trunk instead of a Re-INVITE message.

302 Redirect-based transfers: Unified CVP will send a 302 Redirect message instead of a SIP REFER if the transfer is invoked before a call is completely answered (SIP 200 OK). Unified CM Session Management Edition behavior is analogous to REFER-based transfers.

SIP INFO: Unified CVP sends SIP INFO messages to play DTMF tones out-of-band. This is used in transfer-connect scenarios. Unified CM Session Management Edition behavior is analogous to REFER-based transfers. By default, INFO messages are consumed locally, therefore Lua transparency scripts are required to relay them to the ingress gateway if Unified CM Session Management Edition is in the signaling path.

Supported Deployment Model

To improve solution resiliency and interoperability, the supported deployment model with Unified CM Session Management Edition must adhere to the following:

External calls (PSTN) must not flow through a Unified CM Session Management Edition before reaching Unified CVP. Calls must arrive at a Cisco TDM gateway or Cisco Unified Border Element and then go directly to Unified CVP. Alternatively, Cisco Unified SIP Proxy (Unified SIP Proxy) may be used in front of the Unified CVP servers.

SIP signaling between Unified CVP and the IOS Voice XML browsers must not flow through a Unified CM Session Management Edition. They may flow through Unified SIP Proxy.

Unified CM Session Management Edition may be used when the call egresses from Unified CVP, so Unified CM Session Management Edition is used to route the calls to the Unified CM cluster where the agents are.

Figure 56 illustrates this call flow.

Figure 56 Supported Unified CM Session Management Edition and Unified CCE Deployment

In this deployment model, transparency scripts are not usually required. Unified SIP Proxy can relay headers and messages transparently when calls ingress from the gateway into Unified CVP, and usually there is no need for Unified CVP to pass headers to Unified CM on the egress leg.

Note that in this deployment, calls to back-office (non-contact-center) users are routed through Unified CM Session Management Edition.

The deployment shown in Figure 57 shows an unsupported Unified CM Session Management Edition and Unified CCE design. For deployments requiring high availability for queued contact center calls, these calls should be routed through Unified SIP Proxy rather than through Unified CM Session Management Edition as depicted in Figure 56.

Figure 57 Unified CM Session Management Edition and Unified CCE Deployment—Unsupported if High Availability is Required

IPv6-Based Unified CM Session Management Edition Deployments

Cisco supports IPv4 and IPv6 on the following UC products:

Unified CM/Unified CM Session Management Edition SIP trunks

Newer SCCP-based phones

SIP-based IOS gateways

Cisco Unified Communications Manager Express

Cisco Unified Border Element

SCCP-based VG224 Analog gateways and Router FXS ports

IOS MTPs

SIP trunks to Unity Connection

Summary IPv6 UC Design Guidance

Cisco recommends a dual stack (IPv4 and IPv6) configuration.

Cisco recommends dual stack Alternative Network Address Types (ANAT) for SIP trunks.

For detailed guidance about IPv6 UC design, see http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/ipv6/ipv6srnd.html.

Figure 58 IPv6-Based Unified CM Session Management Edition Deployments

Deploying Cross Cluster Extension Mobility with Unified CM Session Management Edition

Cross Cluster Extension Mobility (EMCC) can be deployed as an overlay between leaf clusters in a Unified CM Session Management Edition-based UC network. Leaf cluster EMCC trunks do not point to the Unified CM Session Management Edition cluster. In each leaf cluster, an EMCC trunk and its corresponding remote cluster destination information are defined such that each EMCC trunk can reach all other EMCC-enabled leaf clusters directly. In general, these EMCC trunks are used only for emergency calls from phones in a visiting cluster. All other calls will typically traverse the Unified CM Session Management Edition cluster.

Figure 59 Leaf Cluster EMCC with Unified CM Session Management Edition



Cisco and the Cisco Logo are trademarks of Cisco Systems, Inc. and/or its affiliates in the U.S. and other countries. A listing of Cisco's trademarks can be found at www.cisco.com/go/trademarks. Third party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1005R)

1 A trunk accepts a call if the incoming source IP address matches one of the addresses that are defined as its destination IP address.
2 Note: With no controlled or monitored third-party devices, or CTI devices in the Unified CM Session Management Edition cluster, no CTI manager real-time traffic is generated.