IVR-Based Outbound Dialer Troubleshooting
Available Languages
Contents
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.
This is an example of the calculation involved:
- UCCX sends a SIP invite to the gateway (T1)
- Gateway sends a ISDN call setup to service provider and onto cell provider (T2)
- Cell phone rings and starts its no answer timer (T3)
- 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.
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).
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
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
Revision History
| Revision | Publish Date | Comments |
|---|---|---|
1.0 |
24-Sep-2013 |
Initial Release |
FeedbackContact Cisco
- Open a Support Case
- (Requires a Cisco Service Contract)