IVR-Based Outbound Dialer Troubleshooting

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:

1. 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.
2. 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.
3. 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).
4. The CUCM transfers the call to an IVR port on the Cisco UCCX server.
5. 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.

This is an example of the calculation involved:

1. UCCX sends a SIP invite to the gateway (T1)
2. Gateway sends a ISDN call setup to service provider and onto cell provider (T2)
3. Cell phone rings and starts its no answer timer (T3)
4. Cell RNA timer expires and forwards to voicemail (T4)

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

Note: Use the Command Lookup Tool (registered customers only) in order to obtain more information on the commands used in this section.

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:

1. show tech
2. debug ccsip messages
3. debug voip ccapi inout
4. debug isdn q931 (or similar debug to capture PSTN side signaling)
5. debug voip hpi all (to troubleshoot CPA)
6. debug voip vtsp all (to troubleshoot CPA)

For UCCX, review log files and configuration:

1. MIVR log files with SS_OB Debugging and XDebug1 - XDebug3 enabled
2. JTAPI log files (to troubleshoot REFERed call failure)
3. SIP gateway configuration from UCCX AppAdmin

For the CUCM, review configurations:

1. Detailed CallManager
2. Detailed CTIManager
3. 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:

1. Inbound dial-peers to match incoming SIP requests from UCCX.
2. Outbound dial-peers (either VoIP or plain old telephone service [POTS]) to route calls to the PSTN.
3. 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.

RyanIVRRouter#show run
Building configuration...

T1 Controller Configured for ISDN PRI

!
controller T1 0/0/0
 cablelength long 0db
 pri-group timeslots 1-24
!

Serial Interface Configured for ISDN PRI

!
interface Serial0/0/0:23
 no ip address
 encapsulation hdlc
 isdn switch-type primary-ni
 isdn incoming-voice voice
 no cdp enable
!

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.

!
dial-peer voice 100 voip
 description -- Outbound Calls From UCCX -- 
 session protocol sipv2
 incoming called-number 717.......
 dtmf-relay rtp-nte
 codec g711ulaw
!

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.

!
dial-peer voice 10 pots
 description -- POTS Dial Peer To/From PSTN Simulator --
 destination-pattern 717.......
 incoming called-number .
 direct-inward-dial
 port 0/0/0:23
 forward-digits all
!

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.

!
dial-peer voice 102 voip
 description -- Redirect Calls to UCCX 90 --
 destination-pattern 200[1-2]
 session protocol sipv2
 session target ipv4:14.10.166.15
 incoming called-number 200[1-2]
 dtmf-relay rtp-nte
 codec g711ulaw
!

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.

Received: 
INVITE sip:7175551212@14.10.153.56:5060;transport=udp SIP/2.0
...
Call-ID: 134401919546410@14.10.166.16
...
Content-Type: multipart/mixed;boundary=unique_boundary

--unique_boundary
Content-Type: application/sdp
Content-Disposition: session;handling=required

v=0
o=Cisco-UCCX 1608 1 IN IP4 14.10.166.16
s=SIP Call
c=IN IP4 0.0.0.0
t=0 0
m=audio 12345 RTP/AVP 0 
a=rtpmap:0 PCMU/8000
a=ptime:20
--unique_boundary
Content-Type: application/x-cisco-cpa
Content-Disposition: signal;handling=optional

Events=FT,Asm,AsmT,Sit
CPAMinSilencePeriod=375
CPAAnalysisPeriod=2500
CPAMaxTimeAnalysis=3000
CPAMinValidSpeechTime=112
CPAMaxTermToneAnalysis=15000
--unique_boundary--

As the call is processing through the dial-peers of the gateway, UCCX is sent a '100 Trying' message.

Sent: 
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 14.10.166.16:5065;branch=z9hG4bKEsF4FAHPTVliP0ozE1BcOQ~~17
From: <sip:9195551212@14.10.166.16>;tag=dsa994554a
To: <sip:7175551212@14.10.153.56>
Date: Fri, 03 Aug 2012 18:38:46 GMT
Call-ID: 134401919546410@14.10.166.16
CSeq: 100 INVITE
Allow-Events: telephone-event
Server: Cisco-SIPGateway/IOS-12.x
Content-Length: 0

When the outbound call matches an outbound dial-peer, it is sent to the PSTN using the configured TDM protocol. In this case, a PRI is used:

Aug  3 18:38:46.559: ISDN Se0/0/0:23 Q931: TX -> SETUP pd = 8  callref = 0x008D 
	Bearer Capability i = 0x8090A2 
		Standard = CCITT 
		Transfer Capability = Speech  
		Transfer Mode = Circuit 
		Transfer Rate = 64 kbit/s 
	Channel ID i = 0xA98397 
		Exclusive, Channel 23 
	Calling Party Number i = 0x2180, '9195551212' 
		Plan:ISDN, Type:National
 	Called Party Number i = 0xA1, '7175551212' 
		Plan:ISDN, Type:National

The call progresses and signaling is exchanged between the PSTN and the gateway. The gateway is notified that the PSTN phone is ringing with the ALERTING message.

Aug  3 18:38:46.595: ISDN Se0/0/0:23 Q931: RX <- CALL_PROC pd = 8  callref = 0x808D 
	Channel ID i = 0xA98397 
		Exclusive, Channel 23

Aug  3 18:38:46.603: ISDN Se0/0/0:23 Q931: RX <- ALERTING pd = 8  callref = 0x808D 
    Progress Ind i = 0x8188 - In-band info or appropriate now available

The gateway sends a 183 Session Progress back to UCCX to notify UCCX that the PSTN phone is ringing. This includes SDP for media negotiation of the ringback tones.

Sent: 
SIP/2.0 183 Session Progress
...
Call-ID: 134401919546410@14.10.166.16
...
--uniqueBoundary
Content-Type: application/sdp
Content-Disposition: session;handling=required

v=0
o=CiscoSystemsSIP-GW-UserAgent 7343 9805 IN IP4 14.10.153.56
s=SIP Call
c=IN IP4 14.10.153.56
t=0 0
m=audio 32330 RTP/AVP 0 101 19
c=IN IP4 14.10.153.56
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=rtpmap:19 CN/8000
a=ptime:20
...
--uniqueBoundary
Content-Type: application/x-cisco-cpa
Content-Disposition: signal;handling=optional

event=enabled
--uniqueBoundary--

The call is connected on the TDM leg as the PSTN phone answered the call. The gateway sends a confirmation in the CONNECT_ACK.

Aug  3 18:38:49.207: ISDN Se0/0/0:23 Q931: RX <- CONNECT pd = 8  callref = 0x808D

Aug  3 18:38:49.211: ISDN Se0/0/0:23 Q931: TX -> CONNECT_ACK pd = 8  callref = 0x008D

The gateway notifies UCCX that the call is connected with a 200 OK. UCCX ACKs this, as required by the SIP RFC. The 200 OK also contains SDP for media negotiation, but it is not used by UCCX.

Sent: 
SIP/2.0 200 OK
...
Call-ID: 134401919546410@14.10.166.16
...
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 271

v=0
o=CiscoSystemsSIP-GW-UserAgent 7343 9805 IN IP4 14.10.153.56
s=SIP Call
c=IN IP4 14.10.153.56
t=0 0
m=audio 32330 RTP/AVP 0 101 19
c=IN IP4 14.10.153.56
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=rtpmap:19 CN/8000
a=ptime:20

Received: 
ACK sip:7175551212@14.10.153.56:5060 SIP/2.0
...
Call-ID: 134401919546410@14.10.166.16
...

The gateway detects the call progress with CPA and notifies UCCX of the call progress through a series of UPDATE messages. UCCS ACKs this, as required by the SIP RFC.

In this example of a SIP update, the event is 'Detected' and the status is 'CpaS'.

• CpaS indicates that the CPA has begun.
• When an answering machine is detected, the status is 'Asm.'
• When the answering machine tone is qualified, the status is 'AsmT.'

This table lists the x-cisco-cpa status codes used in the SIP update messages:

Name	Definition
FT	Fax/Modem tone.
Asm	Answer Machine.
AsmT	Answer Machine Terminate Tone.
LS	Live human speech.
SitIC	SIT tone IC - Intercept - Vacant No. or AIS or so forth.
SitNC	SIT tone NC - No Circuit, Emergency or Trunk Blockage
SitVC	SIT tone VC - Vacant Code
SitRO	SIT tone RO - Reorder Announcement
SitMT	Misc SIT Tone
CpaS	Start of CPA
LV	Low volume or dead air call

Sent: 
UPDATE sip:9195551212@14.10.166.16:5065;transport=udp SIP/2.0
...
Call-ID: 134401919546410@14.10.166.16
...
Content-Type: application/x-cisco-cpa
Content-Disposition: signal;handling=optional
Content-Length: 26

event=detected
status=CpaS

Received: 
SIP/2.0 200 Ok
...
Call-ID: 134401919546410@14.10.166.16
...

UCCX sends a notification to the gateway to redirect the call to the trigger assigned to this outbound campaign. The gateway ACKs this.

Received: 
REFER sip:7175551212@14.10.153.56:5060 SIP/2.0
...
Call-ID: 134401919546410@14.10.166.16
...
Refer-To: <sip:2001@14.10.153.56>
...

Sent: 
SIP/2.0 202 Accepted
...
Call-ID: 134401919546410@14.10.166.16
...

The gateway must route this call to the new destination as any normal call processing through the dial-peers on the gateway.

Aug  3 18:39:07.275: //60/7120520F060E/CCAPI/ccCallSetupRequest:
   Destination=, Calling IE Present=FALSE, Mode=0,
   Outgoing Dial-peer=102, Params=0x31BDB494, Progress Indication=NULL(0)

The call is routed by the gateway based upon the configuration in the outbound dial-peer matched for the destination contained within the REFER.

Sent: 
INVITE sip:2001@14.10.166.15:5060 SIP/2.0
...
Call-ID: 5789DBCB-DCD111E1-8081ADFE-F735B3DC@14.10.153.56
...
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 270

v=0
o=CiscoSystemsSIP-GW-UserAgent 5187 301 IN IP4 14.10.153.56
s=SIP Call
c=IN IP4 14.10.153.56
t=0 0
m=audio 25002 RTP/AVP 0 101 19
c=IN IP4 14.10.153.56
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=rtpmap:19 CN/8000
a=ptime:20

Sample MIVR Log Analysis

These snippets from an MIVR log provide an overview of the call from a UCCX perspective. Enable these debug levels to capture the correct information:

• SS_OB - Debug,XD1,XD2,XD3
• SS_RM - Debug,XDebug1
• CFG_MGR - Debug,XDebug1 (if the issue is with dialing list records)
  

135533948: Aug 20 21:34:54.631 EDT %MIVR-CFG_MGR-7-UNK:ConfigManagerImpl-getAll():CIR
[0]=ConfigImportRecord[schema=DialingListConfig#2,time=2012-08-20 21:34:42.0,
recordId=239,implClass=class com.cisco.crs.outbound.DialingListConfig,desc=,
values=[239, 2, 1662760, NAME, TEST777, 9785551212, , , 343, true, -1, true, -1, true, , 
2012-08-20 21:34:42.0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, null, null, null, null],evalues=null]
//Import the record from the dialing list. In this case, the recordID=239


135533949: Aug 20 21:34:54.632 EDT %MIVR-CFG_MGR-7-UNK:ConfigManagerImpl-getAll():con
figObjs[0]=DialingListConfig[schema=DialingListConfig#2,time=2012-08-20 21:34:42.0,
recordId=239,desc=,recordID=0,dialingListID=239,campaignID=2,accountNumber=1662760,
firstName=NAME,lastName=TEST777,phone01=9785551212,phone02=,phone03=,gmtZonePhone01=343,
dstPhone01=true,gmtZonePhone02=-1,dstPhone02=true,gmtZonePhone03=-1,dstPhone03=true,
callbackNumber=,callbackDateTime=2012-08-20 21:34:42.0,callStatus=1,callResult=0,
callResult01=0,callResult02=0,callResult03=0,lastNumberDialed=0,callsMadeToPhone01=0,
callsMadeToPhone02=0,callsMadeToPhone03=0,numMissedCallback=0,isRetries=false]
//RecordID=239; campaignID=2

Note: Since there might be multiple campaigns at the same time, it is important to pay attention to the campaignID and recordID.

B-7-UNK:CMgrUtil: getPhoneNumber: callStatus=2callResult=0lastNumDialed=0

135534103: Aug 20 21:34:55.424 EDT %MIVR-SS_OB-7-UNK:CMgrUtil: getPhoneNumber: 
   callStatus=2callResult=0lastNumDialed=0
135534104: Aug 20 21:34:55.424 EDT %MIVR-SS_OB-7-UNK:CMgrUtil: getUnformattedPhoneNumber: 
   dlcID:239
135534105: Aug 20 21:34:55.425 EDT %MIVR-SS_OB-7-UNK:CMgrUtil: getFormattedPhoneNumber: 
   phoneNum=9785551212
135534106: Aug 20 21:34:55.425 EDT %MIVR-SS_OB-7-UNK:CMgrUtil: getFormattedPhoneNumber: 
   intPrefix= localAreaCode = 416 lenAreaCode = 3 include lac = true dialingPrefix = 9 
   longDistPrefix = 91
135534107: Aug 20 21:34:55.425 EDT %MIVR-SS_OB-7-UNK:CMgrUtil.getFormattedPhoneNumber(): 
   domestic number
135534108: Aug 20 21:34:55.425 EDT %MIVR-SS_OB-7-UNK:CMgrUtil.getFormattedPhoneNumber(): 
   long distance number
135534109: Aug 20 21:34:55.425 EDT %MIVR-SS_OB-7-UNK:numToDial=9919785551212
135534110: Aug 20 21:34:55.425 EDT %MIVR-SS_OB-7-UNK:CMgrUtil: getUnformattedPhoneNumber: 
   dlcID:239
135534111: Aug 20 21:34:55.425 EDT %MIVR-SS_OB-7-UNK:CMgrUtil.getTimeZoneId - 
   phoneNum=9785551212
135534112: Aug 20 21:34:55.425 EDT %MIVR-SS_OB-7-UNK:CMgrUtil: getGmtOffset: 
   DST observed=true
135534113: Aug 20 21:34:55.425 EDT %MIVR-SS_OB-7-UNK:CMgrUtil.getTimeZoneId - 
   phoneNum=9785551212

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

135534128: Aug 20 21:34:55.425 EDT %MIVR-SS_OB-7-UNK:OutboundIVRContactsRequestor: 
Contacts returned from CampaignMgr for campaignID:2 are [OutboundContactInfo: dlc:239 
(phoneNumber:9919785551212 unformattedPhoneNumber:9785551212 timezone -240 
callStartTime 0 answeringMachine false ) ]
//phoneNumber:9919785551212; unformattedPhoneNumber:9785551212. 

Here are the formatted and unformatted phoneNumbers:

135534131: Aug 20 21:34:55.425 EDT %MIVR-SS_OB-7-UNK:IVRDialer:findValidContact() - 
processing contact in queue OutboundContactInfo: dlc:239 (phoneNumber:9919785551212 
unformattedPhoneNumber:9785551212 timezone -240 callStartTime 0 answeringMachine false )

The SIP signalling starts:

SIP-9919785551212  INVITE sip:9919785551212@10.10.10.7:5060;transport=udp SIP/2.0

SIP-9919785551212  SIP/2.0 100 Trying

SIP-9919785551212  SIP/2.0 183 Session Progress

SIP-9919785551212  SIP/2.0 200 OK

Verify the handling of these messages on the gateway with the gateway messaging explained previously.

135534720: Aug 20 21:34:58.809 EDT %MIVR-SS_OB-7-UNK:ProcessAccepted: DialerSipCall-68, 
State=CONTACTING, fromDN=8005553434, toDN=9919785551212, 
callId=134551289542668@10.10.10.5 sending
 
SIP-9919785551212  ACK sip:9919785551212@10.10.10.7:5060 SIP/2.0

135534722: Aug 20 21:34:58.810 EDT %MIVR-SS_OB-7-UNK:OnConnectionCompleted DialerSipCall-68,
State=ACTIVE, fromDN=8005553434, toDN=9919785551212, callId=134551289542668@10.10.10.5 
notify 
com.cisco.wf.subsystems.outbound.SIPAdapterCallListenerImpl@1b91fa4.onConnectionCompleted()
//The initial SIP signalling is completed

135534723: Aug 20 21:34:58.810 EDT %MIVR-SS_OB-7-UNK:SIPAdapterCallListenerImpl.
onConnectionCompleted post OutboundPlaceGWCallRespMsg: GWCall:  dlcID: 239, csqID: -1, 
contactNumToDial:9919785551212false, dialerType:IVR_DIALER, DialerSipCall-68, State=ACTIVE, 
fromDN=8005553434, toDN=9919785551212, callId=134551289542668@10.10.10.5, status=OK
//The outbound subsystem posts the 'Place call' request to the gateway

135534724: Aug 20 21:34:58.810 EDT %MIVR-SS_OB-7-UNK:OutboundDialerProcessor:Processing msg: 
OutboundPlaceGWCallRespMsg: GWCall:  dlcID: 239, csqID: -1, 
contactNumToDial:9919785551212false, dialerType:IVR_DIALER, DialerSipCall-68, State=ACTIVE, 
fromDN=8005553434, toDN=9919785551212, callId=134551289542668@10.10.10.5, 
status=OK135534725: Aug 20 21:34:58.810 EDT 
%MIVR-SS_OB-7-UNK:IVRDialer:ProcessOutboundPlaceGWCallRespMsg: 
OutboundPlaceGWCallRespMsg: GWCall:  dlcID: 239, csqID: -1, 
contactNumToDial:9919785551212false, dialerType:IVR_DIALER, 
DialerSipCall-68, State=ACTIVE, fromDN=8005553434, toDN=9919785551212, 
callId=134551289542668@10.10.10.5, status=OK
//The OutboundPlaceCall request is processed by the Outbound Dialer, then by the IVR 
Dialer processes
135534728: Aug 20 21:34:58.810 EDT %MIVR-SS_OB-7-UNK:CampaignStatistics:
incrementAttemptedCalls() for phoneNumber=9919785551212 to 1
135534729: Aug 20 21:34:58.810 EDT %MIVR-SS_OB-7-UNK:HalfHourCampaignData:
incrementAttemptedCalls() by 1. Total attempted calls = 1
//Since this is the first time the record is dialled out, the total attempted calls = 1

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

SIP-9919785551212  UPDATE sip:8005553434@10.10.10.5:5060;transport=udp SIP/2.0
SIP-9919785551212  Via: SIP/2.0/UDP 10.10.10.7:5060;branch=z9hG4bK2362542
SIP-9919785551212  Max-Forwards: 69
SIP-9919785551212  To: <sip:8005553434@10.10.10.5>;tag=dsaf56bbcc
SIP-9919785551212  From: <sip:9919785551212@10.10.10.7>;tag=3D33950C-948
SIP-9919785551212  Call-ID: 134551289542668@10.10.10.5
SIP-9919785551212  CSeq: 102 UPDATE
SIP-9919785551212  Content-Length: 26
SIP-9919785551212  Date: Tue, 21 Aug 2012 01:34:58 GMT
SIP-9919785551212  User-Agent: Cisco-SIPGateway/IOS-15.2.4.M1
SIP-9919785551212  Supported: timer,resource-priority,replaces,sdp-anat
SIP-9919785551212  Timestamp: 1345512899
SIP-9919785551212  Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE,
    NOTIFY, INFO, REGISTER
SIP-9919785551212  Contact: <sip:9919785551212@10.10.10.7:5060>
SIP-9919785551212  Min-SE: 1800
SIP-9919785551212  Content-Type: application/x-cisco-cpa
SIP-9919785551212  Content-Disposition: signal;handling=optional
SIP-9919785551212  
SIP-9919785551212  event=detected
SIP-9919785551212  status=CpaS

SIP-9919785551212  UPDATE sip:8005553434@10.10.10.5:5060;transport=udp SIP/2.0
SIP-9919785551212  Via: SIP/2.0/UDP 10.10.10.7:5060;branch=z9hG4bK23714F6
SIP-9919785551212  Max-Forwards: 69
SIP-9919785551212  To: <sip:8005553434@10.10.10.5>;tag=dsaf56bbcc
SIP-9919785551212  From: <sip:9919785551212@10.10.10.7>;tag=3D33950C-948
SIP-9919785551212  Call-ID: 134551289542668@10.10.10.5
SIP-9919785551212  CSeq: 103 UPDATE
SIP-9919785551212  Content-Length: 163
SIP-9919785551212  Date: Tue, 21 Aug 2012 01:34:58 GMT
SIP-9919785551212  User-Agent: Cisco-SIPGateway/IOS-15.2.4.M1
SIP-9919785551212  Supported: timer,resource-priority,replaces,sdp-anat
SIP-9919785551212  Timestamp: 1345512902
SIP-9919785551212  Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE,
    NOTIFY, INFO, REGISTER
SIP-9919785551212  Contact: <sip:9919785551212@10.10.10.7:5060>
SIP-9919785551212  Min-SE: 1800
SIP-9919785551212  Content-Type: application/x-cisco-cpa
SIP-9919785551212  Content-Disposition: signal;handling=optional
SIP-9919785551212  
SIP-9919785551212  event=detected
SIP-9919785551212  status=LV
SIP-9919785551212  pickupT=320
SIP-9919785551212  maxActGlitchT=0
SIP-9919785551212  numActGlitch=0
SIP-9919785551212  valSpeechT=20
SIP-9919785551212  maxPSSGlitchT=0
SIP-9919785551212  numPSSGlitch=0
SIP-9919785551212  silenceP=0
SIP-9919785551212  termToneDetT=0
SIP-9919785551212  noiseTH=1000
SIP-9919785551212  actTh=32000

//This shows that Low Volume is detected. Now, based on the Campaign setting 'Handle Low 
Volume as Voice,' this call is handled accordingly

135535726: Aug 20 21:35:02.036 EDT %MIVR-SS_OB-7-UNK:OnCPAStatus DialerSipCall-68, 
State=ACTIVE, fromDN=8005553434, toDN=9919785551212, callId=134551289542668@10.10.10.5 
notify com.cisco.wf.subsystems.outbound.SIPAdapterCallListenerImpl@1b91fa4.onCPAStatus
(status=LowVolume)
135535727: Aug 20 21:35:02.036 EDT %MIVR-SS_OB-7-UNK:SIPAdapterCallListenerImpl.onCPAStatus 
post OutboundUpdateGWCallStatusMsg: GWCall:  dlcID: 239, csqID: -1, 
contactNumToDial:9919785551212false, dialerType:IVR_DIALER, DialerSipCall-68, State=ACTIVE, 
fromDN=8005553434, toDN=9919785551212, callId=134551289542668@10.10.10.5, status=LowVolume
135535728: Aug 20 21:35:02.036 EDT %MIVR-SS_OB-7-UNK:OutboundDialerProcessor:Processing msg: 
OutboundUpdateGWCallStatusMsg: GWCall:  dlcID: 239, csqID: -1, 
contactNumToDial:9919785551212false, dialerType:IVR_DIALER, DialerSipCall-68, State=ACTIVE, 
fromDN=8005553434, toDN=9919785551212, callId=134551289542668@10.10.10.5, status=LowVolume
135535729: Aug 20 21:35:02.036 EDT %MIVR-SS_OB-7-UNK:IVRDialer:
ProcessOutboundUpdateGWCallStatusMsg: OutboundUpdateGWCallStatusMsg: GWCall:  dlcID: 239, 
csqID: -1, contactNumToDial:9919785551212false, dialerType:IVR_DIALER, DialerSipCall-68, 
State=ACTIVE, fromDN=8005553434, toDN=9919785551212, callId=134551289542668@10.10.10.5, 
status=LowVolume
135535730: Aug 20 21:35:02.036 EDT %MIVR-SS_OB-7-UNK:IVRDialer:
ProcessOutboundUpdateGWCallStatusMsg(): Low Volume detected
135535731: Aug 20 21:35:02.036 EDT %MIVR-SS_OB-7-UNK:IVRDialer:
ProcessOutboundUpdateGWCallStatusMsg(): Handle Low Volume as Voice is true
135535732: Aug 20 21:35:02.036 EDT %MIVR-SS_OB-7-UNK:IVRDialer:
ProcessOutboundUpdateGWCallStatusMsg(): PostingOutboundIVRUpdateContactMsg with 
callstatus = 3(Closed), callresult = 1(Low Volume) for dlcID = 239

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.

Related Information

• Technical Support & Documentation - Cisco Systems