In a distributed deployment, the ingress gateways are
geographically separated from the Unified CVP Call Server. This chapter
discusses how these types of deployments are designed as well as how to
handle call survivability and call admission control.
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 disadvantage of this method is that each NetworkVRU requires its own VRU scripts in Unified ICM. The Unified ICM configuration becomes a significant amount of work when you make a change to each Network VRU script.
Configure Unified CVP using the SigDigits feature.
The SigDigits feature in Unified CVP allows you to use the dial plan on the SIP Proxy to route calls to the correct site. When the call arrives at an ingress gateway, the gateway prepends digits before sending the call to Unified CVP. Those prepended digits are unique to that site for a dial-plan.
When the call arrives at Unified CVP, Unified CVP strips the prepended digits and stores 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 and 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 prepends the digits that it stored in memory before initiating the transfer. The dial plan in the SIP Proxy 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.
It is important to remember that when the Voice XML gateway receives the call, the CVP bootstrap service is configured to strip the digits again, so that when the IVR leg of the call is set up, the original DN is used on the incoming Voiced XML request. Note that digits can be prepended to translation route DNs, and that the egress or receiving component (such as Unified CM) may need to strip digits to see the original DN.
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 it is called Prepend Digits for SIP in the Operations Console.
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 Unified CVP VXML servers and gateways
Either all gateways and servers are centralized or each site has its own set of co-located Unified CVP VXML 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 Unified CVP VXML Servers are required when using replicated branch offices.
There is additional overhead when deploying applications to multiple Unified CVP VXML Servers.
Gateways at the
Branch with Centralized Unified CVP VXML Server
reporting are centralized.
VXML Server capacity can be shared among branch offices.
of centralized VoiceXML:
survivability is limited.
WAN bandwidth must
be sized for additional VoiceXML over HTTP traffic.
Cisco Unified Communications Manager
In a Unified CVP environment, 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, queued by Unified CVP, and then 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.
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. Therefore, Unified CM sees the call as coming from the centralized Unified CVP Call Server rather than from the remote ingress gateway.
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. A 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.
Multicast Music-on-Hold (MOH)
Multicasting may be used for Music-on-Hold with supplementary
services on Unified CM as an alternative to the unicast MOH. There are two ways
to deploy using this feature:
With Unified CM multicasting the packets on the local LAN
With the branch gateway multicasting on their local LAN
Use the latter method when survivable remote site
telephony (SRST) is configured on the gateway. This method enables the deployment to
use MOH locally and avoid MOH streaming over the WAN link.
References for Using Multicast MOH
Refer to the following for configuring MOH on the Call Manager
considerations apply when using Multicast MOH:
Do not set
modem passthrough nse codec g711ulaw
globally, or on a dial peer on the ingress or egress gateway. This
setting may cause Unified CM to stop the MOH after a timeout period of 10-12
Do not set media
inactivity on the ingress gateway, because multicast MOH does not send RTP or
RTCP, so the call may get disconnected due to media inactivity configuration.
The setting media inactivity criteria does not support multicast traffic.
Multicast MOH is not supported on the 5400 platform since ccm-manager-based MOH
subsystems are not supported on 5400 platform. This limitation also includes
the ability of a TDM caller to hear multicast packets broadcasted from the
Unified CM MOH server.
in distributed deployments
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 or egress of the regular non-ACD phone calls.
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
survivability must be considered for both the Unified CVP and non-CVP calls.
For the Unified CM endpoint phones, survivability is accomplished using a
Cisco IOS feature known as Survivable Remote Site Telephony (SRST). For further
details on SRST, see the latest version of the
Communications SRND Based on Cisco Unified Communications Manager,
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 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
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,
see the Cisco Unified Communications SRND based on Cisco Unified Communications
and Recording Servers do not send Real-Time Control Protocol (RTCP) packets in
reverse direction toward the caller (TDM Voice Gateway), and this could falsely
trigger the media-inactivity timer of the survivability script. It is important
to apply the survivability.tcl script carefully to the dial-peers because a
call might drop if it goes to the voice mail or to a recording element. One
method is to use a separate dial-peer for voice mail or recording calls, and do
not associate the Unified CVP survivability script for those dial-peers.
Another method is to disable the media-inactivity on the survivability script
associated with the voice mail or recording dial-peers.
To take advantage of
alternate routing upon signaling failures, you must use the survivability
service on all gateways pointing to Unified CVP. Always use this service,
unless you have a specific implementation that prevents using it.
Router requery is
not supported when using SIP REFER with Unified CVP Comprehensive Call Flow
when the survivability service is handling the REFER message from Unified CVP.
Router requery with REFER can be supported in other call flows when IOS is
handling the REFER without the survivability service, or else Unified CM is
handling the REFER. For third-party SIP trunks, the support of router requery
with REFER is dependent on their implementation and support for SIP REFER.
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 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 is which call admission control mechanisms are in
place on the network so that the same call admission control mechanism is used 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 two call admission control mechanisms that can be
used in a Unified CVP environment: Unified CM Locations, and Unified CM RSVP Agent. In a single-site deployment,
call admission control is not necessary.
The 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:
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.
With SIP-based call flows, Cisco Unified CM Release 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.
You can use the SIP trunk feature to look beyond the source IP address and to inspect information contained in the SIP header, when determining which device originated a call. This enhancement allows the
SIP trunk to be dynamically selected by the original source IP address rather
than the remote port on Unified CVP. The SIP profiles and
settings can be used on the source trunks that are different from the Unified
More specifically, the Call-Info header in the SIP INVITE will
specify the originating device in the following format:
IPAddress:port indicates the originating device and its SIP
This source IP SIP trunk selection feature does not impact the
bandwidth monitoring for call admission control. In Unified CM,
bandwidth monitoring is performed with SIP using locations configuration on
Unified CVP and Unified CM. The following header is used by the location server
in Unified CM to manipulate bandwidth information for call admission control.
RSVP is a protocol used for call admission
control, and it is used by the routers in the network to reserve bandwidth for
calls. RSVP is not qualified for call control signaling via the Unified CVP
Call Server in SIP. The recommended solution for CAC
is to employ Locations configuration on Unified CVP and in Unified CM.
For more information on RSVP, see the latest version of
Cisco Unified Communications SRND Based on Cisco Unified
Communications Manager, available at: