May
07

That is a very true saying - in fact one that we believe strongly in here at INE. However we also understand just how expensive it can be to undertake studying for any CCIE Lab exam. That is why, whenever we can, we try to reduce the load on you - the students - to bear this cost. Take for instance our CCIE RS Volume II for Dynamips - we do all we can to provide you the best available instruction while trying to reduce, or sometimes even be able to eliminate the hardware costs associated with studying.

So now we have taken to task trying to do the same for our CCIE Voice track products. We can't quite virtualize all of the routers used as voice gateways (pesky DSP's and TDM trunk cards that dynamips won't ever be able to support since we actually need hardware for the drivers to be able to trigger the signaling), but we thought we would try to reduce the hardware cost for you, the student, in any way we can with the necessary hardware. Anyone having decided to study for the CCIE Voice lab exam has no doubt realized that even if you decide not to take on the enormous cost of building your own rack to practice with, and instead, to rent rack time from any vendor on the market, you still must purchase your own hardware 7961 IP Phones along with some sort of a hardware VPN solution (such as an ASA 5505 or 851 ISR router) at a minimum in order to be able to practice for all of the most important features tested in the lab. This is quite simply due to the fact that the much older 7960's and all current SCCP Software Client phones (including Cisco CIPC, IPBlue VT-GO*, etc) don't support any of the newer features - those that are most critical to studying for the latest lab exam. Even if you can manage to find refurbished 7961 IP Phones from eBay for roughly $150/phone and $500/ASA5505 - you still have to invest over $1,000USD just in hardware before you are ready to rent the rack! Seeing as how the 7961 phones are already a generation behind the current ones, and the possibility that when you pass your lab 6-12 months from now that they will likely be 2 generations old and harder to sell for the same price you paid for them - it becomes a very expensive venture to undertake!

To that end, we have made the decision to equip each of our voice racks with three 7961 phones (one at each "site" within the rack topology). Now the only way adding these phones to our racks makes any sense for our students is if we give them some way of controlling them. So we decided to form an exclusive partnership with the most premier remote phone control software company on the market - VoIP Integration. They recently upgraded their very popular Remote Phone software and have added a bunch of features, not to mention made the screen refresh rate a lot faster. Anyway - onto the good stuff. If you are a current (or future) Voice customer of INE, our strategic partnership with them will allow you to purchase their normally $199 Remote Phone software for a significantly reduced cost. One license will allow you to run multiple instances of the software in order to allow you to control all of the phones connected to your rack from a single PC.

If you have the ability to procure these hardware 7961 phones, they are still a great study option, and we still of course still support both IPSec EzVPN in Network Extension Mode and SSL VPN for everyone of our 14 Voice racks, just as we have done for well over a year now. And of course every live Voice course that we teach uses six hardware 7961 IP Phones - that won't change.

Students outside the US who have experienced higher latency and trouble getting their remote hardware phones to stay registered to CUCM or CUCME may also wish to consider this option and ultimately find this to be a very acceptable alternative.

One final reason that drove us to form this partnership and invest in phones for our racks was that we've been asked by so many of our Voice students to provide an option for them to study with 7961 phones as they travel from site to site, and don't wish to, or in many cases simply cannot, take their hardware phones with them. This gives them the inexpensive option to study using either our phones directly connected to our racks or else their own phones at their main study location connected to our racks via VPN, remotely controlled with this software.

Either way you choose, you now have an equally suitable option for studying for your Voice lab. The only unfortunate part about this is that you know have less of a reason not to be studying for your exam.

Only thing you have to do to qualify for this deeply-discounted version of VoIP Integration's Remote Phone software is to have 1) purchased any one of INE's Voice Products, and 2) send me an email expressing your wish to purchase a copy of their discounted software. VoIP Integration will then in turn send you an email to purchase the software at the discounted rate.

Finally - stay tuned for a new announcement approximately one week from now on a brand new Voice product that I personally am very excited to deliver! Something that I have been wanting to do now for a very long time, and something that so far, every live classroom student that I've run the concept by, has emphatically communicated back to me how deeply needed this type of instruction is in the Cisco UC marketplace, well beyond the help for the CCIE exam that it will provide. I wish I could give you more info right now - but my flight is landing for my next week's training class, and I am being told to put my laptop away. So watch this blog early next Friday for the announcement of when this product will (so very soon) launch!

In the (modified) words of Napolean Dynamite:

I hope all of your wildest (studying) dreams come true,

Mark Snow

*IPBlue VT-GO can register to CUCM as a 7961/62 phone, however it does not actually act like one. Many of the most important features tested in the lab, specific to the 7961, don't work with the IPBlue soft-client - such as Globalization and Mapping Globalized to Localized, G.722 codec negotiation, and many of the softkeys needed.

Apr
13

We had a great response in turnout to Josh's vSeminar yesterday. Thanks to everyone who made it out, we certainly hope it was beneficial for you!

A few comments from attendees in the ET helped us realize that the next Voice vSeminar, this Friday covering Simplifying Globalization and Localization, might be best held at 4pET/1pPT, rather than the 6pET/3pPT that it was originally scheduled for. So we changed it.

So why a lecture on this topic? Well, every class that I have taught over the last few months has invariably had most students walking in with a printout of the 40+ page, 3-part series on Globalization, Localization, and Mapping the Global to Local Variant blogs that I posted here on this blog a bit back. They all seem to have the same thing to say: "Excellent post, now can you simplify it just a bit for me and can you also explain why we would want to do any of this?". So to that end - I decided to take on the task of helping you understand not only how in a much simpler way, but possibly more importantly, the why of it all.

Now while the CCIE is normally an exam based much more around the how of things, and much less about the why of things (we typically leave the why to the CCDE side of camp), then what is the reason for thinking that the why is important? The reason I submit for this is simply put that in nearly 5 years of teaching students to understand the technologies involved in any CCIE, I find that students' brains' tend to absorb (learn and truly grasp vs. simply learning) the material both more rapidly and thoroughly if they understand the reasons why one might want to implement any sort of technology vs. simply being told that the why of things are not important and that they simply need to learn the technology to pass the lab.

It's going to be a great seminar that will be sure to keep your attention, simplify this seemingly esoteric topic (it's not that esoteric by the way - that's the point of the vSeminar), as well as provide you with invaluable information for taking and much more importantly - passing the CCIE Voice Lab exam.

So again to be clear:
Who: CCIE Voice and CCVP Candidates
What: Free vSeminar on "Simplifying Globalization and Localization"
Where: You can access this vSeminar at http://www.ine.com/free-ccie-vseminar.htm
When: April 16, 2010 at 1:00 PM PDT - 2:00 PM PDT (4:00 PM EDT - 5:00 PM EDT)
Why: Because we all love free - don't we?
How: I'm going to present it

So, again - just to be clear:

Who: CCIE Voice and CCVP Candidates
What: Free vSeminar on "Simplifying Globalization and Localization"
Where: You can access this vSeminar at http://www.ine.com/free-ccie-vseminar.htm
When: April 16, 2010 at 1:00 PM PDT - 2:00 PM PDT (4:00 PM EDT - 5:00 PM EDT)
Why: Because we all love free - don't we?
How: I'm going to present it

See all you hard studiers there!

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!

Dec
15

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:

Incoming Calling Party Settings - US

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 2nd 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:

Incoming Calling Party Settings - Belguim old

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:

Incoming Calling Party Settings - Belguim

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.

Dec
07

While having been covered before, there seems to still be quite a lot of confusion surrounding Cisco’s newest call routing additions and features in CUCM 7. These are best cleared up since they not only are completely fair game as testable topics for the CCIE Voice lab, but also since CUCM 8 is just about to FCS and includes a great deal of call routing enhancements of its own (such as policy-based call-routing and inter-cluster dynamic DN route building) which will only build on the complexity of CUCM 7’s call routing enhancements (I’ll blog on some of the new features of CUCM 8 another day if anyone is interested).

In this blog article I will first list the new call routing features, then explain why we might be interested in using them (which requires a bit of understanding of history that we will go over), next move on to how to configure them, and finally wrap up with some real world examples. This all might take a while to explain with accuracy and clarity, and therefore will be broken down into sections to assist the reader with an easier course of digestion and absorption. Also it should be noted that before we begin, we are only going to seek to understand the E.164 numbering recommendation in this blog article, that is – we will not go into the specifics of E.164 NUmber Mapping (a.k.a. ENUM) here – although I will cover that in a later blog article.

New Call Routing Features in CUCM

The major new call routing specific features in CUCM 7 are as follows:

  • True E.164 Number support complete with + character
  • Calling and Called Party Globalization
  • Calling Party Localization
  • Mapping Globalized Numbers to their Localized Variant
  • Standard Local Route Group

From a very simplified perspective, the reasons for these enhancements can be summed up by saying that they allow for truly globalized, multi-national Unified Communication call routing deployments while concurrently reducing configuration for green-field deployments and ongoing expansion alike.

It used to be that only very large corporations had multi-national operations and therefore needed communications systems that spanned those country borders, however in the past 5-10 years there has of course been a huge expansion of medium-sized (500-1000 employee) and even small (10-20 employee) companies having employees that work across many national boundaries. With the inherent need for employees of businesses of all sizes to communicate effectively with each other, regardless of geographic location between one other, comes the need to have a global standard for understanding and recognizing any phone number when it is presented on any phone screen or is viewed in an application or call history record. To put that in a different way, it would be important that if a call were to be presented to me ringing at a phone, that I be able to quickly and visually distinguish if that call were coming to me from a local area, a national (long distance) area, or from another country altogether, and in fact what country it was coming from.

A Bit of History Necessary to Understand E.164

Not too long after telegraph and then telephones became a common communication platform across the globe, an organization was formed to try to bring together differing systems into some sort of body of standards and principles. This organization started as the CCIF, became the CCITT, and eventually ended up as we now know it – as the ITU-T. In 1997 the ITU-T revised the E.163/Q.11 & E.164/I.331/Q.11 spec into the E.164 (Wikipedia summary here) Public Telecom Numbering Plan recommendation as an international standard for public switched telephone numbers. In a very brief summary that is in no way exhaustive, it defines that:

  • All numbers will be a maximum of 15 digits in length
  • All numbers will have multiple parts to the overall displayed number:
    • Country Code (CC) for Geographic Area portion (1-3 digits)
    • National Destination Code (NDC) portion
    • Subscriber Code (SC) portion
    • (NDC and SC portions will be no longer than 15 digits minus the number of digits contained in the CC)
    • The 15 digit maximum for the CC, NDC, or SC portions do not take into account any National or International carrier code prefixes (such as 011 or 00 for International or 1 or 0 for National carrier codes)
    • All numbers shall be displayed with a + as the preceding character followed by the Country Code (which as we will see is not alone necessarily a good indicator of country but rather geographic area)

It should be noted that the above is more specifically known as the “E.164 Number Structure for Geographic Areas”, and that the E.164 spec also provides for 3 other number structure formats, namely the “E.164 Number Structure for Global Services”, the “E.164 Number Structure for Networks” and the “E.164 Number Structure for Groups of Countries”.

Here let’s quickly take a high-level overview at global geographic groupings (Zones) of geographic areas grouped mainly by the first digit in the CC field of an E.164 number, and break them down loosely just a bit further:

  • Zone 1 – Numbers beginning with +1 denote North America and many Caribbean island countries, however not Mexico or Central America. These are further broken down into NPA’s (Numbering Plan Area codes) (the NDC portion of the E.614 number) that often further delineate cities or areas in the US or Canada, but also many times delineate entire countries especially when referring to Caribbean island countries.
  • Zone 2 – Numbers beginning with +2 denote mostly African countries, some Atlantic and Indian Ocean islands as well. Aside from +20 which is Egypt, typically these countries or areas will use the full three digits in the CC section of the E.164 number (e.g. +2XX).
  • Zone 3 – Numbers beginning with +3 denote European countries. These countries typically utilize 2 or 3 digits in the CC field (e.g. +3X or +3XX).
  • Zone 4 – Numbers beginning with +4 denote European countries. These countries typically utilize 2 or 3 digits in the CC field (e.g. +4X or +4XX).
  • Zone 5 – Numbers beginning with +5 denote Mexico, Central America and South America countries. These countries typically utilize 2 or 3 digits in the CC field (e.g. +5X or +5XX).
  • Zone 6 – Numbers beginning with +6 denote Southeast Asia and Oceania countries. These countries typically utilize 2 or 3 digits in the CC field (e.g. +6X or +6XX).
  • Zone 7 – Numbers beginning with +7 denote former Soviet Union countries such as Russia and Kazakhstan. These countries utilize a single digit from the CC field +7 plus the NDC for delineating between countries similar to North America’s +1 usage.
  • Zone 8 – Numbers beginning with +8 denote East Asia countries and Special Services numbers. These countries typically utilize 2 or 3 digits in the CC field (e.g. +8X or +8XX).
  • Zone 9 – Numbers beginning with +9 denote West, South and Central Asian countries. These countries typically utilize 2 or 3 digits in the CC field (e.g. +9X or +9XX).
  • A complete listing in easy to find format can be found here.

While some readers to this blog will be from the US, and may not think it too normal to format phone numbers with a + followed by country code and remaining digits for use in cell phone and/or corporate contact lists, the readers to this blog from many other parts of the world (EAME, A-PAC, CANSAC theaters) will often no doubt be used to this type of formatting as a very normal way of storing numbers. This is particularly common in any area where countries have very close borders with other countries and one has contacts with people in many of these other countries.

Why We Might Be Interested in Using These New Features – An Example

Now that we’ve talked a good bit of the idea of the + character, E.164 and its usage, let’s unpack the idea of Calling Party Globalization. The new concept that we are beginning to grasp is that we need to have a way to identify any calling party number, anywhere that it might present itself in the company. This is illustrated below (in bad ascii format :))with explanation:

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

--> NYC 7961

--> Brussels 7961

Here a call comes into a New York City, US (NYC) PRI gateway from a NYC caller out on the PSTN, and that call rings into a Hunt Group which first attempts to route the call to a NYC 7961 IP phone and when in does, it should display as a local call (let’s say a 10-digit number). However let’s assume that the call is not answered – it will continue to hunt to the Brussels, Belgium 7961 phone and when it rings there, if it were presented in the same fashion as it was to the NYC 7961 phone (as NYC local 10 digit caller-id), surely the person in Brussels seeing the call come in would not intuitively understand that call as having come from the US. In fact while a calling number within Belgium could be formatted as 10 digits, it could also be formatted with 9, but would most probably begin with a “0” if the carrier were sending in the leading national prefix. Instead of allowing that, we would need that calling number to have somehow dynamically updated to a format that made it immediately recognizable to the Brussels phone that the call was indeed from another country and an easily recognizable format to determine the calling party’s country’s origin.

So the first idea we will look at implementing is that of something we will call “Globalization”, and is really one of a sort of “Normalization” of the calling number. One of the ideas behind normalizing any large dataset is so that if we need to query against, or perform any sort of data manipulation against a large set of data is that we must first normalize that dataset before we perform any sort of global query or manipulation. Failure to do so would result in very different results depending on how we format the query and which portion of data we happen to be affecting at the moment we try to run the query or manipulation. When we first normalize the dataset, we can be assured that we have a common starting point from which we can query or manipulate all data in a similar fashion. So the data we seek to normalize or “globalize” first here is that of Calling Party Number and way we normalize that data is that the moment that the call enters into our domain (any UCM cluster under our administrative control) we identify certain information about the Calling Party Number, and subsequently prefix (and sometimes even drop) certain digits to the beginning of each number, depending on that information obtained from call as the carrier has sent it to us.

The information we need to ascertain from the carrier is most importantly, the Numbering Type, and optionally the Numbering Plan. Both of these bits of information come to us via the ITU-T’s Q.931 recommendation for ISDN signaling, and more specifically in the 3rd octet of both the Called and then the Calling Party Information Elements (IE’s) during a Q.931 SETUP message. As did many parts from the Q.931 spec, these elements carried over to the ITU-T’s writing of the H.323 specification, so we have the idea of these as well.

Now needing these bits of information inbound from the carrier assumes a few things – firstly that we have a sort of TDM or IP trunk from a carrier that is capable of carrying this sort of information and, secondly that the carrier actually sends us reliable information regarding the accurate numbering type. For the sake of this conversation, we will assume that every TDM or IP trunk is capable of sending this information, and that our carriers are reliable (this may be a big assumption – I know J – but we nevertheless have to make such assumptions for the sake of understanding the concepts in their entirety).

Let’s define here the different Numbering Plans and Numbering Types:

Note: The numbering types below that happens to be on the same horizontal line below as a given numbering plan does not necessarily mean that that numbering type has any relevance to the numbering plan – in fact many numbering plans do not contain all of the numbering types.

Numbering Plan
(Octet 3, Bits 1-4)
Numbering Type
(Octet 3, Bits 5-7)
  • ISDN (E.164)
  • Data (X.121)
  • Telex (F.69)
  • National
  • Private
  • Reserved
  • Unknown
  • International
  • National
  • Network
  • Subscriber
  • Abbreviated
  • Reserved

For the sake of this discussion, we only really care about the Numbering Plan of ISDN (or E.164). When we set or receive this kind of Plan (ISDN) going to, or coming from an IP-based trunk, we are actually referring to fact that it represents E.164. For that reason, this is the only Plan we will use from here on in this blog.

Now we will list the types of trunks from CUCM’s perspective that support this information:

Trunk TDM/IP Type Provided
ISDN PRI TDM
  • National
  • International
  • Unknown
  • Subscriber
ISDN BRI TDM
  • National
  • International
  • Unknown
  • Subscriber
H.323 – H.225 IP
  • National
  • International
  • Unknown
  • Subscriber
H.323 – ICT IP
  • National
  • International
  • Unknown
  • Subscriber
SIP IP
  • Unknown

Note above that T1-CAS, E1-CAS and FXO are not listed above, and that SIP has a very limited subset (Unknown). This is because CUCM does not support T1-CAS in an FGD type of trunk via the MGCP protocol, does not support E1-CAS via MGCP at all, and only supports Unknown as a type coming in from a SIP trunk. This does not actually mean that we cannot set a proper Type coming in from these specific trunks, only that if we wish to do so, we must do it on the IOS gateway before it reaches CUCM, and that we will not be able to rely on Type or Plan information coming to us from the carrier and therefore must deduce Type from the digits and what we know of our gateway’s geographic location and the carrier sending digits as they enter our IOS gateway from the carrier. We will revisit these types of trunks at the end of the discussion and discuss variant types of configuration to cover them after we have covered everything else.

Configuration for Globalizing Inbound Calling Party Numbers

So if we wish to globalize this data of Calling Party Number as soon as it come into any gateway or trunk that is a part of any UCM Cluster under our administrative control, we must of course configure this at the gateway or trunk web UI page level (there is an option at the Device Pool level – but we won’t explore that in this post as that simply gets into grouping configuration together for ease of large deployments).

So before we look at the actual configuration applied to a given gateway or trunk, let’s setup some assumptions as to what the carrier is sending into our cluster from each given gateway in each site:

  • Our NYC, US gateway is ISDN PRI, and our carrier is accurately marking and sending us:
    • 10 digits for all Subscriber and National type calls as well as those proper Types in the Calling Party IE
    • Variable digit length beginning with country code (but not beginning with +) for all calls originating outside of the North America along with the proper International Type
    • We also 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 (referred to as NPA’s within the NANP) are National type calls – and while that information shouldn’t be too necessary at this stage since the carrier should mark all types appropriately, we will need to reference it later.
  • Our Brussels, Belgium gateway is ISDN PRI, and our carrier is accurately marking and sending us:
    • 9 digits for all Subscriber and National type calls as well as those proper Types in the Calling Party IE
    • Variable digit length beginning with country code (but not beginning with +) for all calls originating outside of Belgium
    • We also 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.

So on our NYC GW we will configure the following in the UCM NYC ISDN gateway web page:

Type Prefix
Subscriber +1
National +1
International +
Unknown Default

This takes all calls with 10 digits (with proper Subscriber or National types) and adds a +1 to globalize and denote a call from the country code 1, and any International calls with variable digits beginning with country code and simply adds a + to denote that what comes next is the country code.

Then on our Brussels GW we will configure the following in the UCM NYC ISDN gateway web page:

Type Prefix
Subscriber +32
National +32
International +
Unknown Default

This takes all calls with 9 digits (with proper Subscriber or National types) and adds a +32 to globalize and denote a call from the country code 32, and any International calls with variable digits beginning with country code and simply adds a + to denote that what comes next is the country code.

You might ask here why we even have different fields for Subscriber and National – the answer would be to assume that we have a peculiar carrier in a remote, rural part of the US that only sends us 7 digits for Subscriber type calls, and 10 digits for National type calls, in that situation the incoming calling party settings might look something like the next example for a gateway (we will still use the NYC example above so as not to have to define another set of area codes, just for the sake of example, and so let’s just assume that local subscriber calls are only coming in from a 212 area code but again displaying only 7 digits inbound):

Type Prefix
Subscriber +1212
National +1
International +
Unknown Default

The great thing about normalizing or Globalizing this data as it enters any of our our gateways or trunks in any of our UCM Clusters under our administrative control is that once we have Globalized the Calling Party Number, it doesn’t need to be changed or performed again if we wish to move the call across UCM Cluster boundaries. This is regardless of if those boundaries happen to correspond to geographical country boundaries or not, as that Calling Party Number will retain its Globalized Type, Plan and digit format across these boundaries. So to put it in other words, if we have a call come into our NYC, US ISDN gateway as the digits 2125551212, and we accurately identify it and prefix it with a + and a country code of 1 to change it to +12125551212, then when it leaves our US UCM Cluster to route across a Non-GK Controlled ICT Trunk over to our EU UCM Cluster, it remains formatted as +12125551212, and can quickly be recognized as an International calling party from the US.

Now that we have our inbound Calling Party Number properly Globalized, we see from our example of the hunt group earlier that this is obviously great for the quick visual identification of the Brussels 7961 phone as it needs to see and answer this call. However, this doesn’t exactly make it too very quickly readable to the original hunt group member, the NYC 7961 phone who has to see it in its International Globalized format. Sure it is clearly from +1 (US and Canada primarily), but isn’t there an easier way to view it? Such as in its native 10-digit Local format?

There certainly is, and it’s referred to as “Localization”.

But wait, didn’t we just Globalize this call?

Why on Earth (or beyond Earth as dial-plans expand to the ISS, Moon, Mars, etc :)) would we want to Globalize a Calling Party Number if we need to turn right around and Localize it??? That is exactly what we will dive into – the “why” of it, as well as the “how” – in the next installation of this series.

Subscribe to INE Blog Updates