cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
854
Views
0
Helpful
6
Replies

Called placed back in queue by an agent can never be answered

Bill Brown
Level 1
Level 1

So upgraded from 10.6  to 12.5.1 UCCX.  And the following scenario worked before.

 

Scenario: If we have an agent get a call from a queue and that call needs to go to another department.  The agent would blind transfer back to another route point that forwards to a trigger.

That triggered application places the caller in another queue.

 

Problem:  the caller never goes to available agents in the queue.  And caller sets in queue with other lower priority calls being answered.

 

Anyone ran into this and a work around?

6 Replies 6

TomMar1
Level 3
Level 3

Had a similar issue and what TAC came back with was "Translation patterns mapped to UCCX triggers is not supported configuration."

 

Are they actually dialing a trigger or a translation pattern that is mapped to a trigger?

 

Try to delete the translation pattern from UCM and build it via UCCX as a trigger and see if calls continue to be stuck in queue.

Well our translation patterns are mapped to route points, which are forwarded to triggers.  Then if we need to route the translation pattern to a different script we can just modify it's corresponding route point to point to the trigger.  Then the script always sees that route point as the original called number, so we can keep track of what line it came on.  Since I'm not using the translation pattern in the scenario mentioned, I don't think it will help.  The redirects for other departments are independent route points forwarded to triggers.  The new scripts still see the same original called number, but based on the last forwarding route point; place the call in the new queue.  Which is when the caller can't be answered by another agent.  Reports of reserved states by some agents during this issue, makes me think the dequeue of the call is not really happening.  I've added a dequeue all in the top of the new scripts be routed to, but that did not seem to matter.  Thank you for taking your time to try and offer a solution.

I have read this three times now and ... wow, I would not recommend that setup. A Translation Pattern _before_ CCX to get from the PSTN DNIS to the CXX Trigger DN is fine. All of those Route Points and call forwarding complexity should be removed though. If you need multiple TNs or DNs to land on the same CCX Application, just add multiple Triggers to it. If you need to move a TN/DN from one Application to another, just update the Trigger to point at another Application.

Also, I recommend using Get Trigger Info to retrieve the Trigger Name - which is the DN - instead of relying on the called number; the former will always be accurate and reliable while the latter is susceptible to corner case scenarios not matching.

"Reports of reserved states by some agents during this issue"

This is a telltale sign of a CTI-related CSS problem, likely caused/exacerbated by the Route Points & CFA you're doing. The "Calling Search Space for Redirect" setting on the CCX Trigger influences which CSS is used when redirecting from the Trigger (a CUCM Route Point & DN) to the Call Control Group (a CTI Port & DN). Cisco never implemented support for all three options; the default "Route Point Address Search Space" is what you should be using. Normally that would be the CSS defined on the Trigger but with extra RPs and CFA in the middle it could be selecting a different CSS than you think it is.

 

I'm going to make one of these route points into a trigger on the application and see if that makes a difference.  The search spaces were correct, but this will simplify getting to the application.  Although it was getting to the app and you heard hold music when you can't be answered.  However, the scripts that do redirect callers work as expected.  It is worth a shot and thanks for the advice.

Jonathan Schulenberg
Hall of Fame
Hall of Fame

“Had a similar issue and what TAC came back with was ‘Translation patterns mapped to UCCX triggers is not supported configuration.’”

This requirement applies to CCX Applications transferring to another Application. It _shouldn’t_ apply to agent transfers, but the advice is still worth heeding since a Translation pattern will break continuity of the contact session (ie it will look like a new/separate call); I build Finesse phone books so the agent can just click-to-dial. An Application transfer of to another, on the other hand, results in a memory leak if the call is transferred to a destination that is not a Trigger DN and immediately comes back to CCX. Fun times.

Well, I created phone book entries for the route points going back into scripts that queue these calls for other departments, with a note to use direct transfer.  The call keeps all its identifiers and call variables set.  All the data looks the same, except the call goes into the new queue and can't seem to go to another agent.  Testing yesterday; I could send the caller out to other departments by their 8XX number.  Of course this does make the caller become new to our system, not desirable.  I have a TAC ticket open and they are asking for logs of it being reproduced.   A call center that can only queue a call once after an agent has received it; is definitely a bug and you should not have accepted "you can't do it that way".  When before 11.6, it was working this way.  I will definitely update this thread if we come up with a fix or work around.  Thank you for taking the time to offer advise on it.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: