基于IVR的Outbound Dialer排除故障

下载选项

PDF (427.8 KB)
在各种设备上使用 Adobe Reader 查看
ePub (244.4 KB)
在 iPhone、iPad、Android、Sony Reader 或 Windows Phone 上使用各种应用查看
Mobi (Kindle) (175.8 KB)
在 Kindle 设备上查看或在多个设备上使用 Kindle 应用查看

已更新: 2013 年 9 月 24 日

文档 ID:116084

非歧视性语言

此产品的文档集力求使用非歧视性语言。在本文档集中，非歧视性语言是指不隐含针对年龄、残障、性别、种族身份、族群身份、性取向、社会经济地位和交叉性的歧视的语言。由于产品软件的用户界面中使用的硬编码语言、基于 RFP 文档使用的语言或引用的第三方产品使用的语言，文档中可能无法确保完全使用非歧视性语言。深入了解思科如何使用包容性语言。

关于此翻译

思科采用人工翻译与机器翻译相结合的方式将此文档翻译成不同语言，希望全球的用户都能通过各自的语言得到支持性的内容。请注意：即使是最好的机器翻译，其准确度也不及专业翻译人员的水平。 Cisco Systems, Inc. 对于翻译的准确性不承担任何责任，并建议您总是参考英文原始文档（已提供链接）。

Introduction

功能信息

基于IVR的outbound呼叫流

基于IVR的拨号程序类型

与UCCX的拨号程序组件

网关功能信息

Troubleshoot

数据分析

示例SIP网关配置

示例IVR根据outbound呼叫跟踪分析

示例MIVR日志分析

常见问题

CPA没有从网关被发送到UCCX

呼叫没有重定向对UCCX在被发现的实际语音以后

重试次数没有拨号

DTMF不工作，当连接到IVR脚本

Related Information

Introduction

本文描述基于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)网关拨打outbound联系。当网关发现一个实际语音或应答机时，呼叫重定向对UCCX触发器一定对一outbound呼叫控制组。一旦终止在outbound计算机电话集成(CTI)端口，与触发器产生关联的应用程序被执行作为正常。

功能信息

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

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

基于IVR的outbound呼叫流

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

outbound IVR拨号器确定联系的数量拨号(如对算法定义)并且使用SIP通过语音网关拨打出局访问。
语音网关发现非实际联系以其呼叫进展分析(CPA)功能并且发送非实际联系的状况到拨号程序。拨号程序更新在配置数据库的联系状态信息。
语音网关发现实际联系以其CPA功能并且发送实际联系的状况到拨号程序。拨号程序更新在配置数据库的联系状态信息并且发送SIP参考消息SIP网关，反过来，转移呼叫到在Cisco Unified通信管理器(CUCM)的被配置的CTI路由点。
CUCM转移呼叫到在Cisco UCCX服务器的一个IVR端口。
IVR子系统连结呼叫与与活动产生关联的IVR应用程序。引擎开始应用程序的执行，并且IVR会话发生在对活动的IVR申请在UCCX和用户联系之间。

基于IVR的拨号程序类型

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

一预计基于IVR的Outbound Dialer有这些功能：

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

一累进基于IVR的Outbound Dialer有这些功能：

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

与UCCX的拨号程序组件

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

网关功能信息

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

CPA如何工作？

有在CPA的三个主要功能：

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

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

一个实际当事人答案预计是短的称呼，然后沉默的周期。
示例：“Hello” +沉默
示例：“Hello，约翰逊住宅” +沉默
应答机预计是更长的称呼，然后没有沉默。
示例：“您到达了米勒的住宅，在嘟声以后请留下消息”
终止语音的应答机发现预计是应答机，然后沉默的检测，然后终止的语音。
传真发现是传真语音的识别。

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

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

这是介入的计算的示例：

UCCX发送SIP邀请到网关(T1)
网关发送一个ISDN呼叫建立到服务提供商和在信元供应商(T2)上
移动电话不敲响并且启动其答案计时器(T3)
信元RNA计时器到期并且转发到语音邮件(T4)

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

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

Note:CPA是网关的功能;不同于Cisco Unified Contact Center Enterprise (UCCE)， CPA不可能启用开/关在UCCX。当CPA在网关时可以被关闭， Cisco不推荐此。欲知更多信息，请参见呼叫进展Analyis概述。

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

Troubleshoot

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

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

对于网关，请运行这些命令：

show tech
调试ccsip消息
debug voip ccapi inout
debug isdn q931 (或捕获PSTN边信令的相似的调试)
debug voip hpi全部(排除CPA故障)
debug voip vtsp全部(排除CPA故障)

UCCX，复核日志文件和配置：

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

CUCM，复核配置：

详细的呼叫管理器
详细的CtiManager
SIP指向网关的中继线配置使用了outbound IVR

数据分析

SIP网关必须不仅包含必要的配置从UCCX路由呼号要求到PSTN，而且处理那些呼叫转移到outbound选定的UCCX触发器。此SIP网关配置必须有：

匹配自UCCX的流入SIP请求的入站拨号点。
(VoIP或无格式老电话业务[POTS])路由呼叫的出局拨号对等体对PSTN。
路由重定向的(参考的)呼叫的出局拨号对等体(VoIP)对集成UCCX的CUCM簇。

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

示例SIP网关配置

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

Note:支持Time Division Multiplexing (TDM) PSTN连接的其他类型，但是不支持Cisco Unified Border Element (多维数据集)。请参阅Cisco Bug ID CSCui62525和CSCuf44826关于多维数据集技术支持的更多信息。支持与TDM PSTN的多个连接路由不同的组呼叫(本地，长距离，国际)到不同的Trunk或供应商。

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拨号对等体，默认拨号对端(拨号点0)被匹配。是最佳实践定义和匹配入站VoIP拨号对等体。此拨号点通知在从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拨号点

此拨号点路由呼叫对在早先配置的PRI的PSTN。它是来自UCCX的呼号要求的流出的拨号点和以上的VoIP拨号对等体的100出局拨号对等体。此拨号点也起一个入站拨号点作用对于对于测试目的来自PSTN的呼叫。在UCCX Outbound Dialer呼叫流，此拨号点没有被匹配作为一个入站拨号点。

!
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拨号对等体

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

在本例中， IVR根据outbound市场活动的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根据outbound呼叫跟踪分析

这是对在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--

当呼叫通过网关的拨号点处理，发送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。UCCX ACKs这，据SIP RFC要求。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。UCCS ACKs这，据SIP RFC要求。

在本例中SIP更新的， ‘发现事件’，并且状态是‘CpaS’。

CpaS表明CPA开始了。
当发现时应答机，状态是‘Asm’。
当应答机语音合格时，状态是‘AsmT’。

此表列出用于SIP更新消息的x cisco CPA状态码：

名字	定义
FT	传真/modem语音。
Asm	答案机器。
AsmT	答案机器终止语音。
LS	生活人的语音。
SitIC	坐语音ICS -截取-闲置没有或AIS或者那么。
SitNC	坐语音NC -没有电路、紧急状态或者Trunk阻止
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发送一个通知到网关重定向呼叫到触发器分配到此outbound活动。网关ACKs这。

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

网关必须路由此呼叫到新建目标作为所有正常呼叫处理通过在网关的拨号点。

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方面。Enable (event)获取正确的信息的这些调试级别：

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

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

这是格式化的和未编排的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 )

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 cisco 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在被发现的实际语音以后

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

重试次数没有拨号

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

DTMF不工作，当连接到IVR脚本

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

Related Information

Technical Support & Documentation - Cisco Systems

由思科工程师提供

Ryan LaFountain, Abhiram Kramadhati, and Dave Bicknell
Cisco TAC Engineers.

基于IVR的Outbound Dialer排除故障

下载选项

非歧视性语言

关于此翻译

Contents

Introduction

功能信息

基于IVR的outbound呼叫流

基于IVR的拨号程序类型

与UCCX的拨号程序组件

网关功能信息

CPA如何工作？

Troubleshoot

数据分析

示例SIP网关配置

为ISDN PRI配置的T1控制器

为ISDN PRI配置的Serial interfaces

路由的出局访问语音端口对PSTN

入站VoIP拨号对等体

POTS拨号点

outbound VoIP拨号对等体

示例IVR根据outbound呼叫跟踪分析

示例MIVR日志分析

常见问题

CPA没有从网关被发送到UCCX

呼叫没有重定向对UCCX在被发现的实际语音以后

重试次数没有拨号

DTMF不工作，当连接到IVR脚本

Related Information

由思科工程师提供

此文档是否有帮助?

联系我们

本文档适用于以下产品