15.2 ILS Overview

This topic describes the purpose of the ILS and GDPR.

Dial Plan Scalability Issues in Large Networks

  • Call-routing information between separate call-routing domains must be manually configured:
    1. Full-mesh configuration
      • Extremely complex, suitable for small networks only
    2. Hub-and-spoke configuration when centralized call-routing entities (SIP network services or H.323 gatekeepers) are used
      • Scales better than full-mesh topologies
      • Requires redundant deployment of central services
  • Changes must be manually configured.
  • PSTN backup must be implemented independently at each call-routing domain.
  • No dynamic exchange of call-routing information and no automatic PSTN backup.

In large networks with several call agents, such as Cisco Unified Communications Manager clusters, the implementation and maintenance of dial plans can be very complex.

The use of centralized H.323 gatekeepers or SIP network services reduces complexity. However, dial plan implementation still does not scale well in very large deployments.

Call-routing information must be configured separately at each call-routing domain. This requirement is the cause of the main scalability issues in large networks.

Without centralized services (such as H.323 gatekeepers or SIP network services), a full-mesh configuration is required. In other words, each call control domain must be configured with call-routing information toward all other call-routing domains. This implementation model does not scale at all, and therefore it is suitable for smaller deployments only.

In a hub-and-spoke deployment model, call-routing information for each call-routing domain is configured only once at the centralized call-routing entity. This centralized call-routing entity can be a SIP network service or an H.323 gatekeeper. Such a solution scales better than full-mesh topologies; however, it introduces a single point of failure and therefore requires redundant deployment of the centralized service.

In addition, the centralized call routing must still be manually configured. For example, if telephone number ranges or prefixes are changed at one of the call-routing domains, these changes must also be manually performed at the centralized call-routing service. Further, PSTN backup must be implemented independently at each call-routing domain.

In summary, there is no dynamic exchange of call-routing information between call-routing domains, and there is no automatic PSTN backup.

Review of Multicluster URI Routing

URI routing is based on the host part (the domain) of a URI. A SIP route pattern is configured for each domain, and this route pattern refers to a SIP trunk.

  • Other clusters are reached based on SIP route patterns that match the host portion of the called URI.
  • Requires unique host portions per cluster.

The SIP trunk then points to one or more servers of the remote cluster. To route URIs successfully, the host part of URIs must be unique to each cluster.

The figure shows an example with three Cisco Unified Communications Manager clusters. Each of them uses a dedicated domain (amer.cisco.com, emea.cisco.com, and apac.cisco.com) for the host part of the local URIs. Each cluster has two SIP route patterns and two SIP trunks that refer to the other two sites. This method is a typical implementation of intercluster URI routing.

URI Call-Routing Issues in a Flat Domain Scheme

A flat domain scheme causes issues in multicluster URI routing environments.

If URI host portions are not unique across clusters, URI routing does not work:

  • No cluster identification is possible.
  • Calls to remote destinations cannot be routed correctly.

The type of configuration that is shown in the figure causes problems with URI routing because there is no information in the URI that enables a Cisco Unified Communications Manager to find out the location of the endpoint. If the cluster where the target device is registered is not known, Cisco Unified Communications Manager cannot route the call.

Consequently, a flat domain scheme and any scheme that includes overlapping of domains across clusters are not supported for URI routing.

ILS and GDPR Overview

ILS is a service that allows dynamic discovery of services and exchange of application data across clusters.

  • Calls to remote destinations cannot be routed correctly.
    1. GDPR is an ILS application that exchanges call-routing information,
    2. It supports URIs and numbered call-routing information.
    3. It addresses URI call-routing issues in a flat domain scheme.
    4. It simplifies configuration in large deployments based on dynamic exchange of URIs and numbered call-routing information
    5. It provides a scalable call-routing solution for large deployments.

GDPR is an ILS application that supports the exchange of call-routing information. It allows URIs and numbered call-routing information to be exchanged over an ILS network.

GDPR solves the issue of multicluster URI routing when URI host portions are not globally unique. It further simplifies configuration in large deployments because it dynamically exchanges URIs and numbered call-routing information across all participating clusters.

GDPR offers a flexible and scalable solution for call routing in large Cisco Unified Communications Manager deployments.