Number plan globalisation (based on the Australian Numbering Plan)…

Number plan globalisation (based on the Australian Numbering Plan) – Part 2 The Chuck Norris Route Pattern

Part II of my E.164 globalization on Cisco Unified Call Manager series. In this part, I will discuss and describe the nuts and bolts of making E.164 happen. In part one I have already discussed the why. Cisco has a really good chapter on this topic in their services and features guide:

http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/admin/8_5_1/ccmfeat/fscallpn.html http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/admin/8_5_1/ccmfeat/fscallpn.html

INBOUND CALLING PARTY NORMALIZATION

1-Incoming calling party normalisation to E.164

OK, so the first part is the incoming calling party normalisation. The most appropriate way to apply this, is at a gateway settings level. I am assuming that your provider is sending 10 digits for national and subscriber calls (could be 8 for subscriber calls, so use Q.931 debug to verify) and 14 for international, so 001144 20 XXXX XXXX for a call from London coming into our gateway in Melbourne (again, check Q.931 because maybe your provider is already presenting +E.164 international calls)

This results in the following gateway incoming party transformations:

Incoming Calling Party Transformation on the gateway

2-Incoming calling party localisation
So the next step is localizing the E.164 format back. Remember that the calling party presentations that we have obtained in step 1, are OK if the call will be presented to an oversees user (who can quickly ascertain that the call is international and from a party in Australia) but are not so meaningful for an Australian user who would probably want to see where in Australia the call originated. So, according to the AUNP and using our example location, Melbourne, this localization equates to:2-Incoming Calling Party Localization

Subscriber: [89]XXXXXXX (8 digits)
National: 0[23478]XXXXXXXX (10 digits)

Please note that the CngPTP for National Calls includes mobile numbers.

Whatever happens in this step in terms of Digit manipulation is what eventually ends up on the phone screen. IT DOES NOT SHOW UP IN THE CALL HISTORY LOG, these are two distinctly different things. This because CngPTP are transformations on the terminating device (the IP phone being called). Whereas missed call entities are globalized E.164 numbers rooted in the CUCM DB. Remember, transformation patterns are NOT routable. When a pattern is matched its is not routed to any end device, this is really important to remember.

For localization, I will first create a CSS called CSS_AUS_ANI_XFORM_IN.

And I will apply this to the device pool of the Melbourne phone.

Calling Party Transformation CSS setting in the Device Pool Configuration

Now onto the actual Calling Party Transformation Pattern (CngPTP).

Subscriber CngPTP

Obviously, the \+613.[89]XXXXXXX pattern is for Melbourne Metro only. So the CngPTP CSS for Melbourne would need to be different from a CngPTP for Geelong (which would have a \+613.52XXXXXX for subscriber calls)

National/STD CngPTP

Please not that in the pattern above, calls from Mobile phones (04XXXXXXXX) are included as well.

OUTBOUND CALLED PARTY NORMALIZATION

1-The magic route pattern +! used to Globalize

So first of, our magic omnipotent, trillion million times meaner than wannabees Lars Ulrich and James Hetfield together, it is truly the Chuck Norris of Route Patterns: +!

+! route pattern

(The pattern is actually entered as \+! , otherwise CUCM will not accept its entry). Because Class of Control cannot be enforced on a RP level any more, (simply because we have only one RP and thus cannot make any distinction anymore) all phones will have the PT_AUS_OFFNET_E164 partition in their CSS (unless of course certain phones are not allowed to make Off Net calls). As you can also see, this pattern uses RL “RL_LOCAL”, which points to the SLRG.

2-Translation Patterns and Class of Control

Now we have a +! pattern that all phones have access to, and which is all that they will get access to. So now we need to make sure that whatever a user dials, is forced to match that pattern. Because you can’t expect your users to dial +61385671234 to order a kebab at the shop around the corner, local dialing habits will need to be accommodated, as well (have I said this before? Yes I have; in Part I).

Table below, provides translation pattern coverage of AUNP (well actually it doesn’t because numbers such as 1100 Dial before you Dig, directory assistance etc are not in it, so you might want to expand that table, I just couldn’t be bothered). It provides coverage for Local, Standard (10 digits), and International Aim of the TP’s below is not only to provide localization from the caller’s perspective, but also to force all called party numbers be globalised into E.164 .

Translation Patterns for Globalisationa and to allow class of control

Now, because we no longer have RP’s available to enforce class of control (CSS), it will need to be done on a TP level. I am assuming 4 calling permission classes:

Emergency and Local (CSS_LOCAL)
Emergency, Local and Standard (CSS_STD)
Emergency, Local, Standard and International (CSS_INTL)
Emergency, Local, Standard, International and Premium (CSS_PREM)

For this I have put all TP’s in their relevant partitions. Additionally, all phones are allowed to make On Net calls. Nothing special about this, same class of control as you would normally apply on a Route Pattern basis, but no applied to Translation patterns.

There is one flaw in this approach, and I let you sit on it for a while, if you have picked it up, well, you must be a nerd. It has to do with our missed call log and enforcing Class of Control on those numbers. As you will remember all missed/received calls have the +E.164 format (seeing they were dictated by the Incoming Calling party settings on the CUCM gateway). These could be subscriber, national, or international calls. Now, if we don’t cover them off, then any user in the CSS CSS_STD, would still be able to make international calls. This because a user dialing, for instance, +44 20 1122 3344, from the missed call history, would have a match on our +! RP. The same would applies for a Melbourne user with the local calling privileges only i.e. CSS_LOCAL, with a missed call from +61781122334. So TP’s will need to be put into place to allow Class of Control enforcing, for E.164 formatted called numbers. The last 2 patterns in the table above, cover these missed call history numbers.

I have added a +613[89]XXXXXXX pattern for all Melbourne local calls in its own partition, and this will need to be reflected throughout the deployment, based on a phones location. For example in Geelong you could have a +61352XXXXXX pattern for local calls in PT_PSTN_GEE_LOCAL in CSS_LOCAL_GEE.

3-Called Party Transformation Patterns (cdPTP)

The Patterns used in the table above, can be re-used to create these CdPTP’s.

Because we have already enforced Class of Control and assuming carrier requirements in terms of the presented number are the same throughout Australia, or any country that is being considered for that matter, we will re use the same Called Party Transformation CSS. PT_AUS_DNIS_XFORM_OUT and CSS_AUS_DNIS_XFORM_OUT and re-apply this to all gateways in the deployment.

Calling Party Transformation CSS on Gateway page

This would lead to the following CdPTP, in this case for National calls:

So a national call to +0391122334 is now transformed into 0391122334 and send out the PSTN, most likely using an IOS pots dial-peer, or a voip dial-peer.

One of the last things that needs to be taken care of, is pattern transformation when dialing from phone history, remember that these all have +E164 notation. (Remember I said that CngPTP’s do NOT change the CUCM DB and will therefore not change the call history!!). Therefore, I want to bring this back to the original 10 digits for national and 8 digits for subscriber. So I will need to add 2 more CdPTPs. So for subscriber calls I would add a pattern \+613.[89]XXXXXXXX and I would DD=Predot and prefix 0. In summary, I would end up with the following CdPTP’s:

CdPTP summary

So I guess open for discussion at this stage, is should I replace all, but the last 2 (in table above) to CdPTP +!, this would strip just the + off all called parties, except for National and Subscriber calls (where I would strip +, the country code and the national code for a subscriber call). i will look into this further and edit this post accordingly. I am inclined to strip the + sign of all called party numbers before sending it out. This would result in called party numbers with a prefixed 0 for subscriber, national, and international calls. This would further reduce the number of CdPTP, but more importantly it will simplify the the gateway configuration. Let me explain.

With the approach of sending a prefixed 0 in all called party numbers (so both from localized calls as well as calls from the missed call history) to the IOS gateway, it will allow for very simple dial peer configuration (a 0T pattern would suffice for all PSTN outbound calls). Furthermore, it will allow the same dialing habits in SRST mode (and let’s face it fall back should be transparent for a user), without doubling up the amount of dial peers. So that same 0T pattern could still function in SRST mode for all outbound PSTN calls. Alternatively a hybrid solution is possible whereby a +T destination pattern, on the IOS gateway, is added as a catch all. For instance when a call to Germany is made by hitting the Dial soft key from a missed call log (so in +E.164 format) to +492011223344, it would go through a TP, to enforce Class of service, if it passes, it is still the same +E.164 number. I would now prefer to have a +.! CngPTP in place that would strip + and would prefix the international access code 00011 and then have it match 0T destination pattern. You could choose however, not to have the +.! CngPTP and pass the unchanged +E.164 number onto the IOS gateway and have it match a +T destination pattern.This +! destination pattern could then also be used on an SRST phone when a users decides to opt for +E.164 dialing, not a bad idea either.

Now the other thing i haven’t mentioned yet (well, since part I anyway) and you should have probably realized by now, is that AAR is gonna be a doddle to set up. Once you have fully compatible E.164 dial plan and all the external phone number masks are in E.164 formats, there is no need to additional AAR group prefix configuration.

Tail End Hop Off (TEHO) will be a hell of a lot easier as well, especially when international calls can be handed over to their respective geographically local gateways. For instance handing off all calls for Sydney (the other Australian city) to the local gateway is as simple as adding a +612XXXXXXXX pattern and pointing it to the Sydney gateway (NOT USING SLRG’s), easy as that

Number plan globalisation (based on the Australian Numbering Plan) – Part 2