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.
Check the menu prompt option in script and make sure that interruptible is selected to Yes under general tab.
I'm aware of this, but don't you think that if did this, my prompt will not be played to the end, so my caller will hear half of the prompt !?
That's true - but generally that's what you would want with a queue prompt.
Barge In - Determines whether the caller can interrupt the prompt -you can set this to 'No' to prevent the caller pressing a key and skipping the prompt
Interruptible - Determines whether the system can interrupt the prompt -e.g. to do the transfer to the agent
All steps that are hit when the contact is in-queue (i.e. from when the 'select' step is hit) should be interruptible, otherwise the system must wait for the prompt to be played out before it can transfer the call.
If you have a prompt that must be played out in full (for example a recording warning, or regulatory announcement) then this should be played before the select step, and only interruptible prompts should be played after the select step.
Please rate helpful posts...
Thanks guys for your assistance, really appreciate your prompt replys.
Before i try your suggestions (make prompts interruptable in the queue), i have reviewed my script and found that i have 2 delay steps (each of 1 sec) that are configured as interruptable, and i already got my prompts as un-interruptable, so i decieded to make the delay also un-interruptable. (these delays are used to give a gap between prompts)
It has been 4 days for now, and the issue didn't surface again... as soon as the problem hit again, i will try your suggestion and update the post.
Your terminology is confused a litte.
Each step has a property 'Interruptible'. It can be set to 'Yes' or 'No'.
All queue steps should have it set to 'Yes', and would then be interruptible.
Other steps may be set to 'No' if you like, and would then be considered un-interruptible.
If you have set your delay and prompt steps to un-interruptible, then you will still have the problem. If a call comes to the queue, and an agent is available immediately, the steps will not execute, so you won't notice the problem until the queues build up at a busy time.
I know i have been stobborn on this but I have done a some research and didn't find yet a document that recommends to make prompts interruptable in queue. I was reading the "Getting Started with Scripts" guide from Cisco
check page 150 - "About Script Interruption". I couldn't find a clear direct statement that talks about my issue but i found the following:
"If an interrupting event happens when the script is not currently interruptible, the script is automatically interrupted whenever it becomes interruptible again."
On the other hand, my issue was surfucing when agents are all available and no one in queue!!! Anyway, I will be preparing an alternative script that flows as per your recommendation, just in case.
Also if you have more documents you would refere to me, i would appritiate that.
i contacted TAS with issue, that you describe here. I should to be ashamed.. :-)