Using the Cisco UCM Route Next Hop functionality for Inter-Office Site Code Dialing

Most administrators of the Cisco Unified Communications Manager are probably familiar with the Hotline Feature that was introduced with CUCM 8.0. At least, that is my assumption. I also think that a fair number of people "discovered" the Hotline Feature on their quest for a solution to "black list" callers based on calling party number. Until recently, that was the #1 use case in my designs. 

A month or so ago, I was working on a design for a customer where the phones were deployed with an E.164 dial plan solution but dialing between office locations required a 3-digit site code prefix. The customer wanted to preserve the 3-digit site codes for calling and called party information elements. There are somewhere around 50 sites. So, we needed a way to gracefully handle any-to-any calling with a requirement to transform called and calling party information based on call origination and call destination. The following gives a summary of the technique applied to this problem.

Background

The Hotline Feature is essentially an extension of Private Line Automatic Ringdown (PLAR) feature. One of the configuration mods exposed for the Hotline Feature is the ability to instruct a translation pattern to make a routing decision based on the calling party number (route next hop by calling party number or as I like to refer to it: RNH-CPN). The "normal" function of a translation pattern is to make routing decisions based on the called party number. In both routing scenarios the translation pattern can also transform the calling or called party information elements. 

One of the first interesting use cases for RNH-CPN was "black listing". "Black listing" is the idea of blocking a call based on the calling party number.  If you are familiar with the concept then you probably saw it in a blog somewhere. If not then take a look at an article I wrote for NetCraftsmen covering the "black listing" application of the Hotline feature. Interestingly enough, I have never used this translation pattern functionality for its original purpose.

Recently, I had the opportunity to leverage this functionality in another way. I have a customer with approximately 50 offices spread around the globe. They have an established inter-site dialing plan that leverages a 3-digit site code. We were migrating the customer to an E.164 dialing solution and that is all well and good. However, they want to preserve the 3-digit site code dialing behavior.

The Challenge

So, you have 50 offices that each have a unique 3-digit site code. All phone DNs are programmed as E.164 numbers (e.g. +12025551212). Introducing an abbreviated dialing solution preserving the 3-digit site code for called parties is easy peasy. Throw in the requirement to preserve the 3-digit site code of the calling party requires some "out of the box" thinking.

Again, 

• We have 50 offices that can all call each other using 3-digit site codes. 
• All directory numbers are programmed with E.164 patterns. 
• We must present called/calling party information with the assigned site codes

The Solution

There is more than one way to tackle this challenge. The option will either (a) require a "double-decker translation pattern party" or (b) require ridiculous duplication of patterns. In this case, we are following the "double-decker" solution options and leverage the "Route Next Hop by CPN" functionality of translations patterns. We are building a tiered solution where we modify the called party number on one layer and the calling party number on a second layer.

The final solution looks a bit like the following diagram.

Let's walk through the environment: 

• We have three phones: a phone in New York (NYC), one in London (LON), and one in Hong Kong (HK). 
• All three phones are provisioned with an E.164 pattern as their directory number (e.g +12125551234).
• Each site has a 3-digit site code:
• NYC: 120
• LON: 220
• HK: 320
• To call a site using the site code, the calling party dials a 7-digit number: 3-digit Site Code followed by a 4-digit pattern from the assigned DID

Now, the example call scenario:

(1) From NYC and LON, we can call the HK phone using the site code "320" followed by the last 4-digits of the directory number. All originating parties use the same number to reach this HK user: 3201234.

Phones in specific offices (or within a geographic region) are assigned a locally significant calling search space. In the context of our solution, that doesn't matter because our "intra-cluster / inter-tenant" dialing solution is provisioned in a partition that is accessible from all "on-cluster" calling parties. 

(2) Specifically, the CL_Tenant-Std_PT route partition contains translation patterns. In our example there would be three (3) such patterns. The HK pattern is shown in the above example (i.e. 320.XXXX). NYC would be 120.XXXX and LON would be 220.XXXX. 

These translation patterns are our first layer of call processing. Calls from NYC and LON to HK will match the 320.XXXX translation pattern. We provision this translation pattern to do the following:

• Flag the Route Next Hop by Calling Party Number (RNH-CPN) option to True
• Set the CSS to a special CSS for RNH-CPN
• Transform the called party number to the full E.164 number of the HK site by dropping pre-dot (i.e. the 320 in the pattern 320.XXXX goes bye-bye) and prefix what is required (i.e. +8523123). So, the final called party number is +85231231234
• Leave the calling party number alone for the time being

(3) Since we are flagging the RNH-CPN option in step (2) the CUCM digit analysis is going to evaluate the patterns visible from the CL_Tenant-RNHCPN_CSS. It just so happens there is only one partition in this CSS. Further, we have programmed a list of E.164 patterns in that partition that will map the patterns assigned to all sites. So, for NYC there is a \+1212555! pattern and for LON there is a \+4402034! pattern. 

These translation patterns are going to match the DNs assigned to the NYC and LON phones, respectively. Further, these patterns are programmed to do the following:

• Set the CSS to a standard CSS that can see your phone DNs (at a minimum)
• Transform the calling party number to use a 3-digit site code mask  (e.g. 120XXXX)
• Leave the called party number alone

(4) Almost done! So now, we have applied two layers of translations. One layer handles the called party transformation and instructs CUCM to go to the 2nd layer. The second layer handles the calling party transformation. The net effect of this juggling act is that the HK phone rings out on the line associated with \+85231231234 and the display on the phone says From: <name> <site-code><extension>. So, let's say I am chillin' in NYC and I am calling HK, the display on the phone would say "From: William Bell 1201234".

Considerations

The partition and CSS arrangement you apply in your design will vary. Actually, I recommend that the translation patterns used for the RNH-CPN function be "overloaded" if possible. Meaning, if you can apply the patterns to another function then go ahead and do so. Otherwise, think of them in the same context you apply to your transformation CSS/PT and patterns. Basically, that is how we are using these patterns.

There are conditions you may need to address directly. The example is dealing with direct calling only. However, that isn't the only call flow you need to keep in mind. Phones can and will forward calls to other phones using the abbreviated dialing pattern. This means that an outside caller can be treated to the lovely double-decker translation approach. What do you have to watch out for:

1. Make sure your RNH-CPN patterns don't accidentally match an off-net (PSTN) DNIS. Be as specific as possible. Even if it means you have to create more than one pattern. Quit whining and protect the integrity of your dial plan.
2. You need a "catch all" RNH-CPN translation to route for callers that aren't tenants on your system. Simply use a "!" pattern in your RNH-CPN partition and you are good to go.
3. Calls from "blocked" patterns need to be accounted. These calls have no calling party number. This means you need a pattern in your RNH-CPN partition that has no digits assigned (i.e. it is "blank"). Weird? Yes, but that is how you handle these call flows.

---

Thanks for reading. If you have time, post a comment!