To get device statistics:

To add a Call Server:

Services Needed for CVP Call Flow Models

Choose the desired call flow model, and then select the required call services in the Call Server Configuration window:

The Comprehensive call flow model combines the Call Director and the VRU-Only scenarios. It provides initial prompt and collect, self-service IVR, queuing, and VoIP routing among all types of UCCE and TDM agents. This scenario is supported at two port licensing levels: Basic and Advanced. The Basic level supports the playing of .wav files and input using DTMF. The Advanced level adds support for ASR, TTS, and Unified CVP VXML Server applications.

Unified CVP provides ICM with VRU services for calls which are routed in some other manner, such as by a carrier switched network through an ICM NIC interface. VRU services could be for initial prompt and collect, for integrated self service applications, for queuing, or for any combination thereof. This scenario does not use SIP, and requires no Ingress Gateway. It does use VXML Gateways, but the Unified CVP VXML Server is optional, as are ASR and TTS Servers.

Depending on which kind of routing client is in charge of call routing, ICM may transfer the call to the VRU-Only Call Server either by a Translation Route to VRU node, or by a Send To VRU node. In the first case, the Call Server will determine that the arriving call is a VRU leg call by matching the arriving DNIS with its configured list of arriving DNIS numbers. In the second case, it will determine that it is a VRU leg call because the DNIS length is greater than its configured maximum DNIS length. Digits beyond the maximum DNIS length are taken as the Correlation ID.

In Call Director using SIP, Unified CVP provides ICME with VoIP call routing capabilities only. Use your own Service Control VRU if you are using an ICM Server to queue calls, or queue calls directly on an ACD. Calls can be transferred multiple times, from Ingress, to customer-provided VRU, to either UCCE or customer-provided ACD or agent, and back again. When calls are connected to customer-provided equipment, their voice paths must go to an Egress gateway which is connected by TDM to that equipment. If the signaling is SIP, then Unified CVP will work with customer-provided SIP endpoints which have been tested and certified to interoperate with Unified CVP. Neither Unified CVP VXML Server nor any VXML Gateways are used in this model.

In this call flow model, the call server with the ICM Service enabled is required to route calls. The Reporting server is optional. Use a Reporting server if you want to generate reports that include Unified CVP VXML Server events. You can also use the ICM request label from the Unified CVP VXML Server to an ICM Server, if the ICM service is enabled on the Call Server. The Reporting server can be installed on the same physical machine as the Call Server. After you configure the Call Server, you must configure the Unified CVP VXML Server. See Unified CVP VXML Server Setup.

The RequestICMLabel is a feature that allows you to make back-end requests to an ICM Server without relinquishing control of the call. The application generally acts on its own, but includes a special step to send a query to the ICM Server and receive a response. The query and the response may contain full call context information, as can the response.

Following are the features of the IVR application :

• An IVR application can request an ICM server to select an available UCCE or ACD agent to which the call should be transferred. Full call context is preserved during the transfer, but queuing is not possible.
• An IVR application can transfer its call to a separate full-blown Unified CVP system for agent selection and queuing. Full call context is preserved throughout.
• An IVR application can request an ICM server to perform a calculation or application gateway transaction that it already knows how to perform, and return the result to the application.
• An IVR application can report intermediate or final call data to an ICM server to be stored in its database.

In this call flow model, the Call Server is used to route messages between the components. Calls arrive through a VXML gateway, and interact directly with a Unified CVP VXML Server to execute VXML applications. The gateway performs both ingress and VXML functions. This call flow model provides a sophisticated VXML-based VRU, for applications which in many cases do not need to interact with an ICM Server.

For a Unified CVP VXML Server (standalone) with no connection to an ICM Server and no Reporting Server, configure the Call Server with no services enabled. If you need to make requests to an ICM server, without relinquishing control of the call or use Unified CVP reporting, you must configure the VXML Server to use a Call Server with at least the ICM Service enabled. See Unified CVP VXML Server Setup.

After you configure the Call Server, you must configure the Unified CVP VXML Server as a Unified CVP VXML Server (standalone). See Unified CVP VXML Server (Standalone) Setup.

The Basic Video call flow model combines the Call Director and the VRU-Only call flow models, along with video capabilities that are only enabled during the caller-agent conversation. It provides initial prompt and collect, self-service IVR, queuing, and VoIP routing among UCCE and TDM agents.

Note

This call flow model is almost identical to the Unified CVP Comprehensive SIP call flow model. The only change between the two call flow models is the addition of video-enabled endpoints for the calling and called parties (Cisco Unified Video Advantage (CUVA), Cisco Unified Personal Communicator (CUPC), and Cisco TelePresence). See the Configuration Guide for Cisco Unified Customer Voice Portal for additional information about CUVA and Cisco Telepresence.

When you are adding a Call Server, you must configure the call services required for the call flow model you are using.

• SIP Service - Session Initiation Protocol (SIP), RFC 3261, is the primary call control protocol in Unified CVP. The SIP Service uses SIP to communicate with other Unified CVP solution components, such as the SIP Proxy Server, the VXML and Ingress Gateways, and Cisco Unified Communications Manager SIP trunks and SIP phones.
• IVR Service - Creates the VXML pages that implement the Unified CVP Micro-applications, based on Run Script instructions received from an ICM server. The IVR service functions as the Voice Response Unit (VRU) leg, and calls must be transferred to it from the SIP Service in order to execute micro-applications. The VXML pages created by this module are sent to the VXML Gateway to be executed.
• ICM Service - Enables communication between Unified CVP components and the ICM server. It sends and receives messages on behalf of the SIP Service, the IVR Service, and the VXML Service.

You must configure the ICM service if you are adding or editing a Call Server and you are using any of these call flow models:

The following table describes the property settings that you can change to configure the ICM Service. The first time you configure the ICM Service on a Call Server, you must restart the Call Server. You must also restart the server if you change a configuration setting that has been marked yes in the restart required column in the table below.

The following table describes the property settings that you can change to configure the IVR Service.

• Call Director
• Comprehensive

Session Initiation Protocol (SIP), RFC 3261, is the primary call control protocol in Unified CVP. The SIP Service uses SIP to communicate with other Unified CVP solution components, such as the SIP Proxy Server, the VXML and Ingress Gateways, and Cisco Unified Communications Manager SIP trunks and SIP phones.

The following table describes the properties that you can set to configure the SIP Service. The first time you configure the SIP service on a Call Server, you must restart the Call Server.

Configuration

Enable Outbound Proxy

Use DNS SRV type query

Select Yes to use DNS SRV for outbound proxy lookup. Otherwise, select No. See Load-Balancing SIP Calls for information on using DNS SRV for load-balancing SIP calls.

Note	If you enable Resolve SRV records locally, you must select Yes to ensure the feature works properly.

Default	Range	Restart Required
No	Yes and No	Yes

Resolve SRV records locally

Select to resolve the SRV domain name with a local configuration file instead of a DNS Server.

Note	If you enable Resolve SRV records locally, you must select Yes to use DNS SRV type query. Otherwise, this feature will not work.

Outbound Proxy Host

Outbound SRV domain name/Server group name (FQDN)

If you use a hostname that is an SRV type record instead of a standard DNS type record, this field contains a fully qualified domain name that is configured on the DNS server. Otherwise, the field contains an SRV configuration file.

DN on the Gateway to Play the Ringtone

Dialed Number (DN) configured on the gateway to play ringtone (dedicated VoIP dial peer).

DN on the Gateway to Play the Error Tone

Dialed Number (DN) configured on the gateway to play the error.wav file (dedicated VoIP dial peer).

Override System Dialed Number Pattern Configuration

QoS

Select QoS Level

Select the Quality of Service (QoS) level between the SIP Service and the SIP Proxy Server.

Note	For more information, see the Enterprise QoS Solution Reference Network Design Guide.

Default	Range	Restart Required
cs3	The drop-down list has the following values: af11, af12, af13, af21, af22, af23, af31, af32, af33, af41, af42, af43, cs1, cs2, cs3, cs4, cs5, cs6, cs7,default, ef	Yes

Post Call Survey DNIS Mapping

Incoming Call Dialed Number (DN)

Survey Dialed Number (DN)

Local Static Routes

Static Routes for Local Routing Without an Outbound Proxy (see View SIP Server Groups) .

Dialed Number (DN)

Creates a Static Proxy Route Configuration Table. You must create static routes if you do not use a SIP Proxy Server. Before adding a local static route, you must enter a value into both the Dialed Number (DN) and IP Address fields so that the local static route is complete.

Click Add to create a proxy route using the Dialed Number (DN) and the IP address/Hostname entered above the Add button. The newly created proxy route is added to the list of proxy routes displayed in the box below the Add button.

IP Address/Hostname/Server Group Name

The IP address, hostname, or server group SRV domain name.

Note	If you use Server Group Name, you must select Yes to use DNS SRV type query and you must enable Resolve SRV records locally to ensure the feature works properly.

Default	Range	Restart Required
None	Valid IP address, hostname, or SRV domain name	No

Dialed Number (DN) Patterns

Patterns for sending calls to the originator :

Dialed Number (DN)

Creates a SIP Send Back to Originator Lookup Table. Specify the DN patterns to match for sending the call back to the originating gateway for VXML treatment. For the Unified CVP branch model, use this field to automatically route incoming calls to the Call Server from the gateway back to the originating gateway at the branch. For information on the Unified CVP branch model, see Planning Guide for Cisco Unified Customer Voice Portal.

This setting overrides sending the call to the outbound proxy or to any locally configured static routes. It is also limited to calls from the IOS gateway SIP "User Agent" because it checks the incoming invite's User Agent header value to verify this information. If the label returned from ICM for the transfer matches one of the patterns specified in this field, the call is routed to sip:<label>@<host portion of from header of incoming invite>.

Three types of DNs work with Send To Originator: VRU label returned from ICM, Agent label returned from ICM, and Ringtone label.

Send To Originator does not work for the error message DN because the inbound error message is played by survivability and the post-route error message is a SIP REFER. (Send To Originator does not work for REFER transfers).

Note	For Send To Originator to work properly, the call must be TDM originated and have survivability configured on the pots dial peer.

Default	Range	Restart Required
None	See Valid Formats for Dialed Numbers for more information.	No

Patterns for RNA timeout on outbound SIP calls:

- Dialed Number (DN)

Creates a Dialed Number (DN) pattern outbound invite timeout using the DN and Timeout entered above the Add button. Click Add to add the newly created DN pattern outbound invite timeout to the list displayed in the box below the Add button.

Timeout (Seconds)

The number of seconds the SIP Service waits for transferee to answer the phone or accept the call.

Custom ringtone patterns:

Dialed Number (DN)

Specify a custom Dialed Number (DN) pattern. Click Add to add the newly created DN pattern to the list displayed in the box below the Add button.

Ringtone Media file name

The file name of the ringtone to be played for the respective dialed number.

SIP Header Passing (to ICM)

Header Name

Parameter

Post Call Survey DNIS Mapping

Incoming Call Dialed Number (DN)

Survey Dialed Number (DN)

UDP is the default transport in high availability SIP deployments. One of the drawbacks of TCP is the slow response times encountered in transmission failures due to network outages. The slow response times for TCP are caused by slowness in detecting a connection reset in applications running on other SIP devices in the network. This slowness is due to the buffering window of the TCP connection. Higher call loads fill the buffer faster and thus the notification of a connection down with an I/O exception arrives more quickly. Lower call loads or a test with a single call can be affected by as much as a 30-second delay or more. Invite Retry Counts and Retry Timeout settings are not effective when using TCP transport on SIP calls because of the persistent nature of the TCP connection.

For SIP RFC, use TCP transport in deployments in which packet sizes exceed 1300 bytes, the size of a Maximum Transmission Unit (MTU). Using UDP, if a SIP message exceeds 1300 bytes, then it might fragment and cause problems with delivery and message ordering. See Section 18.1.1 Sending Requests in RFC 3261. A SIP packet can exceed 1 MTU for various reasons; for example, if there are many Via headers, or the media portion is very large in bytes.

While the SIP Request For Comments (RFC) mandates the support of both TCP and UDP, not all SIP User Agents support TCP. However, the Unified CVP SIP Service, IOS Gateway, and Cisco Unified Communications Manager use both transport protocols.

SIP calls can be load balanced across destinations in several different ways:

• Using the CUSP, define several static routes with the same route pattern and priorities and weights.
• Using DNS, configure SRV records with priorities and weights. A proxy server is not necessary in this method, but both the DNS client and the server settings must be configured and operating successfully for DNS "A" and "SRV" type queries to work. Configure SRV queries to be used wherever outbound SIP calls are made, such as on the IOS Ingress gateway, on the Call Server itself, and on Cisco Unified CM.

Valid dialed number patterns are the same as for the ICM label sizes and limitations, including:

• Use the period (.) or the X character for single-digit wildcard matching in any position.
• Use the greater than (), asterisk (*), or exclamation (!) character as a wildcard for 0 or more digits at the trailing end of a DN.
• Do not use the character T for wildcard matching.
• Dialed numbers must not be longer than 24 characters.
• The highest precedence of pattern matching is an exact match, followed by the most specific wildcard match. When the number of characters are matched equally by more than one wildcarded pattern, precedence is given from top to bottom of the configured DN list.