I have two different locations having this same issue. The BLF key will stop showing the status of the other but, after a reset of the effected device it works.... only to have the problem roll to another phone in that same call pick up group. The BLFs work as speed dials. Only the flashing to show status has stopped. If the user unplugs the phone or if we perform a RESET of the phone, the flashing returns. It continues to roll through the entire group.
What registration is upon the reboot/restart of these devices? How do I isolate this problem?
There's a few bugs like that on the SIP firmware but shouldn't apply to the SCCP firmware. 9.0(3) is pretty old. Can you try upgrading one phone to a later firmware version and see if that resolves the issue?
If not, we'll probably need CallManager traces/packet captures covering the period of going from working to nonworking to figure it out.
Can you walk me through the firmware upgrade or how to find/capture a trace file? These events are transient and once reset, they may stay clear for hours or days. We have not found any patterns with which we can predict these occurances. Your help is appreciated.
8000 phones means that there is probably more than a CUCM. CUPS, a switchboard, shared lines, Lync or Jabber,... all subscribe to the status. A short network outage or a failover of many phones can cause problems. We observed this many times in the past years. Sometimes lines are busy but no one is using the line, after a reset everything works normal an a few days another line is affected. A phone is ringing and as soon as you lift the receiver the other party is put on hold. ...
A restart of all CTI Manager services solved the problem, otherwise reboot the cluster.