Cisco Preferred Architecture for Enterprise Collaboration 10.x, CVD

Cisco Preferred Architecture for Enterprise Collaboration 10.x, CVD

C H A P T E R

2

Call Control

Revised: January 22, 2015

This chapter describes the call control function for the Cisco Preferred Architecture (PA) for Enterprise

Collaboration.

Certain requirements might put your deployment outside the PA design guidelines and recommendations, in which case you might have to use other documentation such as the

Cisco

Collaboration SRND

and related product documentation.

The first part of this chapter provides an architectural overview and introduces some fundamental design concepts, while the second part explains more detailed deployment considerations. The

Architecture

section discusses topics such as redundancy concepts, high availability, Computer Telephony Integration

(CTI), and IM and presence architecture, and it introduces a hypothetical customer topology used in the examples throughout this document. The focus of this chapter is the

Deployment Overview section. The

deployment examples in that section will help you to understand the background of certain design decisions more clearly than an abstract discussion of concepts can. Topics covered in the

Deployment

Overview section include DNS requirements, cluster provisioning, certificate management, dial plan

configuration, user provisioning using LDAP, media resources, SIP trunking considerations, endpoint

provisioning, and multi-cluster considerations. The order of the topics in the Deployment Overview

section follows the recommended configuration order.

What’s New in This Chapter

Table 2-1

lists the topics that are new in this chapter or that have changed significantly from previous releases of this document.

Table 2-1 New or Changed Information Since the Previous Release of This Document

New or Revised Topic

Enterprise specific numbering (ESN) scheme for conferences was simplified

Described in:

Table 2-11

Revision Date

January 22, 2015

Cisco Preferred Architecture for Enterprise Collaboration 10.x

2-1

January 22, 2015

Core Components

The core architecture contains these key elements (

Figure 2-1

):

Cisco Unified Communications Manager

Cisco Unified Communications Manager IM and Presence Service

Cisco Integrated Services Router (ISR)

Figure 2-1 Preferred Architecture Overview

Chapter 2 Call Control

Key Benefits

Call control is centralized at a single location that serves multiple remote sites.

Management and administration are centralized.

Common telephony features are available across voice and video endpoints.

Single call control and a unified dial plan are provided for voice and video endpoints.

Critical business applications are highly available and redundant.

2-2

Cisco Preferred Architecture for Enterprise Collaboration 10.x

January 22, 2015

Chapter 2 Call Control

Architecture

Architecture

The handling and processing of voice and video calls is a critical function provided by enterprise communications systems. This functionality is handled by some type of call processing entity or agent.

Given the critical nature of call processing operations, it is important to design unified communications deployments to ensure that call processing systems are scalable enough to handle the required number of users and devices and are resilient enough to handle various network and application outages or failures.

This chapter provides guidance for designing scalable and resilient call processing systems with Cisco

Unified Communications Manager (Unified CM) and Survivable Remote Site Telephony (SRST). A centralized Unified CM cluster implements call processing services for all customer sites. Unified CM

IM and Presences Service as part of the centralized Unified CM cluster implements instant messaging and presence services for the enterprise. Cisco Survivable Remote Site Telephony (SRST) is used to implement backup services for remotes sites when the corporate WAN reliability does not match the voice services availability requirements.

Cisco Unified CM provides call processing services for small to very large single-site deployments, multi-site centralized call processing deployments, and/or multi-site distributed call processing deployments. Unified CM is at the core of a Cisco Collaboration solution, and it serves as a foundation to deliver voice, video, TelePresence, IM and presence, messaging, mobility, web conferencing, and security.

Access to the enterprise collaboration network and to Unified CM from the Internet to enable remote access and business-to-business secure telepresence and video communications, is also available through various collaboration edge solutions such as VPN and Cisco Expressway.

Role of Unified CM

Cisco Unified CM is the central call control component in any Cisco collaboration deployment.

Unified CM provides foundation services including call control, endpoint registration, endpoint configuration, call admission control, codec negotiation, trunk protocol translation, and CTI.

Unified CM is the central point of administration and provisioning. All SIP trunks to other components

– including conferencing media resources, gateways, and other components – are terminated on

Unified CM so that Unified CM can orchestrate access to all of those components. Call routing is controlled by the dial plan configuration applied to Unified CM.

Role of IM and Presence Service

The Cisco Unified CM IM and Presence Service provides on-premises instant messaging and presence.

It uses standards-based XMPP and also supports SIP for interoperability with SIP IM providers. Cisco

Unified CM IM and Presence Service is an on-premise solution. The other Cisco instant messaging and presence service, Cisco WebEx Messenger, is a cloud-based service and is not covered in this document.

Role of SRST

When deploying Cisco desk phones in branch locations separated from a centralized call processing platform by a low-speed or unreliable WAN link, it is important to consider local call processing redundancy. By leveraging Survivable Remote Site Telephony (SRST) on a Cisco IOS router in each branch location, basic IP telephony services can be maintained for the desk phones if connectivity to the centralized call processing platform is lost. However, the set of available user-facing features is much smaller when a device is registered to SRST than when the phone is registered to Unified CM.

January 22, 2015

Cisco Preferred Architecture for Enterprise Collaboration 10.x

2-3

Chapter 2 Call Control

Architecture

Unified CM Redundancy with Survivable Remote Site Telephony (SRST)

Cisco IOS SRST provides highly available call processing services for endpoints in locations remote from the Unified CM cluster. Unified CM clustering redundancy schemes provide a high level of redundancy for call processing and other application services within a LAN or MAN environment.

However, for remote locations separated from the central Unified CM cluster by a WAN or other low-speed links, SRST can be used as a redundancy method to provide basic call processing services to these remote locations in the event of loss of network connectivity between the remote and central sites.

We recommend deploying SRST-capable Cisco IOS routers at each remote site where call processing services are considered critical and need to be maintained in the event that connectivity to the

Unified CM cluster is lost. Endpoints at these remote locations must be configured with an appropriate

SRST reference within Unified CM so that the endpoint knows what address to use to connect to the

SRST router for call processing services when connectivity to Unified CM subscribers is unavailable.

Unified CM and IM and Presence Service Clustering

Unified CM supports the concept of clustering. The Unified CM architecture enables a group of server nodes to work together as a single call processing entity. This grouping of server nodes is known as a cluster.

There are two types of Cisco Unified CM nodes: publisher and subscriber.

Unified CM publisher

The publisher is a required server node in all clusters. There can be only one publisher per cluster.

This server node contains the cluster configuration, and it provides the database services to all other subscribers in the cluster. In this design, the Unified CM publisher is a dedicated node; it does not handle TFTP requests, endpoint registration, or call processing.

Unified CM subscriber

Subscriber nodes subscribe to the publisher to obtain a copy of the database information. Subscriber nodes include, for example, the Unified CM TFTP nodes and the Unified CM call processing subscriber nodes.

Cisco IM and Presence nodes have the same clustering concept. The first IM and Presence node is the

IM and Presence publisher. The other IM and Presence nodes are the IM and Presence subscribers, and they obtain a copy of their database from the IM and Presence publisher. The IM and Presence publisher communicates with the Unified CM publisher and most of the IM and Presence configuration is actually done through the Unified CM publisher (for instance, the Unified CM users, the UC services available to presence users, and the service activation). Hence, all IM and Presence nodes, including the IM and

Presence publisher, are considered subscribers of the larger Unified CM and IM and Presence Service cluster.

Figure 2-2 shows the relationship between the Unified CM publisher and a two-node IM and

Presence cluster.

2-4

Cisco Preferred Architecture for Enterprise Collaboration 10.x

January 22, 2015

Chapter 2 Call Control

Figure 2-2

Architecture

Relationship Between Unified CM and a Two-Node IM and Presence Cluster

High Availability

Unified CM and IM and Presence nodes should be deployed in a highly available infrastructure. For example, the use of dual power supplies combined with the use of uninterruptible power supply (UPS) sources will provide maximum power availability. From a network perspective, the platform servers should be connected to multiple upstream switches.

Unified CM and IM and Presence systems also handle high availability at the application level.

With Unified CM in this design, two TFTP servers should be deployed for redundancy. The call processing nodes should be deployed with one-to-one (1:1) redundancy, where for every primary call processing subscriber there is a backup call processing subscriber. This 100%:0% redundancy design compared to a 50%:50% redundancy design has a number of advantages, including the reduction of

Unified CM groups and device pools and simplified configuration and distribution of devices with fewer redundancy options.

Cisco IOS Survivable Remote Site Telephony (SRST) provides highly available call processing services for endpoints in locations remote from the Unified CM cluster when the WAN links are down.

Individual Cisco IM and Presence nodes are grouped in subclusters. A subcluster can have one or two nodes. Adding the second node in a subcluster provides high availability. High availability is recommended, and therefore in this design each subcluster consists of two nodes. A two-node subcluster allows for users associated with one server of the subcluster to use the other server in the subcluster automatically if a failover event occurs. We recommend balancing the user assignment between the two nodes in each pair. The IM and Presence publisher handles IM and Presence information from presence clients just like any other IM and Presence subscriber does, and it is deployed as one of the two nodes in an IM and Presence subcluster.

January 22, 2015

Cisco Preferred Architecture for Enterprise Collaboration 10.x

2-5

Chapter 2 Call Control

Architecture

Computer Telephony Integration (CTI)

Cisco Computer Telephony Integration (CTI) extends the rich feature set available on Cisco Unified CM to third-party applications.

CTI Architecture

Cisco CTI consists of the following components (

Figure 2-3 ), which interact to enable applications to

take advantage of the telephony feature set available in Cisco Unified CM:

CTI application — Cisco or third-party application written to provide specific telephony features and/or functionality. It can use a JTAPI or TAPI interface. The protocol between the CTI application and Unified CM is Quick Buffer Encoding (QBE).

Unified CM subscriber with the following services:

CCM — The Cisco CallManager Service, the telephony processing engine.

CTI Manager (CTIM) — A service that runs on one or more Unified CM subscribers operating in primary/secondary mode and that authenticates and authorizes telephony applications to control and/or monitor Cisco IP devices.

Figure 2-3 CTI Architecture

2-6

Cisco Preferred Architecture for Enterprise Collaboration 10.x

January 22, 2015

Chapter 2 Call Control

Architecture

High Availability for CTI

High availability for CTI Manager relies on the CTI application being able to connect to the backup CTI

Manager Service in case the primary CTI Manager fails. In case both the CTI Manager and CCM services on the primary Unified CM subscriber fail (for example, if the entire primary Unified CM subscriber fails), then both CCM and CTI Manager services running on the backup Unified CM subscriber will become active, and the CTI Manager service will monitor and control the devices that are registered to the CCM service located on the same backup Unified CM subscriber. If the primary CTI

Manager Service fails but the primary CCM Service is still running (assuming you have 1:1 redundancy with a distribution of 100%/0% on the primary/backup Unified CM subscribers), then all the devices will stay registered to the CCM Service running on the primary Unified CM subscriber, and the CTI Manager running on the backup Unified CM subscriber will become active and will monitor and control the CTI devices even though they are registered to a CCM service running on a different node (the primary

Unified CM subscriber in this case).

Capacity Planning for CTI

Ensure the capacity limits are not exceeded for the three types of CTI resources:

The maximum number of CTI applications connecting to a given CTI Manager instance

(Unified CM node running the CTI Manager service). This number is typically low with CTI server-based application, but with CTI client-based applications such as Jabber clients in deskphone mode where each Jabber client is considered a CTI application, it is important to ensure the limit is not exceeded when deploying a large number of Jabber clients.

The maximum number of CTI-enabled endpoints registered to a given Unified CM call processing subscriber.

The maximum number of CTI-enabled endpoints monitored and controlled by a CTI Manager instance. Ideally, the CTI Manager service running on a Unified CM node monitors only the endpoints registered to that Unified CM node. But it is possible that a CTI Manager service also monitors endpoints registered to other Unified CM nodes.

The CTI limits are the same for all three CTI resources described above. The CTI capacity limits vary with the type of OVA template. If the CTI limit is reached, deploy another pair of Unified CM call processing nodes running the CTI Manager service.

IM and Presence Architecture

The Cisco Unified CM IM and Presence Service provides on-premises instant messaging and presence.

The main presence component of the solution is the IM and Presence Service, which incorporates the

Extensible Communications Platform (XCP) and supports SIP/SIMPLE and Extensible Messaging and

Presence Protocol (XMPP) for collecting information regarding a user's availability status and communications capabilities. The user's availability status indicates whether or not the user is actively using a particular communications device such as a phone.

Applications (either Cisco or third-party) can integrate presence and provide services that improve the end user experience and efficiency. In addition, Cisco Jabber is a supported client of the IM and Presence

Service that also integrates instant messaging and presence status.

The IM and Presence Service uses the same underlying appliance model and hardware used by

Unified CM on the Cisco Unified Computing System (UCS) platform.

January 22, 2015

Cisco Preferred Architecture for Enterprise Collaboration 10.x

2-7

Architecture

Chapter 2 Call Control

The IM and Presence Service is deployed as an IM and Presence cluster. The IM and Presence cluster consists of up to six nodes, including one designated as a publisher and up to five subscriber nodes. As

discussed in the sections on Unified CM and IM and Presence Service Clustering

and

High Availability ,

the IM and Presence nodes are grouped in subclusters and each subcluster consists of two nodes for high availability. As discussed in the sizing section, a single subcluster can be deployed in order to support up to 15,000 users. The IM and Presence publisher handles IM and presence requests, just like the IM and Presence subscribers do, so the first subcluster consists of the IM and Presence publisher and one

IM and Presence subscriber.

As discussed in the section on

Unified CM and IM and Presence Service Clustering , the IM and Presence

nodes are considered part of the larger Unified CM and IM and Presence Service cluster.

Deployment of the Unified CM and IM and Presence Service Cluster

The Cisco Unified CM and IM and Presence Service cluster consists of the following nodes:

1x Cisco Unified CM publisher

2x (1 pair) Cisco Unified CM TFTP server subscribers

2x (1 pair) Cisco Unified CM call processing subscribers (Add additional pairs to scale.)

2x (1 pair) Cisco Unified IM and Presence nodes (Add additional pairs, or subclusters, to scale.)

The number of Unified CM call processing pairs and of IM and Presence pairs to add in order to scale is discussed in the chapter on

Sizing .

Figure 2-4

shows an example of a Unified CM and IM and Presence Service cluster deployment with up

to 10,000 devices and 10,000 users. For more sizing information, refer to the Sizing chapter.

2-8

Cisco Preferred Architecture for Enterprise Collaboration 10.x

January 22, 2015

Chapter 2 Call Control

Figure 2-4 Unified CM and IM and Presence Service Cluster Deployment

Architecture

Endpoints

Jabber

Cisco Jabber clients provides core collaboration capabilities for voice, video, and instant messaging to users. Cisco Jabber is available on a wide variety of platforms including Windows, Mac, and mobile devices such as smartphones and tablets.

Cisco Jabber can be deployed in either of two modes:

Full UC and Cisco Jabber for Everyone (IM only) Mode

This is the default mode. The user's primary authentication is to an IM and Presence server. This is the mode used in this Preferred Architecture design and cover in this document.

Phone Mode

In phone mode, the IM and Presence Service is not required.

Figure 2-5 illustrates the architecture of an on-premises deployment that includes Cisco Unified

Communications Manager IM and Presence.

January 22, 2015

Cisco Preferred Architecture for Enterprise Collaboration 10.x

2-9

Architecture

Figure 2-5

Chapter 2 Call Control

Cisco Unified Communications with IM and Presence Architecture

To connect to services, Cisco Jabber requires the following information:

Source of authentication that enables users to sign in to the client

In full UC or IM-only modes, the source of authentication is the IM and Presence service. In phone-only mode, it is Unified CM.

Location of services

The services include IM and Presence, directory, CTI, voicemail, and conferencing.

To provide this information to the client, we recommend using the Service Discovery method over the

Manual Connection method. With the Service Discovery method, the client automatically locates and connects to services.

In this design, the client automatically discovers services and configuration with the SRV record

_cisco-uds that is retrieved when the user first enters his or her email address in the Jabber client.

The Jabber Contact Sources can be an LDAP contact Source with an Enhanced Directory Integration

(EDI) for the Microsoft Windows desktops or a Basic Directory Integration (BDI) for other platforms such as OS X, iOS, or Android. Another source for the contacts can be the Unified CM User Data Service

(UDS), but that will reduce the number of users supported on Unified CM.

2-10

Cisco Preferred Architecture for Enterprise Collaboration 10.x

January 22, 2015

Chapter 2 Call Control

Architecture

Multi-Cluster Considerations

In a multi-cluster deployment, interconnect all the individual Unified CM clusters through SIP trunks.

To avoid session traversal through individual clusters, deploy a full mesh of SIP trunks. With four or more clusters, deploy Cisco Unified CM Session Management Edition (SME) to centralize the dial plan and trunking and to avoid the complexity of a full-mesh SIP trunk topology. Cisco Unified CM SME is not covered in this document. For more information about SME, refer to the

Cisco Collaboration SRND

.

In multi-cluster deployments, use Global Dial Plan Replication (GDPR) to replicate dial plan information between clusters. GDPR can advertise a +E.164 number, one Enterprise Significant Number

(ESN), and up to five alpha-numeric URIs per directory number. An ESN is the abbreviated inter-site dialing equivalent of a directory number. The information advertised and learned through GDPR enables deterministic intercluster routing for these dialing habits:

+E.164 dialing based on the advertised +E.164 numbers

Enterprise abbreviated inter-site dialing based on the advertised ESNs

Alpha-numeric URI dialing based on the advertised URIs

IM and Presence functionality is limited by having communications within a single cluster. To extend presence and instant messaging capability and functionality, these standalone clusters can be configured for peer relationships for communication between clusters within the same domain. This functionality provides the ability for users in one cluster to communicate and subscribe to the presence of users in a different cluster within the same domain. To create a fully meshed presence topology, each Cisco IM and

Presence cluster requires a separate peer relationship for each of the other Cisco IM and Presence clusters within the same domain. The intercluster peer is configured as the IP address of the remote

Unified CM cluster IM and Presence publisher node.

January 22, 2015

Cisco Preferred Architecture for Enterprise Collaboration 10.x

2-11

Chapter 2 Call Control

Architecture

Topology Example

For the purpose of this document, we assume a centralized call processing deployment serving three sites in the US: SJC, RCD, and RTP. The Unified CM and IM and Presence Service servers are centrally located in RCD. Central PSTN access is in RCD as well. SJC and RTP are assumed to be small sites, with Survivable Remote Site Telephony (SRST) configured locally, with local PSTN access when the

WAN connectivity to the RCD site is down.

Figure 2-6 illustrates this topology example.

Figure 2-6 Example Topology

The topology example used in this document for multi-cluster considerations is a two-cluster deployment: the cluster in the United States as shown in

Figure 2-6

, and a second cluster to cover

Europe, the Middle East, and Africa (EMEA).

2-12

Cisco Preferred Architecture for Enterprise Collaboration 10.x

January 22, 2015

Chapter 2 Call Control

Deployment Overview

Deployment Overview

Deployment begins with provisioning of the centralized Cisco Unified CM cluster followed by further configuration and provisioning tasks. The following sections describe how to set up and configure the call control according to the Preferred Architecture design in this document:

DNS Requirements

Provision the Cisco Unified CM and IM and Presence Service Cluster

Cisco Unified CM and IM and Presence Certificate Management

Initial Cisco Unified CM Configuration

Other IM and Presence Settings

Dial Plan Configuration

User Provisioning with LDAP Synchronization

User Authentication with LDAP

Cisco Unified CM Group Configuration

Phone NTP References

Date and Time Groups

Media Resources

Device Pools

SIP Trunks

Endpoint Provisioning

ILS Configuration for Multi-Cluster Deployments

GDPR Configuration (Multi-Cluster Only)

Survivable Remote Site Telephony (SRST) Deployment

Extension Mobility

Busy Line Field (BLF) Presence

Deploying Computer Telephony Integration (CTI)

DNS Requirements

Before deploying the solution, make sure DNS resolution is available for all servers to be deployed. Both forward (from DNS name to IP address) and reverse (from IP address to DNS name) lookups have to be configured in the enterprise DNS.

In addition to enabling UDS-based service discovery for Jabber clients, provision DNS SRV records for all Unified CM publisher and TFTP subscriber nodes, defining these as service locations for _cisco-uds.

Example 2-1

shows an example of DNS SRV records defining a number of Unified CM nodes as

_cisco-uds service locations.

January 22, 2015

Cisco Preferred Architecture for Enterprise Collaboration 10.x

2-13

Chapter 2 Call Control

Deployment Overview

Example 2-1 DNS SRV Record for UDS-Based Service Discovery

_cisco-uds._tcp.ent-pa.com SRV service location:

priority = 10

weight = 10

port = 8443

svr hostname = us-cm-pub.ent-pa.com

_cisco-uds._tcp.ent-pa.com SRV service location:

priority = 10

weight = 10

port = 8443

svr hostname = us-cm-tftp1.ent-pa.com

_cisco-uds._tcp.ent-pa.com SRV service location:

priority = 10

weight = 10

port = 8443

svr hostname = us-cm-tftp2.ent-pa.com

In

Example 2-1 , all three Unified CM nodes (publisher and two TFTP subscriber nodes) are defined as

service locations for UDS service discovery to make sure that the load of the initial UDS requests from

Jabber clients making use of UDS service discovery are evenly distributed among all active Unified CM nodes.

As part of the UDS service discovery process, after locating the home cluster using the /cucm uds/clusterUser resource, Jabber clients will use the /cucm-uds/servers resource to get a list of all UDS nodes in the user's home cluster, so that the actual UDS requests during the registration process are load balanced between all UDS nodes of the cluster even if the SRV records defined only the publishers as service locations.

Provision the Cisco Unified CM and IM and Presence Service Cluster

To deploy the Unified CM and IM and Presence Service cluster, perform the following tasks:

1.

Determine the number of required call processing subscriber pairs based on the target number of users and devices.

2.

3.

Determine the number of required IM and Presence nodes based on the target number of users.

Determine the network parameters (DNS names, IP addresses, and so forth) for all required cluster members. Make sure to consider the TFTP servers also.

4.

Deploy the required number of virtual machines on your compute infrastructure using the appropriate Cisco provided OVA template files. For information on how to obtain these OVA files, refer to the documentation at http://docwiki.cisco.com/wiki/Downloading_OVA_Templates_for_UC_Applications

5.

In Cisco Prime Collaboration Deployment, define the Unified CM cluster with all its members, and map the nodes to the virtual machines created in task 4.

Deploy all nodes using Cisco Prime Collaboration Deployment.

6.

For more information on how to provision a cluster using Cisco Prime Collaboration Deployment, refer to the Cisco Prime Collaboration Deployment Administration Guide, available at http://www.cisco.com/c/en/us/support/unified-communications/unified-communications-managercallmanager/products-maintenance-guides-list.html

2-14

Cisco Preferred Architecture for Enterprise Collaboration 10.x

January 22, 2015

Chapter 2 Call Control

Deployment Overview

Cisco Unified CM and IM and Presence Certificate Management

Whenever a certificate needs to be checked during session establishment, either between two servers or between on central service and a client application such as Cisco Jabber for Windows, the certificate must pass the following checks:

Validity — The current time and date must be within the certificate’s validity range.

Trust — The certificate must be trusted. A certificate is considered trusted if trust with the signing

(issuing) party exists. Trust with signing parties typically is established by importing the certificate of the signing party into a store of trusted certificates.

Identity — The subject or identity for which the certificate is issued must match the identity that the initiator of the session intended to reach.

By default all certificates used by Unified CM and IM and Presence are self-signed certificates. While the validity and identity aspect of the above checks does not create any special problems with the self-signed certificates, the trust aspect is an issue. To establish trust with a service based on a self-signed certificate, the self-signed certificate must be imported into the trusted certificates store of all entities requiring secure connections to the service. This can be handled if the set of communicating parties is small, but it becomes more difficult for large numbers of communication peers (for example, client applications such as Jabber).

If certificate validation fails on Jabber clients, then the user is prompted and can accept the certificate, which then is added to the trusted certificate store. This should be avoided because being prompted multiple times to accept a number of certificates during startup of the client is not the best user experience. Even more important is that in reality most users will not actually verify whether the presented certificate is correct by checking the certificate's fingerprint, and instead will just accept any certificate. This breaks the security concept of certificate-based authentication for secure session establishment.

For these reasons, the recommended deployment of Cisco Jabber clients requires that certificate validation during startup of the clients must not fail. This can be achieved in either of two ways:

Use self-signed certificates and pre-distribute all required self-signed certificates to the devices' certificate stores.

In Windows environments certificates can be added to devices' certificate stores via Microsoft group policies.

Use certificates issued by a certificate authority (CA).

In this case the self-signed certificates used by the infrastructure services are replaced by certificates issued and signed by a trusted CA. To establish trust with the CA, the CA's root certificate is added to the trusted certificates store of all clients. By default most client devices include all of the major public CA root certificates in their trusted certificate store.

The second option is the recommended approach because it allows issue of new service certificates without having to update all client trusted certificate stores as long as the signing CA's root certificate has already been added to the trusted certificates stores of all clients.

Table 2-2

lists the CA root certificates validated by Cisco Jabber clients.

January 22, 2015

Cisco Preferred Architecture for Enterprise Collaboration 10.x

2-15

Chapter 2 Call Control

Deployment Overview

Table 2-2 Certificates Validated by Cisco Jabber Clients

Service

Cisco Unified CM

Cisco Unified CM IM and Presence Service

Certificate

Tomcat

Tomcat

Cisco Unified CM IM and Presence Service cup-xmpp

Cisco Unity Connection Tomcat

Description

Unified CM web services certificate

Unified CM IM and Presence web services certificate

Unified CM IM and Presence

XMPP service certificate

Unity Connection web services certificate

Validated by

Browser accessing GUI

Jabber clients

Browser accessing GUI

Jabber clients

Jabber clients

Browser accessing GUI

Jabber clients

1.

2.

3.

4.

5.

6.

Steps required prior to replacing self-signed certificates with CA issued certificates:

Obtain the root certificate of the CA you plan to use to issue the certificates.

Navigate to the OS administration GUI of Unified CM.

Upload the CA root certificate as tomcat-trust.

Navigate to the OS administration GUI of Unified CM IM and Presence.

Upload the CA root certificate as xmpp-trust.

Navigate to the OS administration GUI of Cisco Unity Connection.

7.

Upload the CA root certificate as tomcat-trust.

Steps to replace a self-signed certificate with a CA issued certificate:

1.

Navigate to the OS administration GUI of the respective platform:

For Unified CM and Unified CM IM and Presence Tomcat certificate, use the Unified CM OS

GUI.

For Unified CM IM and Presence cup-xmpp certificate, use the Unified CM IM and Presence

OS GUI.

For Cisco Unity Connection Tomcat certificate, use Unity Connection OS GUI.

3.

4.

5.

2.

Generate a certificate signing request (CSR) for the desired certificate. Make sure to always set distribution to Multi-Server (SAN).

Download the CSR.

Obtain a CA signed certificate from the trusted CA for the generated CSR.

On the OS administration GUI from step 1, upload the obtained CA issued certificate.

Tip

A single multi-server certificate signing request should be generated for all certificates so that only a single certificate of a given type is required per cluster.

Tip

Make sure that the X.509 key usage and X.509 extended key usage in the issued certificate match the request in the CSR (see

Table 2-3

).

2-16

Cisco Preferred Architecture for Enterprise Collaboration 10.x

January 22, 2015

Chapter 2 Call Control

Deployment Overview

As mentioned above, it is important to make sure that certificates issued by the CA have the required key usage and extended key usage. A typical problem is that the CA issuing the certificate based on the provided CSR does not simply issue a certificate with the key usage and extended key usage copied from the CSR, but instead sets the key usage and extended key usage of the issued certificate based on settings in a template selected for issuing the certificate. A certificate issued based on a typical Web Server template, for example, will not have the TLS Web Client Authentication extended key usage include.

This creates problems with inter-server communications – for example, Intercluster Lookup Service

(ILS) and User Data Store (UDS) – where the Tomcat certificate on the initiating side of the TLS connection is also used as a client certificate, and thus TLS connection setup fails due to the incorrect key usage (see the section

Consider UDS Certificate Requirements ).

Table 2-3 Key Usage Requirements for Tomcat and cup-xmpp Certificates

X.509 Key Usage

Digital Signature

Key Encipherment

Data Encipherment

Key Agreement

X.509 Extended Key Usage

TLS Web Server Authentication

TLS Web Client Authentication

IPSec End System

Initial Cisco Unified CM Configuration

Immediately after installing the Unified CM cluster, perform the following basic configuration tasks:

Node Name Configuration

Enterprise Parameter Settings

Service Activation

Service Parameter Settings

Node Name Configuration

To allow for correct certificate validation and to ensure that references to Unified CM cluster members can always be resolved correctly, set the node names under System/Server in the Unified CM administration GUI to fully qualified domain names (FQDNs) for all cluster members. To achieve this, navigate to System/Server in the Cisco Unified CM administration GUI and verify that all servers show up in the first column as FQDNs. Change the entries of servers showing up as only a hostname without a DNS domain, to FQDNs.

January 22, 2015

Cisco Preferred Architecture for Enterprise Collaboration 10.x

2-17

Chapter 2 Call Control

Deployment Overview

Enterprise Parameter Settings

Check and update the Enterprise Parameters listed in

Table 2-4

.

Table 2-4 Enterprise Parameters

Enterprise Parameter

Cluster ID

Description

Used to uniquely identify the Unified CM cluster in a number of intercluster features, including Intercluster Lookup Service (ILS) and intercluster call admission control

URLs used by endpoints for various purposes

Value

Example: USCluster

URL Authentication

URL Directories

URL Information

URL Services

Secured Authentication URL

Secured Directory URL

Secured Information URL

Make sure these URLs refer to the FQDN of the

Unified CM publisher node

Secured Services URL

Auto Registration Phone

Protocol

BLF For Call Lists

Signaling protocol provisioned for auto-registering phones SIP

Specifies whether call lists in phones supporting this feature should show presence

Enabled

Allows G.722 between compatible devices Enabled Advertise G.722 Codec

URI Lookup Policy

Auto select DN on any

Partition

Enable Dependency Records

Organization Top Level

Domain

According to RFC 3261, when determining SIP URI equivalence, the check on the left-hand side (user portion) of the URI has to be case-sensitive. The default behavior of Unified CM is to adhere to this standard, but to avoid potential issues with URIs using mixed capitalization, it is typically better to change the default.

Simplifies administration. If enabled, the directory number configuration page automatically gets populated with the data of the first matching directory number.

Case Insensitive

True

Dependency records simplify the administration of Unified CM.

True

Example: ent-pa.com

Cluster Fully Qualified

Domain Name

CDR File Time Interval

When routing numeric SIP URIs, Unified CM considers SIP URIs with the right-hand side (host portion) of the URI matching the configured Cluster Fully Qualified Domain Name (CFQDN) as destinations to be routed according to the configured local numeric dial plan. If no match is found for the numeric left-hand side of the

URI in the configured numeric dial plan, then Unified CM rejects the call. For more details, see the section on Routing of SIP Requests

in Unified CM in the

Dial Plan

chapter of the

Cisco Collaboration

System 10.x SRND

.

Space-separated list of all Unified CM call processing nodes in the cluster.

Example: us-cm-sub1.ent-pa.com us-cm-sub2.ent-pa.com

Determines the time interval for call detail record (CDR) file updates

10

2-18

Cisco Preferred Architecture for Enterprise Collaboration 10.x

January 22, 2015

Chapter 2 Call Control

Deployment Overview

Service Activation

Table 2-5

summarizes the services to be activated on the Unified CM publisher node, the dedicated

Unified CM TFTP server subscriber nodes, and the Unified CM call processing subscriber nodes.

Table 2-5 Unified CM Node Service Activation

Service

CM Services

Cisco CallManager

Cisco IP Voice Media Streaming App

Cisco CTIManager

Cisco Intercluster Lookup Service

Publisher

Yes

Cisco Location Bandwidth Manager

Cisco Dialed Number Analyzer Server

Cisco Dialed Number Analyzer

Yes

Yes

Cisco Tftp

CTI Services

Cisco WebDialer Web Service

Database and Admin Services

Cisco Bulk Provisioning Service

Cisco AXL Web Service

Performance and Monitoring Services

Cisco Serviceability Reporter

Cisco CallManager SNMP Service

Security Services

Cisco CTL Provider

Yes

Yes

Yes

Yes

Yes

Cisco Certificate Authority Proxy Function Yes

Directory Services

Cisco DirSync Yes

Dedicated TFTP Subscriber Call Processing Subscriber

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Table 2-6

lists the services to be activated on Cisco Unified CM IM and Presence publisher and subscriber nodes.

January 22, 2015

Cisco Preferred Architecture for Enterprise Collaboration 10.x

2-19

Chapter 2 Call Control

Deployment Overview

Table 2-6 Unified CM IM and Presence Node Service Activation

Service

Cisco AXL Web Service

Cisco Bulk Provisioning Service

Cisco Serviceability Reporter

Cisco SIP Proxy

Cisco Presence Engine

Cisco XCP Connection Manager

Cisco XCP Authentication Service

Publisher

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Subscriber

Yes

Yes

Yes

Yes

Yes

Service Parameter Settings

Some service parameters of the Cisco CallManager service are global in nature and need to be set only once in Unified CM Administration. lists the global service parameter settings for Cisco CallManager service are listed in

Table 2-7

.

Note

Only non-default Service Parameter and other configuration field values are specified in this document.

If a field configuration value is not mentioned, then the default value should be assumed.

Table 2-7 Global Service Parameters

Service Parameter

Apply Transformations On

Remote Number

T302 Timer

Automated Alternate

Routing Enable

Call Diagnostics Enabled

G.722 Codec Enabled

Required Field

Stop Routing on Q.931

Disconnect Cause Code

Value

True

5000

Enable AAR

Enable Only When CDR

Enabled Flag is True

Enabled to All Devices

Except Recording-Enabled

Devices

3 21 27 28 38 42 63

Description

Makes sure that calling party transformations are also applied mid-call; for example, if a call is transferred from one party to another.

Whenever a destination is dialed digit-by-digit and based on the numeric dial plan provisioned in Unified CM, no immediate deterministic decision can be made about which provisioned pattern has to be considered for the dialed destination. Because a potential longer match (could be variable length) exists, the T302 inter-digit timeout has to expire before Unified CM selects the best route and routes the call. The default of 15,000 milliseconds (ms) typically is too long.

This service parameter globally enables automated alternate routing (AAR).

This parameter determines whether call management records

(CMR), also called diagnostic records, are generated.

G.722 disabled on recording-enabled devices to avoid problems with G.722 not being supported by the recorder.

Allows Unified CM to stop hunting down the configured hunt list when receiving specific Q.850 cause codes.

2-20

Cisco Preferred Architecture for Enterprise Collaboration 10.x

January 22, 2015

Chapter 2 Call Control

Deployment Overview

Other service parameters of the Cisco CallManager service must be set explicitly as shown in

Table 2-8

for each Unified CM call processing node.

Table 2-8 Per-Node Service Parameters

Service Parameter

CDR Enabled Flag

CDR Log Calls with Zero

Duration Flag

Value

True

True

Description

This parameter enables the generation of call detail records (CDR).

This parameter enables or disables the logging of call detail records (CDRs) for calls that never connected or that lasted less than 1 second.

Digit Analysis Complexity TranslationAndAlternatePatternAnalysis This parameter specifies the amount of digit analysis information that CCM trace files will provide.

Other IM and Presence Settings

Previous sections discussed the IM and Presence service activation, certificates management, and the IM and Presence SIP trunk configuration. In addition to that, configure settings on IM and Presence servers:

Configure a Unified CM domain in the IM&P Cisco SIP Proxy Service Parameter.

In Cisco Unified CM IM and Presence Administration > Presence > Settings > Standard

Configuration:

Configure a Cluster ID value.

Enable availability sharing. If not enabled, users can view only their own availability status.

Check Enable ad-hoc presence subscriptions to turn on ad-hoc presence subscriptions for

Cisco Jabber users.

In Cisco Unified CM IM and Presence Administration > Presence > Routing > Settings:

Configure Proxy Server Settings: Enable Method/Event Routing Status

In Cisco Unified CM IM and Presence Administration > Messaging > Settings:

Enable instant messaging.

Also configure UC services for Jabber clients, as described in the section on

Jabber Provisioning .

Dial Plan Configuration

A structured, well-designed dial plan is essential to successful deployment of any call control system.

The design of an enterprise dial plan needs to cover these main areas:

Endpoint addressing

General numbering plan

Dialing habits

Routing

Classes of service

The recommended dial plan design follows the design approach documented in the

Dial Plan

chapter of the

Cisco Collaboration System 10.x SRND

.

Cisco Preferred Architecture for Enterprise Collaboration 10.x

January 22, 2015

2-21

Chapter 2 Call Control

Deployment Overview

Example Topology

For the purpose of this document, we assume a centralized call processing deployment serving three sites in the US: SJC, RCD, and RTP.

Table 2-9

provides the DID (direct inward dial) ranges for these sites.

Table 2-9 DID Ranges for Example Sites

Site

SJC

RCD

RTP

DID range

+1 408 555 4XXX

+1 972 555 5XXX

+1 919 555 1XXX

Endpoint Addressing

For endpoints with DID addresses, directory numbers are provisioned as full +E.164 numbers, where

+E.164 represents a leading "+" followed by the full global E.164 phone number. To provision a +E.164 directory number in Unified CM, the leading "+" has to be escaped; for example, extension 4001 in SJC would have to be provisioned as \+14085554001.

Some endpoints will not have DIDs because not enough DIDs are available from the provider or because the associated devices do not need to be reachable from the PSTN (for example, lobby phones). For these endpoints no DIDs (E.164 numbers) exist, and thus an address format other than +E.164 is required for these endpoints.

Addressing Enterprise Services for External Access

Some services have assigned PSTN numbers. An example of this might be a voicemail pilot number that has to be reachable from the outside to enable users to call into voicemail from the PSTN. PSTN E.164 numbers for these services have to be reserved from the DID ranges assigned by the PSTN providers.

General Numbering Plan

In addition to endpoints with associated DIDs for which +E.164 addresses can be used, a number of additional destinations exist for which no DIDs exist:

Lobby phones

Regular endpoints for which no DIDs could be assigned by the provider

Services (call pickup numbers, call park numbers, conferences, and so forth)

In this document we refer to these types of destinations as non-DIDs.

Addresses for these non-DIDs, similar to +E.164 addresses, must be unique system-wide to avoid site-specific partitions for non-DIDs. The recommended solution is to introduce an enterprise specific numbering (ESN) schema for all non-DIDs. This ESN schema follows the structure of typical abbreviated inter-site dialing:

Access-code

A single-digit access code for abbreviated inter-site dialing. In the design phase, choose the access code so that there is no overlap with any other enterprise dialing habit (see below).

2-22

Cisco Preferred Architecture for Enterprise Collaboration 10.x

January 22, 2015

Chapter 2 Call Control

Deployment Overview

Site-code

A digit sequence uniquely identifying a site in the network. In the design phase, choose the length of the site code so that it not only covers all existing sites, but also allows for growth.

Extension

A digit sequence uniquely identifying the respective entity within the site.

In this document we use 8 as the access-code for abbreviated inter-site dialing, and thus all ESNs start with 8 and use a three-digit site code and a four-digit extension.

Table 2-10

indicates an ESN range for the DID and non-DID numbers for each site in our example.

Table 2-10

Site

SJC

RCD

RTP

ESN Ranges for DIDs and Non-DIDs

+E.164 Range

+1 408 555 4XXX

+1 972 555 5XXX

+1 919 555 1XXX

Site Code

140

197

191

ESN Range for DIDs

8-140-4XXX

8-197-5XXX

8-191-1XXX

ESN Range for Non-DIDs

8-140-5XXX

8-197-6XXX

8-191-2XXX

The plan is to use the same site code for DIDs and non-DIDs, but the first digit of the extension for non-DIDs is different from the first digit of the DID extensions. This also allows for abbreviated four-digit intra-site dialing to non-DIDs and DIDs.

While the ESN ranges in

Table 2-10 leave room in the ESN plan for site-specific numbers, there is also

a requirement to assign number ranges for non-site-specific services such as, for example, scheduled conferences.

Table 2-11

shows an example of how this requirement can be addressed by reserving a dedicated site code (in this case 099).

Table 2-11

ESN Range

8099[12]XXX

ESN Ranges for Conferences

Usage

Scheduled conferences

Dialing Habits

Dialing habits describe what end users must dial to reach various types of destinations. Dialing habits can first be classified as numeric dialing (for example, 914085550123) or alphanumeric dialing (for example, [email protected]).

In this design, in addition to alpha URI dialing, the numeric dialing habits shown in

Table 2-12 are

supported.

January 22, 2015

Cisco Preferred Architecture for Enterprise Collaboration 10.x

2-23

Chapter 2 Call Control

Deployment Overview

Table 2-12 Supported Numeric Dialing Habits

Dialed Pattern

XXXX

+E.164

Access code–site code–extension

*E.164

91-<10 digits>

9011-<E.164 number>

Example (site SJC)

4001 (DID)

5001 (non-DID)

+14085554001 (on-net, SJC)

+19195551001 (on-net, RTP)

+1212551001 (off-net)

8-140-4001 (DID, SJC)

8-140-5001 (non-DID, SJC)

8-191-1001 (DID, RTP)

8-191-2001 (non-DID, RTP)

*12125551567

914085554001 (on-net, SJC)

919195551001 (on-net, RTP)

912125551001 (off-net)

90114961007739764

Type of Destination

Abbreviated intra-site dialing to reach a destination at the same site.

The called destination can be a DID, a non-DID, or a service number.

Full +E.164 dialing for example from directories. The dialed destination can be on-net or off-net. The implemented dial plan makes sure that calls to on-net destinations dialed as +E.164 are routed on-net.

Non-DIDs obviously cannot be called as +E.164.

Abbreviated inter-site dialing to reach a destination at the same site or a different site. The called destination can be a DID, a non-DID, or a service number. The access code (8 in the example) has to be selected so that it does not overlap with any other dialing habit; for example any abbreviated intra-site dialing: access code

8 for inter-site dialing prohibits four digit intra-site dialing starting with 8.

Dialing of a video call through dedicated video ISDN gateways. The * is used to create a specific dialing habit with no overlap to any other numeric(!) dialing habit.

To avoid the use of * also a number area starting with the abbreviated inter-site access code 8 can be used: for example 8000-<E.164>.

US specific habitual PSTN dialing of national destinations. The implemented dial plan ensures that if the dialed destination is on-net then the call is routed on-net.

US specific habitual PSTN dialing of international destinations. The implemented dial plan makes sure that if the dialed destination is on-net then the call is routed on-net.

In general, using fewer supported dialing habits simplifies the design. Starting the design process with an overview of all dialing habits makes sure that overlaps between any two dialing habits leading to inter-digit timeouts are detected and can be resolved before starting the dial plan deployment.

+E.164 Routing and Dialing Normalization

To achieve the intended forced on-net routing (calls to any on-net destination dialed using any of the supported numeric dialing habits has to be routed on-net), the recommended dial plan design uses a two-step routing approach. In the first step, the dialed digit string is normalized to +E.164, if possible

(calls to non-DIDs obviously cannot be normalized to +E.164), and then in the second step the resulting

+E.164 digit string is matched against a +E.164 numeric plan that includes directory numbers and route patterns.

2-24

Cisco Preferred Architecture for Enterprise Collaboration 10.x

January 22, 2015

Chapter 2 Call Control

Deployment Overview

The dialing normalization is achieved by provisioning translation patterns matching on the non+E.164 dial strings, and then the dialed string is transformed to +E.164 through the called party transformations on the translation patterns.

Figure 2-7 shows an example of a dialing normalization translation pattern that can be used to normalize

abbreviated intra-site dialing in SJC to the full +E.164 number of the dialed destination. If a user in site

SJC dials 4001, this dialed string is matched by a translation pattern 4XXX and the called party transformation mask configured on the translation pattern, when applied to 4001, creates the resulting digit string +14085554001, which then can be routed in a +E.164 routing schema.

Figure 2-7 Example Dialing Normalization Translation Pattern

Partitions

After applying the called party transformations defined on a translation pattern, Unified CM then executes a secondary lookup of the resulting digit string using the calling search space (CSS) defined on the translation pattern. Unified CM enables definition of translation patterns that use the originator's

CSS for this secondary lookup. This allows definition of dialing normalization translation patterns that can be reused in multiple context, because after applying the dialing normalization, the secondary lookup of the normalized digit string is executed, not based on a single fixed CSS, but based on the CSS in effect when the translation pattern was engaged.

Tip

On dialing normalization translation patterns, set the option Use Originator's Calling Search Space so that the CSS used for the secondary lookup is identical to the CSS used for the primary lookup.

Partitions and CSSs are the fundamental components in Unified CM used to build classes of service.

Dialable patterns are grouped into equivalence classes by putting patterns belonging to the same class into the same partition. Each CSS then is a list of partitions that defines which partitions and, thus, patterns a calling entity using the CSS can access.

When defining the partitions and CSSs provisioned to build an enterprise dial plan, one goal is to avoid replication of duplicate configuration as much as possible. Following this maxim,

Table 2-13

shows the global (that is, not site or country specific) partitions required.

January 22, 2015

Cisco Preferred Architecture for Enterprise Collaboration 10.x

2-25

Chapter 2 Call Control

Deployment Overview

Table 2-13

Partition

DN

ESN

URI onNetRemote

B2B_URI

Directory URI

Global Partitions

PSTNInternational

Description

Holds all +E.164 directory numbers and other local on-net +E.164 destinations (for example, pilot numbers reachable from the PSTN). All

+E.164 patterns are provisioned as urgent patterns.

Holds all Enterprise Specific Numbers (ESNs). This includes ESN directory numbers (for example, for non-DID phones) as well as dialing normalization translation patterns transforming from abbreviated inter-site dialing of DIDs to +E.164.

Holds +E.164 route patterns required to provide PSTN access to international destinations.

Holds manually provisioned URIs.

Holds all patterns of remote on-net destinations. In environments with multiple Unified CM clusters, this includes all remote number ranges learned via Global Dial Plan Replication (GDPR).

Holds SIP route patterns required for business-to-business (B2B) URI dialing through the Internet.

System Partition where all auto-generated URIs are put. This partition does not need to be created. It is listed here for reference to introduce the partition, which is used again later in this document.

All of the partitions

Table 2-13 except the Directory URI partition must be created. In addition to the

pattern classes represented by these global partitions, several site, country, or class-of-service specific pattern classes are required, as show in

Table 2-14 .

Table 2-14

USToE164

Country or Site Specific Partitions

Partition

USPSTNNational

Description

Holds +E.164 route patterns required to provide PSTN access to national destinations in the US. To support other countries, and thus other country-specific dialing habits, a country appropriate xxPSTNNational partition (where xx represents the country; for example, DEPSTNNational,

UKPSTNNational, ITPSTNNational) also needs to be provisioned, which then holds the +E.164 route patterns required to provide PSTN access to national destinations of that country.

The reason we differentiate between international PSTN access (see

Table 2-13 ) and national PSTN access is that we need to be able to build

differentiated classes of service allowing calls to reach national only, or national and international destinations.

Holds dialing normalization translation patterns to transform US specific habitual PSTN dialing (for example, 91-<10 digits>) to +E.164. To support other countries, and thus other country-specific dialing habits, a country appropriate xxToE164 partition (where xx represents the country; for example, DEToE164, UKToE164, ITToE164) also needs to be provisioned, which then holds the dialing normalization translation patterns required to transform the country specific habitual PSTN dialing to +E.164.

2-26

Cisco Preferred Architecture for Enterprise Collaboration 10.x

January 22, 2015

Chapter 2 Call Control

Deployment Overview

Table 2-14

Partition

USEmergency

USPhLocalize

<site>Intra

Country or Site Specific Partitions (continued)

<site>PhLocalize

Description

Holds route patterns required to provide access to emergency calls using the

US specific emergency dialing habits.

Holds calling party transformation patterns to localize +E.164 calling party numbers for abbreviated display on phones in the US.

Site-specific intra-site dialing. For example: SJCIntra. Holds dialing normalization patterns to transform site-specific abbreviated intra-site dialing to DIDs, or non-DIDs to +E164 or ESN, respectively.

Site-specific. For example: SJCPhLocalize. Holds calling party transformation patterns to localize +E.164 calling party numbers for abbreviated display on phones in a given site.

As emergency calls are placed using country specific dialing habits, partition USEmergency with the route patterns enabling the US dialing habit for emergency calls also is country specific. To also support other dialing domains (countries), the equivalent partitions for these other dialing domains (for example,

DEEmergency, ITEmergency, DEPhLocalize, ITPHLocalize, for Germany and Italy respectively) would need to be created.

Dialing Normalization Translation Patterns

Table 2-15

summarizes which dialing normalization translation patterns need to be provisioned using the partitions from the previous section. All dialing normalization translation patterns are provisioned as urgent patterns and have Use Originator's Calling Search Space set as described in section on

+E.164

Routing and Dialing Normalization so that, after applying the called party transformation defined in the

dialing normalization translation pattern, the original CSS is used to find the final match for the dialed destination.

Table 2-15

Partition

ESN

ESN

ESN

SJCIntra

SJCIntra

RCDIntra

RCDIntra

RTPIntra

Summary of Dialing Normalization Translation Patterns

Pattern

81404XXX

81975XXX

81911XXX

4XXX

Called Party

Transformation Mask

+14085554XXX

+19725555XXX

+19195551XXX

+14085554XXX

5XXX

5XXX

6XXX

1XXX

81405XXX

+14085554XXX

81976XXX

+19195551XXX

Note

Abbreviated inter-site dialing to site SJC

Abbreviated inter-site dialing to site RCD

Abbreviated inter-site dialing to site RTP

Abbreviated intra-site dialing in site SJC to DID in

SJC

Abbreviated intra-site dialing in site SJC to non-DID in SJC

Abbreviated intra-site dialing in site RCD to DID in

RCD

Abbreviated intra-site dialing in site RCD to non-DID in RCD

Abbreviated intra-site dialing in site RTP to DID in

RTP

January 22, 2015

Cisco Preferred Architecture for Enterprise Collaboration 10.x

2-27

Chapter 2 Call Control

Deployment Overview

Table 2-15

Partition

RTPIntra

UStoE164

UStoE164

UStoE164

Summary of Dialing Normalization Translation Patterns (continued)

Pattern

9011.!#

Called Party

Transformation Mask Note

2XXX 81912XXX

9.1[2-9]XX[2-9]XXXXXX No Mask, strip pre-dot, prefix +

Abbreviated intra-site dialing in site RTP to non-DID in RTP

US specific habitual PSTN dialing to national destinations in the US

No Mask, strip pre-dot, prefix +

US specific habitual PSTN dialing to national destinations in the US.

9011.!

Note

The trailing "#" is not stripped on the dialing normalization translation pattern. This allows for a secondary match on a variable-length

PSTN route pattern with trailing #.

No Mask, strip pre-dot, prefix +

US specific habitual PSTN dialing to national destinations in the US

Table 2-16

Partition

DEtoE164

DEtoE164

DEtoE164

DEtoE164

ITtoE164

ITtoE164

ITtoE164

ITtoE164

For dialing domains other than the US, other country specific dialing normalization translation patterns must be defined if the installation has to support those country specific dialing habits.

Table 2-16 shows

the required dialing normalization for Germany (DE) and Italy (IT) as examples.

Dialing Normalization for Germany and Italy

Pattern

000.!

000.!#

00.[^0]!

00.[^0]!#

000.!

000.!#

0.0[^0]!

0.0[^0]!#

Called Party Transformation Note

strip pre-dot, prefix + strip pre-dot, prefix + strip pre-dot, prefix +49 strip pre-dot, prefix +49 strip pre-dot, prefix + strip pre-dot, prefix + strip pre-dot, prefix +39 strip pre-dot, prefix +39

Germany: international call (000-E.164).

Germany: international call (000-E.164).

Note

The trailing "#" is not stripped on the dialing normalization translation pattern. This allows for a secondary match on a variable-length PSTN route pattern with trailing #.

Germany: national call (00-national significant number).

Note

The numbering plan in Germany is variable length and this pattern needs to cover this.

Germany: national call (00-national significant number).

Italy: international call (000-E.164).

Italy: international call (000-E.164)

Note

The trailing "#" is not stripped on the dialing normalization translation pattern. This allows for a secondary match on a variable-length PSTN route pattern with trailing #.

Italy: national call (0-national significant number (NSN) where

NSN starts with 0).

Note

The numbering plan in Italy is variable length and this pattern needs to cover this.

Italy: national call (0-NSN where NSN starts with 0).

2-28

Cisco Preferred Architecture for Enterprise Collaboration 10.x

January 22, 2015

Chapter 2 Call Control

Table 2-16

Partition

ITtoE164

ITtoE164

Deployment Overview

Dialing Normalization for Germany and Italy (continued)

Pattern

0.[^0]!

0.[^0]!#

Called Party Transformation Note

strip pre-dot, prefix +39 strip pre-dot, prefix +39

Italy: national call (0-NSN where NSN does not start with 0).

Note

The numbering plan in Italy is variable length and this pattern needs to cover this.

Italy: national call (0-NSN where NSN does not start with 0).

The example in

Table 2-16

shows that in Italy and Germany the ITU recommended 0 is used to access a trunk from inside the enterprise, and then 0 and 00 are used for national and international access. Since

1998, geographic numbers in Italy start with 0, and digits 1 to 9 as the first digit of a national significant number indicate different types of numbers. Hence, dial strings starting with exactly two 0s (00) need to be treated differently in Italy than in Germany. In Italy the second zero has to be considered part of the

NSN and hence has to be kept in the resulting +E.164 digit string, while a second zero in Germany would need to be removed because geographic numbers in Germany do not start with a zero.

The example of the dialing normalization required for these two countries shows how country specific dialing habits can be modeled in the design approach presented.

For more information on international numbering plans, see the International Numbering Resources page of the ITU-T at http://www.itu.int/en/ITU-T/inr/Pages/default.aspx

. There you can find links to various resources, including E.164 country codes and national numbering plans. An overview of dialing procedures used in various countries can be found in Operational Bulletin No.994 (15.XII.2011) and

Annexed List: Dialling procedures (international prefix, national (trunk) prefix and national

(significant) number) (in accordance with ITU-T Recommendation E.164 (11/2010)) (Position on 15

December 2011), available at http://www.itu.int/pub/T-SP-OB.994-2011 . The actual list of dialing procedures starts at page 25 of that document and is also available for download at http://www.itu.int/dms_pub/itu-t/opb/sp/T-SP-E.164C-2011-PDF-E.pdf

.

Classes of Service and Calling Search Spaces (CSSs)

As mentioned before, a CSS is a list of partitions that defines which partitions, and thus patterns, a calling entity using the CSS can access. In this document we use a dial plan approach that uses only the line CSS to define class of service.

Table 2-17

lists the classes of service considered in this design. The classes of service chosen for this design are only examples. If further classes of services are required, then these can be defined equivalently.

Tip

The number of classes of service is one of the key parameters driving the complexity of enterprise dial plan designs. Therefore, it is good practice to define as few classes of service as possible for the dial plan.

The recommended design makes use of only the CSS provisioned on the line and does not use the device

CSS to define class of service. The device CSS can be used to implement general dialing habits that need to be available for everyone. An example for this is emergency calling; see the section on

Emergency

Call Considerations in Multi-National Environments for more details on when to use the device CSS to

implement emergency calls.

January 22, 2015

Cisco Preferred Architecture for Enterprise Collaboration 10.x

2-29

Chapter 2 Call Control

Deployment Overview

Table 2-17

Class of Service

International

National

Internal

Classes of Service

Access to

All on-net destinations

National PSTN destinations

International PSTN destinations

Business-to-business URI dialing

Emergency calls

All on-net destinations

National PSTN destinations

Emergency calls

All on-net destinations

Emergency calls

Adding business-to-business URI dialing to only the International class of service is an example based on the assumption that business-to-business (B2B) calls consume limited edge resources. Also we are trying to avoid increasing the number of classes of service by a factor of two by introducing classes of service International, InternationalB2B, National, NationalB2B, Internal, and InternalB2B.

Because only the line CSS is used to define both class of service and the set of dialing habits available to a given caller, a CSS needs to be provisioned per site and class of service.

Table 2-18 shows how class of service International for a user in site SJC would be defined based on the

partition set previously defined (see

Table 2-13 and Table 2-14 ).

Table 2-18 Class of Service International for SJC User

CSS Name

SJCInternational

Partitions

DN

Directory URI

URI

ESN onNetRemote

SJCIntra

UStoE164

USPSTNNational

PSTNInternational

B2B_URI

USEmergency

As depicted in

Table 2-19

, the remaining classes of service are created equivalently by selectively removing access to B2B URI dialing, international, and national PSTN destinations.

2-30

Cisco Preferred Architecture for Enterprise Collaboration 10.x

January 22, 2015

Chapter 2 Call Control

Deployment Overview

Table 2-19

CSS Name

SJCNational

Classes of Service National and Internal for SJC User

Partitions

DN

Directory URI

URI

ESN onNetRemote

SJCIntra

UStoE164

USPSTNNational

USEmergency

CSS Name

SJCInternal

Partitions

DN

Directory URI

URI

ESN onNetRemote

SJCIntra

UStoE164

USEmergency

CSSs for classes of services for users in other sites are created equivalent to the above CSSs, with the only difference being a different partition used with the site-specific dialing normalization patterns.

Table 2-20

shows an example of the RTP site National and Internal classes of service.

Table 2-20 Classes of Service National and Internal for RTP User

CSS Name

RTPNational

Partitions

DN

Directory URI

URI

ESN onNetRemote

RTPIntra

UStoE164

USPSTNNational

USEmergency

CSS Name

RTPInternal

Partitions

DN

Directory URI

URI

ESN onNetRemote

RTPIntra

UStoE164

USEmergency

These examples clearly show that the chosen partition scheme allows for optimal reuse of patterns and partitions when creating CSSs to implement classes of service for multiple sites.

For sites in other dialing domains (countries), the same CSS and partition schema as shown above can be used, with the only difference being that the dialing normalization partition for the specific dialing domain and the partition with the country specific route to national PSTN destinations would be used

instead of the US partitions used above. For example, Table 2-21 shows the CSS for class of service

International for a site FRA in Germany (DE).

January 22, 2015

Cisco Preferred Architecture for Enterprise Collaboration 10.x

2-31

Chapter 2 Call Control

Deployment Overview

Table 2-21 Class of Service International for Users in site FRA in Germany (DE)

CSS Name

FRAInternational

Partitions

DN

Directory URI

URI

ESN onNetRemote

FRAIntra

DEtoE164

DEPSTNNational

PSTNInternational

B2B_URI

DEEmergency

Special CSSs

In addition to classes of service for users, calling search spaces (CSSs) also are used to define classes of service for applications connected through trunks, such as Cisco Unity Connection, for example.

Assuming that Unity Connection should have access only to on-net destinations and that, in addition to

ESN and +E.164 dialing, also US dialing habits should be supported from Unity Connection,

Table 2-22

shows the CSS to implement this class of service.

Table 2-22 Class of Service for Voicemail

CSS Name

VoiceMail

Partitions

DN

ESN

URI onNetRemote

Directory URI

UStoE164

In scenarios where Cisco Unity Connection needs to serve multiple countries, then implementing the country specific dialing normalization as defined in partition UStoE164 in the above example is not an option. The only dialing habits that can be supported in that case are the globally significant dialing habits ESN and +E.164.

To use Unified CM presence, a subscribe CSS has to be provisioned, among other things, to allow access to all presentities that a presence user subscribes to. To allow for a very simple provisioning of

Unified CM presence without further differentiation of presence access, a single CSS needs to be

provisioned that allows access to all possible on-net destinations. Table 2-23 shows the settings for this

default subscribe CSS.

2-32

Cisco Preferred Architecture for Enterprise Collaboration 10.x

January 22, 2015

Chapter 2 Call Control

Deployment Overview

Table 2-23 Default Subscribe CSS

CSS Name

DefaultSubscribe

Partitions

DN

ESN

URI onNetRemote

Directory URI

This subscribe CSS ensures access to all types of on-net destinations.

Table 2-24

shows the (trivial) CSS "DN" to be used as the incoming CSS on PSTN trunks. To avoid loops, a PSTN trunk can address only +E.164 directory numbers. A PSTN trunk would not need access to ESN patterns, dialing normalization patterns, or URIs because only a single number format is supported by the PSTN, and this is normalized to +E.164 on ingress.

Table 2-24

CSS Name

DN

Inbound CSS for PSTN Gateways

Partitions

DN

Cisco TelePresence Servers and the TelePresence Conductor require access to all on-net destinations, and at the same time need to be able to place calls to any PSTN destination. On the other hand, they do not require access to any dialing domain-specific or site-specific dialing normalization patterns. CSS

TelePresenceConferencing shown in

Table 2-25 implements this class of service.

Table 2-25 Inbound CSS for Trunk from TelePresence Conferencing

CSS Name

TelePresenceConferencing

Partitions

DN

ESN

URI onNetRemote

Directory URI

PSTNInternational

Table 2-26

shows the CSS ICTInbound to be used as an incoming CSS on trunks to other Unified CM clusters. To avoid loops, the incoming CSS on these intercluster trunks should not provide access to remote on-net destinations (partition onNetRemote), but the trunks (inbound CSS) need to support all valid on-net addressing modes (+E.164, ESN, and URIs). Dialing normalization is not part of this CSS because dialing habits other than +E.164 and ESN would already have been normalized to +E.164 or

ESN on the remote Unified CM cluster prior to landing on the incoming intercluster trunk.

Table 2-26

CSS Name

ICTInbound

Inbound CSS for Trunks to Other Unified CM Clusters

Partitions

DN

ESN

URI

Directory URI

January 22, 2015

Cisco Preferred Architecture for Enterprise Collaboration 10.x

2-33

Chapter 2 Call Control

Deployment Overview

Local Route Groups for Call Type Specific Outbound Gateway Selection

To allow for flexible egress gateway selection based on the calling device, we recommend using local route groups (LRGs). Using LRGs for egress gateway selection avoids the need for site-specific route patterns. Route patterns using a local route group offer a unique characteristic: they allow for dynamic selection of the egress gateway based on the device originating the call. By contrast, calls routed by route patterns using static route groups will route the call to the same gateway, no matter which device originated the call. Route patterns configured to refer to a route list that makes use of LRGs will resolve to the actual route group configured as the LRG in the calling party's device pool.

To allow for differentiated LRG selection for different call types, set up multiple LRG names as shown in

Table 2-27 .

Table 2-27 Local Route Group Names

Local Route Group Name

LRG_PSTN_1

LRG_PSTN_2

LRG_VIDEO_1

LRG_VIDEO_2

LRG_Emergency_1

LRG_Emergency_2

Description

Local route group referring to primary PSTN resources to be used for PSTN calls

Local route group referring to secondary PSTN resources to be used for PSTN calls

Local route group referring to primary PSTN resources to be used for video PSTN calls

Local route group referring to secondary PSTN resources to be used for video PSTN calls

Local route group referring to primary PSTN resources to be used for emergency calls

Local route group referring to secondary PSTN resources to be used for emergency calls

With these LRG definitions, dedicated route lists can be created for both "normal" PSTN calls and emergency calls so that different PSTN resources (gateways) are used for emergency calls than for normal PSTN calls. This makes sense in scenarios where centralized PSTN resources are provisioned for normal PSTN calls, but emergency calls should still use dedicated small gateways local to the site to allow for local emergency call routing to the correct Public Safety Answering Point (PSAP).

The video LRGs are provisioned for video-enabled ISDN gateways and treat them as separate resources.

2-34

Cisco Preferred Architecture for Enterprise Collaboration 10.x

January 22, 2015

Chapter 2 Call Control

Deployment Overview

Route Lists Using Local Route Groups

Using the LRGs as defined in the previous section, route lists should be created as depicted in

Table 2-28

.

Table 2-28 Route List Definitions

Route List

RL_PSTN

RL_Emergency

RL_VIDEO

Members

LRG_PSTN_1

LRG_PSTN_1

Standard Local Route Group

LRG_Emergency_1

LRG_Emergency_2

LRG_PSTN_1

LRG_PSTN_1

Standard Local Route Group

LRG_VIDEO_1

LRG_VIDEO_2

LRG_PSTN_1

LRG_PSTN_2

Standard Local Route Group

Description

Normal PSTN calls should make use of the primary and secondary site-specific PSTN resources defined for normal PSTN calls. The last member, Standard Local Route Group, allows for fallback to PSTN resources not specific to a call type.

For emergency calls, the first call-specific resources for emergency calls should be used, then the second, then the PSTN resources defined for normal PSTN calls, and lastly the non-specific

PSTN resources.

For video calls, first the video-specific gateway resources are used, then the regular PSTN resources are considered as a fallback (audio only), and lastly the Standard Local Route Group is used if the others fail.

With the above LRG and route list definition on each device pool, up to seven route groups can be selected for the defined LRGs to allow for very specific outbound gateway selection. The actual PSTN resources to be used for certain call types are defined during device pool provisioning. If selecting different outbound PSTN resources based on call type is not required for a given set of devices, and only a single PSTN resource is needed for all call types, then it is sufficient to define only an actual route group for the Standard Local Route Group on the respective device pool and leave all other LRGs in that device pool set to <None>. Having Standard Local Route Group as the last entry in all route lists is a good way to achieve this.

Route Patterns for PSTN Access and Emergency Calls

PSTN access is achieved through PSTN route patterns. As described in the section about Classes of

Service and Calling Search Spaces (CSSs)

, the route to international destinations needs to be provisioned in the PSTNInternational partition, while national PSTN routes are provisioned in the dialing domain specific partitions xxPSTNNational (where xx represents dialing domain USPSTNNational, for example).

Table 2-29

shows the configured PSTN route patterns.

January 22, 2015

Cisco Preferred Architecture for Enterprise Collaboration 10.x

2-35

Chapter 2 Call Control

Deployment Overview

Table 2-29

Pattern

\+!

\+!#

911

9911

PSTN Route Patterns

\+1[2-9]XX[2-9]XXXXXX

Partition

PSTNInternational

PSTNInternational

USPSTNNational

USEmergency

USEmergency

Gateway or Route List Description

RL_PSTN Variable length to allow for dialing of arbitrary international destinations.

RL_PSTN Alternative pattern for international destinations to allow terminating variable length dialing with #.

RL_PSTN

Discard Digits set to Trailing-#

Explicit pattern for national destinations in the US.

RL_Emergency

RL_Emergency

Urgent Priority checked to avoid overlap with variable length PSTN route pattern

\+! defined for international destinations.

US emergency calling

Urgent Priority checked

US emergency calling

Urgent Priority checked

Apart from the route pattern settings explicitly shown in

Table 2-29

, all other settings are left with default values as shown in

Table 2-30

. This especially includes the calling, connected, and called party transformations, which are left empty (apart from stripping a trailing # as mentioned above) because the calling and called party transformations required to match the PSTN requirements are configured as explicit calling and called party transformations. This is described in the sections on

Outbound Calls:

Called and Calling Number Transformations on ISDN Gateways and

Outbound Calls: Called and Calling

Number Transformations on SIP Trunks

.

Table 2-30 Route Pattern Default Settings

Setting

Pattern Definition

Numbering Plan

Value

Route Filter

MLPP Precedence

-- Not Selected --

<None>

Default

Apply Call Blocking Percentage Unchecked

Resource Priority Namespace Network Domain <None>

Route Class

Route Option

Call Classification

External Call Control Profile

Default

Route this pattern

OffNet

<None>

Allow Device Override

Provide Outside Dial Tone

Allow Overlap Sending

Unchecked

Checked

Unchecked

2-36

Cisco Preferred Architecture for Enterprise Collaboration 10.x

January 22, 2015

Chapter 2 Call Control

Deployment Overview

Table 2-30 Route Pattern Default Settings (continued)

Setting

Require Forced Authorization Code

Authorization Level

Value

Unchecked

0

Require Client Matter Code

Calling Party Transformations

Unchecked

Use Calling Party's External Phone Number Mask Unchecked

Calling Party Transform Mask

Prefix Digits (Outgoing Calls)

Calling Line ID Presentation

Calling Name Presentation

Calling Party Number Type

Leave empty; do not enter any value

Leave empty; do not enter any value

Default

Default

Cisco CallManager

Cisco CallManager Calling Party Numbering Plan

Connected Party Transformations

Connected Line ID Presentation

Connected Name Presentation

Called Party Transformations

Discard Digits

Called Party Transform Mask

Prefix Digits (Outgoing Calls)

Called Party Number Type

Called Party Numbering Plan

ISDN Network-Specific Facilities Information Element

Network Service Protocol

Carrier Identification Code

Network Service

Default

Default

<None>

Leave empty; do not enter any value

Leave empty; do not enter any value

Cisco CallManager

Cisco CallManager

-- Not Selected --

Leave empty; do not enter any value

-- Not Selected --

While the international PSTN route patterns in partition PSTNInternational are not dialing domain

(country) specific, the route patterns in partitions USPSTNNational and USEmergency are country specific. If the dial plan needs to support other countries, then the route patterns for these countries need to be created as shown in

Table 2-31 .

January 22, 2015

Cisco Preferred Architecture for Enterprise Collaboration 10.x

2-37

Chapter 2 Call Control

Deployment Overview

Table 2-31

Pattern

\+49!

\+49!#

Non-US Route Patterns for National Destinations

\+33XXXXXXXXX

112

0112

112

0112

Partition

DEPSTNNational

DEPSTNNational

FRPSTNNational

DEEmergency

DEEmergency

FREmergency

FREmergency

Gateway or Route List

RL_PSTN

RL_PSTN

RL_PSTN

RL_Emergency

RL_Emergency

RL_Emergency

RL_Emergency

Description

Variable length because the German numbering plan with country code 49 is variable length.

Alternative pattern for national destinations to allow terminating variable length dialing with #.

Discard Digits set to Trailing-#

Explicit pattern for national destinations in

France.

Urgent Priority checked to avoid overlap with variable length PSTN route pattern \+! defined for international destinations.

German emergency calling

Urgent Priority checked

German emergency calling

Urgent Priority checked

French emergency calling

Urgent Priority checked

French emergency calling

Urgent Priority checked

Table 2-31 shows the difference between fixed and variable length numbering plans. The national

numbering plan in Germany is variable length and thus the route pattern to match on national destinations in Germany has to match on variable length digit strings, and we also need to provision an alternate route pattern ending on # to enable users to explicitly terminate dial strings with # to avoid inter-digit timeouts when dialing national destinations. In contrast to this, the national numbering plan in France is fixed length (as in the US), and thus a single urgent fixed-length route pattern is enough to cover all national numbers in France.

Because Germany and France use the same emergency dialing habit, the emergency routing can be simplified by combining both emergency partitions DEEmergency and FREmergency into a single partition 112Emergency and by using that partition instead in the CSS definitions.

Emergency Call Considerations in Multi-National Environments

Independent from individual classes of service, access to emergency numbers is required from all endpoints at all times. As shown previously, this is easily achieved by adding the partition with the emergency calling route patterns to all CSSs. This approach is problematic if multiple countries need to be supported, those countries require different emergency dialing habits, and mobility features such as extension mobility and device mobility are used.

In this case, if a user roams between countries with different emergency dialing habits, then the device this user is using inherits the emergency dialing habits specific to the visiting user. For example, if a user from Germany logs into a phone in the US, then the line CSS as defined on the German user's extension

2-38

Cisco Preferred Architecture for Enterprise Collaboration 10.x

January 22, 2015

Chapter 2 Call Control

Deployment Overview

mobility profile gets assigned to the visited phone in the US, so that on this phone emergency calls now need to be placed using the German emergency calling dialing 112, and the US emergency call dialing habit 911 is not supported any longer.

To make sure that phones in a given country always support the national emergency call dialing habit independent of whether a foreign user logged into the phone, a different approach for emergency calls can be implemented. Instead of adding the USEmergency to all CSSs, create a dedicated USEmergency

CSS and assign that CSS as the device CSS on all devices in the US. Then if a foreign user logs into a phone in the US, the visiting user's "home" dialing habits as defined by the line CSS will be combined with the visited countries emergency dialing habit. In the above case of a German user logging into a US phone, that user's German PSTN dialing habits will be supported together with the US specific emergency dialing habit 911. Keep in mind that this combination of dialing habits between different countries might create overlaps between the visited sites' emergency dialing and the visiting user's regular dialing habits. For example, if a site in Germany has four-digit extensions starting with 9 (such as +E.164 range +49 6100 773 9XXX), then the abbreviated four-digit intra-site dialing defined for that site through a 9XXX dialing normalization translation pattern creates an overlap with the US emergency dialing 911 if a user from that German site logs into a phone in the US. As long as the emergency dialing habit is more specific, then creating the emergency calling route pattern as urgent pattern makes sure that no delay is experienced when placing an emergency call. On the other hand, the 911 US emergency pattern would "block" all four-digit dialing starting with 911, affecting four-digit intra-site dialing to directory numbers +49 6100 773 911X, for example.

Moving the emergency dialing from the line to the device CSS also avoids the problem that visiting users' emergency dialing habits (112 in case of a user from Germany) need to be transformed to the visited countries emergency dialing habit (911 in the US).

Route Patterns for Video PSTN (ISDN) Calls

Video ISDN gateways require special treatment from the dial plan perspective because it is unfeasible from the cost perspective to use ISDN video gateways for regular voice calls. In this design the selection of video ISDN gateways is explicitly tied to a special video PSTN dialing habit (see

Table 2-12

).

Table 2-32

shows the required route patterns to enable this dialing habit.

Table 2-32

Pattern

*!

*!#

Route Patterns for Video PSTN (ISDN) Calls

*1XXXXXXXXXX

Partition

PSTNInternational

PSTNInternational

PSTNInternational

Gateway or Route List

RL_VIDEO

RL_VIDEO

RL_VIDEO

Description

Variable length because we need to support E.164 behind the *

Alternative pattern to allow termination of variable length dialing with #.

Discard Digits set to Trailing-#

Supplementary route pattern to allow dialing to

US destinations (fixed length) without inter-digit timeout.

Urgent Priority checked.

Putting the video ISDN route patterns into partition PSTNInternational effectively adds video dialing capabilities to class of service International.

January 22, 2015

Cisco Preferred Architecture for Enterprise Collaboration 10.x

2-39

Chapter 2 Call Control

Deployment Overview

Outbound Calls: Called and Calling Number Transformations on ISDN Gateways

The dial plan design presented in this document uses local route groups for egress gateway selection based on the calling device. Hence, calling and called party transformations required to adapt to service provider requirements cannot be done on the route pattern or route list level. These transformations would be shared between all gateways. Instead, these service provider specific calling and called party transformations are configured either on the gateway using Cisco IOS voice translation rules or on

Unified CM using calling and called party transformation patterns addressed by calling and called party transformation CSSs configured on the gateway or on the gateway's device pool.

On ISDN trunks, calling and called party number information is sent and received in calling and called party information elements. These information elements are a triplet consisting of numbering plan, number type, and number. How these fields need to be set depends on the trunk service definition of the provider. As an example, for a call to E.164 destination 4961007739764 on a trunk in Germany in the same area code 6100, the called party number in the outgoing ISDN SETUP message could be sent as

(plan/type/number) ISDN/national/61007739764, ISDN/subscriber/7739764, or unknown/unknown/061007739764.

If gateways terminating ISDN trunks are connected to Unified CM using SIP, then number types cannot be sent from Unified CM to the gateway because SIP does not know the concept of number types.

Whether different ISDN number types need to be supported for different call types depends on the provider's SIP trunk service definition. On ISDN trunks, some providers always allow called and calling party numbers independent of called destination to be sent using the same ISDN plan and type indication.

Table 2-33 shows an example of alternate called party number formats that an ISDN provider in the US

might accept.

Table 2-33

Type of Call

National

International

Alternate ISDN Number Format for Calls on US ISDN Trunk

Destination

+12125551234

+4961007739764

Called Party Plan/Type/Number to Be Sent to PSTN

unknown/unknown/12125551234 unknown/unknown/0114961007739764

Digit String Sent to Gateway

*12125551234

*0114961007739764

The digit string sent to the gateway is prefixed with a "*" to simplify the dial peer definition on the gateway. Prefixing called party numbers sent to the gateway with a "*" enables easy non-colliding destination-pattern based outbound dial-peer selection on the gateway for inbound and outbound calls because called party numbers received from the PSTN never start with a "*". The leading "*" prefixed by Unified CM needs to be removed on the gateway before sending the call to the PSTN. The leading

"*" on all called party numbers sent from Unified CM to the gateway allows the use of

"destination-pattern *" on the POTS dial peers on the gateway. The default digit stripping behavior of

Cisco IOS will then automatically strip the leading "*".

The transformation from the called +E.164 destination to the digit string to be sent to the PSTN can be achieved on Unified CM, and on the gateway the ISDN plan and type can be enforced easily using

Cisco IOS voice translation rules as shown in

Example 2-2

.

2-40

Cisco Preferred Architecture for Enterprise Collaboration 10.x

January 22, 2015

Chapter 2 Call Control

Example 2-2 Cisco IOS Voice Translations to Force Single ISDN Plan and Type

voice translation-rule 1 rule 1 /^\*/ // type any unknown plan any unknown rule 2 // // type any unknown plan any unknown voice translation-profile ISDNunknown translate called 1 translate calling 1 dial-peer voice 1 pots translation-profile outgoing ISDNunknown

Deployment Overview

Table 2-34

Pattern

\+.1!

\+.!

The Cisco IOS configuration piece shown in

Example 2-2

demonstrates how to force a single ISDN plan and type for calling and called party information to be sent to the PSTN through a given POTS dial-peer.

Rule 1 of voice-translation-rule 1 matches all numbers starting with "*" and simply removes this leading

"*". Rule 2 of voice translation-rule 1 matches on all numbers with any plan and type, and it forces both plan and type to unknown while not changing the actual digit string of the number. With this Cisco IOS voice translation-rule applied to the POTS dial peer pointing to the ISDN, all called and calling party numbers sent from Unified CM to the gateway will be forwarded to the PSTN unchanged, with plan and type forced to unknown.

With this translation logic in place on the gateway, the piece that still needs to be provisioned on

Unified CM is the transformation of the +E.164 called party information to the digit string to be sent to the PSTN according to

Table 2-33

. Table 24 depicts the required called party transformation patterns for localizing +E.164 for ISDN dialing.

Called Party Transformation Patterns to Localize +E.164 for ISDN via SIP

Partition

USGWLocalizeCd

USGWLocalizeCd

Transformation

Strip pre-dot, prefix *

Description

+12125551234 –> *12125551234

Strip pre-dot, prefix *011 +4961007739764 –> *0114961007739764

To apply the called party transformations defined by the called party transformation patterns shown in

Table 2-34

to a gateway, a CSS USGWLocalizeCd with only partition USGWLocalizeCd in it needs to be defined, and this CSS is then set as Called Party Transformation CSS in the Device Mobility

Related Information section on the gateway's device pool. Configuring these transformations on the device pool enables sharing the same settings with multiple gateways in the same site sharing the same called party transformation requirements. To achieve this, the Use Device Pool Called Party

Transformation CSS option needs to be checked in the Outbound Calls section on the gateway configuration page.

Also, we need to provision the transformation required to force the calling party number from +E.164 to whatever needs to be sent to the service provider. Here we need to consider how to treat calling party information for a call originating from a non-DID or a call originating from a DN that is not part of the

DID range associated with the given gateway. The most common option is to set the caller ID to a site-specific main extension. This site specificity requires creation of site-specific calling party transformations as illustrated by

Table 2-35 .

January 22, 2015

Cisco Preferred Architecture for Enterprise Collaboration 10.x

2-41

Chapter 2 Call Control

Deployment Overview

Table 2-35 Calling Party Transformation Patterns to Localize +E.164 for ISDN via SIP

Pattern

\+.19195551XXX

\+!

!

Partition

RTPGWLocalizeCn

RTPGWLocalizeCn

RTPGWLocalizeCn

Transformation

Strip pre-dot

Mask 19195551888

Mask 19195551888

Description

+19195551001 –> 19195551001

Forward caller ID from the DID range associated with the gateway, but strip the leading plus (+), assuming that the calling party number can be sent to the provider as

1 plus 10 digits

Force everything to 19195551888

Force everything to 19195551888

The calling party transformation patterns in

Table 2-35

perform the required transformations that make sure any calling party number, whether in the form of a +E.164 number or an enterprise specific number not matching the trunks DN range, is forced to a main number (19195551888).

To enable these transformations equivalent to the above method to apply outbound called party transformations, a CSS RTPGWLocalizeCn needs to be created using only partition

RTPGWLocalizeCn, and this CSS needs to be applied as the calling party transformation CSS in the

Outbound Calls section on the gateway configuration page or in the Device Mobility Related

Information section on the gateway's device pool.

If a specific called or calling party transformation is needed per gateway, then using the device pool level settings for the called party transformations is overly complicated. In that case uncheck the Use Device

Pool Called/Calling Party Transformation CSS options in the Outbound Calls section on the gateway configuration page, and set the called or calling party transformation CSS there.

Outbound Calls: Called and Calling Number Transformations on SIP Trunks

As mentioned earlier, SIP does not have the concept of "typed" numbers. Usually on SIP trunks all called and calling party numbers need to be sent in a single format independent of the type of called destination.

The most common options are +E.164 or E.164. To enable easier dial-peer configuration with non-overlapping destination patterns for inbound and outbound calls, again we want to prefix all E.164 called party information with "*" when sent to the Cisco Unified Border Element terminating the SIP trunk.

If E.164 needs to be sent (without the +), then the above approach using called party transformation patterns can be reused. The single called party transformation shown in

Table 2-36

is enough to make sure that the leading + of all +E.164 numbers gets stripped. Again we also need to create a CSS (for example, GWNoPlus) that addresses only partition GWNoPlus, and then apply this called party transformation pattern as Called Party Transformation CSS on either the gateway or the gateway's device pool.

Table 2-36

Pattern

\+.!

Called Party Transformation Pattern to Localize +E.164 to *E.164 for SIP

Partition

GWNoPlus

Transformation Description

Strip pre-dot, prefix * +4961007739764 –> *4961007739764

+12125551234 –> *12125551234

2-42

Cisco Preferred Architecture for Enterprise Collaboration 10.x

January 22, 2015

Chapter 2 Call Control

Deployment Overview

Even if no format transformation is required for calling party information sent on a SIP trunk, some filtering still needs to be applied to the calling party information to make sure that only valid numbers are sent to the provider. The same calling party transformations as described before in section on

Outbound Calls: Called and Calling Number Transformations on ISDN Gateways

and summarized in

Table 2-35

can be used. Cisco IOS voice translations on Cisco Unified Border Element then make sure that the calling party information is sent to the provider according to the format requirements of the provider.

Example 2-3 shows Cisco IOS voice translations to be applied on the VoIP dial-peer on the

Cisco Unified Border Element (CUBE) pointing to the provider. These translations transform called party information from *E.164 to +E.164 and the calling party information from E.164 to +E.164.

Example 2-3 Cisco IOS Voice Translations to Force +E.164 Calling and Called Party Number on CUBE

voice translation-rule 2 rule 1 /^\*/ /+/ rule 2 // /+/ voice translation-profile SIPtoE164 translate called 2 translate calling 2 dial-peer voice 2 voip translation-profile outgoing SIPtoE164

Rule 1 in

Example 2-3

replaces a leading "*" with a leading "+" while rule 2 just prefixes a "+" to all numbers.

Inbound Calls: Called and Calling Number Transformations on ISDN Gateways

Because all call routing on Unified CM is based on +E.164 for all incoming calls arriving at Unified CM, we need to make sure that called party information is transformed to +E.164 from the format received on the link from the provider. As mentioned earlier in the section on

Outbound Calls: Called and Calling

Number Transformations on ISDN Gateways , calling and called party information sent and received on

ISDN trunks is a triplet consisting of numbering plan, number type, and number. Because SIP does not support number types, the semantics of the number type as received from the provider is lost if only the actual number is forwarded by the gateway over the SIP trunk to Unified CM. To avoid this, Cisco IOS voice translation needs to be deployed on the gateway to create a +E.164 digit string to be sent to

Unified CM based on the received number plan, type, and number.

Example 2-4

shows the Cisco IOS voice translation configuration to achieve this.

Example 2-4 Cisco IOS Voice Translations to Map from ISDN to +E.164

voice translation-rule 3 rule 1 /^\(.+\)$/ /+1\1/ type national unknown plan any unknown rule 2 /^\(.+\)$/ /+\1/ type international unknown plan any unknown voice translation-profile ISDNtoE164 translate called 3 translate calling 3 dial-peer voice 1 pots translation-profile incoming ISDNtoE164

The Cisco IOS translation shown in

Example 2-4

assumes that we received called party information as type national and that the number in this case has only 10 digits. Rule 1 matches on any number

(/^\(.+\)$/) with type international and simply prefixes +1 (/+\1/) while forcing plan and type to unknown because both are irrelevant when forwarded on the SIP trunk to Unified CM. The same translation rule is applied to both calling and called party information in translation profile ISDNtoE164, so that the calling party information as a 10-digit number with type national will be transformed correctly to +E.164

January 22, 2015

Cisco Preferred Architecture for Enterprise Collaboration 10.x

2-43

Chapter 2 Call Control

Deployment Overview

by rule 1. Rule 2 does not really apply to received called party information because the provider will typically send called party information using only a single format. Hence, rule 2 is relevant only for calls received from international destinations for which we expect to receive calling party information as type international with the number set to the full E.164 number of the calling party.

Different number formats might be used, depending on the provider, and this will require use of different transformations on the gateway or on Unified CM. For a detailed explanation of voice translation rules, see the document on Number Translation using Voice Translation Profiles, available at http://www.cisco.com/c/en/us/support/docs/voice/call-routing-dial-plans/64020-number-voice-tran slation-profiles.html

If for some reason the same rules cannot be used for calling and called party information transformation, then separate voice translation rules need to be provisioned for calling and called party information and associated with translation of calling and called party information in one translation profile.

Using inbound Cisco IOS voice translation rules is required only if different number types are sent by the provider. If the number type for calling or called party information is always unknown, for example, then the digit transformation to globalized +E.164 can happen on Unified CM either by using the inbound prefixes for calling and called party information or by using calling and called party transformation CSSs. Both prefixes and calling and called party transformations can be defined either on the trunk level or on the device pool level. Keep in mind that, because SIP does not support different number types, inbound calling and called prefixes or CSSs need to be set for number type unknown if set on the device pool level.

Inbound Calls: Called and Calling Number Transformations on SIP Trunks

Inbound call number information treatment on PSTN SIP trunks is generally simpler than the number handling in the ISDN case described before. The main reason is that number information on SIP trunks is not typed, and thus transformations are less complex and need to consider only the received digit string. Typically both calling and called party information on a SIP trunk is already in +E.164 format, and thus no transformations are needed.

If calling and called parties are received in E.164 format, then the easiest way to transform to +E.164 is to simply configure a prefix "+" on the SIP trunk in Unified CM or on the trunk's device pool. This prefix can be configured in the Incoming Calling Party Settings or Incoming Called Party Settings on the trunk or the trunk's device pool. Remember that for SIP trunks the setting for number type Unknown Number is relevant on the device pool level.

Calling Party Information Display on Phones

Because all directory numbers are provisioned as +E.164 numbers for calls originating from these

+E.164 directory numbers, calling party information is in +E.164 format automatically. To simplify and provide consistent calling party presentation for all possible call flows, all calling party information received from outside networks such as the PSTN is normalized to +E.164 as discussed earlier. When a call is presented to a phone or to an outside network, the calling party information presented for that call sometimes needs to be transformed to the format expected by the network in case of the call being sent to a gateway or the format expected by the user in case of the call being sent to a phone.

Of special consideration are calls originating from phones with non-DIDs. In this case the only available calling party information is identical to the provisioned non-DID in the format of an enterprise specific number (ESN).

Table 2-10

summarizes the ESN ranges used in the example topology.

2-44

Cisco Preferred Architecture for Enterprise Collaboration 10.x

January 22, 2015

Chapter 2 Call Control

Deployment Overview

On phones, sometimes +E.164 is not the preferred calling party display information, although keeping this information as +E.164 simplifies the deployment and is preferred. In that case the desired format

typically depends on both the calling and called entities. Table 2-37

shows an example of the expected calling party display on a phone in site SJC for calls from various sources.

Table 2-37

Calling Entity "Native"

Calling Party Information

+12125551234

+14085554001

81405001

Expected Calling Party Display on SJC Phone

+4961007739764

Expected Display

912125551234

4001

5001

90114961007739764

Comment

Call from US; display follows PSTN dialing habit.

Call from +E.164 DN in the SJC DID range; display follows abbreviated intra-site dialing habit.

Call from non-DID in the SJC ESN range (see

Table 2-10 ); display follows abbreviated

four-digit intra-site dialing to non-DIDs in site

SJC.

Call from international PSTN destination; display follows US PSTN dialing habit for international destinations.

To achieve the display format depicted in

Table 2-37 , calling party transformation patterns need to be

provisioned in adequate partitions, and calling party transformation CSSs based on these partitions have to be configured on the phones, to enable the transformations.

Table 28 summarizes all calling party transformation patterns that must be provisioned to achieve the abbreviated calling party number display shown in

Table 2-37

for all US sites based on the number ranges shown in

Table 2-10 .

Table 2-38

Pattern

\+.1!

\+.!

\+14085554XXX

81405XXX

\+19725555XXX

81976XXX

Phone Localization Calling Party Transformation Patterns

Partition

USPhLocalize

USPhLocalize

SJCPhLocalize

SJCPhLocalize

RCDPhLocalize

RCDPhLocalize

Transformation

Strip pre-dot, prefix 9 Any US destination:

Strip pre-dot, prefix

9011

Mask 4XXX

Mask 5XXX

Mask 5XXX

Mask 6XXX

Description

+12125551234 –> 912125551234

Any international destination:

+4961007739764 –> 90114961007739764

Call from local DN range:

+14085554001 –> 4001

Call from local non-DID range:

81405001 –> 5001

Call from local DN range:

+19725555001 –> 5001

Call from local non-DID range:

81976001 –> 6001

January 22, 2015

Cisco Preferred Architecture for Enterprise Collaboration 10.x

2-45

Chapter 2 Call Control

Deployment Overview

Table 2-38

Pattern

\+19195551XXX

81912XXX

Phone Localization Calling Party Transformation Patterns (continued)

Partition

RTPPhLocalize

RTPPhLocalize

Transformation

Mask 1XXX

Mask 2XXX

Description

Call from local DN range:

+19195551001 –> 1001

Call from local non-DID range:

81912001 –> 2001

Table 2-40

Pattern

\+49.!

\+.!

\+39.!

\+.!

Table 2-39 shows the calling party transformation CSSs to enable calling party localization for phones

in all US sites. The schema allows the reuse of dialing domain (country) specific calling party localization transformation patterns for all sites in that dialing domain (country). The country specific calling party localization patterns basically map national and international numbers to the country specific national and international dialing habit.

Table 2-39

CSS

SJCPhLocalize

RCDPhLocalize

RTPPhLocalize

Phone Localization Calling Party Transformation CSSs for US Sites

Partitions

SJCPhLocalize

USPhLocalize

RCDPhLocalize

USPhLocalize

RTPPhLocalize

USPhLocalize

Table 2-40 shows an example of the country specific phone localization calling party transformation

patterns that would need to be provisioned for Italy and Germany.

Phone Localization Calling Party Transformation Patterns for Italy and Germany

Partition

DEPhLocalize

DEPhLocalize

ITPhLocalize

ITPhLocalize

Transformation

Strip pre-dot, prefix 00

Description

Any German destination:

+4941001234 –> 0041001234

Strip pre-dot, prefix 000 Any international destination:

+14085551234 –> 00014085551234

Strip pre-dot, prefix 0 Any Italian destination:

+390730123456 –> 00730123456

+393012345678 –> 03012345678

Strip pre-dot, prefix 000 Any international destination:

+14085551234 –> 00014085551234

2-46

Cisco Preferred Architecture for Enterprise Collaboration 10.x

January 22, 2015

Chapter 2 Call Control

Deployment Overview

Automated Alternate Routing

If a call to a registered endpoint fails due to insufficient bandwidth (call admission control fails) then automated alternate routing (AAR) allows to reroute the call to the PSTN. The following steps need to be taken to activate AAR:

Set the Automated Alternate Routing Enable service parameter (see the section on Service

Parameter Settings ).

Configure a single AAR group Default without any Dial Prefix (default).

Define a CSS PSTNReroute with access only to +E.164 PSTN route patterns. Based on the examples in this design, this CSS would need to include only partition PSTNInternational.

On all endpoints, trunks, and other devices initiating calls that potentially might be subject to AAR:

Set the AAR Calling Search Space to PSTNReroute.

Set AAR Group to Default.

On all device pools, set the AAR Calling Search Space to PSTNReroute.

On all device pools, set AAR Group to Default

On +E.164 directory numbers, configure the AAR masks so that the resulting number is the +E.164 number of the directory number. In a country with a fixed length numbering plan, the mask can be set to some identical value on all directory numbers (such as +1XXXXXXXXXX in the US). If variable length directory numbers need to be covered, more specific masks covering a single site or, as a worst case scenario, a fully qualified +E.164 AAR mask identical to the respective directory number have to be provisioned. For non-DIDs the AAR mask is left empty. This effectively disables

AAR if a non-DID is called. This makes sense because a non-DID does not have an equivalent E.164 address and thus cannot be reached via the PSTN.

The above list shows one of the advantages of a dial plan using +E.164 directory numbers. In this case the called +E.164 address can be reused directly for alternate dialing over the PSTN without applying any other modifications.

Alternate Routing for Unregistered Endpoints

In case of a WAN failure in a multi-site deployment with centralized call processing, endpoints in the affected lose connectivity with the centralized Unified CM and register with a local SRST gateway instead (see the section on

Survivable Remote Site Telephony (SRST) Deployment

). This allows the affected phones to still place and received calls to and from phones in the same site and the PSTN. Calls from phones registered with the central Unified CM will fail, though, because from the central

Unified CM’s perspective the called device is unregistered and thus unreachable. To enable automatic rerouting of calls to unregistered endpoints over the PSTN, perform the following tasks on each directory number that requires automatic rerouting:

Set the Forward Unregistered Internal and Forward Unregistered External destination to the same value as the +E.164 directory number.

Set the Forward Unregistered Internal and Forward Unregistered External CSS to PSTNReroute.

This is the same CSS as defined in the section on

Automated Alternate Routing , and it allows access

to PSTN route patterns.

January 22, 2015

Cisco Preferred Architecture for Enterprise Collaboration 10.x

2-47

Chapter 2 Call Control

Deployment Overview

Alternate routing over the PSTN for unregistered endpoints makes sense only for endpoints with +E.164 directory numbers. For endpoints without a DID (endpoints with an ESN as directory number), the only meaningful rerouting for unregistered endpoints is to forward incoming calls to voicemail. To forward calls to unregistered endpoints to voicemail, perform these tasks:

Select the Voicemail options for Forward Unregistered Internal and Forward Unregistered External.

Set the Forward Unregistered Internal and Forward Unregistered External CSS to a CSS implementing class of service Internal (for example, SJCInternal). Effectively this CSS has to provide access to only the voicemail pilot number.

User Provisioning with LDAP Synchronization

Synchronization of Unified CM with a corporate LDAP directory allows the administrator to provision users easily by mapping Unified CM data fields to directory attributes. Critical user data maintained in the LDAP store is copied into the appropriate corresponding fields in the Unified CM database on a scheduled basis. The corporate LDAP directory retains its status as the central repository. Unified M has an integrated database for storing user data and a web interface within Unified CM Administration for creating and managing user accounts and data. When LDAP synchronization is enabled, the local

Unified CM database is still used, and additional local end-user accounts can be created. Management of end-user accounts is then accomplished through the interface of the LDAP directory and the

Unified CM administration GUI.

LDAP System Configuration

Before defining the actual synchronization agreements, the LDAP system has to be enabled. In the LDAP

System Configuration menu, do the following:

Select (check) the Enable Synchronizing from LDAP Server option

Select the correct LDAP Server Type for your deployment.

Select the correct LDAP Attribute for User ID for your deployment.

In an environment where users are synchronized from Microsoft Active Directory, use the settings shown in

Table 2-41 .

Table 2-41 LDAP System Settings for Microsoft Active Directory

Setting

LDAP Server Type

LDAP Attribute for User ID

Value

Microsoft Active Directory sAMAccountName

2-48

Cisco Preferred Architecture for Enterprise Collaboration 10.x

January 22, 2015

Chapter 2 Call Control

Deployment Overview

LDAP Custom Filter

If a Unified CM based directory search is used on phones, then it does make sense to synchronized the full corporate LDAP directory to Unified CM. In that case we need to be able to differentiate between users who actually use UC services of the local cluster and users who are synchronized only to reflect the complete corporate LDAP directory on Unified CM.

To achieve this goal, custom LDAP filters can be used to define two groups of users: local and remote.

Remote here means that these users do not use any UC services on the local Unified CM cluster.

Table 2-42

shows two custom LDAP filters, assuming that our deployment has users in the US and

Europe and that only the US users are considered as local users.

Table 2-42

Remote

Custom LDAP Filter Settings

LDAP Filter Name

Local

Filter

(&

)

(objectclass=user)

(!(objectclass=Computer))

(!(UserAccountControl:1.2.840.113556.1.4.803:=2))

(telephoneNumber=+1*)

(&

(objectclass=user)

(!(objectclass=Computer))

(!(UserAccountControl:1.2.840.113556.1.4.803:=2))

(|

(telephoneNumber=+3*)

(telephoneNumber=+4*)

)

)

For better readability, the LDAP filter strings in

Table 2-42

are separated into multiple lines, with the indentation levels reflecting the structure of the LDAP filter strings. To provision these LDAP filters in

Unified CM, you have to concatenate all lines of a given filter into a single line.

Both LDAP filters are extensions of the default LDAP filter for Microsoft Active Directory. Default

LDAP filters for other directory types can be found in the chapter on

Directory Integration and Identity

Management

in the

Cisco Collaboration System 10.x SRND

and in the Unified CM online help for the

LDAP directory settings.

The LDAP filters in

Table 2-42 use the beginning of the phone numbers as criteria to determine whether

the individual user is a local or a remote user.

When using multiple LDAP synchronization agreements, you have to make sure that the LDAP filters used by these synchronization agreements are disjunct so that no single user is matched by both filters.

January 22, 2015

Cisco Preferred Architecture for Enterprise Collaboration 10.x

2-49

Chapter 2 Call Control

Deployment Overview

Feature Group Templates

Capabilities of users synchronized from LDAP are defined in a feature group template (FGT). Table 2-43

summarizes the settings for the FGT defining the capabilities of users with active devices on the

Unified CM cluster.

Table 2-43 Feature Group Template for Local Users

Setting

Name

Value

FGTlocal

Comment

Name should indicate that this is an

FGT used for local users.

Description

Home Cluster

FGT for local users

Checked Make sure that UDS-based service discovery for this user resolves to the local Unified CM cluster.

Enable the user for IM and Presence Enable User for Unified CM

IM and Presence

BLF Presence Group

Checked

Standard Presence Group

SUBSCRIBE Calling Search DefaultSubscribe

Single BLF presence group for all users, to simplify the deployment.

Use the default subscribe CSS described in the section on

Special

CSSs .

All other settings can be left as default values.

Because remote users are also synchronized from LDAP (see the section on

LDAP Custom Filter

), an

FGT for remote users must also be provisioned. The key difference is that in that FGT the Home Cluster and Enable User for Unified CM IM and Presence options are not checked.

Table 2-44

summarizes these settings.

Table 2-44

Setting

Name

Description

Home Cluster

Feature Group Template for Remote Users

Value

FGTremote

Comment

Name should indicate that this is an

FGT used for remote users.

FGT for remote users

Not checked

Enable User for Unified CM

IM and Presence

Not checked

Make sure that UDS-based service discovery for this user does not resolve to the local Unified CM cluster.

Do not enable the user for IM and

Presence.

All other settings can be left as default values.

2-50

Cisco Preferred Architecture for Enterprise Collaboration 10.x

January 22, 2015

Chapter 2 Call Control

Deployment Overview

LDAP Synchronization Agreements

To synchronize all local users to Unified CM, an LDAP synchronization agreement needs to be configured.

Table 2-45 shows the required settings to be configured under

System/LDAP/LDAP Directory.

Table 2-45 LDAP Synchronization Agreement for Local Users

Setting

LDAP Configuration Name

LDAP Manager Distinguished

Name

LDAP Password

LDAP User Search Base

LDAP Custom Filter

Perform Sync Just Once

Perform a Re-sync Every

Directory URI

Access Control Groups

Feature Group Template

LDAP Server Information

Value

Local

Name of admin users

Comment

Indicates that this LDAP synchronization agreement synchronizes local users.

Can be in the form of [email protected] or cn=ldapaccess,cn=users,dc=ent-pa,dc=com

Password of the LDAP admin

LDAP Search base

Local

Unchecked

Reasonable interval mail

Standard CCM End Users

Standard CTI Enabled

Local

References to corporate LDAP servers to be uses as source

Example: dc=ent-pa,dc=com

Refers to the custom LDAP filter described in the section on

LDAP Custom Filter

.

LDAP synchronization is executed periodically.

Make sure to set the interval small enough to pick up corporate directory changes in a reasonable time, but keep in mind that executing the LDAP synchronization creates significant load on the Unified CM publisher.

Synchronizing once every 24 hours probably is a good default.

Typically directory URIs of users are identical to their email addresses.

Add or remove other access control groups as needed, but keep in mind that without Standard CCM End

Users, the users will not be able to log into the self-service portal.

Refers to the FGT described in the section on Feature

Group Templates .

Make sure to provision redundant servers, if possible.

The LDAP synchronization agreement in

Table 2-45

ties together the FGT and custom LDAP filter defined before. This makes sure that, for all users in the corporate directory matching the custom LDAP filter, a user on Unified CM is created with the capabilities defined in the FGT.

A dedicated LDAP synchronization agreement is also required to synchronize the remote users who do not use UC services on the local Unified CM cluster.

Table 2-46

summarizes the settings for this LDAP synchronization agreement.

January 22, 2015

Cisco Preferred Architecture for Enterprise Collaboration 10.x

2-51

Chapter 2 Call Control

Deployment Overview

Table 2-46 LDAP Sync Agreement for Remote Users

Setting

LDAP Configuration Name

LDAP Manager Distinguished

Name

LDAP Password

LDAP User Search Base

LDAP Custom Filter

Perform Sync Just Once

Perform a Re-sync Every

Directory URI

Access Control Groups

Feature Group Template

LDAP Server Information

Value

Remote

Name of admin users

Comment

Indicates that this LDAP synchronization agreement synchronizes remote users.

Can be in the form of [email protected] or cn=ldapaccess,cn=users,dc=ent-pa,dc=com

Password of the LDAP admin

LDAP Search base

Remote

Unchecked

Reasonable interval mail

No access control groups selected

Remote

References to corporate LDAP servers to be uses as source

Example: dc=ent-pa,dc=com

Refers to the custom LDAP filter described in the section on

LDAP Custom Filter .

LDAP synchronization is executed periodically.

Make sure to set the interval small enough to pick up corporate directory changes in a reasonable time, but keep in mind that executing the LDAP synchronization creates significant load on the Unified CM publisher.

Synchronizing once every 24 hours probably is a good default.

Typically directory URIs of users are identical to their email addresses.

Remote users are not members of any access control group.

Refers to the FGT described in the section on

Feature

Group Templates .

Make sure to provision redundant servers, if possible.

Using the above LDAP synchronization agreements, all users can be identified from the corporate directory, and the FGTs associated with the LDAP synchronization agreements make sure that capabilities are configured correctly for all users.

User Authentication with LDAP

The LDAP authentication feature enables Unified CM to authenticate LDAP synchronized users against the corporate LDAP directory. Locally configured users are always authenticated against the local database. Also, PINs of all end users are always checked against the local database only.

To enable authentication, a single authentication agreement is defined for the entire cluster.

The following statements describe Unified CM's behavior when authentication is enabled:

End user passwords of users imported from LDAP are authenticated against the corporate directory by a simple bind operation.

End user passwords for local users are authenticated against the Unified CM database.

Application user passwords are authenticated against the Unified CM database.

End user PINs are authenticated against the Unified CM database.

2-52

Cisco Preferred Architecture for Enterprise Collaboration 10.x

January 22, 2015

Chapter 2 Call Control

Deployment Overview

In environments that employ a distributed Active Directory topology with multiple domain controllers geographically distributed, authentication speed might be unacceptable. When the Domain Controller for the authentication agreement does not contain a user account, a search must occur for that user across other domain controllers. If this configuration applies, and login speed is unacceptable, it is possible to set the authentication configuration to use a Global Catalog Server.

An important restriction exists, however. A Global Catalog does not carry the employeeNumber attribute by default. In that case either use Domain Controllers for authentication (beware of the limitations listed above) or update the Global Catalog to include the employeeNumber attribute. Refer to Microsoft Active

Directory documentation for details.

To enable queries against the Global Catalog, simply configure the LDAP Server Information in the

LDAP Authentication page to point to the IP address or host name of a Domain Controller that has the

Global Catalog role enabled, and configure the LDAP port as 3268.

Table 2-47

shows an example of LDAP authentication settings.

LDAP Authentication Settings Table 2-47

Setting

LDAP Authentication for End Users

Example

Use LDAP Authentication for End Users Checked

LDAP Manager Distinguished Name

LDAP Password

Confirm Password Same as above ou=enterprise,dc=ent-pa,dc=com

Comment

Enables LDAP authentication for the

Unified CM cluster.

cn=ldapmanager,dc=ent pa,dc=com Distinguished name of an AD account with read access rights to all user objects in the desired user search base.

Some password

LDAP User Search Base

LDAP Server Information

Host Name or IP Address for Server

LDAP Port ent-dc1.ent-pa.com

3268

Server with global catalog role

Port to access global catalog

(recommended)

Cisco Unified CM Group Configuration

Cisco Unified CM groups allow you to define groups of Unified CM instances in the cluster that determine which Unified CM instances should be used by devices to register to the Unified CM cluster.

If only a single Unified CM call processing pair is deployed (see the section on

Provision the Cisco

Unified CM and IM and Presence Service Cluster

for more information), then a single Unified CM group named Default also needs to be deployed, and both Unified CM instances running on the single pair of

Unified CM call processing subscribers in the cluster have to be members of this single Unified CM group.

If more than one pair of Unified CM call processing subscribers exists, then additional Unified CM groups need to be provisioned (one for each pair of Unified CM call processing subscribers), and in each

Unified CM group the two Unified CM instances running on that specific pair are added to the group.

January 22, 2015

Cisco Preferred Architecture for Enterprise Collaboration 10.x

2-53

Chapter 2 Call Control

Deployment Overview

For a Unified CM cluster with two pairs of Unified CM call processing subscribers named ucm1a.ent-pa.com and ucm1b.ent-pa.com in the first pair and ucm2a.ent-pa.com and ucm2b.ent-pa.com in the second pair, with ucm1a and ucm2a being the primary Unified CM call processing subscribers in each pair,

Table 2-48

lists the Unified CM groups to be provisioned.

Table 2-48

CM_2

Example Unified CM Group Definition

Unified CM Group

CM_1

Unified CM Group Members

CM_ucm1a.ent-pa.com

CM_ucm1b.ent-pa.com

CM_ucm2a.ent-pa.com

CM_ucm2b.ent-pa.com

All registrations have to be equally balanced between Unified CM groups. This is achieved by assigning devices to Unified CM groups via device pool configuration as discussed in the section on

Device Pools

.

Phone NTP References

If you want to do so, you can configure phone Network Time Protocol (NTP) references in Cisco Unified

Communications Manager Administration to ensure that a phone running SIP gets its date and time from the NTP server. If all NTP servers do not respond, the phone that is running SIP uses the date header in the 200 OK response to the REGISTER message for the date and time.

After you add the phone NTP reference to Cisco Unified CM Administration, you must add it to a date/time group.

To define phone NTP references, get the IP addresses of the NTP servers you plan to use, and configure the settings according to

Table 2-49

.

Table 2-49

Setting

IP Address

Description

Mode

Phone NTP Reference Settings

Example

66.228.35.252

0.pool.ntp.org

Unicast

Comment

IP address of NTP server to be used

Should refer to the hostname of the IP address being entered

Unicast limits devices to using only NTP response from listed servers

Make sure to provision multiple phone NTP references for redundancy.

Date and Time Groups

Date and time groups allow you to define the time zone and the date and time format to be used for sets of devices registering with Unified CM. The date/time group configuration is specified in the device pool, and the device pool is specified on the phone page. For more information on device pools, see the section on

Device Pools

.

2-54

Cisco Preferred Architecture for Enterprise Collaboration 10.x

January 22, 2015

Chapter 2 Call Control

Deployment Overview

If you want SIP phones to get their date and time from NTP servers, then in the date/time group you prioritize the phone NTP references, starting with the first server that you want the phone to contact.

Create one named Date/Time Group for each of the time zones in which you will deploy endpoints, as illustrated in

Table 2-50 .

Table 2-50 Example Date/Time Group Definitions

Date and Time Group

RCD_Time

RTP_Time

SJC_Time

Time Zone

America/North_Dakota/New_Salem

America/New_York

America/Los_Angeles

Media Resources

A media resource is a software-based or hardware-based entity that performs media processing functions on the data streams to which it is connected. Media processing functions include mixing multiple streams to create one output stream (conferencing), passing the stream from one connection to another

(media termination point), converting the data stream from one compression type to another

(transcoding), streaming music to callers on hold (music on hold), echo cancellation, signaling, voice termination from a TDM circuit (coding/decoding), packetization of a stream, streaming audio

(annunciation), and so forth. The software-based resources are provided by the Cisco Unified CM

IP Voice Media Streaming Application.

Media Resource Manager

The Media Resource Manager (MRM), a software component in the Unified CM, determines whether a media resource needs to be allocated and inserted in the media path. When the MRM decides and identifies the type of the media resource, it searches through the available resources according to the configuration settings of the media resource group list (MRGL) and media resource groups (MRGs) associated with the devices in question. MRGLs and MRGs are constructs that hold related groups of media resources together for allocation purposes

Media Resource Selection and Avoiding the Default MRG

Media resource groups (MRGs) and media resource group lists (MRGLs) provide a method to control how resources are allocated, which could include rights to resources, location of resources, or resource type for specific applications. MRGs are used to group together media resources of similar characteristics, and MRGLs define a set of MRGs to be considered when selecting a required media resource for a session. If the Media Resource Manager does not find a required resource by searching through a configured MRGL, considering all media resources being members of MRGs of that list, then the Media Resource Manager checks a default media resource group for media resources. All media resources by default are members of this default MRG unless they are explicitly configured to be members of any specific MRG.

In this design we will not use the default MRG because it makes troubleshooting of media resource selection more complicated. To make sure that the default MRG is empty, you have to assign all media resources to at least one MRG.

January 22, 2015

Cisco Preferred Architecture for Enterprise Collaboration 10.x

2-55

Chapter 2 Call Control

Deployment Overview

Cisco IP Voice Media Streaming Application

The Cisco IP Voice Media Streaming Application provides the following software-based media resources:

Conference bridge

Music on Hold (MoH)

Annunciator

Media termination point (MTP)

When the IP Voice Media Streaming Application is activated on a node in the Unified CM cluster, one of each of the above resources is automatically configured. For service activation recommendations, see

Table 2-5 .

In this design only unicast MoH is used, with media being streamed from the Cisco IP Voice Media

Streaming Application running on the Unified CM cluster subscriber nodes.

An annunciator is a software function of the Cisco IP Voice Media Streaming Application that provides the ability to stream spoken messages or various call progress tones from the system to a user.

All MOH and annunciator media resources created by the Cisco IP Voice Media Streaming Application running on Unified CM are combined in a single MRG by performing the following tasks:

Create an MRG named Software.

Assign all annunciator resources created by the Cisco IP Voice Media Streaming Application to

MRG Software.

Assign all MoH resources created by the Cisco IP Voice Media Streaming Application to MRG

Software.

The software-based conferencing and media termination points created by the Cisco IP Voice Media

Streaming Application are not used in this design. To disable them, perform the following tasks:

Create an MRG named Unused.

Assign all software-based conference bridges created by the Cisco IP Voice Media Streaming

Application to MRG Unused.

Assign all software-based media termination points created by the Cisco IP Voice Media Streaming

Application to MRG Unused.

This makes sure that these resources are not part of the default MRG any longer and are never considered in the Media Resource Manager media resource selection process.

2-56

Cisco Preferred Architecture for Enterprise Collaboration 10.x

January 22, 2015

Chapter 2 Call Control

Deployment Overview

MRG and MRGL Definitions

Its good practice to keep the number of provisioned MRGLs to a minimum. Factors contributing to the number of required MRGLs include:

Site specificity

If site-specific media resources exist, then site-specific MRGs for those resources need to be configured, and typically also site-specific MRGLs are required to allow for site-specific selection of (typically local) media resources.

Different types of media resources of the same class

Unified CM does not differentiate between audio-only and audio/video conferencing resources. If both audio and audio/video conferencing media resources are provisioned, then an MRG (and

MRGL) is required per type of media resource to allow configuration of differential access policies to these resources. See the

Conferencing

chapter for more details on conferencing resources.

If no site-specific media resources and no differentiation of media resource types is required, then at least a single MRGL named Standard needs to be configured.

For each required MRGL based on site specificity and media resource type provision, create an MRGL by performing the following tasks:

Set the MRGL name so that it reflects the site specificity and media resource type of the MRGL.

Select the desired MRGs for the MRGL. Make sure to always include the Software MRG so that access to MoH and Annunciator is ensured.

Table 2-51

shows example MRGL definitions that provide differentiated treatment of audio and video conferencing. MRGL Audio would need to be assigned to devices requiring access to audio conferencing media resources only, while MRGL Video would allow access to video conferencing resources.

Table 2-51

MRGL Name

Audio

Video

Example MRGL Definition with Audio and Video Conferencing

MRGs

Audio

Software

Video

Software

Comment

MRGL with access to audio conferencing media resources in MRG Audio.

MRG Software added to provide access to MoH and annunciator.

MRGL with access to video conferencing media resources in MRG Video.

MRG Software added to provide access to MoH and annunciator.

January 22, 2015

Cisco Preferred Architecture for Enterprise Collaboration 10.x

2-57

Chapter 2 Call Control

Deployment Overview

Device Pools

Table 2-52

Device pools define sets of common characteristics for devices. Characteristics defined on the device pool include the settings shown in

Table 2-52 .

Device Pool Settings

Setting

Cisco Unified

Communications Manager

Group

Local Route Groups

Description

Unified CM groups are needed to distribute registrations equally among Unified CM call

processing subscriber pairs (see the section on Cisco Unified CM Group Configuration ). The

Unified CM Group provisioned on the device pool determines the Unified CM call processing subscribers to which devices associated with the given device pool will try to register.

As described in the section on

Local Route Groups for Call Type Specific Outbound Gateway

Selection , multiple LRGs are defined to allow for call type specific egress gateway selection

based on LRGs. For each defined LRG name, the route group selected for that LRG name defines which devices will be considered for a call of the selected type (defined by the route pattern matching on the called number and pointing to a route list referring to specific LRGs).

It is important to set route groups for all defined LRG names to avoid call failures due to route lists not containing any valid PSTN resources.

Roaming Sensitive Settings

Date/Time Group Defines date and time format and phone NTP references. See the section on

Phone NTP

References

.

Media Resource Group List MRGL defining the media resources available for a group of devices. See the section on

MRG and MRGL Definitions .

Device Mobility Related Information

AAR Calling Search Space The CSS used to route calls to an alternate PSTN destination. The dial plan design in this document allows use of the same AAR CSS (PSTNReroute) in all cases (see the section on

Automated Alternate Routing ).

AAR Group To enable AAR, an AAR group has to be defined. Using +E.164 directory numbers allows you to deploy AAR using a single AAR group, Default (see the section on

Automated Alternate

Routing ).

Calling Party Transformation

CSS

This CSS defines the calling party transformations applied to calling party information sent in the direction of the affected device.

For gateways this CSS is tied to the calling party transformation CSS defined in the Outbound

Calls section on the gateway configuration page.

For phones this CSS is tied to the calling party transformation CSS defined in the Remote

Number section on the phone configuration page.

Called Party Transformation

CSS

This CSS defines the called party transformations applied to called party information sent in the direction of the affected device.

For gateways this CSS is tied to the called party transformation CSS defined in the Outbound

Calls section on the gateway configuration page.

Call Routing Information

For phones this CSS has no equivalent on the phone configuration page and does not have any effect when configured on a device pool used for phones.

This setting allows you to define incoming calling and called party transformations per numbering type to be applied to incoming calls on gateways. The same settings also can be configured in the gateway configuration page if individual gateway-specific settings are required.

2-58

Cisco Preferred Architecture for Enterprise Collaboration 10.x

January 22, 2015

Chapter 2 Call Control

Deployment Overview

All other device pool level settings are not used in this design.

Whenever the same settings for the configuration options listed in

Table 2-52

need to be applied to a group of devices, we recommend creating a device pool with these settings and then assigning all devices to this device pool. If one of the settings needs to be changed for all of the devices, the device pool level configuration allows you to change the setting for all devices at one point.

To minimize the number of device pools, create a device pool only if multiple devices share the same characteristics. An example of this is phones in the same site.

Table 2-53 shows an example of device

pool settings for phones with video conferencing capabilities in site RTP.

Table 2-53 Device Pool Settings for Phones with Video Conferencing Capabilities in Site RTP

Setting

Device Pool Name

Value

RTPPhoneVideo

Comment

Name should uniquely identify the devices (type and further classification) this device pool is used for. In this case we use this device pool for phones in site RTP with video conferencing capabilities

Cisco Unified Communications

Manager Group

Local Route Group Settings

Standard Local Route Group

CM_1

RTP_PSTN

LRG_PSTN_1

LRG_PSTN_2

LRG_VIDEO_1

RTP_PSTN

SJC_PSTN

SJC_VIDEO

All route lists use Standard Local Route Group as last option.

Always set Standard Local Route Group to the local PSTN gateways' route group.

First option for PSTN calls is to use local RTP gateways.

Use HQ gateways as fallback.

No site-specific video gateways exist. We use the video gateway in site SJC.

LRG_VIDEO_2

LRG_EMERGENCY_1

LRG_EMERGENCY_2

Roaming Sensitive Settings

Date/Time Group

Media Resource Group List

<None>

<None>

<None>

RTP_Time

Video

No setting; fallback to Standard Local Route Group.

No setting; fallback to Standard Local Route Group.

See the section on Date and Time Groups .

Provide access to video conferencing media resources (see

Table 2-51

).

Device Mobility Related Information

AAR Calling Search Space

AAR Group

Calling Party Transformation

CSS

Called Party Transformation

CSS

PSTNReroute

Default

RTPPhLocalize

<None>

Same for all devices and device pools.

Same for all devices and device pools.

Site-specific calling party transformations (see

Table 2-38

and

Table 2-39 ).

Does not apply to phones.

Table 2-53

shows how the actual site-specific PSTN gateways are assigned to the LRG names to achieve the site-specific egress gateway selection for phones in different sites.

January 22, 2015

Cisco Preferred Architecture for Enterprise Collaboration 10.x

2-59

Chapter 2 Call Control

Deployment Overview

Figure 2-8

shows how different LRG selections for the same LRG name LRG_PSTN_1 on the device pools for phones in site RTP and SJC make sure that PSTN calls from phones in site RTP and SJC egress to the PSTN through different gateways although the same route pattern and route list are used for calls from both sites.

Figure 2-8 Site-Specific Egress Gateway Selection

From the example in Table 2-53 we can see that, following the same schema, we would need to provision

two device pools per site to be able to differentiate between devices with and without video conferencing capabilities. If video conferencing capabilities were the exception, we could decide to use only one device pool per site with MRGL set to Audio and then on the few video-enabled devices set the MRGL to Video in the device configuration.

2-60

Cisco Preferred Architecture for Enterprise Collaboration 10.x

January 22, 2015

Chapter 2 Call Control

Deployment Overview

Table 2-54

summarizes the device pool settings of the device pool used for gateways in a specific site.

Site RTP is used as an example here.

Table 2-54 Device Pool Settings for PSTN Gateways in Site RTP

Setting

Device Pool Name

Value

RTP_PSTN

Comment

Name should uniquely identify the devices (type and further classification) this device pool is used for. In this case we use this device pool for PSTN gateways in site RTP.

Cisco Unified Communications

Manager Group

Local Route Group Settings

Standard Local Route Group

CM_1

RTP_PSTN There actually is no call flow for which a PSTN trunk would need a

PSTN resource. Also see the note on configuration order in the section on

Route Groups . When you create the device pool, the

required route group does not exist yet. Hence, initially you need to configure the device pool and leave the LRG mapping set to

<None>. After configuring the SIP trunks and route groups, you can come back and set the LRG mapping.

LRG_PSTN_1

LRG_PSTN_2

LRG_VIDEO_1

LRG_VIDEO_2

LRG_EMERGENCY_1

<None>

<None>

<None>

<None>

LRG_EMERGENCY_2

Roaming Sensitive Settings

Date/Time Group

Media Resource Group List

<None>

<None>

RTP_Time

Audio

See the section on

Date and Time Groups .

Calls coming in from the PSTN would not require access to video conferencing resources.

Device Mobility Related Information

AAR Calling Search Space

AAR Group

Calling Party Transformation

CSS

PSTNReroute

Default

Same for all devices and device pools, although not really required for a PSTN trunk.

Same for all devices and device pools, although not really required for a PSTN trunk.

RTPGWLocalizeCn Site-specific calling party transformations to make sure that only valid calling party information is sent (all numbers not belonging to the RTP DID range are masked). Also, the digit string is set to a format suitable for the ISDN gateway (see

Table 2-35 ).

Called Party Transformation

CSS

USGWLocalizeCd See

Table 2-34 . This transformation makes sure that called party

numbers are transformed from +E.164 to the format that can be sent as plan unknown and type unknown.

Call Routing Information

Incoming Calling Party Settings Nothing is configured here. We assume that the transformation from ISDN number format

Incoming Called Party Settings to +E.164 is achieved using Cisco IOS voice translation rules on the gateway (see the section on

Inbound Calls: Called and Calling Number Transformations on ISDN

Gateways ).

Cisco Preferred Architecture for Enterprise Collaboration 10.x

January 22, 2015

2-61

Chapter 2 Call Control

Deployment Overview

Table 2-55 summarizes the device pool settings for a SIP trunks to other Unified CM clusters and

application servers. SIP trunks to other Unified CM clusters do not require any transformations on calling and called part information because the called party number already is globalized to +E.164 by the dialing normalization translation patterns provisioned in the dial plan, and calling party information internal to Unified CM based on the provisioned dial plan is either +E.164 or an ESN and both formats make sense in the context of on-net intercluster calls.

Table 2-55 Device Pool Settings for Central Trunks and Applications

Setting

Device Pool Name

Value

Trunks_and_Apps

Comment

Name should uniquely identify the devices (type and further classification) this device pool is used for.

Cisco Unified Communications

Manager Group

Local Route Group Settings

Standard Local Route Group

CM_1

RTP_PSTN Trunks actually do not need PSTN access, but applications might require PSTN access. So PSTN resources of one site are selected via the Standard Local Route Group configuration. Other site's PSTN resources can be used as failover.

LRG_PSTN_1

LRG_PSTN_2

LRG_VIDEO_1

LRG_VIDEO_2

LRG_EMERGENCY_1

RTP_PSTN

SJC_PSTN

<None>

<None>

LRG_EMERGENCY_2

Roaming Sensitive Settings

Date/Time Group

Media Resource Group List

<None>

<None>

RTP_Time

Video

See the section on

Date and Time Groups

.

Intercluster calls could potentially require video media resources.

Device Mobility Related Information

AAR Calling Search Space

AAR Group

Calling Party Transformation

CSS

PSTNReroute

Default

<None>

Same for all devices and device pools.

Same for all devices and device pools.

No transformations on intercluster trunks and trunks to application servers.

Called Party Transformation

CSS

Call Routing Information

USGWLocalizeCd No transformations on intercluster trunks and trunks to application servers.

Incoming Calling Party Settings Nothing configured. We assume that inbound calling and called party numbers already are

Incoming Called Party Settings normalized.

2-62

Cisco Preferred Architecture for Enterprise Collaboration 10.x

January 22, 2015

Chapter 2 Call Control

Deployment Overview

SIP Trunks

All connections to other entities, including call controls, applications, and conferencing resources, use

SIP trunks.

SIP Profiles

A SIP profile comprises the set of SIP attributes that are associated with SIP trunks and SIP endpoints.

To keep the number of SIP profiles to a minimum, follow these rules:

Consider the default profiles first.

Then consider already defined non-default profiles.

Create a new SIP profile only if none of the default profiles match.

Avoid defining profiles per trunk.

Table 2-56

shows the settings for a SIP profile to be used for all SIP IP phones and SIP trunks to other

Unified CM clusters or SIP gateways.

SIP Profile for SIP Phones and Standard Trunks Table 2-56

Setting

Copy of Standard SIP Profile

Name

Use Fully Qualified Domain Name in SIP

Requests

Value

FQDN

Checked

Comment

Early Offer support for voice and video calls

Enable OPTIONS Ping to monitor destination status for Trunks with Service

Type "None (Default)"

Ping Interval for In-service and Partially

In-service Trunks (seconds)

10

Ping Interval for Out-of-service Trunks

(seconds)

Ping Retry Timer (milliseconds)

Ping Retry Count

Best Effort (no MTP inserted)

Checked

60

500

6

Prevents IP address of Unified CM server from showing up in SIP calling party information sent by Unified CM.

This is the recommended configuration for all

Unified CM trunks. Best Effort Early Offer trunks never use MTPs to create an Early Offer and, depending on the calling device, can initiate an outbound SIP trunk call using either

Early Offer or Delayed Offer. In the context of this design, outbound calls always use Early

Offer.

Allows monitoring of the reachability of SIP trunk peers; applies to SIP trunks only.

One ping every 10 seconds, combined with a retry count of 6, makes sure that SIP trunk unavailability is detected within a minute.

If a trunk is out of service, then we do not have to try to reach the peer as often.

January 22, 2015

Cisco Preferred Architecture for Enterprise Collaboration 10.x

2-63

Chapter 2 Call Control

Deployment Overview

SIP Trunk Security Profiles

Cisco CallManager Administration groups SIP trunk security-related settings – for example, device security mode, digest authentication, and incoming/outgoing transport type settings – so you can apply all configured settings to a SIP trunk when you choose the profile in the SIP Trunk Configuration window.

Table 2-57 shows the default settings on the system generated SIP trunk security profile Non Secure SIP

Trunk Profile. This SIP trunk security profile is used for the SIP trunks to ISDN PSTN gateways, for example.

Table 2-57 Non Secure SIP Trunk Profile SIP Trunk Security Profile Settings

Setting

Name

Device Security Mode

Incoming Transport Type

Outgoing Transport Type

Enable Digest Authentication

Incoming Port

Enable Application level authorization

Accept presence subscription

Accept out-of-dialog refer

Accept unsolicited notification

Accept replaces header

Transmit security status

Allow charging header

SIP V.150 Outbound SDP Offer Filtering

Value

Non Secure SIP Trunk Profile

Non Secure

TCP+UDP

TCP

Not Checked

5060

Not Checked

Not Checked

Not Checked

Not Checked

Not Checked

Not Checked

Not Checked

Use Default Filter

Table 2-58 shows the settings for a SIP Trunk Security Profile used for a SIP trunk to the IM and

Presence nodes, differing from the default settings in

Table 2-57 .

Table 2-58

Setting

Name

SIP Trunk Security Profile for IM and Presence Trunk

Value

IM and Presence

Comment

Meaningful name describing the use of the SIP Trunk Security Profile.

Accept Presence Subscription Checked

Accept Out-of-Dialog REFER Checked

Accept Unsolicited Notification Checked

Accept Replaces Header Checked

Table 2-59 shows the settings on the SIP trunk security profile to be used for intercluster trunks to other

Unified CM clusters. On these trunks we want to accept presence subscriptions to enable intercluster

Busy Lamp Field (BLF) presence.

2-64

Cisco Preferred Architecture for Enterprise Collaboration 10.x

January 22, 2015

Chapter 2 Call Control

Deployment Overview

Table 2-59

Setting

Name

SIP Trunk Security Profile for Intercluster Trunks

Value

ICT

Comment

Name describing the use of the SIP Trunk

Security Profile.

Accept Presence Subscription

Transmit Security Status

Checked

Checked

SIP Trunk Connections

SIP trunks are the preferred way to set up connectivity between Unified CM clusters and between

Unified CM and other systems such as gateways, applications, and media resources. Depending on the type of connected system, the parameters configured on each SIP trunk differ slightly.

Table 2-60

summarizes the settings for a SIP trunk to a PSTN gateway in site RTP.

Table 2-60

Setting

Name

Description

Device Pool

AAR Group

SIP Trunk Settings for Trunk to ISDN Gateway in Site RTP

Value

ST_RTP_PSTN_1

Media Resource Group List

PSTN Access

Run On All Active Unified CM Nodes

RTP_PSTN

<None>

Default

Checked

Checked

Comment

Prefix ST_ to avoid name collisions with other devices stored in the same table internally. The remainder of the name identifies the location of the gateway and allows numbers for multiple gateways.

Some meaningful description

Common device pool for all RTP PSTN gateways. Allows sharing of site-specific settings between all RTP gateways.

Use the MRGL defined on the device pool.

Same everywhere

This settings is recommended on all SIP trunks. This makes sure that outbound calls to

SIP do not require intra-cluster control signaling between Unified CM call processing subscribers.

Inbound Calls

Calling Search Space DN Inbound calls have +E.164 called party numbers, and only local destinations can be called from the PSTN. Hence, no access is required to ESN numbers and intercluster destinations.

AAR Calling Search Space

Outbound Calls

Use Device Pool Called Party

Transformation CSS

PSTNReroute

Checked

January 22, 2015

Cisco Preferred Architecture for Enterprise Collaboration 10.x

2-65

Chapter 2 Call Control

Deployment Overview

Table 2-60

Setting

Use Device Pool Calling Party

Transformation CSS

SIP Information

Destination

SIP Trunk Security Profile

SIP Profile

SIP Trunk Settings for Trunk to ISDN Gateway in Site RTP (continued)

Value

Checked

Comment

X.X.X.X

Non Secure SIP Trunk Profile

FQDN

IP address of ISDN gateway

Default SIP trunk security profile

The key here is that the inbound CSS provides access to local +E.164 destinations only. These include voicemail pilots or other services that need to be reachable from the PSTN, but no access is required to

PSTN route patterns, dialing normalization translation patterns, ESNs, URIs, and intercluster destinations.

Settings for SIP trunks to other Unified CM clusters differ somewhat from the settings on SIP trunks to

ISDN gateways. Table 2-61

summarizes these settings.

Table 2-61

Setting

Name

Description

Device Pool

AAR Group

PSTN Access

SIP Trunk Settings for Intercluster Trunk to Other Unified CM Cluster

Media Resource Group List

Run On All Active Unified CM

Nodes

Value

ST_UCM_EMEA

Trunks_and_Apps

<None>

Default

Not checked

Checked

Comment

Prefix ST_ to avoid name collisions with other devices stored in the same table internally. The remainder of the name identifies the trunk's purpose.

Some meaningful description

Common device pool for central trunks (see

Table 2-55

)

Use the MRGL defined on the device pool.

Same everywhere

This settings is recommended on all SIP trunks. This makes sure that outbound calls to SIP do not require intra-cluster control signaling between Unified CM call processing subscribers.

Inbound Calls

Calling Search Space ICTInbound

AAR Calling Search Space PSTNReroute

Incoming calls on trunks need to support +E.164, ESN, and URI dialing. This special CSS supports all three dialing habits but does not provide access to PSTN or remote on-net destinations (see

Table 2-26

in the section on

Special CSSs

).

For applications requiring PSTN access, another special class of service (CSS) is required to also provide access to the partitions with PSTN access route patterns

(see Table 2-29

in the section on Route Patterns for

PSTN Access and Emergency Calls ).

Same CSS everywhere

2-66

Cisco Preferred Architecture for Enterprise Collaboration 10.x

January 22, 2015

Chapter 2 Call Control

Deployment Overview

Table 2-61 SIP Trunk Settings for Intercluster Trunk to Other Unified CM Cluster (continued)

Comment Setting

Outbound Calls

Use Device Pool Called Party

Transformation CSS

Use Device Pool Calling Party

Transformation CSS

Calling and Connected Party

Info Format

Value

Checked

Checked

Deliver URI and DN in connected party, if available

On intercluster trunks to other Unified CM clusters, blended identity with both numeric and URI information should be delivered to the remote cluster. If both types of identity exist, then based on the capabilities of the called endpoint, the cluster terminating the call can decide which piece of the identity information can be displayed on the final called party.

SIP Information

Destination X.X.X.X

SIP Trunk Security Profile

SUBSCRIBE Calling Search

Space

SIP Profile

ICT

ICTInbound

FQDN

List IP addresses of all Unified CM call processing subscribers of remote Unified CM cluster. The order of the IP addresses is not relevant because outbound calls are randomly distributed among the defined destinations.

See

Table 2-59

Subscriptions on +E.164, ESN, and URIs should be accepted. For the definition of the CSS, see the section on

Special CSSs

.

See

Table 2-56

In contrast to the SIP trunk to a PSTN ISDN gateway, inbound calls from other Unified CM clusters in addition to +E.164 numbers also need access to ESNs and URIs. However, to avoid routing loops and transit-routing, intercluster trunks do not have access to intercluster destinations (partition remoteOnNet, see

Table 2-13

).

For the SIP trunk to the IM and Presence nodes, configure a SIP trunk between Unified CM and IM and

Presence. For this SIP trunk, configure the destination IP addresses of all IM and Presence nodes. Select the SIP Trunk Security Profile that you just created for the IM and Presence Service. Also select the

Standard SIP Profile.

January 22, 2015

Cisco Preferred Architecture for Enterprise Collaboration 10.x

2-67

Chapter 2 Call Control

Deployment Overview

Route Groups

All SIP trunks are assigned to route groups. Route groups combine trunks with common characteristics.

Table 2-62 shows the route group definition for the PSTN gateways in site RTP.

Table 2-62 Route Group for RTP PSTN Gateways

Setting

Route Group Name

Distribution Algorithm

Route Group Members

Value

RTP_PSTN

Circular

ST_RTP_PSTN_1

ST_RTP_PSTN_2

ST_RTP_PSTN_3

Comment

Meaningful name

We want to make sure to balance the load over all gateways.

Add all SIP trunks to all SIP gateways in site RRP.

Note

2.

3.

4.

Route groups can be configured only after the SIP trunks have been created, and these can be added only after the respective device pool have been configured. This means that at the time of creating the device pool for PSTN gateways, route groups do not yet exist. Thus the configuration order is:

1.

Configure the device pool for the PSTN gateway without defining the LRG mapping in the device pool.

Configure SIP trunks.

Create the route group.

Go back to the device pool and add LRG mapping (if required).

For intercluster trunks to other Unified CM clusters, a route group per trunks also needs to be defined.

Table 2-63 shows an example of a route group for an intercluster trunks to a remote Unified CM cluster.

Table 2-63 Route Group for Intercluster Trunk to Other Unified CM Cluster

Setting

Route Group Name

Distribution Algorithm

Route Group Members

Value

UCM_EMEA

Circular

ST_UCM_EMEA

Comment

Meaningful name; in this case, for the route group holding only the intercluster trunk to the EMEA Unified CM cluster.

Irrelevant as long as only one route group member exists.

SIP trunk to remote Unified CM cluster.

Similar trivial route groups must be created for each non-PSTN SIP trunk provisioned on Unified CM.

2-68

Cisco Preferred Architecture for Enterprise Collaboration 10.x

January 22, 2015

Chapter 2 Call Control

Deployment Overview

Specific Non-LRG Route Lists

The section on

Route Lists Using Local Route Groups

introduces route lists for PSTN access using local route groups only. For non-PSTN trunks, specific route lists need to be created using the route groups referring to these non-PSTN trunks. The reason for defining trivial route groups with only a single member and trivial route lists with only a single non-LRG route group as member, is that route patterns in Unified CM should never point to a trunk directly, because whenever a route pattern is changed in

Unified CM, then the device the route pattern is pointing to is reset, and pointing route patterns to a route list instead of trunks makes sure that editing the route patterns will not reset the trunk itself but rather the route list. Examples for such trunks include trunks to other Unified CM clusters and applications.

Table 2-64

shows the trivial route list for an intercluster trunk to another Unified CM cluster.

Table 2-64 Route List for Intercluster Trunk to Another Unified CM Cluster

Route List Members

RL_UCM_EMEA UCM_EMEA

Description

Only a single member: the actual trunk to the remote

Unified CM cluster. The leading RL makes sure to avoid naming collisions with trunks. Internally route lists are treated as devices, and the names of route lists cannot be identical to names of SIP trunks, for example.

Similar trivial route lists have to be created for each non-PSTN SIP trunk provisioned on Unified CM.

Endpoint Provisioning

When provisioning a new endpoint, these minimum tasks are required:

Configure the Device

Configure the Line

Add the Device to Devices Controlled by the User

Configure the Line Association for Presence

January 22, 2015

Cisco Preferred Architecture for Enterprise Collaboration 10.x

2-69

Chapter 2 Call Control

Deployment Overview

Configure the Device

When adding a new endpoint to Unified CM, the design described in this document requires the settings summarized in

Table 2-65 . Settings not mentioned here are either left as default or have to be configured

according to device-specific requirements:

Table 2-65 Endpoint Device Settings

Setting

Device Information

Device Pool

Calling Search Space

AAR Calling Search Space

Media Resource Group List

AAR_Group

Owner

Value

RTPPhoneVideo

USEmergency

PSTNReroute

<None>

Default

Select "User"

Description

Site-specific device pool for endpoints (see

Table 2-53

). In this case this is the device pool for endpoints in site RTP with access to video conferencing media resources.

Access to emergency routing in multi-national environments is implemented on the device level

(see the section on

Emergency Call

Considerations in Multi-National

Environments

). If only one country (dialing domain) such as the US needs to be supported, then this CSS can be left as <None>.

Same everywhere (see the section on Automated

Alternate Routing

).

Use device pool level settings.

Same everywhere (see the section on Automated

Alternate Routing

).

If the device is a phones without user association

(for example a lobby phone), then select

"Anonymous (Public/Shared Space)" and do not set the "Owner User ID"

Owner User ID

Allow Control of Device from CTI Checked

Number Presentation Transformation

Caller ID For Calls From This

Phone

Select "Use Device Pool Calling

Party Transformation CSS (Caller

ID For Calls From This Phone)"

Remote Number

Select the user ID of the owner of this phone.

Select "Use Device Pool Calling

Party Transformation CSS (Device

Mobility Related Information)"

Protocol Specific Information

SIP Profile FQDN See

Table 2-56

2-70

Cisco Preferred Architecture for Enterprise Collaboration 10.x

January 22, 2015

Chapter 2 Call Control

Deployment Overview

Configure the Line

On each endpoint, at least the first line needs to be provisioned.

Table 2-66 summarizes the line settings

specific to the design described in this document.

Table 2-66 Line Settings

Setting

Directory Number Information

Directory Number

Value Description

Route Partition

Alerting Name

\+14085554146

DN

Aristotle Boyle

Full +E.164 directory number matching the phone number of the user this DN is provisioned for. The leading + has to be escaped with \. If a non-DID is provisioned, then the directory number is set to the

ESN (for example, 81405001).

If a non-DID is provisioned, then the partition is

ESN.

Full name of the user associated with the number. If the number is not associated with a user, then provision a meaningful name (for example, Bldg. 31

Lobby).

Allow Control of Device from CTI Checked

Directory Number Settings

Calling Search Space SJCInternational CSS defining the effective class of service for calls from this line. The CSS is specific to site and class of service (see the section on

Classes of Service and

Calling Search Spaces (CSSs) for other CSSs).

Same for all lines BLF Presence Group

+E.164 Alternate Number

Number Mask

Standard Presence Group

Add to Local Route Partition

Leave mask empty

Not checked

An empty mask creates the +E.164 alternate number identical to the directory number configured above.

If a non-DID is provisioned, no +E.164 alternate number is added because no PSTN address exists for non-DIDs, by definition.

The +E.164 alternate number is not added to a local route partition because the directory number itself already is a +E.164 number

Advertise Globally via ILS Not checked The +E.164 alternate number is not advertised via

ILS. Instead, summary routes for each DID range are advertised (see

Table 2-70

). The only reason to create the +E.164 alternate number is to be able to advertise this +E.164 alternate number as the GDPR

PSTN failover number for URIs associated with this directory number.

PSTN Failover for Enterprise Alternate Number, +E.164 Alternate Number, and URI Dialing

Advertised Failover Number +E.164 Number The +E.164 number is advertised as GDPR PSTN. If a non-DID is provisioned, then set to <None>.

January 22, 2015

Cisco Preferred Architecture for Enterprise Collaboration 10.x

2-71

Chapter 2 Call Control

Deployment Overview

Table 2-66

Setting

AAR Settings

Voice Mail

Line Settings (continued)

Value

AAR Destination Mask

Not checked

+14085554XXX

External Phone Number Mask +14085554XXX

Description

If a non-DID is provisioned, then check this option.

This DID range mask makes sure that the alternate

PSTN destination for AAR is equal to the directory number. If a non-DID is provisioned, then leave this mask empty.

Same everywhere AAR Group

Call Forward and Call Pickup Settings

Calling Search Space Activation

Policy

Forward All

Default

Use System Default

All other Forward settings other than "Forward Unregistered

Internal" and "Forward

Unregistered External"

"Forward Unregistered Internal" and "Forward Unregistered

External"

"Voicemail" not checked

Calling Search Space:

SJCInternational

"Voicemail" checked

Calling Search Space:

SJCInternational

Destination: +14085554146

Calling Search Space:

PSTNReroute

Line 1 on Device

Display (Caller ID)

Line Text Label

Aristotle Boyle

4146

CSS might be set to a more restricted CSS

CSS might be set to a more restricted CSS

Forward Unregistered implements an alternate route through the PSTN in case the endpoint is unregistered. This makes sense only for endpoints in remote sites with local PSTN access for which an alternate route through the PSTN can be established.

If a non-DID is provisioned or a DN for which

PSTN reroute does not make sense, then check

"Voicemail" and set the CSS to SJCInternational or some other CSS that can reach the voicemail pilot.

Full name of the user associated with the number. If the number is not associated with a user then, provision a meaningful name (for example, Bldg. 31

Lobby).

Makes sure that the last four digits of the directory number are displayed next to the line button on the phone. This setting exists only for lines on devices supporting line text labels.

The external phone number mask is not referenced anywhere in the provisioned dial plan and can be set to anything. For phones on which the external phone number mask determines the text in the first line on the phone display, the mask can be set to something that creates a meaningful label.

2-72

Cisco Preferred Architecture for Enterprise Collaboration 10.x

January 22, 2015

Chapter 2 Call Control

Deployment Overview

Add the Device to Devices Controlled by the User

For devices associated with users, after provisioning the device in the End User Configuration of the respective user in the Device Information section in Unified CM Administration, make sure that the device is associated with the user. The recommended way to achieve this is to select Device Association and search for devices where the directory number matches the phone number of the user.

Configure the Line Association for Presence

To determine the presence state of a user, only the line appearances (per DN and device) explicitly associated for presence are considered. To make sure that all line appearances of a user's directory numbers are considered for presence, in the End User Configuration of the respective user in the section on Device Information in Unified CM Administration, select Line Appearance Association for

Presence and associate all line appearances.

Verify the User's Primary Extension

To make sure that the user's directory URI synchronized from LDAP propagates to the directory number, select the Primary Extension in the Directory Number Associations section in the End User

Configuration of the respective user in Unified CM Administration.

Jabber Provisioning

Service Discovery enables Jabber to establish configuration automatically. The Jabber client gets its configuration through Unified CM User Discovery Service (UDS). It is the recommended configuration and is preferred over the older manual configuration.

The services are configured through UC services. A Service profile specifies which UC services to use.

Each user is associated with a service profile.

Table 2-67

shows the UC services that can be made available to Jabber clients. Those services are configured in User Management > User Settings > UC service.

Table 2-67 UC Services

UC Service Type

IM and Presence

Directory

CTI

Voicemail

Conferencing

Comment

Create an IM and Presence service for each IM and Presence node.

Create a Directory service for each active directory server. Do not select

"Use UDS for Contact Resolution" when integrating with LDAP directly.

When using UDS for Contact Resolution, the Unified CM user scalability decreases.

Create a CTI service for each Unified CM running the CTI Manager service.

This is used for desk phone control mode. Load balance the CTI load across all Unified CM call processing nodes.

Create a Voicemail service for each Unity Connection node.

Jabber can be integrated with Cisco WebEx Meetings Server or Cisco WebEx

Meeting Center. In this design, we cover the integration with Cisco WebEx

Meetings Server.

January 22, 2015

Cisco Preferred Architecture for Enterprise Collaboration 10.x

2-73

Chapter 2 Call Control

Deployment Overview

Associate the UC services to a Service Profile. A Service Profile is then associated to each user. For deployments with more than two Unified CM call processing subscribers, spread the CTI load equally across all Unified CM call processing subscribers and ensure that the CTI scalability limit is not exceeded on any single Unified CM call processing subscriber running the CTI Manager service. To associate Jabber clients with another Unified CM call processing subscriber running the CTI Manager service, configure another Service Profile with the relevant CTI UC service settings.

For users connected to the internal enterprise network (not using Cisco Collaboration Edge), directory search Contact Sources can be provided through UDS or through LDAP. With LDAP, Enhanced

Directory Integration (EDI) for Windows desktops and Basic Directory Integration (BDI) for Mac, iOS, and Android are available. BDI and EDI can co-exist. The Contact Source or directory can be configured through the jabber-config.xml file or through the directory UC service which takes precedence. The recommendation is to configure a jabber-config.xml file that is uploaded onto the Unified CM TFTP server. The jabber-config.xml file is also used to enable URI dialing for Jabber clients.

Example 2-5

shows a jabber-config.xml file to enable URI dialing for Jabber clients. This is the recommended minimum. Additional configuration options can be added.

Example 2-5 jabber-config.xml File to Enable URI Dialing

<?xml version="1.0" encoding="utf-8"?>

<config version="1.0">

<Policies>

<EnableSIPURIDialling>true</EnableSIPURIDialling>

</Policies>

</config>

For more details, refer to the following documentation:

Configuration and Administration of IM and Presence on Cisco Unified Communications Manager

http://www.cisco.com/c/en/us/support/unified-communications/unified-communications-managercallmanager/products-installation-and-configuration-guides-list.html

Deployment and Installation Guide for Cisco Jabber

http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/jabber/10_5/CJAB_BK_D6497E98_00_dep loyment-installation-guide-ciscojabber.html

ILS Configuration for Multi-Cluster Deployments

When the Intercluster Lookup Service (ILS) is configured on multiple clusters, ILS updates Unified CM with the current status of remote clusters in the ILS network.

The ILS cluster discovery service allows Unified CM to learn about remote clusters without the need for an administrator to manually configure connections between each cluster.

The ILS cluster discovery service enables UDS-based service discovery for Jabber clients in multi-cluster environments. In addition, ILS is the foundation for global dial plan replication (GDPR), which allows the exchange of reachability information for both alphanumeric URIs and numeric destinations between Unified CM clusters to enable deterministic intercluster routing for those destinations.

2-74

Cisco Preferred Architecture for Enterprise Collaboration 10.x

January 22, 2015

Chapter 2 Call Control

Deployment Overview

To create an ILS network of multiple Unified CM clusters, perform the following tasks:

Assign Unique Cluster IDs for Each Unified CM Cluster in the Network

Activate ILS on the First ILS Hub Cluster in the Network

Activate ILS on the Remaining ILS Clusters in the Network

Consider UDS Certificate Requirements

Assign Unique Cluster IDs for Each Unified CM Cluster in the Network

The cluster IDs defined in the Unified CM cluster enterprise parameters have to be unique. See

Table 2-4

for details.

Activate ILS on the First ILS Hub Cluster in the Network

Forming an ILS network starts with activating ILS on the first Unified CM cluster. This done by changing the role from Standalone Cluster to Hub Cluster in the ILS Configuration menu in Unified CM

Administration.

Table 2-68

shows the settings to be applied when activating ILS on the first Unified CM cluster.

Table 2-68

Setting

Role

ILS Activation on First Unified CM Cluster

Value

Hub Cluster

Exchange Global Dial Plan

Replication Data with Remote

Clusters

Advertised Route String

Synchronize Clusters Every

Checked us.route

2

Comment

ILS is activated by changing the role from Standalone Cluster to

Hub Cluster.

Makes sure that URI and numeric reachability information is exchanged with remote clusters.

The advertised route string is the location attribute tied to all

URI and numeric reachability information advertised by this

Unified CM cluster. Remote clusters trying to reach any of the destinations advertised by this cluster will establish the route to this destination by matching the learned SIP route string against

SIP route patterns provisioned on the remote cluster.

Setting the synchronization interval to a reasonably small interval makes sure that changes are picked up by remote clusters after a short period of time. The overhead of a short synchronization interval is limited because GDPR uses an incremental update algorithm that exchanges only delta information if any changes occurred since the last update.

ILS Authentication

Use Password

Password

Checked

<some password>

Password based authentication is selected.

Choose a secure password. This password is shared among all

Unified CM clusters participating in the ILS network.

When activating ILS by changing the role from Standalone Cluster to Hub Cluster in Unified CM

Administration, an ILS Cluster Registration pop-up appears and asks you to input a Registration Server.

When activating ILS on the first Unified CM cluster, no registration server information is available, so the input in that pop-up should be left empty.

Cisco Preferred Architecture for Enterprise Collaboration 10.x

January 22, 2015

2-75

Chapter 2 Call Control

Deployment Overview

Activate ILS on the Remaining ILS Clusters in the Network

Adding more Unified CM clusters to the ILS network requires the same process as activating ILS on the first Unified CM cluster: changing the role from Standalone Cluster to Hub Cluster in the ILS

Configuration menu in Unified CM Administration.

Table 2-69 shows the settings to apply when activating ILS on the remaining Unified CM clusters.

Table 2-69

Setting

Role

ILS Activation on Additional Unified CM Clusters

Exchange Global Dial Plan

Replication Data with Remote

Clusters

Advertised Route String

Synchronize Clusters Every

Value

Hub Cluster

Checked emea.route

2

Comment

ILS is activated by changing the role from Standalone Cluster to

Hub Cluster.

Makes sure that URI and numeric reachability information is exchanged with remote clusters.

Make sure that the SIP route string for each cluster is unique to allow for deterministic routing based on these route strings.

The example here indicated that this is a Unified CM cluster serving EMEA destinations.

Make sure to use the same synchronization interval on all clusters for consistency.

ILS Authentication

Use Password

Password

Checked

<some password>

Password based authentication is selected.

Choose a secure password. This password is shared among all

Unified CM clusters participating in the ILS network.

Consider UDS Certificate Requirements

To enable UDS-based service discovery, the UDS process on each Unified CM cluster tries to establish connectivity with the UDS processes running on remote Unified CM clusters to learn about the remote clusters' UDS nodes. For this server-to-server communication, TLS connections between the

Unified CM clusters' publishers are established and the remote peers' certificates are validated during

TLS connection setup. To prevent this validation from failing, the Tomcat certificates of the Unified CM publisher nodes of all Unified CM clusters must be exchanged.

Also, this server-to-server communication is one of the reasons why TLS Web Client Authentication has to be in the X.509 extended key usage when issuing Tomcat certificates on an external CA (see

Table 2-3 ).

To exchange the Unified CM cluster publisher certificates, perform the following tasks:

On each Unified CM cluster in the Cisco Unified Operating System Administration, use Bulk

Certificate Management to export the cluster's Tomcat certificate to a central SFTP server.

After Tomcat certificates from all clusters have been exported, use the Consolidate option in Cisco

Unified Operating System Administration on one of the clusters to consolidate all Tomcat certificates into one file.

On each Unified CM cluster in the Cisco Unified Operating System Administration, use Bulk

Certificate Management to import the consolidated file of all Tomcat certificates.

2-76

Cisco Preferred Architecture for Enterprise Collaboration 10.x

January 22, 2015

Chapter 2 Call Control

Deployment Overview

This process makes sure that all Tomcat certificates of all Unified CM cluster publishers are imported in the local certificate stores of all Unified CM clusters as Tomcat trust, so that the certificate validation happening as part of TLS connection setup as part of the UDS communication between clusters does not fail.

GDPR Configuration (Multi-Cluster Only)

When Global Dial Plan Replication (GDPR) is enabled across an ILS network, remote clusters in an ILS network share global dial plan data, including the following:

Directory URIs

+E.164 and ESN patterns

PSTN failover numbers

GDPR allows you to create a global dial plan, including intercluster dialing of directory URIs and alternate numbers, that spans across an ILS network. GDPR allows you to quickly configure the global dial plan across the ILS network without the need to configure each dial plan component on each cluster separately.

Configuring GDPR requires the following steps in addition to activating ILS as described in the previous section:

Advertise URIs

Configure Advertised Patterns

Configure Partitions for Learned Numbers and Patterns

Configure Intercluster Trunks

Configure SIP Route Patterns

Advertise URIs

In this document we assume that URIs for users are automatically provisioned based on the directory

URI synchronized for each user from the email attribute of the corporate directory (see

Table 2-45 ) and

the primary extension configure for the user. By default the Advertise Globally via ILS option is set for these URIs automatically created in partition Directory URI. Also make sure to set the Advertise

Globally via ILS option on all URIs you have provisioned in addition to the ones created automatically.

Configure Advertised Patterns

To keep the route plan small on remote clusters, in this design only summary patterns are advertised for each +E.164 and ESN range hosted on each cluster. For the example cluster hosting the sites RTP, RCD, and SJC, the patterns shown in

Table 2-70 need to be configured as GDPR advertised patterns. For

information on the DID ranges and ESN ranges used in the example, refer to

Table 2-10 and Table 2-11 .

January 22, 2015

Cisco Preferred Architecture for Enterprise Collaboration 10.x

2-77

Chapter 2 Call Control

Deployment Overview

Table 2-70

Pattern

+14085554XXX

81404XXX

Patterns Advertised via GDPR

Pattern Type

+E.164 Number

Enterprise Number

81405XXX

+19195551XXX

81911XXX

81912XXX

+19725555XXX

81975XXX

81976XXX

8099XXXX

Enterprise Number

+E.164 Number

Enterprise Number

Enterprise Number

+E.164 Number

Enterprise Number

Enterprise Number

Enterprise Number

PSTN Failover Setting Comment

Use Pattern as PSTN Failover Number Site SJC DID range

Apply Strip Digits and Prepend Digits to Pattern and Use for PSTN Failover

PSTN Failover Strip Digits: 4

ESN range of SJC DIDs. Strip digits and prefix to transform from ESN to

PSTN failover number.

PSTN Failover Prepend Digits:

+1408555

Don't use PSTN Failover ESN range of SJC non-DIDs. No

PSTN failover possible.

Use Pattern as PSTN Failover Number Site RTP DID range

Apply Strip Digits and Prepend Digits to Pattern and Use for PSTN Failover

PSTN Failover Strip Digits: 4

ESN range of RTP DIDs. Strip digits and prefix to transform from ESN to

PSTN failover number.

PSTN Failover Prepend Digits:

+1919555

Don't use PSTN Failover ESN range of SJC non-DIDs. No

PSTN failover possible.

Use Pattern as PSTN Failover Number Site RCD DID range

Apply Strip Digits and Prepend Digits to Pattern and Use for PSTN Failover

PSTN Failover Strip Digits: 4

ESN range of RCD DIDs. Strip digits and prefix to transform from

ESN to PSTN failover number.

PSTN Failover Prepend Digits:

+1972555

Don't use PSTN Failover

Don't use PSTN Failover

ESN range of RCD non-DIDs. No

PSTN failover possible.

ESN ranges for conferences on this cluster (see

Table 2-11 ).

Advertising both the +E.164 range and the ESN range for each site makes sure that both formats can be used as the intercluster dialing habit on the remote clusters learning this information.

Configure Partitions for Learned Numbers and Patterns

Numeric patterns (+E.164 and ESN) learned from remote clusters are added to the local route plan into predefined partitions. The Partitions for Learned Numbers and Patterns menu in Unified CM

Administration allows you to define differentiated partitions for each type of learned information. In this design we do not need this differentiation and simply configure GDPR to learn all remote numeric patterns in a single partition, onNetRemote (see

Table 2-13

).

Table 2-71 summarizes the settings for the GDPR partitions.

2-78

Cisco Preferred Architecture for Enterprise Collaboration 10.x

January 22, 2015

Chapter 2 Call Control

Deployment Overview

Table 2-71 GDPR Partition Settings

Setting

Partition for Enterprise

Alternate Numbers

Value

onNetRemote

Partition for +E.164

Alternate Numbers

Partition for Enterprise

Patterns

Comment

"Mark Learned Numbers as Urgent" unchecked onNetRemote

"Mark Learned Numbers as Urgent" checked

Marked as urgent to avoid inter-digit timeout on +E.164 on-net intercluster calls.

onNetRemote

Partition for +E.164

Patterns

"Mark Learned Numbers as Urgent" unchecked

"Mark Variable Length Patterns as Urgent" unchecked onNetRemote

"Mark Learned Numbers as Urgent" checked

Marked as urgent to avoid inter-digit timeout on +E.164 on-net intercluster calls.

"Mark Variable Length Patterns as Urgent" unchecked

Configure Intercluster Trunks

The GDPR exchange only makes sure that all URI and numeric reachability information is exchanged between Unified CM clusters and associated with a SIP route string as the location attribute. Sessions between clusters need SIP trunks to be established. In this design we assume full-mesh SIP trunks between all Unified CM clusters, with a maximum of three Unified CM clusters. The maximum of three

Unified CM clusters makes sure that the topology of the full mesh of SIP trunks is manageable. If more than three Unified CM clusters are required, then adding Unified CM Session Management Edition

(SME) is recommended to simplify the topology to a hub-and-spoke topology with SME as the hub and all other Unified CM clusters as spokes or leaf clusters.

Regular SIP intercluster trunks are used for GDPR routing. SIP trunk ST_UCM_EMEA, as with the settings shown in

Table 2-61

, is an example of an intercluster trunk provisioned for GDPR routing.

Configure SIP Route Patterns

SIP route patterns tie together the SIP route strings learned via GDPR and the SIP trunk topology. Think of it as if a GDPR route strings tells us "where" a learned URI or numeric pattern is located, and we need route patterns matching on these route strings to tell how to get to this destination.

To achieve full GDPR reachability, we need to make sure that each SIP route string advertised via GDPR can be routed according to the provisioned SIP route patterns.

Table 2-72 summarizes the trunks, route

groups, route lists, and SIP route patterns that need to be provisioned to enable full intercluster GDPR routing between two Unified CM clusters.

January 22, 2015

Cisco Preferred Architecture for Enterprise Collaboration 10.x

2-79

Chapter 2 Call Control

Deployment Overview

Table 2-72

Component

SIP Trunk

GDPR Routing with Two Unified CM Clusters

Route Group with above SIP trunk as member

Route List with above route group as member

SIP Route String

US Cluster

ST_UCM_EMEA

UCM_EMEA

RL_UCM_EMEA us.route

EMEA Cluster

ST_UCM_US

UCM_US

RL_UCM_US emea.route

SIP Route Pattern pointing to above route list emea.route in partition onNetRemote us.route in partition onNetRemote

Comment

SIP trunk on each cluster to the other

Unified CM cluster (see

Table 2-61

)

Dedicated route group for the intercluster trunk (see

Table 2-63 )

Dedicated non-LRG route list for the intercluster trunk (see

Table 2-64 )

SIP route string advertised by the

Unified CM cluster

Provisioned SIP route pattern matches on the SIP route string advertised by the other Unified CM cluster

Example GDPR Call Flow

With the above configuration, this section describes how a call would be routed if +14085554001 is dialed on an endpoint with class of service "international" registered to the EMEA cluster in the above example.

1.

The dialed digits (+14085554001) are matched against the dial plan on the EMEA cluster, using the calling device’s CSS XXXInternational, where XXX represents a site code of a site provisioned on the EMEA cluster. The actual site-specific dialing normalization is irrelevant here.

The important point is that CSS XXXInternational contains at least the following partitions (see

Table 2-18 ; again XXX represents a site code while XX represents some dialing domain identifier):

DN

Directory URI

URI

ESN

onNetRemote

XXXIntra

XXtoE164

XXPSTNNational

PSTNInternational

B2B_URI

USEmergency

The dialed digits (+14085554001) in these partitions have three matches:

+14085554XXX in partition onNetRemote learned from the US cluster with SIP route string us.route (see

Table 2-70

)

\+! in partition PSTNInternational (see

Table 2-29 )

\+!# in partition PSTNInternational (see Table 2-29 )

2-80

Cisco Preferred Architecture for Enterprise Collaboration 10.x

January 22, 2015

Chapter 2 Call Control

Deployment Overview

2.

3.

4.

5.

6.

Because +14085554XXX in partition onNetRemote is inserted into the route plan as urgent pattern

(see Table 2-71 ) and this pattern at this point is the best match, digit collection is stopped

immediately and the call is routed based on this best match.

+14085554XXX in partition onNetRemote is a GDPR learned pattern and is associated with SIP route string us.route. Hence, us.route is matched against the configured SIP route patterns on the

EMEA cluster, again using the calling device's CSS XXXInternational.

The only match is SIP route pattern us.route in partition onNetRemote.

The call on the EMEA cluster is extended to SIP trunk ST_UCM_EMEA, dereferencing the route list RL_UCM_EMEA the matched SIP route pattern us.route points to and route group

RG_UCM_EMEA (see

Table 2-72

)

On the US cluster, the inbound CSS ICTInbound of SIP trunk ST_UCM_EMEA (see

Table 2-61

) is used to route the inbound call to destination +14085554001.

CSS ICTInbound has these partitions:

DN

ESN

URI

Directory URI

In these partitions the only (potential) match is on a +E.164 directory number \+14085554001

(marked urgent) in partition DN. If this directory number exists, then the call is extended to all associated devices.

Routing of remotely dialed ESN destinations follows the exact same flow, with the only exception being that the final lookup on the US cluster using CSS ICTInbound in that case would find a match on an ESN in partition ESN.

IM and Presence Intercluster

To create a fully meshed presence topology, each Cisco IM and Presence cluster requires a separate peer relationship for each of the other Cisco IM and Presence clusters within the same domain. The address configured in this intercluster peer is the IP address of the remote Unified CM cluster IM and Presence publisher node.

The interface between each Cisco IM and Presence cluster is two-fold: an AXL/SOAP interface and a signaling protocol interface (SIP or XMPP). The AXL/SOAP interface, between publisher-only servers of an IM and Presence cluster, handles the synchronization of user information for home cluster association, but it is not a full user synchronization. The signaling protocol interface (SIP or XMPP) is a full mesh encompassing all servers within the deployment. It handles the subscription and notification traffic, and it rewrites the host portion of the URI before forwarding if the user is detected to be on a remote Cisco IM and Presence cluster within the same domain.

When Cisco IM and Presence is deployed in an intercluster environment, a presence user profile should be determined. The presence user profile helps determine the scale and performance of an intercluster presence deployment and the number of users that can be supported. The presence user profile helps establish the number of contacts (or buddies) a typical user has, as well as whether those contacts are mostly local cluster users or users of remote clusters.

January 22, 2015

Cisco Preferred Architecture for Enterprise Collaboration 10.x

2-81

Chapter 2 Call Control

Deployment Overview

Survivable Remote Site Telephony (SRST) Deployment

Configure SRST at each remote site in order to provide call processing survivability in case the WAN to the remote site fails. With SRST, if the WAN fails, phone calls can still be made within the remote site or out to the PSTN.

Deployment

Deploy one Cisco Integrated Services Router (ISR) for each remote sites that you want to enable for

SRST.

Provisioning

To configure SRST, you must perform the configuration on both Unified CM and the SRST router.

On Unified CM:

Configure an SRST Reference for each remote site, and associate this SRST Reference in the device pool of the remote phones.

Configure Call Forwarding Unregistered (CFUR) on the DNs of the remote phones to use the +E.164 number and the AAR CSS. In case the WAN fails, the call will use this information to get routed via the PSTN.

On the SRST router:

Configure SRST on each remote branch router. Since our recommendation is to use SIP phones, use the voice register global and voice register pool commands. Use the voice service voip/sip command to bind the IP addresses of the source interface and enable the registrar capability.

Configure DHCP for the phones in the remote branch. The DHCP server may be configured on the

SRST router or on other network service resources.

If the WAN fails, the SIP phones will register with their +E.164 extensions. In order to allow users to call other local users by their four-digit extensions, configure a voice translation profile that is referenced as an incoming profile in the voice register pool configuration. This voice translation profile transforms the called number from four digits to the complete +E.164 number.

Configure POTS dial-peers to allow local access to the PSTN in case the WAN is down. Configure translation voice profiles in order to comply with the service provider’s PSTN dialing requirements.

For more details on dial-peer configuration, refer to the section that describes how to

Deploy Cisco

Unified Border Element .

The SRST configuration in Example 2-6 is just a partial configuration to illustrate some of the concepts

discussed in the previous paragraphs. It does not cover the full SRST configuration. For instance, configuration to reach the Cisco Unity Connection server in the main site is covered in the chapter on

Core Applications .

2-82

Cisco Preferred Architecture for Enterprise Collaboration 10.x

January 22, 2015

Chapter 2 Call Control

Deployment Overview

Example 2-6 SRST Partial Configuration

voice service voip

allow-connections sip to sip sip

bind control source-interface GigabitEthernet0/0.241

bind media source-interface GigabitEthernet0/0.241

registrar server

!

voice register global

mode srst

max-dn 100

max-pool 100

!

voice register pool 1

translation-profile incoming 4-digit-rtp

id network 10.0.94.0 mask 255.255.255.0

!

voice translation-rule 1

rule 1 /\(^1...\)$/ /+1919555\1/

!

voice translation-profile 4-digit-rtp

translate called 1

!

For more details on configuring SRST, refer to the Cisco Unified SCCP and SIP SRST System

Administrator Guide, available at http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cusrst/admin/sccp_sip_srst/configuration/g uide/SCCP_and_SIP_SRST_Admin_Guide.html

Extension Mobility

Cisco Extension Mobility allows users to temporarily access their Cisco Unified IP Phone configuration

– such as line appearances, services, and speed dials – from other Cisco Unified IP Phones.

One or two Unified CM call processing nodes can actively handle Extension Mobility requests. The benefits of adding a second Unified CM call processing node for Extension Mobility are resiliency and increased capacity. In this scenario, a load balancer is required to send the requests to both Unified CM nodes. Cisco IOS Server Load Balancing can be used, for example.

Extension Mobility Cross Cluster (EMCC) provides the ability to perform Extension Mobility logins between clusters within an enterprise. This feature is not covered in this guide. For more details on

EMCC, refer to the

Cisco Collaboration System 10.x SRND

and the EMCC product documentation.

Deploying Extension Mobility

To deploy Extension Mobility, perform the following tasks:

Ensure that the Cisco Extension Mobility service is activated on one or two Unified CM call processing servers.

Add an IP Phone Service for Extension Mobility. A secure IP Phone Services URL using HTTPS in addition to a non-secure URL can be configured. The non-secure URL is http://<IPAddress>:8080/emapp/ EMAppServlet?device=#DEVICENAME#

You can either make this service available to all phones in the cluster by selecting Enterprise

Subscription or make it available to selected phones by subscribing those phones to this service.

Cisco Preferred Architecture for Enterprise Collaboration 10.x

January 22, 2015

2-83

Chapter 2 Call Control

Deployment Overview

For each user that will use Extension Mobility, create at least one Device Profile. Since a Device

Profile is tied to a specific user, the Device Profile is usually referred to as a User Device Profile. If a Device Profile is not created for a user, that user will not be able to log in with extension mobility.

Associate the device profile to a user for extension mobility. If CTI is needed, also associate the profile to be a CTI controlled device profile.

For each phone that can be used for users to log in, enable Extension Mobility. For Cisco DX Series endpoints, also enable Multi-User (the phone will reset). For Cisco TelePresence endpoints using the TC software (for instance, Cisco TelePresence EX and SX Series endpoints), ensure that the

TelePresence endpoints are not provisioned in Cisco TelePresence Management Suite (TMS), otherwise the sign-in button will not be available on the endpoint.

On the DN configuration, configure the association of the appropriate user to the line. This allows the DN to send presence information for that user if the line of that phone is in use. For example:

User B is using Jabber and is monitoring user A. User A logs into a phone with Extension

Mobility and has a User Device Profile with the DN associated to himself/herself. When user A goes off-hook, this presence information will be reported on the Jabber client of user B.

For more details on Extension Mobility, refer to the Features and Services Guide for Cisco Unified

Communications Manager, available at http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/admin/10_0_1/ccmfeat/CUCM_BK_

F3AC1C0F_00_cucm-features-services-guide-100.html

Busy Line Field (BLF) Presence

The BLF Presence feature allows a user (watcher) to monitor the real-time status of another user at a directory number or SIP URI from the device of the watcher. A watcher can monitor the status of the user by using the following options:

BLF/SpeedDial buttons

Missed call, placed call, or received call lists in the directories window

Shared directories, such as the corporate directory

BLF Presence is not based in Cisco Unified IM and Presence.

Deploying BLF Presence

Enable the BLF for Call List enterprise parameter (see Table 2-4 ).

Configure the cluster-wide service parameters for BLF presence.

To use BLF presence group authorization, configure BLF presence groups and permissions.

Apply a BLF presence group to the directory number, SIP trunk, phone that is running SIP, phone that is running SCCP, end user, and application user (for application users that are sending BLF presence requests over the SIP trunk) in Cisco Unified Communications Manager Administration.

To allow BLF presence requests from a SIP trunk, select the Accept Presence Subscription option in the SIP Trunk Security Profile Configuration window (see

Table 2-59

).

Configure the SUBSCRIBE calling search space and apply the calling search space to the phone, trunk, or end user, if required.

For BLF/SpeedDial buttons on the phones, customize phone button templates for the

BLF/SpeedDial buttons or add them directly to the phones.

2-84

Cisco Preferred Architecture for Enterprise Collaboration 10.x

January 22, 2015

Chapter 2 Call Control

Deployment Overview

Deploying Computer Telephony Integration (CTI)

Activate the CTI Manager service on the Unified CM call processing nodes that need the

CTI Manager service.

For redundancy, through the CTI application administration, select a primary and backup

Unified CM node running the CTI Manager service,

Download the TAPI client software for applications using TAPI.

If possible, for a given CTI-enabled endpoint, configure the same Unified CM call processing node for CCM registration and for CTI Manager monitoring and control.

Ensure the CTI load is spread across all Unified CM nodes running the CTI Manager and that the

CTI capacity limits are not exceeded. For example, with Jabber clients, if two Unified CM call processing pairs are required, spread the registration across the two pairs; also, if the Jabber clients are configured with the ability to be in deskphone mode, spread the CTI Manager connectivity across the two pairs. This can be achieved with multiple Service Profiles with different CTI profiles associated. Ensure the number of Jabber clients in deskphone mode monitored and controlled by each Unified CM running the CTI Manager service does not exceed the CTI capacity limit.

January 22, 2015

Cisco Preferred Architecture for Enterprise Collaboration 10.x

2-85

Deployment Overview

Chapter 2 Call Control

2-86

Cisco Preferred Architecture for Enterprise Collaboration 10.x

January 22, 2015

Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertisement

Table of contents