cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3336
Views
25
Helpful
11
Replies

10 Digits DialPlan Design

Hello All,

My company is migrating from a dianplan of 4 digits to 10 digits. The idea is to keep the calls intra-site with 4 digits and calls inter-site with 10 digits.

The question is do I change the extensions numbers on CUCM to 10 digits and add a translation rule on the Gateway to prefix the digits when a incoming call arrives, that way send the 10 digits number to CUCM and add a translation in CUCM that when a 4 digits call is made prefix the 6 remaing.

or

Continue to use 4 digits on callmanager directory number configuration and add a external number mask, that way calls intra-site continue to use the 4 digits and there is no need of translations for that....

Just add a translation on the CUCM for outgoing calls in another site but in the same cluster (remove the first 6 digits)  and another translation for incoming calls from another cluster.

What do you think is best?

1 Accepted Solution

Accepted Solutions

Rafael,

Under the circumstances flat is good.  Excellent write up in the 8.X SRND for guidance....

HTH,

Art

View solution in original post

11 Replies 11

UP!

Someone?

If 10 digits intersite is going to be used, I am assuming you will keep 4 digits for intrasite calls?


Based on some assumption I would do the following:

the following DN's on the phones.

site A=1xxxx

site B=2xxxx

if callers in site A call a phone in site B using 10 digits, just do a translation patters such as 123456.2xxxx and discard digits predot

adding just the translation patterns will be less work than running BAT to change all the DN's on the phones

If it helps post the dialplan and we will work it out.

Regards

Dennis

(if usefull, please post)

Please remember to rate useful posts, by clicking on the stars below.

Thanks Dennis,

The idea is just what you said.

Just want to make sure that is the best design.

Some administrators from others clusters expanded the Dn's from 4 to 10 digits, but I really don't think this is the best way of doing this.

One item that I would like to accomplish is displaying the full 10 digits number when people call internally, but the external number mask will not be able to this right?

Or at least be able to display the full 10 digits number when calling others clusters, what is the best way of doing this?

Raf,

Internally, external phone number mask will not accomplish this.

Calling party transformations will do this and as you will used translation patterns for intersite calls ,

make sure you set the calling party transformation mask to send out 10 digits, do this by populating the "prefix digits (outgoing calls)" in the calling party transformations in the translation pattern. In your case you will prefix 6 digits to make it 10 digits as the caller ID

Please also note that if you are not going change your DNs from 4 to 10 digits, and you still want a 10 digit caller ID internally, you will also need a translation patterns, just for the purpose of manipulating the caller ID from 4 to 10 digits

I hope this makes sense

Please rate if useful

Please remember to rate useful posts, by clicking on the stars below.

The idea for migrating dial plan is to avoid possible overlaps with the business expension, so I would strongly suggest going to flat addressing rather than paritioned addressing, meaning you need to convert all your DNs to desired lenght.  Keep in mind there is more to it than just chaning phone DNs, you need to take into consideration already forwarded DNs as those may have to be changed, voicemail extensions, other application extensions, internal system DNs, etc.

HTH,

Chris

Thanks for the answer Chris...After some research and the posts from the forum, I'm going to the flat addressing.

But I'm curious about one thing. Why should I also change voicemail ext, app ext and internal ext? What is the impact on leaving it with 4 digits? A possible overlapping problem?

Indeed, the idea is to avoid overlaps and ensure every DN is unique.

HTH,

Chris

James Hawkins
Level 8
Level 8

Cisco have a great dial plan design presentation which they were showing when the new dial plan features were introduced in CUCM 7.0.

It has 181 slides and covers design options in great depth.

The presentation title was  UC 7.0 Dial Plan design session and I saw it at the November 2008 European Partner Virtual Team event

If you can ask your Cisco AM to track it down for you it will be a great resource to help you plan the deployment.

This presentation recommends the flat addressing scheme suggested by Chris in the previous post.

It would be interesting if you can update this thread with the design choices you make and issues you face.

asandborgh
Level 4
Level 4

Hi Rafael,

Either strategy will likely be fine, one might be better than the other under different circumstances.  Are most of you sites in the NANP?  If so are you trying to standardize on the fully qualified E.164 number?  What is the reason you are changing the dial-plan now?  Was it not built around multiple sites/regions originally?

If you have many phones/users on the system now changing all of the numbers to ten digits will certainly take a lot more work.  I've set up clusters utilizing both strategies - they work well as long as you follow the underlying logic throughout.

HTH,

Art

Art,

Most sites are in Europe, also have sites in Asia and South America. Yes we have sites using NAMP but not most.

Yes we are trying to go to E.164

In the past the clusters did not talk with each other we getting all cluster now interconnected and the idea is to use E.164.

First I thought that using the 4 digits in the DN and work with translations would be better, but now I'm seeing that for maintaining this, expandind to 10 digits should be better.

Rafael,

Under the circumstances flat is good.  Excellent write up in the 8.X SRND for guidance....

HTH,

Art

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: