CUC (6) CUCM (26) Jabber (6) Python (2) Routing (3) Solarwinds Orion NPM (4) switching (1) Video (6) voice (2)

Monday, 14 May 2012

Number plan globalization (based on the Australian Numbering Plan) part I

Another post on what I am most passionate about; UC. Definitely a post that took me a while to compose, the topic itself is sometimes a bit abstract but always complex. I was inspired by Mark Snow's posts on his blog on this topic.
I will expand this post gradually as I go along, and I consider this and the next posts on the subject of a globalized number plan also as a way for myself to fully understand the nuts and bolts of it. Hopefully, it will also convince other engineers to start using it. Recently I heard someone say;"if your are not using E.164, you are doing it wrong!"....Well, since CUCM provides the features to implement it in an easy way, I guess that might well be true. There is a lot of information out there on the interwebs on this topic and I will quote my sources, as this post is by no means a reinvention of the wheel.

Ok, so I have seen the terms E.164 and globalization used interchangeably, well  it is not interchangeable. E.164 is an ITU-T recommendation that defines the international public telecommunications numbering plan, and globalization in this context is a method to save a whole heap of work when building multi site CUCM deployments. Possibly in a few years down the track URIs will have taken over from E.164 as a method for globalization. And that's all I have to say about URI's.


So, this first post will describe the reasoning for a globalized dial plan and then in later post I will explain in detail, what Cisco Unified Call Manager (CUCM) features are required to pull that off. Now, for all intents and purposes I have based this and following posts on number plan globalization on CUCM version 8.6 and I will use the Australian Numbering Plan (ANP) as much as I can throughout my examples (for a full overview of the ANP see, )

Cynics might argue, they don't really need dial plan globalization in case of a  multi site CUCM deployment that does not span country borders, well sure if adding separate route patterns, for each and every site is your cup of tea, by all means. Just as an example, I remember a 100+ site single cluster deployment I was involved in, for every single site this meant at least 15 RP's to cover the Australian Numbering plan, so a total of around 1500 RP's. so you can image the amount of work involved in putting those in.

So let me sum up the benefits of a globalized numbering plan:
  • Minimal amount of Route Patterns Required (Single +! pattern will route all egress) especially, if combined with Standard local Route Group (SLRG)
  • Present calls to users in a format based on local dialing habits (localization)
  • Simplified configuration of system functions such as: Tail end Hop off (TEHO), Click to dial of E.164 numbers (as well as dialing from CUPC), one-touch dialing from directories and received/missed calls (all including potential + dialing)
  • Automated Alternate Routing (AAR) will be very easy to configure. This because if the external phone number mask (used by AAR as its destination) is entered in +E.164 format, and the AAR CSS can route calls to destinations in +E.164 format, the no additional AAR group configuration is required. because we already know how to route +E.164, there is no need for additional prefixes using AAR groups.
So just to make sure, globalization is not just limited to a uniform presentation of a calling party number, it is also used for call routing, i.e. called numbers.

The Cisco 8.x SRND (which is very good bed time reading) states:

"The simplification is primarily obtained through the use of a single routing structure for off-net calls, no matter the source of the call. For example, two users in separate countries could use the same  route patterns to carry calls to their respective local gateways, instead of requiring site-specific route  patterns, each configured to match their respective dialing habits."


Despite the fact that in this post I am trying to advocate the globalized approach (just because we engineers are lazy bastards), we cannot and should not forget to cater for of localization. With this I mean a way to accommodate local dialing habits and also to allow for easily identifiable CLID's (for instance if calls are forwarded across national boundaries) on inbound calls. Let me explain. So when I talk about Globalization, it implies globalization in terms of outbound calls and globalization in terms of CLID. Globalization, is really a way of normalization, this normalization will provide us with a common starting point from which we can manipulate, in this case calling and called numbers, in the same fashion. Here is how it's done (screen shots will follow in next post).

Globalizing Inbound calling party numbers (A)
This should take place as soon as an incoming call enters a gateway that is under CUCM administrative control, sure it can be done IOS based, but I won't  cover that. So the place to normalize is using the gateway's incoming Calling Party settings. (details in Part II)

Incoming party Settings (per Gateway) and Numbering types

Globalization starts here, as soon as an inbound call lands in our CUCM cluster. Here we identify certain information about the Calling Party Number and prefix or drop certain digits, depending on the number of digits the carrier has provided. And important tool to find out what is actually send by the carrier is running a debug Q.931 on the ingress gateway. If you would do this,  you would see something like the output below:

Channel ID i = 0xA98383
Exclusive, Channel 3
Display i = ‘SiteB-Ph1′
Calling Party Number i = 0×1081, ‘+31209988776′
Plan:ISDN, Type:International
Called Party Number i = 0×90, ’01161399887766′

This will tell you exactly what the carrier presents to you and what the numbering type is. Your gateway will receive all this information through ISDN Information Elements (IE) that are sent using certain bits in Q931, but I don't want to loose you just yet, and to be honest it bores the crap out of me, so I won't go into that. What is important is that your carrier provides the proper IE values, and for the purpose of this post I assume they do. Having said that, if you connect to the PSTN through a SIP trunk, your calling party numbering type will be "unknown" in which case you will need to use CgPTP's instead. (I have read that an IOS based gateway, say a CUBE can actually set the numbering type before a call hits CUCM, but I have never set this up myself, might be worth reading into) Anyway, the Numbering Type flavours here are:
  1. Unknown
  2. Subscriber
  3. National
  4. International

The numbering type will become more important in the next posts, where they will be used in Translation Patterns (TP) and such. 

Inbound calling party localization (B)
With this I mean that a caller ID has to be easily identifiable, so the user will only have to look at his phone display and be able to say where, geographically, the call is coming from. For instance if someone in New York receives a local NY call it will present him with a local 10 digit CLID, if this call is forwarded to someone in Australia (poor bastard waking up in the middle of the night), it should the be presented as an international call with a  + and 1 as the country code.  For this we will use the Calling Party Transformation Pattern  (CngPTP). Because the calling party has already been globalized (step A), it will now be really easy to localize, it based on its normalized form. 

I have summarized the globalization and localization below, for a national number coming into a Melbourne gateway.

Calling Party number manipulation

So although the call is formatted to E.164 on the gateway, Melbourne user will be able to identify the call as coming from Brisbane, based on it being presented as a 10 digit interstate call.
If this incoming call was to be forwarded from the Melbourne phone, to a call center in the US (or less hypothetically speaking, Bangalore), the calling party will not have to be transformed again, because the gateway configuration will already present it in E.164 format, so it is ready to cross any geographic boundary.


OK so far I have discussed the E.164 globalization of the incoming calling party and localizing it back for easy interpretation based on a device's location an local numbering plan. Next, I will discuss using this E.164 format to make outbound calls. The whole idea behind this, is that a user who looks at their call history (Directory-->Call History-->Missed Calls or Received Calls),will see the E.164 format for any call coming from the PSTN and will only need to hit the Dial soft key (without requiring any editing), in order to call the missed/received number. Prerequisite for this is, that the user has either a Gen 3 or 4 phone. These types of phone do not store a call history log locally, but in fact pull that information off the CUCM DB, each time the users goes to the missed/received call directory on the phone. Because we implemented E.164 incoming calling party globalization on the gateway level, all calls will therefore show up in their proper E.164 format. In order to dial that number using the Dial soft key an RP would need to be configured to route that call, we are going to use +! as the pattern that can do that, and apart from that, it will route each and every other call (local, interstate, international or premium numbers, pretty much everything in the AUNP).

Yes. Mike! With this product, one single route pattern can route everything, it is amazing, you have never seen anything like it! But wait, there is more!!

For this we will need a mechanism in place that will translate local dialing habits into our magic route pattern +!. Translation Patterns are the answer to this; they will translate patterns straight away (contrary to the RP->RL->RG->GW path, where each step can have its own digit manipulations (DM) and each step is cached until final DM can be established). This combined with the fact that if Standard Local Route Groups (SLRG) are used, you will loose the availability of RP, RL, RG as a way of manipulating digits (see my previous post on this topic), because these will now be commonly used by most if not all your devices in the cluster. 

Essentially what this means it that if, for example you would have a deployment covering 20 countries spread out over 500 sites, you would need only an X amount of translation patterns (subscriber, national and international, and possibly a few other patterns such as premium numbers and like directory assistance) to cover off a country's numbering plan. So a very significant gain.

Digit Manipulation steps

As you would have noticed, I slipped in a Called Party Transformation Pattern (yellow box). This strips off the + sign of the called number, as it has now served its purpose and besides +0722223333 is not a PSTN routable national number. Of course there will also need to be a CgPTP for Subscriber calls and obviously no CgPTP is required for numbers that are already have the E.164 format.

Outbound calls localization
If a user in Australia wished to make an external phone call to a number in the UK, that person would dial for example 00011441519988776 to call someone in Liverpool (assuming a leading 0 is used for Off Net calls, and yes Australia uses 0011 as the international access code). If someone from the US/Canada would try to ring that same scouser, that person would dial 9011441519988776 (assuming a leading 9 for Off Net calls). Someone in Germany would dial 000441519988776 (leading 0 for Off Net). In all there, are nearly 20 different international access codes around the world.

Now, when using globalization, that same Liverpool number would be +441519988776 no matter what local dialing habits exists and the could be routed using one single RP: +! Which would be a substantial simplification of our dial plan, compared to 15 or 20 individual RP's, to cover the ANP. 

This form of localization is achieved by means of Translation patterns (and I will cover this in Part 2)


+ Dialing

With CUCM's support, roaming users can the + sign to replace the appropriate off net access code when on the road (+ would be 0 in most, if not all European countries and 011 in the USA) and add speed dials as such. Non roaming users can do the same for mobile phone numbers (+614XXXXXXXX for Australia). The same numbering format could be used from CUPC when dialing a contact person's alternate/mobile number. Because this sort of information is LDAP synced from a CUCM perspective (well I would assume), I would advise all out there to start populating AD with +E.164 compliant numbers (i.e. the "mobile" LDAP attribute)! Obviously this goes for directory integration in general. Basically + dialing will allow users to rely on numbers represented in +E.164 form and to route them properly without requiring the user to edit the number to adapt it manually to the local dialing habits. This last sentence for instance means that users who would go to their missed calls history, and want to return a certain missed call, without hitting the EditDial button first, can do so. Surely we have all done this in the past by adding a 0 or a 9 (or whatever needed as a prefix for an Off Net call) to all ingress calling party numbers. Go on, admit it, I personally always did it by prefixing a 0 to the caller ID by means of a translation pattern on the gateway itself. I guess with + dialing support and E.164, the same approach is followed. 

Calling Party Number Transformation Patterns (CngPTP)

CngPTP works pretty  much the same as RP's or TP's; it uses patterns with wild cards, regular expressions, CSS's and partitions. So nothing new here.

In the call set up process, a CngPTP will be invoked, once a call routing decision is made. In other words, based on the originating devices CSS's and partitions (and hence RP's), CUCM has ascertained what endpoint (called number) needs to be signaled to establish the call. So once this has all taken place the, the Calling Party Transformation CSS on the terminating device, will then try to find a pattern that matches the calling party number and manipulate it accordingly. As stated earlier, this type of manipulation will take place AFTER globalization on the gateway has taken place.

This type of localization can be carried out on a device pool level or CSS level. I prefer to do it on DP level as it makes bulk assignment easier, but make sure you use a different device pool for gateway and phones, so no overlap exists. 

Called Party Transformation Pattern (CdPTP)

CdPTP has been around since CUCM 7.x. Prior to this, you would apply Digit Manipulation at either one of the following four places:

  1. The Route Pattern.
  2. The Route List
  3. The Terminating Gateway
  4. A Translation Pattern
Because, we are using SLRG, the first 3 options are not available anymore for location specific digit manipulation.

It must be noted that any Called Number Transformation that is performed on the Route Pattern or Route List would be overridden by the Device Pool Called Party Transformation. Another important point to remember is that the Called Number Transformations and Calling Number Transformation do not replace Translation Patterns which still exist on UCM 7.x. Translation Patterns behave slightly differently in that they effect call routing. Once a Translation Pattern has been processed, the CUCM re-attempts digit analysis except the translated number and not the original called number is used for this second attempt at digit analysis. Compare this with Called/Calling Transformations, which do not affect call routing but only serve the purpose of manipulating the Called/Calling Number before being sent to the pre-defined gateway or trunk. In our particular case we will implement CdPTP's on the actual gateway for all outbound calls, which will trump all previous manipulations.

Translation Patterns

Nothing new here. i would like to re-iterate that TP's can influence call routing, in that sense (and i have stated this above as well), Translation Patterns will be analysed and dealt with first, after this digit analysis is re-attempted. In Number plan globalization, TP's will be used to accommodate local dialing habits and translating them in a form so it matches our magic +! RP.

OK, so now I have got this cleared out of the way, I am gonna drink some Scotch malt whiskey. In Part II I will illustrate which steps need to be taken in terms of CUCM configuration work, to pull all this off.

If you think this post can be approved (which i am sure it can), or if you want to further discuss, please put a comment in 


  1. Hi Dennis,

    \+! leaves us with a T302 timeout. I cannot find a way around this.

    Do we have to live with this?

    1. you dont have to use a \+!. This is just the bare minimum route pattern. You could easily implement more granular route patterns based on digit amounts. This would then overcome T302 timeout issues as your patterns are then being matched exactly. Or another option would be to reduce your T302 timeout value.

    2. Agree Dougal,

      T302 will need to expire before a call routing decision can be made, if \+! is the only pattern you could decide to add an additional pattern trailing with "#" to force call routing, and decrease the T302 timer (not too much though).

  2. Thank you for sharing the post. For beneficial telecom assistance you can visit

  3. Dears
    im facing a problem in this
    i configure my Route pattern as
    Pstn Gateway

    and the Gateway is configure as you mentioned and the call come just like this

    Then i configure Transformation to localize the call as

    and i configure phone transformation as Internal

    and the call come to my phone perfectly as

    till now everything is fine

    when i check my history call the number shown as

    so i configure translated pattern

    Stil the call will not work
    i have to Delete the transformation
    then the call is working
    can you help me in this
    the normal full number i dnt know why my phone is 8961 firemware 9-3-4-24 in cucm 9.1