Preconceptos claves. 61

■ Dialing from an enterprise directory based on CUCM always goes to a number and not a URI.

■ An endpoint using other data sources (e.g., LDAP) might dial the alpha URI instead.

■ All phones can be called via a SIP URI because the URI is mapped to a DN.

■ Intrasite dialing is a two-step process (normalize and route). A normalization transla-tion pattern might impose calling party transformatransla-tions (in additransla-tion to called party transformations).

■ Calling a URI takes a different path as the only option for calling party transforma-tion is the calling party transformatransforma-tion CSS on calling endpoint or calling endpoint’s device pool.

■ The default “Directory URI” partition will have all auto-generated user-based URIs.

Intercluster Lookup Service

In the case of intercluster (multicluster) dialing, the host part of URIs might identify the home cluster. Reachability is established through SIP route patterns for host parts.

However, it requires a hierarchical URI schema, such as [email protected] and xyz@

siteB.corp.local, instead of a flat schema, such as [email protected] and [email protected].

Moreover, the remote clusters may not be aware of the local cluster’s route strings (SIP route patterns). In this instance, Intercluster Lookup Service (ILS) comes to the rescue.

It enables clusters to exchange URIs and create a URI to route string mapping table, as shown in Figure 4-10 .

ILS allows propagation of individual alpha URIs between call-control agents (clusters) and helps bind an alpha URI with attributes that allow routing to the URI’s home cluster. Each call-control agent replicates its alpha URIs to its neighbors and also announces a SIP route

ptg13358382 string together with the alpha URIs. A SIP route string can be routed based on SIP route

patterns for intercluster call routing of alpha URIs, not based on the URIs’ host part, but on the SIP route string.

The following are the components of end-to-end URI dialing/routing:

^■ ILS networking ^■ URI propagation ^■ SIP trunk ^■ SIP route pattern

There are three important points to consider. SIP connectivity is the foundation for call routing based on SIP route patterns, ILS networking is the foundation for exchange of URI reachability information, and URI propagation is enabled independently of ILS networking.

For ILS networking and URI propagation, the following must be considered:

^■ Call-control agents participating in an ILS network form a hub-and-spoke topology.

^■ Each call-control agent is a hub or spoke. All hubs need to be full-mesh.

^■ Each call-control agent keeps a local copy of all URIs advertised by all other nodes in the ILS network.

^■ Each call-control agent periodically pulls in all changes in all URI catalogs advertised into ILS from directly connected call-control agents (with an interval of 1 to 1440 minutes).

^■ URI catalog updates propagate through the ILS network hop by hop (maximum diameter is three hops).

Figure 4-11 illustrates ILS networking and the relationships between the call-control agents acting as hubs and spokes.

ILS Spoke

ILS Hub ILS Hub

ILS Spoke ILS Spoke

ILS Spoke

Figure 4-11 ILS Networking

ptg13358382 Intercluster Lookup Service 121

To configure ILS, follow these steps:

Step 1. Ensure that a unique Cluster ID is defined for each cluster that is going to par-ticipate in ILS networking. The Cluster ID can be changed from the default by browsing to the Cisco Unified CM Administration page and choosing System

> Enterprise Parameters .

Step 2. Select a node in a cluster that will communicate with other nodes in other call-control agents (clusters). This node is known as XNode and needs to exchange Cisco Tomcat certificates with other XNodes. Using the Bulk Certificate Management option in Cisco Unified Operating System Administration ( Security > Certificates ), exchange the Cisco Tomcat certifi-cates of an XNode with other XNodes.

Step 3. In Cisco Unified CM Administration, choose Advanced Features > ILS Configuration . Set the Role option for the first (full-mesh connected) cluster to Hub Cluster (others can be set as Hub or Spoke as per the topology of the network) as shown in Figure 4-12 . Hub Cluster can be the Session Manager Edition (SME) cluster. Don’t set the Registration Server.

Figure 4-12 ILS Configuration

Step 4. On other clusters, to join an ILS network, set the Role to Spoke Cluster and configure Registration Server as the SME IP address/hostname (in the win-dow that pops up when saving the configuration for spoke cluster).

Step 5. To define the unique SIP route string to be advertised for local alpha URIs, go to Call Routing > Intercluster Directory URI > Intercluster Directory URI Configuration . Check the Exchange Directory URI Catalogs with Remote Clusters check box and provide the route string that should be exchanged with ILS neighbors.

Step 6. Configure SIP route patterns on leaf nodes and SME. SME needs specific SIP route patterns for each SIP route string pointing to the respective leaf cluster, such as siteA.corp.local or siteB.corp.local, whereas leaf clusters only need a

“catch all” SIP route pattern that matches on all SIP route strings and points up to SME, such as *.corp.local.

ptg13358382 At this time, ILS configuration is complete. Remote cluster information and services

pro-vided can be viewed by navigating to Advanced Features > Cluster View . Also, the ILS Configuration menu enables you to monitor the sync state of URI data.