Introduction

This document describes the IVR-Based Outbound Dialer and includes a sample SIP gateway configuration, log analyses from both the SIP gateway and the Cisco Unified Contact Center Express (UCCX) engine, and the limitations of the IVR-Based Outbound Dialer.

In UCCX 8.5, a new type of outbound dialer was introduced: the Interactive Voice Response (IVR)-Based Outbound Dialer. Unlike the older Preview Outbound Dialer, no agent is used to make the outbound call. UCCX connects directly to a Session Initiation Protocol (SIP) gateway in the customer enterprise to dial the outbound contacts. When the gateway detects a live voice or answering machine, the call is redirected to a UCCX trigger bound to an outbound call control group. Once terminated on the outbound computer telephony integration (CTI) port, the application associated with the trigger is executed as normal.

Feature Information

In UCCX versions earlier than 8.5, only the Preview Outbound Dialer existed. This dialer used third-party call control via Java Telephony Application Programming Interface (JTAPI)/CTI to instruct the agent's phone to make the call. The call was made after an agent accepted an outbound reservation. The interaction between the client and server for outbound reservations was accomplished via CTI.

For certain use cases (such as appointment reminders and self-service IVR applications), the Preview Outbound Dialer was not a good fit. To make a call to a number in the DialingList, an agent was tied up while the call was placed. That meant the agent was occupied for each and every outbound call, even if the Public Switched Telephony Network (PSTN) number was invalid, busy or resulted in an answering machine. This high level of agent utilization was a major drawback of Preview Outbound Dialer for these use cases.

IVR-Based Outbound Call Flow

For the same use cases (appointment reminders and self-service IVR applications) in the IVR-Based Outbound Dialer, an agent might never be involved in the call flow. This is the call flow for IVR-Based Outbound Dialer:

The outbound IVR dialer determines the number of contacts to dial (as defined in the algorithm) and uses SIP to place outbound calls through the voice gateway.

The voice gateway detects non-live contact with its Call Progress Analysis (CPA) capabilities and sends the status of the non-live contact to the dialer. The dialer updates the contact status information in the configuration database.

The voice gateway detects live contact with its CPA capabilities and sends the status of the live contact to the dialer. The dialer updates the contact status information in the configuration database and also sends a SIP refer message to the SIP gateway, which, in turn, transfers the call to the configured CTI route point on the Cisco Unified Communications Manager (CUCM).

The CUCM transfers the call to an IVR port on the Cisco UCCX server.

The IVR subsystem associates the call with the IVR application associated with the campaign. The engine starts execution of the application and an IVR session takes place between the IVR application for the campaign on UCCX and the customer contact.

IVR-Based Dialer Types

There are two types of IVR-Based Outbound Dialers, predictive and progressive. Since UCCX only transfers a call to an IVR port to execute a script when a live voice (or configurable answering machine) is detected, it is reasonable to assume that not every outbound contact requires a port. In order to balance the chance that a CTI port is needed against the probability that Ring No Answer (RNA), busy and invalid number situations exist, predictive and progressive dialers modify the number of outbound calls that are made at a time against the number of configured outbound CTI ports.

A predictive IVR-Based Outbound Dialer has these features:

The number of lines for each port can be tuned, based upon the abandon call rate.

No manual intervention is needed.

The goal is to dial enough lines to keep the IVR ports busy but not to exceed the configured maximum abandon call rate.

A progressive IVR-Based Outbound Dialer has these features:

You can specify a fixed number of lines that are always dialed for each available outbound IVR port.

The number of lines can be updated at a later date.

If there are three lines for each port and the dedicated number of ports for outbound is three, then nine calls (3x3) are dialed.

An abandoned call occurs when a customer answers the phone, but no port is available to prompt the customer.

You can define default settings.

Dialer Components with UCCX

All functionality and internal subsystems are abstracted to account for this new IVR-Based Outbound Dialer. System components in the new dialer, like the Engine and DialingList table, are the same as in the Preview Outbound Dialer, with extensions (like more callStatus and callResult values) added.

Gateway Feature Information

In order to support detection of live voice, answering machine and special information tones (SIT), the gateway must support the CPA feature. Use the Cisco Feature Navigator in order to determine the gateway Cisco IOS® versions that support SIP dialer and CPA; use the 'Search by Feature' search for 'Serviceability support for SIP dialer and Call Progress Analysis.'

How does CPA work?

There are three primary functions in CPA:

Answering machine detection (AMD)

Fax/modem detection

Answering machine terminating tone detection

There are complex algorithms implemented to make these distinctions, but, from a functional stand point:

A live party answer is expected to be a short salutation, then a period of silence. Example: "Hello" + silence Example: "Hello, Johnson residence" + silence

An answering machine is expected to be a longer salutation, then no silence. Example: "You've reached the Miller's residence, please leave a message after the beep"

An answering machine terminating tone detect is expected to be detection of the answering machine, then silence, then a terminating tone.

A fax detect is recognition of the fax tone.

The ability to make these distinctions might be difficult, so you might need to adjust timing parameters in order to optimize the configuration.

Another factor to consider is that cell phone providers might have various degrees of delay beween presentation of a call to them, location of the cell, and presentation of the call to the cell itself.

If you assume that the RNA timer for the cell is 15 seconds, the actual amount of time it would take for a call to a cell to forward to voicemail is (T1 + T2 + T3 + 15). T1 + T2 + T3 could be significantly higher than the amount of time it takes to present a call to a landline or other non-cell device.

Thus, when you define the No Answer ring limit for a campaign, the time period needs to be long enough to reach the voicemail system for cell phones; this would be the desired behavior, for example, for a campaign intended to leave a message.

Note: CPA is a functionality of the gateway; unlike Cisco Unified Contact Center Enterprise (UCCE), CPA cannot be turned on or off on UCCX. While CPA can be turned off on the gateway, Cisco does not recommend this. For more information, refer to Call Progress Analyis Overview.

Selection of IOS gateway codes is beyond the scope of this document. The gateway code must support CPA and SIP dialer to use IVR-Based Outbound Dialer. The Cisco Feature Navigator can help you find IOS releases that meet feature requirements. Always ensure your IOS release is compatible with all components that interact with this gateway.

Troubleshoot

In order to troubleshoot an Outbound IVR, determine if the gateway, CUCM or UCCX is at fault. Troubleshooting is easier once you isolate the problem to a specific component. It is helpful to collect this information from the system components

For the gateway, run these commands:

show tech

debug ccsip messages

debug voip ccapi inout

debug isdn q931 (or similar debug to capture PSTN side signaling)

debug voip hpi all (to troubleshoot CPA)

debug voip vtsp all (to troubleshoot CPA)

For UCCX, review log files and configuration:

MIVR log files with SS_OB Debugging and XDebug1 - XDebug3 enabled

JTAPI log files (to troubleshoot REFERed call failure)

SIP gateway configuration from UCCX AppAdmin

For the CUCM, review configurations:

Detailed CallManager

Detailed CTIManager

SIP trunk configuration that points to the gateway used for Outbound IVR

Data Analysis

The SIP gateway must contain the necessary configuration not only to route call requests from UCCX to the PSTN, but also to handle the transfer of those calls to the UCCX trigger designated for outbound. This SIP gateway configuration must have:

Inbound dial-peers to match incoming SIP requests from UCCX.

Outbound dial-peers (either VoIP or plain old telephone service [POTS]) to route calls to the PSTN.

Outbound dial-peers (VoIP) to route the redirected (REFERed) call to the CUCM cluster that is integrated with UCCX.

The CUCM server must be configured to receive inbound SIP call requests from the SIP gateway (the REFERed calls) and to route the requests accordingly to the UCCX trigger and the UCCX call control group CTI ports.

Sample SIP Gateway Configuration

This is an example of a SIP gateway configuration with notations. The PSTN connectivity in this example is ISDN Primary Rate Interface (PRI).

Note: Other types of time division multiplexing (TDM) PSTN connectivity are supported, but Cisco Unified Border Element (CUBE) is not supported. See Cisco bug IDs CSCui62525 and CSCuf44826 for more information on CUBE support. Multiple connections to the TDM PSTN are supported to route different classes of calls (local, long distance, international) to different trunks or providers.

Serial Interface Configured for ISDN PRI

Voice Port for Routing Outbound Calls to PSTN

!voice-port 0/0/0:23!

Inbound VoIP Dial-Peer

This dial-peer matches incoming SIP call requests from UCCX. If an inbound VoIP dial-peer is not configured, the default dial-peer (dial-peer 0) is matched. It is best practice to define and match an inbound VoIP dial-peer. This dial-peer notifies the gateway of the codec, protocol and dual-tone multifrequency (DTMF) relay to be used on the inbound SIP leg from UCCX.

This dial-peer matches all inbound SIP INVITEs with a Digital Number Identification Service (DNIS) that start with 717 and that are 10 digits long. In this example, all contacts dialed by UCCX are in the 717 area code and have phone numbers 10 digits long.

POTS Dial-Peer

This dial-peer routes calls to the PSTN over the PRI configured previously. It is the outgoing dial-peer for call requests coming from UCCX and the outbound dial-peer for VoIP dial-peer 100 above. This dial-peer also serves as an inbound dial-peer for calls coming from the PSTN for test purposes. In the UCCX outbound dialer call flow, this dial-peer is not matched as an inbound dial-peer.

Outbound VoIP Dial-Peer

This dial-peer serves as the outbound dial-peer needed by the SIP gateway to route calls to the CUCM cluster destined for the UCCX trigger. This dial-peer is used by the gateway to route the REFER sent by UCCX when live voice (or answering machine if the configuration exists) is detected. This dial-peer defines the protocol, DTMF relay, codec and IP address of the CUCM node where the SIP gateway should route the redirected call. For purposes of redundancy and load balancing, multiple dial-peers of this type might exist. They could be partitioned to route requests to multiple CUCM nodes in the cluster or be provisioned to route redirects for certain triggers to different CUCM nodes.

In this example, UCCX triggers for IVR-Based Outbound Campaigns are 2001 and 2002.

Sample IVR-Based Outbound Call Trace Analysis

This is a detailed analysis of an example messaging log between the SIP gateway, UCCX and the PSTN.

The initial INVITE from UCCX instructs the gateway to make a call to the PSTN number. The INVITE contains the Call-ID, which can be used to track all messages associated with this call, and the Session Description Protocol (SDP) (media parameters).

More importantly, the INVITE includes the parameters the gateway should use to complete CPA. These parameters are configured in the UCCX AppAdmin pages, but are not used by UCCX. Rather, they are sent in the INVITE to the gateway and used by the gateway to configure the digital signal processors (DSPs) for CPA for this call. As a result, these parameters are sent to the gateway on a per-call basis and can be changed at any time from AppAdmin.

UCCX sends these CPA configuration attributes to the gateway for each call:

Parameter Name

Parameter Value

Suggested Value

Minimum Silence Period (100 - 1000)*

Milliseconds

375

Analysis Period (1000 - 10000)*

Milliseconds

2500

Maximum Time Analysis (1000 - 10000)*

Milliseconds

3000

Minimum Valid Speech Time (50 - 500)*

Milliseconds

112

Maximum Term Tone Analysis (1000 - 60000)*

Milliseconds

15000

Configurable values are presented in AppAdmin on the SIP Gateway Configuration page.

//Based on the Campaign config, the phone number is modified accordingly. In a failed call scenario, you might want to verify what the number is after the formatting is done. Look for 'MIVR-SS_OB-7-UNK:numToDial=' which gives you the actual number to be dialed.

The gateway sends a SIP UPDATE message along with the CPA message. The CPA software runs on the gateway and analyzes the Real-Time Transport Protocol (RTP) from the called party. This helps differentiate between voice and answering machine at the called party end. You can identify a CPA SIP UPDATE message by its Content-Type of 'application/x-cisco-cpa'.

Common Problems

No CPA Is Sent from Gateway to UCCX

After the call is connected with the PSTN caller, no messages are sent back to UCCX by the gateway to indicate that CPA has been completed and that a call has resulted (live voice, busy, answering machine, and so forth). Make sure the IOS version on the gateway supports CPA. Investigate the gateway to verify CPA is operating properly.

Call is Not Redirected to UCCX After Live Voice Detected

Verify the gateway has a dial-peer that matches the UCCX trigger dialed number (DN) assigned to the campaign. Verify that a call from the gateway can route to that CTI route point/trigger in CUCM.

Retries are Not Dialed

Similar to callbacks in the Preview Outbound Dialer, if calls that receive RNA or busy are not retried, verify that these records are correctly marked as Retry in the DialingList table. Verify from the MIVR logs that the call attempt is being made at the specified callback or retry time.

DTMF Does Not Work When Connected to IVR Script

Verify that DTMF is negotiated properly between CUCM and the gateway and that named dial-peers are matched (dial-peer 0 does not contain DTMF relay configuration). UCCX only supports out-of-band DTMF via JTAPI, so some gateway types and call flows might require a Media Termination Point (MTP) to be invoked to complete DTMF interworking. Investigate the gateway to verify the gateway and CUCM are properly processing DTMF requests and negotiation.