Cisco Customer Voice Portal (CVP) Release 3.1 Solution Reference Network Design (SRND)
Deployment Models
Downloads: This chapterpdf (PDF - 307.0KB) The complete bookPDF (PDF - 1.96MB) | Feedback

Deployment Models

Table Of Contents

Deployment Models

Model #1, Standalone Self Service

Customer Requirements

Caller Experience

Characteristics

Components

Protocol Level Call Flow

Transfers

Geographic Distribution Alternatives

Collocated VoiceXML Servers and Gateways

Gateways at the Branch, Centralized VoiceXML Servers (non-collocated)

Model #2, CVP Call Control

Customer Requirements

Caller Experience

Characteristics

Components

Protocol Level Call Flow

Ingress Gateway New Call Flow

ICM Transfers a Call to a Target

ICM Transfers a Call to a Second Target Via Blind Network Transfer

Transfers

Distributed: Ingress and/or Egress Gateway at the branch

Network Traffic

Survivability

Model #3a, CVP Call Control with Queue and Collect

Customer Requirements

Caller Experience

Characteristics

Components

Protocol Level Call Flow

Ingress Gateway new Call Flow

Establishment of VRU Leg to VXML Gateway

ICM Transfers the Call to a Target

ICM Transfers a Call to a Second Target Via Blind Network Transfer

Transfers

Distributed: Ingress/VXML Gateway at branch

Model #3b, CVP Call Control with Queue and Self Service

Customer Requirements

Caller Experience

Characteristics

Components

Protocol Level Call Flow

Transfers

Distributed: Ingress/VXML Gateway and VoiceXML Server at branch

Model #4, NIC-based Call Control with CVP Queue, Collect and Self Service

Customer Requirements

Caller Experience

Characteristics

Components

Protocol Level Call Flow


Deployment Models


This chapter covers following five substantially different deployment models for CVP customers:

Model #1, Standalone Self Service

Model #2, CVP Call Control

Model #3a, CVP Call Control with Queue and Collect

Model #3b, CVP Call Control with Queue and Self Service

Model #4, NIC-based Call Control with CVP Queue, Collect and Self Service

Each model begins by listing the types of customer requirements and the expected caller experience which would lead a customer to that particular model. Salient characteristics of the model are presented, mentioning at a high level what makes each model different from the others, and any important constraints or caveats that the reader needs to know about. Next, we list the CVP product and solution components which might or must be present in that model.

These descriptive sections are followed by a detailed specification of the protocol level message flow between components, and a list of the types of transfers which are supported (refer to Chapter 7, "Call Transfer Options"for detailed information about these types of transfers). Each model ends finally with a section describing how it can or must be adapted if it is deployed in a geographically distributed fashion (A.K.A. branch office deployment).

All of these models can be deployed with CVP's standard set of high availability features. However, we have chosen not to discuss the design or effects of high availability here, in order to keep the discussion focused. That topic is covered in Chapter 5, "Designing CVP for High Availability".

Model #1, Standalone Self Service

This section covers the following topics:

Customer Requirements

Caller Experience

Characteristics

Components

Protocol Level Call Flow

Transfers

Geographic Distribution Alternatives

Customer Requirements

The customer wants a standalone IVR for automated self service and call handling.

Caller Experience

The caller dials either a local phone number or a centralized phone number, communicates with an IVR, and then optionally transfers to a destination.

Characteristics

This deployment model provides IVR services only. Intelligent contact center integration is not included, though it is possible to transfer the call to an arbitrary destination, without call context, and without queuing. This model requires VoiceXML Servers and gateways, but does not include the CVP Call Server or any ICM components. IVR applications support either DTMF- only or ASR and TTS.

Components

Required components:

Ingress/VXML Gateways

VoiceXML Servers

VoiceXML Studio

Optional components:

ASR and TTS Servers

Media Servers

Content Services Switches

Protocol Level Call Flow

The steps involved in handling a call in a CVP standalone IVR deployment are describe below. Typically, the inbound call activates an IVR application that plays pre-recorded prompts and TTS with caller input via DTMF and/or speech recognition. The call might simply comprise IVR dialogue or might additionally involve one or more subsequent transfers.

The flow described here assumes the use a Content Services Switch (CSS) for failover and load balancing purposes. Note that the CSS is optional; please see Chapter 5, "Designing CVP for High Availability" to better understand the benefits of deploying a CSS.

1. Call arrives to ingress gateway via TDM/SIP/H.323. Gateway performs normal inbound pots/voip dial-peer matching.

2. Selected dial-peer invokes CVP self-service TCL script.

3. TCL script invokes CVP standalone bootstrap VoiceXML Document which performs an HTTP request to the configured CSS VIP address for the primary VXML server.

4. CSS selects an available VXML server to process the call. CSS also creates a cookie to ensure that subsequent HTTP requests for the call are directed to the same VXML server.

5. VXML server runs the application specified in the HTTP URL.

6. VXML server returns a dynamically generated VXML doc to the gateway via the CSS.

7. Gateway parses and renders VXML doc.

8. For spoken output, the gateway either retrieves and plays back pre-recorded audio files referenced in the VXML documentation, or streams media from a TTS server via an MRCP session:

a. Pre-recorded Audio

Gateway looks in local cache for the requested audio file. If the audio file exists in cache and has not expired, gateway renders from cache. Alternatively, if the file cannot be retrieved from cache or has expired, gateway makes an HTTP request to the destination defined by the URL of the audio source in the VXML doc. Note that mechanisms other than HTTP might be used, such as tftp, rtsp, flash, etc. For more information, reference Cisco IOS TCL IVR and VoiceXML Application Guide http://www.cisco.com/application/pdf/en/us/guest/products/ps6242/c1696/ccmigration_09186a008045e24d.pdf

The CSS is configured to select an available media server for the specified URL. Once selected, the CSS sends an HTTP redirect back to the gateway with the IP address of media server. The gateway then retrieves the media directly.

b. TTS

Gateway establishes an MRCP session to the TTS server configured on the gateway, using the CSS to determine the actual physical server. Note that the TTS server address can be overridden by populating the VXML property com.cisco.tts-server.

TTS server sends RTP packets back to the Gateway directly, bypassing the CSS. Gateway plays TTS to the caller.

9. Caller input can be captured either by DTMF detection on the gateway or via DTMF/utterance recognition on the ASR server. When an ASR server is used, the gateway establishes an MRCP connection to the ASR server configured on the gateway using the CSS to determine the actual physical server. Note that the ASR server address can be overridden by populating the VXML property com.cisco.asr-server. The caller's speech is streamed over RTP directly from the gateway to the ASR server.

10. As defined in the VoiceXML document, gateway submits an HTTP request containing the results of the caller input to the VXML server via the CSS. Using the cookie saved earlier, the original VXML server will be (and must be) selected to handle the request because it has retained context for the call.

11. The IVR dialogue continues with repeated iterations from Step 6. on page 3- 3 to Step 10. on page 3- 3.

12. The application on the VXML server might access back-end systems for personalized data to incorporate into the VoiceXML documents that it sends back to the gateway.

13. As part of the self-service application, transferring the caller to another destination might be necessary.

14. In the case of a VXML Bridged Transfer the outcome of the transferred call leg is submitted back to the VXML server when the transfer completes either normally or because of an error. The VXML session is resumed and further iterations of IVR call treatment and transfers can be performed.

Transfers

The following types of transfer are supported in this model.

VXML 2.0 Bridged Transfer

VXML 2.0 Blind Transfer

Release Trunk Transfer (Hook Flash and TBCT)

The VoiceXML transfers are invoked using the VoiceXML Studio's `transfer' element. Release Trunk Transfers are invoked by providing specially formatted return values in VoiceXML Studio's `subdialog_return' element.

Geographic Distribution Alternatives

Collocated VoiceXML Servers and Gateways

All gateways and servers either are centralized or are all replicated at branch offices with no centralized control. If ASR servers are used, they must be collocated with the gateway.

Pros of collocation:

WAN outage does not impact self service application

ASR is permitted with centralized ASR servers

Cons of collocation:

No centralized administration or reporting

Extra VoiceXML Servers required when using replicated branch offices

Deployment of applications to multiple VoiceXML servers

Gateways at the Branch, Centralized VoiceXML Servers (non-collocated)

Pros of non-collocation:

Centralized administration and reporting

Local phone numbers

VoiceXML Server capacity can be shared among branch offices

Cons of non-collocation:

Limited branch survivability

ASR requires a local ASR server at each branch

WAN bandwidth must be sized for additional VoiceXML over HTTP traffic

Model #2, CVP Call Control

This section covers the following topics:

Customer Requirements

Caller Experience

Characteristics

Components

Protocol Level Call Flow

Transfers

Distributed: Ingress and/or Egress Gateway at the branch

Customer Requirements

This model has the following customer requirements:

TDM migration to IP: Customer has a TDM ACD network, and wants to exploit the benefits and flexibility of routing calls over an IP network among those existing ACDs without tromboning.

Customer wants to use the IP infrastructure to save costs, such as Takeback and Transfer charges, tie line charges, and PSTN network dip charges.

Customer wants the advantages of pre-routing within an enterprise infrastructure without resorting to a service provider.

Customer wants a cradle to grave view of all calls in the contact center.

Caller Experience

The caller dials either a local or a centralized phone number and is intelligently routed to a business- appropriate service. The caller might be subsequently transferred to one or more other services, with call context preserved.

Characteristics

This deployment model is a call-switching-only solution and does not insert any IVR capability into the network. This model requires ICM in order to provide the intelligent call routing, but does not provide for any queuing other than what is already provided by the existing ACDs. Calls can be transferred among agents and other devices without loss of call context information and without tromboning through those devices.

In addition, this model facilitates migration of existing TDM peripherals to IP, since a Child IPCC Enterprise can take the place of any traditional ACD.


Note The Child IPCC deployment was added in the ICM 7.0(0) release. For more information on this deployment, refer to the Cisco IPCC Gateway Deployment Guide at: http://www.cisco.com/en/US/products/sw/custcosw/ps1001/tsd_products_support_series_home.html


Components

Required components:

Ingress and egress gateways

Gatekeepers

CVP Call Servers

ICM

Protocol Level Call Flow


Note This call flow refers to a target as the destination of the transferred call leg. This target could be an IPCC Enterprise agent, an ACD with its own queuing capabilities, or anything else that can take a caller's call.


Ingress Gateway New Call Flow

1. Call arrives to ingress gateway via TDM/SIP/H.323. Gateway performs normal inbound pots/voip dial-peer matching

2. Ingress gateway makes an H.323 RAS request to the gatekeeper to find the IP address of an appropriate CVP Call Server for that dialed number.

3. Gateway sends an H.225 call setup to the CVP Call Server. For a brief period of time, a G.711 bearer stream exists between the ingress gateway and the CVP Call Server.

4. CVP Call Server sends a New Call message to ICM via the VRU PG.

5. ICM starts a routing script based on dialed number and other criteria.

ICM Transfers a Call to a Target

1. ICM routing script selects a target.

2. ICM sends the target's label to the CVP Call Server. The label might or might not be prefixed with "DTMF", "TBCT", or "HF".

a. If the label contains no prefix, then the transfer is conducted through H.323 signaling.  The CVP Call Server consults the gatekeeper to translate the label to the IP address of an appropriate Cisco CallManager or other H.323 endpoint. The CVP Call Server then sends an H.225 call setup to the selected endpoint, and makes an Empty Capability Set (ECS) request to the ingress gateway to redirect. Through the media stream is redirected, the H.225 signaling path continues to pass through the CVP Call Server.

b. In the case of DTMF (used for TNT), the CVP Call Server sends an H.323 message to the ingress gateway requesting that it outpulse the remainder of the label (which usually begins with "*8") to the carrier. The carrier pulls the call away from the ingress gateway and delivers it to the specified destination. Both the signaling and media connections to the CVP Call Server are terminated.

c. In the case of hook flash the CVP Call Server sends an H.323 message to the ingress gateway requesting that it generates a hook flash, and then outpulses the remainder of the label to the carrier, PBX, or other TDM peer to which the gateway is connected. The call is disconnected from the ingress gateway, pulled back into the connected TDM network and delivered to the specified destination.

d. In the case of TBCT, the CVP Call Server instructs the Survivability.tcl script running on the ingress gateway to issue a 2-B Channel Transfer to the specified target. The carrier pulls the call away from the ingress gateway and delivers it to the specified destination.

3. If the H.323 target returns a busy or connect failure status, or if the target rings for a period of time which exceeds the CVP Call Server's RNATimeout setting, the CVP Call Server cancels the transfer request and sends a transfer failure indication to ICM. This causes a "Router Requery" operation; the ICM routing script recovers control and has the opportunity to select a different target or take other remedial action. (Note: Router Requery is only available for transfers which use H.323 signaling; see ICM Managed Transfers, page 7-3.)

4. The call arrives at the H.323 endpoint.

5. Caller speaks to the agent.  We assume now that the agent needs to blind-transfer the call to a second agent.

ICM Transfers a Call to a Second Target Via Blind Network Transfer

1. ACD issues a Route Request to ICM.

2. ICM starts a new routing script which contains a Select node, Label node, or other non-queuing node that results in the immediate selection of a label.

3. ICM sends an agent label to the CVP Call Server. 

4. The CVP Call Server disconnects the transferred call leg from the current H.323 endpoint and connects the call to the new endpoint in exactly the same way as described earlier when the call was transferred to the first endpoint.

5. Caller speaks to the second agent. We assume now that the caller is satisfied and hangs up.

6. Ingress gateway sends an H.225 release to the CVP Call Server.

7. CVP Call Server sends an H.225 release to the Cisco CallManager to disconnect the agent.

8. CVP Call Server sends a Disconnect message to ICM.

Transfers

The following types of transfers are supported:

Takeback-N-Transfer (TNT)

Hook flash and Wink

Two B Channel Transfer (TBCT)

ICM Managed Transfers

Since this model does not include any Cisco-provided VRU, the transfer target will often be another VRU rather than an ACD or agent. However, this is not relevant to the protocol level call flow shown above, since in any case the VRU is simply another endpoint.

Distributed: Ingress and/or Egress Gateway at the branch

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 being especially important in international deployments spanning multiple countries. Egress gateways are located at branches either for localized PSTN breakout or for integration of decentralized TDM platforms into the 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.

Network Traffic

Two kinds of traffic flows over the WAN: signaling and media.  The signaling is H.323 between the ingress/egress gateways and the centralized gatekeepers and CVP Call Servers, and possibly SCCP between the Cisco CallManager phones and the centralized Cisco CallManagers.

The media comprises RTP traffic between:

The ingress gateways and the centralized CVP Call Servers (briefly at the start of each new call only)

The ingress gateways and centralized or remote IP phones

The ingress gateways and egress gateways located in different sites.

If the customer requirements permit, dial plans and routing priorities can be configured such 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. (Signaling and data may traverse the WAN.)

WAN links are typically provisioned with a minimal amount of bandwidth. In order to conserve that bandwidth, use G.729 encoding for any RTP traffic which traverses the WAN s. (However, the initial brief setup to the CVP Call Server must use G.711, because the CVP Call Server only supports that codec.)

Survivability

Branch reliability becomes somewhat more of an issue than centralized reliability because WANs are typically less reliable than LAN links. Therefore, provide mechanisms which are local to the branch to gracefully handle calls which are impacted by loss of a WAN link to the central site.

This topic is discussed in detail in Chapter 6, "Call Survivability in Distributed Deployments".

Model #3a, CVP Call Control with Queue and Collect

This section covers the following topics:

Customer Requirements

Caller Experience

Characteristics

Components

Protocol Level Call Flow

Transfers

Distributed: Ingress/VXML Gateway at branch

Customer Requirements

Customer requirements include everything in Model #2:

TDM migration to IP: Customer has a TDM ACD network, and wants to exploit the benefits and flexibility of routing calls over an IP network among those existing ACDs without tromboning.

Customer wants to use the IP infrastructure to save costs, such as Takeback and Transfer charges, tie line charges, and PSTN network dip charges.

Customer wants the advantages of pre-routing within an enterprise infrastructure without resorting to a service provider.

Customer wants a cradle to grave view of all calls in the contact center.

as well as:

The ability to bring network level prompting and queuing into the enterprise.

This deployment also allows the customer to leverage ICM scripting knowledge to write simple IVR applications integrated with the routing script logic.

Caller Experience

The caller dials a local or centralized phone number. The caller receives a welcome prompt, an initial menu, and perhaps a simple data entry dialogue to collect an account number. Based on the caller's input, the call might be queued for a contact center agent, receiving music or announcements while on hold.

Eventually the caller is connected to an available agent, after which the caller might be returned to queue and/or transferred to a different target, such as voice mail, another agent, or IVR menu.

All call context information is maintained for the life of the call.

Characteristics

All scripting is done using the ICM Script Editor, with ICM Network VRU Scripts forming the building blocks of the IVR application. Each script invokes the appropriate CVP Micro-application for the required operation.

Most implementations use DTMF data entry and recorded. wav files rather than ASR and TTS.

Transfers to agents can involve queuing, and subsequent transfers might involve further IVR dialog as well. Agent to agent calls can be blind-transferred without tromboning, but warm transfers might require tromboning through the ACD.

Call context is maintained throughout the call.

Components

Required components:

Ingress gateways

VXML gateways

Gatekeepers

CVP Call Servers

ICM, or IPCC Enterprise or Hosted

Optional components:

Dedicated media servers

Content Services Switches

Rarely used:

ASR/TTS services

Protocol Level Call Flow

Ingress Gateway new Call Flow

1. Call arrives to ingress gateway via TDM/SIP/H.323. Gateway performs normal inbound pots/voip dial-peer matching

2. Ingress gateway optionally makes an H.323 RAS request to the gatekeeper (static dial-peer targets might be configured instead) to find the IP address of an appropriate CVP Call Server for that dialed number.

3. Gateway sends an H.225 call setup to the CVP Call Server, and the CVP Call Server immediately responds with an H.225 connect. At this point the gateway answers the incoming call leg. For 100ms or so, a G.711 RTP stream exists between the ingress gateway and the CVP Call Server. This short term media burst sends only a few RTP packets to the CVP Call Server from the gateway before it is torn down as the call is transferred to the VXML gateway. This should be considered negligible and does not impact network design. Gateway access lists can be configured if necessary to prevent this stream from being established.

4. CVP Call Server sends a New Call message to ICM via the VRU PG.

5. ICM starts a routing script based on dialed number and other criteria. We assume now that the script begins with a simple menu.

Establishment of VRU Leg to VXML Gateway

1. The ICM script executes a Send To VRU script node which results in a Connect message containing the VRU access number and a unique Correlation ID being sent to the CVP Call Server. The label is known as the "VRU Transfer Label".

2. CVP Call Server consults that gatekeeper to translate the label to the IP address of an appropriate VXML gateway. (This gatekeeper consultation is mandatory as the CVP Call Server cannot transfer H.323 calls without being configured to use a gatekeeper)

3. CVP Call Server sends an H.225 call setup to the selected VXML gateway, and requests the ingress gateway to redirect the media stream to the VXML gateway. Note that the destination number comprises the VRU transfer label with the Correlation ID appended.

4. The H.323 call arrives at the VXML gateway which performs normal inbound VoIP dial-peer matching.

5. Selected dial-peer invokes CVP TCL script.

6. TCL script invokes CVP VXML bootstrap document, which performs an HTTP request to the configured CVP Call Server for the gateway (or via a CSS if present in the solution, see Chapter 5, "Designing CVP for High Availability").

7. The CVP Call Server strips the Correlation ID from the end of the dialed number and sends a Request-Instruction message to the ICM, which correlates this VRU call leg with the script that invoked the Send To VRU operation.

8. The ICM script resumes and the IVR dialogue commences.

9. The ICM sends a Run External Script to the CVP Call Server specifying the CVP microapp to be executed.

10. CVP Call Server sends a VoiceXML Document containing the prompt or DTMF input instructions to the VXML gateway.

11. VXML gateway voice browser executes the VoiceXML Document. 

12. In executing the VoiceXML Document, the VXML gateway could optionally make an HTTP request to retrieve media files from the Media Server.

13. VXML gateway sends an HTTP Call Result to the CVP Call Server.

14. CVP Call Server sends a RunScriptResult message to ICM.

15. ICM routing script continues by queuing the call for an appropriate skill group.  We assume that no agents are currently available.

16. The ICM routing script enters a RunExternalScript node to play a music file.

17. ICM sends a RunScriptRequest message to the CVP Call Server.

18. CVP Call Server sends a VoiceXML Document containing instructions to the VXML gateway to play a music file.

19. VXML gateway voice browser executes the VoiceXML Document. 

20. In executing the VoiceXML Document, the VXML gateway retrieves the required media file from local cache or the configured media server if necessary.

ICM Transfers the Call to a Target

1. While the music is playing an agent becomes available.  ICM sends an agent label to the CVP Call Server. 

2. The CVP Call Server disconnects the current transferred call leg to the VXML Gateway and re-establishes the media channels for the incoming call leg from the ingress gateway to the CVP Call Server.

3. The CVP Call Server sends an Empty Capability Set message to the ingress gateway and the media channels are disconnected pending setup of the new transferred call leg to the agent.

4. The CVP Call Server consults the gatekeeper to translate the agent label to an appropriate destination IP address. This is a Cisco CallManager in the example scenario here but could alternatively be an egress gateway which is front-ending an ACD or TDM voice network.

5. If the gatekeeper cannot return a destination IP address in response to the ARQ or the call setup fails to the primary and all possible alternate endpoints returned by the gatekeeper, an event report is sent to the ICM indicating connect failure. The ICM Router requery mechanism is invoked in order that the script might resume and perform further IVR treatment or provide alternative transfer destinations. Router requery is also performed if the call setup attempt results in destination busy or the called number does not answer within the CVP Call Server's predefined RNATimeout period. Note that RNATimeout is a system-wide setting for each CVP Call Server.

6. The CVP Call Server issues an H.225 Setup to the target device and requests the ingress gateway to establish the media stream to the target device.

7. Caller speaks to the agent.

ICM Transfers a Call to a Second Target Via Blind Network Transfer

1. We assume now that the agent needs to blind-transfer the call to a second skill group. We also assume that there are currently no agents available in that skill group.

2. The agent, via his ACD or CTI desktop application makes a post-route request to ICM.

3. ICM starts a new routing script, and executes another Queue node.

4. On successfully queuing the call ICM executes a Run External Script node to return the caller to the VRU and present queuing messages and music while waiting in queue.

5. ICM sends the VRU Transfer Label to the CVP Call Server along with a unique Correlation ID.

6. The CVP Call Server commences another Empty Capability Set transfer to reconnect the caller to the VXML gateway.

7. The CVP Call Server disconnects the current transferred call leg to the Cisco CallManager and re-establishes the media channels for the incoming call leg from the ingress gateway to the CVP Call Server.

8. The CVP Call Server sends an Empty Capability Set message to the ingress gateway and the media channels are disconnected pending setup of the new transferred call leg to the VXML gateway.

9. CVP Call Server consults that gatekeeper to translate the label to the IP address of an appropriate VXML gateway.

10. CVP Call Server sends an H.225 Setup to the selected VXML gateway, and requests the ingress gateway to redirect the media stream to the VXML gateway.

11. The VXML gateway starts a TCL/VXML application as described already for the VRU leg, which sends an HTTP New Call message to the CVP Call Server (optionally via a CSS - see High Availability Design section).

12. The CVP Call Server sends a Request Instruction message containing the call's Correlation ID to ICM via the VRU PG.

13. The ICM routing script resumes execution with a RunExternalScript node to play the queuing messages/music.

14. ICM sends a RunScriptRequest message to the CVP Call Server.

15. CVP Call Server sends a VoiceXML Document containing instructions to play the specified media file.

16. VXML gateway voice browser executes the VoiceXML Document, retrieving media files from the Media Server as necessary.

17. VXML gateway sends an HTTP Call Result to the CVP Call Server.

18. CVP Call Server sends a RunScriptResult message to ICM.

19. While the music is playing, an agent in the second skill group becomes available.  ICM sends an agent label to the CVP Call Server. 

20. The CVP Call Server disconnects the transferred call leg to the VXML gateway and connects the call to the new agent in exactly the same way as described earlier when the call was transferred to the first agent.

21. Caller speaks to the second agent.  We assume now that the caller is satisfied and hangs up.

22. Ingress gateway sends an H.225 release to the CVP Call Server.

23. CVP Call Server sends an H.225 release to the Cisco CallManager to disconnect the agent.

24. CVP Call Server sends a Disconnect message to ICM.

Transfers

The following types of transfer are supported:

Takeback-N-Transfer (TNT)

Hook flash and Wink

Two B Channel Transfer (TBCT)

ICM Managed Transfers

For agent to agent transfers, only blind transfers are supported when the agents are hosted on TDM ACD's.  For IPCC agents, warm transfers are also supported. However, note that in this case the H.323 signaling is daisy-chained through the Cisco CallManager once the warm transfer has been completed by the agent. From the customer's perspective, this means that the original caller's line appearance remains on the first agent's desktop application until the caller eventually hangs up. It also means that auto-answer will not function properly for the first agent, since she still appears to be talking to the caller.

Distributed: Ingress/VXML Gateway at branch

Consideration needs to be given to other voice services that are being run at the branch. For example, the branch is typically a remote Cisco CallManager site supporting both ACD agent and non-agent phones. This model also implies that the PSTN gateway is used not only for ingress of CVP calls, but also for ingress/egress of CVP related calls for that site. In circumstances where the VXML and voice gateway functions reside at the same branch location but on separate devices, special attention has to be paid to the dial plan to ensure that the VRU leg is sent to the local VXML resource, as the CVP Call Server settransferlabel mechanism only applies to co-resident VXML and voice gateway configurations.

Model #3b, CVP Call Control with Queue and Self Service

This section covers the following topics:

Customer Requirements

Caller Experience

Characteristics

Components

Protocol Level Call Flow

Transfers

Distributed: Ingress/VXML Gateway and VoiceXML Server at branch

Customer Requirements

Customer requirements include everything in Model #3a:

TDM migration to IP: Customer has a TDM ACD network, and wants to exploit the benefits and flexibility of routing calls over an IP network among those existing ACDs without tromboning.

Customer wants to use the IP infrastructure to save costs, such as Takeback and Transfer charges, tie line charges, and PSTN network dip charges.

Customer wants the advantages of pre-routing within an enterprise infrastructure without resorting to a service provider.

Customer wants a cradle to grave view of all calls in the contact center.

The ability to bring network level prompting and queuing into the enterprise.

as well as:

a need to support substantially more complex self service applications, which might or might not include ASR and TTS.

The customer has an existing services oriented architecture environment for his web infrastructure, and wants to make use of it for self service.

Caller Experience

Caller dials a local or centralized phone number.  The caller interacts with a complex self service application, and might choose to transfer to an agent.  The caller might wait in queue, listening to music or messages.

Eventually the caller speaks to an agent, after which the caller might be returned to queue and/or transferred to a different target, such as voice mail, another agent, or back into a self service application.

All call context information is maintained for the life of the call.

Characteristics

The self-service scripting is developed primarily in VoiceXML Studio, though the initial invocation and possibly some amount of scripting might also be developed in the ICM Script Editor in order to link a number of self-service modules into an overall IVR service.  The ICM script coordinates the interaction at a high level and integrates the IVR aspects of the call with the call routing business rules.

ASR and TTS are often used in this model.

Components

Required components:

Ingress gateways

VXML gateways

Gatekeepers

CVP Call Servers

CVP VoiceXML Servers (or other VXML application server)

ICM or IPCC Enterprise or Hosted

Optional components:

Media servers

Content Services Switches

ASR/TTS MRCP servers

Protocol Level Call Flow

From a caller experience perspective, this model differs from Model 3a in only one respect: rather than beginning with a basic prompt and collect interaction, the caller enters a complex self service application. Everything else remains the same. At a protocol level, the entire message flow is the same, except that the ICM RunExternalScript node which invokes the prompting and collecting now invokes something more complex.

Thus, Step 10. on page 3- 11 in the call flow above changes from "CVP Call Server sends a VoiceXML Document containing the prompt or DTMF input instructions to the VXML gateway" to the following steps:

1. CVP Call Server sends a VoiceXML Document containing an embedded "subdialog" element, containing a URL for the VoiceXML Server application. This URL is built dynamically by the CVP Call Server using values set in CVP ECC variables by the ICM script. Optionally, data can be passed to the VXML subdialog either via URL or VXML parameters; the content of which is determined by the ToExtVXML ECC variables set in the ICM script.

2. When the gateway voice browser executes this VoiceXML Document, it sends the embedded HTTP request to the VoiceXML Server.

3. The VoiceXML Server invokes the requested application, and responds with a VoiceXML Document of its own, containing the first instructions comprising the self-service application.

4. The gateway voice browser executes the VoiceXML Document, fetching and playing prompts as necessary from the Media Server.

5. We assume that the application uses ASR to input information from the caller, and TTS to play text-based messages.  The gateway voice browser sends a set of grammars and a request to the ASR server to recognize spoken input, as well as TTS requests to synthesize speech.

6. The MRCP ASR/TTS server synthesizes the spoken message and plays it via an RTP stream back to the gateway. It also listens via an RTP stream in the other direction for utterances which match the specified grammars.

7. The MRCP server responds to the gateway voice browser with a list of words which it recognized. 

8. The gateway voice browser sends a resulting HTTP request to the VoiceXML Server.

9. The VoiceXML Server continues executing its script, serving additional Voice XML documents. Steps 2 through 8 are repeated as necessary.

10. Eventually the VoiceXML Server script terminates, and sends a VoiceXML Document to the gateway voice browser containing a "subdialog return" element and optional data for delivery back to ICM.

11. The gateway voice browser sends the resulting information in an HTTP request to the CVP Call Server.

12. The CVP Call Server sends a RunScriptResult message to ICM.

13. ICM continues its routing script.

Transfers

Transfers are performed as detailed previously for model 3a:

Takeback-N-Transfer (TNT)

Hook flash and Wink

Two B Channel Transfer (TBCT)

ICM Managed Transfers

Although the CVP VXML self-service applications could theoretically be scripted to perform their own transfers, these should not be used in this model and are not supported. The ICM, having passed control to an external CVP VXML application, expects to resume control of the call once the application has completed. If a transfer is required then the destination number, if determined by the self-service application, wants be returned to ICM via the FromExtVXML ECC variables which can be set on the subdialog-return script element.

For agent to agent transfers, only blind transfers are supported when the agents are hosted on TDM ACDs. For IPCC agents, warm transfers are also supported. However, it should be noted that in this case the H.323 signaling is daisy-chained through the Cisco CallManager once the warm transfer has been completed by the agent.  From the customer's perspective, this means that the original caller's line appearance remains on the first agent's desktop application until the caller eventually hangs up. It also means that auto-answer will not function properly for the first agent, since she still appears to be talking to the caller.

Distributed: Ingress/VXML Gateway and VoiceXML Server at branch

When this model is extended to a distributed gateway architecture, all the points mentioned in model 3a must be considered. In addition, since the CVP VoiceXML Server and ASR/TTS are now involved, we must also consider the points described in model 1.

For example, the VoiceXML Server might be either centralized or located at the branch, and ASR is not supported unless the ASR servers can be co-located with the VXML gateways wherever they are placed. Finally, if the solution involves internal IP calls from the branch to the central office or to another branch office, these calls are not currently supported with ASR.

Model #4, NIC-based Call Control with CVP Queue, Collect and Self Service

This section covers the following topics:

Customer Requirements

Caller Experience

Characteristics

Components

Protocol Level Call Flow

Customer Requirements

The customer has an existing PGW (PSTN Gateway) or TDM Intelligent Network for call control, and wants to use CVP as a network IVR or network self-service platform.

Caller Experience

Caller experience can be any of those described in models Model #2, CVP Call Control, Model #3a, CVP Call Control with Queue and Collect or Model #3b, CVP Call Control with Queue and Self Service.

Characteristics

This model is characterized by the fact that all call control is performed through the NIC.  CVP is only involved for the purpose of doing VRU treatment (ie.,queueing, collecting caller-input, or self service). Self service applications can be simple or complex, involving DTMF and/or ASR/TTS, and calls can be queued and transferred to agents. Blind network transfers are possible, subject to availability in the particular call control platform to which the NIC is connected.

Note that PGW deployments connecting to ICM via the Generic SS7 NIC fall into this category, Models 2 and 3 apply when the PGW delivers H.323 calls to the CVP Call Server.

Components

Required components:

Ingress/VXML gateways

CVP Call Servers

ICM

Optional components:

CVP VoiceXML Servers

Media Servers

ASR/TTS Servers

Content Services Switch

Protocol Level Call Flow

In this deployment model the call control is performed by a voice network switching platform connected to the ICM typically via an SS7 or CRSP NIC.

The steps involved in handling a typical inbound call are described below. In this scenario, the call receives initial IVR treatment, possibly involving queuing messages, and is transferred to a final destination.

1. A call is delivered to the voice network switching platform.

2. The switching platform sends a new call indication to the ICM.

3. The ICM identifies the call from the dialed number and selects a routing script to process the call. The script is executed and the call is sent to the VRU for call treatment using a translation route or label plus Correlation ID depending on the ICM VRU type being used in this deployment. The selection of VRU type is determined by placement of the VRU at NAM or CICM level and the ability of the switching platform to support use of a Correlation ID.

4. The connect-to-VRU message is sent from the ICM to the switching platform.

5. The switching platform connects the incoming call to the voice gateway.

6. Call arrives at the ingress gateway via a TDM connection. The gateway performs normal inbound pots dial-peer matching. (Note that in the case of the PGW being used in this deployment model this step involves delivery of an H.323 call to a VXML gateway and matching of a VoIP dial-peer)

7. Selected dial-peer invokes CVP TCL script.

8. TCL script invokes CVP VXML bootstrap document, which performs an HTTP request to the configured CSS VIP address for the primary CVP Call Server.

9. CSS selects an available CVP Call Server to process the call. The CSS is only used for the initial http request to the CVP Call Server as subsequent requests from the gateway use the IP address of the CVP Call Server explicitly.

10. The CVP Call Server sends a Request-Instruction message to the ICM, which correlates this VRU call leg with the script that performed the Send/Translation Route to VRU operation.

11. The ICM script resumes and the IVR dialogue commences.

12. The ICM sends a Run External Script to the CVP Call Server specifying the CVP microapp to be executed.

13. The CVP Call Server sends a dynamically generated VoiceXML Document to the voice gateway.

14. The gateway parses and renders the VoiceXML document.

15. This document might contain either VXML elements for speech output and caller input, or it might invoke a sub-dialogue with a destination URL that references another VXML server, typically a CVP VoiceXML Server, in order to incorporate self service modules into the overall dialogue.

16. In the latter case, the IVR dialogue continues between the gateway and the VXML server as defined in Model #3b (see Model #3b, CVP Call Control with Queue and Self Service).

17. On completion of the self-service operations defined in the VoiceXML Document, the gateway sends another http request to the CVP Call Server containing the results.

18. The CVP Call Server forwards the outcome to ICM using a Run Script Results message.

19. Further Run External Script nodes are executed in the ICM script until the IVR dialogue is completed.

20. At this point the call might either be terminated or transferred to a call center agent or other destination.

21. To terminate the call, the ICM sends a disconnect message to the switching platform.

22. Alternatively, to transfer the call to another destination, the ICM sends a connect message to the switching platform which will result in disconnection of the VRU call leg from the voice/VXML gateway and connection of a new transferred leg to the selected target.

23. Subsequently, depending on the capability set of the switching platform and the ability of the destination to perform a route request to ICM, the caller could be returned to CVP for further IVR treatment and queuing.