+E.164 Dialing in CUCM 7.1.X

[btmulgrew]

Hi - I think i have (at last) got my head around the theory of the new dial plan aproach using +E.164 dialling, globalized and localized routing; but have a couple of question marks around how this ties in with a the phone DN and the Directory in deployment:

As we globalize on-net calls from abbreviated extensions e.g. dialling 51111 on-net, translates this called number to the full  +E.164 using a CSS, should we now address on-net endpoints with their DN as the full +E.164 number?  In respect to this, what should users be made aware of as their internal  extension? Should this still be, for example, internal 5 digit and let the CSS take care of ringing the +E.164 internal endpoint .  Also what is best practice for the corporate directory? should the phone number field be populated with the full +E.164 or the abbreviated extension?

Any thoughts on this would be greatly appreciated.

thks

Brian

[hassan_oudeh · Accepted solution]

Hi

I liked this post and i think it's important to understand the direction of E.164.

I'm also having the same concerns, furthermore I'm doing implementation for CUCI MOC, which should force the extensions on the LDAP to be + prefixed.

But again the users using the corporate directory which is including the +XXXX extension.

unexpectedly the call is not going except you modify and remve the +, but from IP COMM it's working fine !

I'm running CUCM 7.0 which should be full E.164 support !

Regards,

[asandborgh · Accepted solution]

A couple things that should be noted about + dialing.  It is a worldwide standard (ITU-T I think)

indicating that the number that follows it is completely formed and ready to be passed between carriers - in potentially any situation (local, LD, Int'l).  In other words you should only use it when it is followed by the ITU country code and then the proper area/region/subdivision/office code and then the subscriber code.  It should not contain trunk access codes and should not be used in-house.

The beauty of it is that once you have it fully formed you move it to any exit point of your enterprise and drop it onto the PSTN and it should always work.

The other thing to note - that Jonathan wisely noted earlier, is that for CCM you must insert a leading slash ( \ ).  However, at least in CCM 7.1 this is not fully consistent.  As I recall for transformations you need it but route patterns you do not (can't remember exactly).  At any rate keep in mind that you may need it one place but not another, and try it both ways to see what works.

HTH,

Art Sandborgh

[Jonathan Schulenberg]

You need to escape the plus character in any field that accepts expressions. If a field only takes a literal value, such as Prefix Digits, then you do not need to escape the plus character. This is by design.

[Jonathan Schulenberg · Accepted solution]

E.164 is a wonderful design once you understand it and all of the implications to the UCM features like AAR, Unity, etc. It sure is quite a trip to figure it out though. Everyone I try to explain it to looks at me like I'm crazy.

Anyways, to answer your questions:

"As we globalize on-net calls from abbreviated extensions e.g. dialling 51111 on-net, translates this called number to the full  +E.164 using a CSS, should we now address on-net endpoints with their DN as the full +E.164 number?"

If your directory numbers are simply an abbreviation of their E.164 number (51111 expands to +18005551111), then yes. You will need to insert it into UCM as \+16085551111 so the plus is treated as a literal character. A partition in the device-level CSS should include the appropriate translation patterns to expand the user entered abbreviated pattern into it's fully qualified value.

"In respect to this, what should users be made aware of as their internal extension?" Should this still be, for example, internal 5 digit and let the CSS take care of ringing the +E.164 internal endpoint .

There is no need to re-educate them. They should be able to dial it as they already have been. Again, this assumes that extension are simple abbreviations of real telephone numbers. If they dialed five digits before and those five digits were the last five of the E.164 number, they can still call that. Their phone will show the real number though when they make a call.

Also what is best practice for the corporate directory? should the phone number field be populated with the full +E.164 or the abbreviated extension?

The corporate directory is best in an E.164 format. This allows clean dialing from the phone (assuming the model supports plus-dialing!). It also is what other applications are hoping to see as they pick up on the standard. Anything that pulls info from AXL or LDAP gets a universally recognizable value then.

[iptuser55 · Accepted solution]

Just to add, I think it also depends on what your  roadmap is, OSC- dare I say it, makes use of the + feature also

previously AD integration depending on who sets it up may also have added the + dialing as well. It saves you having to translate incoming DN`s to match your internal . With a large cluster, it may makes sense to have the full number on devices to separate them 

[btmulgrew]

Guys - I cant thank you enough for these excellent clarifications; i can see the real benefits of this methodology, particularly when calls arent routed as originally planned (CFWD / AAR / TEHO / LRG / MOBILITY etc).

My (simplistic) view of this is to globalize "called and calling" as close as possible to the calling device (phone / gateway) to accommodate +E.164 routing and presentation within CUC, then localize (if required) as close as possible to the end device (phone / gateway).

I am planning on setting this up in the lab, as I would like to get a feel as to how to deploy the more aesthetic side, e.g. line text labels, alerting, connected, caller id etc.

I think the next phase is to ensure that it is supported throughout the UC suite of apps being deployed (billing / attendant / contact centre etc.)

I was at a partner demo a few months ago when Cisco were talking about this - we were jokingly advised to deploy +E.164 in customer sites were the average age of the customer was under 30!

thks again

[iptuser55]

I forgot

"I think the next phase is to ensure that it is supported throughout the UC suite of apps being deployed (billing / attendant / contact centre etc.)"

This is important particular billing if you have a 3rd party -app. can your billing application server cope with the + sign also be aware of where you do the translations- user dials 4 digit number ( if you let do this still) translate to E164- user real DB- if this is done in the translation section then it does not  effect the CDR db however if you have configure speed dials, contacts from say AD etc with E164 and your telco does not support+ dialing and you have to remove it then again where you do this translation will effect the CDR as if it is done in the translation section as I mentioned no  problem as the "after" translated digits are seen and sent to the CUCM CDR, if you do the Route Patterns and translation, remove using any other then Translations i.e GW, Route Lists, Groups etc then even though you translate it, the "after" digits/digits sent to line are not seen in the CDR.

[Michael Whaley]

With the recent addition of several International office locations into our environment, it became clear very quickly why E.164 works so well (albeit, everyone looks at me like I'm crazy when I explain it).

The challenges we are running into is that we have LECs all over the county all with different rules on how they want their Number Type and Number Plan sent for the various call types (not to mention our Dial Plan/Route Patterns were implemented long before CUCM 7.X).

This year, we have a project on the books to move our domestic DID blocks into a "SIP Cloud", so in order to reduce the amount of work/rework we have to do, we are breaking our E.164 conversion into a couple of different steps.

1. Get everyone's external phone number mask reformatted into E.164 Format (we use "External Phone Number Mask" to control outbound calling number)

2. Configure all outbound Route Patterns to set Calling Party Number Type/Plan to International/ISDN (all of our MGCP gateways are connected to PRI services).

3. Perform SIP Integration using new route patterns.

4. Tweak setup by configuring TEHO behavior, etc.

I'd love to hear how your E.164 configuration/conversions went.

[Jonathan Schulenberg]

The challenges we are running into is that we have LECs all over the  county all with different rules on how they want their Number Type and  Number Plan sent for the various call types (not to mention our Dial  Plan/Route Patterns were implemented long before CUCM 7.X).

I'm guessing you already know this but in case others don't: The E.164 dial plan works to your advantage with varying rules on TON per ISDN circuit. When you localize the pattern from the global form to the 7, 10, 11, or whatever format is appropriate, you can also set the TON and numbering plan at that point.

It isn't required that you convert to SIP trunks for this to work.

[Michael Whaley]

It isn't required that you convert to SIP trunks for this to work.

That's a great point Jonathan. We are only waiting on the conversion to SIP trunks on our end to make our migration for our legacy setup a little easier. If you are building a new system from the ground up, E.164 is the way to go (even if you don't use SIP)! It's worth the effort to understand it, and build it right.

[Jimmi2shooz]

Hello, a little late to the party here...  Has anyone here introduced e.164 dialing to an existing enterprise config?  We have a large cluster which was recently upgraded to CUCM 7.1, and would like to leverage these new features.  However, documentation in CCO mostly talks high level and lists some configuration steps which are helpful to someone who is building a PBX from the ground up. This doesnt help much in our case. It would be great to speak with someone who's had experience with this, so that i could strategize.  Are Local Route Groups neccessary to do this, or can it just be provisioned "normally?"  If they are required, has anyone had any luck migrating to them from provisioned route groups with out breaking anything?

Any insight or shared experiences would be great.

thanks,

-james

[Jonathan Schulenberg]

You're not late to the game, many people haven't even noticed this topic yet. Just wait until they start approaching SAF, IME, Tandberg, or anything else that breaks UCM out of its silo.

I agree the documentation doesn't do a great job of walking you through it. These forums are somewhat limiting by nature to addressing specific questions; working through a design and migration strategy is probably better suited for a phone call or other medium.

To answer your specific questions:

• Local Route Groups are not required for E.164; however, for any customer with distributed PSTN connectivity, they tend to be an awesome tool.
• Migrating to LRGs, or E.164 in general for that matter, is somewhat involved because UCM doesn't provide anything you would consider a migration path. You essentially have to modify the relevant dial-plan elements in place; or, rebuild them and change over to it.
  If the project plan allows for it, I tend to just start a new cluster since many of these customers upgrading have to go through an MCS hardware change anyways and this provides for an easy rollback plan.
  

Anyway, I would be happy to answer specific questions on here. If you're looking for a Cisco partner that has gone through this, PDS is happy to help. My contact information is listed in my profile.

[btmulgrew]

Hi - I would just back up Jonathan's comments; we have deployed it for a few customers and you do start to see the benefits, as well as being able to make the move fairly transparent to those users who may feel uncomfortable with the +e164 format.

One thing that can add some complexity is in the UC apps you may be integrating but these are pretty well documented and workarounds are available (usually by Jonathan!).

Some examples included:

Unit Connection / Visual Vmail supporting +e164 as primary number

UCCX support

Meeting Place 6.0 / 7.0 / Meeting Place Express outdial from within a web conference (Adobe Breeze)

CUPC 7.0 (this is resolved in the latest  7.x release)

Thanks

Brian

[Chris Deren]

Guys,  great thread.

I was hoping to jump on the band wagon and deploy e164 dial plan fror my next truly global customer with offices in every major country in the world, and I was hoping UCON 8.5 would support + dialing to define my extensions within UCON, however after reading the release notes it appears this feature did not make the cut.  So, my question is how do others work around the limitations of apps such as UCON, CER, UCCX which do not support + dialing currently.  Do you simply use translation pattenrs?  Are there any caveats to it?

Chris