So let’s recap, we’ve discussed the how and why of Globalizing every Calling Party Number – and we recall that this occurs as the first step inside CUCM as the call arrives Inbound at any of our enterprise gateways. We’ve also taken a good look at Localizing each number – and we recall that this occurs as the last step inside the CUCM as the call leaves Outbound to each destination IP Phone. So it logically behooves us to next take a look at the task Cisco labels “Mapping Global Calling Party Numbers to their Local Variant”. Now this may sound a bit daunting or even just plain confusing, but rest assured that it isn’t, and it could probably even stand a naming refinement – in fact for the rest of this article I will simply refer to it as “Call History Dialing” since that is more properly what we are wishing to perform.

So the whole idea is that if a user at a Gen3 hardware IP phone (7941, 7961, 7971 or newer) looks at their call history logs (Directories-->Call History-->Missed Calls or Received Calls), they will see the Globalized format of any number that has come from the PSTN, and not the Localized format, and that user will wish to very simply press the “Dial” softkey without the need to first press the “EditDial” softkey and make any sort of amends to the number for it to be able to work properly. (We could configure this same functionality for Gen1/2 phones – however that particular task falls outside of the focused scope of this article)

As a somewhat brief aside, any Gen2 or older hardware IP phone as well as all softphone clients including CUPC, CIPC, IPBlue (even IPBlue registered as a 7961) will display the localized format of these same numbers coming in from the PSTN when viewing these same call history logs. This is due to the nature of how the Globalization --> Localization --> Call History process occurs. The call coming in from the PSTN upon hitting the gateway is always Globalized, and that number is forever rooted in CUCM’s DBs in that Globalized format. However as soon as the CUCM is about to hand the call off from itself to an IP Phone (hardware or software), CUCM Localizes the call, and then hands it to the phone. It is here where the real difference between Gen1/2 and Gen3/4 phones behaves in regards to storing Call History logs. You see, the Gen1/2 phones (and all softphones) do just that – they receive the Localized number, and then they (the phones) store the number in their local running memory. However the Gen3/4 phones do not. Instead they do not ever store any call history. “Well then how do they access their call history logs then? Don’t they have the ability to do so?” you might ask. Yes, of course they do, however they access these logs, not from stored running memory as the Gen1/2 phones do, but rather from a DB on the CUCM servers who stores them on behalf of the Gen3/4 phones. So the Gen3/4 phones place an HTTP call to a URI where they can access these call logs – in real time I might add. In fact it is the ability to access these logs in real time directly from the CUCM server – which is also the primary Presence server in any implementation to which all users/server place Subscribe/Notify requests – that gives the CUCM server the ability to display to the Gen3/4 phone looking at their call history lists – real time Presence/Status for any DN registered to the same Cluster with the appropriate Presence Group / Subscribe CSS settings.

So, if that user at a Gen3/4 phone (hereafter simply referred to as “phone”) were to simply press “Dial” from a Call History log view – what would happen? Well just as any call made from any Line/Device – the CUCM would take a look at the given CSS(s) at those Line/Device levels and try to find the longest matching Pattern in the Partitions located within them. Well, what types of patterns qualify? Any patterns anywhere in any Partition found within the DNorPartition table in the DB – which includes but is not limited to: Line DNs, Hunt Pilots, Translation Patterns, Route Patterns, etc, etc. However let’s be perfectly clear about one pattern they could not ever try to match at this stage: They will never try to match a Called Party Transformation Pattern. Now this may sound perfectly logical to some, but yet be surprising to others (which is why I put it in here). This is because this is not routable pattern – it is instead a transformative pattern; that is – it doesn’t route anywhere – it only transforms. Now one might say, “Well all perfectly fine and good but a Translation Pattern transforms ….”, but take a look at it – it doesn’t really does it? It doesn’t transform, it translates; and then what does it do once it translates? It routes! That being the case – we certainly will come back to these entities (Called Party Transformation Patterns) – we will need them in a bit – but not just yet.

So before we can look at what pattern it will match when “Dial” is pressed, we should probably define a few since up until now in this series, we haven’t explicitly done so. At this point it might do us good once again to step back for just a wee bit and define a decent strategy for creating our Route Patterns and various like creatures.

Now you might say, “I’ve been working with, and building CUCM 
dial-plans for a long time now, I don’t need to go over a “strategy” just to build some route patterns, point them to Route Lists, those to Gateways or Trunks, and route the suckers out to the PSTN”.

And, well, that might be all fine and good, except that given that point of view I would have to reply saying that you have been fine up until now. You see in CUCM 7 – we have this new (now relatively old in internet years) thing called a “Standard Local Route Group”.

“What is this ‘SLRG’? Doesn’t seem to sound too very different than a plain ol’ Route Group to me! Contains a Gateway or Trunk I would imagine?”

Well yes, it does contain a Gateway or Trunk – but you see the thing is – much like the smoke monster on the Island of LOST, the Gateway or Trunk contained within – well, it sort of changes depending on who it is that is seeing it.

"Changes? What are we now getting into some sort of strange guessing game? I want things to work the way I program them to, the way they should work - not have to guess at how I think they might work this time I route a call through!"

Well just hold on and first try and understand a very large problem that designers and (maybe much more so) implementers have had for quite some time now when designing and implementing very large scale clusters and dial plans with hundreds and sometimes on occasion, even thousand(s) of sites and gateways.

You see when designers would, in the past, come up against such things - let's take a company (we'll call them ARD and they have 1,000 sites that they want their consultant to put all under 1 cluster - for whatever crazy reason), well they simply had to create more.

"More what?"

Well it started with more Calling Search Spaces and Partitions. If ARD wanted to have 4 User Dialing "Class of Restrictions" (CoR's) -such as International, Long Distance, Local, and Restricted dialing- and of course wanted "Site Specific Call Routing" (that is, we wanted those calls to route out specific gateways), then we would have, in the past, had to create 4 CSS's and PT's for every site - so 1,000 sites X 4 CoR's or 4,000 CSS's and 4,000 PT's. Well to solve that issue, designers (years ago) re-designed their CSS designations and placement based on the fact that in CUCM, phone Devices and Lines both allowed CSS assignment, and that they concatenated those CSS's together (if CSS is assigned to both), to the effect that if we allowed all CoR calls to proceed via the CSS applied to the Device level and pointed to the local gateway, but then knowing the effect of the concatenation of the PT's within the CSS assigned at the Line level along with the PT's within the CSS assigned at the Device level, along with the fact that the PT’s that were at the Line level CSS override PT’s that were at the Device level CSS (but only in the case of a direct tie), that we could apply blocking CSS/PT/RP’s at the Line level. The overall effect of this was that the Device level CSS/PT’s defined the Site Specific Call Routing and allowed all calls, but then that the Line level CSS/PT’s defined the CoR’s, and so therefore allowed the user to only ring numbers that he/she was supposed to and that they would go out the proper gateway. Since we only ever needed 4 CoR’s, we now only ever needed 4 CSS’s for our Line-level CoR needs. However at the time we still needed 1 CSS and PT for every site or 1,000 CSS’s and 1,000 PT's. So instead of 1,000 X 4 = 4,000, we had then reduced our needs to 1,000 + 4 = 1,004, a big improvement at the time.

However at the time we still needed more Route Patterns (RP's) and Route Lists (RL's). We still needed 1 Route Pattern for every type of call (e.g. 1 for Emergency Services, 1 for Local, 1 for LD, 1 for Intl at a minimum) and those 4 multiplied by the number of sites so 4,000 RP’s. Also another 4 RP's for the blocking ones that we described above applied at the Line level. Those 4,000 RP's needed at least a minimum of 1,000 RL’s (one for each site). This again was so that we might have "Site Specific Call Routing".

So let's recap: we found a way with clever engineering to reduce the number of CSS’s and PT's from 4,000 each down to 1,004 each, however we still needed 4,000 RP’s, (at least) 1,000 RL’s, and 1,000 RG’s - so we still needed to create 8,008 entities inside of the CUCMA WUI (CUCM Admin Web-based User Interface - we'll just refer to it as CUCMA from here on). That's a LOT!

What if we could reduce that down to 4 CSS’s, 4 PT’s, 4 RP’s, and 1 RL? Wouldn't that be fantastic? I personally think so. Now to be completely forthcoming, we do still need to create 1 RG for each site or 1,000 RG’s. But if we could, we would be down from 8,008 entities in the CUCMA, to 1,013.

That is the power of the SLRG.

"OK, so you've gotten my attention, how does this SLRG work?"

Well to begin with, we have to understand a very simple concept; The IP Phone who initiates the call, also determines the RG that will be used when routing the call through the RL.

"How is that?"

That is what we mean by the Standard Local Route Group. When we now create a new single Route List, and assign the new, unique (always present) entity called the SLRG, it dynamically and on-the-fly chooses the RG to be used based on the original Calling IP Phone's "Local" Route Group.

"OK, but how does it know what Route Group is 'Local' to that calling IP Phone?"

Good question. Answer? Device Pool. The Device Pool that is assigned to the calling IP Phone is queried and within we find a field called "Local Route Group" (that will have of course been populated properly beforehand), and the RG found there will dynamically be used for the Route List making the query. This means that no matter what phone in any one of the 1,000 sites that goes to make a call out to the PSTN, that call will always be routed out of the gateway local to the calling phone.

So what does this mean again? This means that where we used to have to have 1,004 CSS’s, we now need 4; where we used to need 1,004 PT’s, we now need 4, where we used to need 4,000 RP’s, we now need 4; and where we used to need 1,000 RL’s, we now need only 1. Again other than RG’s (which we do still need at least one per site - so 1,000), we now need to create only 13 entities in our CUCMA.

This is massive improvement from where we've come from.

So getting back to where we left off - how to properly design call routing dial plans in CUCM 7. You see, we used to simply create every pattern for routing using the entity that we've just discussed: the Route Pattern. However we want to be able to use this new idea of only having to create exactly one Route List, and a problem presents itself in the form of Digit Manipulation.

Now as another very brief aside, we could have more than one Route List, however for the sake of understanding this simple design concept, I hope you'll allow me to proceed with only one. By the way, this doesn't mean that with only 1 Route List, that we cannot have redundancy. In fact many large enterprises that I consult for these days desire only one of the two options here: Either A) That all calls from any site go first through the HQ's aggregation of gateways and PRI trunks, and then as a backup to WAN failure that they then try and go out their local site's gateway - Or else B) that all calls from any site go first out their own local site's gateway, and then as a backup to their local site's gateway being exhausted with calls, that all calls then failover to the HQ's aggregation of gateways and PRI trunks. Either way - both methods can be accomplished with only 1 Route List - and they are each shown here:

All Calls via HQ 1st, Local 2nd (WAN failover)

Route List Name	HG-SLRG-RL
1st Route Group option	HQ-RG
2nd Route Group option	SLRG

All Calls via Local 1st, HQ failover (Local Exhaustion)

Route List Name	SLRG-HQ-RL
1st Route Group option	SLRG
2nd Route Group option	HQ-RG

The above being stated, this article isn't written with the intention of going into detailed TEHO methods (whether domestic or international), so for the sake of the article we will simply be looking at a RL written like this:

All Calls via Local only

Route List Name	SLRG-RL
1st Route Group option	SLRG

So the problem with Digit Manipulation given the new format of only one Route List is that, in the prior model where we used to have at least one Route List for every site, and many times a Route List for every type of call as well, we could perform Digit Manipulation at the Route List Details level (or Route Group within each Route List) within each Route List we had created. This would be useful for (among other things) manipulating both Calling and Called Number Types. If we now only have one Route List, and the Route Group changes every time a call is made (at least in the case of the SLRG), then how can we, with any normality and accuracy, perform Digit Manipulation at the Route List Details level any longer? We can't. So, to solve this issue, we have a new level of Digit Manipulation - and this is now performed on the egress Gateway or Trunk. So now we call back into remembrance the what we said we'd come back to, at the start of this post: Both Calling & Called Party Transformation Patterns.

In the same way we did with Localization, when we manipulated the Calling Party Number (only - no Called) on the egress leg, just before the call left the CUCM on it's way to ring the IP Phone, so we can do with Gateways and Trunks as well - only we can and may need to manipulate both Calling and Called Type numbers here. *(We didn't need to manipulate Called Type numbers as they were exiting the CUCM on their way to a IP Phone - since the phone was the final destination of the call. With a Gateway of course, that is not the case.)

So this sounds great right? We already know in detail from the previous article on Localization how this works, right? The call reaches the (in this case) Gateway or Trunk, and before leaving CUCM, tries to match a Calling and/or Called (both independent of each other) Party Transformation Pattern based on the Gateway/Trunk's Calling/Called Party CSS and Partitions found therein, respectively. If a Calling or Called Party Transformation Pattern is found via that CSS/PT process, then the transformations contained within that pattern are applied, and the call routes out as normal.

However we do still have a problem.

What if I tell you that I want you to change the Calling Party Numbering Type, for a call to a local number, to the Type of Subscriber, by using the above method of one RL, and only one SLRG. This one RL needs to be used for any of ARD's 1,000 sites.

"No problem" you tell me, "I'll just manipulate that using the Calling Party Transformation CSS/PT/Pattern at the Gateway level - just as you finished explaining we should do"

OK, however, if you are using the Calling Party Transformation Pattern match - what is it exactly that you are matching on?

"The Calling Party - of course"

Right - so doesn't that mean that, if say the calling party happens to be a phone with the DN of '533643', that our Calling Party Transformation Pattern will be something like '5336XX' - or something similar to that?

"OK - so what's the problem"

The problem is, how is matching on that pattern going to isolate calls specifically made to Local numbers?

"Ummm - it's not I guess, it's going to match all calls that those DN's make. I see. That is a problem. OK, so how do we fix that?"

In order to fix that issue, we are going to do something that will seem a complete departure from everything you've done prior to CUCM v7 regarding creating Route Patterns. Instead of creating 4 Route Patterns (one for each type of call we wish to make, we are going to create 4 Translation Patterns, and only 1 Route Pattern that all 4 Translation Patterns will essentially translate their Called Number format into.

"Ummm - Why? What will the difference really be? And also, why, if we are only going to translate the Called Number format from the Translation Pattern into the single Route Pattern, wouldn't we just skip that step and simply create 4 Route Patterns? This seems needless and quite silly."

Well if we very quickly take a look back at Digit Manipulation (DM) within CUCM - I think the reason will quickly become apparent. When a call is placed, the digits dialed go to match a Route Pattern, and we can (if we choose) apply DM there at the RP level. If we choose to however - that DM is not immediately applied. Instead it is cached, and the call continues to route through to the RL Details level, to see if any DM has been applied at that level. Again, if it has, that DM is again not immediately applied, instead it drops (forgets about) any DM that had been applied back at the RP level and caches the new DM found at the RL Details level, and the call continues to route through to the Gateway or Trunk. Now at the Gateway, again it checks to see if any new DM has been applied in the form of matching either a Calling and/or Called Party Number Transformation Patterns - and if it does find matching pattern(s), it now does apply those (similarly to before - dropping/forgetting about any DM that it found at the RL Details level). So you see - DM is never immediately applied - it always waits to see if there is DM further down the line that will trump or override the current DM found.

Well - it's never applied with one exception: Translation Pattern DM.

Translation Pattern DM is actually immediately applied. It is the only place in CUCM that it is so. And it is for this very reason that we choose to create our new "Pseudo Route Patterns" as Translation Patterns instead of traditional Route Patterns. We have the ability to apply dynamic, immediate, and most importantly Called Party Specific, Calling Party DM to a specific pattern before it enters the new, dynamic, ever-changing RP/RL/GW entity. (What do we mean by "Called Party Specific, Calling Party DM"? We simply mean that we can apply Calling Party DM that is specific to a particular Called Party matching Pattern) Now we can (and sometimes will - depending on the given task) still perform Called Number DM at the GW level via Called Party Number Transformation Patterns - since those are in fact specific to the Called Number Type. However much of what we may wish to do can many times also be accomplished back at the Translation Pattern level using its Called Party DM.

"So what would this all look like? And better yet - what about the whole premise of what this article was about huh - Call History Dialing?"

Let's take a look at just that - right now. Incidentally, all of this prior deviation from the article topic hasn't been needless drivel, and in fact, if you will notice, it has been a detailed explanation covering the last bullet that I mentioned in the original third paragraph of the first part of this series, namely "Standard Local Route Group" and the inherent need therein to discuss Called Party Number Transformation Patterns. All of this has been absolutely necessary to understand why I mentioned in the last sentence of my last part in this series that "... done properly – it actually mean no additional route pattern configuration for you whatsoever."

So our new Route Pattern will simply look like this:

Our 1 Route Pattern

Pattern	\+!
Partition	PT-PSTN
Route List	RL-PSTN
Urgent Priority	Checked
Calling Party Transformation	N/A
Called Party Transformation	N/A

Then we will have 4 Translation Patterns that will all (amongst other things noted below) prefix a "+" to the Called Number and use their CSS to route onto and match the 1 Route Pattern. Actually it should be said that we will have 4 Translation Patterns for each country, and since throughout these past two series postings we had both the US and Belgium represented, we will create 4 Translation Patterns for each country. If, as in the example we had begun to give in this part of the series, we had our company "ARD" and they had 1,000 sites, and they were spread out across multiple countries beyond just the US and BE, we still would only need 1 pattern for each type of call for each country (this could vary from city-to-city in certain countries depending on how they treat variable-length digits dialing within a given country). No matter - this still beats the heck out of 4 TP's or RP's per site! And this still means only one Route Pattern - regardless of the number of countries - because the one RP is nothing more than the globally recognized "+" and any variable number of digits!

It should also be noted that the below example assumes that we have already programmed every phone's External Number Mask with the format of their full E.164 format including prefixed "+".

One other thing we haven't noted up until now is how the carrier is expecting to see digits coming from us. We previously noted how the carrier is sending us digits, but we should define how they are expecting them here before creating our patterns.

• Our NYC carrier is expecting us to send calls in the following fashion:
  • 10 digits for all Subscriber calls
  • The PSTN carrier code of "1" and 10 digits for all National calls
  • Variable digit length beginning with country code (but not beginning with +) for all calls destined for outside of North America

• Our Brussels carrier is expecting us to send calls in the following fashion:
  • 7 digits for all Subscriber calls
  • The PSTN carrier code of "0" followed by the 1 or 2 digit area code and followed by 7 or 6 digits respectively for all National calls
  • Variable digit length beginning with country code (but not beginning with +) for all calls destined for outside of Brussels

So our US Translation Patterns should look something like this:

US Emergency - Translation Pattern

Pattern	911
Partition	PT-PSTN-Emergency
Calling Search Space	CSS-PSTN
"Use Calling Party's External Phone Number Mask"	Checked
Calling Party Transformation	Calling Party Mask: XXXXXXXXXX Calling Party Prefix: N/A Calling Party Type: Subscriber Calling Party Plan: ISDN
Called Party Transformation	Discard Digits: N/A Called Party Mask: N/A Called Party Prefix: + Called Party Type: Subscriber Called Party Plan: ISDN

US Local - Translation Pattern

Pattern	9.[2-9]XX[2-9]XXXXXX
Partition	PT-PSTN-Local
Calling Search Space	CSS-PSTN
"Use Calling Party's External Phone Number Mask"	Checked
Calling Party Transformation	Calling Party Mask: XXXXXXXXXX Calling Party Prefix: N/A Calling Party Type: Subscriber Calling Party Plan: ISDN
Called Party Transformation	Discard Digits: PreDot Called Party Mask: N/A Called Party Prefix: + Called Party Type: Subscriber Called Party Plan: ISDN

US Long Distance - Translation Pattern

Pattern	9.1[2-9]XX[2-9]XXXXXX
Partition	PT-PSTN-LD
Calling Search Space	CSS-PSTN
"Use Calling Party's External Phone Number Mask"	Checked
Calling Party Transformation	Calling Party Mask: XXXXXXXXXX Calling Party Prefix: N/A Calling Party Type: National Calling Party Plan: ISDN
Called Party Transformation	Discard Digits: PreDot Called Party Mask: N/A Called Party Prefix: + Called Party Type: National Called Party Plan: ISDN

US International - Translation Pattern

Pattern	9011.!
Partition	PT-PSTN-Intl
Calling Search Space	CSS-PSTN
"Use Calling Party's External Phone Number Mask"	Checked
Calling Party Transformation	Calling Party Mask: N/A Calling Party Prefix: N/A Calling Party Type: International Calling Party Plan: ISDN
Called Party Transformation	Discard Digits: PreDot Called Party Mask: N/A Called Party Prefix: + Called Party Type: International Called Party Plan: ISDN

And our BE Translation Patterns would look something like this:

BE Emergency - Translation Pattern

Pattern	112
Partition	PT-PSTN-Emergency
Calling Search Space	CSS-PSTN
"Use Calling Party's External Phone Number Mask"	Checked
Calling Party Transformation	Calling Party Mask: XXXXXXX Calling Party Prefix: N/A Calling Party Type: Subscriber Calling Party Plan: ISDN
Called Party Transformation	Discard Digits: N/A Called Party Mask: N/A Called Party Prefix: + Called Party Type: Subscriber Called Party Plan: ISDN

BE Local - Translation Pattern

Pattern	9.[1-9]XXXXXX
Partition	PT-PSTN-Local
Calling Search Space	CSS-PSTN
"Use Calling Party's External Phone Number Mask"	Checked
Calling Party Transformation	Calling Party Mask: XXXXXXX Calling Party Prefix: N/A Calling Party Type: Subscriber Calling Party Plan: ISDN
Called Party Transformation	Discard Digits: PreDot Called Party Mask: N/A Called Party Prefix: + Called Party Type: Subscriber Called Party Plan: ISDN

BE Long Distance - Translation Pattern

Pattern	9.0[1-9]XXXXXXX
Partition	PT-PSTN-LD
Calling Search Space	CSS-PSTN
"Use Calling Party's External Phone Number Mask"	Checked
Calling Party Transformation	Calling Party Mask: XXXXXXXXX Calling Party Prefix: N/A Calling Party Type: National Calling Party Plan: ISDN
Called Party Transformation	Discard Digits: PreDot Called Party Mask: N/A Called Party Prefix: + Called Party Type: National Called Party Plan: ISDN

BE International - Translation Pattern

Pattern	900.!
Partition	PT-PSTN-Intl
Calling Search Space	CSS-PSTN
"Use Calling Party's External Phone Number Mask"	Checked
Calling Party Transformation	Calling Party Mask: N/A Calling Party Prefix: N/A Calling Party Type: International Calling Party Plan: ISDN
Called Party Transformation	Discard Digits: PreDot Called Party Mask: N/A Called Party Prefix: + Called Party Type: International Called Party Plan: ISDN

Now once we have created those TP's and the one and only RP, then we have to move on and take care of stripping the "+" from the Called Number that we prefixed at the TP in order to patch the one RP, before the call leaves for the Gateway or Trunk. We will of course, as we have mentioned above, do this at the level that trumps all else: the Called Party Transformation CSS/Pattern at the Gateway:

Outbound Gateway

Gateway	(Local) Gateway
Called Party Transformation CSS	CSS-DNIS-XFORM-OUT
Calling Party Transformation CSS	N/A

CdPTP for All Outbound Calls

Matching Pattern	\+.!
Partition	PT-DNIS-XFORM-OUT
Discard Digit	PreDot

That pretty much takes care of the call routing for normal calls.

So finally - back to the original point of this article - Call History Dial. What do we need to do to make this work? Well, since the numbers in our Call History --> Missed and Received Calls are already in proper, full E.164 format due to having been Globalized, then as we mentioned previously, nothing really needs to be done in regards to creating a matching Route Pattern - our only Route Pattern matches every call in Gen3/4 phone Call History!

"What about those calls being properly formatted for routing out to the PSTN once they hit a Gateway?"

Let's take a brief look back at their current Globalized format in Call History. Regardless of which gateway any call had come in from anywhere, those calls were evaluated based on what Calling Party Type and Plan information was presented to the gateway from the carrier in the PRI IE, and then prefixed with certain digits depending on whether the call was Subscriber, National or International (we did nothing with the Unknown type calls). All calls were formatted in their proper, full E.164 format. This essentially meant that every call would be formatted first with a "+", followed by the calling party's Country Code and subsequent National and Subscriber digits. This means that every call in Call History was essentially formatted in a way that, if the "+" symbol were stripped, and the proper PSTN International Routing Code applied (depending on the country and gateway you were dialing from), that the call could be routed out properly and internationally.

"So again I ask, what about those calls being properly formatted for routing out to the PSTN once they hit a Gateway? I mean take for instance that I am in NYC and I sit down at my IP Phone and hit Call History, and I see that there was a call from '+12125551212'. I know from visual recognition that call is from a calling party local to NYC. Based on everything you've just told us about calls going out the Local Gateway via the SLRG/1RL dealio, if I simply go and hit 'Dial' without doing any sort of DM on my phone via the 'EditDial' button, the call will try to match a Pattern (which we have in the form of the one '+' RP), and then try to route out the one RL, then SLRG, and then our 'local' gateway will simply strip off the '+' due to the only matching Called Party Transformation Pattern matched via the Gateway's Outbound Called Party Transformation CSS/PT, and be routed out with Country Code and everything - and will most probably fail due to the carrier not wanting to see all of that junk just to route a local call - right?!?!?"

That's exactly correct - you are definitely getting the hang of things! So what do we do about it? Well we must create some new Called Party Transformation Patterns - two to be exact - and we must do this for every Gateway or Trunk in our cluster (at least for every Gateway/Trunk in each different city or locale).

"Wait a minute, I thought we went through that whole exercise earlier in an attempt to reduce the number of 'entities' needed to be created in CUCMA? Aren't you telling me that if we have 1,000 sites and thus gateways, that we are needing to create 2 new entities per site or 2,000 more entities?"

Yes, that is correct. I didn't say it was a perfect world - just that we did in fact previously take 8,008 entities and reduce them down to 1,013. So now we are back up to 3,013 entities - still a reduction of  just under 2/3. Still not too bad. And there is something else that will help us tremendously.

"What is that?"

The fact that, for the most part, we have already created these patterns before. When we were doing Localization in the previous Part II, we created 2 Calling Party Transformation Patterns for each site. We basically want to use these exact same patterns and digit discard, however the difference is, instead of them being Calling Party, we need them to be Called Party XForm Patterns. So unfortunately we won't be able to simply use the "copy" feature found at the top of each CngPTP, but we will be able to use copy & paste for the Pattern field, and use a similar CSS/PT naming convention as we did before - only changing out ANI for DNIS (and that sometimes we will need to do a little prefixing - all depending on the local carrier sending requirements - but not in our case here). This does also mean that every Gateway (or at least group of gateways at a given site) will need its own CSS created for its Outbound - Called Party Transformation CSS field. Another unfortunate necessity. But hey - we are still down from 8,008 to now 4,013 - almost a 50% savings of your time.

So the Gateways would have to be modified from before to look like this:

Outbound NYC Gateway

Gateway	NYC Gateway
Called Party Transformation CSS	CSS-NYC-DNIS-XFORM-OUT
Calling Party Transformation CSS	N/A

Outbound Brussels Gateway

Gateway	Brussels Gateway
Called Party Transformation CSS	CSS-BRUS-DNIS-XFORM-OUT
Calling Party Transformation CSS	N/A

And the new Called Party Transformation Patterns would look like this:

CdPTP for Outbound NYC Subscriber Calls

Matching Pattern	\+.212XXXXXXX
Partition	PT-NYC-DNIS-XFORM-OUT
Discard Digit	PreDot

CdPTP for Outbound NYC National Calls

Matching Pattern	\+.1XXXXXXXXXX
Partition	PT-NYC-DNIS-XFORM-OUT
Discard Digit	PreDot

CdPTP for Outbound Brussels Subscriber Calls

Matching Pattern	\+322.XXXXXXX
Partition	PT-BRUS-DNIS-XFORM-OUT
Discard Digit	PreDot

CdPTP for Outbound Brussels National Calls

Matching Pattern	\+32.XXXXXXXX
Partition	PT-NYC-DNIS-XFORM-OUT
Discard Digit	PreDot

And then the one Called Party Transformation Pattern that we had from previously would remain and the PT would be able to be seen from every Gateway's CdPTCSS and would function as the "International" strip "+". It would look still look like it had before:

CdPTP for All Outbound Calls

Matching Pattern	\+.!
Partition	PT-DNIS-XFORM-OUT
Discard Digit	PreDot

So that fairly well wraps it up! We've looked at the first step of Globalizing the inbound Calling Party number for use in Gen3/4 IP Phone's Call History lists, Localizing that same Calling Party number before it leaves CUCM for use in the alerting (or ringing) display at any IP Phone (hard or software), being able to use the fancy Cisco "Mapping Global Calling Party Numbers to their Local Variant" (a.k.a. Call History Dialing) to simply press dial and not have to edit anything, as well as the new, advanced method of creating what use to be Route Patterns now as Translation Patterns, doing a bit of Calling and Called DM in those TP's, sending them to the one and only RP, having that access the new, cool, shiny SLRG, having that ring the local Gateway, and finally on the egress Gateway - doing a bit more DM using Called Party Transformation Patterns and CSS's.

Hope everything was quite informative and straightforward. Will be back shortly with some new in-demand topic!