UCCE with multiple agentpg

[pavelekshin]

Hi there!

I going through SRND , and missed one moment about passing CV in deployment with two agent pg and two Finesse clusters. Its should work out of the box? Or agent in different pg is almost isolated? How to perform transfer between them, via CVP/CTI RP/ both? Which way better?
Could someone provide clear view of this aspect?

[Slavik Bialik]

Hi, what are you trying to accomplish? Do you have 2 different CUCM clusters and you want to treat them as one contact center of agents? If that's the case, should be possible, just create another peripheral under your PG in the PG Explorer (in Configuration Manager) and then in the PG Setup just add another PIM that will "talk" to this new peripheral you created and configure it with the 2nd CUCM IP and authentication details.

Never done it, never had do, but I think it should work.

Just do not forget to add the newly created routing client to the Agent Targeting Rule you already have.

[pavelekshin]

Hi,
No, enough single CUCM but imagine that you need to seat down 4000 agents.
According SRND we should add second AgentPg for this task and connect extra Finesse cluster.

One extra interesting thing about SRND, if I understood correctly the problem is on AgentPG PIM  which doesn't allow more than 2000 users.
That's means that we can connect as many pairs of Finesse, as we need to single AgentPg, if we doesn't exit 2000 user ?

[Slavik Bialik]

Ah OK, now I understand what it is it about.

You don't need another separate agent PG, you just need to install your UCCE with 2 sides, and it is not only redundancy it is also for increasing the capacity.

Look at the 4000 Agents deployment:

As you can see, you have 4 different PG servers here. Each PG supports 1000 agents.

You create on each PG the same PG instance with the same configurations, only the difference is that two of them configured as side A and the others as side B. If you set all of the 4 of them as PG 1 (for example) they'll operate as one and not as separate PG instances. They're using the private NIC in order to pass all the relevant data between them and sync the information. 

[pavelekshin]

Slavik, I'm appreciated for your comment, but you on wrong way, and I asked about another...
Look at little more closely in docs where you find this pics, and you will see what UCCE is active / standby model..
Also PG communicated only with their pair, I mean SideA/SideB, and we cannot aggregate 2 pair PG in one.

[Chris Deren]

Just a clarification on UCCE deployment, it ALWAYS needs to be deployed with SideA and B in production, simplex solution is not supported outside of a lab.  So, this has no impact on capacity as all capacity numbers assume side A and B is in place.  

When looking at agent capacity per UCCE deployment you need to consider not only what UCCE supports, but how many CTI connections are supported on your CUCM cluster, thus how many agent phones per cluster/node, which is documented in SRND.

[Chris Deren]

To answer your original question, transfers between queues initiated from internal phones should be done via CTI Route points, it does not matter which PG the CTI RP is registered to as the script it points to via DN --> CT will determine where the call goes. If you are using PQs then they are not tied to peripheral, but traditional skill group are, so if you want agents across both PGs to span "common" skill group, you'd need to use either PQ (recommended) or Enterprise Skill Group.

[geoff]

Transfers between agents do not involve CTI Route points these days - that is old school. CVP is the glue that joins all Agent PGs together.  Transfers from agent to agent through Dialed Numbers on UCM Routing Clients invoke ICM scripts that span PGs. Use PQs, as Chris said, and there are no issues and no PG dependencies. Skill Groups and Enterprise Skill Groups are a thing of the past. As long as your Agent Targeting Rules are correct, you have a universal routing platform. There are no barriers here and if you are seeing some, you are doing it incorrectly. 

Regards,

Geoff

[pavelekshin]

Thanks, will check.

Do you have any diagram for understanding CV passing between different CTI server?

[geoff]

If you understand how a Translation Route works, you can understand how an "implicit" Translation Route works, which is what happens with CVP.

Entity A wants to send a call to Entity B with call data that is out of band. So it asks the Router to help.

The Router tells Entity B to expect a call soon on a certain number, and when it arrives, here is the call data to attach to that call. The Router tells Entity A to transfer to that number within a certain number of seconds. Entity A transfers to the number; Entity B sees a call arrive on a certain number and says: "ah ha! I was expecting a call here. I am going to stick all this call data the Router gave me on this call and tell the Router the translation route was successful". 

That is the essence of a Trans Route. A correlation ID builds a sort of Trans Route for CVP. PGs are tied together through CVP. The Router is in charge and always knows the call context because all PGs report to it.

You just have to think about it for a while. 

Regards,

Geoff

[pavelekshin]

Hi Geoff.

I finally going to do this.

Is where a doc which clearly describe Translation Route mechanism for CVP?
As far as I remember there are features in the creation Service/TR targeted to destination peripheral. Like for dialer and IVR campaign implementation, but it's because MR_PG type2.
I have 1 vru(cvp) pg and two agent pg.
all of them aggregated to one type10 NVRU, agent pg has same label and targeted to one UCM. And passing variable between two agent pg work out of box via CTI RP.

For transfer via CVP I should created service/tr on VRU pg ? It's applicable on one NVRU, or we should split it on different, cause call will be already controlled by CVP.
CVP should be front while transfer a call as routing client?