In the last installment of this series, we took a brief look at the history of the ITU-T's E.164 recommendation, as well as, hopefully, an understanding as to why we might want to begin building dial plans in CUCM versions 7 and later in a truly Globalized format, and we took a look at the basic configuration to do so. In this post we will look at the next phase in the process, namely Localization.

We last looked at an example where we had a very basic hunt group to facilitate calls coming into a New York City, US (NYC) PRI gateway from a NYC caller out on the PSTN. As a quick reminder of our scenario, when the call rings into the hunt group, it first attempts to route the call to a NYC 7961 IP phone and then, if the call is not answered, it continues to hunt to the Brussels, Belgium 7961 IP phone.

NYC PSTN caller ---> UCM NYC GW ---> Hunt Group  ----> NYC 7961

|

|---> Brussels 7961

Now you will recall that the goal is for the call to be intuitively and quickly, visibly identifiable to either one of the potential called hunt group parties answering the phone – in other words, they should be able to look down at the phone display and quickly be able to identify where, geographically the call is coming from. In order for this to be the case, when the call rings into the NYC 7961, it should display as a local 10-digit calling number. However, when that same call hunts to the Brussels 7961 hunt group phone, it should display as an international call, beginning with + and the country code of 1. We of course already took care of making sure that when the call reaches the Brussels 7961 phone, that it is formatted the proper way – that was our Globalization configuration using the Inbound Calling Party Settings on the gateway web page. However if we don’t take any next steps, the NYC 7961 phone will view that call ringing in to it in the exact same format. That next step is known as Localization, and is what we are here to discuss now and perform. Also, if you don’t remember everything from the last post, you may still be a bit hesitant, asking yourself “If I just Globalized the number (expanding it from 10 inbound digits up to include a +1), why in the world would I now want to Localize this number (effectively taking it from its 11 digit format including the +, back down to a 10 digit number)?”. Again we want to consider the fact that we only first Globalized the number in order to normalize it, such that all further manipulation of the number would all follow a similar method. Taking a look at it from another perspective you might simply ask, “Instead of Globalizing every call to begin with, only later to Localize it for the NYC phone, why not instead simply wait until the call arrives at a phone needing to see the Globalized format, such as the Brussels phone, to do the expanding up to the Globalized format?”. In order to answer that question consider this question in response, “If a call arrives at the Brussels 7961 phone, how do we know where it came from in the first place in order to decide how to manipulate it when it finally arrives?”.

So enough of the recap, now onto the business of actually Localizing any numbers needing so for NYC, and then we’ll take a look at when and if that function ever needs performed for Brussels phones. In order Globalize the calling party, we performed Digit Manipulation using the “Incoming Calling Party Settings” section of fields on a Gateway web page in CUCMA as seen here:

In order to Localize a call we are also going to be performing Digit Manipulation, however we will be using a new entity in CUCM v7 known as a “Calling Party Transformation Pattern” (CngPTP). We configure the CngPTP in a web page all of its own in CUCMA, found under the 2^nd main drop-down – “Call Routing”, however we actually apply this new Digit Manipulation pattern via an old well-recognized process – using Partitions and Calling Search Spaces.

As a very brief recap of functionality, Partitions contain DNs, and Calling Search Spaces contain Partitions. The normalcy with which we are familiar in using Partitions and Calling Search Spaces has up until CUCM v7 always been associated with trying to match the Called number we are trying to reach (e.g. In order to be able to call someone, a phone had to be assigned a Calling Search Space, in which a Partition could be found, within which the DN had to be found of the party we were trying to call) – which we should note still occurs – that process hasn’t changed, we are simply now introducing a new process that occurs once that process has occurred and all these requirements have been met, and the call has finally reached the desired called phone. So this new method of wanting to perform Digit Manipulation on a Calling number once the call has already reached the terminating device – being the called party’s phone – requires us to step back and take a fresh look at the possible functionality of Partitions and Calling Search Spaces. Note carefully what I just said – instead of looking to the Calling Search Space assigned to the originating device in order to find a Partition with the DN we are trying to call (i.e. the Called number), we are instead looking to a new Calling Search Space field called the “Calling Party Transformation CSS” on our terminating device (the IP phone being called) to try to find a Partition with a Pattern (specifically a CngPTP) of the Calling number of the party who placed the call to this phone in the first place. Then once we match the Calling Party number, we can perform Digit Manipulation to it. One other thing that should already be understood, but we will reiterate it here just to be perfectly clear: We mustn’t attempt to match the Calling Party number as it originally entered our Gateway, instead we must attempt to match the number in the format it has now been changed to after being Globalized.

So working off our Hunt Group example, we first wish to try and match the Globalized format of the inbound NYC PSTN calling number, which you’ll recall from our previous post was manipulated to become +12125551212. Now we could build a CngPTP that matches that number exactly, but of course that isn’t very scalable or practical, as we would have to build one for every PSTN number. So we need to build something more vague using wildcards in the Pattern, but the question becomes, “How general can I be in order to match every proper call, without being too general as to catch and manipulate too many unwanted calls?”. We first need to decide what we wish to display to our receiving NYC 7961 phone, then second, take a look at the Globalized Calling number and determine what needs manipulated in order to properly Localize it.

Let’s take a quick look back at what our carriers were sending us in our respective office’s PRIs:

• Our NYC PRI had the inbound carrier accurately marking and sending us:
  • 10 digits for all Subscriber and National type calls
  • Variable digit length beginning with country code (but not beginning with +) for all calls originating outside of the North America
  • And we happen know that all 10-digit calls beginning with 212, 718, 917, 347 and 646 are Subscriber type calls and thus local to NYC, while any other 3-digit NDC (remember it was here in the last post that we said that this information wasn’t too necessary at that stage of Globalization, but that we would need to reference it later – well it’s later and we need to reference it)
• Our Brussels PRI had the inbound carrier accurately sending us:
  • 9 digits for all Subscriber and National type calls
  • Variable digit length beginning with country code (but not beginning with +) for all calls originating outside of Belgium
  • And we happen know that all 9-digit calls beginning with 02 are Subscriber type calls and thus local to Brussels, while any other 2 or 3 digit calls beginning with 0[1,3-9] are National type calls – and again that info shouldn’t be too necessary at this stage since again the carrier should mark all types appropriately, we will need to reference it later – so we list it here.

Let’s decide that for our purposes, we wish to display the following:

US Offices – Called Phone Display

Type of Calling Number	Display on Phone
Subscriber	10 digits
National	Prefixed “1” plus 10 digits (11 digits total)
International	Fully Globalized E.164 Number including “+”

Belgium Offices – Called Phone Display

Type of Calling Number	Display on Phone
Subscriber	7 digits (not to include the beginning “02”)
National	9 digits (including the beginning “0”)
International	Fully Globalized E.164 Number including “+”

So if the call is inbound is from a NYC PSTN caller, inbound on the NYC PRI, then it is a “Subscriber” Type call, and when it hit the inbound PRI, it was Globalized which means it was manipulated from 2125551212 and expanded out to +12125551212. Now the call has reached its final destination, the NYC 7961 phone, and we wish to display what we noted above for a Subscriber type of Calling Number for US Phones – 10 digits.

Before we talk about the Pattern needed to be matched, lets say a quick word about the pattern field and what can and needs to be in there. The Pattern field in CngPTPs in CUCM v7 can have wildcards that we are all familiar with such as “X” to denote one digit, “!” to denote any variable length of digits, and left and right brackets ([ and ]) to denote a range of digits – however whichever digit gets matched within the brackets equals exactly one digit. CUCM v7 can also use some regular expressions as matching criteria such as “+” to match one or more occurrences of the preceding digit or wildcard value or “?” to match zero or more occurrences of the preceding digit or wildcard value. CUCM does not allow the regular expression “.” because this character is reserved for special use as a delimiter between digits or wildcards. The “.” or “dot” as we call it in CUCM, determines the boundary that we will use to decide what digits before that “.” are to be dropped as a form of digit manipulation. Now because we stated that the “+” character is a valid regular expression (regex) useable in this field, what does that mean if we wish to match a “+” that is part of the string? It means that we first must escape the regular expression to tell CUCM that it should instead be considered as a literal string. We escape a regular expression with a “\”.

Also before we go back to the configuration, let’s quickly setup our Calling Search Space and Partition structure for the NYC and Brussels IP phones in regards to their Calling Party Transformation CSS drop-down field on the GW web pages in CUCM, and what Partitions are assigned to them, that way we understand the Partitions used in our pattern examples below.

Calling Search Space (CSS) on Phones CngPTP field	Partitions (PT) in CSS
CSS-NYC-PHONES-IN-ANI	PT-NYC-ANI-XFORM-IN
CSS-BRUS-PHONES-IN-ANI	PT-BRUS-ANI-XFORM-IN

So back to the actual configuration for matching Subscriber numbers in the Globalized format manipulating them down to 10 digits for display. So here is the Calling Party Transformation Pattern that we would create and notice the interesting placement of the dot:

CngPTP for NYC Subscriber Calls

Matching Pattern	\+1.212XXXXXXX
Partition	PT-NYC-ANI-XFORM-IN
Discard Digit	PreDot

So we see here that the pattern begins by escaping the usage of the “+” as a regex, and instead indicates that it will be part of the string of digits. Next we indicate a “1” digit and then see the placement of the dot to indicate that we will be later stripping everything before that dot (the +1). Next we see 10 digits, but they are only matching 10 digits that specifically begin with “212”. If we weren’t this specific, then we would match every call from North America and display them as 10 digits, which according to what we indicated above that we wanted to see, would violate that. Since we have multiple area codes in NYC, we of course would need one of these patterns for each:

\+1.718xxxxxxx

\+1.917xxxxxxx

\+1.347xxxxxxx

\+1.646xxxxxxx

So now that we have handled all calls being Globalized and NYC Local calls being Localized, let’s take a look at some other scenarios and Localization patterns.

We still need to create a Localization pattern needed for National calls in the US. Per our requirements above, we really don’t need a Localization pattern for any International calls, simply because once they have been Globalized, they meet the requirement for display on the phone. If our requirement had been different than the already Globalized pattern, it might call for a Localization pattern as well.

CngPTP for NYC National Calls

Matching Pattern	\+.1XXXXXXXXXX
Partition	PT-NYC-ANI-XFORM-IN
Discard Digit	PreDot

Now let’s take a look back to our Brussels PRI and discuss something interesting about most calls in Europe before we press on to Localize calls coming in that GW. If you will recall, when we first Globalized all numbers inbound on the Brussels GW, we did so in a fashion simply prefixing the country code of "32" along with a "+" to all Subscriber and National calls, and simply a "+" to International call types as seen here:

However, remember that calls coming into the Brussels GW were 9 digits in length, and all began with a “0”. Now a “0” in most European countries is the Long Distance PSTN access code (just as “1” is the LD PSTN access code in North America). But if we retain that “0” and simply add on the “+32”, we get a number formatted like this example call:

Original Inbound PRI Calling Number:

025551212         (Typically written as:  02 555 12 12)

Globalized Calling Number:

+32025551212

Now the problem with that Globalized number is that it isn’t truly an E.164 number format in that, if I were to get that call formatted in that fashion on my NYC phone, and I tried to dial it back, and let’s say I stripped the “+” and added a “011” as an North America PSTN International access code – it wouldn’t route. Properly formatted to E.164 standards, the “0” following the country code, but preceding the area code, mustn’t be there! So when the call came into the Brussels PRI GW, what really needed to be done was to first strip the “0”, and then prefix the “+32”. Stripping an inbound most significant digit prior to prefixing other digits can be accomplished with the use of the colon “:”. When we use the “:” and then specify what digits to drop, we indicate the number of digits and not try to match a specific digit with pattern matching. So here we would wish to first drop the 1st most significant digit, and then prefix “+32”. This can be accomplished with the following revision:

Now our original inbound PRI Calling number, 025551212 has been Globalized to +3225551212.

So our Brussels 7961 IP phone, receiving this call (remember that 02 was local to Brussels) would need to Localize it to match calls beginning with “+322” and drop that part, but display the remaining 7 digits, as we see here:

CngPTP for Brussels Subscriber Calls

Matching Pattern	\+322.XXXXXXX
Partition	PT-BRUS-ANI-XFORM-IN
Discard Digit	PreDot

The same Globalization would have also happened for National numbers inbound on the Brussels PRI, dropping the “0” and prefixing “+32” to make the number into a proper E.164 format, because hey – we don’t know where the call will end up – it may end up on a US phone. However, what if it doesn’t end up on a US phone, it ends up on the Brussels 7961, what do we do then? You might ask, “Wouldn’t the Brussels 7961 need that preceding “0” as a Long Distance PSTN access code in order to route the call?”. The answer is, “Yes they do!”. So what do we need to do? We simply need to add it back in, but only when we localize National Belgium calls when they reach Belgium phones (that are not in the same area code of course).

So here a call comes into the Brussels PRI from an Antwerp number:

035552121

It becomes Globalized once it hits the Brussels GW page in CUCM:

+3235552121

And we need to Localize all National type calls (non-Brussels originated calls):

CngPTP for Brussels National Calls

Matching Pattern	\+32.XXXXXXXX
Partition	PT-BRUS-ANI-XFORM-IN
Discard Digit	PreDot
Prefix Digit	0

So now the Globalized number, +3235552121 matches the above pattern in a Partition visible by the Calling Search Space assigned to the Brussels 7961 phone in the CngPTP CSS field, and performs the manipulation to drop pre-dot - which drops the "+32", then prefixes a “0”, to transform the number to 035552121 for display on the phone. Now you might ask, “Wait a minute, doesn’t this new National CngPTP also match Subscriber calls that begin with a +32 2 as well?”. The answer would be that “Yes, it does", however the thing to keep in mind is that the Subscriber CngPTP is a more specific – longer match than this National CngPTP is, and so it would always be chosen just as CUCM always chooses longer matched Called number patterns as well.

In Part III of this series we will move on to take a look at what the daunting-sounding step of “Mapping the Global Party Calling Number to its Local Variant” actually means. Its actually a lot less harmless than it sounds, and in fact – done properly – it actually mean no additional route pattern configuration for you whatsoever.