agent set auto answer but few calls RONAed

[kavle]

Hi All,

we got some reports that , few calls are RONAed on a specific PQ and these agents are set on auto answer ADS on their profile , however few calls are RONAed . 

I pulled the DB records for reason code 32767 and event 3. I see agents who have auto answer on their ADS.

any thoughts what could have been done to show the RONA in reports

[bill.king1]

Are you looking to report on why they RONAed or when they RONAed? It is likely that there was an issue delivering the call to the agent's device for instance.

[kavle]

yes Bill , I want to understand why the call was RONAed when the agent is set to auto answer.

[bill.king1]

As a start you can look at the Requery Status to see why UCCE thinks it couldn't make it there (busy, no answer, etc.).

[kavle]

Hi Bill , I see no answer as reason code from the DB records .

[david.macias]

Are these agents working remote? The most likely reason for something like this would be that ICM tried to send the call down, but it never got the right ack back from Finesse and thus considered it a RONA. This could happen when there's congestion/network issues at the agent end. Again, this is the most likely scenario, you could enable agent state trace on any particularly troublesome agent to get further details.

david

[kavle]

yes , these agents are remote . and I agree with your statement about ring back.

I have the ANI , DN , routercall key and daykey info on RONAed call  . so I should be checking in the CVP logs or router calls to see the ring back ??

[kavle]

after I checked further , for the RONA calls( on the auto answer agents ) I see the Jabber extension as NULL during the RONA occurred and I could see the extension for the next agent who took that call in the DB records, looks to be at that time the jabber extension was out of service caused the call to RONA .

this RONA report is like less than 3% of the the over call count of the day.

[kavle]

I see the below error in the RTR logs 

DEVICE_TARGET_ABORT_IND message received from Peripheral for that callkey .

[bill.king1]

@kavle , did you ever find the root cause for this?

[kavle]

it was the network glitch on the user client is what we saw many samples . its kind of false finesse state and call routed to that agent where actually agent was not in ready state . its kind of communication issue with pim and finesse server about the agent state

[bill.king1]

Was the agent logged out though? In other words, agent is not ready and logged in, they had network glitch, the call somehow got routed to the agent. What was the tip off that there was an issue (i.e. the agent was logged out and back in and set to ready and you see a certain code). Or you saw something in the pim or jgw log specifically?

[mbieyasid]

What the auto answer do you used? Using cucm or icm

Becuase i get the same issue, on the script used target requery and auto answer on the cucm device.