I do not believe there is an official suggestion. Most dial plans are built around what DID ranges the customer has across their sites in an attempt to avoid inter-site access codes if possible. I would personally recommend against assigning 9XXX to the CTI Ports (or anything else) if that is your off-net access code. This would likely break things such as your secondary dial tone or require the T302 timer to expire if a call does not use enbloc dialing (i.e. user dials a call digit by digit).
In practical terms, I see 8XXX least frequently assigned as a DID range; however, this may be a local symptom due to lower prefix utilization in my area. Urban areas may not be able say this as the prefix is nearing exhaustion.
Well, everyone will have their own methods and reasons for choosing said method. Cisco won't have a specific recommendation nor should they really. My approach in North America is pretty straight forward. If the customer has a pre-conceived notion or existing design I will take that into consideration. People get used to doing things a certain way and if there are no conflicts I choose not to pick a fight. Mainly because I have plenty of other design points that are more important.
If the customer has no opinion or their proposal is not workable, then I typically default to using a 7-digit plan with a leading "1" in the 7th digit. This is because the NANP excludes 0 and 1 in the NPA and NXX portion of the phone number. Meaning, you will not see an area code or exchange that starts with a 0 or a 1. I try to incorporate that fact into my dialplan. Particularly for "software" or "application" numbers. So, Unity ports, UCCX CTI RP/CTI Ports, etc.
I used to be more stubborn about these aspects of the dial plan but now I have loosened up some. What I like to do (in NANP) is to lay out a 10-digit solution using the customer's DID and a private numbering standard using the leading "0" or "1" digit approach. I find that most customers already have a range of numbers they reserve for private numbering. I try to tap into that and expand it if I can.
All that being said, personally I would stay away from using a digit that is also known as the "steering" or trunk access digit (typically "9", but I have also seen "8" used). The reason I steer clear of this assignment is because I have been pulled into customer issues where they lost secondary dial-tone. Which typically means they assigned a "9" (or other as applicable) as a leading digit to an extension, mml, or UCCX port. For some strange reason it always falls into one of those three buckets. Now, it should be said that if your dialplan approach has a hierarchy built-in then using a "9" is non-issue. Sounds like you have worked that out. So, not sure you need to tweak it.
Have you run into issues with assigning directory numbers that have a leading zero digit? I have always steered clear of that since the UCM documentation says not to use it, at least for auto registration DNs. It doesn't elaborate why; I presumed that some subroutine or DB field may strip the leading zero if they process it as an integer or something. Zero does make for a wonderful off-net steering code though.
That is a good question. Because, "0" is one of those special digits that seems to be a problem. I suppose I do avoid it but not to the point where I won't use it. You are correct though in that there are several Cisco products that have or had a problem with "0" as a leading digit. Which always amazed me. It is just a number! I recall having issues with VG248 and DPA devices when integrating with legacy VM systems. If the VM system had a "0" as a leading digit it was a big pain in the ***. Which is just plain annoying. Slowly, over time, I believe Cisco has fixed many of these defects.
As far as auto-registration I wasn't aware the leading "0" caveat. I am not a fan of auto-registration for several reasons, but that is good info.
In regards to digits, I think that everything on the DTMF keypad is fair game. I also use the "*" for a lot of "private" numbers (like a voicemail pilot number) because you can guarantee uniqueness and longevity. I even use "*" for call park applications. It is funny, users are picky about what they will dial. They b**** and moan about dialing more than 4-digits but you throw a two-digit "star-code" at them and no complaints, AS LONG as they can associate it to an application (like call park, or blocking CLID, or transfer to a VM box, etc.). Humans are funny.
SIP traces provide key information in troubleshooting SIP Trunks, SIP
endpoints and other SIP related issues. Even though these traces are in
clear text, these texts can be gibberish unless you understand fully
what they mean. This document attempts to br...
Please find the attached HTML document, download and open it on your PC.
This provides an easy to use form where you simply answer a few
questions and it will render the proper jabber-config.xml file for you
to copy/paste. There is built in logic to verif...
CUCM Database Replication is an area in which Cisco customers and
partners have asked for more in-depth training in being able to properly
assess a replication problem and potentially resolve an issue without
involving TAC. This document discusses the bas...