Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

New Member

UCCX CTI Ports - range suggestions?

We used CTI ports starting with a 9 and we 

put the CTI ports and route points 

in a separate partition so they are not in the same partition as what the customer would dial out to the PSTN,

so that there would not be a conflict with 9.X route patterns.  This works.

Is there any standard practice on what ranges

CTI ports should be in? I keep seeing in 4 digit

dial plan the least used is 9XXX.

and if Cisco recommends avoiding

certain DN ranges like 9XXX

for UCCX CTI ports

VIP Super Bronze

Re: UCCX CTI Ports - range suggestions?

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.

Please remember to rate helpful responses and identify helpful or

Re: UCCX CTI Ports - range suggestions?

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.




Please remember to rate helpful posts.

HTH -Bill (b) (t) @ucguerrilla

Please remember to rate helpful responses and identify

VIP Super Bronze

Re: UCCX CTI Ports - range suggestions?

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.

Please remember to rate helpful responses and identify helpful or

Re: UCCX CTI Ports - range suggestions?

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.


HTH -Bill (b) (t) @ucguerrilla

Please remember to rate helpful responses and identify