Dear All - I need calrification of creating CUCM PIM, let says i have CUCM cluster with 1 - PUB and 3 - SUB and two CVP and i have created Generic PG.
During installation of PG can i create 4 CUCM PIM which is pointing 1- PUB and 3 - SUB on both side of PG? For VRU we can have two PIM one point towards CVP - A and other Point towards CVP - B, i need clarity on CUCM PIM.
In most of the setup Side A PG points towards one CUCM node, other side of PG point towards another CUCM Node, Also if both PG lost connectivty with both CUCM Node which they pointing towards, entire CUCM PIM will be down even if we have more CUCM Node in the cluster.
Also if one of the PG lost connectivty with CUCM node, other side will be active and CTI Manage services in CUCM responsible to route the call to respective nodes where the phones got registered?
Can you please clarify whether i can have 4 PIM'S which pointing to 1 - PUB and 3 - SUB on both sides of PG, If not can you please explain logic behind that.
for CUCM, you only create 1 PIM only... and the you point one side to sub1 and the other to sub2...
CUCM, with all its subs is a single cluster.. so you can only have a single PIM active on it..
the reason you can only point to 2 subs and not more is that you can only have pga and pgb... so you dont have a third pg to point to a different sub
Sent from Cisco Technical Support Android App
You can configure Multiple PIM in the PG Box connecting towards the single CUCM Cluster. This is going to be a seperate peripheral from the UCCE perspective.
There is a sepearte section in the SRND for this Multiple PIM connections, It explains why a customer can go for Multiple PIM deployment. I am pasting the snippet here.
Multiple PIM Connections to a Single Unified CM Cluster
Although the Agent PG in this document is described as typically having only one PIM process that connects to the Unified CM cluster, the Agent PG can manage multiple PIM interfaces to the same Unified CM cluster, which can be used to create additional peripherals within Unified CCE for two purposes:
• Improving Failover Recovery for Customers with Large Numbers of CTI Route Points
• Scaling the Unified CCE PG Beyond 2,000 Agents per Server
Improving Failover Recovery for Customers with Large Numbers of CTI Route Points
When a Unified CCE PG fails-over, the PIM connection that was previously controlling the Unified CM
cluster is disconnected from its CTI Manager, and the duplex or redundant side of the PG will attempt
to connect it's PIM to the cluster using a different CTI Manager and Subscriber. This process requires
the new PIM connection to register for all of the devices (phones, CTI Route Points, CTI Ports, and so
forth) that are controlled by Unified CCE on the cluster. When the PIM makes these registration requests,
all of them must be confirmed by Unified CM before the PIM can go into an active state and process
To help recover more quickly, the Unified CCE PG can have a PIM created that is dedicated to the CTI
Route Points for the customer, thus allowing this PIM to register for these devices at a rate of
approximately five per second and allowing the PIM to activate and respond to calls hitting these CTI
Route points faster than if the PIM had to wait for all of the route points, then all the agent phones, and
all the CTI ports. This dedicated CTI Route Point PIM could become active several minutes sooner and
be able to respond to new inbound calls, directing them to queuing or treatment resources while waiting
for the Agent PIM with the phones and CTI Ports to complete the registration process and become active.
This does not provide any additional scaling or other benefits for the design; the only purpose is to allow
Unified CM to have the calls on the CTI Route Points serviced faster by this dedicated PIM. Use this
only with customers who have more than 250 Route Points, because anything less does not provide a
reasonable improvement in recovery time. Additionally,associate only the CTI Route Points that would
be serviced by Unified CCE with this PIM, and provide it with its own dedicated CTI-Enabled JTAPI or
PGUser specific to the CTI Route Point PIM.
Let me know if any more questions arises from this.
Hope this helps
Thanks Senthil, In that Case can i have same CUCM Routing Client for all CUCM Node or I need to use different RC.
Couldn't get your question.
Are you trying to ask whether you can use same node ip address for 2nd PIM configuration ? You can use but you need give different PG user. There should not be any problem in PIM getting activated.
Basically by doing this, you will end up by having 2 PIMs, 2 JGW Process, you will create 2 application users(PGUser)
Just a couple of questions from side about this:
- Can we have 2 JGW processes on the same server? I always thought only 1 can be added
- if we configure the above with multiple PIMs, do we need to have each user monitoring different phones, or can it monitor the same phones?
Yes there can be 2 JGW Process on the Same Server. The JGW process wont be added by us. It would be automatically started by the PG.
The JGW process deals with the messages sent from CM PIM and CTI Manager in CallManger. So when you add another CM PIM there will be seperate JGW will be started by PG.
Basically this kind of approach can be done when you have more than 2500 CTIRoutepoints, So one PGUser will be controlling the CTI RoutePoints and another will be controlling the Phones & CTI Ports.
Both the PIM's can monitor even if you map the phones to both App Users. But it is not a best practice. You should have 1 dedicated for CTI Route Points
Thanks for clarification...
so, what would prevent me from adding the same user on both PIMs to monitor same phone? i would then be able to point PIM2 to subscribers 3 & 4?
Sent from Cisco Technical Support Android App
I want to add few more things with Senthil response.
Having two peripherals will have impact on routing and reporting. Additionally, agent teams and supervisors cannot cross peripherals, so careful consideration must be given to which agent groups are allocated to each PIM and Peripheral in such a design.