In a distributed deployment, the ingress gateways are geographically separated from the Unified CVP Call Server. This chapter discusses how these types of deployments should be designed as well as how to handle call survivability and call admission control.
Unified CVP can use several different types of gateways depending on the deployment model. This section discusses each type of gateway and how a distributed deployment can affect them.
Ingress and/or Egress Gateway at the Branch
In this deployment model, ingress gateways located at a branch office are typically used to provide callers with access using local phone numbers rather than centralized or non-geographic numbers. This capability is especially important in international deployments spanning multiple countries. Egress gateways are located at branches either for localized PSTN breakout or for integration of decentralized TDM platforms into the Unified CVP switching solution. Apart from the gateways, all other Unified CVP components are centrally located, and WAN links provide data connectivity from each branch location to the central data center.
Ingress or VoiceXML Gateway at Branch
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 Unified Communications Manager (Unified CM) site supporting both ACD agent and non-agent phones. This model also implies that the PSTN gateway is used not only for ingress of Unified CVP calls but also for ingress/egress of normal user calls for that site. In circumstances where the VoiceXML and voice gateway functions reside at the same branch location but on separate devices, special attention has to be paid to the dial plan to ensure that the VRU leg is sent to the local VoiceXML resource because the Unified CVP Call Server settransferlabel mechanism applies only to co-resident VoiceXML and voice gateway configurations.
When the ingress gateway and VoiceXML gateway at a branch do not reside on the same gateway, there are two ways to ensure that the calls are handled within the branch and not sent across the WAN to a different VoiceXML gateway:
•Configure Unified ICM with multiple Customers, one per location.
This option relies on the Unified ICM configuration to differentiate between calls based on the Dialed Number. The Dialed Number is associated with a Customer representing the branch site. When a NetworkVRU is needed, the NetworkVRU associated with the Customer in Unified ICM is selected and the caller is sent to that NetworkVRU. This allows you to have multiple NetworkVRUs, each with a unique label. The downside of this method is that each NetworkVRU requires its own VRU scripts in Unified ICM. The Unified ICM configuration overhead of making a change to each NetworkVRU script quickly becomes overwhelming when a large number of remote sites are required.
•Configure Unified CVP using the SigDigits feature.
The SigDigits feature in Unified CVP allows you to use the dial plan on the SIP Proxy or gatekeeper to route calls to the correct site. When the call arrives at an ingress gateway, the gateway will prepend digits before sending the call to Unified CVP. Those prepended digits are unique to that site from a dial-plan perspective.
When the call arrives at Unified CVP, Unified CVP will strip the prepended digits and store them in memory, resulting in the original DID on which the call arrived. Unified CVP then notifies Unified ICM of the call arrival using the original DID, which matches a Dialed Number in Unified ICM.
When Unified ICM returns a label to Unified CVP in order to transfer the call to a VoiceXML gateway for IVR treatment or to transfer the call to an agent phone, Unified CVP will prepend the digits that it stored in memory before initiating the transfer. The dial plan in the SIP Proxy or gatekeeper must be configured with the prepended digits in such a way to ensure that calls with a certain prepended digit string are sent to specific VoiceXML gateways or egress gateways. The prepended digits are prepended as a tech-prefix when using H.323.
The term SigDigits is used to describe this feature because the command in Unified CVP to turn on the feature and specify how many significant digits should be stripped is setsigdigits X for H.323, and the sip.properties file configuration directive is sip.SigDigits = X.
This method is preferred because it involves the least amount of Unified ICM configuration overhead; a single NetworkVRU and single set of VRU scripts and Unified ICM routing scripts is all that is needed. This allows all of the Unified CVP servers and VoiceXML gateways to function as a single network-wide virtual IVR from the perspective of Unified ICM.
The SigDigits feature can also be used to solve multi-cluster call admission control problems. (See Call Admission Control Considerations, for more information.)
Co-Located VoiceXML Servers and Gateways
Either all gateways and servers are centralized or each site has its own set of co-located VoiceXML Servers and gateways.
Advantages of co-location:
•A WAN outage does not impact self-service applications.
•No WAN bandwidth is required.
Disadvantages of co-location:
•Extra VoiceXML Servers are required when using replicated branch offices.
•There is additional overhead when deploying applications to multiple VoiceXML servers.
Gateways at the Branch, with Centralized VoiceXML Servers
Advantages of centralized VoiceXML:
•Administration and reporting are centralized.
•VoiceXML Server capacity can be shared among branch offices.
Disadvantages of centralized VoiceXML:
•Branch survivability is limited.
•WAN bandwidth must be sized for additional VoiceXML over HTTP traffic.
Cisco Unified Communications Manager
In a Unified CVP environment, Cisco Unified Communications Manager (Unified CM) can be an ingress or egress gateway. It is more common for Unified CM to be an egress gateway because typically callers are calling from the PSTN, being queued by Unified CVP, and then being switched to Unified CM for handling by an agent. If the caller is not calling from the PSTN but from an IP phone instead, then Unified CM is an ingress gateway from the perspective of Unified CVP.
Unified CM as an Egress Gateway
Unified CVP normally depends on the gatekeeper for dial-plan resolution and call admission control. To deploy Unified CM alongside Unified CVP, you must use Unified CM call admission control for calls between the ingress Unified CVP gateway and the agent IP phone. The ability for Unified CM to identify the ingress Unified CVP gateway correctly is complicated because the Unified CVP Call Server is the component that is actually making the H.323 call to Unified CM. Therefore, Unified CM sees the call as coming from the centralized Unified CVP Call Server rather than from the remote ingress gateway.
The Unified CVP Call Server is able to solve this problem by setting the sourcesignaladdress field inside the H.323 setup to the IP address of the ingress gateway. Upon receiving the setup from Unified CVP, Unified CM sees the source signaling address and knows that the address is the one that should be used when determining from which location the call is coming. Because Unified CM has this ingress gateway IP configured, Unified CM will use its Locations call admission control configuration to deduct the bandwidth between the ingress gateway and the destination IP phone locations. The Unified CVP Call Server should not be configured as a gateway in Unified CM; instead, the Unified CVP Call Server should send calls to Unified CM via a gatekeeper-controlled H.323 trunk. (See Call Admission Control Considerations, for more information on call admission control mechanisms.)
Unified CM as an Ingress Gateway
When an IP phone initiates a call to Unified CVP, Unified CM acts as the ingress gateway to Unified CVP. An H.323 or SIP trunk is used to send calls to Unified CVP. For more information on these types of call flows, see the chapter on Calls Originated by Cisco Unified Communications Manager, page 6-1.
Call Survivability in Distributed Deployments
Distributed deployments require design considerations for other voice services that are being run at the branch. For example, the branch is typically a remote Unified CM site supporting both ACD agent and non-agent phones. This deployment also implies that the PSTN gateway is used not only for ingress of Unified CVP calls but also for ingress/egress of the regular non-ACD phone calls.
Branch reliability becomes somewhat more of an issue than it is in a centralized Unified CVP model because WANs are typically less reliable than LAN links. Therefore, you must provide mechanisms that 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 Unified CVP and non-CVP calls. For the Unified CM endpoint phones, survivability is accomplished via a Cisco IOS feature known as Survivable Remote Site Telephony (SRST). For further details on SRST, refer to the latest version of the Cisco Unified Communications SRND Based on Cisco Unified Communications Manager, available at
For Unified CVP calls, survivability is handled by a combination of services from a TCL script (survivability.tcl) and SRST functions. The survivability TCL script is used to monitor the H.225 or SIP connection for all calls that ingress through the remote gateway. If a signaling failure occurs, 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 Cisco IOS Gateway configuration.
Alternative destinations for this transfer could be another IP destination (including the SRST call agent at the remote site), *8 TNT, or hookflash. With transfers to the SRST call agent at the remote site, the most common target is an SRST alias or a Basic ACD hunt group. For further information about these SRST functions, refer to the Cisco Unified Communications SRND Based on Cisco Unified Communications Manager.
For further information on configuration and application of these transfer methods, refer to the latest version of the Cisco Unified CVP Configuration and Administration Guide, available at http://www.cisco.com.
Call Admission Control Considerations
Call admission control must also be considered from a solution perspective, not just a Unified CVP perspective. These considerations are most evident in the distributed branch office model where there are other voice services, such as Cisco Unified CM, sharing the same gateways with Unified CVP and the amount of bandwidth between the sites is limited. The most important item to consider in this case is which call admission control mechanisms are in place on the network so that a consistent call admission control mechanism can be used to account for all the calls traversing the WAN from that site. If two call admission control mechanisms can admit four calls each and the WAN link is able to handle only four calls, then it is possible for both call admission control entities to admit four calls onto the WAN simultaneously and thereby impair the voice quality. If a single call admission mechanism cannot be implemented, then each call admission control mechanism must have bandwidth allocated to it. This situation is not desirable because it leads to inefficient bandwidth over-provisioning.
There are three call admission control mechanisms that can be used in a Unified CVP environment: gatekeeper call admission control, Unified CM Locations, and Unified CM RSVP Agent. In a single-site deployment, call admission control is not necessary.
Unified CM performs call admission by assigning devices to certain locations and keeping track of how many calls are active between these locations. Because Unified CM 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 to limit the number of calls allowed.
A thorough conceptual understanding of call admission control mechanisms is important. These mechanisms are explained in the Cisco Unified Communications SRND Based on Cisco Unified Communications Manager, available at
Gatekeeper Call Admission Control
In a pure TDM environment where Unified CVP is switching calls from an ingress gateway to an egress gateway attached to a TDM ACD/IVR, the gatekeeper can handle the call admission control functionality.
If Unified CM is the egress gateway, gatekeeper call admission control can be used only if the ingress Unified CVP gateways and the IP phones are at different sites. Note that gatekeeper dial-plan resolution is still in use.
Because Unified CM locations-based call admission control is used between the remote sites of a cluster, a gatekeeper typically is used for dial-plan resolution only. Understanding the routing of calls in the dial plan and the gatekeeper resolution is important because 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 Unified CM cluster are being used to control the remote sites. For further discussion and information on this topic, see H.323 Gatekeeper Call Routing.
Unified CM Call Admission Control
If Unified CM is sending or receiving calls from Unified CVP and there are Unified CVP gateways and IP phone agents co-located at remote sites, it is important to understand the call flows in order to design and configure call admission control correctly.
H.323 Call Flows
The gatekeeper and Unified CM do not share bandwidth usage information. Networks shared by both the gatekeeper and IP phones will have two separate call admission control mechanisms determining if there is enough bandwidth to place a call. Instead of using the gatekeeper for call admission control, it is possible to use Unified CM Locations as the call admission control mechanism for Unified CVP calls. How Unified CM determines an endpoint's location is key to designing call admission control properly.
Consider the basic call flow of a Unified CVP call versus a non-CVP call. When a user picks up an IP phone and makes a call from the remote site to the central site, Unified CM considers the location definitions of the endpoints and the codec requirements defined in the Unified CM Region configurations and decides whether or not to allow the call. Note that the call admission control and the codec requirements are controlled between these endpoints by Unified CM as the controlling call agent.
By default, Unified CM looks at the source IP address of an incoming H.323 call to determine which H.323 device is originating the call. Unified CM then uses the configuration of this device to determine its location and to perform call admission control for the call. When Unified CVP is delivering calls from a remote branch gateway to a Unified CM IP Phone, Unified CVP is in the middle of the H.323 signaling, so the source IP address from Unified CM's perspective is the Unified CVP Server. Because the Unified CVP Server is centralized along with Unified CM, it is not possible to perform call admission control based on the Unified CVP Server's IP address. Unified CM must be aware that calls arriving from Unified CVP are coming from a gateway at a specific branch so that it can calculate call admission control correctly. In order to solve this problem, Unified CVP must be configured to insert information in the payload of the H.323 SETUP message that identifies the IP address of the originating gateway, and Unified CM must be configured to look at this information when determining on which gateway an H.323 call is arriving.
This requires enabling one Unified CM service parameter and ensuring that another parameter is set to its default value:
•Change the cluster-wide service parameter Accept unknown TCP connection to True. (The default is False.)
•Ensure that the service parameter Device Name of gatekeeper trunk that will use port 1720 remains at its default setting of blank.
When set to True, the service parameter Accept Unknown TCP Connection changes the behavior for inbound H.323 calls. Unified CM accepts an unknown H.225 TCP connection and waits for the H.323 SETUP message. Unified CM then extracts the User-to-User Information Element (UUIE) and examines the sourceCallSignalAddress field, which contains the IP address of the originating gateway. Unified CM compares this address against its configured gateways. If a match is found, the call is treated as if it originated from the voice gateway and not the Unified CVP Server. The Unified CVP Server IP address must not be configured as an H.323 gateway, otherwise Unified CM will match first on the source IP address and will not look at the information in the sourceCallSignalAddress field. In order to deliver calls to Unified CM from Unified CVP without specifying Unified CVP as an H.323 gateway, you must configure an H.323 Gatekeeper Trunk in Unified CM so that Unified CVP will sends calls to Unified CM via the gatekeeper over the trunk.
The Unified CM service parameter Device Name of gatekeeper trunk that will use port 1720 is used to force a gatekeeper-controlled trunk to register to a gatekeeper on port 1720. This feature causes any inbound H323 call that is signaling on port 1720 to be treated immediately as a gatekeeper-controlled trunk call. The H.225 signaling address is not examined in this case.
This behavior is not how Unified CM traditionally treats a gatekeeper-controlled H.323 call. Typically, all gatekeeper-controlled calls come from the hub location (location None or Hub_None). These changes ensure that the call is not treated as a gatekeeper-controlled call and that locations-based call admission control is applied. Note that, in this model, if Unified CM does not match the gateway signaling address in its list of configured gateways, it rejects the call. Figure 3-1 illustrates the decision tree for H.323 call processing.
Figure 3-1 Cisco Unified CM H.323 Signaling Flow Topology
To configure Unified CVP to work correctly with Unified CM call admission control, use VBAdmin to set the Unified CVP Server parameter setlocationsbasedcac on. This setting tells Unified CVP to populate the sourceCallSignalAddress field and to use TCP port 1720 when sending calls to Unified CM.
When using this feature in conjunction with calls originated by Unified CM, the sourceCallSignalAddress populated by Unified CVP will be the IP address of Unified CM. If the call is transferred back to Unified CM, it will inspect this field and try to find a configured gateway with that IP address, but the call will fail because normally Unified CM will never be configured as a gateway. As a workaround to this problem, configure each Unified CM in the cluster as an H.323 gateway, but be sure to never configure the Unified CM dial plan to send calls using those gateways.
Multiple Cisco Unified CM Clusters
When more than one centralized Unified CM cluster are used for the remote sites, additional consideration must be given to routing calls based on agent selection. In a multi-cluster environment, each cluster manages a group of remote sites and tracks the voice calls to those sites within the locations-based call admission control mechanism. Using the changes discussed above, Unified CM considers H.323 calls within its locations-based call admission control 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 locations-based call admission control mechanism described above, it is necessary for the remote gateway to be told to signal a call to the Unified CM cluster that owns the location of that remote gateway. However, in a Unified CCE environment, Unified ICM tracks the availability of agents without considering on which cluster they are located. This ability provides great scalability for Unified CCE but must be accounted for in this type of implementation.
If a call coming in through a Unified CVP ingress gateway is destined for an IP Phone at a different site registered to a different cluster, the call must first be routed through the cluster that is handling call admission control for the ingress gateway, 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 call admission control for the ingress gateway is not aware of the call traversing the WAN and does not deduct bandwidth appropriately.
This call routing can be handled by using the SigDigits feature in Unified CVP and its associated dial-plan configuration. The SigDigits feature in Unified CVP allows you to use the dial plan on the SIP Proxy or gatekeeper to route calls to a specific Unified CM cluster. When the call arrives at an ingress gateway, the gateway will prepend digits before sending the call to Unified CVP. Those prepended digits are unique to that site from a dial-plan perspective. When the call arrives at Unified CVP, Unified CVP will strip the prepended digits and store them in memory, resulting in the original DID on which the call arrived. When Unified ICM returns a label to Unified CVP in order to transfer the call to an agent phone, Unified CVP will prepend the digits that it stored in memory before initiating the transfer. The dial-plan configuration in the SIP Proxy or gatekeeper is configured with the prepended digits so that calls with a certain prepended digit string are sent to a specific Unified CM cluster. The digits are prepended as a tech-prefix when using H.323.
For more information on how the SigDigits feature works, see Distributed VoiceXML Gateways (Separate Ingress Gateway and VoiceXML), page 4-18.
SIP Call Flows
With SIP-based call flows in Unified CVP 4.0, Cisco Unified CM 6.0 (and prior releases) is able to look at only the source IP address of the incoming SIP INVITE from Unified CVP. This limitation causes a problem with call admission control because Unified CM is not able to identify which gateway behind Unified CVP originated the call.
Cisco Unified CM 6.1 introduces a new feature that functions in a similar manner to the H.323 call flow. Cisco Unified CM 6.1 has enhanced the SIP Trunk to look beyond the source IP address and to inspect information contained in the SIP header when determining which device originated a call. More specifically, the Call-Info header in the SIP INVITE will specify the originating device in the following format:
Where IPAddress:port indicates the originating device and its SIP signaling port.
By default, Unified CVP does not populate the Call-Info header with this field. In order to configure Unified CVP to insert this information into the header, you must edit the sip.properties file to include the following line:
When using SIP with Cisco Unified CM 6.0 or prior releases and Unified CVP 4.0 deployments with remote gateways and IP phones, there will not be a fully integrated call admission control mechanism, therefore you must use one of the following mechanisms instead:
•Use H.323 as the signaling protocol.
•Deploy a Unified CVP Server at each site.
•Over-provision enough voice priority queue bandwidth so that call admission control is not needed.
Note that this limitation is not an issue for deployments that do not need call admission control, such as a campus LAN or MAN, where all of the devices are connected with high-bandwidth links.
Cisco Unified CM 5.0 introduced support for Resource Reservation Protocol (RSVP) between endpoints within a cluster. RSVP is a protocol used for call admission control and is used by the routers in the network to reserve bandwidth for calls. RSVP can be used for delivering calls to Unified CCE agents in a Unified CM cluster. Unified CM uses the RSVP Agent associated with each device in order to complete the RSVP reservation. Because Unified CM must be able to identify the originating gateway, you must use the same configuration of Unified CM for locations-based call admission control with Unified CVP. This configuration enables Unified CM to correctly identify the remote gateway and its associated RSVP agent and to complete the RSVP reservation. Because Unified CM is currently not able to identify SIP gateways behind Unified CVP, RSVP has the same limitation as locations-based call admission control with SIP.
For more information on RSVP, refer to the latest version of the Cisco Unified Communications SRND Based on Cisco Unified Communications Manager, available at
H.323 Gatekeeper Call Routing
For proper configuration of remote H.323 gateways with a Unified CM cluster, first consider the H.225 implications of this configuration without the use of gatekeeper.
When configuring dial-peer destinations for the Cisco IOS Gateways, you must configure a dial peer pointing to the IP addresses of the Unified CM servers that are processing calls for that gateway. These server IP addresses must be the same servers that are in the redundancy group of the device pool definition for that gateway in the Unified CM configuration. (See Figure 3-2.) If the remote H.323 gateway sends a call to a Unified CM server that is not in the redundancy group for that gateway, the call is rejected. For example, if the Madison gateway in Figure 3-2 sends a call to the.3 server, the call is rejected.
Figure 3-2 Dial Peer Configuration
While the example in Figure 3-2 is simple to understand, the configuration can become challenging to maintain for several hundred remote sites over an extended period of time. If the Cisco Unified CM gatekeeper redundancy group is 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 Registration Admission Status (RAS) request to the gatekeeper for an IP address to which to send the call. The gatekeeper automatically responds with one of the Unified CM server addresses defined in the redundancy group for the gatekeeper trunk. If the redundancy group is changed, Unified CM must re-register to the gatekeeper. However, no further configuration is necessary on the remote gateway.