协作 : Cisco Unified Contact Center Express

基于IVR的Outbound Dialer排除故障

2016 年 10 月 24 日 - 机器翻译
其他版本: PDFpdf | 英语 (2015 年 8 月 22 日) | 反馈

简介

本文描述基于IVR的Outbound Dialer并且包括一个示例SIP网关配置、日志分析从SIP网关和Cisco Unified Contact Center Express (UCCX)引擎和基于IVR的Outbound Dialer的限制。

在UCCX 8.5中, Outbound Dialer新类型介绍:交互语音应答(IVR) -基于Outbound Dialer。不同于更旧的预览Outbound Dialer,代理程序没有用于做呼出。UCCX在客户企业中连接直接地到一个会话初始化协议(SIP)网关拨号出站联系方式。当网关检测一个实际语音或应答机时,呼叫重定向到UCCX触发一定对呼出控制组。一旦终止在出站计算机电话集成(CTI)端口,用触发关联的应用程序被执行作为正常。

贡献由赖安LaFountain, Abhiram Kramadhati和Dave Bicknell, Cisco TAC工程师。

功能信息

在UCCX版本中早于8.5,仅预览Outbound Dialer存在。此拨号程序通过Java电话应用可编程接口(JTAPI) /CTI使用三方呼叫控制指示座席的电话做呼叫。呼叫在代理程序以后被做了接受出站预约。客户端和服务器之间的交互作用出站预约的通过CTI是实现的。

对于某些用途案件(例如约会提醒和自助IVR应用程序),预览Outbound Dialer不是好适应。当发出了时,要做呼叫到在DialingList的一个编号,代理程序附加呼叫。那含义代理程序为每呼出占用,即使Public Switched Telephony Network (PSTN)编号是无效,忙碌或者导致应答机。这高层次代理程序利用率是预览Outbound Dialer主要缺点这些使用案件的。

基于IVR的呼出流

对于同样使用事例(约会提醒和自助IVR应用程序)在基于IVR的Outbound Dialer,代理程序在呼叫流不也许涉及。这是IVR根据Outbound Dialer的呼叫流:

  1. 出站IVR拨号器确定联系方式数量拨号(如对算法定义)并且使用SIP通过语音网关发出呼出。
  2. 语音网关检测非Live联系方式以其呼叫过程分析(CPA)功能并且发送非Live联系方式的状况对拨号程序。拨号程序更新在配置数据库的联系方式状态信息。
  3. 语音网关检测生活联系方式以其CPA功能并且发送生活联系方式的状况对拨号程序。拨号程序更新在配置数据库的联系方式状态信息并且发送SIP参考消息SIP网关,反过来,转移呼叫到在Cisco Unified Communications Manager (CUCM)的已配置的CTI路由点。
  4. CUCM转移呼叫到思科UCCX服务器的一个IVR端口。
  5. IVR子系统连结呼叫与IVR应用程序关联与活动。引擎开始应用程序的执行,并且IVR会话发生在对活动的IVR申请在UCCX和用户联系之间。

基于IVR的拨号程序类型

有IVR根据出站拨号程序的两种类型,预测和渐进。因为UCCX只转移呼叫到IVR端口执行脚本,当一实际语音(或可配置应答机)时检测,假设是合理的,没有每出站联系方式要求端口。为了平衡机会CTI端口是需要的振铃无应答的可能性(RNA),忙碌和无效号码情况存在,预测和渐进拨号程序修改每次被做已配置的出站CTI端口数量呼出的数量。

一预测基于IVR的Outbound Dialer有这些功能:

  • 每个端口的线路数可以根据放弃呼叫费率被调整。
  • 人工干预不是需要的。
  • 目标是拨号足够的线路保持IVR端口忙碌,但是不超出配置的最大值放弃呼叫费率。

一渐进基于IVR的Outbound Dialer有这些功能:

  • 您能指定为每个可用的出站IVR端口总是拨号线路的固定数量的。
  • 线路数可以以后更新。
  • 如果有每个端口的三条线路,并且端口专用的数量出站的是三,则九呼叫(3x3)拨号。
  • 放弃的呼叫发生,当客户回答电话,但是端口不是可用提示客户。
  • 您能定义默认设置。

有UCCX的拨号程序组件

提取所有功能和内部子系统考虑此新的基于IVR的Outbound Dialer。在新的拨号程序的系统组件,类似引擎和DialingList表,是相同的正如在预览Outbound Dialer,与已添加的扩展(类似更多callStatus和callResult值)。

网关功能信息

为了支持实际语音的检测,应答机和特殊信息提示音(请坐),网关必须支持CPA功能。请使用Cisco Feature Navigator为了确定支持SIP拨号程序和CPA的网关Cisco IOS版本;请使用‘维护性支持的‘搜索由功能’搜索SIP拨号程序和呼叫过程分析的’。

CPA如何工作?

有在CPA的三个主要功能:

  • 应答机检测(AMD)
  • 传真/modem检测
  • 终止信号音检测的应答机

有实现的复杂算法由一个功能支架点做这些差异,但是, :

  • 一实际当事人答案预计是一短的问候语,然后期限沉默。
    示例:“Hello” +沉默
    示例:“Hello,约翰逊住宅” +沉默
  • 应答机预计是一更加长的问候语,然后没有沉默。
    示例:“您到达了米勒的住宅,在嘟声以后请留下消息”
  • 终止音的应答机检测预计是应答机、然后沉默,然后一终止的音的检测。
  • 传真检测是传真音的识别。

能力做这些差异也许是困难,因此您也许需要调整时钟参数为了优化配置。

要考虑的另一个要素是移动电话供应商也许有多种度呼叫的演示的之间延迟到他们,信元的呼叫的位置和演示对信元。

这是介入的计算的示例:

  1. UCCX发送SIP邀请到网关(T1)
  2. 网关发送设置的ISDN呼叫对服务提供商和在信元供应商(T2)上
  3. 移动电话不敲响并且启动其答案计时器(T3)
  4. 信元RNA计时器超时并且转发对语音邮件(T4)

如果假设,信元的RNA计时器是15秒,为呼叫将采取对信元转发到语音邮件的实际金额时间是(T1 + T2 + T3 + 15)。T1 +采取提交呼叫到输送路线或其他非信元设备的T2 + T3高于时间可能显着。

因此,当您不定义了活动的时答案环限速,时间需要是足够长到达移动电话的语音邮件系统;这是所需的行为,例如,打算的活动的留下消息。

注意:CPA是网关的功能;不同于Cisco Unified Contact Center Enterprise (UCCE), CPA不可能启用开/关在UCCX。当CPA在网关时可以被关闭,思科不推荐此。欲知更多信息,参考呼叫过程Analyis概述

IOS网关代码的选择是超出本文的范围之外。网关代码必须支持CPA和SIP拨号程序使用基于IVR的Outbound Dialer。Cisco Feature Navigator可帮助您查找符合功能需求的IOS版本。总是请保证您的IOS版本是与与此网关呼应的所有组件兼容。

故障排除

注意:使用命令查找工具仅限注册用户)可获取有关本部分所使用命令的详细信息。

为了排除故障出站IVR,请确定网关、CUCM或者UCCX是否是应负责任的。一旦离析问题特定组件,故障排除是更加容易。从系统组件收集此信息是有用的

对于网关,请运行这些命令:

  1. show tech
  2. 调试ccsip消息
  3. debug voip ccapi inout
  4. debug isdn q931 (或捕获PSTN侧信令的相似的调试)
  5. debug voip hpi全部(排除故障CPA)
  6. debug voip vtsp全部(排除故障CPA)

UCCX、复核日志文件和配置:

  1. 有SS_OB调试和XDebug1的MIVR日志文件-启用的XDebug3
  2. JTAPI日志文件(排除故障参考的呼叫失败)
  3. 从UCCX Appadmin的SIP网关配置

CUCM,复核配置:

  1. 详细的CallManager
  2. 详细的CtiManager
  3. 指向网关的SIP中继配置使用了出站IVR

数据分析

SIP网关必须不仅包含必要的配置从UCCX路由呼叫请求到PSTN,而且处理那些呼叫转移到选定的UCCX触发出站的。此SIP网关配置必须有:

  1. 匹配从UCCX的流入SIP请求的呼入拨号对端。
  2. (VoIP或普通旧式电话服务[POTS])路由呼叫的呼出拨号对端对PSTN。
  3. 路由重定向的(参考的)呼叫的呼出拨号对端(VoIP)对集成与UCCX的CUCM集群。

必须配置CUCM服务器收到从SIP网关(参考的呼叫)的入站SIP呼叫请求和相应地路由请求到UCCX触发和UCCX呼叫控制组CTI端口。

示例SIP网关配置

这是一个SIP网关配置的示例与符号的。在本例中的PSTN连接是ISDN基本速率接口(PRI)。

注意:支持Time Division Multiplexing (TDM) PSTN连接的其他类型,但是不支持Cisco Unified Border Element (多维数据集)。请参阅Cisco Bug ID CSCui62525CSCuf44826关于多维数据集支持的更多信息。支持对TDM PSTN的多个连接路由不同的类呼叫(本地,长距离,国际)到不同的中继或供应商。

RyanIVRRouter#show run
Building configuration...

为ISDN PRI配置的T1控制器

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

为ISDN PRI配置的Serial interfaces

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

路由的呼出语音端口对PSTN

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

呼入VoIP拨号对等体

此从UCCX的拨号对端匹配流入SIP呼叫请求。如果呼入VoIP拨号对等体没有配置,默认拨号对端(dial-peer 0)匹配。是最佳实践定义和匹配呼入VoIP拨号对等体。此dial-peer通知在从UCCX的入站SIP段将使用的编码、协议和双音多频(DTMF)中继的网关。

此拨号对端匹配全部从717开始,并且是长10个的位的入站SIP邀请与数字号码识别服务(DNIS)。在本例中,所有由UCCX与已拨号联系在717区域代码并且有电话号码长10个的位。

!
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路由呼叫对在以前配置的PRI的PSTN。它是呼叫请求来自UCCX的和呼出拨号对端的流出拨号对等体以上的VoIP拨号对等体的100。此dial-peer也起一呼入拨号对端作用对于对于测试目的来自PSTN的呼叫。在UCCX Outbound Dialer呼叫流,此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
!

出局的VoIP拨号对等体

此dial-peer担当SIP网关需要的呼出拨号对端路由呼叫到被注定的CUCM集群UCCX触发的。网关用于此dial-peer路由UCCX发送的REFER,当实际语音(或应答机时,如果配置存在)检测。此dial-peer定义了协议、DTMF中继、SIP网关应该路由重定向呼叫CUCM节点的编码和IP地址。为冗余和负载均衡的目的,此类型的多个拨号对等体也许存在。他们能分成到对多个CUCM节点的路由请求在集群或设置路由某些触发的重定向到另外CUCM节点。

在本例中, IVR根据出站市场活动的UCCX触发是2001年和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
!

示例IVR根据呼出痕量分析

这是一本示例消息传送日志的详细分析在SIP网关、UCCX和PSTN之间的。

初始从UCCX邀请指示网关做呼叫到PSTN编号。邀请包含呼叫ID,可以用于跟踪所有消息关联与此呼叫和会话描述协议(SDP) (媒体参数)。

更加重要地,邀请包括网关应该使用完成CPA的参数。在UCCX AppAdmin页配置,但是UCCX没有使用这些参数。相反,在邀请发送到网关并且网关用于他们配置数字信号处理器(DSP)此呼叫的CPA的。结果,这些参数发送到网关在每呼叫的基础上并且可以从Appadmin在任何时间更改。

UCCX发送这些CPA配置属性到每呼叫的网关:

参数名 参数值 建议的值
最低的沉默期限(100 - 1000)* 毫秒 375
分析期限(1000 - 10000)* 毫秒 2500
最大时间分析(1000 - 10000)* 毫秒 3000
最低的有效语音时间(50 - 500)* 毫秒 112
最大期限音分析(1000 - 60000)* 毫秒 15000

可配置的值在SIP Gateway Configuration页的Appadmin被提交。

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

当呼叫通过网关的dial-peer处理, UCCX发送'100 Trying消息。

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

当呼出匹配呼出拨号对端时,使用已配置的TDM协议,发送对PSTN。在这种情况下,使用PRI :

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

呼叫过程和信令交换在PSTN和网关之间。网关通知PSTN电话响与警报消息。

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

网关送回183会话进展到UCCX通知UCCX PSTN电话响。这包括回令音的媒体协商的SDP。

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

呼叫在TDM段连接作为PSTN电话应答了呼叫。网关发送在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

网关通知UCCX呼叫连接以200 OK。据SIP RFC要求的UCCX ACK这。200 OK也包含媒体协商的SDP,但是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
...

网关检测与CPA的呼叫过程并且通过一系列的更新消息通知呼叫过程的UCCX。据SIP RFC要求的UCCS ACK这。

在本例中SIP更新的,事件‘检测’,并且状态是‘CpaS’。

  • CpaS表明CPA开始。
  • 当应答机检测时,状态是‘Asm’。
  • 当应答机音合格时,状态是‘AsmT’。

此表列出用于SIP更新消息的x思科CPA状态码:

名称 定义

FT

传真/modem音。

Asm

答案计算机。

AsmT

答案计算机终止音。

LS

生活人的语音。

SitIC

坐音ICS -截取-闲置没有或AIS或者那么。

SitNC

坐音NC -没有电路、紧急或者中继阻止

SitVC

坐音VC -闲置代码

SitRO

坐音RO -重拨通告

SitMT

混杂请坐音

CpaS

CPA开始

LV

低音量或断线呼叫

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发送通知到网关重定向呼叫到触发分配到此出站活动。网关ACK这。

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

网关必须路由此呼叫到新建目标作为处理所有的正常呼叫通过网关的dial-peer。

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)

呼叫由网关路由根据在呼出拨号对端的配置匹配在内包含的目的地的参考。

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

示例MIVR日志分析

从MIVR日志的这些片断提供呼叫的概述从UCCX方面。使这些调试级别获取正确信息:

  • SS_OB - Debug,XD1,XD2,XD3
  • SS_RM - Debug,XDebug1
  • CFG_MGR - Debug,XDebug1 (如果问题是正在拨号列表记录)
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

注意:因为也许同时有多个市场活动,注意campaignID和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
.

这是格式化的和未编排的电话号码:

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 )

SIP信令开始:

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

验证这些消息处理在网关的有以前解释的网关消息传送的。

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&colon;
incrementAttemptedCalls() by 1. Total attempted calls = 1
//Since this is the first time the record is dialled out, the total attempted calls = 1

网关与CPA消息一起传送SIP更新消息。CPA软件在网关运行并且分析从被叫方的实时传输协议(RTP)。这帮助区分在语音和应答机之间在被叫方末端。您能通过‘application/x思科CPA’其内容类型鉴别CPA SIP更新消息。

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

常见问题

CPA没有从网关发送到UCCX

在呼叫连接与PSTN主叫方后,消息不被退还的对UCCX由表明的网关CPA完成,并且呼叫发生了(实际语音,忙碌,应答机,等等)。确保在网关技术支持CPA的IOS版本。调查网关验证CPA适当地操作。

呼叫没有重定向对UCCX在检测的Live语音以后

验证网关有匹配UCCX触发拨叫号码(DN)分配到活动的dial-peer。验证从网关的一呼叫能路由到该CTI路由点/在CUCM的触发。

重试次数没有拨号

类似于在预览Outbound Dialer的回拨,如果接收RNA或忙碌的呼叫没有再试,请验证这些记录在DialingList表里正确地被标记作为重试次数。从MIVR日志验证呼叫尝试被做在指定的回拨或重试次数时间。

DTMF不工作,当连接对IVR脚本

验证DTMF适当地协商在CUCM和网关之间,并且已命名dial-peer匹配(dial-peer 0不包含DTMF中继配置)。UCCX通过JTAPI只支持带外DTMF,因此一些网关类型和呼叫流也许要求将被调用的媒介终接点(MTP)完成相互作用的DTMF。调查网关验证网关,并且CUCM适当地处理DTMF请求和协商。

相关信息



Document ID: 116084