Currently we have CallManager 3.0.11, and Unity 188.8.131.52 with TSP 184.108.40.206. The user scenario we have is a primary user and an assistant. The call routing is set up to ring three times at the primary persons phone and then forward to an extension on the assistants desk. When the call forwards out we want the ability to respond to the call or transfer directly to voicemail. The current process that we are using is to press TRANSFER, MESSAGES, # then the 4 digit extension, # 2, TRANSFER. The issue that we are experiencing is that sometimes the calls transfer and other times the caller gets lost into voicemail. There is not a real determination of what causes the process to fail, although we have noticed to a certain degree the speed of input has the greatest impact. We seem to have 4 users that continuously are unable to successfully complete the process. We are looking for any adjustments that could be done to simplfy this process or could account for the random functionality of the process. It's also been suggested that the 2.5 second interdigit timeout is not long enough for these users. Can this timeout be increased with a registry edit ?<br><br><br>
The transfer sequence that is posted is absolutely correct IF AND ONLY IF, the line appearance used to intiate the transfer to voice mail corrsponds to a Unity subscriber. So, if I use extension 100 to answer this call and transfer the caller to Unity, then 100 is a Unity subscriber DTMF ID. If the line appearance use to do the transfer is not associated with a Unity subscriber DTMF ID, then you're going to want to leave that first "#" out of there. Depending upon how caller input options are set, dialing an unnecessary "#" could get the call "lost" so to speak.
When the caller gets lost in voice mail in these conditions, what happens? What to they hear?
If I am thinking about your question correctly, the timing to wait for extra digits should be configured on a call handler to call handler basis, under Caller Input "Ms to wait for extra digits".
actually, my guess is this has to do with the speed of the input between the # and the 2. This is not 2.5 seconds and it's no configureable on the conversation. It's set to about 250 ms I believe by default. This is the "double key press" time out. If they come slower than that we treat them as two seperate key presses, not one event (i.e. skip transfer in this case).
Yes, this is configurable... download the registry setting tool off of AnswerMonkey 2.x page and it'll be one of the options in there (refered to as "double key press time"). I believe it does require a restart of Unity before the updated delay time here takes effect. Try that and see if users have better luck.
If not, it may be along the lines of what Steve is thinking here.
IntroductionCUCM Routing RulesDial String implementation PolicyCUCM Routing LogicSIP URI Call Routing Analysis+++ Case Study: 1 ++++++ Case Study: 2 +++Conclusion
Over the last few months, I have had the privilege of working on SI...
Are you getting this error “Installer User Interface Mode Not Supported. The installer cannot run in this UI mode. To specify the interface mode, use the -i command-line option, followed by the UI mode identifier. The value UI mode identifiers...