CUCM failover timings

[dcharlier]

Hello,

Does anyone know how much time it take to :

1) failover from an active cucm to a standby cucm. (I know that the phone re-registers to a second cucm, as soon as it misses 3 keepalives, and by default, a keepalive is sent each 30 seconds), but is this documented somewhere ?

2) failover from an active cucm to an srst

Many Thanks for all input on this.

Thanks,

Dirk

[Sushil Kumar Katre · Accepted solution]

Hi Dirk,

Follwing is a nice description of how failover is going to happen from "Cisco Voice Gateway and Gatekeeper" book -

During normal operation, Cisco IP phones exchange keepalive messages with their configured Cisco CallManagers. SRST is a licensed feature available on Cisco voice routers that allows Cisco IP phones to register with the gateway if these keepalive messages are lost. Cisco IP phones exchange the keepalive messages every 30 seconds by default. If three keepalive messages are missed, the IP phone initiates registration with the next device in its CallManager list. If the IP phone cannot reach a Cisco CallManager, it initiates registration with the gateway.

When the gateway receives a registration request from an IP phone, it acknowledges the request and enters SRST mode. The IP phone then sends its configuration settings to the SRST gateway. The gateway uses these settings to configure virtual dial peers on the SRST gateway for each IP phone directory number (DN)

Fallback Time-

The time that it takes for an IP phone to initiate registration with the SRST gateway depends on what caused the failover. Three scenarios can lead to the phone registering with the SRST gateway:

The CallManager process on the active CallManager is manually shut down This results in the TCP connection between the IP phone and the CallManager being closed. If no backup CallManager is available, the IP phone immediately attempts to register with the SRST gateway.

IP connectivity between the IP phone and the CallManager is broken When the IP phone sends its first keepalive after the TCP connection is broken, it sends TCP retries for 20 to 25 seconds. Then it initiates registration with the SRST gateway.

The CallManager process is locked In this case, the TCP connection is not closed. The IP phone waits for the keepalives to expire before initiating registration with the SRST gateway. This can take up to 90 seconds. This occurs when the server operating system (OS) is still functioning. If the entire server fails or is shut down, the TCP retries fail, as described in the previous bullet.

Restoral Time

By default, the IP phone waits for 120 seconds after the CallManager connection is restored before unregistering with the SRST gateway. This prevents a flapping link or other intermittent problem from causing the IP phone to repeatedly unregister and reregister with SRST.

-> Sushil

[Marwan ALshawi · Accepted solution]

i think Sushil has put the right answer for ur second question

and here the answer for ur first question from the same book :)

You might need to adjust the default timers when using multiple CallManagers, especially if the gateway has a PRI connection for inbound calls. When a call comes in that should be forwarded to a CallManager, the router attempts to set up an H.225 TCP session to its preferred VoIP dial peer. The TCP session must time out before it will try another dial peer. This takes 15 seconds by default. ISDN Q.931 has a Call Proceeding timeout of 10 seconds. A call that comes in over a PRI line will time out before the router can fail over to an alternate CallManager. Even without a PRI connection, 15 seconds might be longer than you want to wait.

To remedy this, change the H.225 TCP session establishment timer. The voice class h323 10 command creates a voice class in global configuration mode that reduces the timer to three seconds:

NYCgateway(config)#voice class h323 10

NYCgateway(configs-class)#h225 timeout tcp establish 3

Apply that voice class under the dial peers pointing to redundant CallManagers:

NYCgateway(config)#dial-peer voice 1 voip

NYCgateway(config-dial-peer)#session target ipv4:10.1.10.10

NYCgateway(config-dial-peer)#voice-class h323 10

if helpful Rate