[cisco-voip] UCCX Place Call, Get Digit String and Play Prompt
Ray Maslanka
ray.maslanka at gmail.com
Wed Aug 9 10:42:50 EDT 2017
Gentlemen,
Much like the BaseLineAdvQueueing.aef script in the script repository, I
have scripts in production that allow callers the ability to leave a
message if they choose and receive a call back. UCCX records the callers
message, terminates the call, calls a trigger, waits for an agent to answer
and prompts them to press a digit to confirm they want to hear the recorded
message. The agent is then free to do what they want with that information.
It seems what really happens after the message is recorded and the call is
made to the trigger to deliver it to an agent is that the script starts
playing the prompt "Press a digit to hear a message", regardless of whether
an agent has actually answered. That prompt plays and waits a given amount
of seconds for the agent's digit input, and then loops, courtesy of the
timeout function related to the initial digit timer. If no agents are
available, the script will continue to play the prompt and wait for digits
while listening to hold music, delay prompts or whatever may be presented
while waiting for an agent. There is no real harm done here though.
The issue is when an agent does answer, depending on when they answer
during the looping process, they may hear "Press a digit to hear a message"
or "to hear a message" or silence as long as the initial timeout value in
the Get Digit String step before "Press a digit to hear a message". In
higher volume environments, that timer and the possible related silence
after answering may be unacceptable. Three seconds of nothing may be
enough to trigger an agent to assume it is an abandoned call and hang up.
I am hoping someone has a technique to have UCCX only start playing the
"Press a digit to hear a message" when the agent actually answers the call
that UCCX made into their queue. If what I am experiencing is expected,
confirming that would be great too and I'll try to find an acceptable timer
or different recordings, etc. If you believe what I am experiencing is not
correct behavior, any suggestions on what is wrong with that sample would
be appreciated.
Running into this on fully patched UCCX 11, CUCM 11 and 8800 series
endpoints.
Thanks in advance for any feedback.
Ray Maslanka
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20170809/6b66a105/attachment.html>
More information about the cisco-voip
mailing list