I'm wondering if anybody has the following issue. We have attendant console (legacy AC and not the new Arc Express client) installed and running on several computers. Call Manager version is 7.0.2 and AC console version is 7.1(1_a). The reason we can use Attendant console is because the call managers were upgraded from 6.1. Everything works fine except the following:
When trying to do a blind transfer (on the AC client) of any incoming call from the outside world to a CTI-RP DN that is registered to an IPCC server (a jtapi trigger), the call fails and the outside person hears a busy tone. The same transfer works if the call is internal. Also, the transfer works if it's performed on the phone itself (for both internal/external calls). The kicker is that the consult transfer works on the AC client, and that's what's being used currently by the operator, but that's not ideal as the beginning portion of the ACD greeting gets cut off if the transfer is not completed fast enough.
Customer tells me that this was working initially when deployed and then it broked down. The engineers in charge of the IPCC tell me nothing has changed on their end.
If it helps any, transfers to non-registered CTI-RP DNs work fine. It only has to do with DN's that are registered as a JTAPI trigger on the IPCC server. I wonder if anyboyd has run into this, or if someboyd has a similar setup and can give it a test and let me know what they get.
Very sorry that i dont have a solution to the issue you're experiencing. However, i'm interested to know how you got AC to work on CM 7.X. We just upgraded from 4.1.3 (we're way behind), and while the app is able to hit the call manager, none of the lines on the phone show up as registered in the app. When i try to make a call, the error i get says, No Available Lines to Make a New Call. Is there somethign im missing? I've only enabled one server in the cluster to use AC, per the instructions on CCO.
Any insight would be much appreciated. Again, sorry i dont have anything to contribute to the issue you're reporting. Though if i can get this to work, i'll probably experience the same thing...
I'm doing the upgrade just like this right now.....the problem for me was that the ac app user and ACDevice auth user password need to be 12345 and also put the controlled devices and pilot points as a controlled device as well. Then restart the CTI mgr and Auto Attendant Services under feature services and do it on both servers, if applicable. Then also, I set my jtapi username to ac and the Device auth app username to the AVDevice auth user. Make sure CTI control is checked on your phones too.
I meant to post my fix in here, but it's been real hectic lately. What I found out is that when the direct transfer option of the AC client is used, the originating end-point of the transfer is the gateway that the call came through. If the partition of the IP-IVR port is not in the calling search space of the gateway port, the transfer fails. We added the partition of the CTI ports to the gateway CSS and it worked fine.
The reason consult tranfer on AC and either consult/blind transfer on the phone worked is because the phone/AC on these transfers actually initiate a new call to the IP-IVR port using the phone's CSS, which can reach those ports without any issues, and then call is bridged when the transfer is completed. That's not the case for a direct transfer from AC where the orginating end-point is the gateway.
If you have the same setup as ours, it should resolve your issue too.
You have reached the Cisco Logistics Support Center.. To Check Status of
your RMA, visit Product Returns & Replacements (RMA). Need help? Contact
us by Phone or Email. North Americas Phone: 1800 553 2447 Option 4
Email: firstname.lastname@example.org Europe Phone: +3...
The short answer is that you don't.... That isn't entirely true while at
the same time it kind of is, but for the most part you don't configure
the softkeys. You enable or disable them via TCL. Here is the long
answer. Be sure to read the whole thing or e...
Topology: IP Phone > Switches > Microsoft NPS setup to forward 802.1x
proxy to > ISE 2.1 patch 3 Authentication: EAP-TLS using Cisco MIC SANs
Phone Models 802.1X support? 802.1x flavor Addtl Comment EAP-MD5 EAP-TLS
Cisco 3905 Y Y N Cisco 6911 Y Y N Cisco ...