It may be caused for one of this reasons:
- CSCeb36950 ( registered customers only) − The Select Resource step is set to Connect, No and the Failed Branch of the Connect Step has a Goto step that jumps back into the Select Resource Step
- CSCdx46617 ( registered customers only) − An ICD Route point is the destination of a redirect from another CRS script. The script should have a Delay step before the Accept step that gives the transferring party time to complete their transfer before the CRS script answers the call
- Misconfiguration:An ICD extension assigned to multiple devices,Call waiting enabled on an ICD line or Two lines on an agents phone that have the same extension but exist in different partitions
Wish this be helpfull
Thanks for the links. Upon further investigation I believe I may have an issue with my script.
When a customer is queued they have the option to press 3 to leave a voice message. I then use a goto step which takes a recording and emails it to our representatives.
What I am not doing is dequeuing the call before they leave a voice message. So it almost seems like the caller is off leaving a message but the call is still technically in the queue being assinged to agents who cannot answer the call.
Does this sound like it might be the issue? If so, where should I dequeue the caller? Before the goto leave message step or after?
I faced this issue before
I was redirecting in my script to a voice mail number to listen to greeting
and when successful then Dequeue
But in your case you'll go to the voice mail then your the call won't see the Dequeue
So try using redirect with Dequeue,it will be valuable
wish this be helpful
The problem with reservation an agent is that the call can not route to this agent. The problem is that your CTI port calling search space is incorrect assigned or not contain the agent phone partition.
Anybody got that resolved? i'm facing the same issue. Call arrive, agent get reserved, phone doesn't ring... the caller will wait around 2 minutes and hang up, agent get back to ready, call in considered abandoned, and everything is back to normal. this happens twice a day!!
CTI ports CSS, Agent shared line, Select Resource step, all check and configured they should.
I found in some discussions that i have to set my prompts as "Interruptable"... but this will not play my prompt to the end...
First, I recomend you to recheck the css of CTI port. It should be incorrect with calling search space.
Secondly, agent must use the first DN line.
Exactly, i already checked the CTI calling search space. My agents also are using the first and only extension.
Thinking about it again, the CSS doesn't relate to my case, cause I receive more than 1,000 call daily and just very few are going to this issue. Add to that, the problem appears at different agent each time!!
Another possible reason is:
when the call come in, all agents are busy. The call will be placed on the queue. Then caller hang up. There is no signal to UCCX to notice that call is not hanged up now and not there in queue.
Then when agent become available; because UCCX doesn't know the call are hanged up before and UCCX will treat it as a normail queueing call, UCCX will reserve an agent for this call. And of course, agent will be in reserved state in some timeout interval because no call there to be routed in.
I don't know in your system if you use a voice gateway with R2 or ISDN connection? Please show me how the call flow through all components.
If an agent is in queue and he hangs up, then the call will considered as abandoned. My UCCX is aware of this, and it can detect this. I'm using E1 PRI on my voice gateway, to call manager to UCCX.
I don't believe this is my case at all.
Did you ever get solution for this problem i am facing exact similar issue.
7821 SIP phones.
TAC is involved in it but they are struggling to provide root cause of this form past 1.5 months
Please let me know if you got fix / workaround for this .
The issue got resolved only when the CUCM was upgraded to 10.5 from 9.0.
Post upgrade we never observed the issue, unfortunately TAC has no clue about UCCX & CUCM software incompatibility which could have caused the issue.