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.
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.
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
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.
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 !