E.164 Dial Plan Conversions

[pkrysinski]

Hello,

I know that I might be asking a lot of the community as far as an answer is concerned, so if I am out of scope on this topic please let me know and I will open up a TAC case for assistance.

History

We currently have our corporate site configured and ready to go with 10-digit DN's setup.  We have internal translation patterns for 5-digit dialing to make it easier on the users.  Since we have three-clusters now (United States, UK, APAC) our company would like to implement full E.164 dialing and DNs.

Questions

- The first part is to change all of the existing DN's and translation patterns.  I need to change them from 10-digits to \+1(area code)(phone number).  Does CUCM 8.6 still require a \ in-front of the + on a DN?

- If anyone else has implemented E.164 dialing, how do you have it setup so that you can dial another location that is configured within CUCM? Do you have a 5-digit translation pattern? Or do you make the users dial the full 11-digits of the phone number?

- As for dialing extensions within other clusters, I know that I first have to have an inter-cluster trunk setup.  In this kind of scenario, how have you instructed the end-users to dial the international sites? Again with a 5-digit translation or possibly telling them to use the full 10-15 digits of the extension?

- How does E.164 affect AAR configurations?

- One item regarding Unity Connection integration.  How are voicemail pilots setup when a site is using E.164? Are the current 10-digit extensions I have still valid or would UCX need to be re-configured as well?

- Lastly, I have UCX configured with 5-digit extensions so that it is easier for user's to access their voicemail remotely.  If we migrate to E.164, will all users need to then change how they access their remote voicemail boxes using all 11-digits?

Any help that you can provide is greatly appreciated!

Thank you.

[Jonathan Schulenberg]

Does CUCM 8.6 still require a \ in-front of the + on a DN?

Yes. This is not a defect and escapes the plus character to make it a literal character instead of a wildcard.

how do you have it setup so that you can dial another location that is configured within CUCM? Do you have a 5-digit translation pattern? Or do you make the users dial the full 11-digits of the phone number?

My default advice is four/five/whatever-digit intra-site and then your normal offnet patterns for inter-site (e.g. 916085550100). Since you are globalizing all user input to an +E.164 format you can let the user continue to dial as they do today. The globalized patterns will match the OnNet DN and route accordingly.

If that isn't viable you can allow ten or eleven-digit dialing but only if you're careful not to get yourself into a T.302 overlap problem. For example, a common request I hear is to allow straight 10-digit dialing. Ignore for the moment that the international calling patterns then chew up your zero key. The problem with this is that intra-site dialing is likely to overlap. Example: Intra-site is 8XXX and Inter-site is 8XXXXXXXX. If the user dials 8000 they are going to hit a delay before CUCM routes the call. This seems trivial to telecom people but users will complain. The workaround I hear is to prefix the intra-site pattern with # or * (i.e. #8XXX). That's even more change (in addition to changing to 10-digit dialing)! Change equals drama/stress/complaints.

how have you instructed the end-users to dial the international sites? 

The Route Pattern in CUCM would be the global +E.164 format of the TNs at that site. Example +44123456XXX (no idea how legit that is or not, just an example). It doesn't matter how the user dials it: if you allow five-digit translations or if they dial 901144123456789. In either case the globalize-at-ingress phillosophy will convert it to +44123456789 wihch will match the route pattern. You need to mentally disconnect the user input choices from how CUCM routes the call. Globalize, THEN route.

Also, you may want to consider implementing SAF between the CUCM clusters. This allows them to dynamically learn (and forget in the event of a WAN outage) about E.164-formatted TNs in other clusters. If the SAF network breaks those routes will be torn down - think EIGRP-style dynamic routing - and your normal PSTN-bound international route patterns can route the calls.

How does E.164 affect AAR configurations?

It massively simplifies it. There is only one AAR Group and it has no prefix. On the DN you just set the full +E.164 TN in the AAR Destination. Done.

How are voicemail pilots setup when a site is using E.164?

This answer changes in CXN 9.0 because the Primary Extension field supports a +E.164-formatted value. Prior to 9.0 you typically set everything except the plus. This allowed for global uniqueness when doing CXN Networking without needing complicated Partitions/CSSes within the CXN site. For MWI to work you either could change the MWI destination from 'X' to +E.164; or, add translation patterns from the non-plus formatted Primary Extension (e.g. 16085550100) to the CSS applied to the SIP Trunk or VM Ports. If you use translation profiles you must also enable the Multi-Tennent MWI service parameter within CUCM. Without it CUCM won't process translation rules for MWI requests.

Lastly, I have UCX configured with 5-digit extensions

CCX is the last major thorn in the side of +E.164. It will remain this way until CSD/CAD are replaced with Finesse. For the purposes of accessing voicemail the easiest way out would be to add the five-digit value as an Alternate Extension. Short of that you would end up changing the ACD DNs to something more globally unique. Even in a globally unique non-plus formatted value you could add it as an Alternate Extension. Just be careful not to create both the ACD and personal DNs with the plus character; CCX won't be able to tell the difference when doing CTI Manager subscriptions on the device.

Please remember to rate helpful responses and identify helpful or correct answers.

[Roger Kallberg]

Really nice work Jonathan (+5)

Sent from Cisco Technical Support iPhone App

[Ayodeji Okanlawon]

+5 Jonathan..Great Job!..

In addition to the great ideas by Jonathan here are a few things

1. Intrasite calls can be done using abreviated dialling. This makes it a much better experience for the end user. Also ensure that this is implemented on the Line CSS and not on the device CSS. This way when a user moves to a different location his/her dialling experience remains the same

2.Inter site calls within the same cluster: Users should diall the full 11 digit extension numbers. There is no way an abreviated dialling will work in this scenario without getting into overlapping patterns. So calls to other sites will have to be by dialling the full 11 digit number.

3. Inter site calls between Clusters: Here the full 11 digit extension number is also dialled. This is then globalized at ingress. Like Jonathan suggested you should consider using SAF with SME, this will greatly make your call routing easy. In this case globalizing the call provides a great advantage of having a single route pattern to other clusters (\+!)

Thats all the route pattern you will need to route calls to any of the other clusters. This makes your dial plan neat and tidy. All calls are globalized then sent to the SME cluster...

Finally you should carefully consider what your over all dial plan is. Ensure you use a dial plan is unique and less likely to create over laps for you. For example you can have something like this..

A B B B C C C C C C

Where A=Global extension number prefix ( eg 7)

BBB= Country code in the E164 number

CCCCCC= end point identifier and will correspond to the last 6 digit of the DDI

So for a user in the USA with DDI= 9165407300

The full 10 digit Extension will be

7 001 407300

For inter site dialling you can come up with a plan like

8 D D D D D D

where 8 will be the inter site dialling prefix and DDDDDD will be the last 6 digit of the DDI

so fo our USA user the abbreviated dialling will be

8407300

Using the last 6 digit of the DDI will almost gurantee that you avoid overlapps with sites on the same cluster for abbreviated dialling

Please rate all useful posts

"'Nature is too thin a screen, the glory of the omnipresent God bursts through it everywhere"-Ralph Waldo Emerson