Cisco CUCM number plan globalization localization normalization - volume 1 - incoming caller ID CLID

For complete and up to date information on Cisco CUCM number plan globalization and localization, please see the latest SRND at Cisco.com: https://www.google.com/search?q=CUCM+SRND

Then when you are good and confused, do yourself a favor and see Mark Snow's excellent write up regarding the same at: http://blog.internetworkexpert.com/2009/12/07/building-global-dial-plans-in-cucm7-part-i-globalization/

Now not being confused but possibly a product of the United States, for some international flair and level setting, see:
http://ciscoshizzle.blogspot.com/2012/05/number-plan-globalization-based-on.html

The motivation behind "globalizing" and "localizing" your numbering plan is basically to simplify the routing of calls when multiple locations and / or countries in your enterprise have different local dialing requirements.  Another advantage is to provide consistency to users fielding incoming calls that may cross these requirement boundaries.

For example:

Let's assume you have an office in Lockport NY, USA and another in New York City NY, USA, served by a single CUCM cluster.

Let's also assume that in Lockport NY, making a local, also know as a Subscriber Type call to the pizza place across the street requires you to dial only 7 digits, something like 9 for outside line access and then 438-0645 to reach Stevie V's pizza place.  The area code in Lockport is 716 and the complete US telephone number is (716)438-0645, but no one is required or in practice dials the 716 area code in Lockport NY.  To dial any number outside of the local area, also know as a National Type call, a Lockport user would dial 9, and then maybe 1(212)438-0645, assuming Stevie V's had a pizza shop in New York City NY, USA, 400 miles away.

Then, let's assume that the New York City user needs to dial 9 and then 1(716)438-0645 to reach Stevie V's in Lockport, a long distance / National Type call, much like how a Lockport user would call the New York City location. Nothing interesting there.  Now, if a New York City user wants to order a pizza from across the street, rather than dial 7 digits like a Lockport user, they are required to dial the full 11 digits, 9 and 1(212)438-0645, the same pattern type used for long distance / National Type calls even though it is a call to a local / Subscriber type call to a location right across the street.

There are two problems here.

1. To allow for outgoing calls without globalizing / normalizing your numbering, you will need to create a set of route patterns for each location to handle all possible dialing patterns at each location.  For example, the Buffalo phones would need access to patterns like 9.[2-9]XXXXXX and 9.1[2-9]XX[2-9]XXXXXX at very least to handle basic local and long distance calls, while the New York City location would need access to patterns like 9.1212XXXXXXX and 9.1[2-9]XX[2-9]XXXXXX to route basic local and long distance calls.  In reality, you would need additional patterns at each for emergency, toll free, international, etc. type calls. This may not seem like a big deal with a couple sites and relatively consistent patterns at each, but keep in mind the number of patterns required grows at least exponentially each time a site is added.  Adding sites as well as routing features like TEHO, redundancy and international sites can have your numbering plan exploding at the seams in no time.
2. Where incoming calls may be distributed to locations that don't use the same dialing patterns (i.e. 7 digits for local calls in Lockport and 11 digits for local in New York City), the location of the incoming caller may not be easily identified by the caller ID.  For example, assume a Lockport user orders a pizza from Stevie V's across the street by dialing 9 + 438-0645. Then Stevie V's calls that user back to confirm the delivery location.  The Lockport user might see Stevie V's and 4380645 as caller ID in their display and everything is great.  Now, let's assume instead the Lockport user went to the bathroom and the incoming calls were temporarily answered by the New York City location.  The New York City user would still see Stevie V's and 4380645 as caller ID in their display, since that's how it is presented to the Lockport locations's gateway.  There is no way for the New York City user to know where that calls is actually coming from.  Unfortunately, when the New York City location confirms their delivery location with Stevie V's in Lockport, the pizza delivery charge gets changed to several hundred dollars and it will likely take 7 hours to get there.

Globalizing and localizing numbers can simplify your dial plan, provide a consistent and familiar user experience, and cuts down on pizza delivery charges.

Or, from the CUCM SRND, we have this general concept description:

Globalized Design Approach

This section describes dial plan features used to implement simplified call routing based on globalized numbers. The simplification is primarily obtained through the use of a single routing structure for off-net calls, no matter the source of the call. For example, two users in separate countries could use the same route patterns to carry calls to their respective local gateways, instead of requiring site-specific route patterns, each configured to match their respective dialing habits.

The main architectural approach used to attain this globalization can be summarized as follows:

• When a call enters the system, the destination number and the calling number are accepted in their local format but are then immediately globalized by the system.
• Once globalized, the called number is used to route the call to its destination through the use of route patterns expressed in the global form. The global form may be a combination of a global internal, enterprise-specific form such as 81001234 and/or a globalized PSTN representation of a DID number, such as the +E.164 form (for example, +12125551234).
• Once a destination has been identified, the calling and called numbers are localized to the form required by the endpoint, the network, or the system to which the call is to be delivered.

Thus, the guiding principle is:

Accept localized forms upon call ingress, and globalize them; route the call based on the globalized form; and localize the call to comply to the form required by the destination. 

Wow.

Now that we have all that and given the ideas have been spelled out quite well already (see links above),  for those that haven't seen it in action, here's a more pictorial how to.

We start with accepting incoming calls via a H323 gateway in Lockport NY, a small town north of Buffalo NY.

Using a very basic and standard phone device and gateway configuration, we will route calls from outside to DN 300 in the Lockport location.  We also have a New York City phone sitting nearby with DN 400 to test with.

Lockport DN 300 and NYC DN 400 - note the External Phone Number Masks

When we receive an incoming call from a 585 area code Rochester NY caller through the Lockport voice gateway, the caller ID is presented in a fashion that makes sense in both the Lockport and New York City locations.  The caller ID is (585)555-1212 and users in both Buffalo and New York City are able to decipher the calling party is an outside caller in Rochester NY.  Since the caller ID is 10 digits and would be the correct number to dial Rochester from either New York City or Lockport, both location users understand where the call is coming from.

(585)555-1212 calling Lockport through Lockport gateway. Looks good.

(585)555-1212 calling NYC through Lockport gateway. Looks good.

Now, to make things a little interesting, we have to consider what a local / Subscriber type call from the Buffalo area PSTN into the Lockport voice gateway looks like.  When we receive an incoming call from a 716 area code Buffalo NY caller through the Lockport voice gateway, the caller ID is presented in a fashion that makes sense only in the Lockport location.  The caller ID is 555-1212 and only users in the Lockport location are able to decipher the calling party is an outside caller in the Buffalo NY area, as this is the pattern they would use to dial out to the Buffalo NY area.  Since the caller ID is 7 digits and would be the correct number to dial Buffalo from Lockport, Lockport location users understand where the call is coming from.  When this same incoming call through the Lockport gateway is presented to New York City users,  because the caller ID is only 7 digits, they cannot tell where the call was initiated from.

An incoming call from Buffalo to Lockport through the Lockport gateway with 7 digit CLID.  This looks like a normal local caller  to Lockport users. We're good.

An incoming call from Buffalo to NYC through the Lockport gateway with 7 digit CLID.  This does not look like a normal calling pattern to NYC users who use 10 digits for outgoing. We've got a problem.

This is not a monster problem as presented, but introduce an international location or two where different country users might not be prepared to remember all the possible off-net dialing combinations, bump your DN lengths up to 4 digits and start adding location codes for users to identify on-net enterprise locations, and all of a sudden you don't know if it's Stevie V's new Japan location calling and answered in Lockport to verify a delivery location or if it's someone named Stevie on his WiFi phone calling to say the elevator is back in service in the NYC office.

So let's fix this. Let's do some cool stuff.  Let's "globalize" the numbers that are presented via caller ID.  Let's make the caller ID look like a number that could be called correctly from anywhere on the globe (hence the term globalize), regardless of where it came from and where it was answered.

The format we are looking to present the numbers in that work globally is defined by E.164, the ITU-T numbering plan recommendation.  Start reading here: https://www.google.com/search?q=E.164.

The secret first step here is to determine, as an inbound call enters a gateway at each location, what each type of call's caller ID looks like.  Then we can adjust it at the gateway to match the E.164 format.

In our example, an inbound Subscriber type / ISDN plan call to the Lockport gateway would present 7 digits for caller ID, like we see above in the 555-1212 example.  Likewise an inbound National type / ISDN plan call to the Lockport gateway would present 10 digits for caller ID, like we see above in the (585)555-1212 example. Inbound international calls caller ID would be presented as 011 with the country code, city code, etc. following (but I'm too lazy to setup an example test for that).

Therefore, if we could just put a + in front of inbound international call caller IDs, and put a +1 in front of inbound national call caller IDs, and put a +1716 in front of inbound subscriber call caller IDs as they enter the Lockport gateway, we would be all set with globalizing the caller ID of all inbound calls there.  It doesn't matter who answers them or where, as the caller ID from the anywhere in the US would be in the +1(NPA)NXX-XXXX format.  The inbound local calls from 716 area code would look like +1(716)NXX-XXXX instead of the old, broken NXX-XXXX format, and all other calls would have to cool +1 tacked on as well.

You do this on the gateway, using the Incoming Calling Party Settings. Here's a before and after on our Lockport gateway:

Incoming Calling Party Settings in the default state

Incoming Calling Party Settings, inserting characters in front of CALLING party IDs to globalize them.

With that, we have basically covered the first general recommendation in the Cisco CUCM SRND regarding globalizing your numbering plan, that being:

Accept localized forms upon call ingress, and globalize them

The end result of prefixing incoming Subscriber / local calls with a +1716 and prefixing incoming National / long distance calls with a +1 is that all the US incoming call caller IDs through the Lockport voice gateway now have the same format, regardless of where on the planet your user might be answering them.  It looks like +1 (the plus is a recommended prefix and the 1 is the US country code), then area code, office code and numbers.  This is the standard E.164 recommended US format, recognized across the globe.  We've globalized.

Caller ID of +17165551212, a local caller answered in Lockport, shown in a globalized format.  This previously displayed as 7 digits, the way a Lockport user would be accustomed to dialing it.  This is good,

Caller ID of +17165551212, a Lockport caller answered in NYC, shown in a globalized format.  This previously displayed as 7 digits, and did not make sense to the New York City user, accustomed to always dialing 1+10 digits. This is good.

Now if we want to follow the Cisco SRND rules (skipping call routing for now), we theoretically should localize the caller ID, so that it's familiar to the end user again.  From the SRND:

localize the call to comply to the form required by the destination

What this means in our example is we need a method to again remove the +1 or +1716, depending on where the call is answered.  We don't want to NOT globalize like we just did because that will provide us with options to simplify call routing.  Now that we've globalized for our call routing purposes, maybe we want to again simplify the end user experience though and get rid of the what could be perceived as a weird +1 format.

We now turn to Calling Party Transformation Patterns and Calling Party Transformation CSSs.  The basic idea is we can put some patterns in partitions like we always have, and put the partitions in calling search spaces like we always have, and assign the calling search spaces to devices like we always have, but this time we aren't doing it to prevent or allow access to resources like we always have.  We are doing it to control the CALLING number (the caller ID), not what you called.

See Call Routing | Transformation | Transformation Pattern | Calling Party Transformation Pattern.

Here you will find what look like the average translation patterns we've always used, but which are designed to specifically modify Calling Party information.  Remember we are using Calling Party Transformation Patterns, not Translation Patterns.

In my example, they look like this:

Since we need to strip the +1 from the caller ID regardless of whether the call is answered in Lockport or New York City, we create a +1.XXXXXXXXXX pattern a partition associated with Lockport and another in a partition associated with New York City.

Since we also want to strip the +1716 from caller ID of local calls answered in Lockport, we create another +1716.XXXXXXX pattern in the partition associated with Lockport.  Since users in New York City need to see the 716 area code when they answer calls, we do not use the +1716.XXXXXXX pattern there. We want to retain the 716, but still strip the +1.  The +1.XXXXXXXXXX pattern in the NYC partition will do that for us.

We then create a plain old CSS for each of the Lockport and NYC locations, and put our the new partiton associated with each site in the cooresponding new CSS, which again contain the Calling Party Transformation Patterns required at each site.

To make these new CSSs, PTs and cngPTPs effective, we need to associate them to the local devices where the calls will be answered and where we need to localize the number, hence the term localize.  After we globalized the caller ID and routed the calls around the world, we want to again present the calls in formats that make sense to the local devices where they are answered.  For example and again, a (716)NXX-XXXX caller ID should be presented as NXX-XXXX in Lockport, but (716)NXX-XXXX in New York City.

The CSSs you created for these purposes get applied in the Calling Party Transformation CSS fields on the local device.  Below you can see them applied to the phone devices themselves in the two locations.  You can also apply them at the Device Pool level, if it makes sense in your organization.

Device in Lockport using Lockport base Calling Party Transformation CSS

Device in New York City  using New York City base Calling Party Transformation CSS

With that, the end result is we've globalized the caller ID for incoming calls through the Lockport voice gateway.  This provides us with a uniform globally acceptable way to present calls to users throughout the organization and simplifies call routing administration in CUCM. We then localized the caller ID so that users throughout the organization see caller ID in formats that are acceptable to them.

In our example, the incoming call from (716) 555-1212 in the Buffalo area is now presented with 7 digit caller ID to the Lockport users and 10 digit caller ID to the New York City users. Although CUCM has a record of the globalized format, the users enjoy the localized presentation.

A (716)555-1212 caller through the Lockport gateway displaying correct 7 digit localized format in Lockport

A (716)555-1212 caller through the Lockport gateway displaying correct 10 digit localized format in New York City

Even after localization, the gloabl formats are retained by CUCM to aid in uniform and simplified call routing.

TADA...  that's the incoming caller ID globalization and localization story.  When I have time, I'll document the really fun outgoing routing simplification techniques.

To be continued...