IP Phone switchover to SRST and back - process involved
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
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.
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..
Please rate all useful posts
"The essence of christianity is not the enthronement but the obliteration of self --William Barclay"
SIP traces provide key information in troubleshooting SIP Trunks, SIP
endpoints and other SIP related issues. Even though these traces are in
clear text, these texts can be gibberish unless you understand fully
what they mean. This document attempts to br...
Please find the attached HTML document, download and open it on your PC.
This provides an easy to use form where you simply answer a few
questions and it will render the proper jabber-config.xml file for you
to copy/paste. There is built in logic to verif...
CUCM Database Replication is an area in which Cisco customers and
partners have asked for more in-depth training in being able to properly
assess a replication problem and potentially resolve an issue without
involving TAC. This document discusses the bas...