CUCM 8.5, CER 8.5 and Variable length dial-plan issues

[desmith]

Hello!

In the past, I remember that there were issues with having variable length dial-plans at different sites: the inter-digit timeout was set cluster-wide, and so folks at a site with, e.g., a 4-digit dial-plan would have to wait a long time (whatever the interdigit timeout was set to) before their call would complete. 

I have heard that this is no longer a problem.  Is that because of some new capability to set the interdigit timeout by region, or something?  Or is that information incorrect and it still is an issue?  (This is a situation where there is 3-, 4-, and 5-digit dialing at different sites.  They want a centralized CUCM, and are adamant about not changing dial plans.)

Also, any issues in such an environment with CER?

Thank you for any information/direction you may have!

Cheerio,

Deb

[chrward]

Hi Deb,

I am not aware of any changes to the inter-digit timeout settings in terms of their scope (still a global setting). As long as the partitions and calling search spaces contain well thought-out route and translation patterns, you could minimize or eliminate any issues you have with variable length dial plans. Without specific issues or details about this customer's dial plan its hard to say if this customer would face issues, but good planning can probably solve most of the issues.

In regards to CER, there should be no issue since CER uses phone location (based off device name) rather than DN to apply proper call routing to 911 calls.

HTH

Chris

[desmith]

Thanks for your response, Chris.

I'm fine with the CUCM question now, but I still have a concern about CER. 

I see the following caution in the CER Admin Guide:

---

Caution Before you create a Cisco ER cluster, be aware that the dial plans in all Cisco Unified Communications Manager clusters supported by the Cisco ER cluster must be unique. For example, extension 2002 can only be defined in one Cisco Unified Communications Manager cluster. If you have overlapping dial plans, you must have separate Cisco ER clusters, which means you cannot support dynamic phone movement between those Cisco Unified Communications Manager clusters.

This particular caution is related to the case where a CER supports more than one CUCM cluster.  However, it's unclear to me why in this case an overlapping dial plan is a serious problem, while in the case of a single CUCM cluster, it isn't.  Isn't the phone location information still different between the two clusters, even if the DN is the same?  

Thanks for any insights or help you can offer!

Deb

[Jeffrey Ness]

Deb,

In a single cluster scenario the issue with overlapping extensions is the CTI ports for CER can only have 1 Calling Search Space causing it to only be able to reach one of the numbers (whichever is first in the list of partitions for that CSS). I'm not sure how this works in a single CER multiple CUCM cluster integration as each CUCM cluster would have CTI ports for CER.

[chrward]

Hi Deb,

I may have not taken CER call back into account when I said CER should function. 911 calls will go out, but callback may or may not work, I am checking on some CER info that might help me answer the call back question and I will post that when I get it.

One way to work around all these issues is to have the illusion on overlapping DNs without actually having them. Basically, make your DNs include site codes, but using line labels and the like, you can mask the site codes. So basically, every phone has a unique DN, but the users are not aware of that. You would use translation patters and route patterns to enable 3, 4, and 5 digit dialing and inter-site dialing. This would also solve any CER issues since all the DNs would be unique.

Once I hear back from the CER team I will update on CER with true over-lapping dial plans.

Chris

[chrward · Accepted solution]

Hi Deb,

I got word back and even with a single CUCM cluster with a single CER cluster, call back wouldn't work with overlapping dial plans (two phones with the same DNs).

So the only option left would be to make unique DNs and then mask them to the users through line labels and translation patterns.

HTH,

Chris

[desmith]

Thank you very much, Chris and Jeff, for taking the time and trouble to answer.

It looked to me like there would be a problem with CER, and I appreciate knowing for certain. 

The clever suggestion on how to make it work anyway (through line labels and translation patterns) is a triple bonus! 

Thanks again, and Best Regards,

Deb