Jan
11

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!

About Mark Snow, CCIE #14073:

Mark Snow has been actively working with data and traditional telephony as a Network Consulting Engineer since 1995, and has been working with Cisco Call Manager and voice-over technology since 1998. Mark has been actively teaching and developing content for the CCIE Voice track since 2005, and the Security track since 2007. Mark's story with both data and voice technology started out quite young, as he began learning around the age of five from his father who was a patented inventor and a research scientist at AT&T Bell Laboratories. Mark started out on Unix System V and basic analog telephony, and went on from there to large data networking projects with technologies such as Banyan Vines, IPX and of course IP, and large phone systems such as Nortel 61c, Tadiran Coral, Avaya Definity and of course Cisco Unified Communications Manager in both enterprise and 911 PSAP environments across the US and internationally. Mark is also an accomplished pilot and punched his ticket in 2001. When Mark isn't learning, labing, consulting or teaching, he can be found either piloting or possibly jumping out of a perfectly good airplane, hanging off a rock somewhere or else skiing out west. He also might just be enjoying a quiet day at the beach with his wife and two wonderful young kids, Ryleigh and Judah.

Find all posts by Mark Snow, CCIE #14073 | Visit Website


You can leave a response, or trackback from your own site.

19 Responses to “Building Global Dial Plans in CUCM7 Part III – Mapping Global Calling Party Numbers to their Local Variant”

 
  1. Akteem says:

    Hi Mark,
    Awsome post !
    You have a gift for explaining complex topics.
    Can’t wait to attend your bootcamp.

  2. Angel says:

    A very long read, but a very good explanation. Right now I’m in my job, so, can’t read and get my brian refreshed. Tonight I have a date with my Virtualized CUCM… that sounds very geek, hahahaha

    Thanks!

  3. Roger says:

    Great post Mark, as always :-)

    Thanks and keep up the good work.

  4. Marc says:

    Great article Mark,

    I do have one question though. With the configuration you outlined in your article it doesn’t appear as though there is any form of COR when dialing from the phones history. If a user were to receive a call from say an international number and they were not supposed to be able to make calls to international numbers it appears with this configuration they would be able too as the \+! RP would let it through.

    Am I missing something or is this a correct observation? I could see this being abused as users could just have someone call them and hang up and then they could call them back bypassing COR.

  5. @Marc,

    You do bring up a great point that I didn’t touch on in the article. If someone were to receive (or miss) a call, and then try to call that number back by pressing the “Dial” softkey, he/she *would* be able to successfully place the call to that one (or any) number from their call history records. Bear in mind that they would not be able to make any other calls to LD/Intl numbers without the proper rights.

    Now of course there would be a way to limit their calls so that they wouldn’t be able to place calls back to these numbers without also having the appropriate permissions first, and that would be to create one duplicate Translation Pattern for each normal dial Translation Pattern, but instead with the pattern for each beginning with a \+ and no 9.

    So given the Translation Pattern examples above, the duplicate(s) for the US (only Local and Intl are exampled here) would look like this:

    ——————————
    Pattern \+.[2-9]XXXXXXXXX
    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: N/A
    Called Party Type: Subscriber
    Called Party Plan: ISDN
    ——————————
    ——————————
    Pattern \+.!
    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: N/A
    Called Party Type: International
    Called Party Plan: ISDN
    ——————————

    HTH!

    Mark

  6. da ill says:

    Great article!
    Thanks a lot for all the thorough explanations.

    I believe because of the extension of your articles, perhaps you missed a tiny thing on the translations, or perhaps we are seeing the necessary configuration a bit different.

    From your examples on this last part, I would have done differently some of the patterns. My point is that on your translations, you are not normalizing to E164 format some of the called numbers. (perhaps a typo and not on purpose).

    For example, the NYC Local you missed to include the 1 for country code on the translation pattern.
    Then on the CdPTP for the NYC, you are expecting the 1 for localizing the called number with \+1.212XXXXXXX

    Also, for the US International, I would have stripped 011 as well for example. Keeping the 011 could break TEHO setups where the call would be routed off from another country. The called party localization then would be done at the gateway level, and not still remain at the translation pattern level.

    Similar with the BE Local translation.
    The called number is not normalized to E164.

    This is important to allow the use of backup gateways or circuits on different area codes or even countries.
    For example, you could have a RL that points first to the SLRG but as second option point to a gateway on different city/state as backup.

    If the called party is not already normalized, it would be difficult for the backup gateway to perform the necessary transformations.

    I believe I finally got all this stuff so these are my opinions. Would love to hear if you agree or disagree.

    I’m going for my first attempt on March 25th, so wish me luck!

  7. @da ill,

    The translation patterns are here for normal type human dialing habits (not for any sort of globalization or localization). So a user picks up a phone and simply dials 9 and 10 digits for a local call (e.g. 95612387659). It is the single route pattern that picks up any calls that were once globalized, then left under Call History and dialed via that method.

    As for the international, though I did cover the ability to create one RL that would allow for backup RGs, it was never the intention of this article to cover TEHO implementations and all of their complexities and additional patterns (TPs, RPs or CdPTPs). You certainly could (and I agree with you that I probably would normally) strip off the 011 or 00. I’ll be sure to update the article to reflect that so that in fact the fallback gateway would work most efficiently, but also to note under the RL section what I meant to add – namely that the article wasn’t trying to describe all functions including TEHO, but merely as an aside was I noting the ability to have 1 RL with a rather rich ability in regards to redundancy.

    Good luck on the 25th and don’t hesitate to unicast me with any questions!

  8. manu says:

    Mark,

    I have followed all the three sections, and it’s awesome. You have made the Call routing section in the SRND and Features and Service guide very simple. Thanks again for posting this great info in simple and lucid way.

    Thanks,
    Manu

  9. Natan says:

    Hey Mark. Grate articles indeed, 3 of them. One question please. Do we consider using “+” for E.164 External Phone Number Mask as best practices? I just can’t see any specific reference for it on SRND..

  10. Manu says:

    Hi Mark,

    Where will the CdPTP and CngPTP on the Device Pool used? Because there is a corresponding Checkbox in the Gateway/Trunk page for this?

    Thanks,
    Manu

  11. Ali says:

    Hi Mark,

    I want to thank you for this grate description for the (dial plan), but I have a question :

    I did’t get that why you’ve used Translation Pattern instead of Route Pattern, I mean what you did using Translation Pattern it can be done using route pattern(by using calling and called Party Transformation ).
    I read this tutorial more than three times but still I did’t understand the concept.
    Please advise.

    Thanks,

  12. @Ali,

    Good question. The answer has to do with the desire to use the new feature in CUCM v7 called “Local Route Groups” (a.k.a. Standard Local Route Groups or “SLRG”). If we choose to use this new entity, it “dynamically” chooses a RG to replace the temporary placeholder in the RL (the SLRG) with the RG found in the CallING Party’s Device Pool. Since it does this, the simple fact (just now stated) is that the RG being used by RL is completely dynamic! If in fact it is dynamic, then we can’t very well know which RG will be chosen, and therefore can’t very well apply any sort of “Gateway specific” digit manipulation at the RP or RL Details (RG within the RL) level. That leaves us only two choices: 1) Use the new digit manipulation mechanism(s) in CUCM v7 which is (are) called “Calling Party Transformation Patterns” and “Called Party Transformation Patterns” or 2) Preform the digit manipulation at the Translation Pattern (which is the only place in CUCM that DM occurs immediately) BEFORE the call gets into the RP/RL/RG/GW phase.

    So the problem here if we choose to use #1 (Calling or Called Party Transformation Patterns) is that each of them can ONLY match on their specific function (CallING Party Transformation Pattern can ONLY match CallING number patterns; and CallED Party Transformation Pattern can ONLY match on CallED number patterns) – meaning I could NOT use a Calling Party Transformation Pattern to match and change the Calling Party number for a call that went to a specific CallED number. (e.g. I could not change the calling party pattern from 1001 to something else whenever 1001 dialed 911. If I used a Calling Party Transformation Pattern to match 1XXX – it would change 1001 ALL of the time – not ONLY when 1001 dialed 911). I hope that makes sense.

    This is where Translation Patterns come in, and why we choose to use them for (ALL) new Route Patterns. With a Translation Pattern we can manipulate the Calling Party number and attributes based SOLEY on the type of number callED (since the translation pattern itself is first matched from the callED number pattern, and then also based on WHO called that pattern via Partitions.

    So think of it (and simply choose to accept it :) ) in realm of thinking of the fashion world: “Translation Patterns are the new Route Patterns”!

    HTH!
    Mark Snow

  13. Rahaman says:

    Hi,

    I actuallly work on a test rack at home. My CUCM is coonected to a MGCP gw and this gw is connected by ISDN PRI to a router in CUCME mode that acts as the Telco. I have an Ip phone as PSTN phone.

    I have a problem when I’m sending +E164 number with my CUCM 7.0.

    When I debug isdn q931 i can see something like

    Bearer Capability i = 0x8090A3
    Standard = CCITT
    Transfer Capability = Speech
    Transfer Mode = Circuit
    Transfer Rate = 64 kbit/s
    Channel ID i = 0xA98383
    Exclusive, Channel 3
    Display i = ‘SiteB-Ph1′
    Calling Party Number i = 0×1081, ‘+33178153400′
    Plan:Unknown, Type:International
    Called Party Number i = 0×90, ’0012123334444′

    But when I see on my CUCME phone that acts as PSTN switch, I cannot see +, I see only “from 33178153400″.

    So I lost the “+”…

    My question is : Is it possible in CUCM 7 to put in ISDN something like a flag that avoid to show the “+” when it’s received by ISDN switch, but permit to send it as we had seen above. Is there a special service parameter to do it????

    Hope my question is clear!

    Rahaman

  14. Roger Wiklund says:

    Thanks for a great article!

    I’ve been testing this a lot myself, but mostly with SIP trunks.
    However, based on my experience, some of your examples doesn’t work in real life.

    1. E164 with + as external phone number mask.
    I have not come across one customer who has accepted this, as it is shown on top of the phone display. Usually they want it in local format, sometimes they are OK with area code also.

    I have used Calling Party Transformation on the SIP Trunk to normalize the number to a specific format requred by my ITSP. Should work with ISDN GWs also.

    2. Globalizing Called number in countries with open numbering plan.
    For example in Sweden, let’s take two major cities – Stockholm(08) and Uppsala(018).
    When you are in Stockholm, you can dial another number in Stockholm without the area code(08). 6-8 digits subscriber number.

    If you are in Uppsala you can dial other numbers in Uppsala without the area code(018) 6-8 digits subscriber number.

    When I created my Translation Patterns for Sweden, I had the intention to only do it once, and to be able to use them for all cities in Sweden. However I have no idea how to accomplish this.

    If a user in Stockholm calls a Stockholm local subscriber number, 56617339, I must translate that number to +46856617308
    46 beeing country code for Sweden, and (0)8 area code for Stockholm.

    And if a user in Uppsala calls a Uppsala subscriber number, 506134, I must translate that number to +4618506134

    I have NO idea how to differentiate these local subscriber numbers in each city, without having the full numbering plan for each city. 1 million+ users in Stockholm, 200k+ in Uppsala. It’s just not possible.

    The only way I see is to have city specific translation patterns, and that kind of defeats the purpose with SLRG. Or ask the end users to always dial with area code even in the same area (not gonna happen)

    3. I don’t see how your Translation Pattern Globalization can work with example SLRG and CFA.

    For example, you have US Local Translation Pattern:
    “9.[2-9]XX[2-9]XXXXXX” where you preDot and prefix a + on the Called number. To me that is not an E164 number. I would like to see prefix +1 to get a full E164 number.

    If you don´t prefix +1, and only + as your example, you will end up with +2119123456(bogus number just for example).

    If you on your NYC phone, CFA to this number, 9.2119123456, it will translate to +2119123456.

    Now if you have another IP Phone in Brussels, placing an on-net call to the NYC Phone(for arguments sake we will say they are connected to the same Callmanger) If you are using SLRG the Brussels phone will try to call the number Globalized number out via it’s own closes gateway (remember its SLRG). So it will try to dial +2119123456 that should normalize on the Brussel gateway going out to strip the + and prepend 00 or something like that. But still it’s gonna fail. But If you had +1 prefixed to begin with, that would have solved this problem.

    I may be missunderstanding how you intended it to work, if you would like to clarify that would be great!

    Thanks again!

    Roger

  15. Ramcharan Arya - CCIE # 28926 (R&S) says:

    Hi Mark,

    Thank you very much for such a nice explanation on Dial plan.

    Regards,
    Ramcharan Arya

  16. Marty says:

    Hi Mark,

    Thanks very much for the great tutorial. Can you comment on how you’d implement FAC in a dial plan structured this way? With the authorization occurring at the route pattern level and having only 1 route pattern, I’m failing to understand how this would work in a FAC-enabled environment.

    Thanks

  17. Hatem says:

    Mark,

    Can you please explain why TP should have “urgent priority” unchecked while RP should have it checked.

    Thanks

    • Certainly. Because when a TP sends a call to a RP, it does so with all the digits being sent at once (en-bloc) and so if we do not have the urgent priority bit checked at the RP, then a brand new T302 timer will kick in and we will most certainly have an interdigit delay even though one is not needed, since the RP has all the digits it needs to match and route the pattern.

 

Leave a Reply

Categories

CCIE Bloggers