Nothing in your SRST config would prevent the phone from registering back with UCM, that behaviour is controlled by phone firmware. I agree with Chris that firmware is most likely the culprit here. There have been many issues with several models of phones not being able to transition back and forth from SRST properly on certain software loads. Can you post the firmware version you upgraded to?
In terms of logging and root cause analysis, as Manish mentioned the "full meal deal" of logs would be a PCAP from the phone and from CUCM. This would prove whether the phone is trying to re-establish TCP connecitivity with CUCM at all. If it is not even trying, then we have even more certainty that it is firmware related. I understand that sometimes it is difficult to get the PCAP from the phone side (which is the more valuable one to obtain in this case) if you don't have physical access. For the CUCM side, packet captures are super easy to run and download, for more on this read here.
In the absence of a PCAP, what you could grab is the console phone logs from the phone web interface. Enable web access on the phone, drop the phone into SRST, then restore network connectivity back to CUCM. After a few minutes grab the console logs for the time range you were testing. There should be some clues in that log whether or not the phone tried to re-establish a connection to UCM.
Here is how to grab the console logs from the 78XX phones:
- Enable web access for the phone in CUCM
- Navigate to the phone web interface (ip address of the phone)
- Navigate to Device Logs > Console Logs
- Right click and save all of the .txt logs under the "Current Logs in /var/log:" section. Screenshot below.
Please let us know if this helps, or if you have more questions, and feel free to post any additional logs you capture! If there is one thing this community loves, it is the thrill of crunching through logs!! :)
- Jon
