Call is not connecting to agent after PG Failover

[Ayodeji Okanlawon]

Gents,

I have opened or tired to open TAC case over this and I am not getting a good response on this so far, so I am throwing it out here hopefully you guys can help

We are testing new UCCE deployment and in one of the scenarios experienced the issue below.

UCCE:11.0.1

CVP 11.5(1) ES=1 Build=349

When call is queued and PG services on side A are recycled, once side B becomes active and agent is ready, call is not connected to the agent. When looking at router logs, no agent label is returned to CVP for the agent, checking CTIsvr logs showed that agent was in ready state. New calls are routed to agent but existing call remains queued and then disconnects after a while. Call survivability doesn't kick in either.

Is this expected behavior and how can we get call survivability to kick in in this scenario that calls are not abandoned in the event of the failure of a call server

[Chintan Gajjar]

Hi Deji, Which PG did you bounce? Agent or CVP?

[burkr]

with us, we are restarting the CVP PG

difference is we are running on CCE 11.5 (PCCE deployment) and CVP 11.5

[Ayodeji Okanlawon]

Burkr,

If you are using a generic PG and your agent PIM runs on the same PG that your CVP VRU PIM is on, then this behavior is working as expected. This is because when you restart the PG, UCCE router will delete all dialogs for the PG when its restarted, so even though your agent PG fail over to the active side, the call on the CVP PG is no longer present in router's memory. However if the agent PG is different from the CVP PG, and you restart the agent PG then the call will be routed to an available agent once the fail over is complete

[burkr]

We don't have a generic PG.

- PG1 (PIM1) holds all the Agents

- PG2 (PIM1, PIM2) are connected to the CVP Servers

In case, PG2 fails over to the other side, we are affected by this issue. Also, in case a PIM of the VRU PG  (PIM1 or PIM2) get killed, the calls are dying on the corresponding CVP as soon as the "Run External Script" has finished.

I found a pretty old topic on this:
https://supportforums.cisco.com/discussion/11614491/cvp-vru-pim-failover 

From my point of view, it makes no sense, that the router deletes all the active Calls on a Peripheral in case the PG switchs to the other side - therefore, redundancy somehow should be designed ;-)

Unfortunatly, it looks like "works as designed" (or in other words: worse as designed).

cheers

roland

[Ayodeji Okanlawon]

Yes this is correct in your case. PG2 is the VRU PG and was active when failure occurred. Once the router looses connection to the PG, it will delete the dialog on that PG.

Have a look at your logs and you will see the logs showing something similar to my logs below:

"When I restarted PGA, router lost connection to VRU 5002 and deleted all call on this routing client.

09:16:29:813 ra-rtr Trace: Received dialog fail for Routing Client 5002 (CVP2_PG01_RC), Physical Controller 5000 (PG1_US)

09:16:29:813 ra-rtr Trace: (83 84 10274 : 0 0) DialogFail: Reason=8 CallState=2.

09:16:29:813 ra-rtr Trace: (83 84 10274 : 0 0) Dialog state(2) handling dialog fail from (1)

09:16:29:813 ra-rtr Trace: (83 84 10274 : 0 0) Handling dialogFail from (1) reason(8)

09:16:29:813 ra-rtr Trace: (83 84 10274 : 0 0) We can not continue - VRU service inactivated.

09:16:29:813 ra-rtr Trace: (83 84 10274 : 0 0) Canceling queuing for CID=(152153,812)

09:16:29:813 ra-rtr Trace: (83 84 10274 : 0 0) Unqueuing Call CID=(152153,812) for PQStep UCCE_TEST.1, pos=1

09:16:29:813 ra-rtr Trace: (83 84 10274 : 0 0) Dialog sending VRUQueueEvent to VRU (4)

09:16:29:813 ra-rtr Trace: (83 84 10274 : 0 0) Deleting Dialog.