cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1570
Views
8
Helpful
6
Replies

UCCX 9.0 Agent Ready State Duration being reset by non-ACD line

Michael Marvin
Level 1
Level 1

Hi,

Our environment is CUCM 8.6.2 with UCCX 9.0.2 running on UCS blades. Agents have recently started complaining that calls ringing on their non-ACD line have been resetting their Ready duration counter to zero for all Ready agents in the group, every time that line rings. Configuration is as follows:

  • Cisco 7942G phones
  • Each agent has a non-ACD line on the top button and IPCC ACD extension on bottom button
  • Top button non-ACD extensions are members of a line group which gets triggered by a hunt pilot/hunt list. The line group is configured in "Broadcast" mode so all extensions in the group ring simultaneously. This is used for a specific group of callers who do not need treatment by the UCCX queues.
  • Agents are in Ready state. Call comes into the line group and rings the top (non-ACD) line of all phones. As soon as the phones start ringing, all agents go temporarily into "Not Ready" state with reason code 32761 (Non-ICD call). Agent who answers the call stays in "Not Ready" for the duration of the call, all other agents go immediately automatically back to "Ready", but their State Duration is reset to zero seconds and begins counting. If no one answers the call, after the phones stop ringing all agents go automatically back to "Ready" and like above, State Duration is reset to zero seconds and begins counting.
  • We have several teams configured this way, and it appears this behavior is happening with all of them. But they are different ACD teams with different queues, and different line groups/hunt lists/hunt pilots on the top buttons.

From what I've read, UCCX is only supposed to monitor the extension selected as "IPPC Extension" in the End User properties in UCM. But in my case it is clearly being affected but the non-ACD line. Anyone have any thoughts on this? My users are saying this behavior just started recently, that it was functioning correctly before.

This behavior is problematic for the teams because we use "Longest Available" as the Resource Selection Criteria. So every time a non-ACD call comes in it resets the idle counter for thr group  and the calls are not being distributed the way the teams would like.

Thanks in advance for any insight.

-Mike

6 Replies 6

Deepak Rawat
Cisco Employee
Cisco Employee

Mike,

I am afraid that your understanding about UCCX only monitoring the ACD line is incorrect. Please find the below information from UCCX Release Notes that clearly states UCCX by default monitor the first four lines of an agents IP Phone:

Agent extensions cannot be added to hunt lists or hunt groups. If an agent has only one line, then the agent phone cannot be part of a hunt list or hunt group. In the case of multiple lines, none of the lines on the first four lines monitored by the UCCX must be part of the hunt group.

Hi Deepak,

Thanks for taking the time to answer, I appreciate it. I think I used the wrong word "monitor"... I understand that UCCX monitors the first four lines on the phone, but I have read that Agent State is only supposed to be affected by the IPCC extension. Why would a ringing non-ACD extension change the agent state? It's not even that they're on the call, the state changes to Not Ready as soon as that top button starts ringing.

I found this info in the UCCX 9.0 Design Guide:

Unified CCX provides multiple line support using the 6900/7900/8900/9900 series phones as agent devices.
The Join Across Line (JAL) and Direct Transfer Across Line (DTAL) operations are supported on the
7900/8900/9900 series phones. Up to four lines are monitored by Unified CCX, including one ACD line and
three non-ACD lines (but only the ACD line can be controlled from the agent desktop). The agent state depends
only on the ACD line on the agent's device.


Unified CCX allows more than four lines to be configured on the agent device but monitors only the first four
lines, provided these lines are not shared. The ACD line should be among the first four lines. The Agent can
perform JAL and DTAL operations for the ACD call only by using the monitored lines.


The Unified CCX Engine receives CTI events on the first four configured lines of a monitored device, but it
filters events that occur on non-ACD lines.


Cisco Agent Desktop does not show activities that occur on non-ACD lines with the exception of JAL calls
that are on non-ACD lines.


Historical reports display call activity on monitored lines. Agent state is determined based on the line involved
and original nature of the call.

Reviving an old thread here, but it's the only one I've found describing a similar situation I'm currently experiencing.

My environment/scenario:

CUCM: 10.5.2.13900-12

UCCX: 10.6.1.11002-15

CCX agent phones: 7945

Each agent has 2 lines; IPCC Extension is line 1, while a non-ACD "personal" line is line 2. Some agents are members of a broadcast hunt group, which rings on the non-ACD line. When the hunt group is ringing line 2, the CCX agents that are part of the hunt group have their states changed to Not Ready, code 32761 in Finesse. When the hunt group stops ringing, the CCX agents go Ready again.

Intermittent worse case, when the hunt group is ringing line 2, the CCX agents that are part of the hunt group have their states changed to Reserved in Finesse. Reserved state remains even after the hunt group is no longer ringing line 2. Agents are then unable to change their state in Finesse. I haven't personally seen this, but my Agents are reporting it, and CUIC reports show Agents in Reserved state for 25+ minutes after a call to the hunt group rings their non-ACD extension (date/time of hunt group call corresponds to the second with beginning timestamp of the Reserved state).

UCCX 10.6 Design Guide:

“The agent's ACD line must be in button positions 1 - 4. Any calls on the observed lines are reported in the historical reports. However, Finesse blocks any events that are sent by the CTI server as a result of call activity on an agent’s non-primary/non-ACD line (lines other than the one the agent is logged into). These events are not published to Finesse clients. No information about calls that are handled on non-primary/non ACD line appears on the Finesse desktop.

Michael, did you ever get a resolution?

TIA!

Scott

Scott, I can understand your point related to Non ACD line making an impact on the ACD line when it should ideally not. However what you are not focusing on the fact is that at no point the first four lines on an agent phone should be a part of hunt list or hunt group and since you are doing this, there can be unexpected behavior(s) like the one you are observing there. Refer below note that is there in the Release Notes:

Agent extensions cannot be added to hunt lists or hunt groups. If an agent has only one line, then the agent phone cannot be part of a hunt list or hunt group. In the case of multiple lines, none of the lines on the first four lines monitored by the UCCX must be part of the hunt group.

Link to Release Notes:

http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/crs/express_10_6/release/docs/UCCX_BK_UC733F42_00_uccx-release-notes-106/UCCX_BK_UC733F42_00_uccc-release-notes-106_chapter_00.html

Hence, the setup you are running there is unsupported in the first place and with this the kind of issues you are experiencing can happen. If you have an agent there for whom none of the first four lines are part of the hunt group and still he/she is facing this issue, then it is a valid case discussion scenario else it is not. Even if you will go to TAC, this is the first thing they will tell you i.e., to correct your configuration

Regards

Deepak

Hi Deepak,

The answer was right in front of me...thanks for pointing it out.  I was sure I had reviewed the release notes, but clearly didn't do a good job of it.

Thanks for the help!

Scott

No issues Scott, glad that I was able to help. Please remember to rate helpful posts so that they can stay on top and help others with the same issue in Community.

Regards

Deepak