Guest

Cisco Unified Communications Manager (CallManager)

Setting up Intercluster Trunks with Three or More Cisco CallManagers

Document ID: 19200

Updated: Mar 30, 2005

   Print

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

intercluster_1.gif

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.

IPPhone Calls IPPhone-B1 IPPhone-B2
IPPhone-A1 A1 can call B1 A1 can call B2
IPPhone-A2 A2 can not call B1 A2 can not call B2
IPPhone-A3 A3 can not call B1 A3 can not call B2

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.

intercluster_2.gif

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:

intercluster_3.gif

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 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.

intercluster_4.gif

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.

intercluster_4.gif

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.

intercluster_5.gif

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

Related Information

Updated: Mar 30, 2005
Document ID: 19200