Cisco Unity-CM TSP device 8 (Unity port 57): Failed blind transfer to extension 2796. Busy tone detected. If this is a persistent problem, it may indicate a problem on the Cisco Unity and/or Cisco Call Manager. Verify that transfers are working, and contact TAC if the problem persists.
Is this Unity system configured to support a Legacy PBX in addition to CallManager? We sometimes see messages like this in dual-switch configurations of that type. Anyway, here's my response to the messages you're seeing.
1) "Failed blind transfer to extension 2796." What type of device is at extension 2796 - is it an IP phone, a CTI route point, a gateway, or what? Also, is it a number that Unity ports can reach in your dial plan - do you need a feature access code (ie, dial a 9 first, for instance) to reach it? Also, it says "Busy tone detected." For most devices, getting a busy tone on a blind transfer isn't a big deal - what is this device configured to do when busy? Most IP phones are configured to forward back to Unity on busy transfers, but some other devices may have problems on busy transfers. Also, do you see similar messages in the eventlog for extensions other than 2796, or is it just that one?
2) The other messages you list (Drop and Answer timing-out) happen about 8 minutes later, so they likely aren't related. We sometimes see messages of this type if a site has not isolated the dial-out ports from the incoming-call ports. What can happen is that a call arrives on the port at the same time that Unity wants to use it to send a notification of a new message or turn on/off a user's MWI. It is considered a Unity best-practice to isolate dial-out ports from incoming-call ports in order to avoid those types of problems. In Unity 3.1(5), you can do this via the "Ports" page in the Unity System Administration screens - on some ports, remove the answer calls capability and on the others remove all capabilities except to answer calls. Generally, you should reserve 15-20% of your ports for Notifications and MWIs. Also, you will need to change the voicemail hunt group on CallManager so that it doesn't route calls to the ports that you've now reserved for dialouts.
Finally, how often do you see these errors in the eventlog, and when they occur, what behavior do you observe? Are ports getting stuck when you view the Status Monitor, or does the system seem to recover? If you are losing ports, especially after you do some more analysis & changes based on what I've written above, you should probably open a case with Cisco TAC.
the same problems occur with the system of a customer.
--> Dual switch integration with LegacyPBX (switch 0) and cCM 3.3.2 / TSP7.0.3 and Unity 4.0.2. (switch 1)
port 1-10 = legacy
port 11-18 = ccm
--> device 16 = port 1 of ccm.
port 11-16 answer, no dialout
port 17 no answer, TRAP
port 18 no answer, configured for MWI.
also tested with every port configured for answering as well.
Event Source: CiscoUnity_TSP
Event Category: None
Event ID: 115
Time: 3:02:24 PM
Cisco Unity-CM TSP: Warning: CallWaiting tone detected on a Voicemail port. The second caller (that is on Call Waiting) will be ignored, and eventually the ports will disconnect from Cisco Call Manager. To fix this problem, disable CallWaiting for Voice Mail ports on the Cisco Call Manager. device 16
<<16 = port 1 of CCM; It is NOT possible to have a CCM voicemail ports configured with Call Waiting....>
a call dials the Message button on the ip phone. (VM pilot 10101) Then the call is connected.
a second caller dials the Message button as well.
The call is ringing. When the first subscriber is disconnected, the second caller will then be connected to port 1.
It should have gone to port 2 immediately because of my CFWDNA and CFWDBSY settings with the same CSS settings. (port 2 = 10102; port 1 has got CFWD to 10102)
Ofcourse I already checked the VM partitions and css.
When dialing individualy to the ports, all ports are answering.
Cisco Unity-CM TSP device 16 (Unity port 1): Failed blind transfer to extension 7715. Busy tone detected. If this is a persistent problem, it may indicate a problem on the Cisco Unity and/or Cisco Call Manager. Verify that transfers are working, and contact TAC if the problem persists. %5
related to event 115 as well (in this case), because of the 2nd port not answering.
These are the paths to get to each CCX logs through CLI. They may be helpful if you are having issues accessing RTMT or downloading logs through it.
If you want to download them you have to prefix "file get " and you can add one of the options (re...