UCM Down / Features Disabled

[tim.moomaw]

Hello All,

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?

[jaylena123]

Did you ever find a resolution to this?  we are having the same issue with IP Communicator 7.0.3.

[srsivara]

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.

- Sriram