In a Unified CVP environment, group WAN and LAN traffic into voice traffic, call control traffic, and data traffic.

CVP supports mixed G.711 and G.729 codecs in Standalone and Comprehensive SIP deployments with Cisco Unified Border Element Enterprise Edition and Cisco Unified Communications Manager (Unified CM). Calls that are ingressed through a SIP trunk from the carrier to a Cisco Unified Border Element Enterprise Edition require Cisco Release 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.

For more information on use of mixed codecs in a Unified CVP deployment, see Mixed G.729 and G.711 Codec Support.

A Unified CVP solution has several types of call control traffic. Call control functions are to set up, maintain, tear down, or redirect calls.

Unified CVP works in Call Control mode or Signaling mode with three types of VoIP endpoints: Cisco IOS Voice Gateways, Cisco Unified Communications Manager, and Peripheral Gateway. Call Control traffic flows between the following endpoints:

• Ingress Gateway and the Call Server

  The Ingress Gateway can be a Peripheral Gateway, Unified Communication Manager, a Cisco IOS Voice Gateway, or another SIP device. The connection can be over a WAN or a LAN.

• Call Server and Egress Gateway

  The Egress Gateway can be Unified Communication Manager or a Cisco IOS Voice Gateway. The Egress Gateway is either a VoiceXML Gateway that is 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.

  Note	Deployment designs do not support SIP for interoperability between the Peripheral Gateway and Unified CVP. If your design requires this functionality, contact the Cisco Assessment to Quality (A2Q) team.

Media Resource Control Protocol

The VoiceXML Gateway communicates with ASR/TTS Servers using Media Resource Control Protocol (MRCP) v1.0 and v2 only with IOS Voice Gateway. This protocol establish connections to the ASR/TTS Server, such as Nuance. The connection can be over LAN or WAN.

Note

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 provide limited support (as in the case of any third-party interoperability certified products) on issues related to speech applications.

Data traffic includes VoiceXML documents and prerecorded media files that are returned as a result of HTTP requests. VoiceXML Gateway executes the following requests the following:

• Media files in an HTTP request to a Media File Server—The Media File Server response returns the media file in the body of the HTTP message. The VoiceXML Gateway then converts the media files to Real-Time Transport Protocol (RTP) packets and plays them to a caller. The connection can be over a WAN or a LAN.

• VoiceXML documents from the CVP Server—In this case, the connection can be over a WAN or a LAN.

  Note	CVP Server includes VXML Server and CVP IVR service.

The data flows and bandwidth are used between a remote Ingress Gateway and the components for which bandwidth is required. These components are listed as follows:

• VXML Server

• Call Server IVR service

• Call Server SIP service

• IP phones

• Media Servers

• Egress Gateways

• ASR or TTS Servers

• Cisco VVB

A VoiceXML document is generated for every prompt that is played to the caller. This document is generated based on voice application scripts that you write using either Unified ICM scripts or Cisco Unified Call Studio, or both. A VoiceXML document varies in size, depending on the type of prompt being used. For example, menu prompts with multiple selections are larger in size than prompts that play announcements only.

Note	The approximate size of a VoiceXML document for a Call Server or a VXML Server and the gateway is 7 kilobytes.

You can calculate bandwidth in the following ways:

• Estimated bandwidth—Calculate the estimated bandwidth for the number of prompts that are used per call per minute. For example, consider a VoiceXML document of 7 kilobytes and perform the following calculation:

  7,000 bytes * 8 bits = 56,000 bits per prompt

  (0.166 calls/second) * (56,000 bits/prompt) * (Number of prompts / call) = bps per branch

• Exact Bandwidth—Use the VoiceXML document sizes listed in the following table to calculate the required bandwidth. The document sizes in the following table are measured from the VXML Server to the VoiceXML Gateway.

  Table 2. Approximate Size of VoiceXML Document Types

  VoiceXML Document Type	VoiceXML Document Size (approximate)
  Root document (one required at beginning of call)	19,000 bytes
  Subdialog_start (at least one per call at beginning of call)	700 bytes
  Query gateway for Call-ID and GUID (one required per call)	1300 bytes
  Menu (increases in size with number of menu choices)	1000 bytes + 2000 bytes per menu choice
  Play announcement (simple .wav file)	1100 bytes
  Cleanup (one required at end of call)	4000 bytes

  Note	You can calculate exact bandwidth of VoiceXML document types if you use a complex application that uses multiple menu prompts.

You can store media files also referred as prompts, locally in flash memory for IOS Voice Gateway and file system for Cisco VVB on each router. Storing them locally eliminates bandwidth considerations. However, it is difficult to maintain these prompts because a prompt that requires changes must be replaced on every router. If these prompts are stored locally on an HTTP media server (or an HTTP cache engine), the gateway can locally cache voice prompts after it retrieves the prompts. An HTTP media server can cache multiple prompts, depending on the number and size of the prompts. The refresh period for the prompts is defined on the HTTP media server. The utilized bandwidth is limited to the initial load of the prompts at each gateway, including the periodic updates after the expiration of the refresh interval.

Not caching prompts at the VoiceXML Gateway causes significant Cisco IOS performance degradation, 35 percent to 40 percent approximately, in addition to the extra bandwidth usage. For information on configuring gateway prompt caching, see Configuration Guide for Cisco Unified Customer Voice Portal at http://www.cisco.com/en/US/products/sw/custcosw/ps1006/products_installation_and_configuration_guides_list.html.

For 50 prompts with an average size of 50 KB and a refresh interval of 15 minutes, the bandwidth usage is:

(50 prompts) * (50,000 bytes/prompt) * (8 bits/byte) = 20,000,000 bits

(20,000,000 bits) / (900 second) = 22.2 average kbps per branch

SIP is a text-based and signaling communications protocol that is used to control multimedia communication sessions, such as voice and video calls over Internet Protocol (IP) networks. It is also used to create, modify, and terminate sessions consisting of one or several media streams. These sessions include Internet telephone calls, multimedia distribution, and multimedia conferences. SIP can be used for two-party (unicast) or multiparty (multicast) sessions.

A 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 is:

(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 in WAN Configurations

Note

Cisco does not test or qualify speech applications in a WAN environment. For guidelines on design, support over WAN, and associated caveats, see the vendor-specific documentation. The Cisco Technical Assistance Center provides limited support (as in the case of any third-party interoperability-certified products) on issues related to speech applications.

Limiting the Maximum Number of ASR or TTS-Enabled Calls

You can limit the number of calls enabled for ASR or TTS so that as soon as 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 exceed maximum connections allowed on the ASR or TTS VoIP dial peer.

Note	Cisco VVB does not support this feature.

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
 max-conn 6
 preference 1
 destination-pattern 55590..
 ...
!
!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
 preference 2
 destination-pattern 55590..
 ...
!

Note

80 kbps is the rate for G.711 full-duplex with no Voice activity detection, including IP/RTP headers and no compression. The rate for G.729 full-duplex with no VAD is 24 kbps, including IP/RTP headers and no compression. For information on VoIP bandwidth usage, see Voice Codec Bandwidth Calculator at http://tools.cisco.com/Support/VBC/do/CodecCalc1.do.

Unified CVP supports both G.711 and G.729 codecs. However, both call legs and all IVRs on a given call must use the same voice codec. To use ASR/TTS for speech recognition, use G.711 codec because ASR/TTS server supports G.711 only. For information on voice RTP streams, see Cisco Unified Communications SRND Based on Cisco Unified Communications Manager, at http://www.cisco.com/c/en/us/support/unified-communications/unified-communications-manager-callmanager/products-implementation-design-guides-list.html.