Cisco Unified Customer Voice Portal (CVP) 7.x Solution Reference Network Design (SRND) - Gateway Options [Cisco Unified Customer Voice Portal]

Table Of Contents

Gateway Options

What's New in This Chapter

PSTN Gateway

VoiceXML Gateway with DTMF or ASR/TTS

VoiceXML and PSTN Gateway with DTMF or ASR/TTS

TDM Interfaces

Cisco Unified Border Element

Gateway Choices

Gateway Sizing

Using MGCP Gateways

Gateway Options

Last revised on: August 18, 2009

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

http://www.cisco.com/en/US/products/sw/custcosw/ps1006/prod_technical_reference_list.html

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:

•PSTN Gateway

•VoiceXML Gateway with DTMF or ASR/TTS

•VoiceXML and PSTN Gateway with DTMF or ASR/TTS

•TDM Interfaces

•Gateway Choices

•Gateway Sizing

•Using MGCP Gateways

What's New in This Chapter

Table 7-1 lists the topics that are new in this chapter or that have changed significantly from previous releases of this document.

Table 7-1 New or Changed Information Since the Previous Release of This Document

New or Revised Topic

Described in:

Co-resident deployment of voice gateway and VoiceXML gateway.

Gateway Sizing

Maximum number of VoiceXML sessions supported by Cisco Voice Gateways

Gateway Sizing

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 H.245 or RFC2833 events. Unified CVP does not currently support passing SIP-Notify or KPML 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.

Note Any 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.

Note The Cisco AS5850eRSC is recommended only for PSTN gateway use. It is not designed to process VoiceXML.

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 H.245 or 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, the recommended voice gateway is the Cisco AS5350XM. 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.

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 3800 Series and 2800 Series routers are the best choice for the voice gateway because they support SRST.

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 Communications Manager deployment, you must provide support for Survivable Remote Site Telephony (SRST). The Cisco 3800 and 2800 Series routers are the best choice for the voice gateway because they support SRST.

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 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.

For the most current information about the various digital (T1/E1) and analog interfaces supported by the various voice gateways, refer to 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 Unified Border Element

The Cisco Unified Border Element (formerly known as the Cisco Multiservice IP-to-IP Gateway) is a session border controller (SBC) that provides connectivity between IP voice networks using H.323 or SIP. Unified CVP has been supported with Cisco Unified Border Element starting with Unified CVP 4.1. Cisco Unified Border Element is supported in flow-through mode only, so that all calls are routed through the Cisco Unified Border Element. 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 Cisco Unified Border Element serves as a feature-rich demarcation point for connecting enterprises to service providers over IP voice trunks.

The Cisco Unified Border Element 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

•SIP-to-H.323 connectivity between a third-party SIP device and Cisco Unified CVP

•SIP-to-SIP connectivity between Cisco Unified Communications Manager and Cisco Unified CVP

•Co-residency of the VoiceXML Gateway and the Cisco Unified Border Element for any of the above scenarios

•Transcoding between G.711 and G.729

For more information about using the Cisco Unified Border Element with Unified CVP, including topologies and configurations, refer to the document 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 Cisco Unified Border Element does not support mid-call escalation or de-escalation from audio to video, and vice versa.

Using a SIP Trunk Without a Cisco Unified Border Element

When connecting to a third-party SIP device, including a SIP PSTN service provider, if a Cisco Unified Border Element 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 Cisco Unified Border Element, carefully consider how the connection between the customer and service provider will be secured, and how NAT and/or address hiding will be accomplished. Otherwise, it is possible for the service-provider network to have full access to the customer network. The Cisco Unified Border Element addresses both of these concerns, and it is the service-provider interconnect interface recommended by Cisco.

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 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 will share the gateways, it is recommended to dedicated Ingress for that purpose, and use separate VXML gateways.

•The Cisco AS5850eRSC can be used for ingress only; it cannot be used for VoiceXML.

•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 or 3800 Series) or the Cisco AS5x00 Series Gateways. Guidelines state that ISR gateways should be used 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 should be used. The following guidelines can help with that determination:

•The classical definition of branch offices, for which you should use ISR gateways, includes:

–Multiple sites where TDM calls will be arriving from the PSTN.

–Those sites are separated from the data centers where most of the Unified CVP equipment resides.

–You will be placing only one gateway at each site.

•If you have sites where you will be stacking multiple gateways for any reason, then those sites are data center sites and should use Cisco AS5x00 Series gateways.

For more information on the Cisco AS5x00 Series Gateways, refer to the technical specifications available at

http://www.cisco.com/en/US/products/hw/iad/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 will be less than 75% on average. The numbers in Table 7-2 are based on Unified CVP VoiceXML documents; other applications that generate more complex VoiceXML documents will have a higher impact on performance. The following factors affect CPU usage:

•Calls per second (cps)

•Maximum concurrent calls

•Maximum concurrent VoiceXML sessions

Before sizing the voice gateways, use the IPCC 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, as listed in Table 7-2, Table 7-3, Table 7-4, and Table 7-5.

Table 7-2 Maximum Number of VoiceXML Sessions Supported by Cisco Voice Gateways

Cisco Voice Gateway Platform

Dedicated VoiceXML Gateway

Voice Gateway and VoiceXML

Memory Recommended

VoiceXML and DTMF

VoiceXML and ASR/TTS

VoiceXML and DTMF

VoiceXML and ASR/TTS

1861

5

4

4

2

256 MB

2801

7

6

6

4

256 MB

2811

30

24

25

20

256 MB

2821

45

36

36

30

256 MB

2851

60

56

56

48

512 MB

3825

180

140

210

130

512 MB

3845

200

155

230

145

512 MB

AS5350XM¹

240

192

240

160

512 MB (default)

AS5400XM1

240

192

240

160

512 MB (default)

¹Not to exceed 80% of CPU utilization.

Table 7-3 Maximum Number of VoiceXML Sessions Supported by Cisco Voice Gateways Executing Intensive JavaScript Applications

Cisco Voice Gateway Platform

Dedicated VoiceXML Gateway

Voice Gateway and VoiceXML

Memory Recommended

VoiceXML and DTMF

VoiceXML and ASR/TTS

VoiceXML and DTMF

VoiceXML and ASR/TTS

1861

2

2

2

2

256 MB

2801

3

2

2

2

256 MB

2811

10

5

10

5

256 MB

2821

20

15

15

15

256 MB

2851

30

25

25

20

512 MB

3825

70

55

85

50

512 MB

3845

80

60

95

60

512 MB

AS5350XM¹

105

85

110

70

512 MB (default)

AS5400XM1

105

85

110

70

512 MB (default)

¹Not to exceed 80% of CPU utilization.

Table 7-4 Maximum Number of VoiceXML Sessions Supported by Cisco Voice Gateways Using HTTPS

Cisco Voice Gateway Platform

Dedicated VoiceXML Gateway

Voice Gateway and VoiceXML

Memory Recommended

VoiceXML and DTMF

VoiceXML and ASR/TTS

VoiceXML and DTMF

VoiceXML and ASR/TTS

1861

3

2

2

2

256 MB

2801

4

4

4

2

256 MB

2811

15

10

15

10

256 MB

2821

30

20

20

15

256 MB

2851

40

35

30

25

512 MB

3825

115

90

125

75

512 MB

3845

125

100

135

85

512 MB

AS5350XM¹

155

120

138

95

512 MB (default)

AS5400XM1

155

120

138

95

512 MB (default)

¹Not to exceed 80% of CPU utilization.

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 Table 7-2, Table 7-3, and Table 7-4 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 Table 7-2 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 12.4(15)T5. The Cisco 1861 Integrated Services Router requires Cisco IOS 12.4(20)T1 as the minimum release.

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 If you run VoiceXML on one of the Cisco 1800, 2800, or 3800 Series gateways, additional licenses (FL-VXML-1 or FL-VXML-12) are required.

Also consult Table 7-5 to ensure that the concurrent call load and call arrival rates do not exceed the listed capacities.

Table 7-5 Maximum Number of Calls Supported per Gateway Platform

Cisco Voice Gateway Platform

Maximum Calls per Second

Maximum VoIP Calls

2801

1

32

2811

1

80

2821

1.2

128

2851

2

192

3725

2

192

3745

4

384

3825

4

384

3845

8

540

AS5400HPX¹

7

384

AS5350XM

20

192

AS5400XM

20

648

¹Listed capacities for the AS5400HPX apply only for existing deployments. The Cisco AS5400HPX Universal Gateway has reached End of Sale (EoS) and is no longer available for new deployments. For more details, refer to the EoS announcement for the AS5400HPX, available at http://www.cisco.com/en/US/prod/collateral/iad/ps505/ps507/prod_end-of-life_notice0900aecd804c6e98.html.

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 cache space. The .wav files are recorded at 8 kbps. Additionally, if you plan to use the flash memory itself rather than a media server to house media files, you might 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, page 12-1.

Using MGCP Gateways

Cisco Unified CVP requires the deployment of H.323 or SIP gateways. However, customers might require the use of MGCP 0.1 voice gateways with Cisco Unified Communications Manager 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 Cisco Unified Communications Manager calls and H.323 or SIP for Unified CVP calls, you will need two PSTN circuits.

•Deploy a second H.323 or SIP voice gateway at each Unified CVP location.

•Send calls through the Cisco Unified Communications Manager to Unified CVP.

When sending calls through Cisco Unified Communications Manager 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 Cisco Unified Communications Manager. This is because, in a "normal" Unified CVP deployment, Cisco Unified Communications Manager resources are not used until the call is sent to the agent. In this model, Cisco Unified Communications Manager 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 Cisco Unified Communications Manager 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, page 3-1, and Designing Unified CVP for High Availability, page 4-1.