02-22-2008 02:16 PM - edited 03-15-2019 09:01 AM
I've looked through CM services and enterprise settings but could not find a way to control whether to allow automated fall-back to primary CM after primary CM comes back on-line. I know it won't do it with a call active, but is anyone aware of a way to control when phones re-register to primary CM after an outage?
02-22-2008 04:34 PM
the phones use their CCM group to define to which server to register
By default they send keepalives to the primary server every 30 seconds, and to the backup every 60 seconds. The loss of the ACKs from the server causes the phone to fail to the 2nd option
when they are on the 2nd server they still keep sending keepalives to the primary server expecting the ACK, when they start receiving the ACKs they return to the primary server
this goes all down all the way thru the 3 servers and even to SRST.
If the phones are in SRST mode they keep sending keepalives to the CCMs ervers waiting for them to come back
HTH
02-23-2008 11:59 AM
Thanks for the reply. I guess my question more specifically is: Is there a way to configure CM to tell the phones to only go back to their primary server manually, rather than to be automatically triggered through the receipt of a keepalive? I don't think so, but just want to verify. THANKS!
02-23-2008 12:15 PM
Sorry, but we cannot configure that as you could do with a GW. the process is automatic
just to be sure i went thru the service parameters (i still keep learning of new parameters =)) and only found this one, it's not for that purpose but i like the explanation of the process
Maximum Phone Fallback Queue Depth:
This parameter specifies the maximum number of phone registrations that a higher priority Cisco CallManager queues at one time. The Cisco CallManager Group determines Cisco CallManager priority. This parameter protects Cisco CallManager from being overloaded with registration requests when it comes back online after a failover situation. When a phone receives notification that a higher priority Cisco CallManager is available, it sends a registration request to the higher priority Cisco CallManager. After acknowledgement, the phone immediately unregisters to the lower priority Cisco CallManager and sends a registration request to the higher priority Cisco CallManager. The phone stays unregistered to the previous Cisco CallManager for the time that it takes for the higher priority Cisco CallManager to process the queued registration request.
HTH
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide