New Practices for CUCM Dial Plans

Traditionally, enterprise dial plans for organizations running Cisco Unified Communications Manager (CUCM) were structured in a simple fashion. Each user would get assigned with an internal extension (aka Directory Number), usually 4 to 6 digits long. Users would also get assigned with an externally reachable phone number (aka DID, or Direct Inward Dial).

In many cases, to simplify the assignment of internal and external numbers, UC engineers would use the last digits of the DID as the internal extension. As such, a user with DID 555-123-4567 would have the 4567 directory number. In this scenario, incoming PSTN call routing is simple: a single rule in the ingress PSTN voice gateway allows for the translation of a whole DID block to its matching internal directory numbers, (ex. 555-123-XXXX matches Directory Numbers XXXX).

In geographies where DID numbers are more expensive, only a select group of users, usually executives, receive DIDs. Other users would need be reached by calling the main office number, before being transferred to the right internal extension by way of a receptionist or automated attendant. As such, it is not rare to see dial plans where users’ internal directory numbers do not match any digits from their assigned DIDs – we dub this as “non-matching DIDs” in this post. In such a case, incoming PSTN call routing rules are a bit more complex: one routing rule must be defined for each DID, mapping each of them to an internal directory number. This is usually achieved by defining an explicit Translation Pattern in CUCM for each DID (ex. 555-123-4567 matches Directory Number 7654).

In recent years, enterprise dial plans have grown more complex, due to the changing nature of technology and the evolving realities of today’s businesses:

• Phone systems are now more centralized, often supporting users in multiple geographies within the same environment.
• Companies are now more geographically distributed, which often implies the need for many distributed phone systems to all be linked together to form a global unified communications footprint.
• E.164 numbers are now officially recognized globally as the standard for phone number representations (ex. +1-514-940-1480), and phone systems need to know how to handle this type of numbers.

All of these factors have contributed to the creation of new features within CUCM to help businesses simplify their enterprise dial plans. Although these features have been around since CUCM 10.0, we have yet to see many organizations taking advantage of these new enhancements. In the past few weeks, however, the Stack8 team came across two customers who do utilize these functionalities to simplify their dial plan – we hope more organizations will follow their footsteps after reading this blog post.

Global Dial Plan Replication (GDPR) and Intercluster Lookup Service (ILS)

In multi-cluster organizations, it is usually a good practice to keep calls between end-users of different systems “on-net,” rather than using the PSTN. This keeps PSTN usage down as well as reduces toll fees, in addition to allowing for more advanced functionalities such as video.

In such a deployment, complex sets of dialing rules would have typically been implemented manually by UC engineers, allowing for proper translation and routing of calls between clusters. Moreover, failover rules would have also been manually added to each cluster, in order to account for situations where bandwidth is insufficient, inter-cluster trunks are down, etc. In situations where toll-bypass, or Tail End Hop Off (TEHO), is required for routing PSTN calls to the least cost gateway, the quantity of dialing rules again multiply to daunting numbers.

With GDPR, these manual dialing rules mostly disappear. Rather, systems will dynamically advertise local numbers, or patterns, to their peer systems using ILS. These advertised patterns will be tagged with a unique location attribute which identifies the cluster from which this pattern originates.

For internal dialing (or “on-net” calls), Enterprise Alternate Numbers and E.164 Alternate are set to be advertised by ILS, such that any user within the organization dialing an internal extension or a DID belonging to the organization will remain “on-net.” In case of a failure for this call to remain “on-net,” an additional parameter of the Directory Number allows the cluster to advertise the Enterprise Alternate Number or the E.164 Alternate Number as a PSTN failover number. In our example, a failed “on-net” call would fall back to the PSTN using a routable E.164 number – no additional configurations required!

For external dialing, local dialing rules will be advertised by each ILS peer, thus creating a dynamic set of toll-bypass rules that can be used by any cluster within the ILS network. In the example below, a pattern for local calls to San Jose (US) is created on the US cluster which, once advertised to peer clusters through ILS, will enable users from any peer cluster to make PSTN calls to San Jose through the US cluster.

Enterprise Alternate Numbers

This new parameter, found in the Directory Number configuration page, allows for the creation of an alternate number, or alias, to be directly tied to said Directory Number. This alternate number can be injected in a local Route Partition, and/or can be advertised via GDPR and ILS.

In multi-site organizations, Directory Numbers usually consist of a Site Prefix, followed by the user’s unique identifier. As an example, a user with directory number 501234 (or 50-1234 for better legibility) would correspond to a user in site 50, with a unique ID of 1234.

Expanding the scope of this example to a multi-cluster environment, the Enterprise Alternate Number feature can be easily used to dynamically replicate Directory Numbers to peer clusters via GDPR and ILS.

With the above empty mask, the Directory Number also becomes the Enterprise Alternate Number. With the “Advertise Globally via ILS” option checked, the alternate number will be dynamically replicated to peer clusters, thus enabling inter-cluster calling with very little effort.

+E.164 Alternate Numbers

Although CUCM has supported E.164 Directory Numbers for quite a while, some UC applications, especially from third-party manufacturers, do not always handle these well. As such, most UC engineers still shy away from using E.164 numbers as Directory Numbers. The E.164 Alternate Number feature was created to help with these issues.

In a nutshell, this feature allows for an E.164 number to be tied to an internal Directory Number. This effectively allows for a Directory Number to have a “double identity.”

In the above example, the user’s DID is directly tied to its Directory Number using the E.164 Alternate Number. This number is also injected in a Local Route Partition containing all internal directory numbers, thus making sure that all calls to DIDs that are attached to this same system remain internal, rather than trombone through the PSTN. Alternatively, users with non-matching DIDs can also explicitly configure their E.164 DID using this same feature, only this time without using wildcards (ex. +15559874321 rather than using Xs as above). Another benefit is that this concept now eliminates the need for DID translation rules at the ingress voice gateway or CUCM level, which is especially useful for organizations with non-matching DIDs.

In addition, in multi-cluster environments with global enterprise dial plans, it is usually recommended to advertise E.164 numbers through GDPR and ILS – this is easily achieved by checking the appropriate box in this same section. As was the case with the Enterprise Alternate Number, this feature greatly reduces the effort required to have all DIDs of the local cluster dynamically replicated with all other clusters in the organizations, thus keeping calls to the organization’s DIDs “on-net” rather than using the PSTN and incurring toll charges.

YMMV (Your Mileage May Vary)

Dial plan architecture is definitely not an exact science. Different organizations have different realities, both business and technical, which may require different approaches to design the proper dial plan to achieve the desired result. At the very least, the examples above should help illustrate how Enterprise Alternate Numbers, E.164 Alternate Numbers, and Global Dial Plan Replication can provide easier solutions than more traditional approaches.

Although these features are meant to simplify global dial plans, implementing Global Dial Plan Replication, Enterprise Alternate Numbers or E.164 Alternate Numbers can sometimes require quite a bit of heavy lifting. Should you require assistance with dial plan architecture or implementation, our Cisco UC experts are available to help!