IP Phone switchover to SRST and back - process involved

[gp1200x]

Are there configurable parameters of when a phone will attempt to switch to the backup CM and the SRST? The VOIP phones at our sites are set to use a primary CM, backup CM and then an SRST as the last resort. We have noticed that if a phone loses communication to its primary CM due to a short communication outage (that will prevent communicating to both the primary and backup CM) that the phone attempts to begin registration to the SRST. However the communication path to the primary CM is restored before this action completes so it appears that the registration to the SRST never finishes and the phones seem to undergo a reboot (seems like a real full reboot) process and re-establish communications to the primary CM. Can someone explain the process here since I do not see why the phone should be attempting a reboot. Are the times configurable as to how long the phone waits before it attempts to utilize the backup CM and then the SRST? Does the phone actually perform a full reboot if the comm path to the CM is restored before the backup registration to the SRST is completed?  The real problem is the amount of time all of this takes. Unfortunately it appears that once the switchover hunt  process starts (communication loss to the primary CM exceeds the max time) the restoration process to the primary CM takes a significant amount of time even if the path to the primary CM is available shortly after that max time has been exceeded. Do the phones actually perform a reboot during any of these cycles?   Thanks

[Manish Gogna]

Hi,

There is a setting in the Device Pool of the IP phone called 'Connection Monitor Duration'.

This setting defines the time that the Cisco Unified IP Phone monitors its connection to Cisco Unified Communications Manager before it unregisters from SRST and reregisters to Cisco Unified Communications Manager.

To use the configuration for the enterprise parameter, you can enter -1 or leave the field blank. The default value for the enterprise parameter equals 120 seconds.

Change this setting if you need to disable the connection monitor or if you want to extend the connection monitor time. The maximum number of seconds that you can enter in the field equals 2592000.

HTH

Manish

[Ayodeji Okanlawon]

To understand the SCCP failover architecture you need to take a few minutes to read this documentation. Its worth every bit of your time.

https://supportforums.cisco.com/document/74666/cucm-ip-phone-sccp-keepalive-and-failover-architecture

Now to your questions..

By default, SCCP phones send a keepalive to their primary CUCM server every 30 seconds and to their failover node, which is the second node listed in the phone's Call Manager (CM) Group, every 60 seconds. The primary node will respond with a keepalive ACK confirming that both the TCP connection and the SCCP connection are both still valid. Alternatively, if the CCM Service on the primary node is down, the TCP connection may be ACK'd, but the SCCP aspect of the keepalive would not.

The phone should never perform a full reboot, something is not right here. You should take wireshark captures and look at what is going on when the phone looses connectivity to its primary node. This will be the starting point of your troubleshooting..