I'm not sure where I'm going wrong, but I'm obviously overlooking something.
I have a RONA ICM script scheduled and associated to the DN 7505. This DN is setup as a CTI Route Point in CM, associated to the PG user account and the IVR JTAPI user account. I created 7505 as a Trigger for a Post-Translation routed application on the IVR. I can dial 7505 and the script works. I have created a DN in ICM and it's selected in the Agent Desktop Settings to use for the RONA. The RONA seconds are set to 5 seconds. I set the ring no answer duration on the agent's hard phone to 20 just to be sure that wasn't the problem.
I've played with changing the Routing Client of the DN, but it doesn't seem to matter. The call goes straight into the agent's voicemail rather than pulling the call back and sending it to 7505 no matter what I try.
if so, remove the trigger 7505 and setup a trigger that is unique. (not used in the dialPlan anywhere else)
associate the trigger with the jtapi user.
also, 7505 RP needs to be associated to the PGUSER, not the jtapi user. (DialedNumber RPs and ACD Phones only need be associated to the pguser). you should remove the association of 7505 from the JTAPI user.
ctiPorts and triggers are associated to the JTAPI user. (make sure this is the case)
Voicemail on an agent's ICM extension is not a recommended configuration, though I use it in one instance in my company.
The suggested method is to give agents who need voicemail a second line which is not ICM controlled.
However, if you need to maintain voicemail on the ICM extension, you need to ensure that the agent has an ICM desk setting which specifies an RNA timer shorter than the CFNA timer in CallManager. If that is set properly, calls to the agent while logged on will RONA, and calls while not logged on will go to VM.
Thanks for your help with this. I opened a TAC case on this. Turns out that I had everything configured correctly. TAC had me turn on certain tracing within a couple of processes. This fixed the problem. I don't know why that worked, but it did.
The problem I was having was the behavior of ICM despite whatever configurations I tried. ICM was not pulling the call back and sending it to the RONA script. Even if my configurations in Call Manager were wrong, ICM should have attempted to pull the call back on "no answer". ICM wasn't even making the attempt.
SIP traces provide key information in troubleshooting SIP Trunks, SIP
endpoints and other SIP related issues. Even though these traces are in
clear text, these texts can be gibberish unless you understand fully
what they mean. This document attempts to br...
Please find the attached HTML document, download and open it on your PC.
This provides an easy to use form where you simply answer a few
questions and it will render the proper jabber-config.xml file for you
to copy/paste. There is built in logic to verif...
[toc:faq]CUCM Database Replication is an area in which Cisco customers
and partners have asked for more in-depth training in being able to
properly assess a replication problem and potentially resolve an issue
without involving TAC. This document discusse...