Introduction
This document describes in detail different kinds of route-on-no-answer (RONA) issue faced by webex contact center (WxCC) agents and how administrators can help the cisco support team.
Contributed by Anuj Bhatia & Rohit Harsh , Cisco Engineers.
Prerequisites
Requirements
Cisco recommends that you have skills and knowledge of Webex Contact Center (WxCC) solution.
Components Used
This document is not restricted to specific software and hardware versions.
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, ensure that you understand the potential impact of any command.
Overview
RONA which stands for Route on no answer is also defined as re-route-on-no-answer, or redirect on no answer. When an agent is available to take the call or non voice task, WxCC automatically picks the agent and delivers the call to agents phone. However, agent may not be able to pick up the call, due to system issues or they are not at their desk or just got busy on another task which results in a RONA situation. There is a configurable timeout for RONA which can be defined as the timer during which the agent phone rings. Once this timer expires, the call is pulled back from the agent desktop and parked in the queue again to be assigned to the next available agent. The state of the agent is set to RONA once the timer is expired and the call is not answered.
Mainly agents can end up in RONA state due to these two common conditions (not limited):
- RONA After Ring Event: In this case the call via SIP protocol is able to reach the endpoint, endpoint is able to respond back with 180 ring message, however there is no Off hook event (200 OK) received by the system. After configured RONA time (deafult 18 seconds) system moves the agent into a non responsive state. This is the case where the agent phone rings, however the agent never picks the call.
For both the conditions, there is a significant difference on how the agent desktop user interface reflects the RONA state. Details on these conditions and how to effectively gather the information to troubleshoot the issue deeper is described in the next section
Condition 1: RONA After Agent Ring Event
In this condition, agent phone rings but for some technical or non-technical reason agent is not able to answer the call. After the RONA timer expiration, agent desktop gets a standard pop up that they have missed a call.
In this circumstances administrator must gather these details
- Basic details of the call and information as highlighted in the table
Details |
Data to Collect |
- Does the agent phone ring or gets an error on the Agent Desktop?
- Is the agent unable to answer the call received on the phone?
- Are these failures specific to agents at a particular site?
- Are Agent Directory Numbers (DN) / Extensions added recently?
- What percentage of calls experience these failures?
- Is it dependent on area codes from specific location/s?
- Can the issue be recreated on demand?
|
- ANI or Session ID of the failure call
- Exact time stamp of the call failure
- Agent Information
- Screen shot of any error (ensure that all details are captured on the screen)
- Download Error Report section on Agent Desktop (Ctrl+Shift+2)
|
- Alternatively, an analyzer report based on CARS which highlights the various events for this call can also be generated. For reference the highlighted video explains step by step on how to create a basic RONA report.
- For example this reports highlights that the agent received the call and it rang the endpoint for the duration of 18 seconds (RONA timer) and then encountered con-to-agent error which implies that the agent did not pick up the call
Condition 2: Immediate RONA
In this case, system moves the agent into RONA state immediately if its not able to reach agent endpoint due to various conditions and pops up an error message on the agent desktop. If this is the situation faced by the agents, administrator should gather these details
- Request the agent to click on error details and copy the tracking ID presented to them on the error screen.
- As in condition 1, data as per the table and analyzer report based on CARS can also be generated by following the same video.
- This example highlights pstn agent 1 with RONA issues where we see four connect events for the agent, but if we observe closely all these events have a duration of less that 500 ms, which indicates that the system was not able to deliver the call and the phone never rang for configured RONA timer. Further peek show cases, the call was sent back to the original queue so that it can be answered by the next available agent.
Resources & References