This chapter presents deployment characteristics and
provisioning requirements of the Unified CVP network. Provisioning guidelines
are presented for network traffic flows between remote components over the WAN,
including recommendations for applying proper Quality of Service (QoS) to WAN
For the most current information on network considerations,
refer to the sections on deployment models, bandwidth, and QoS presented in the
latest version of the
Cisco Unified Contact Center Enterprise Solution Reference Network
Design (SRND), available at:
In many Unified CVP deployments, all components are centralized; therefore, there is no WAN network traffic to consider. In general, there are only two scenarios when WAN network structure must be considered in a Unified CVP environment:
In a distributed Unified CVP deployment, when the ingress gateways are separated from the Unified CVP servers by a WAN.
In Unified CVP deployments where the ingress gateway and the agent are separated over a WAN. The agent can be a TDM ACD agent or a Unified CCE agent.
Unlike Unified ICM, Unified CVP has a very simple view of QoS:
Unified CVP has no concept of a private WAN network structure. All WAN activity, when required, is conducted on a converged WAN network structure.
Unified CVP does not use separate IP addresses for high and low priority traffic.
Adequate bandwidth provisioning is an important component in the success of Unified CVP deployments. Bandwidth guidelines and examples are provided in this chapter to help with provisioning the required bandwidth.
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 Call Admission Control is to employ Locations configuration on CVP and in UCM. Refer to Enhanced Location Call Admission Control.
Voice calls consist of Real-Time Transport Protocol (RTP)
packets that contain actual voice samples. RTP packets are transmitted in the
Between the ingress PSTN gateway or originating IP phone and one of
Another IP phone, such as an agent
The destination phone might or might not be co-located with the
ingress gateway or calling IP phone, and the connection can be over a WAN or
An egress gateway front-ending a TDM ACD (for legacy ACDs or
The egress gateway might or might not be co-located with the
ingress gateway, and the connection can be over a WAN or LAN.
A VoiceXML gateway performing prompt-and-collect treatment
The VoiceXML gateway is usually the same as the
ingress gateway, but it can be different. In either case, both the ingress and
VoiceXML gateways are typically co-located (located on the same LAN). The
connection is typically over a LAN but can be over a WAN.
Between the VoiceXML gateway and the ASR or TTS server. The RTP stream
between the VoiceXML gateway and ASR/TTS server must be G.711.
CVP supports mixed G.711 and G.729 codecs in Standalone and Comprehensive SIP deployments with Cisco Unified Border Element Enterprise Edition (CUBE) and Cisco Unified Communications Manager (Unified CM). Calls that are ingressed through a SIP trunk from the carrier to a CUBE require IOS 15.1(2)T or later T for mixed codec support. You can use any combination of codecs on the legs of a call.
The solution requires significantly more bandwidth over the WAN link.
Benefits and drawbacks for G.729 codec include:
No extra bandwidth is required.
Conversion of prompts to G.729 is required.
G.729 prompts have an inferior audio quality to G.711 prompts.
ASR/TTS cannot be used.
Call control traffic
There are several types of call control traffic in a Unified
CVP solution. Call control functions include those used to set up, maintain,
tear down, or redirect calls.
Unified CVP is currently certified with three types of VoIP
endpoints: Cisco IOS voice gateways, Cisco Unified Communications Manager
(Unified CM), and the PGW in either Call Control mode or Signaling mode. Call
Control traffic flows between the following endpoints:
Ingress gateway to/from Unified CVP Call Server
The ingress gateway can be a PGW, Unified CM, or a Cisco IOS
gateway, or other SIP device in the case of SIP. The connection can be over a
WAN or LAN.
Unified CVP Call Server to or from egress gateway
The egress gateway can be Unified CM or a Cisco IOS gateway. The
egress gateway is either a VoiceXML gateway used to provide prompt-and-collect
treatment to the caller, or it is the target of a transfer to an agent (Unified
CCE or TDM) or a legacy TDM IVR. The connection can be over a WAN or LAN.
Currently approved deployment designs do not support SIP for
interoperability between the PGW and Unified CVP. If your design requires this
functionality, contact the Cisco Assessment to Quality (A2Q) team.
The Unified CVP Call Server and the Unified ICM VRU PG
communicate using the GED-125 protocol. The GED-125 protocol includes:
Messages that control the caller experience, such as notification
when a call arrives
Instructions to transfer or disconnect the caller
Instructions that control the IVR treatment the caller experiences
The VRU PG normally connects to Unified CVP over a LAN
connection. However, in deployments that use clustering over the WAN, it is
possible for Unified CVP to connect to the redundant VRU PG across the WAN.
At this time, no tool exists that specifically addresses
communications between the VRU PG and Unified CVP. However, bandwidth consumed
between the Unified ICM Central Controller and VRU PG is very similar to the
bandwidth consumed between the VRU PG and Unified CVP.
VRU Peripheral Gateway to ICM Central Controller Bandwidth
Calculator tool is available (with proper login authentication) through
the Cisco Steps to Success Portal at:
If the VRU PGs are split across the WAN, the total bandwidth
required would be double what the calculator tool reports: once for Unified ICM
Central Controller to VRU PG and once for VRU PG to Unified CVP.
Media Resource Control Protocol (MRCP)
The VoiceXML gateway communicates with ASR/TTS servers using
Media Resource Control Protocol (MRCP) v1.0 and v2 as well. This protocol currently works with
Real-Time Streaming Protocol (RTSP) to help establish control connections to
the ASR/TTS server such as Nuance. The
connection can be over the LAN or WAN.
ICM Central Controller to Unified CVP VRU PG
No tool exists that specifically addresses communications
between the Unified ICM Central Controller and the Unified CVP VRU PG. Testing
has shown, however, that the tool for calculating bandwidth needed between the
Unified ICM Central Controller and the IP IVR PG also produces accurate
measurements for Unified CVP if you perform the following substitution in one
For the field labeled
Average number of RUN VRU SCRIPT nodes, substitute the number of
Unified ICM script nodes that interact with Unified CVP. Nodes that can
interact with Unified CVP are Run External Script, Label, Divert Label, Queue
to Skill Group, Queue to Agent, Agent, Release, Send to VRU, and Translation
Route to VRU.
This bandwidth calculator tool is available (with proper login
The connection in this case can be over a WAN or LAN.
Data traffic includes VoiceXML documents and prerecorded media files returned as a result of HTTP requests executed by the VoiceXML gateway. Specifically:
The VoiceXML gateway requests media files in an HTTP request to a media file server. The media server response returns the media file in the body of the HTTP message. The VoiceXML gateway then converts the media files to RTP packets and plays them to the caller. The connection in this case can be over a WAN or LAN.
The VoiceXML gateway requests VoiceXML documents from either the Unified CVP VXML Server or the Unified CVP IVR Service. The connection in this case can be over a WAN or LAN.
This chapter focuses primarily on the types of data flows and bandwidth used between a remote ingress gateway and the components with which it interfaces:
Unified CVP VXML Server
Unified CVP Call Server IVR Service
Unified CVP Call Server SIP Service
ASR or TTS servers
Guidelines and examples are presented to help estimate required bandwidth and, where applicable, provision QoS for these network segments.
Most of the bandwidth requirements in a Unified CVP solution occur in a Distributed Unified CVP topology, due primarily to the fact that the ingress and/or VoiceXML gateway is separated from the servers that provide it with media files, VoiceXML documents, and call control signaling. For purposes of the following discussion, assume all calls to a branch begin with one minute of IVR treatment followed by a single transfer to an agent that also lasts one minute. Each branch has 20 agents, and each agent handles 30 calls per hour for a total of 600 calls per hour per branch. The call average rate is therefore 0.166 calls per second (cps) per branch.
Note that even a slight change in these variables might have a large impact on sizing. It is important to remember that .166 calls per second is an average for the entire hour. Typically, calls do not come in uniformly across an entire hour, and there are usually peaks and valleys within the busy hour. Try to find the busiest traffic period, and calculate the call arrival rate based on the worst-case scenario.
VoiceXML documents are generated based on voice application scripts written using either Unified ICM scripts or Cisco Unified Call Studio, or both. A VoiceXML document is generated for every prompt that is played to the caller. The VoiceXML documents vary in size, depending on the type of prompt being used; menu prompts with many selections are much larger than a simple prompt that simply plays an announcement.
On average, a VoiceXML document between the Unified CVP Call Server or Unified CVP VXML Server and the gateway is about 7 kilobytes. You can calculate the bandwidth used by approximating the number of prompts that will be used per call, per minute. The calculation, for this example, is as follows:
7,000 bytes * 8 bits = 56,000 bits per prompt
(.166 call/second) * (56,000 bit/prompt) * (# of prompts / call) = bps per branch
However, if you are going to use a more complex application that uses many menu prompts (more than the average estimated above) or if you want to calculate the bandwidth more exactly, you can use the VoiceXML document sizes listed in the following table to calculate the amount of bandwidth needed. The document sizes in the following table are measured from the Unified CVP VXML Server to the VoiceXML Gateway.
Table 1 Approximate Size of VoiceXML Document Types
VoiceXML Document Type
VoiceXML Document Size (approximate)
Root document (one required at beginning of call)
Subdialog_start (at least one per call at beginning of call)
Query gateway for Call-ID and GUID (one required per call)
Menu (increases in size with number of menu choices)
1,000 bytes + 2,000 bytes per menu choice
Play announcement (simple .wav file)
Cleanup (one required at end of call)
(prompts) can be stored locally in flash memory on each router. This method
eliminates bandwidth considerations, but maintainability becomes an issue
because a prompt that requires changes must then be replaced on every router.
If the prompts are instead stored on an HTTP media server (or an HTTP cache
engine), the gateway can locally cache voice prompts once it has initially
retrieved the prompts. If configured correctly, the HTTP media server can cache
many, if not all, prompts, depending on the number and size of the prompts. The
refresh period for the prompts is defined on the HTTP media server. Therefore,
the bandwidth utilized would be limited to the initial load of the prompts at
each gateway, plus periodic updates after the expiration of the refresh
prompts at the gateway causes significant Cisco IOS performance degradation (as
much as 35% to 40%) in addition to the extra bandwidth usage. For the most
current information on configuring gateway prompt caching, refer to the latest
version of the
Guide for Cisco Unified Customer Voice Portal (CVP), available at:
(20,000,000 bits) /
(900 secs) = 22.2 average kbps per branch
SIP is a text-based protocol. The typical SIP call flow uses about 17,000 bytes per call. Using the previous bandwidth formulas based on calls per second, the average bandwidth usage would be:
(17,000 bytes/call) * (8 bits/byte) = 136,000 bits per call
(0.166 calls/second) * (136 kilobits/call) = 22.5 average kbps per branch
ASR and TTS
ASR or TTS cannot use silence suppression and must use the G.711 codec.
ASR and TTS in WAN Configurations
Cisco does not test or qualify speech applications in WAN environment. For guidelines on design, support over WAN and associated caveats, see the vendor specific documentation.
TAC will be providing limited support (as in the case of any third party interoperability certified products) on issues related to speech applications.
ASR or TTS is bandwidth intensive. ASR or TTS RTP and MRCP traffic is not tagged with QoS DSCP markings, therefore it is necessary to use access control lists (ACLs) to classify and re-mark the traffic at the remote site and central site.
Classifying RTP Media Traffic Between VoiceXML Gateways and
ASR or TTS Servers
The RTP port range used by the VoiceXML gateway is the normal
Cisco IOS RTP UDP port range of 16384 to 32767; however, the RTP UDP port range
used by the ASR or TTS server can vary by OS and ASR or TTS vendor. Itis possible to
construct an ACL to match the traffic from the ASR or TTS server based on the
VoiceXML gateway UDP port range; but if possible, Cisco recommends finding the
ports used by the ASR or TTS server as well. The RTP traffic should be marked with
DSCP EF so that it is placed in the priority queue with other voice traffic.
The QoS priority queue must also be configured to support the
maximum number of ASR or TTS sessions anticipated. If a call admission control
mechanism such as Cisco Unified CM locations or Resource Reservation Protocol
(RSVP) is used, this extra priority queue bandwidth should not be included when
configuring the locations or RSVP bandwidth. For example, if you want to
support two ASR or TTS G.711 sessions (80 kbps each) as well as four IP telephony
phone calls using G.729 (24 kbps each), the priority queue total bandwidth
would be 256 kbps. The locations call admission control or RSVP bandwidth
should be limited to only the IP telephony bandwidth (96 kbps in this example).
Configuring the locations or RSVP bandwidth with 256 kbps would allow IP
telephony calls to use all of the bandwidth and conflict with the ASR or TTS
Classifying MRCP Traffic Between VoiceXML Gateways and
ASR or TTS Servers
The MRCP traffic is much easier to classify. ASR or TTS servers
listen on TCP 554 for MRCP requests, therefore this port should be used in ACLs
to classify the traffic. The bandwidth used by MRCP can vary depending on how
often the application uses the ASR or TTS resource. MRCP uses about 2000 bytes per
interaction. If there is an ASR or TTS interaction every 3 seconds per call, you
can calculate the average bandwidth as follows:
(2000 bytes/interaction) * (20 interactions/minute) * (8 bits/byte) =
320,000 bits per minute per call
(320,000 bits per minute) / (60 seconds/minute) = 5.3 average kbps per
If you configure a maximum of 6 ASR or TTS sessions at any given
time, then (6 * 5.3 kbps) = 32 average kbps per branch.
Limiting the Maximum Number of ASR or TTS-Enabled Calls
It is possible to limit the number of calls enable for ASR or TTS
so that, once the limit is reached, regular DTMF prompt-and-collect can be used
instead of rejecting the call altogether. In the following example, assume
5559000 is the ASR or TTS DNIS and 5559001 is the DTMF DNIS. You can configure the
ingress gateway to do the ASR load limiting for you by changing the DNIS when
you have exceeded maximum connections allowed on the ASR or TTS VoIP dial peer.
voice translation-rule 3 rule 3 /5559000/ /5559001/
voice translation-profile change
translate called 3
!Primary dial-peer is ASR or TTS enabled DNIS in ICM script
dial-peer voice 9000 voip
!As soon as 'max-conn' is exceeded, next preferred dial-peer will change
the DNIS to a DTMF prompt & collect ICM script
dial-peer voice 9001 voip
translation-profile outgoing change
80 kbps is the rate for G.711 full-duplex with no VAD, including
IP/RTP headers and no compression. 24 kbps is the rate for G.729 full-duplex
with no VAD, including IP/RTP headers and no compression. For more information
on VoIP bandwidth usage, refer to the
Voice Codec Bandwidth Calculator (login authentication
required), available at
G.711 and G.729 voice traffic
Unified CVP can support both G.711 and G.729. However, both
call legs and all IVR on a given call must use the same voice codec. If you are
using ASR/TTS for speech recognition, then G.711 must be used because ASR or TTS
servers support only G.711. For the most current bandwidth information on voice
RTP streams, see the latest version of the
Cisco Unified Communications SRND Based on Cisco Unified
Communications Manager, available at:
Call admission control is the mechanism for determining if
there is enough bandwidth available on the network to carry an RTP stream.
Unified CM can use its own locations mechanism or RSVP to track bandwidth
between the ingress gateway and destination IP phone locations.
Reservation Protocol (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 Call Admission Control 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:
When you are
using the Unified CVP intra-cluster Enhanced Location CAC model deployment, you
must control the number of calls that go over the WAN link to branch offices.
The decision to admit calls is based on the CAC computations which represent
the bandwidth used by the call. These computations are valid whether the calls
are IP calls between two phones within Cisco Unified Communications Manager ,
calls over SIP trunks, or calls originated from TDM-IP GW.
queue-at-the-edge functionality, the call originating from a specific branch
office must be routed to a local Unified CVP VXML Gateway based on priority.
That is, always choose a local branch agent if possible.
following diagram illustrates a typical branch office deployment.
You can deploy Unified CVP in a single cluster Unified CM deployment to provide queue-at-the-edge functionality. In this deployment model, branch-located ingress gateways are typically used to allow callers access using local phone numbers rather than centralized or non-geographic numbers. This consideration 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 (ACDs) into the CVP switching solution. Apart from the gateways all other CVP components are centrally located and WAN links provide data connectivity from each branch location to the central data center. (Although the media server is centrally located, commonly used VRU media is cached at the local branch.)
In the Unified CVP branch office deployment model using queue-at-the-edge, the only equipment at the branch office is an ingress gateway (optionally acting as a VoiceXML gateway as well), IP phones for Unified CCE agents, IPT (user) phones, and agent desktops.
You can configure Unified CCE Skill Groups, dial plans and routing priorities so that callers who ingress at one branch are connected by preference to agents who are located at the same branch. In these cases, the RTP traffic flows directly from ingress gateway to IP phone, and does not need to traverse the WAN (although signaling and data may traverse the WAN).
The goal of this model is to first route the calls locally to an agent available in the branch office, if possible, and keep the media streams local. If the local agent is not available, only the call gets routed to the agent on another branch office over the WAN link; the originating call and the initial VRU treatment are done locally.
Another advantage of this deployment configuration is that in the event of WAN link failure, the call can still be routed locally using the CVP survivability application running on the pots dial-peer for TDM originated calls.
following definitions are important to the ELCAC feature:
Phantom Location: A
default location with unlimited bandwidth used when calculating calls that are
hairpinned over a SIP trunk or when the SIP call is queued at the local branch,
to enable correct bandwidth calculations. The Phantom location should be
assigned to the gateway or trunk for CVP.
siteID: The siteID is a
string of numbers that is appended to the label from Unified ICM so that the
dial plan can be configured to route the call to a specific destination, such
as the branch VXML gateway or egress gateway, or UCM node. The siteID can be
appended at the front of the label, at the end, or not at all. This
configuration is separate from the Unified CM location configuration, and is
specific to Unified CVP. The siteID is used to indicate the real location of
the call and allow the bandwidth to be deducted from the correct location.
siteID is unique across multiple Unified CM clusters. Multiple siteIDs can
still route to the same branch office (if needed) by mapping the unique siteIDs
to same branch gateways in proxy routes.
Shadow Location: This new
location is used for inter-cluster trunks between two Cisco Unified
Communications Manager clusters. This location is not used as inter-cluster
ELCAC is not supported in Unified CVP.
Importance and comparison of Enhanced Location Call Admission Control Feature
The Enhanced Location Call Admission Control (ELCAC) Feature addresses two important issues with the prior CAC feature:
Bandwidth miscalculations in CAC with IP originated callers, as well as with any post transfers from agents.
Inability to deterministically select a local VXML GW for VRU treatment at the branch office during warm transfers from an agent due to no correlation between the two calls at consult.
Comparing ELCAC to the OrigIP Trunk feature on Unified CM:
Before Unified CM implemented the phantom trunk and siteID feature for bandwidth calculation, there was the existing feature used by Unified CVP that enabled the correct trunk to be selected depending on the original IP of the caller. This feature enabled Unified CM to select to the correct trunk for the TDM gateway, instead of only using the single Unified CVP trunk, and it only applies to incoming calls on the trunk. With this feature, distinct SIP profiles and trunk settings could be used for each branch gateway without being limited to the settings of the single Unified CVP trunk. This feature has no impact on bandwidth calculations.
Router Requery with ELCAC
When a call is rejected by the UCM due to not enough bandwidth, a SIP message 488 Not Acceptable Here is returned to Unified CVP, where it triggers a router requery over the GED-125 interface to the VRU peripheral, and the UCCE Router may return another agent label if requery is configured properly.
following considerations apply when using ELCAC:
The SIP trunk
configured between Unified CVP and Unified CM should be associated with Phantom
location. A new location called shadow location is added in Unified CM 9.0 for
inter cluster ELCAC, but it is not supported in Unified CVP.
A trunk configured
with MTP required will not work with the ELCAC siteID feature. The reason is
when MTP is inserted, the media is terminated between the end point and MTP
resource, not between the two end points.
MTP/Transcoder/TRP media resource is inserted by the Unified CM media layer,
the incoming location information is not used.
If the inter
cluster call is not looped back to the same cluster, the former behavior of
Location CAC logic will apply.
Each site is
uniquely identified by one siteID. Multiple gateways at the same site would
need to align to the same siteID, but if two clusters happen to use the same
location name, then two siteIDs can map to the same physical branch.
A second Unified
CM cluster may have the same location as the first cluster, but be required to
use a unique siteID on Unified CVP. You can define a route in the proxy server
to send those cluster calls to the common VXML gateway at the same location,
but used by both the clusters.
Each cluster would
manage the bandwidth for devices in its cluster. If two clusters happen to use
the same physical location, then they would each separately manage the
bandwidth for the phones that they manage.
High availability and failover
The following considerations apply when using LBCAC:
During the CAC failure, Unified CVP returns a failure code to Unified CCE that triggers router requery.
If a branch doesn't have a VXML Gateway, then it is recommended to use the VoiceXML Gateway at the Central data center.
version of Unified CVP provided a method of configuring CAC. This method is
superseded by the ELCAC method presented here. Both configuration methods are
provided in the
Guide for Cisco Unified Customer Voice Portal (CVP), available at:
The Unified CVP Call Server marks only the QoS DSCP for SIP messages. If QoS is needed for Unified CVP signaling and data traffic across a WAN, configure network routers for QoS using the IP address and ports to classify and mark the traffic as recommended in the following table.
Neither the CVP-Data queue nor the Signaling queue is a priority queue as described in Cisco IOS router terminology. The priority queue is used for voice or other real-time traffic, while call signaling and Unified CVP traffic are reserved a certain amount of bandwidth based on the call volume.
Table 2 Recommended port usage and QoS settings
Maximum Latency (Round Trip)
Unified CVP Call Server, SIP
TCP or UDP 5060
Unified CVP IVR Service
Unified CVP VXML Server
Ingress Gateway, SIP
TCP or UDP 5060
VoiceXML Gateway, SIP
TCP or UDP 5060
SIP Proxy Server
TCP or UDP 5060
application bandwidth and QOS policies are in place, another important
consideration in a distributed CVP deployment is that of network latency. With
sufficient network bandwidth, the primary contributor to latency is distance
between the VoiceXML gateway and the Call Server or VXML Server.In distributed
CVP deployments, it is important to minimize this latency and to also
understand its effect on solution performance.
effect of network latency between CVP components is on the end user calling
experience. Call signaling latency, with SIP, between the CVP Call Servers and
voice gateways affects the call setup time and may add a period of silence
during this setup. This includes the initial call setup and subsequent
transfers or conferences that are part of the final call flow. VoiceXML
application document download time is also significantly affected by network
latency and will have a pronounced effect on the ultimate caller experience.
recommendations are defined below to help minimize the effect of geographic
separation of VXML gateway from CVP VXML Server. However, in some cases
depending on the business needs of the customer callflows, it may still be
necessary to co-locate the CVP VXMLServer with the remote VXML gateways.
makes heavy use of the HTTP protocol to transfer VoiceXML documents and other
media files that are ultimately played to the caller. For the best end user
calling experience, this HTTP traffic should be treated with a priority higher
than that of normal HTTP traffic in an enterprise network. The recommendation
is to treat this HTTP traffic the same as CVP call signaling traffic if
possible. Measures that may be used to work around latency issues include
moving the VXML Server to the same local area as the VoiceXML gateway, or using
Wide Area Application Services (WAAS).
system configuration changes listed in the following bullets can help with WAN
Provide audio to
the caller during periods of silence
following settings provide ringback and audio during times of dead air so that
the caller does not disconnect.
survivability service, the setting for
"wan-delay-ringback" can be set to 1 to add a ringback tone
during longer than normal call setup times with IVR.
settings for IVR.FetchAudioDelay and IVR.FetchAudioMinimum are added. They are
WAN Delay settings for when root doc fetch is delayed over the WAN link.
value for IVR.FetchAudio as follows: IVR.Fetchaudio= flash:holdmusic.wav. Leave
the default empty so that nothing will be played in a normal scenario.
A default setting of 2 is
needed to avoid a blip sound in a normal network scenario.
WAN Delay to zero will have the effect of immediately playing holdmusic.wav and
then playing it for a minimum of 5 seconds.
variables such as user.microapp.fetchdelay, user.microapp.fetchminimum and
user.microapp.fetchaudio may be used to override these values in between
invocations of getSpeechExternal microapps.
Enable Path MTU
Discovery on the VoiceXML gateways
VoiceXML gateways, add the following command: ip tcp path-mtu-discovery
Discovery is a method for maximizing the use of available bandwidth in the
network between the endpoints of a TCP connection.
trips between the VXML Server and the ICM script
control is passed from a running VXML Server application back to the ICM
script, you incurr a significant WAN delay.
VXML Server application starts executing, the best practice is to minimize the
number of trips back to the ICM script. Each round trip between the VXML Server
and the ICM script incurs delay due to establishing two new TCP connections and
HTTP retrieval of several VoiceXML documents, including the VXML Server root
Decrease the size
of the VXML Server root document.
VXML Server, in your specific gateway adapter plugin.xml file:
example, the location of the plugin.xml file for the CISCO DTMF 1 GW adapter
TCP/UDP ports used
by Unified CVP, voice, and VoiceXML gateways
configuring network security using firewalls or ACLs, see the following table
for information about TCP/UDP ports used by Unified CVP, voice gateways,
VoiceXML gateways. For a complete listing of ports used by Unified CVP, see the
Port Utilization Guide.
Unified CVP Operations Console Server uses dynamic ports for communication with
other components, it cannot be deployed outside of a firewall while the rest of
the Unified CVP components reside inside the firewall.
Table 3 TCP/UDP Ports
Used by Unified CVP, Voice Gateways, and VoiceXML Gateways
Source and Destination Component
Voice Gateway to Media Server
Voice Gateway to Unified CVP Call Server SIP
TCP or UDP 5060
Voice Gateway to Unified CVP Call Server
TCP 8000 (non-SSL); TCP 8443 (SSL)
Voice Gateway to Unified CVP VXML Server
TCP 7000 (non-SSL); TCP 7443 (SSL)
Voice Gateway to MRCP V1 (RTSP) Server
Voice Gateway to MRCP V2 (SIP) Server
Unified CVP Call Server to Egress Voice Gateway SIP