CallManager 6.X - Control fall-back to primary CM

Unanswered Question

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?

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
Jaime Valencia Fri, 02/22/2008 - 16:34

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

Jaime Valencia Sat, 02/23/2008 - 12:15

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

Actions

This Discussion