Thanks for your feedback.
Feedback?Contributed by Anuj Bhatia and Rohit Harsh, Cisco TAC Engineers
Prerequisites
Requirements
Cisco recommends that you have skills and knowledge of Webex Contact Center (WxCC) solutions.
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-answear, or redirect on no answer. When an agent is available to take a call or non-voice task, WxCC automatically picks the agent and delivers the call to the agent's phone. However, the 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 a 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, and the endpoint is able to respond back with a 180-ring message. However, there is no Off-hook event (200OK) received by the system. After configuring RONA time (default 18 seconds) system moves the agent into a nonresponsive state. This is the case, where the agent's phone rings, however, the agent never picks up the call.
- Immediate RONA: In this scenario, the system discovers an issue while presenting a call or task to the agent endpoint, as a result, the agent is immediately moved into a RONA state. This can be due to a system/agent endpoint problem, or agents entering the dialed number in the wrong Dialed Number/Extension Tabs.
For both of the conditions, there is a significant difference in 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, are described in the next section.
Condition 1: RONA After Agent Ring Event
In this condition, the agent's phone rings, but for some technical or non-technical reason, the agent is not able to answer the call. After the RONA timer expiration, the agent desktop gets a standard pop-up, that they have missed a call.
In these circumstances, the administrator must gather these details:
- Basic details of the call and information as highlighted in the table.
Details Data to Collect - Does the agent'sget 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 the agents at a particular site?
- Are Agent Directory Numbers (DN)/Extensions added recently?
- What percentage of calls experience these failures?
- Is it dependent on the area codes from a 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 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 how to create a basic RONA report.
WxCC RONA Report - For example, this report highlights, that the agent received the call and it rang the endpoint for the duration of 18 seconds (RONA timer), and then encountered a con-to-agent error, which implies, that the agent did not pick up the call.
Condition 2: Immediate RONA
In this case, the system moves the agent into the RONA state immediately, if it is not able to reach the 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, the 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, the data as per the table nd 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 ONA 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
- For general Call related issues, please refer to the article Webex Contact Center Data Collection for Technical Assistance, which highlights the important information that is required for Cisco support team to analyze and to isolate the issue efficiently.
