07-19-2012 02:17 PM - edited 03-16-2019 12:17 PM
Hi All,
I'm after some advice on a dial plan design for a new CUCM depoyment.
There will be about 20 global offices with a total of 5000 staff connecting to a single CUCM cluster in the US
One of the biggest challanges that I have is making sure that all extension numbers do not overlap and that the dial plan is scalable for future expansion. The company does not want to use a variable dial plan with offnet and site codes etc as we have quite a large mobile workforce who hotdesk in these offices so all users should be dialed using the same extension format.
After looking at the current DID ranges I'm looking at a minimum of a 7 digit extension number for the users to acheive the above but this doesnt avoid an overlapping DID range when we add new DID numbers to an existing office or open up a new office.
One solution that I thought of is using an E164 dial plan and assigning users with an E164 (example +01234567890) extension to ensure that extension are unique but this means that I will need to use translations for abbreviated dialing (to make dialing easier for the users) but this still leaves in the same situation that the abbreivated extensions might clash when a new DID range is configured.
Any suggestions on how to do this without increasing the extension number length even further?
Solved! Go to Solution.
07-20-2012 04:20 AM
HI,
What we have done in the past is this using a 9 digit dial plan.
We divided the dial plan into section as follows:
A=service identifier
BCD=Country code (ur case u can use regional code)
EFGHI=Endpoint identifier
A= can be any number of your chosen and this will idfentify the type of service this dialplan represent. Eg user DN, voicemail port, UCCX DN, short dials etc
BCD, is just what it is
EFGHI= will be the last 5 digit of the user DDI
Example..
A user with DDI=+34 128 58 55980
Will have a DN= 603455980 (assuming 6 is our Service Identifier for user DNs)
Service Identifier | country Code | Endpoint Identifier | ||||||
6 | B | C | D | E | F | G | H | I |
You can modify yours such that the country code is replaced by the area codes since your users are all in one country but different areas.
Eg if you have a user with E.164 number as follows +17134557556 and +12813998552
The resulting DN will be 671357556 and 628198552.
Bear in mind that there is a chance that the last 5 digit of the DDI could overlap eg..
E.16E number for user1= +17134557556
E.16E number for user2= +12813957556
E.16E number for user3=+18322257556
As you can see even though the final DN for the user will be unique, the last 5 digit will overlapp. This could create an issue when you are configuring xlation pattern for short dials.
e.g
Service Identifier | Endpoint Identifier | ||||
* | E | F | G | H | I |
As you can see the short dials for all these numbers will be *57556, that could be an issue. because unless you know which areas each belong to.
The chances of these happening I must say are a little bit remote, but you should still plan for it.
The options of resolving this are
1. Ask for new Block of DDIs for the users affected
2. Change the 5th digit in the E164 number, eg 671357556 will become 671397556 ( i have replaced 5 with 9)
Just my 2 cents...
Please rate all useful posts
"'Nature is too thin a screen, the glory of the omnipresent God bursts through it everywhere"-Ralph Waldo Emerson
07-20-2012 02:42 PM
I recently did a European project with +E164 DNs. Route globally, act locally;
Used translations at the device-level to make 4-digit dialing possible for local dns and used *(country-code)XXXX translations to limit the nr of digits to reach abroad locations.
There are still some gotchas for unity connection and found none for uccx (so far). Connection for example cannot sync with ucm when dns are +e164, you need ldap imports and also use the alternate extension fields for the + dns.
Also I got inter-digit timeout because the DNs are not 'urgent priority'. Cucm has a hard time choosing (inter digit timeout) between +31xxxxxxxx (route pattern) and +3112341234 (dn). Fixed this by summarizing all location did's with a single urgent translation that translates to the same in an other partition housing all phone DNs. Can you follow? (I hope this is fixed in cucm 9)
Regards,
Erik
Sent from Cisco Technical Support iPad App
07-22-2012 09:10 AM
Yes. The dialling habit remains what it is when user A is in his home location.
eg.User A in UK dials *XXXX to reach user B in UK. And dials full nine digit/8 digit extension of user C in US.
when user A moves to US, this pattern remains the same. However when you do the xlation pattern on the device level..
User A can no longer dial user B using *XXXX because the device user A is logged into in the remote location does not have access to that PT. Which means that user A will then need to dial user B's full 9/8 digit DN. This is not a show stopper only that when user A is used to dialling user B in a way he/she may have forgotten what the full DN of user B is....Because it makes things much more seemless....I like this approcah
Please rate all useful posts
"'Nature is too thin a screen, the glory of the omnipresent God bursts through it everywhere"-Ralph Waldo Emerson
07-20-2012 04:20 AM
HI,
What we have done in the past is this using a 9 digit dial plan.
We divided the dial plan into section as follows:
A=service identifier
BCD=Country code (ur case u can use regional code)
EFGHI=Endpoint identifier
A= can be any number of your chosen and this will idfentify the type of service this dialplan represent. Eg user DN, voicemail port, UCCX DN, short dials etc
BCD, is just what it is
EFGHI= will be the last 5 digit of the user DDI
Example..
A user with DDI=+34 128 58 55980
Will have a DN= 603455980 (assuming 6 is our Service Identifier for user DNs)
Service Identifier | country Code | Endpoint Identifier | ||||||
6 | B | C | D | E | F | G | H | I |
You can modify yours such that the country code is replaced by the area codes since your users are all in one country but different areas.
Eg if you have a user with E.164 number as follows +17134557556 and +12813998552
The resulting DN will be 671357556 and 628198552.
Bear in mind that there is a chance that the last 5 digit of the DDI could overlap eg..
E.16E number for user1= +17134557556
E.16E number for user2= +12813957556
E.16E number for user3=+18322257556
As you can see even though the final DN for the user will be unique, the last 5 digit will overlapp. This could create an issue when you are configuring xlation pattern for short dials.
e.g
Service Identifier | Endpoint Identifier | ||||
* | E | F | G | H | I |
As you can see the short dials for all these numbers will be *57556, that could be an issue. because unless you know which areas each belong to.
The chances of these happening I must say are a little bit remote, but you should still plan for it.
The options of resolving this are
1. Ask for new Block of DDIs for the users affected
2. Change the 5th digit in the E164 number, eg 671357556 will become 671397556 ( i have replaced 5 with 9)
Just my 2 cents...
Please rate all useful posts
"'Nature is too thin a screen, the glory of the omnipresent God bursts through it everywhere"-Ralph Waldo Emerson
07-20-2012 06:14 AM
Hi,
This is very helpful, thank you.
Our offices will actually be located all over the world and connecting back to the central cluster in the US via MPLS. All offices will have local PSTN breakout.
The above will work but the abbreviated dials will be a concern as you correctly identified, although a slim chance of this happening I do still need to plan for this. Are you using abbreviated dials in your enviroment?
07-20-2012 06:21 AM
Yes our design had abbreviated dials as you can imagine it could be a nightmare for users dialling 9 digit extensions all the time
Please rate all useful posts
"'Nature is too thin a screen, the glory of the omnipresent God bursts through it everywhere"-Ralph Waldo Emerson
07-20-2012 06:28 AM
In addition to great post by aokanlawon (+5), I have done many, many dial plans over the years ranging from simply 3 digit uniform to 8 digit uniform to different variants of variable length addressing. There are pros and cons to each and it is nicely described in CUCM SRND. The obvious direction from cisco and industry is to use +e164 dial plan, that works great in perfect world where all applications support it (UCCX, CER, etc do not), however in reality it makes for unhappy end user when they have to dial via dial pad. I these days lean with e164 format for defining DNs yet I still recommend abbreviated dialing i.e. 8 digit between sites to avoid overlaps, 4 digits within a site which typically works OK. The issues you run into is keeping Unity/Unity Connection to play nicely with it when users want to check their messages remotely (if required) as their used ID is full e164 number. There are ways to get around it via Routing Rules/CSS/PTs on UCON but it gets a little complex. Either way, if I was in your shoes this is what I would explore, as uniform dial plan as you note with your size will require you to have long digit string (8,9) that all users will need to dial from the dial plan even when they dial a guys 2 cubicles from him, this typically does not go well for users used to dialing 4 digits as they see the new phone system as a downgrade.
HTH,
Chris
07-20-2012 06:48 AM
Hey folks,
Excellent discussion here +5 to both Deji and Chris for their
valuable input!
Cheers!
Rob
Chris....so true about users seeing the new system as a "downgrade"!
"Show a little faith, there's magic in the night" - Springsteen
07-20-2012 07:55 AM
Thanks all. I'm glad I'm not the only one thats faced this issue.
I do like the idea of using E164 with the DNs in the format +123456789 as I understand the benefits of E164 but I have not explored the limitations with UCCX as this is a requirement. What are the currently limitations with UCCX? I just found a post mentioning that CAD didnt support DNs begining with + but apparently this was fixed in one of the lastest releases, is this correct?
07-20-2012 02:42 PM
I recently did a European project with +E164 DNs. Route globally, act locally;
Used translations at the device-level to make 4-digit dialing possible for local dns and used *(country-code)XXXX translations to limit the nr of digits to reach abroad locations.
There are still some gotchas for unity connection and found none for uccx (so far). Connection for example cannot sync with ucm when dns are +e164, you need ldap imports and also use the alternate extension fields for the + dns.
Also I got inter-digit timeout because the DNs are not 'urgent priority'. Cucm has a hard time choosing (inter digit timeout) between +31xxxxxxxx (route pattern) and +3112341234 (dn). Fixed this by summarizing all location did's with a single urgent translation that translates to the same in an other partition housing all phone DNs. Can you follow? (I hope this is fixed in cucm 9)
Regards,
Erik
Sent from Cisco Technical Support iPad App
07-21-2012 02:16 PM
Thanks for the info. How many users and how many sites was this for?
07-21-2012 02:34 PM
1500+ users total, in all major european countries
Sent from Cisco Technical Support iPad App
07-21-2012 02:43 PM
From my experience Abbreviated dialling within a site should be controlled by the Line Calling Search Space configured on the calling device. This means that the user has the same abbreviated dialling experience if they are using a phone at their home location or have temporarily moved to a different location and have logged in using the Extension Mobility feature.
Often people design their system such that site specific xlation patterns are defined at the device level. This implies that a user logged in to EM at a remote site i sunable to maintain his/her home location dialling experience because the device he/she is o n does not have access to her xlation pattern. So consider implementing abbreviated dials at the line CSS
Please rate all useful posts
"'Nature is too thin a screen, the glory of the omnipresent God bursts through it everywhere"-Ralph Waldo Emerson
07-21-2012 02:57 PM
Thanks for the advise.
Just so I understand you correctly regarding the recommendation of line level xlate patterns, if user A in a UK office dials user B in a US office on xlate *001XXXX and then user A moves to that US office, user A still dials user B on *001XXXX instead of XXXX?
07-22-2012 09:10 AM
Yes. The dialling habit remains what it is when user A is in his home location.
eg.User A in UK dials *XXXX to reach user B in UK. And dials full nine digit/8 digit extension of user C in US.
when user A moves to US, this pattern remains the same. However when you do the xlation pattern on the device level..
User A can no longer dial user B using *XXXX because the device user A is logged into in the remote location does not have access to that PT. Which means that user A will then need to dial user B's full 9/8 digit DN. This is not a show stopper only that when user A is used to dialling user B in a way he/she may have forgotten what the full DN of user B is....Because it makes things much more seemless....I like this approcah
Please rate all useful posts
"'Nature is too thin a screen, the glory of the omnipresent God bursts through it everywhere"-Ralph Waldo Emerson
07-21-2012 03:04 PM
Ofcourse, "it depends". both ways work.
We use EM extensively. And we (the users) know/accept/think it is obvious, that when they are abroad they need to dial according to the local dialing habits. ie dial +31.... to reach holland from Germany and dial a local pstn extension to reach the local pizza/taxi company. Thinking this way, translations should be done at the device level.
Regards,
Erik
Sent from Cisco Technical Support iPad App
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide