Multiple Numbers on a CTI Route Point

[wschochet]

Why is this bad? It's sooooo tempting. Has anyone had any extperience with this or any other information? Is there some document some where that discusses this?

[gpulos]

Not exactly sure what you mean by 'multiple numbers on a cti route point'.

You can only assign a single DN to a CTI Route Point.

The CTI Route Point can use many CTI Ports, each with their own DN.

(or multiple cti route points can use the same cti port groups)

[wschochet]

Yes, I should have said DNs. And, I'm thinking specifically of ICM/IPCC. Why is it that you you can only assign one DN to each?

[geoff]

Why would you want to? Route points are free - make as many as you like. They all have different Dialed Numbers.

Regards,

Geoff

[wschochet]

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.

Thanks...

[gpulos]

The fact that you have to reset your CTI RPs continually tells me you probably have something wrong with your Peripheral Gateway.

(or connectivity issues altogether)

Check you PG config. Why do you have to reset CTI RPs? What is the symptom you're troubleshooting?

There is no way to get around the PGUser device association. It is required for every CTI RP you need active.

(again, you can only assign one DN per CTI RP. You cannot assign multiple DNs to a single CTI RP; a CTI RP can only have one DN assigned to it....that is the specific reason.

(unless i am misunderstanding your question...)

[wschochet]

"You cannot assign multiple DNs to a single CTI RP; a CTI RP can only have one DN assigned to it....that is the specific reason."

But I can - I can go in there and load it up with as many DNs as I want as long as the call totals don't exceed 9500 (in CCM 4.1 anyway).

I'm willing to subscribe to the "it's a bad idea to do that" theory, but I'm trying to understand why it's a bad idea. What is the risk? What breaks?

[gpulos]

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)

[geoff]

If you don't like the web pages for device association in CCM 4.1, wait until you get to the Linux ones (CUCM 5.x, CUCM 6.x). They are far worse.

Regards,

Geoff