-
Cisco Unified Customer Voice Portal (CVP) Solution Reference Network Design (SRND) Release 9.0(1)
-
Preface
-
Unified CVP architecture
-
Functional deployment models
-
Distributed deployments
-
Unified CVP design for high availability
-
Cisco Unified ICM interactions
-
Calls originated by Cisco Unified Communications Manager
-
Gateway options
-
Unified CVP VXML server design implications
-
Network infrastructure considerations
-
Call transfer options
-
Media file options
-
Managing, monitoring, and reporting functions
-
Sizing
-
Index
-
Feedback
Contents
- Gateway options
- New or changed chapter information
- PSTN gateway
- VoiceXML gateway with DTMF or ASR/TTS
- VoiceXML and PSTN Gateway with DTMF or ASR/TTS
- Cisco Integrated 3G-H324M gateway
- Gateway topology and call flow
- CVP configuration
- TDM interfaces
- Cisco Unified Border Element
- Mixed G.729 and G.711 codec support
- Gateway choices
- Gateway sizing
- Using MGCP gateways
Gateway options
Cisco offers a large range of voice gateway models to cover a large range of requirements. Many, but not all, of these gateways have been qualified for use with Unified CVP. For the list of currently supported gateway models, always check the latest version of the Hardware and System Software Specification for Cisco Unified CVP (formerly called the Bill of Materials), available at:
Gateways are used in Unified CVP for conversion of TDM to IP and for executing VoiceXML instructions. The following sections help you determine which gateways to incorporate into your design:
- New or changed chapter information
- PSTN gateway
- VoiceXML gateway with DTMF or ASR/TTS
- VoiceXML and PSTN Gateway with DTMF or ASR/TTS
- Cisco Integrated 3G-H324M gateway
- TDM interfaces
- Cisco Unified Border Element
- Mixed G.729 and G.711 codec support
- Gateway choices
- Gateway sizing
- Using MGCP gateways
New or changed chapter information
PSTN gateway
In this type of deployment, the voice gateway is used as the PSTN voice gateway. The voice gateway is responsible for converting TDM speech to IP and for recognizing DTMF digits and converting them to RFC2833 events.
NoteUnified CVP does not support passing SIP-Notify DTMF events.
In a centralized Unified CVP deployment, you can separate the VoiceXML functionality from the ingress gateway to provide a separate PSTN ingress layer. The separate PSTN layer and VoiceXML farm enables the deployment to support a large number of VoiceXML sessions and PSTN interfaces. For example, the Cisco AS5400XM can accept a DS3 connection, providing support for up to 648 DSOs. However, a gateway that is handling that many ingress calls cannot also support as many VoiceXML sessions. In such cases, the VoiceXML sessions should be off-loaded to a separate farm of VoiceXML-only gateways.
NoteAny TDM interface can be used as long as it is supported by the Cisco IOS gateway and by the Cisco IOS version compatible with CVP.
VoiceXML gateway with DTMF or ASR/TTS
A standalone VoiceXML gateway is a voice gateway with no PSTN interfaces or DSPs. The VoiceXML gateway enables customers to interact with the Cisco IOS VoiceXML Browser via DTMF tones or ASR/TTS. Because the gateway does not have PSTN interfaces, voice traffic is sent via Real-Time Transport Protocol (RTP) to the gateway, and DTMF tones are sent via out-of-band RFC2833 events.
A voice gateway deployment using VoiceXML with DTMF or ASR/TTS, but no PSTN, enables you to increase the scale of the deployment and support hundreds of VoiceXML sessions per voice gateway.
In a centralized Unified CVP deployment, you could use a VoiceXML farm. For example, if you want to support 300 to 10,000 or more VoiceXML sessions, possible voice gateways include the Cisco AS5350XM gateway. The standalone AS5350XM can support many DTMF or ASR/TTS VoiceXML sessions per voice gateway. In addition, Cisco recommends that you stack the AS5350XM gateways to support large VoiceXML IVR farms. However, for better performance and higher capacity, and to avoid the need for stacking, you can use the 3945 or 3945-E series gateways. See Table 1.
In a distributed Unified CVP deployment, consider providing an extra layer of redundancy at the branch office. You can deploy a separate PSTN gateway and a VoiceXML gateway to provide an extra layer of redundancy. In addition, for a centralized Cisco Unified Communications Manager deployment, you must provide support for Survivable Remote Site Telephony (SRST). The Cisco 2800 Series and 3800 Series and the newer 2900 Series and 3900 Series routers are the best choices for the voice gateway because they support SRST.
For a discussion on the advantages and disadvantages of each codec, See Voice traffic.
VoiceXML and PSTN Gateway with DTMF or ASR/TTS
The most popular voice gateway is the combination VoiceXML and PSTN Interface Gateway. In addition, for a centralized Cisco Unified CM deployment, you must provide support for Survivable Remote Site Telephony (SRST). The Cisco 2800 Series and 3800 Series and the newer 2900 Series and 3900 Series routers are the best choices for the voice gateway because they support SRST.
Cisco Integrated 3G-H324M gateway
The Cisco Integrated 3G-324M Gateway - or Video Gateway - allows multimedia communications (H.324M) between 3G (third generation) mobile handsets and Cisco AS5xxx Universal Gateways. For more information on Cisco Integrated 3G-324M Gateway see http://www.cisco.com/en/US/docs/video/milticomm/3g324m.html.
Gateway topology and call flow
The following figure displays the topology and call flow for the Cisco Integrated 3G-H324M Gateway call flow model.
The call flow shown in the previous figure is as follows:
- A new call arrives from the PSTN network to Unified CVP.
- The new call is sent from Unified CVP to Unified CCE.
- Call is sent from Unified CCE to Unified CVP/VRU.
- Unified CVP sends the call to the VXML Gateway. The caller hears audio IVR.
- The Agent becomes available. Unified CVP connects the video caller to the video agent.
- Caller-Agent video conversation begins.
CVP configuration
For information on configuring Unified CVP for this feature, see the Unified CVP Configuration and Administration (CAG) Guide which you can locate from this link: http://www.cisco.com/en/US/products/sw/custcosw/ps1006/products_installation_and_configuration_guides_list.html.
TDM interfaces
The Cisco AS5400XM Universal Gateway offers unparalleled capacity in only two rack units (2 RUs) and provides best-of-class voice, fax, and remote-access services. High density (up to one Channelized T3 (CT3) of voice over IP (VoIP) and two CT3s of time-division multiplexing (TDM) switching), low power consumption (as low as 2.4 A at 48 VDC per G.711 CT3), high-density packet voice digital signal processor (DSP) modules, universal port DSPs, and session border control (SBC) features make the Cisco AS5400XM Universal Gateway ideal for many network deployment architectures, especially co-location environments and mega points of presence (POPs).
The Cisco AS5350XM Universal Gateway is the one-rack-unit (1 RU) gateway that supports 2-, 4-,8-, or 16-port T1/12-port E1 configurations and provides universal port data, voice, and fax services on any port at any time. The Cisco AS5350XM Universal Gateway offers high performance and high reliability in a compact, modular design. This cost-effective platform is ideally suited for internet service providers (ISPs) and enterprise companies that require innovative universal services.
The Cisco 2800 Series and 3800 Series and the newer 2900 Series and 3900 Series Routers support the widest range of packet telephony-based voice interfaces and signaling protocols within the industry, providing connectivity support for more than 90 percent of the world's private branch exchanges (PBXs) and public switched telephone network (PSTN) connection points. Signaling support includes T1/E1 Primary Rate Interface (PRI), T1 channel associated signaling (CAS), E1-R2, T1/E1 QSIG Protocol, T1 Feature Group D (FGD), Basic Rate Interface (BRI), foreign exchange office (FXO), E&M, and foreign exchange station (FXS). The Cisco 2800 Series and 3800 Series Routers can be configured to support from two to 540 voice channels. The Cisco 2900 Series and 3900 Series Routers can be configured to support from two to 720 voice channels.
For the most current information about the various digital (T1/E1) and analog interfaces supported by the various voice gateways, see the latest product documentation available at the following sites:
- Cisco 2800 Series http://www.cisco.com/en/US/products/ps5854/tsd_products_support_series_home.html
- Cisco 3800 Series http://www.cisco.com/en/US/products/ps5855/tsd_products_support_series_home.html
- Cisco AS5300 http://www.cisco.com/en/US/products/hw/univgate/ps501/tsd_products_support_series_home.html
- Cisco 2900 Series
- http://www.cisco.com/en/US/products/ps10537/index.htm.
- Cisco 3900 Series
- http://www.cisco.com/en/US/products/ps10536/index.htm
Cisco Unified Border Element
The Cisco Unified Border Element (CUBE) (formerly known as the Cisco Multiservice IP-to-IP Gateway) is a session border controller (SBC) that provides connectivity between IP voice networks using SIP. CUBE is supported in flow-through mode only, so that all calls are routed through the CUBE.
Note
Unlike flow-through mode, with flow-around mode, you lose the ability to do DTMF interworking, transcoding, and other key functions such as telephone and media capabilities that flow-through will otherwise allow.
A Unified Border Element is typically needed when replacing a TDM voice circuit with an IP voice trunk, such as a SIP trunk, from a telephone company. The CUBE serves as a feature-rich demarcation point for connecting enterprises to service providers over IP voice trunks.
The CUBE has been tested with, and can be used in, any of the following scenarios:
- SIP-to-SIP connectivity between a third-party SIP device and Cisco Unified CVP over the SIP trunks certified by Cisco.
- SIP-to-SIP connectivity between Cisco Unified Communications Manager and Cisco Unified CVP.
- Co-residency of VoiceXML Gateway and CUBE for any of the above scenarios but with the limitation that the call flow does not work when the configurations listed below occur at the same time on the CUBE:
- For CUBE session numbers, refer to: http://www.cisco.com/en/US/prod/collateral/voicesw/ps6790/gatecont/ps5640/order_guide_c07_462222.html
- Transcoding between G.711 and G.729
For more information about using the CUBE with Unified CVP, including topologies and configurations, see ,mn,.nm,,mml'
Cisco Unified Border Element for Contact Center Solutions, available at:
http://cisco.com/en/US/docs/voice_ip_comm/unified_communications/cubecc.html
Note
Due to a limitation in Cisco IOS, the CUBE does not support mid-call escalation or de-escalation from audio to video, and vice versa.
Using a SIP Trunk Without a CUBE
When connecting to a third-party SIP device, including a SIP PSTN service provider, if a CUBE is not placed between Unified CVP and the SIP device, the customer is responsible for doing integration testing to ensure that both sides are compatible.
When connecting to a PSTN SIP Trunking service without a CUBE, carefully consider how the connection between the customer and service provider will be secured, and how NAT and/or address hiding is accomplished. Otherwise, it is possible for the service-provider network to have full access to the customer network. The CUBE addresses both of these concerns, and it is the service-provider interconnect interface recommended by Cisco.
Using Cisco ASR 1000 Series as a Unified Border Element
Unified CVP supports IOS XE Software - 3.3.0S Enterprise with the following limitations:
- ASR 1000 Series do not support VXML. As a result, the VRU leg of the call must be routed to a separate VXML Gateway. You must not use the “Send To Originator” setting on the CVP Call Server to route the IVR leg of the call back to the originating ASR CUBE gateway, and standalone CVP calls must be routed to a separate VXML Gateway.
- The global “Pass Thru SDP” setting on the ASR 1000 Series gateways is not supported with CVP deployments.
- ASR 1000 Series gateways do not support the TCP transport with SIP signaling when using the box to box hardware redundancy feature. The UDP transport is supported when failing the active ASR chassis to the standby chassis. Since the CVP solution has documented the recommendation of using the TCP transport, it is important to note that the default TCP setting will not work with failover in this version of the ASR release. Therefore, UDP must be used on both the incoming and outgoing legs of the ASR CUBE for uninterrupted call control with CVP. UCS VM deployments cannot support ASR box to box failover due to the above limitation because CVP only supports TCP on the UCS Call Server.
- Regarding the feature of proxy servers to perform UDP to TCP Up-Conversion when receiving large size packet SIP messages, in a scenario where the proxy is in front of the ASR session border controller, this feature should be turned off to ensure that UDP transport is used for the connection on the inbound call. Typically, however, a proxy server is positioned behind the session border controller in the deployment.
- Calls requiring mid-call codec renegotiation, such as a g711 caller transfer to a g729 agent, are not supported by ASR 1000.
- A“sip-profile” configuration is needed on ASR 1000 Series for the courtesy callback feature. To configure the “sip-profile”, the following must be added: voice class sip-profiles 103 request INVITE sip-header Call-Info add "X-Cisco-CCBProbe: <ccb param>"where “<ccb param>” is the “ccb” parameter defined in the survivability service. Add this “sip-profile” to the outgoing dial-peer to the CVP. The following is a configuration example: voice class sip-profiles 103 hoigogpoupcoioivc9iu i 8s66d8 8hxiciuvyd78zicvc8ayge request INVITE sip-header Call-Info add "X-Cisco-CCBProbe: id:192.168.1.50;loc:testbed04;trunks:10" application service survivability flash:survivability.tcl param ccb id:192.168.1.52;loc:testbed04;trunks:10 dial-peer voice 700051 voip description Comprehensive outbound route to CVP destination-pattern 7000200T session protocol sipv2 session target ipv4:192.168.1.20:5060 dtmf-relay rtp-nte voice-class sip profiles 103 codec g711ulaw no vad
- The following Survivability.tcl options are not applicable for use on the ASR because they are traditionally for POTS dial-peers:
- The following Survivability.tcl options are not supported: aa-name, standalone, and standalone-isntime.
- Due to ASR limitations, the following features are not supported:
NoteBecause ASR 1000 represents the introduction of new equipment, to ensure success of ASR 1000 deployments, any UCCE/CVP contact center integration that utilizes the ASR 1000 requires an Assessment to Quality (A2Q) review. This review will be required for new UCCE customers, as well as existing UCCE customers who desire to move to the ASR 1000.
Using Cisco ISR as a Unified Border Element
Unified CVP supports ISR 15.0(1)M1.2, 15.1(4)M3, 15.2(2)T, 15.2(3)T1 and 15.2.4 M with the following limitations:
- A“sip-profile” configuration is needed on ISR for the courtesy callback feature. To configure the “sip-profile”, the following must be added: voice class sip-profiles 103 request INVITE sip-header Call-Info add "X-Cisco-CCBProbe: <ccb param>" where “<ccb param>” is the “ccb” parameter defined in the survivability service. Add this “sip-profile” to the outgoing dial-peer to the CVP. The following is a configuration example: voice class sip-profiles 103 request INVITE sip-header Call-Info add "X-Cisco-CCBProbe: id:192.168.1.50;loc:testbed04;trunks:10" application service survivability flash:survivability.tcl param ccb id:192.168.1.52;loc:testbed04;trunks:10 dial-peer voice 700051 voip description Comprehensive outbound route to CVP destination-pattern 7000200T session protocol sipv2 session target ipv4:192.168.1.20:5060 dtmf-relay rtp-nte voice-class sip profiles 103 codec g711ulaw no vad
NoteUsing a CUBE between Cisco Unified CM and CVP is not supported. This applies to using either Cisco ASR 1000 Series or Cisco ISR as a Unified Border Element.
Mixed G.729 and G.711 codec support
Transcoders (DSPs) are required when two endpoints participating in a call cannot negotiate a common codec. Midcall codec negotiation greatly reduces the need for transcoders.
CUBE introduced support for midcall codec negotiation in IOS 15.1(2)T and IOS-XE 3.7 versions. These versions or higher are required for solution mixed codec support. You can use any combination of codecs on the legs of a call. For example, a caller can place a call using the G.729 codec, hear an IVR prompt played using the G.711 codec, be transferred to the first agent using the G.729 codec, and then transferred to the second agent using the G.711 codec
Transcoders may be required when phones in a WAN- connected location support only the G.729 codec, and CVP is configured for G.711 support. In this case, when these the phones call into Unified CVP, then Unified CM will engage transcoders. Note that for inbound calls that arrive from a gateway or CUBE can start with G.711 at Unified CVP then later renegotiate to G.729 with the agents without the need for transcoders.
Transcoding codecs requires IOS 15.1(2)T or later T release.
For information on the benefits of using the G.711 versus G.729 codec, see G.729 versus G.711 codec support.
Gateway choices
Unified CVP uses gateways for two purposes: TDM ingress and VoiceXML rendering. Any Cisco gateway that is supported by Unified CVP can usually be used for either purpose or both. However, depending on your deployment model, you might need only one of the functions:
- Model #1: Standalone Self-Service All calls use both ingress and VoiceXML.
- Model #2: Call Director All calls use ingress only.
- Model #3a: Comprehensive Using Unified ICM Micro-Apps All calls use ingress, and some calls use VoiceXML.
- Model #3b: Comprehensive Using Unified CVP VXML Server All calls use ingress, and some calls use VoiceXML.
- Model #4: VRU Only with NIC Controlled Routing All calls use both ingress and VoiceXML.
In cases where both ingress and VoiceXML are required, you can choose to run both functions on the same gateways or you can choose to designate some gateways for ingress and others for VoiceXML. Use the following guidelines to determine whether the functions should be combined or split:
- In classical branch office deployments, where the call needs to be queued at the branch where it arrived, ingress and VoiceXML functions must always be combined.
- In cases where a large number of non-CVP PSTN connections share the gateways, it is recommended to dedicated Ingress for that purpose, and use separate VXML gateways.
- VoiceXML-only gateways are less costly because they do not require DSP farms or TDM cards. Use a spreadsheet to determine which way you obtain the best price.
- With relatively low call volume, it is usually better to combine the functions for redundancy purposes. Two combined gateways are better than one of each because the loss of one gateway still allows calls to be processed, though at a lower capacity.
The next decision is whether to use Cisco Integrated Service Router (ISR) gateways (Cisco 2800, 2900 series routers), ISGR-G2 (3800, or 3900 Series routers), or the Cisco AS5x00 Series Gateways. Guidelines state that you use ISR gateways only in branch office sites, whereas AS5x00 Series gateways should be used in centralized data center sites.
Sometimes it is difficult to determine what constitutes a branch office, and therefore which gateway is used. The following guidelines can help with that determination:For more information on the Cisco AS5x00 Series Gateways, refer to the technical specifications available at http://www.cisco.com/en/US/products/hw/univgate/ps501/index.html.
For more information on the Cisco Integrated Service Routers (ISRs), refer to the documentation available at http://www.cisco.com/en/US/products/hw/routers/index.html.
Gateway sizing
Individual Cisco gateways can handle various call capacities depending on whether they are doing ingress only, VoiceXML only, or a combination of the two. Gateways doing VoiceXML activities also have different call capacities depending on whether or not they are supporting ASR or TTS activities and on the type of VoiceXML application being executed. For instance, an intensive JavaScript application reduces call capacity. Gateways doing HTTPS experience lower call capacity as compared to HTTP.
In general, gateways performing ingress-only can be sized according to the number of TDM cables that can be connected to them. For gateways that are combined or VoiceXML-only, it is important to ensure that the overall CPU usage is less than 75% on average. The numbers in the following table are based on Unified CVP VoiceXML documents; other applications that generate more complex VoiceXML documents have a higher impact on performance. The following factors affect CPU usage:
Before sizing the voice gateways, use the Unified CCE Resource Calculator to determine the maximum number of trunks (DS0s) and VoiceXML IVR ports needed to support the entire solution.
For almost all Unified CVP deployment models, sizing is based on the maximum number of concurrent VoiceXML sessions and VoIP calls. The following tables list this information for different IOS release versions as follows:
- Table 1 (IOS version 15.1.1T)
- The following tables (IOS version 15.1.1T and greater):
- For Cisco IOS Release 15.1.1T and greater Maximum Number of VoiceXML Sessions Supported by Cisco Voice Gateways
- For Cisco IOS Release 15.1.1T and greater Maximum Number of VoiceXML Sessions Supported by Cisco Voice Gateways Executing Intensive JavaScript Applications
- For Cisco IOS Release 15.1.1T and greater Maximum Number of VoiceXML Sessions Supported by Cisco Voice Gateways Using HTTPS
Table 3 For Cisco IOS Release 15.1.1T and greater Maximum Number of VoiceXML Sessions Supported by Cisco Voice Gateways
Table 4 For Cisco IOS Release 15.1.1T and greater Maximum Number of VoiceXML Sessions Supported by Cisco Voice Gateways Executing Intensive JavaScript Applications
Table 5 For Cisco IOS Release 15.1.1T and greater Maximum Number of VoiceXML Sessions Supported by Cisco Voice Gateways Using HTTPS 3945E
510
342
408
270
512 MB
AS5350XM1
Note
The following note does not apply to Cisco IOS Release 15.0.1M and IOS 15.1.1T.
Note
Performance numbers for the Cisco 3825 Series and 3845 Series Integrated Services Routers (ISRs) are higher when the voice gateway and the VoiceXML gateway functions reside on the same router (co-resident deployment). When the call is connected to the VoiceXML gateway from the ingress voice gateway, the media flows directly between the two. In a co-resident deployment, the gateway does not have to spend CPU cycles to packetize and de-packetize the RTP packets. Hence, by saving these CPU cycles, the gateway can support increased VoiceXML sessions.
The numbers in For Cisco IOS Release 15.1.1T and greater Maximum Number of VoiceXML Sessions Supported by Cisco Voice Gateways, For Cisco IOS Release 15.1.1T and greater Maximum Number of VoiceXML Sessions Supported by Cisco Voice Gateways Executing Intensive JavaScript Applications, and For Cisco IOS Release 15.1.1T and greater Maximum Number of VoiceXML Sessions Supported by Cisco Voice Gateways Using HTTPS assume the only activities running on the gateway are VXML with basic routing and IP connectivity. If you intend to run additional applications such as fax, security, normal business calls, and so forth, then the capacity numbers presented here should be prorated accordingly. The numbers mentioned in the "Voice Gateway and VoiceXML" column mean that the indicated number of VoiceXML sessions and voice calls can be supported simultaneous on the same gateway. For example, in For Cisco IOS Release 15.1.1T and greater Maximum Number of VoiceXML Sessions Supported by Cisco Voice Gateways the AS5350XM can terminate a maximum of 240 PSTN calls, and those 240 PSTN calls could have 240 corresponding VoiceXML sessions at the same time.
The numbers represent performance with scripts generated by Unified CVP Studio running on the Unified CVP VXML Server. Other VoiceXML applications might perform differently. These figures apply if the CPU utilization does not exceed more than 75%, Voice Activity Detection (VAD) is turned off, and your system is running VoiceXML v2.0 and MRCP v2 with Cisco IOS Release 15.1.1T and greater. The Cisco 1861 Integrated Services Router requires Cisco IOS 15.1.1T and greater.
Note
These performance numbers are accurate when used with either the Cisco Call Server or Cisco Unified CVP VXML Server. Performance can, and often does, vary with different applications. Performance from external VoiceXML applications (such as Nuance OSDMs) might not be representative of the performance when interoperating with non-Cisco applications. You must ensure that the CPU usage is less than 75% on average and that adequate memory is available on Cisco gateways at full load when running external VoiceXML applications. Users should contact the application provider of the desired VoiceXML application for performance and availability information. Be aware that external VoiceXML applications are not provided by Cisco, and Cisco makes no claims or warranties regarding the performance, stability, or feature capabilities of the application when interoperating in a Cisco environment.
Note
Cisco does not specifically test or qualify mixes of traffic because there are infinite combinations. All numbers should be seen as guidelines only and will vary from one implementation to the next based on configurations and traffic patterns. It is recommended that the systems be engineered for worst-case traffic (all ASR) if it is not known or cannot be predicted what kinds of calls will be offered to the VXML gateway.
If you run VoiceXML on one of the Cisco 1800, 2800, 3800 or 2900 and 3900 Series gateways, additional licenses (FL-VXML-1 or FL-VXML-12) are required.
Also consult the following links to ensure that the concurrent call load and call arrival rates do not exceed the listed capacities:
- Model Comparison: http://www.cisco.com/en/US/products/ps10536/prod_series_comparison.html
- Gateway Sizing for Contact Center Traffic: http://cisco.biz/en/US/docs/voice_ip_comm/cucm/srnd/8x/gateways.html#wp1043594
In addition to these capacities, also consider how much DRAM and flash memory to order. The capacity that comes with the machine by default is usually sufficient for most purposes. However, if your application requires large numbers of distinct .wav files (as with complex self-service applications) or if your application has unusually large .wav files (as with extended voice messages or music files), you might want to increase the amount of DRAM in order to accommodate more want to expand your flash memory order. The use of DRAM for prompt caching is discussed in detail in the chapter on Media file options.
NoteHTTP cache can only be extended to100 MB in the current IOS versions.
Using MGCP gateways
Cisco Unified CVP requires the deployment of a SIP gateway. However, customers might require the use of MGCP 0.1 voice gateways with Unified CM deployments for purposes of overlap sending, NSF, and Q.SIG support. The following design considerations apply to deploying Cisco Unified CVP in this environment:
- Design and plan a phased migration of each MGCP voice gateway to SIP.
- Implement both MGCP 0.1 and SIP. Because of the way MGCP works, a PSTN interface using MGCP can be used for MGCP only. Therefore, if you want to use MGCP for regular Unified CM calls and SIP for Unified CVP calls, you will need two PSTN circuits.
- Deploy a second SIP voice gateway at each Unified CVP location.
- Send calls through the Unified CM to Unified CVP.
When sending calls through Unified CM to Unified CVP, the following guidelines apply:
- The Unified CVP survivability.tcl script cannot be used in this solution. If the remote site is disconnected from the central site, the call will be dropped.
- There will be an additional hit on the performance of Unified CM. This is because, in a "normal" Unified CVP deployment, Unified CM resources are not used until the call is sent to the agent. In this model, Unified CM resources are used for all calls to Unified CVP, even if they terminate in self-service. This is in addition to the calls that are extended to agents. If all calls are eventually extended to an agent, the performance impact on Unified CM is approximately double that of a "normal" Unified CVP deployment. This factor alone typically limits this scenario to small call centers only.
- In order to queue calls at the edge, you must use the sigdigits feature in Unified CVP to ensure that the calls are queued at the appropriate site or VXML gateway. For more information on how the sigdigits feature works, see the chapters on Distributed deployments, and Unified CVP design for high availability.
