Cisco Unified Communications Manager (CallManager)

Downloads Setting up Intercluster Trunks with Three or More Cisco CallManagers Related Documents • Setting up Intercluster Trunks with Three or More Cisco CallManagers[Cisco Unified Communications Manager (CallManager)] • Cisco Unified Communications Manager (CallManager) Configuration Examples and TechNotes • Cisco Unified Communications Manager (CallManager) Troubleshooting TechNotes • Cisco Unified CallManager Trunks- Cisco Unified Communications SRND Based on Cisco Unified CallManager 4.x [Cisco Unified Communications Manager (CallManager)] • Cisco Unified CallManager Trunks- Cisco Unified Communications SRND Based on Cisco Unified CallManager 4.x [Cisco Unified Communications Manager (CallManager)] More... Related Products/Technology • Cisco Unified Communications Manager (CallManager) Related Discussion

Introduction

An inter-cluster link is an H.323 connection that allows two separate Cisco CallManager clusters to route calls between each other over an IP cloud. When you connect two or more 3.1.x or 3.2.x multi-server CallManager clusters, improper trunk configuration might cause problems with call routing between the two clusters. Cisco has enhanced and simplified the configuration in CallManager version 3.3.x.

• Cluster-A

  • CM-A1

  • CM-A2

  • CM-A3

  • IPPhone-A1 (registered with CM-A1)

  • IPPhone-A2 (registered with CM-A2)

  • IPPhone-A3 (registered with CM-A3)

• Cluster-B

  • CM-B1

  • CM-B2

  • IPPhone-B1 (registered with CM-B1)

  • IPPhone-B2 (registered with CM-B2)

• Inter-Cluster Trunk

  • CM-A1 «-» CM-B1

Prerequisites

Requirements

Readers of this document should understand how to administer CallManager networks.

Components Used

The information in this document is based on CallManager version 3.1x, 3.2x, and 3.3x.

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Conventions

For more information on document conventions, refer to the Cisco Technical Tips Conventions.

Problem

IPPhone-A2 and IPPhone-A3 are not able to perform any calls over the inter-cluster trunk.

This is because, when IPPhone-A2 attempts to establish a call, the call is initiated on CM-A2 and points to CM-B1. Because only one inter-cluster trunk has been configured (between CM-A1 and CM-B1), CM-B1 is not aware of the existence of CM-A2 as an H.323 endpoint. As a result, the call is rejected by CM-B1 and it fails.

3.1.x or 3.2.x Solutions

There are three ways to resolve the issue. These solutions are explained in the next sections. In addition, pros and cons are listed for each solution.

Solution 1—Creation of a Pseudo-Gatekeeper on Cluster-A and Cluster-B, then “Allow Anonymous Calls”

The first solution involves a Gatekeeper Configuration that allows Anonymous Devices.

This solution allows each of the inter-cluster endpoints to receive an incoming call from an unknown H.323 endpoint. Thus, the call from CM-A2 can be accepted and established.

When you configure the Gatekeeper, complete the necessary fields as per the administration guide.

Note: Pay special attention to the Allow Anonymous Calls and Device Protocol fields, which are marked in this screen shot:

Pros

• Simple Configuration—No modification of Call-Routing configuration is required.

• Scalability—Single device configuration.

• Scalability—You only need to configure a new cluster to connect it to the network.

Cons

• Redundancy—No outgoing redundancy, in the event of failure of explicitly configured servers (in this example, CM-A1 or CM-B1). Single route to remote cluster.

• Elegance—Not a “clean” solution, because a “fake” Gatekeeper is created.

• Caution: Allows unknown inter-cluster trunk endpoints (example: an unknown Cisco CallManager cluster) to establish calls to the cluster.

Solution 2—Explicit Configuration of an Inter-Cluster Trunk for Each Remote Cisco CallManager

This solution requires you to configure explicit inter-cluster trunks on each Cisco CallManager cluster, each of which point to all remote Cisco CallManager servers. It is not necessary to modify Call-Routing; it should remain the same as with a single inter-cluster trunk.

This solution allows each cluster to be “aware” of the remote servers. Thus, the call from CM-A2 is accepted and established.

Pros

• Simple Configuration—No modification of Call-Routing configuration is required.

Cons

• Redundancy—No outgoing redundancy, in the event of failure of primary servers (in this example, CM-A1 or CM-B1).

• Scalability—A quasi-full mesh is required.

• Scalability—You must reconfigure all clusters when a new cluster is added to the network.

Solution 3—Explicit Configuration of an Inter-Cluster Trunk for Each Remote Cisco CallManager Included in Route-Lists

This solution requires you to configure explicit inter-cluster trunks on each Cisco CallManager cluster, each of which point to all remote Cisco CallManager servers. It is necessary to modify Call-Routing: create a route list that includes a route group that contains all configured inter-cluster trunks, in order of preference. This route list should be the destination of the route pattern that is responsible for inter-cluster call routing.

This solution allows each cluster to be “aware” of the remote servers. Thus, the call from CM-A2 is accepted and established. It also allows calls to be established on backup trunks, in case the primary trunk or server goes down.

Pros

• Redundancy—Outgoing redundancy, in the event of failure of primary servers (in this example, CM-A1 or CM-B1).

Cons

• Complexity—Modification of Call-Routing configuration is required.

• Scalability—A quasi-full mesh is required.

• Scalability—You must reconfigure all clusters when a new cluster is added to the network.

3.3.x Enhancement and Configuration

Cisco CallManager 3.3.x has introduced a new configuration interface that makes it easier to configure redundant inter-cluster trunks, when you must use Inter-Cluster Trunk protocol. In earlier CallManager versions, multiple gateways and a complex configuration were required, to add the same level of redundancy.

Configuration of a Single Inter-Cluster Trunk with Multiple IP Endpoints

Cisco CallManager 3.3.x inter-cluster trunk configuration requires the administrator to create a single Gateway on each cluster with the IP addresses of up to three remote CallManager servers. This single gateway will be available to all CallManager servers in their respective cluster. To set the priority, configure the remote CallManager in the order that you prefer.

For additional information on the configuration of trucks in CallManager 3.3x, refer to Trunk Configuration.

Cisco Support Community - Featured Conversations

Related Information

• Voice Technology Support
• Voice and Unified Communications Product Support
• Troubleshooting Cisco IP Telephony
• Technical Support - Cisco Systems