We are on occasion experiencing disconnects with our IP Communicator clients running 7.0.2 of the communicator. We recently upgraded to Call Manager 7.0.2 as well as moved several call centers to UCCX 7.0. Typically what happens is that the voice stream drops with either a one way audio issue or just drops completely. The communicator tends to lock-up and then shortly after displays, UCM Down/Features Disabled. When this occurs it only affects individual clients and nobody else is affected. We typically will need to go in and kill the communicatork9.exe process. TAC states that this is a connectivity issue - ok... I don't doubt that but there are no errors on the Call Manager port, no other clients are affected, and other applications running on the machine that are far more "sensitive" than the IPC remain stable. TAC has said that the phone appears to "unregister" itself from call manager. We have applied the typical qos trust commands on both the CM ports and also the client ports. One engineer who was using a version 2 of the IPC never saw this error in the past 5 years but when he upgraded his IPC to 7.0.2 he experienced it. After the engineer experienced it yesetday he went to the status display and there was no status next to the CM that was supposed to be active and the standby CM was still listed as Standby - shouldn't the client try to register with the standby if the IPC thinks the active server is down? There is no windows firewall enabled and there is no other firewall, ips, etc between the clients and the Call Managers. It appears in the logs that the heartbeat dies completely even though it should send out 3 heartbeats correct before failing? I have a hard time believing all 3 heartbeats get dropped. If it were a connectivity issue I would also think that more than 1 IPC client at a time would experience this issue. Any thoughts?
Does this problem follow a pattern, like the call processing being high during that time, cpu spikes ? IP Communicator logs and CallManager traces for the time period of the issue might help. However, packet capture from IP Communicator might show more information, if the TCP socket is being broken / keepalives being missed / etc.
This problem would require signficant analysis and troubleshooting - opening a TAC case once you have the logs and captures might be a good idea.
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...
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 discusses the bas...