语音和统一通信 : Cisco Unified Communications Manager (CallManager)

Cisco CallManager与传统语音邮件集成的故障排除

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


目录


简介

本文排除故障的老式语音信息处理系统的集成使用简单信息台界面(SMDI)和数字PBX适配器用Cisco CallManager (DPA) 7630/7610。

先决条件

要求

本文档的读者应掌握以下这些主题的相关知识:

  • Cisco CallManager 3.x 或 4.x

  • Telcordia GR 283-core问题2 (SMDI)

  • Octel语音邮件,如果适用(DPA -7630/7610)

使用的组件

本文档中的信息基于以下软件和硬件版本:

  • Cisco CallManager 3.x 和 4.x

  • Cisco MCS-7835

本文档中的信息都是基于特定实验室环境中的设备编写的。本文档中使用的所有设备最初均采用原始(默认)配置。如果您使用的是真实网络,请确保您已经了解所有命令的潜在影响。

规则

有关文档规则的详细信息,请参阅 Cisco 技术提示规则

SMDI集成用Cisco CallManager

Cisco信息处理接口是允许传统语音邮件平台连接到有使用的Cisco CallManager SMDI在Cisco CallManager内的一服务。Cisco信息处理接口提供信息给关于呼叫和主叫用户名详细资料的一个传统语音邮件系统,原因为什么提交呼叫,并且端口语音邮件系统应该期待呼叫。这允许语音邮件系统正确地应答呼叫。

有与SMDI的两种呼叫类型:

  • 直接呼叫

  • 转发呼叫

直接呼叫格式

直接呼叫SMDI格式是:

  • <CR><LF>MDXXXLLLLT<0x20>YYYY<0x20><CR><LF><^Y>

<CR> 回车
<LF> 换行
MDXXX 消息平台。这是3数字字段,通常001
LLLL 逻辑终端编号(0001 ?4096)
T 原因代码- D等于直接呼叫
<0x20> 空间
YYYY 主叫方编号
<0x20> 空间
<CR> 回车
<LF> 换行
<^Y> 记录媒体用完

这是一次直接呼叫的示例从分机的2000年。它被提交了对在LTN 0002的语音消息处理系统或者端口2。

  • <CR><LF>MD0010002D<0x20>2000<0x20><CR><LF><^Y>

排除故障直接呼叫

当呼叫方发出一次直接呼叫时,期望提示呼叫方输入他们的密码。为了那能发生,网关、路由列表和路由组对语音邮件系统必须配置作为配置集成的Cisco CallManager 3.0(x)对语音邮件系统通过SMDI描述。直接呼叫的多数常见原因能发生故障是在消息平台或逻辑终端编号(LTN)之间的一误配置。默认情况下Cisco信息处理接口使用消息平台001。如果由内部交换机(PBX)供应商或中心局给另一消息平台,您必须在Cisco信息处理接口配置里指定那。

smdi-1.gif

如果MessageDeskNumber正确,请验证LTN正确。在Cisco CallManager侧, LTN等同于到您在路由组中配置的端口。第一个端口是LTN 1,第二个端口是LTN 2,等等。这就是为什么配置波尔特和命令下拉列表框,因为配置集成的Cisco CallManager 3.0(x)对语音邮件系统通过SMDI是重要的描述。如果所有端口选择, Cisco信息处理接口生成的LTN是LTN 1。这导致失败的集成。在语音邮件侧,保证是重要的布线是正确在网关和语音邮件端口之间。因为SMDI消息指示哪个端口(LTN)呼叫被提交到语音邮件系统,所有第1层问题必须是解决的。

第二常见原因对语音邮件的一次直接呼叫为什么发生故障是VoiceMailPartition字段的误配置Cisco信息处理接口的。

/image/gif/paws/18779/smdi-2.gif

VoiceMailPartition字段需要包含分配到路由模式对路由列表的该点为语音邮件划分的名称。如果此信息不正确, VoiceMailDn的截取没有被触发,并且SMDI消息没有生成。结果,语音邮件系统没有处理的相应的信息如期望的一样呼叫,并且应答与一通用的问候语。

验证SMDI链路是UP在语音邮件侧,如果您的语音邮件系统取决于在此。Cisco CallManager在标准PC运行,含义有实际上配线到串行端口的九个管脚。然而, Cisco信息处理接口只使用三RS-232线路:TD、RD和GND。有两条出站控制线路:RTS和DTR。这些两个主张,当打开时端口,但是Cisco信息处理接口不关心,如果线路忽略。有四条流入控制线路:DCD、CTS、DSR和RI。所有这些线路也忽略。

从CMI的直接呼叫Trace

对于排除故障与SMDI的问题,请检查在C查找的Cisco信息处理接口跟踪文件:/Program文件/Cisco/Trace/CMI目录。

19:27:58.578 Cisco Messaging Interface|   CMISsapiClient::RecvSsCallInfoResMsg()
Received RecvSsCallInfoResMsg userdata = 5996360, Key = 7864, DSL2 = 2,
calledparty =3500, callingparty =2000
19:27:58.578 Cisco Messaging Interface|   CMISsapiClient::RecvSsCallInfoResMsg()
Direct Call port - 2, callingparty -2000
19:27:58.578 Cisco Messaging Interface|-->CMISsapiClient::SendDirectCall()
19:27:58.578 Cisco Messaging Interface|   CMISsapiClient::SendDirectCall()

这是一次直接呼叫的示例从分机的2000年。它被提交了对在LTN 0002的语音消息处理系统或者端口2。

  • 发送直接呼叫:[<CR><LF>MD0010002D<0x20>2000<0x20><CR><LF><^Y>]

一旦验证Cisco信息处理接口拦截VoiceMailDn并且生成SMDI消息,您能工作以语音邮件供应商保证消息接收。如果语音邮件系统不收到任何SMDI消息,即使Cisco信息处理接口生成他们,有超级终端的PC可以用于展示他们是否留下Cisco CallManager服务器。

转发呼叫格式

Cisco CallManager 3.0支持A向前原因代码所有呼叫转发的。在Cisco CallManager 3.1中和以后,原因代码B和N为忙碌和没有答案被添加,分别。

转发呼叫格式是:

  • <CR><LF>MDXXXLLLLTDDDDDDD<0x20>CCCCCCC<0x20><CR><LF><^Y>

<CR> 回车
<LF> 换行
MDXXX 消息平台。第xxx通常是001
LLLL 逻辑终端编号(0001 - 4096)
T 呼叫类型。A是转发的所有呼叫(支持由CM 3.0), B是忙碌转发(CM 3.1), N是为振铃无应答(CM 3.1)
DDDDDDD 被叫方
<0x20> 空间
CCCCCCC 主叫方
<0x20> 空间
<CR> 回车
<LF> 换行
<EM> 记录媒体用完

这是一次转发呼叫的示例从分机的2000年对分机2001年。因为被叫方的电话在一前转所有呼叫状态,呼叫被发送对语音邮件。呼叫被提交对在LTN 0002的语音消息处理系统或者端口2。

  • [<CR><LF>MD0010002A2001<0X20> 2000<0x20><CR><LF><^Y>]

排除故障转发呼叫

当呼叫方发出呼叫对另一个当事人和转发对语音邮件时,所需的是他们接收被叫方的问候语。为了那能发生,必须配置网关对语音邮件系统正如配置集成的Cisco CallManager 3.0(x)所描述对语音邮件系统通过SMDI。保证直接呼叫工作,在您设法排除故障转发呼叫前。

当您排除故障转发呼叫时,请检查保证传统语音邮件系统系统支持转发的原因代码。一些语音邮件系统允许编程各种原因代码。有时,其中Cisco CallManager在版本3.1前部署,语音邮件系统不可以被编程接受忙碌和答案转发的原因代码,因为Cisco CallManager那时不支持他们。

从Cisco信息处理接口的转发呼叫Trace

当您排除故障与SMDI时的问题,请检查在C查找的Cisco信息处理接口跟踪文件:/Program文件/Cisco/Trace/CMI目录。

18:33:28.187 Cisco Messaging Interface|   CMISsapiClient::RecvSsCallInfoResMsg()
Received RecvSsCallInfoResMsg fOriginalCdpn = 2001, fCgpn = 2000 fCallingPattern
= 2000
18:33:28.187 Cisco Messaging Interface|   CMISsapiClient::RecvSsCallInfoResMsg()
Received RecvSsCallInfoResMsg userdata = 5996336, Key = 7864, DSL2 = 2,
calledparty = 2001, callingparty = 2000
18:33:28.187 Cisco Messaging Interface|   CMISsapiClient::RecvSsCallInfoResMsg()
Forwarded Call port - 2, calledparty - 2001, callingparty - 2000
18:33:28.187 Cisco Messaging Interface|-->CMISsapiClient::SendCallForwardAll()
18:33:28.187 Cisco Messaging Interface|   CMISsapiClient::SendCallForwardAll()
Send call forward all: [<CR><LF>MD0010002A2001<0x20>2000<0x20><CR><LF><^Y>]
18:33:28.187 Cisco Messaging Interface|-->CMISerialWorker::SendBuffer()
18:33:28.187 Cisco Messaging Interface|   CMISerialWorker::SendBuffer()
Send Buffer - <CR><LF>MD0010002A2001<0x20>2000<0x20><CR><LF><^Y>
18:33:28.197 Cisco Messaging Interface|<--CMISerialWorker::SendBuffer()
18:33:28.197 Cisco Messaging Interface|<--CMISsapiClient::SendCallForwardAll()

这是一次转发呼叫的示例从分机的2000年对分机2001年。因为被叫方的电话在一前转所有呼叫状态,呼叫被发送对语音邮件。呼叫被提交对在LTN 0002的语音消息处理系统或者端口2。

一旦验证Cisco信息处理接口拦截VoiceMailDn并且生成SMDI消息,您能工作以语音邮件供应商保证消息接收。如果语音邮件系统不收到任何SMDI消息,即使Cisco信息处理接口生成他们,有超级终端的PC可以用于展示他们是否留下Cisco CallManager服务器。

MWI格式

等待断断续续的命令的消息的格式是:

MWI On:

操作:MWI 操作消息等待指示符
<0x20> 空间
分机号
<EOT> 传输结束

OP:MWI<0x20>2001!<EOT>

请求打开消息等待的分机2001年。

MWI Off:

RMV :MWI 删除消息等待指示符
<0x20> 空间
分机号
<EOT> 传输结束

RMV:MWI<0x20>2001!<EOT>

请求关闭消息等待的分机2001年。

排除故障MWI

当您排除故障与SMDI时的MWI问题,第一步是确定请求是否由Cisco CallManager接收。Cisco信息处理接口跟踪文件查找在C :/Program文件/Cisco/Trace/CMI显示SMDI消息是否由语音邮件系统传送并且由Cisco CallManager接收。

如果请求由Cisco CallManager接收,但是MWI不正确地运作,请验证Cisco信息处理接口的MWI SearchSpace字段包含属于电话闪亮指示请求启用开/关的分区。MWISearchSpace字段需要包含冒号分离的分区的名称。此字段区分大小写。

/image/gif/paws/18779/smdi-3.gif

从Cisco信息处理接口的MWI跟踪

MWI

18:33:47.846 Cisco Messaging Interface|   CMISerialWorker::SerialThread()
Saw EOT, inbound message: [OP:MWI<0x20>2001!<EOT>]
18:33:47.846 Cisco Messaging Interface|-->CMISsapiClient::OnLampOn()
18:33:47.846 Cisco Messaging Interface|   CMISsapiClient::OnLampOn()
Lamp On - 2001
18:33:47.846 Cisco Messaging Interface|   CMISsapiClient::OnLampOn()
Processed number = 2001
18:33:47.906 Cisco Messaging Interface|<--CMISsapiClient::OnLampOn()

MWI

18:33:47.846 Cisco Messaging Interface|   CMISerialWorker::SerialThread()
Saw EOT, inbound message: [RMV:MWI<0x20>2001!<EOT>]
18:33:47.846 Cisco Messaging Interface|-->CMISsapiClient::OnLampOff()
18:33:47.846 Cisco Messaging Interface|   CMISsapiClient::OnLampOff()
Lamp Off - 2001
18:33:47.846 Cisco Messaging Interface|   CMISsapiClient::OnLampOff()
Processed number = 2001
18:33:47.906 Cisco Messaging Interface|<--CMISsapiClient::OnLampOff()

已知问题

  • 6624刀片的FXS端口和AT-x网关不以适时的方式去挂机。

    当他们接收交换机忙音时,这些设备默认行为是去挂机。然而,许多语音邮件系统不断开重拨,但是相当拨号音。您能修改从其默认值的呼叫重启计时器为5000到1234为了更改网关的行为。

    /image/gif/paws/18779/smdi-4.gif

  • 关于Cisco信息处理接口的错误消息在事件查看器。

    Error:  CMyProcessConfigList::GetSafeIntegerParam() catch 
    handler Parameter MessageDeskNumber not found in database, using 
    default value of 1. 

    在Cisco CallManager中更早版本,消息平台参数是硬编码到1。在Cisco CallManager 3.0(7)中,可配置消息平台编号的支持介绍。如果不定义了消息平台编号, Cisco CallManager使用消息平台1。

  • Cisco信息处理接口不坚持运行。

    使用Cisco CallManager 3.0(7)版本, VoiceMailDN字段要求。

  • 与Octel 250/350的没有MWI,当Octel使用多条SMDI链路。

    当Octel语音邮件系统使用多条SMDI链路时,在是必要的哪条链路指定MWI命令需要发送。在邮箱配置文件,您能编辑Int。对应的链路编号数字域于连接Octel到Cisco CallManager的SMDI链路。

思科DPA 7630/7610

思科DPA76xx语音邮件网关是使传统语音邮件设备连接到Cisco IP电话解决方案网络的VoIP网关。思科DPA 7610允许当前使用数字站点仿真连接到Nortel Meridian 1 PBX的Octel语音邮件系统,连接到思科IP Callmanager系统。思科DPA 7630允许当前使用数字站点仿真连接到Avaya Definity PBX的Octel语音邮件系统,连接到思科IP Callmanager系统,不用对语音邮件系统的任何更改。

Cisco CallManager查看思科DPA76xx,当30 VIP的一集打电话,并且PBX的Avaya G3观看DPA作为7504D数字电话的一集。Nortel Meridian M1观看DPA作为2616个电话机的一集。

排除故障呼叫对语音邮件通过思科DPA 7630/7610

思科DPA76xx网关有非常准确的配线需求。当您排除故障与思科DPA76xx时的问题验证布线是重要的。

一旦肯定第1层问题是解决的,您能调查这些建议。

  • 症状:当呼叫发出对语音邮件时,交换机忙音播放给呼叫方。

    • 建议:如果DPA在十二个端口之外配置,第十三个呼叫方能接收重拨,如果前十二个端口是在使用中的。Cisco CallManager有题为ForwardMaximumHopCount的一个服务参数。默认情况下,此字段设置为值为12。

      /image/gif/paws/18779/smdi-5.gif

      设置此值为在DPA配置的端口数量。

  • 症状:呼叫方获得主要问候(开放树)而不是用户邮箱的问候语。

    • 建议:DPA取决于在值被输入到超过一个DPA的部署的Cisco CallManager ‘试验’ Directory Number字段。CallManager ‘试验’目录号应该是第一个DPA的第一个端口。当第一个DPA认识用其自己的端口(Dns)时关联的目录号,随后的DPAs需要此信息保证正确集成。

      注意: 最普通的误配置是,当客户配置CTI路由点或转发对DPA的搜索组时。这不是必要的,您能分配适当的DN到第一个DPA端口。

排除故障与思科DPA 7630/7610的MWI

为了等待通知的消息正确地工作,必须配置Cisco CallManager和DPA使用同样Dns MWI。

/image/gif/paws/18779/smdi-6.gif

被输入在Service > Service Parameters > Cisco CallManager下的值,为了MessageWaitingOn DN和MessageWaitingOffDN必须匹配在DPA输入的值下配置> CallManager

/image/gif/paws/18779/smdi-7.gif

  • 症状:MWIs不启用开/关。

    • 建议:保证MWI开/关Dns不作为一个更加通用的模式的部分。例如,请检查没有指向网关1xxx的路由模式。

  • 症状:MWIs在Octel不关闭250/350平台。

    • 建议:为了使正常运行的MWIs,必须设置等待在菜单6.2的消息超时功能, Octel系统的在波段之内集成到1 - Timeout=肯定回答设置。2 - Timeout=否定应答设置处理Octel系统解释缺乏确认音作为错误指示。DPA 7630/7610要求1 - Timeout=使用肯定回答选项。

  • 症状:使用思科DPA 7630, MWIs不启用开/关。

    • 建议:Avaya G3 PBX利用功能代码设置等待在PBX的消息。Octel语音邮件系统因而也使用他们。这些传统上分别为*4和#4留言呼叫的激活并且取消。在Octel 250/350平台,菜单的6.2,在波段之内集成,那里是两个参数:拨号顺序激活MWI的和拨号顺序撤销MWI。这些值应该是相同的象在DPA配置的那些下配置> Octel/Definity集成

      smdi-8.gif

      对于一个原因或别的,许多Octel系统有激活的拨号顺序MWI和拨号顺序撤销作为*4PN和#4PN配置的MWI,而不是*4N和#4N。P代表暂停,通常500ms,并且此延迟能导致与MWI的问题,在DPA代码1.2(1)前。


相关信息


Document ID: 18779