Cisco Cisco Customer Voice Portal 8.0(1) Design Guide

The call dispositions presented in this section apply to both HSRP and alternate gatekeeper.

A gatekeeper can fail in any of the following ways:

The primary gatekeeper fails

Some calls in progress may not be transferred during the period that the endpoints are 
re-registering to the backup gatekeeper. After the failed transfer, an error is returned to the ICM. 
If the ICM script is coded to return an error (an END node does this) and survivability is 
configured on the gateway, the call is default-routed.

New calls arriving at the incoming gateway and Unified CVP are serviced correctly, although it 
is possible that some of the calls might invoke survivability during the period that the endpoints 
are re-registering to the backup gatekeeper.

All gatekeepers fail

The Unified CVP H.323 Service goes out of service.

Calls in progress are not transferred. After the failed transfer, an error is returned to the ICM. 
If the ICM script is coded to return an error (an END node does this) and survivability is 
configured on the gateway, the call is default-routed.

New calls arriving at the gateway are default-routed if survivability is configured on the 
gateway.

The primary gatekeeper degrades but does not fail

There are two conditions that usually cause this behavior: low memory due to memory leaks or 
excessive debug levels causing CPU overload.

In this situation, call processing behavior is unpredictable due to the fact that there might be no 
clean failover to the backup gatekeeper. If survivability is configured on the gateway, calls are 
default-routed.

When multiple Unified CVP Call Servers (Call Servers) are used for redundancy and scalability 
purposes in Unified CVP, Cisco recommends using a gatekeeper for load balancing and failover services. 
The H.323 Service is the component of the Call Server that processes H.323 messages and registers with 
the gatekeeper.

While it is possible for the ingress PSTN gateways to send H.323 calls to the H.323 Service using 
dial-peers with the specific IP address of the Call Server, doing so results in delays to callers during a 
failure scenario. In this scenario, a dial-peer is statically configured on the ingress gateways to 
load-balance across Unified CVP servers, or in a prioritized fashion so that the primary server is always 
used under normal conditions. When the H.323 Service is no longer reachable for whatever reason, the 
dial-peer will attempt to send the call to the failed server and wait for a timeout to occur before 
proceeding to the next dial-peer configured, and this process occurs for each new call.

When a gatekeeper is used instead, the gateway dial-peer simply points to the gatekeeper, and the 
gatekeeper is responsible for determining which Call Servers are active and it load balances across them. 
The gatekeeper's registration process enables it to know which servers are available and does not suffer 
from the same time-outs as dial-peers. Therefore, Cisco recommends using a gatekeeper instead of static 
Cisco IOS dial-peers for redundancy and load balancing.