Global Dial Plan Replication (GDPR)

by ⋅ Leave a Comment

The need to share dial plan information between multiple call control nodes has been around since gatekeeper, but I find the latest iteration, GDPR, particularly smooth.

Gatekeeper had its downsides: additional hardware costs, lack of URI or +E164 support, and reliance on H323 protocol. CUCM 8 introduced CCD (Call Control Discovery) using SAF (Service Advertisement Framework), but since it required end-to-end EIGRP and a complex configuration, I’ve never known anyone to actually use it. With CUCM 9 came Intercluster Lookup Service (ILS) I did a write up on a year or so ago. The first iteration only supported URIs but was onto something. ILS adds a route string to the database, which tags Directory URIs on each node. Route strings use sip route patterns as opposed to traditional route patterns to dynamically route.

GDPR is simply the addition of numbers and patterns tagged with a route string in ILS. GDPR is supported in CUCM 10+ and uses the following new system partitions:

Directory URI: As soon as the directory number is associated to the end user, this becomes the primary URI on the directory number page.

dna
directoryuri
Global Learned E164 Numbers / Global Learned Enterprise Numbers:

On the directory number page, two new fields “add enterprise alternate number” and “add +E164 alternate number” have been added. Simply check “Advertise Globally via ILS” and these numbers will show up on ILS neighbor clusters as “Global Learned Enterprise Numbers” or “Global Learned E164 Numbers”

numbers

Global Learned E164 Patterns / Global Learned Enterprise Patterns:

Under Call Routing, a new option “Global Dial Plan Replication” has been added. Advertised Patterns is where you can add entire patterns you want to advertise. I find this is easier to manage rather than advertising each number individually; although its nice to have that granularity, it’s usually not necessary.

advertised

To view learned Numbers, Patterns, and Directory URIs, you can find these under “Global Dial Plan Replication” and “View…“, or you can run a traditional route plan report. This is much improved to the “utils ils lookup” needed with CUCM 9.

Intercluster Lookup Service

by ⋅ Leave a Comment

ILS is a new feature service in CUCM 9.0 that allows for sharing of Directory-URIs between clusters.

A Directory URI is much like an email address, formatted like jlevensailor@ciscolab.com where jlevensailor is the user portion and ciscolab.com is the host portion. The user portion is actually case sensitive, but only in the context of CUCM, and is actually an enterprise parameter that can be set to fix this.

The internet uses dns via _sip._udp/tcp or _sips._tls SRV records to route calls between Directory URIs much like email uses mx records. CUCM uses sip route patterns for Directory URIs much like they use standard route patterns for DNs. To tell CUCM that a particular Directory URI is on-net within a particular multi-cluster environment, ILS was introduced.

*It is recommended to first change the Cluster ID enterprise parameter in both clusters to something unique.

To get started, I’ll assume you have a sip trunk has been created already between the two clusters, directly or via SME. Go to Advanced Features and ILS Configuration.

You’ll change the role to “Hub Cluster” and enter the corresponding clusters domain name or ip-address in the popup. For authentication you can either use TLS certificates and exchange certs (default), or you can use a password. Note: The password does require a restart of the ILS service, in case you were already running this.

The advertised route string is what you will create a sip route pattern for on the other cluster, pointing to the ICT so calls can work. When you are done, you can go ahead and start the service if you haven’t already, wait until synchronization finishes and run a route plan report to confirm:

As you can see, any URI on the remote hub cluster will be discovered, not just those that happen to match the advertised route string, which by default is the cluster FQDN.

The call flow is: nbates@car.lab wants to call test@dur.lab. CUCM checks the CSS of nbates@car.lab and proceeds to search for the URI in the list of ordered partitions as usual. When it finds test@dur.lab, it sees that it is a “Learned URI” from sbcucm.dur.lab, and uses the target from the sip route pattern of “dur.lab” I created to call the remote user.

The benefit of this is that sip route patterns won’t have to be created for each remote domain, just one for each ILS partner cluster. I would imagine you’ll start seeing a blank sip route pattern pointed to VCS/Expressway-C for outside domains and a specific ILS route pattern for internal domains/on-net traffic.

Official Documentation HERE