Your right, there is no urgent need to do multiples, but I have some annoyances around the way the admin is structured.
Two reasons: First, from a troubleshooting standpoint, I find my self resetting CTI RPs a lot. if that doesn't work, the next step is usually de-associating and re-associating my JTAPI / PG user account to the RPs. When I have multiple numbers per CTIO RP (just on the test systems for now), I can eliminate the CCM related issues when some numbers work and others don't.
Second, and more important (in my mind) is that the User / Device Association tool (in CCM 4.1) is horribly cumbersome. I have many TFNs, Device profiles etc and have to browse through 49 pages of that horrible user interface to see if something is already in the list! I just have this urge to simplify and consolidate things. I find the UI administratively hostile and am trying to simply and minimize the amount of effort it takes. I will however survive in the current MO.
Lastly, I am just curious in an academic sense as to what breaks or gets confused when multiple DNs are assigned to a single RP. There must be some specific reason? I'm just starting up with ICM/IPCC and am trying to get some intuitive sense of the relationships between the various components.
sorry...I'm a complete iTard today...totally misunderstood your statement.
It would be a bad idea to assign more DNs to an RP than there are cti ports to handle the calls.
Other than that I can't see where it would be a bad idea to assign multiple DNs to an RP if they are to be used for the same application but there may be a few instances where it is especially beneficial.
This could be used for those, rare, circumstances that require integration of a system to the CCM/ICM environment where you have multiple lines, say 800 numbers, to access the system. (for ease of administration)
Or perhaps you have only 1 port available out of your licenced ports. Using multiple DNs on the RP would help get the calls through the system without requiring the addtional cti port licenses.
(it may be just as easy or better to use a wildcard in your RP when configuing DNs; ie: 22XX to cover the 2200 - 2299 numbers that should be answered by the RP)
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...