Call Survivability in Distributed Deployments
In distributed deployments, design consideration needs to be given to other voice services that are being run at the branch. For example, the branch is typically a remote Cisco CallManager site supporting both ACD agent and non-agent phones. This deployment also implies that the PSTN gateway is used not only for ingress of CVP calls, but ingress/egress of the regular non-ACD phone calls.
Branch reliability becomes somewhat more of an issue than it is in a centralized CVP model, because WAN's are typically less reliable than LAN links. Therefore, you must provide mechanisms which are local to the branch to gracefully handle calls that are impacted by loss of a WAN link to the central site.
Call survivability must be considered for both the CVP and non-CVP related calls. For the Cisco CallManager endpoint phones, this is accomplished via on IOS feature known as Survivable Remote Site Telephony (SRST).
Further details specific to SRST can be found in the IP Telephony SRND at:
For CVP related calls, survivability is handled using a combination of services from a TCL script (survivability.tcl) and SRST functions.
The survivability TCL script is used to monitor the H.225 connection for all calls that ingress through the remote gateway. If a signaling failure occurs with this H.225 link, the TCL script takes control of the call and redirects it to a configurable destination. The destination choices for the TCL script are configured as parameters in the IOS Gateway configuration.
Alternative destinations for this transfer could be another H.323 transfer (including the SRST call agent at the remote site), *x TnT, and hook flash. When transferring to the SRST call agent at the remote site, the most common target is an SRST alias or a Basic ACD hunt group. Further information about these SRST functions can be found at the above link.
For further information on configuration and application of these transfer methods, please see Appendix B, Transferring and Queueing calls with Customer Voice Portal of the CVP 3.1 Configuration and Administration guide. This can be found at:
This chapter covers the following topics:
•H.323 Gatekeeper Call Routing implications in a distributed branch CVP model (Centralized CallManager model)
In a pure TDM environment where CVP is switching calls from an ingress gateway to an egress gateway attached to TDM ACD/IVR, the gatekeeper can handle the Call Admission Control (CAC) functionality. CAC is a term used to describe the mechanism for determining if there is enough bandwidth on a network to place a call.
If Cisco CallManager is the egress gateway, gatekeeper CAC can only be used if the ingress CVP gateways and the IP phones are at different sites. Please note that gatekeeper dialplan resolution is still in use.
Since Cisco CallManager Locations-based CAC is used between the remote sites of a cluster, gatekeeper typically is used for dial-plan resolution only. Understanding the routing of calls in the dial plan and the gatekeeper resolution is important, as call routing situations might occur in which it is necessary to use more than one set of gatekeepers in the implementation. This is particularly common when using this model in a situation where more than one Cisco CallManager Cluster is being used to control the remote sites. For further discussion and understanding of this topic, see H.323 Gatekeeper Call Routing implications in a distributed branch CVP model (Centralized CallManager model).
The two CAC mechanisms used in a CVP environment are Gatekeeper CAC and CallManager Locations CAC. In a completely centralized deployment, CAC is not necessary. CAC is only needed when there is a limited amount of bandwidth between the IP phones or gateways.
Connection Admission Control (CAC) needs to be considered from a solution perspective, not just a CVP perspective. This is most evident in the distributed branch office model where there are other voice services, such as Cisco CallManager, sharing the same H.323 gateways with CVP and the amount of bandwidth between the sites is limited. The most important item to consider here is what CAC mechanisms are in place on the network so that a consistent CAC mechanism can be used to account for all the calls managed at that site. A standalone CVP system typically uses Gatekeeper CAC while a Cisco CallManager cluster managing multiple sites will use Cisco CallManager Locations Based CAC.
Cisco CallManager keeps track of CAC by identifying devices in certain "locations" and keeping track of how many calls are active between these locations. Since the Cisco CallManager knows how many calls are active and what codec is in use for each call, it is able to calculate how much bandwidth is in use and limit the number of calls allowed.
A thorough conceptual understanding of CAC mechanisms is important. These mechanisms are explained in the CAC section of the IPT SRND, which can be found at
If considerations are not given to CAC, in a distributed CVP model, three unique methods of CAC could be in use at the same time.
•Gatekeepers for CVP
•If multiple clusters are used, gatekeepers for intercluster Cisco CallManager calls
•Cisco CallManager Controlled Locations Based Admission Control for remote sites managed by the same cluster
If Cisco CallManager is sending or receiving calls from CVP, and there are CVP gateways & IP Phone Agents collocated at remote sites, it is important to understand the call flows in order to design and configure CAC correctly.
The gatekeeper and Cisco CallManager do not share bandwidth usage information. Networks shared by both the gatekeeper and IP phones will have 2 separate CAC mechanisms determining if there is enough bandwidth to place a call. Understanding how Cisco CallManager determines an endpoints location is key to designing the CAC properly.
Investigating this further, consider the basic call flow of a non-CVP call vs. a CVP call. When a user picks up an IP Phone and makes a call from the remote site to a the central site, Cisco CallManager considers the location definitions of the endpoints and the codec requirements defined in the CallManager Region definitions and decides whether or not to allow the call. Note that the CAC and the codec requirements are controlled between these endpoints by Cisco CallManager as the controlling call agent.
CVP itself uses gatekeeper for dialed-number resolution and CAC. However, as previously noted, with multiple branch locations controlled by a single Cisco CallManager cluster, Cisco CallManager does not use gatekeeper for CAC (but LCAC instead). The Cisco CallManager must be aware that CVP delivered calls are coming from a gateway at a specific branch so it can consider these calls in the LCAC mechanism. This requires enabling one CallManager service parameter and ensuring that one other is set to default:
•Change the Cluster wide service parameter "Accept unknown TCP connections" to True. (The default is False)
•Device Name of gatekeeper trunk that will use port 1720" must remain at the default of blank
"Accept Unknown TCP Connection" when set to "true" changes the behavior for inbound for H.323 calls. Cisco CallManager accepts an unknown H.225 TCP connection and wait for the H.323 setup message. Cisco CallManager then extracts the User to User Information Element "UUIE". In this case, the element contains the IP address of the originating gateway. Cisco CallManager compares this against its configured gateways. If a match is found, the call is treated as if it originated from the voice gateway and not the CVP Voice Browser. Note that this is NOT how Cisco CallManager traditionally treats a gatekeeper-controlled H.323 call. Typically, all gatekeeper-controlled calls come from Location "0" (Zero). This change ensures the call is not treated as a gatekeeper-controlled call and that Locations Admission control is applied. Note that, in this model, if the Cisco CallManager does not match the gateway signaling address in its list of configured gateways, it rejects the call. Figure 6-1 illustrates the decision tree for H.323 call processing.
Figure 6-1 CallManager H323 Signalling Flow Topology
These changes allow for effective and scalable use of H.323 gateways in a Centralized CallManager deployment.
In a CVP environment, Cisco CallManager can be an ingress or egress gateway. It is more common for Cisco CallManager to be an egress gateway because typically callers are calling from the PSTN, being queued by CVP, and then switched to Cisco CallManager for handling by an Agent. If the caller is not calling from the PSTN, but instead from an IP Phone, Cisco CallManager is an ingress gateway from the perspective of CVP.
Cisco CallManager as an egress Gateway
CVP normally depends on the gatekeeper for Dial-plan resolution & CAC. In order to deploy Cisco CallManager alongside CVP, Cisco CallManager CAC needs to be used for calls between the ingress CVP gateway and the agent IP phone. The ability for Cisco CallManager to correctly identify the ingress CVP gateway is complicated because the CVP Call Server is the one that is actually making the H.323 call to Cisco CallManager. Therefore, Cisco CallManager sees the call as coming from the centralized CVP Call Server rather than the remote ingress gateway.
The CVP Call Server is able to solve this problem by setting the source signaling inside the H.323 setup to the IP address of the ingress gateway. The Cisco CallManager, upon receiving the setup from CVP, sees the source signaling address and knows that the address is the one that should be used when determining what location the call is coming from. Since the Cisco CallManager has this ingress gateway IP configured, Cisco CallManager will use Locations CAC to deduct bandwidth between the ingress gateway and destination IP phone locations. The CVP Call Server should not be configured as a gateway in Cisco CallManager; instead the CVP Call Server should send calls to Cisco CallManager via a gatekeeper controlled H.323 Trunk.
Cisco CallManager as an ingress Gateway
When an IP Phone initiates a call to CVP, Cisco CallManager is acting as the ingress gateway to CVP. Since the CVP Call Server cannot be configured as a gateway in Cisco CallManager, Cisco CallManager must send the call to CVP via a gatekeeper controlled H.323 Trunk. When a remote phone calls CVP, and is transferred to its local VoiceXML gateway, Cisco CallManager thinks that the call is traversing the WAN since the gatekeeper controlled Trunk is in the hub location and deducts bandwidth to the remote phone even though no WAN bandwidth is in use. Also, the Trunk that is sending calls to CVP needs to have MTP required checked.
Multiple Cisco CallManager Clusters
If a call coming in through a CVP ingress gateway is destined for an IP Phone at a different site registered to a different cluster, the call must be routed through the cluster that is handling CAC for the ingress gateway first, and then routed to the destination cluster. If the call is routed directly from the ingress gateway to the destination cluster, the cluster that is handling CAC for the ingress gateway is not aware of the call traversing the WAN and does not deduct bandwidth appropriately.
Cisco CallManager 5.0 introduces support for RSVP between endpoints within a cluster. RSVP is a protocol used for Call Admission Control (CAC) and is used by the routers in the network to reserve bandwidth for calls. RSVP can be used for delivering calls to IPCC agents in a CallManager cluster. For more information on RSVP, please refer to the Cisco CallManager 5.0 version of the Cisco IP Telephony Solution Reference Network Design (SRND), available at
H.323 Gatekeeper Call Routing implications in a distributed branch CVP model (Centralized CallManager model)
Proper configuration of remote H.323 gateways with a CallManager cluster is important. First consider the H.225 implications of this without the use of gatekeeper.
When configuring dial-peer destinations for the IOS Gateways, you must configure a dial-peer pointing to the IP addresses of the Cisco CallManager servers that are processing calls for that gateway. These server IP addresses must be the same servers that are in the redundancy group on the device pool definition for that gateway in the CallManager configuration. If the remote H.323 gateway sends a call to a Cisco CallManager server that is not in the redundancy group for that gateway, the call is rejected.
Figure 6-2 Dial Peer Configuration
In Figure 6-2, if the Madison gateway sends a call to the.3 server, the call is rejected.
While this is simple to understand, with several hundred remote sites it can become challenging to maintain over an extended period of time; anytime the Cisco CallManager's gatekeeper redundancy group might be changed, all the remote H.323 gateway dial-peer targets must be changed to match the new IP address of the server added to the redundancy group. A gatekeeper can help reduce this challenge.
When using the gatekeeper for configuration, the H.323 gateway makes a RAS request to the gatekeeper for an IP address to which to send the call. The gatekeeper automatically responds with one of the Cisco CallManager server addresses defined in the redundancy group for the gatekeeper trunk. If the redundancy group is changed, the Cisco CallManager must be re-registered to the gatekeeper. However, no further configuration is necessary on the remote gateway.
Multiple Cisco CallManager Clusters
When more than one centralized Cisco CallManager cluster are used for the remote sites, additional consideration must be given to routing calls based on agent selection. In a multiple cluster environment, each cluster manages a group of remote sites and tracks the voice calls to those sites within the locations-based CAC mechanism. Using the changes discussed above, Cisco CallManager considers H.323 calls within its locations based CAC mechanism. Because H.323 is a peer-to-peer protocol, an H.323 gateway can signal a call to any other call agent that will accept it. Considering the LCAC mechanism described above, it is necessary for the remote gateway to be told to signal a call to the Cisco CallManager cluster that owns the location of that remote gateway. However, in an IPCC Enterprise environment, the ICM tracks the availability of agents without consideration to what cluster they are located on. This ability provides great scalability for IPCC Enterprise, but must be accounted for in this type of implementation.