Our client is a US-based company known for providing high quality municipal services. It is headquartered in Georgia.
– IP phones at one of the client’s locations kept going in and out of registering.
– After phones were registered, it was showing “CM fallback server” every few minutes.
– We found that after the phones were manually rebooted, they’d register to the CUCM server and then go into SRST mode in a few minutes.
– Upon looking at the phone console logs, we found that the phones did not trust the configuration file downloaded from CUCM during its registration process.
– We verified the connectivity of the CUCM servers and it was fine. However, we found database replication issues between the primary and secondary nodes.
– We also found that the servers were up for over 350 days.
– With the customer’s approval, we repaired the database replication issue between the CUCM publisher and CUC subscriber.
– After the database replication issue was fixed, we performed a reboot of both the CUCM servers (publisher and subscriber).
– Once the servers were rebooted, we allowed the services for back up. Our team performed a diagnostic test on the servers, which passed successfully. We re-verified the database replication and everything was working normally.
– The customer’s phones were successfully registered to the CUCM server without losing registration.
– We advised the customer that it is recommended to perform a maintenance reboot of the UC servers every 90-180 days.
– Servers running for a long time may cause database replication to be disrupted, which can lead to multiple issues with IP phone registration, calling, etc.