Cart
Historically when speaking of a dialing plan within the Unified Communications Manager, we have been primarily interested in matching digits that a user dials from a phone, or digits that are carried in through a gateway, and those digits have always represented the CALLED Party (a.k.a. DNIS). Now if we had wanted to manipulate the Calling Party digits, once we had first matched a Called Party number and found the best route (i.e. longest match of DNIS digits) and sent that to a RL/RG, we were perfectly allowed to do so – but to be clear we were still matching on the DNIS digits and only then performing digit manipulation on the Calling Party digits. Now of course we could also perform digit manipulation on the called party digits at that time as well – but we are not concerned with that for this post.
Well now enters a brand new world of digit matching and digit manipulation, only we aren’t matching DNIS digits and we aren’t routing a call, so open up your minds and try (if you can) to forget for a moment, all about matching on DNIS digits to route a call somewhere. The new type of digit matching we have to think relates to matching the ANI Number and also Type of Number that comes with a call in from an MGCP gateway or a SIP trunk, and then manipulating those ANI digits in order to meet a few, well, shall we say – niceties? That is to say, these aren’t requirements we are meeting per se (well unless your lab exam makes them into requirements (grin)) – but they are rather enhancements that make it simple to quickly identify where a call came in from (geographically), and then also to return that same call with simplicity and without the need to dial extra digits such as PBX, long distance and international access codes and even country codes.
So getting on with it – one of the major new enhancements in UCM 7.x is the ability to receive a call from a gateway or trunk (MGCP and SIP only), and ‘normalize’ the calling number to a globally accepted international representation as per the E164 standard. Of course the process of “normalizing” anything typically refers to (to borrow a few words from Wikipedia) “mak[ing] something more normal” or “making [something] conform to some regularity or rule.
The idea here is that when a called party has a call ringing in, they can see that call in a localized fashion, however have the call stored in their call history logs in the globalized fashion. This way the call is easily recognizable upon ringing into the called phone, but is also easily returned later by going to the call history and simply pressing the “Dial” softkey without to know and input any additional access codes, country codes, or prefix characters via the phone keypad.
We will do this through a few processes:
- Firstly by ‘Globalizing the Calling Party Number’
- Secondly by ‘Localizing the Calling Party Number’
- Finally by ‘Mapping the Global Calling Party Number to its Local Variant’
Sounds a bit complicated (and possibly redundant) doesn’t it? Well, I won’t lie to you – it isn’t the easiest topic your likely to come across on the CCIE Voice Lab Exam – but then again, that’s why you come to us to make learning and more importantly understanding the sometimes-difficult-to-grasp-Cisco-technical-docs, easy to understand – isn’t it? In a later post we will go through the steps necessary to configure this.
Cheers,
Mark
Tags: ccie voice 3.0, Cisco
