I am in the planning stages of a potentially large Call Manger installation. We will start out w/ 14 rather large core sites with anywhere from 700 to 1200 IP sets If all goes well, over the the next few years adding over 200 smaller sites w/ 40 to 100 IP sets at each site. I am trying to design the dial plan for the long term and have come up against a few road blocks Looking at the existing number range for all sites, the number range covers nearly all ranges with overlaps My idea is to have location codes plus their 4 digit DID DN for each site. The only issue I see is that the location code ranges overlap w/ DN ranges Solution ??? all on-net calls start w a * plus location code plus 4 digit DN, which will allow me to pick a range of over 200 location codes and not worry about any overlaps .Please let me know what you all think about using the * or any other suggestions .THANKS ALL!!
What if you do this...
Give all users a 7 digit extension (the last 7 of the DID). Assuming you have no overlap with 7 digits. Then you can create a translation pattern so that within a site users can just dial the last 4 digits to reach other people within the same site. If they need to call out of the site to another, then they would need to use the 7 digit extension.
I have used this technique several times. It works out well...
Well, there is the ideal way to set this up and then there's the way that you can actually convince the customer to go with. Ideally, you should setup each site with the same extension range, say 3000-4999. Then setup the standard "Dial 9 for outside line" and setup another access number, I'd suggest 8, for on-net, intra-site calls, in the format 8LLLXXXX where LLL is location code and XXXX is extension.
Unfortantely, it sounds like the customer has existing extension ranges and doesn't want to change. In that case, I would suggest letting all sites with extension below 8000 to keep there's but force the customer to change any 8XXX or 9XXX extension ranges. Explain to the customer that this type of intergration requires some changes. They should be thankful that you don't require them to use 5 digits and all 15000 phone to have a unique extension.
As for useing the asterik as an access digit, a) I'm not sure Cisco allows it today, and B) if they do, I would suspect that you will see compatibility issues down the road with additional features, such as SRST, auto-attendant, and AAR.
In any case, it sounds like a peach of a design. Good luck on it.
First, let's do some math: 14 core sites * about 1000 sets each == 14,000 DNs. 200 remote sites * about 75 sets each == 15,000 DNs. Total of 29,000 directory numbers.
Then multiply this by two, because best practice is to give each user a second directory number different from their first that their first line can CFB to. This is to give people effective, working Call Waiting service that you can't do with CCM 3.3 on a single DN (CCM 4.0 is supposed to fix this, if you're willing to wait). Some people like to use the same DN in a different partition. We used to do this, but it turns out to be a bad idea for any sort of TAPI application, because TAPI has no concept of partitions. This scheme also gets Attendant Console confused about line states, for the same reason - line 1 gets a call, line 2 gets a call, line 2 hangs up - AC thinks you're off the phone and you're not. So now we're up to 58,000 directory numbers not including system DNs for voicemail, IPCC express, hunt groups and shared lines, etc. Let's call it an even 60,000 directory numbers.
So, that's a lot of directory numbers. Consider that you effectively have only [1-8]XXXX to work with, because you need 9 for trunk access and it's not a real great idea to lead DNs with 0. So you would only have 20,000 directory numbers left if all of the above were perfectly "packed", which won't be even close to the truth if you try to make the numbers make any sort of sense in a locations kind of scheme and do DID number matching. You kind of want to do that for the humans to understand the dial plan, and you really want to do so for the system to understand the dial plan, so you can set up sensible wildcard route patterns, patterns for AAR, a working backup dial plan in SRST, etc.
All of this means that even if you managed to jam this into a 5-digit dialing plan, you would have pretty much zero room for expansion, which is not a good idea. What else can you do? You can go for 6 or 7 digit internal dialing, but that will probably get you lynched by your users. Or, you can not have a unified internal dialing plan, which is what I would suggest.
I'm going to assume you will have several separate clusters for this deployment. I think you're technically within the max phone count for a cluster right now, but it's kind of close and really you want to have dedicated local CallManager(s) at least for all your core sites, and you can't have that many CallManagers in a single cluster. So we're going to have many CallManager clusters communicating via intercluster trunks or similar.
Consider a scheme where each site has a 3 or 4 digit internal dial plan, and dials the full 7 or 10 digit PSTN DID number for the party they're trying to reach at other sites. You have the ability to intercept 7/10 digit numbers they've called and translate it to another partition or send it over intercluster trunks if that's called for. Then, if the network goes down between sites, you already have their full phone number to send out the PSTN, and if you go into SRST mode at a remote, you again have the 10 digit number to make the call. Internal extensions at different sites can and probably will overlap in this scheme. Very few corporations of this size already have a unified internal dialing plan, so this is no functionality loss for them, it's actually what they're used to. It's just that you're able to fix it so they don't get long-distance bills. This scheme does depend on everybody having DID numbers, but it also lends you the room in the dial plan to make sure you can match people's extensions to their DID numbers.
If you're willing to accept dividing up the dial plan and just want to shorten down the number of digits they need to call between sites from 10 digits, yes, you can use some sort of location code in front of their extension. However, this is a third set of numbers for a user to remember besides the user's internal extension and their external DID. You suggest using * or # for a prefix on this; you should bear in mind the caveat that at least on 7940/7960 and I think the 7920, you can't start on-hook dialing with a * or a # (try it!), and a lot of users like to do this.
I was thinking along the same lines. I have a large plan in the implementation stages. I was thinking have users dial 8-XXX-XXXX for intersite calls, dialing XXXX for calls within the same site (partition) to keep them from protesting dialing 7 digits within a site. Using the area code for the office location seems like a good idea. The tricky part is having the intersite calls automatically route to the PSTN of the WAN is unavailable. Anyone have any ideas? Thanks
You would setup up two Route Groups in the Route List Route Group1/first choice would be on-net dialing and Route Group2/second choice out you will need to pre-pend 1-NPA-NXX-4 digit DN Hope this helps
My suggestion was to have them call remote sites just as if they were calling them over the PSTN, trunk access code and everything. Let CallManager outsmart the user and route it over the IP WAN if possible. If there's a problem, well, put some PSTN circuits after your intercluster trunk in the route group you use to send that call out. Done and done. There is, again, the caveat that everybody has to have DIDs, so you'll have to come up with something else if they don't.
I thought of that, because it would make automatic failover to the PSTN a non-event, user-wise. I could still do 4-digit dialing within the individual partitions. The difference between dialing 7 digits for a large company (apprx 3500 users) and ten digits is not that significant. Does anyone know of a good guide I can refernce for ideas?