I currently have 2 Pims pointing to 2 different call managers (more for resilience than anything), within ICM have I so far configured Skill Groups, Agents, etc to point to the Routing Client of one of the Call Managers.
Is there a way to have all the Agents and Skill groups configured and talking to the second Call Manager via the routing client without having to enter duplicate ICM config (eg. agent details, skill groups, etc).
If you are using ICM 4.6.1 or greater, then you do not need 2 separate PIMs. You can treat the CM cluster as a single Peripheral and Routing Client, with all the Agents associated with it.
Set up your "A" side PG's PIM to connect to the Subscriber CM and the "B" side to the Publisher. Because we now communicate with a process on CM called CTI Manager, we can get information about the entire cluster from any single connection.
Can you please explain why you go for connection from Side A pim to CCM sub and Side B Pim to CCM pub.
Since we plan to go for CCM Cluster setup. Side A Pim and Side B Pim can target Same CCM publisher. if anything wrong with the side A pim then Side B pim will come to the picture and communicate to the CCM Pub. If something wrong with the CCM Pub, as cisco says the other ccm in the cluster setup should come to the picture and do the required action.
This is what I understood. Correct me if I am wrong,
Sorry - it is a little confusing. You're close, but here are the factors:
When you set up the PIMs on the PG, you are actually configuring CTI Manager connections. If both PIMs point to, as in your example, the Publisher, then you would lose connectivity if the Publisher should fail. The PG failover will be fine, but it is CM failure that we're trying to work around as well.
The reason I mentioned Side A PG/PIM connecting to the Subscriber is that you generally want to avoid connecting to the Publisher's CTI Manager. This is strictly for load balancing reasons. The Publisher is usually the most heavily loaded machine, because of its publishing duties.
So, you basically end up with a 2:2 ratio - 2 PIMs connecting to 2 different CallManagers (CTI Managers). Since the CTI Manager interface allows us to see the entire cluster as a single Periperal (in ICM terms), then it doesn't matter which one we connect to. Having a duplexed PG and 2 separate CM/CTI Manager connections protects you from PG failure as well as CM failure. In fact, this configuration could survive a multiple machine failure scenario (1 PG and 1 CM).
Hopefully that's slightly clearer than mud! Let me know if you have any more questions.
I did as you mentioned and connected side A PG to Subscriber and side B to the Publisher. This works fine from the PG perspective but this doesn't resolve the CTI agent resilience as the CTI service can only connect to one PG. Surely if, for example, Call Manager 'A' went down and the CTI service was configured to the associated PG, then although PG B would stand in and calls would be routed to a queue no of the agent would be able to login as the CTI service can not see the side B PG.
Also I should have mentioned this sooner but we are running ICM 4.6.2
There is redundancy down to the Agent, depending on which CTI Desktop Application you're using.
Are you using the Cisco Agent Desktop (CAD)? If so, then the CAD servers themselves are not able to be duplexed, save for the Directory Services portion.
If you are using CTI OS Desktop, then your CTIOS server can communicate with either CTI Server side, and the Desktops themselves will communicate with either CTIOS Server.
Even if you have a custom app that talks directly to CTI Server, unless the app has not been configured to do so, it should be able to communicate with either CTI Server. The CTI Server process itself is redundant - as long as there is an active PIM on one side of the PG, there is CTI connectivity.
The short answer is that you don't.... That isn't entirely true while at
the same time it kind of is, but for the most part you don't configure
the softkeys. You enable or disable them via TCL. Here is the long
answer. Be sure to read the whole thing or e...
Topology: IP Phone > Switches > Microsoft NPS setup to forward 802.1x
proxy to > ISE 2.1 patch 3 Authentication: EAP-TLS using Cisco MIC SANs
Phone Models 802.1X support? 802.1x flavor Addtl Comment EAP-MD5 EAP-TLS
Cisco 3905 Y Y N Cisco 6911 Y Y N Cisco ...
This document describe how DST changes and how time changes are
implemented in DST. Daylight Saving Time (DST) is the practice of
setting the clocks forward 1 hour from standard time during the summer
months, and back again in the fall, in order to make b...