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

Cisco CallManager 3.0(x) 的 Cisco IP 电话故障排除指南

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


目录


简介

此故障排除指南描述用于的工具和实用程序配置,监控和排除故障Cisco CallManager版本3.0(1),思科IOSï ¿  ½网关和网守。本文提供三个不同的呼叫流详细示例,并且案例研究提供进一步解释概念。

在第一案例研究, Cisco IP电话呼叫在集群(集群内呼叫)内的另一Cisco IP电话。在第二案例研究, Cisco IP电话呼叫通过Cisco IOS网关对在公共交换电话网(PSTN)连接的通过本地PBX或电话。在第三案例研究, Cisco IP电话呼叫在不同的集群(中间聚集呼叫)的另一Cisco IP电话。

一旦了解呼叫流并且调试跟踪,隔离问题和确定将是更加容易的哪个组件引起问题。本文描述可用的工具排除故障潜在问题。它也描述呼叫跟踪和debug输出如何可帮助您了解事件呼叫流和系列。

在必须与Cisco技术支持中心(TAC)联系情况下,解释的许多工具此处将是有助在收集TAC要求的数据。问题解决方法更加快速,如果在呼叫TAC前已经收集了此数据。

先决条件

要求

请使用以下核对表肯定您有在您的网络拓扑的正确文档记录。

  • 显示所有网络设备和关键组件用端口/接口号对他们附加的拓扑,并且哪个VLAN的他们属于(如果适用)。应该用于特殊指定在中继或信道模式的端口。

  • 应该配置生成树的根,并且应该识别所有正常阻塞端口。

  • 应该识别所有广域网电路与相当数量带宽(一旦帧中继的CIR)。

注意: Cisco IP电话7960有一个10/100交换式网络端口和一个10/100 PC端口。思科不支持“层次发送的”电话PC端口。我们不推荐附加网络和PC端口到交换机(从而创建在网络的一条物理环路)。

因为这是拥塞,潜在的来源所有广域网接口将要求特别注意事项。思科IP电话和网关设置实时传输协议(RTP)数据流IP优先域到五,然而这只标记RTP数据包。它是至保证的网络管理员网络为优先级和呼叫接纳控制配置,以便VoIP流量可以服务与最小延迟和资源争夺。关于此主题的更多信息,参考:

使用的组件

本文档不限于特定的软件和硬件版本。

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

注意: 在本文的所有讨论为Cisco CallManager版本3.0(1)写入,除非另外说明。

规则

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

背景信息

拓扑

您应该有包含多种组件连接,例如VLAN,路由器,交换机,网关的端口的一个准确网络拓扑,等等。一有大量文件证明的拓扑帮助,当排除故障问题用系统。与对所有网络设备和终端服务的访问一起请务必您有一准确拓扑, Cisco CallManager的管理的。

重大的计划要求为了成功地添加IP电话到新或现有的网络。因为实时数据流比数据流有不同的需求,必须设计网络有低延时和服务质量(QoS)的念头。如同运载关键的数据流的所有网络,切记网络管理员维护准确,网络拓扑的详细的图表。在危机情况下认识端口连接到网络组件网络的不仅的清楚的概述是重要的,而且(路由器、交换机、Cisco CallManager服务器、网关和其他重要设备)。计划与冗余的网络和可扩展性在头脑里是重要的。

警告 警告: 思科不支持使用共享连接的集线器到交换机。集线器能干涉IP电话系统的正确操作。

当工作与交换网络时,非常重要的是您认识生成树的状态(冗余)。在所有失败发生前,网络的状态应该描述。

术语词汇表

表下面的列表在本文可能使用的一些普通的术语与缩略语。

词汇表
缩略语/期限 定义
.cnf 设备使用的配置文件。
ï ¿  ½ -法律(“mu-law”) 压缩扩展技术常用在北美。ï ¿  ½ -法律标准化作为在ITU-T G.711的64 KBPS编码。
A律 ITU-T用于在模拟和数字信号之间的转换的压缩扩展标准在脉冲编码调制(PCM)系统。A律主要在欧洲电话网使用并且类似于北美ï ¿  ½ -法律标准。
ACF 准入确认。
ANI 呼叫号码。
ARQ 准入请求。
B信道 承载信道。在ISDN中,这是全双工, 64 KBPS用于的信道发送用户数据。
呼叫搜索空间 目录号和路由模式一个给的设备能呼叫的呼叫搜索空间定义了。它是查找,当进行呼叫的分组分区。例如,假设有被命名“高级管理在呼叫搜索空间的几个分区”。在本例中, Cisco IP电话号码在“行政”呼叫搜索空间。当发起呼叫时, Cisco IP电话号码通过“NYInternationalCall搜索”, “NYLongDistance”, “NYLocalCall”,和"NY911"联机分区。有“访客”呼叫搜索空间,例如的Cisco IP电话号码,也许只允许通过“NYLocalCall”和"NY911"分区搜索。所以,如果用户设法拨国际号码,编号不会查找一匹配和呼叫不路由。
Ccapi 呼叫控制API。用于由Cisco IOS处理VoIP呼叫处理。
CCO Cisco在线连接(http://www.cisco.com)。在思科产品、技术支持信息和技术文档提供最新的信息。
CDR 呼叫详细信息详情记录。提供关于呼叫始发、目的地和持续时间的信息。这用于创建计费记录。
Cisco IOS Cisco 系统软件,可为 CiscoFusion 架构下的所有产品提供常用的功能、可扩展性和安全性。Cisco IOS允许互联网络、,当保证时支持多样化的协议,媒体、服务和平台的集中化,集成和自动化的安装和管理。
团星 Cisco CallManager集群。几个Cisco CallManager服务器的逻辑分组。
CMR 呼叫管理记录,亦称诊断CDR。这些是包含发送的计数字节的记录,发送的数据包,抖动,延迟,丢弃的数据包,等等。
编码 编码器译码器。用于的域专用部分(DSP)软件算法压缩/解压语音或音频信号。
D-channel 数据信道。全双工, 16 KBPS (BRI)或64 KBPS (PRI) ISDN信道。使用发信号和控制。
DCF 服务器确认。
DHCP 动态主机配置协议。为动态分配IP地址提供一机制,以便可以重新使用地址,当主机不再需要他们时。
DN 目录号。这是终端设备的电话号码。它可以是编号分配到Cisco IP电话、Cisco IP SoftPhone、传真机或者模拟电话附加对网关。示例包括1000和24231。
DNIS 拨叫号码标识服务。
DNS 域名系统。这是用于互联网的系统翻译网络节点名称到地址。
DRQ 断连请求。
DTMF 双音多频。这是使用拨号的两同时话音频带音(例如按键式)。
传播在间网络的两个终端之间的数据流例如(从一个LAN站点到另一个)。单个电路上可以传输多个流。
全双工 同时数据传输的功能从发送站和接收站。
G.711 描述64 KBPS PCM语音编码编程技术。在G.711,编码语音已经在数字语音发送的正确格式在PSTN或通过PBX。这在其G系列推荐的ITU-T标准描述。
G.729 描述语音被编码到8 KBPS数据流的码激励线性预测编码(CELP)压缩。有主要在计算的复杂性有所不同此标准的两变化(G.729和G.729附件A);两个提供通话质量类似于32 KBPS自适应差分脉冲编码调制(ADPCM)。这在其G系列推荐的ITU-T标准描述。
H.225 管理H.225会话建立和封包化的ITU标准。H.225实际上描述几份不同的协议:RAS、使用Q.931和使用RTP。
H.245 管理H.245终端控制的ITU标准。
H.323 启用在LAN和其他分组交换网络的视频会议ITU-T标准的H.320的在互联网的分机,以及视频。
半双工 数据传输的功能在仅一个方向每次在发送站和接收站之间。二进制同步通信(BSC)是一份半双工协议的示例。
Hookflash 一个短的挂机期限,通常生成由一个类似电话的设备在呼叫期间,表明电话尝试执行从PBX的拨号音撤回。Hookflash是常用的执行呼叫转移。
ICCP 簇内部控制协议
ISDN 综合业务数字网络。通信协议,提供由电话公司,允许电话网运载数据、语音和其他源数据流。
抖动 在到达时间的变化语音数据包上。
MGCP 梅迪亚网关控制协议。Cisco CallManager的一份协议能控制VoIP网关(MGCP终端)。
MTP 媒介终接点。
分区 分区是目录号(DN)和路由模式的逻辑分组与相似的可达性特性的。为了简化,这些通常被命名对于他们的特性,例如“NYLongDistance”, "NY911",等等。当DN或路由模式被放置到某一分区时,这创建谁的一个规则能呼叫该设备或路由列表。
PBX 专用交换分机位于用户之前的数字或模拟电话总机,它用于连接私用和专用电话网络。
PRI 主速率接口。主速率接入包括一条 64-Kbps D 信道和 23条 (T1) 或 30 条 (E1) B 信道,用于语音或数据。
PSTN 公共交换电话网络。关于全球范围内不同的电话网络和服务的一般术语。
Q.931 描述ISDN信令的ITU标准。H.225.0标准使用Q.931变量建立和断开H.323会话。
RAS 注册、准入和状态协议。这是用于H.323协议组的协议发现和呼应与网守。
路由过滤器 路由过滤器可以不仅用于限制正在拨号,而且识别通配符模式的一子集(当曾经@通配符在北美拨号方案)时。例如,它可能用于阻塞900个区域代码正在拨号。在能与分区和呼叫搜索空间一道也使用设置复杂规则。例如,假设您让三个用户组设立:高级管理、员工和访客。路由过滤器能准许管理用户组拨号国际号码、职员用户组拨通本地号码或长途呼叫和客户用户组只拨号本地号码, 911和800号码。
路由组 路由组是一个或更多网关或端口列表被看到作为相等访问的网关的。它类似于传统 PBX 术语中的中继组。例如,您可以有两个PRI电路到能任意地使用的同一载波。网关(或网关的一个特定端口)可能只被添加到一个路由组。
路由列表 以前呼叫的路由点,路由列表允许Cisco CallManager通过路由组列表寻找配置的顺序按首选的顺序。多个路由列表能指向同样路由组。
路由模式 一个特定编号或,通常,将使用路由呼叫到设备的范围呼叫号码(例如思科访问DT-24+网关或有语音能力的路由器)或间接通过路由列表。例如,1XXX 表示 1000 至 1999。‘X’在1XXX表示单数位;一个通配符。有其他这样通配符(例如@。! 等等)。只要路由过滤器不同的,路由模式不必须是唯一在分区内。
RRJ 注册拒绝。
RTP 实时传输协议,其中一份IPv6协议。RTP 用于为通过组播或单播网络服务传输实时数据(例如音频、视频或模拟数据)的应用程序提供端到端网络传输功能。RTP 可向实时应用程序提供有效负载类型识别、序列编号、时间戳记和传送监控等服务。
SEP Selsius以太网电话。此缩略语先于在思科IP电话的MAC地址,并且代表唯一设备标识符。
静音抑制(语音激活检测) 静音抑制允许Cisco IP电话检测无音频并且不传送在网络的数据包。音频质量也许轻微降低,但是连接可能也使用较少带宽。默认情况下静音抑制禁用。
SNMP 简单网络管理协议。网络管理协议在TCP/IP网络几乎完全使用。SNMP提供监控和控制网络设备及管理配置、统计收集、性能和安全的方法。
SQL 结构化查询语言。定义和访问的关系数据库国际标准标准语言。
T1/CAS T1是数字广域网运营商设备,传送DS-1-formatted数据在1.544 Mbps通过电话交换网络,使用AMI或B8ZS编码。CAS是随路信令接口。
T1/PRI T1是数字广域网运营商设备,传送DS-1-formatted数据在1.544 Mbps通过电话交换网络,使用AMI或B8ZS编码。PRI是主速率接口。主速率接入包括一条 64-Kbps D 信道和 23条 (T1) 或 30 条 (E1) B 信道,用于语音或数据。
TCP 传输控制协议。这是提供可靠的面向连接的传输传送层协议,全双工数据数据传输。TCP 是 TCP/IP 协议栈的一部分。
TFTP 简单文件传输协议。FTP 的简化版本,允许文件通过网络从一台计算机传送到另一台计算机。
转换模式 用于翻译呼叫(DNIS),并且呼叫自动数字标识(ANI)在路由呼叫前编号。例如,呼叫可能进来到一组数字(919 392-3XXX)该需要翻译到一套是在2XXX范围内的Cisco IP电话。Cisco CallManager有为919 392-3XXX设置的一个转换模式。此模式翻译导致的919 392-3到2,当留下剩余数字完整时。然后呼叫路由对适当的Cisco IP电话。转换模式仅使用真的转换,并且不应该用于简单数字剥离和加前缀。
UDP 用户数据报协议。这是在TCP/IP协议栈的一个无连接传输层协议。UDP 是一种简单的协议,它在没有确认或保证送达的情况下交换数据包,这要求其它协议来处理错误和重新发送。RFC 768 中对 UDP 进行了定义。
语音激活检测(静音抑制) 语音激活检测允许Cisco IP电话检测无音频并且不传送在网络的数据包。音频质量也许轻微降低,但是连接可能也使用较少带宽。默认情况下VAD/Silence抑制禁用。
VoIP 基于IP的语音。
VLAN 虚拟LAN。设备的一组在配置的一个或更多LAN的(使用管理软件),以便他们能通信,好象他们附加对同样电线,当他们在一定数量不同的LAN分段实际上查找。因为 VLAN 基于逻辑连接而非物理连接,所以极为灵活。

用于监控和排除 Cisco CallManager 故障的工具和实用程序

此部分寻址工具和实用程序配置,监控和排除故障Cisco CallManager。

Cisco CallManager 管理详细信息

Cisco CallManager管理为系统、数据库和其他组件提供版本信息。在开端页,请点击详细信息按钮并且写下在使用中的版本。

ccm_admin.gif

Cisco CallManager管理更多详细说明是可用的在Cisco CallManager线文档

Microsoft 性能

性能(箴言报)是能显示您的Cisco CallManager系统活动和状况的Windows 2000服务器服务器应用。它在实时报告一般和特定信息。您能使用Windows 2000性能所有Cisco CallManager安装的收集和显示系统和设备统计信息。此管理工具允许您获得系统的充分的了解,无需学习其组件中的每一的操作个。

您在实时能使用性能监控各种各样的系统变量。在添加Cisco CallManager参数以后,您能定义下Cisco CallManager将显示系统生成的统计信息的期限在。例如,能在任何时间监控进行中的呼叫编号或者呼叫数量当前通过通过一个特定网关的您。性能显示常规和思科CallManager-specific状态信息在实时。

/image/gif/paws/30266/ms_perf.gif

打开Microsoft性能

要打开在服务器PC运行Cisco CallManager的性能,请点击Start > Settings > Control Panel > Administration Tools > Performance

定制性能

必须定制性能监控程序查看您希望监控的思科CallManager-related参数。选择您要包括的对象、计数器和实例。参考配置Cisco CallManager的远程维护性,版本3.0关于关于如何的说明使用对象和计数器定制Cisco CallManager操作的Microsoft性能。

Microsoft 事件查看器

微软Event Viewer是显示系统、安全和应用程序事件的Windows NT服务器应用(包括Cisco CallManager) Windows NT服务器的。如果服务(包括TFTP)不能读数据库(其中获得trace配置),将添加错误到事件查看器。事件查看器是错误的这些类型将出现的唯一的地方。以下图示显示运行在Windows NT服务器的应用程序日志。

ms_event_viewer.gif

打开事件查看器

要打开运行Cisco CallManager的服务器PC上的事件日志,请点击Start > Settings > Control Panel > Administrative Tools > Event Viewer。事件查看器为系统、安全和应用程序提供错误日志。Cisco CallManager错误被记录在应用程序日志下。

关于事件的详细信息

您能双击在日志的一个事件学习关于事件的更多信息。

/image/gif/paws/30266/event_prop.gif

SDI 跟踪

SDI跟踪是本地日志文件。当查看SDI trace监控出现或请求的处理时, IP地址、TCP把柄、设备名或者时间戳可以用于。此设备名可能被跟踪回到文件的建立,显示设备池和型号。设备池和型号可以被跟踪回到配置文件原型的建立,将列出Cisco CallManager和TCP连接端口的网络地址。

当观察SDI跟踪时,请注意C++类和程序名用多数跟踪线路包括。多数惯例关联与一特定的请求的服务在标准格式包括线索ID。

SDI跟踪在案例研究将详细解释。

SDI Trace输出

SDI跟踪生成文件(例如, CCM000000000) Cisco CallManager活动该存储跟踪。这些跟踪提供关于Cisco CallManager初始化进程、注册过程、Keepalive进程、呼叫流、数字分析和相关设备的信息例如思科IP电话、网关,网守,等等。当排除故障Cisco CallManager时,此信息可帮助您隔离问题。适当地跟踪您需要的信息,并且您需要仅的信息,它是重要知道如何设置在trace配置接口的选项。

跟踪文件在以下默认位置存储:C:\Program Files\cisco\bin。一个新的跟踪文件开始,每次Cisco CallManager重新启动,或者,当指定线路数到达了。

以下Cisco CallManager管理trace配置接口的图示。您必须启用trace,选择在需要的信息的级别和检查用户屏蔽得到所需的级别信息。

/image/gif/paws/30266/trace_config.gif

如果trace没有适当地配置,将生成很多信息进行它非常难隔离问题。以下部分说明如何适当配置一有用的trace。

配置跟踪

跟踪撰写用户屏蔽标志(亦称位)和跟踪级别。打开Cisco CallManager管理。要启用跟踪,设置您的trace参数(包括配置的服务,位,等等)在Service > Trace屏幕。参考Cisco CallManager管理指南,断断续续发布3.0(1)关于启用跟踪的全部信息和为每配置的服务,等等的用户屏蔽的说明和级别。

以下的trace掩码位两示例根据特定问题将启用。

  • 对于调试的一般留言,把子系统位5, 6, 7, 8, 11和12置

  • 对于调试网关,把子系统位3, 4, 5, 6, 7, 8, 9, 11, 12和13置

以下根据特定问题的希望的跟踪级别两示例

  • 对于正常调试,应该设置跟踪级别为SDI_LEVEL_ARBITRARY

  • 对于正常运行系统,应该设置跟踪级别为SDI_LEVEL_ERROR

SDL 跟踪

Cisco工程师使用查找错误的原因的SDL跟踪。您没有预计充分地了解在SDL trace包含的信息。然而,当工作与TAC,您会询问启用SDL trace和提供它给TAC时。SDL跟踪文件可以保存到本地目录、Windows NT事件查看器和CiscoWorks 2000。要避免在服务器的所有性能下降,请务必您关闭SDL追踪,在trace捕获后。

SDL trace提供a.c.接口跟踪和报警。报警用于通知管理员意外的事件,例如无法访问文件、数据库, Winsock或者无法指定其他操作系统的资源。

启用SDL Trace

SDL跟踪在Service > Service参数范围在Cisco CallManager管理中启用。切记应该由TAC工程师打开这些跟踪,只有当请求的。注释选择的值打开在以下图示的SDL trace。

/image/gif/paws/30266/serv_param_config.gif

一旦SDL跟踪启用,请收集跟踪。如果跟踪发送到本地驱动器,则您在思科\ Trace子目录能获取他们。或者,跟踪文件可以发送到事件日志或到CiscoWorks 2000。

在下表里描述的SDL标志位在Service > Service Parameters地区在Cisco CallManager管理中设置。以下根据特定问题的所需的值两示例。

  • 正常呼叫调试的推荐值是SdlTraceTypeFlags=0x00000b04

  • 低级调试或调试网关的推荐值是SdlTraceTypeFlags=0x00004b05

Sdltracetypeflag定义
Sdltracetypeflag 定义
traceLayer1 = 0x00000001 所有第1层trace
TraceDetailLayer1 = 0x00000002 详细信息第1层trace
TraceSdlLinkAdmin = 0x00000004 Trace Cisco之间在集群内的CallManager链路
traceUnused = 0x00000008 未使用
traceLayer2 = 0x00000010 所有Layer2 trace
traceLayer2Interface = 0x00000020 第二层接口trace
traceLayer2TCP = 0x00000040 Layer2 TCP trace
TraceDetailLayer2 = 0x00000080 Layer2帧更多详细信息转储。
traceLayer3 = 0x00000100 所有第3层trace
traceCc = 0x00000200 所有呼叫控制trace
traceMiscPolls = 0x00000400 Trace其他投票
traceMisc = 0x00000800 其他trace在(数据库信号)
traceMsgtrans = 0x00001000 消息转换信号(TranslateIsdnToSdlReq、TranslateIsdnToSdlRes TranslateSdlToIsdnReq, TranslateSdlToIsdnRes)
traceUuie = 0x00002000 UUIE输出trace
traceGateway = 0x00004000 网关信号

在下表里描述的数据位在Service > Service Parameters地区在Cisco CallManager管理中设置。以下根据特定问题的所需的值两示例。

  • 正常系统调试的推荐值是SdlTraceDataFlags=0x110

  • 推荐值,当跟踪与SDL链路时的问题是0x13D (非压缩的trace;如果一紧凑trace希望,必须设置位0x200。它可以设置与所有其他位的组合)

Sdltracedataflags定义
SDLTraceDataFlag 定义
TraceSdlLinkState = 0x001 SDL林克初始化Enable (event) trace
TraceSdlLowLevel = 0x002 启用低级SDL事件、fileOpen和socket事件跟踪(例如)
TraceSdlLinkPoll = 0x004 SDL林克投票消息Enable (event)跟踪
TraceSdlLinkMsg = 0x008 SDL林克消息Enable (event)跟踪
traceRawData = 0x010 在所有信号的Enable (event)原始信号数据trace
TraceSdlTagMap = 0x020 Enable (event)标记映射
traceCreate = 0x100 Enable (event)进程创建并且终止跟踪
TraceNoPrettyPrint = 0x200 跟踪文件禁用相当打印

磁盘空间亚里桑

警告 警告: 请建议从此接口得到的信息可能是非常详细的,并且消耗很多磁盘空间。为此,我们建议您启动特定量的时刻的跟踪文件,查看信息和关掉trace。

嗅探器踪迹

嗅探器是以trace的形式,监控在网络的IP数据流并且提供信息的软件应用。嗅探器跟踪在您的网络提供关于数量的信息和网络数据流的类型。TCP/IP或UDP数据包是端点设备使用的由Cisco CallManager和协议,例如电话和网关。嗅探器跟踪可也帮助您识别可能导致语音音频问题或呼叫断线广播数据流的高水平。普通的嗅探器应用程序包括网络关联SnifferPro、惠普(HP)互联网顾问和Acterna Domino。Domino提供探测硬件与软件解决方案和网络分析器。如果要使用Domino,我们推荐使用分析软件评估一个获取嗅探器文件(例如从SnifferPro应用程序)。

呼叫详细记录 (CDR) 和呼叫管理记录 (CMR)

CDR是记录每发出的呼叫的报告选项(或尝试)从所有Cisco IP电话。有两CDR :基本CDR和诊断CDR (或CMRs)。一旦启用,您能打开CDR或诊断CDR (CMRs)在SQL server企业管理器。CDR文件在可以导出到接近所有应用程序,包括Microsoft访问或Excel的SQL数据库保存。

CDR记录包含必要的信息生成计费记录。在分布式环境,所有CDR数据在中央位置或者一套收集位置。Cisco CallManager节点的失败不使CDR数据关联与该节点无法获得。数据在Cisco CallManager磁盘在中央数据库在表里不再存储作为展开文件,但是存储。

如果Cisco CallManager出故障,在所有记录写入前,呼叫的记录不会存在。这意味着记录不会为是活跃的在给的Cisco CallManager的呼叫写入,当发生故障时,在呼叫终止前。

参考本文的Call Detail Records部分关于CDR和CMRs的详细信息。

被提供的信息包括:

  • 读和文字记录

  • 已知问题

  • 生成的记录类型列表

  • 在每个记录和什么的说明包含的字段列表该字段代表

  • 呼叫种类的说明被记录的和字段记录与每一个

  • 在CDR记录可能出现原因代码的列表

启用或禁用的CDR

默认情况下,当系统安装时, CDR记录创建禁用。如果希望有CDR数据,您必须启用CDR在Cisco CallManager管理Service > Service Parameters范围。当系统运转中时, CDR处理可以在任何时间启用和禁用。您不需要重新启动Cisco CallManager启用的或禁用CDR生效。系统在一些秒钟以内将回应对所有更改。CMR或诊断数据分开启用与CDR数据。CMR数据不会生成,除非CDR和呼叫诊断启用,但是CDR数据可能生成和被记录,不用CMR数据。

请使用以下步骤启用CDR。

  1. 打开Cisco CallManager管理。

  2. 选择Service > Service Parameters

  3. 选择您的Cisco CallManager安装的IP地址。

  4. 从参数列表,请选择CDREnabled

  5. 定义类型作为布尔型

  6. 选择真的T

    /image/gif/paws/30266/serv_param_config2.gif

  7. 更新。

    结果:呼叫详细记录立即开始录音。

    警告 警告: 跟踪语音连通性在集群的每Cisco CallManager安装要求该Cdr记录启用。

    /image/gif/paws/30266/log_enable.gif

CDR

CDR提供可帮助您了解在SDI跟踪包含的详细信息的基本信息。基本CDR提供信息例如呼叫号码,被叫号码,产生IP地址,目的IP地址,呼叫持续时间,等等。CDR可帮助您排除故障电话问题。例如,如果用户报告与以特定时间发生的呼叫的一问题,您能参见在指示的时间附近发生学习关于该呼叫和其他的其他信息的CDR。CDR为发单是常用的。

诊断CDR (亦称CMRs)

诊断CDR提供详细呼叫信息例如发送的数据包编号,接收和丢失和相当数量抖动和延迟。此详细程度能为一些问题提供说明,例如单向音频。例如,单向音频问题指示数据包大小10,000是否发送,但是已接收大小只是10。

用 Windows NT 和 Internet 信息服务器 (IIS) 排除 CallManager 问题

此部分寻址可能发生在Cisco CallManager和相关设备的一些常见问题类别。每个问题类别建议您应该使用帮助隔离问题的故障排除工具。本文提供潜在问题和建议一般类别关于怎样排除故障那些问题。它不提供问题和解决方法详尽列表。如果遇到不可以是解决的使用在本文描述的工具和实用程序的问题,请参见协助的Cisco技术支持中心(TAC)。请务必有Cisco CallManager管理详细信息联机,加上所有诊断信息(例如跟踪)您聚集了至呼叫TAC点。

语音质量

在电话期间,语音质量问题包括丢失的或误解的音频。常见问题在声音包括造成音频断断续续的中断(类似残破的词),或者误解音频多的个噪声的出现(响应)或作用造成所说的话听起来含水或机器人。单向音频,即,在仅一个人能听到任何东西的两个人之间的一次会话,实际上不是语音质量问题。这将是讨论以后在此部分。

一个或很多以下组件可能引起音频问题:

  • 网关

  • 电话

  • 网络

适当地排除故障语音质量问题,您必须假定有基础设施和所有设备丢包和延迟的。

丢失的或误解的音频

遇到的其中一个最常见的问题是“破坏”音频(经常描述作为被错误的语音或音节损耗在词或句子内的)。有此的两个常见原因:包丢失和抖动。包丢失意味着语音信息包不到达在他们的目的地,因为他们太晚期丢弃了或到达是有用的。抖动是在到达时间的变化数据包上。理想的状态,从一个电话的VoIP信息包到另一个将恰好到达以1每20毫秒的速率。注意这不提及多长时间需要对于数据包从对点B的点A获得,完全在到达时间上的变化。

有可变延迟许多来源在实际网络的。其中一些不可能被控制,并且一些能。可变延迟在分组的语音网络不可能完全地被排除。数字信号处理器(DSP)在电话和其他有语音能力的设备设计缓冲某些音频,预期可变延迟。此“取消抖动”执行,只有当语音信息包到达了其目的地时并且准备被放到一常规音频流(即播放到用户的耳朵,发送对PSTN通过一数字PCM数据流)。Cisco IP电话7960能缓冲多达一秒钟语音示例。抖动缓冲区可适应,含义数据包突发流量是否接收, Cisco IP电话7960能显示他们为控制抖动。网络管理员需要通过事先应用服务质量(QoS)和其他测量最小化在信息包到达到达时间之间的变化(特别是如果呼叫交叉广域网)。

当面对一个丢失的或误解的音频问题,您应该首先设法隔离音频的路径。在呼叫的音频流的路径设法识别每个网络设备(交换机和路由器)。记住音频可能在两个电话之间,在电话和网关之间,或者可能有多个段(从一个电话到一个转码设备和从那里到另一个电话)。设法识别问题是否仅发生在两个站点之间,仅通过某一网关,在某一子网,等等。设备您需要认真地检查的这将帮助缩小。其次,这经常是最佳的禁用静音抑制(亦称语音激活检测或VAD),如果这已经未执行。此机制通过不传送任何音频保存带宽,当有沉默时,但是可能在词初导致显而易见(和不可接受的)限幅。您能在Cisco CallManager管理中禁用此,在Service > Service Parameters下。从那里,选择服务器和Cisco CallManager服务。设置SilenceSuppressionSystemWide为“F” (您能二者择一设置SilenceSuppressionWithGateways为“F”,但是这不适用于H.323网关或MGCP网关)。当不确定时,请通过选择其中每一的值关闭两个F。

/image/gif/paws/30266/serv_param.gif

如果网络分析器是可用的,在两个电话之间的一监听呼叫应该有50数据包每秒(或1数据包每20毫秒),当静音抑制禁用时。使用适当的过滤,识别,如果数据包丢失应该是可能的或非常地延迟。

切记该延迟单独不会导致限幅,只有可变延迟。在下表的,代表一完善的trace,之间的到达时间将有一个RTP报头)的语音信息包(是20毫秒。在质量差呼叫(例如与很多抖动的一呼叫),到达时间非常地将变化。

一完善的Trace
数据包编号 时间:绝对(毫秒) 时间:Delta (毫秒)
1 0
2 0.02 20
3 0.04 20
4 0.06 20
5 0.08 20

放置信息包分析程序到在网络的多种点将帮助从缩小延迟来的地方。如果分析器不是可用的,其他方法将要求。检查每个设备接口统计信息在音频的路径是重要的。跟踪的呼叫另一个工具与拙劣语音质量是诊断呼叫详细记录(CDR)。请参阅工具和实用程序区分和Call Detail Records部分关于CDR的更多信息。

抖动和延迟的值可以为所有呼叫被检索(但是,在呼叫终止)之后。以下示例诊断CDR (CallDetailRecordDiagnostic是实际表名称)。发送的数据包编号,接收,丢失,抖动和延迟全部被记录。globalCallID值在正常CDR表里可以用于查找呼叫,以便断开原因和其他信息可以得到。下图所示显示开放两个的表。注意在诊断CDR,能可能报告的每个设备此信息包括。因此,如果问题在两思科IP电话之间,我们看到每呼叫两条目。例如,如果我们有一呼叫通过Cisco IOS网关我们只看到从Cisco IP电话的诊断信息,不是网关,因为没有它的机制能通知与此信息的SQL数据库。

ibutton.gif

i按钮帮助

Cisco IP电话7960提供诊断的可能的音频问题另一个工具。在激活的呼叫,您能两次按i按钮(迅速地),并且电话显示包含数据包接收和传输统计信息,以及平均值和最大抖动计数器的信息屏幕。在此屏幕,没有该抖动是到达最后五数据包的平均值;最大抖动是平均的抖动的高水线标记。

延迟和包丢失的多数共源是更高的速度接口投向低速度接口的设备。例如,路由器可能有100 Mb快速以太网接口连接对LAN和一慢帧中继连接对广域网。当质量差发生,只有当通信对远程站点(仅远程站点可能报告拙劣语音质量时,当在另一个方向一切看来是细致的)时,下面产生此问题的最可能的原因:

  • 路由器未适当地配置制定在数据流的语音流量优先级。

  • 有活动许多的呼叫广域网的能支持(即没有限制可以发出)呼叫的数量的呼叫接纳控制。

  • 有物理端口错误。

  • 有在广域网的拥塞。

在LAN,最常见的问题是配置不正确设备(例如CRC错误)造成的由有故障的电缆和接口,或者物理层错误(例如端口速度或双工不匹配)。确保流量不交叉任何共享媒介设备,例如集线器。可能也有流量通过网络比预计采取一个更加慢的路径的情况。如果QoS正确地配置,很可能,没有呼叫接纳控制。根据您的拓扑,这可以是实现的通过使用位置在Cisco CallManager管理配置方面,或者通过使用Cisco IOS路由器作为网守。无论如何,您应该总是知道多少呼叫可能在您的广域网间支持。若可能,请由禁用的静音抑制测试此如描述前,然后发出呼叫在两个站点之间。因为这从传送,将终止数据包请勿让呼叫在暂挂或消音状态。使用呼叫最大在广域网间的,呼叫如果所有有合格的质量。测试确保,快速忙音返回,当尝试更做一呼叫时。

哔拍作响

另一“质量差”症状可能是脆皮,由有缺陷的电源或接近电话的强电子干扰有时造成。尝试交换电源和移动电话对一个不同的位置。

检查您的负载

另外,您应该总是检查电话,并且保证最新的软件负载的网关是在使用中的。当不确定时,最新的软件负载的检查CCO (Cisco在线连接在www.cisco.com),新建的补丁程序或者版本注释与问题相关。

响应

响应(亦称“讲话者回音”)发生,当健谈的人的语音能量,传送在主信号信道下,被耦合到从远端时的接收路径。流量生成者然后听到他们自己的语音,延迟在总响应路径延迟延时之前。

/image/gif/paws/30266/voice.gif

在以上图表,约翰的语音(用蓝色)是反射的上一步。因为延迟很低,这可以发生,但是未被注意在传统语音网络。对用户,比响应发声更多象侧音。在VoIP网络中,因为封包化和压缩总是贡献足够的延迟,它永远将是显而易见的。记住的重要事情是响应的原因总是模拟组件和配线。例如, IP信息包不可以转过来和回到来源在一低音频级。同样是不可能的在数字T1/E1电路。因此在从一Cisco IP电话的一呼叫到另一个,不应该有任何问题。唯一的例外可能是,如果一个当事人使用有太高的音量设置或某个其他情况音频环路创建的一免提。

当排除故障回声问题时,请确保测试或检查不使用免提的电话,并且他们有耳机音量设置对合理的级别(请从音频级的50百分比开始)。多数时间,当附加对PSTN通过数字或模拟网关时,问题将发生。Cisco IP电话用户可能抱怨说他们听到他们反射回到他们的自己的语音。虽然问题的真正的源几乎总是在远端,更改任何东西在PSTN是接近总是不可能的。因此,第一步将确定使用哪个网关。如果数字网关是在使用中的,它可能是在传送方向的可能的添加另外的填充(往PSTN)希望较低的信号强度将产生较少被反射的能量。另外,您能调节接收级别,以便所有反射的音频减少的更加进一步。记住每次做小调整是非常重要的。信号的许多衰减在两边将使音频不可能听到。或者,您能与载波和请求联系安排线路被检查。在一个典型的T1/PRI电路上在北美,输入信号应该是-15dB。如果信号电平更高(例如-5 dB),响应将是可能导致。

保持感受响应所有呼叫的日志。问题、来源电话号码和数字称为的时期如果所有被记录。网关有16毫秒的已修复时光回波取消。如果反射的音频的延迟比此长,响应大臣无法适当地工作。这不应该是本地呼叫的一个问题,并且长途呼叫应该有外部响应大臣被构件到网络在中心局。这是其中一个原因为什么注释体验响应呼叫的外部电话号码是重要的。

检查您的负载

应该验证网关和电话负载。检查CCO (在www.cisco.com的Cisco在线连接)最新的软件负载、新建的补丁程序或者版本注释与问题相关。

单向音频或没有音频

在呼叫期间时,当一个人不能听到另一个人单向音频发生。这可以由配置不正确Cisco IOS网关、防火墙或者路由或者默认网关问题造成,尤其。

在呼叫期间,有单向音频或没有音频的一定数量的原因。多数常见原因是一个配置不正确设备。例如, Cisco CallManager处理Cisco IP电话的呼叫建立。实际音频流发生在两思科IP电话之间(或在Cisco IP电话和网关之间)。因此,是完全可能的Cisco CallManager能发信号到目的地电话(进行它环),当发起呼叫的电话没有一Ip route到目的地电话时。这通常发生,当在电话的默认网关不正确地配置时(手工或在动态主机配置协议(DHCP)服务器)。

如果呼叫一致有单向音频,请设法ping目的地Cisco IP电话使用在相同子网作为电话并且有同一默认网关的PC。采取在相同子网作为目的地电话的PC (用默认网关和目的地电话一样)并且ping来源电话。两个那些测验应该工作。音频数据流可能受可能阻塞在一个的音频或两个方向的防火墙或数据包过滤器的也影响(例如在路由器的访问列表)。如果单向音频通过支持语音的Cisco IOS网关仅发生,请仔细检查配置。必须启用IP路由(请检查配置确保, no ip routing没有在配置的开始处附近被找到)。并且,如果使用RTP报头压缩保存在广域网间的带宽,请确保在附加对WAN回路的每路由器运载的语音流量启用。在广域网的另一侧不应该有RTP报头在一端被压缩的情况,但是不可能被解压。嗅探器是一非常有用工具,当排除故障单向音频问题时,因为您能验证电话或网关是实际上发送或接收数据包。诊断CDR是有用的在确定呼叫是否体验单向音频,因为他们记录已发送和收到的信息包(参考丢失的或误解的音频)。您能两次也按i按钮(迅速)在Cisco IP电话7960在激活的呼叫期间查看关于已发送和收到的信息包的详细信息。

注意: 当呼叫静音(在电话按的静音按键),数据包不会传送。保留按键终止音频流,因此数据包没有在任何一个方向被发送。当保留按键发布时,所有信息包计数器重置。切记在TX和RX计数器的设备必须禁用静音抑制能坚持相等。全系统的禁用的静音抑制不会影响Cisco IOS网关。

MTP和单向音频

如果在呼叫使用媒介终接点(MTP) (支持附加服务例如暂挂和转移用不支持H.323版本2)的H.323设备,请确认分配的MTP是否正确地工作。Cisco IOS路由器支持H.323在版本11.3(9)NA和12.0(3)T的版本2开始处。开始用Cisco IOS版本12.0(7)T,/Close LogicalChannel支持开放可选的H.323,因此基于软件的MTP为附加服务不再要求。

MTP设备、以及会议桥和代码转换器,将桥接两个或多个音频流。如果MTP、会议桥或者代码转换器是工作不正常,单向音频或音频损耗也许是有经验的。如果MTP引起问题,请关闭MTP发现。

电话重置

电话将被重新通电或重置,由于以下两个原因之一:

  • 连接对Cisco CallManager的TCP失败或者

  • 疏忽收到确认到电话的保活信息。

下面排除故障的电话重置步骤:

  1. 检查电话和网关保证您使用最新的软件负载。

  2. 检查CCO (在www.cisco.com的Cisco在线连接)最新的软件负载、新建的补丁程序或者版本注释与问题相关。

  3. 检查事件查看器实例电话重置。如以下图示所显示,电话重置认为信息事件。

    /image/gif/paws/30266/event_prop.gif

  4. 寻找可能在该的时间附近发生电话重置的这些和所有错误。

  5. 开始SDI trace并且设法通过识别在重置的电话的所有普通的特性隔离问题。例如,请检查他们全部是否在相同子网查找,同样VLAN,等等。查看trace并且确定是否:

    • 重置发生在呼叫期间或间歇地发生或者

    • 有电话型号所有相似性:Cisco IP电话7960, Cisco IP电话30VIP,等等。

  6. 开始在频繁地重置的电话的嗅探器跟踪。在它重置后,请查看trace确定是否有任何TCP重试次数发生。如果那样,这指示一个网络问题。trace可能显示在重置的一些一致性,例如重置每七天的电话。这也许指示DHCP租用有效期每七天(此值用户可配置的,并且可能是每两分钟,等等)。

呼叫断线

当呼叫过早地终止时,呼叫断线发生。特别如果问题断断续续,您能使用CDR确定呼叫断线的可能的原因。呼叫断线可以是电话的结果或网关重置(请参阅上述部分)或电路问题,例如不正确PRI配置或错误。

第一步将确定此问题是否隔离给一个电话或电话的一组。或许受影响的电话是全部在特定子网或位置。下一步是检查事件查看器电话或网关重置。

/image/gif/paws/30266/drop_call.gif

应该有一亚里桑和一错误消息重置的每个电话的。在这种情况下,问题经常是电话不能保持其对Cisco CallManager的TCP连接运行,因此Cisco CallManager重置连接。这可能是因为电话被关闭了或可能有在网络的一问题。如果这是间歇问题,使用Microsoft性能记录电话注册可能是有用的。

/image/gif/paws/30266/drop_call2.gif

如果问题似乎仅发生通过某一网关,例如思科访问DT-24+,最好的措施将启用跟踪并且/或者查看CDR。CDR文件将给可能帮助确定问题的原因的Cause Of Termination (COT)。

drop_call3.gif

断开原因值(origCause_value和destCause_value,侧暂停呼叫),映射对Q.931可以在ISDN交换机类型、代码和值找到的断开原因代码(在十进制)。在以上示例中,原因16是指一个正常呼叫清除。如果呼叫出去网关对PSTN, CDR可以用于确定哪侧挂断呼叫。许多同一信息可以通过启用在Cisco CallManager的跟踪得到。请仅请使用trace工具作为最后一招或,如果网络不在制作。

检查您的负载

如同所有问题,请检查电话和网关负载和CCO (在www.cisco.com的Cisco在线连接)最新的软件负载、新建的补丁程序或者版本注释与问题相关。

Cisco CallManager 功能问题

问题可能发生在功能,例如会议桥或媒介终接点,与Cisco CallManager一道使用。其中一些功能问题由配置错误或缺乏资源引起。例如,如果特别会议资源指定的编号被超出了,用户可能不能对电话会议。当用户尝试启动会议功能,结果是呼叫断线。当实际上它是一问题用可用的会议资源时,数量这可能看来是Cisco CallManager功能问题。次数会议资源要求,但是不可用的,是一个计数器登陆的Microsoft性能。同一种行为出现,如果有会议资源联机,但是会议服务终止了。

编码/地区:编码解码器不匹配

如果用户获得交换机忙音,当去摘机时,它可能是编码分歧结果在地区之间的。验证两个呼叫末端支持至少一个普通的编码(例如, G.711)。否则,您将需要使用代码转换器。

区域指定能使用与其他地区中的每一个的范围支持的编码。每个设备属于区域。

注意: 用Cisco IOS路由器不支持编解码器协商。

Region1<->Region2 = G.711意味着在一个设备在Region1和一个设备之间的一呼叫在Region2能使用G.711或任何其他要求同样或较少的带宽作为G.711的支持的编码(在G.711、G.729, G.723内的任何支持的编码,等等)。

注意: 以下编码为每个设备支持:

  • Cisco IP电话7960 G.711A-law/ï ¿  ½ -法律, G.729AnnexB

  • SP12系列的Cisco IP电话和VIP30 G.711A-law/ï ¿  ½ -法律, G.723.1

  • 思科接入网关DE30和DT-24+ G.711A-law/ï ¿  ½ -法律, G.723.1

位置

如果用户接收交换机忙音,在拨号编号,它后可能是,因为位置的Cisco CallManager带宽分配其中一个呼叫终端设备被超出了(较少比24k)。Cisco CallManager检查每个设备的可用的带宽前面进行呼叫的24k。如果较少比24k带宽是可用的, Cisco CallManager不会设置呼叫,并且用户将听到交换机忙音。

12:42:09.017 Cisco CallManager|Locations: Orig=1 BW=12 Dest=0 BW=-1 
(-1 implies infinite bw available)

12:42:09.017 Cisco CallManager|StationD
- stationOutputCallState tcpHandle=0x4f1ad98 

12:42:09.017 Cisco CallManager|StationD
- stationOutputCallInfo CallingPartyName=, CallingParty=5003, CalledPartyName=,
 CalledParty=5005, tcpHandle=0x4f1ad98 

12:42:09.017 Cisco CallManager|StationD
- stationOutputStartTone: 37=ReorderTone tcpHandle=0x4f1ad98 

一旦呼叫建立, Cisco CallManager从位置减去带宽根据用于该呼叫的编码。如果呼叫使用G.711, Cisco CallManager减去80k;如果呼叫使用G.723, Cisco CallManager减去24k;如果呼叫使用G729, Cisco CallManager减去24k。

会议桥

请使用以下信息帮助排除故障"No Conference Bridge available"问题。这能是软件或硬件故障。

首先,看到的检查是否有用Cisco CallManager注册的任何可用的会议桥资源(软件或硬件)。要执行如此,您能使用Microsoft性能检查“单播AvailableConferences编号”。

思科IP语音媒体流应用程序执行会议桥功能。一软件安装思科IP语音媒体放出将支持16个单播可用的会议(3个人/会议)如以下trace所显示。

10:59:29.951 Cisco CallManager|UnicastBridgeControl - wait_capabilities_StationCapRes 
- Device= CFB_kirribilli - Registered - ConfBridges= 16,
 Streams= 48, tcpHandle=4f12738

10:59:29.951 Cisco CallManager|UnicastBridgeManager - UnicastBridgeRegistrationReq 
- Device Registration Complete for Name= Xo??%? - DeviceType= 50, ResourcesAvailable= 16, 
deviceTblIndex= 0 

一个E1端口(WS-X6608-E1卡包含8x E1端口)提供五个单播可用的会议(最大会议大小= 6),如以下trace所显示。

11:14:05.390 Cisco CallManager|UnicastBridgeControl - wait_capabilities_StationCapRes 
- Device= CFB00107B000FB0 - Registered - ConfBridges= 5, Streams= 16, 
tcpHandle=4f19d64

11:14:05.480 Cisco CallManager|UnicastBridgeManager - UnicastBridgeRegistrationReq 
- Device Registration Complete for Name= Xo??% - DeviceType= 51, ResourcesAvailable= 5,
 deviceTblIndex= 0 

在思科Catalyst 6000 8端口语音T1/E1和服务模块的以下硬件trace表明在卡的E1端口4/1注册作为一座会议桥用Cisco CallManager。

greece-sup (enable) sh port 4/1

Port Name Status Vlan Duplex Speed Type

----- ------------------ ---------- ---------- ------ ----- ------------

4/1 enabled 1 full - Conf Bridge


Port DHCP MAC-Address IP-Address Subnet-Mask

-------- ------- ----------------- --------------- ---------------

4/1 disable 00-10-7b-00-0f-b0 10.200.72.31 255.255.255.0 


Port Call-Manager(s) DHCP-Server TFTP-Server Gateway

-------- ----------------- --------------- --------------- ---------------

4/1 10.200.72.25 - 10.200.72.25 - 


Port DNS-Server(s) Domain

-------- ----------------- -------------------------------------------------

4/1 - 0.0.0.0


Port CallManagerState DSP-Type

-------- ---------------- --------

4/1 registered C549


Port NoiseRegen NonLinearProcessing

----- ---------- -------------------

4/1 disabled disabled

其次,请检查在会议配置的最大用户数(对等或Meet-Me)确定,如果问题发生了,因为此编号被超出了。

转码的问题

如果安装在思科Catalyst 6000 8端口语音T1/E1和服务模块的一硬件代码转换器,并且不运作正如所料(含义您不能做在两个用户之间的呼叫没有普通的编码),请确认是否有用Cisco CallManager注册的任何可用的转码器资源(这必须是硬件)。请使用Microsoft性能检查“MediaTermPointsAvailable”联机编号。

一个E1端口(WS-X6608-E1卡包含8x E1端口)提供16呼叫的Transcoder/MTP资源,如以下trace所显示。

11:51:09.939 Cisco CallManager|MediaTerminationPointControl - Capabilities Received 
- Device= MTP00107B000FB1 - Registered - Supports 16 calls

在思科Catalyst 6000 8端口语音T1/E1和服务模块的以下硬件trace表明在卡的E1端口4/2注册作为一MTP/transcoder用Cisco CallManager。

greece-sup (enable) sh port 4/2

Port Name Status Vlan Duplex Speed Type

----- ------------------ ---------- ---------- ------ ----- ------------

4/2 enabled 1 full - MTP


Port DHCP MAC-Address IP-Address Subnet-Mask

-------- ------- ----------------- --------------- ---------------

4/2 disable 00-10-7b-00-0f-b1 10.200.72.32 255.255.255.0 


Port Call-Manager(s) DHCP-Server TFTP-Server Gateway

-------- ----------------- --------------- --------------- ---------------

4/2 10.200.72.25 - 10.200.72.25 - 


Port DNS-Server(s) Domain

-------- ----------------- -------------------------------------------------

4/2 - 0.0.0.0


Port CallManagerState DSP-Type

-------- ---------------- --------

4/2 registered C549


Port NoiseRegen NonLinearProcessing

----- ---------- -------------------

4/2 disabled disabled

注意: 同样E1端口不可能为会议桥和Transcoder/MTP配置

为了做在两个设备之间的一呼叫使用低比特率代码(例如G.729和G.723)不支持同样编码,转码器资源要求。考虑以下图示:

/image/gif/paws/30266/ccm_ill.gif

假设Cisco CallManager配置这样在Region1和Region2之间的编码是G.729。以下方案是可能的:

  • 如果呼叫方打电话A发起呼叫, Cisco CallManager意识到它是Cisco IP电话7960,偶然支持G.729。在位收集后, Cisco CallManager确定呼叫为是在Region2的用户D是注定的。因为目的地设备也支持G.729,呼叫设置和音频流直接地在电话A和电话D.之间。

  • 如果电话的B一个呼叫方,有Cisco IP电话12SP+,将发起呼叫给D打电话,这次Cisco CallManager意识到产生的电话只支持G.723或G.711。Cisco CallManager将需要指定转码资源,以便音频将流作为G.711在电话B和代码转换器之间,而是作为在代码转换器和电话D.之间的G.729。如果代码转换器不是可用的,给D的电话打电话将敲响,但是,当呼叫应答了,呼叫将断开。

  • 如果电话的B一个用户将呼叫电话F (Cisco IP电话12SP+),两个电话实际上将使用G.723,即使G.729配置作为编码使用在地区之间。使用G.723,因为两个终端支持它,并且比G.729使用较少带宽。

  • 如果Cisco uOne语音邮件系统被添加(只支持G.711)或为对Region1的G.711配置的Cisco IOS路由器,则必须使用转码设备,如果呼叫从Region2。如果什么都不是可用的,则呼叫将发生故障。

MTP资源问题

MTP资源问题可能是罪犯,如果呼叫建立,并且附加服务不是可用的在不支持H323v2的H.323设备。首先,请确定您是否有用Cisco CallManager (软件或硬件)注册的任何可用的MTP资源。您能如此执行通过使用Microsoft性能检查“MediaTermPointsAvailable编号”。

一MTP软件应用支持24呼叫(使用支持的MTP附加服务用如以下trace所显示,没有支持H.323v2)的H.323设备。

10:12:19.161 Cisco CallManager|MediaTerminationPointControl - Capabilities Received 
- Device= MTP_kirribilli. - Registered - Supports 24 calls

一个E1端口(WS-X6608-E1卡包含8x E1端口)提供16呼叫的MTP资源,如以下trace所显示。

11:51:09.939 Cisco CallManager|MediaTerminationPointControl - Capabilities Received 
- Device= MTP00107B000FB1 - Registered - Supports 16 calls

以下硬件trace,从思科Catalyst 6000 8端口语音T1/E1和服务模块,表明在卡的E1端口4/2注册作为一MTP/transcoder用Cisco CallManager。

greece-sup (enable) sh port 4/2

Port Name Status Vlan Duplex Speed Type

----- ------------------ ---------- ---------- ------ ----- ------------

4/2 enabled 1 full - MTP


Port DHCP MAC-Address IP-Address Subnet-Mask

-------- ------- ----------------- --------------- ---------------

4/2 disable 00-10-7b-00-0f-b1 10.200.72.32 255.255.255.0 


Port Call-Manager(s) DHCP-Server TFTP-Server Gateway

-------- ----------------- --------------- --------------- ---------------

4/2 10.200.72.25 - 10.200.72.25 - 


Port DNS-Server(s) Domain

-------- ----------------- -------------------------------------------------

4/2 - 0.0.0.0


Port CallManagerState DSP-Type

-------- ---------------- --------

4/2 registered C549


Port NoiseRegen NonLinearProcessing

----- ---------- -------------------

4/2 disabled disabled

其次,请检查媒介终接点要求的复选框是否在Cisco CallManager管理Gateway Configuration屏幕选择。

第三,请验证Cisco CallManager分配了MTP设备所需数量。

从SDI文件:

15:22:23.848 Cisco CallManager|MediaManager(40) started

  15:22:23.848 Cisco CallManager|MediaManager - wait_AuConnectRequest

  15:22:23.848 Cisco CallManager|MediaManager - wait_AuConnectRequest - Transcoder 
  Enabled

  15:22:23.848 Cisco CallManager|MediaManager - wait_AuConnectRequest - party1(16777357), 
  party2(16777358), proxies=1, connections=2, current proxies=0

  15:22:23.848 Cisco CallManager|MediaManager - wait_AuConnectRequest - proxy 
  connections

  15:22:23.848 Cisco CallManager|MediaManager - wait_AuConnectRequest - allocating 
  MTP(ci=16777359)

  15:22:23.848 Cisco CallManager|MediaManager - wait_AllocateMtpResourceRes

  15:22:23.848 Cisco CallManager|MediaManager - wait_AllocateMtpResourceRes 
  - start 2 connections

  15:22:23.848 Cisco CallManager|MediaManager - wait_AllocateMtpResourceRes 
  - creating connection between party1(16777357) and party2(16777359)

  15:22:23.848 Cisco CallManager|MediaManager - wait_AllocateMtpResourceRes 
  - creating connection between party1(16777358) and party2(16777359)

  15:22:23.848 Cisco CallManager|MediaCoordinator - wait_MediaCoordinatorAddResource - 
  CI=16777359 count=1

  15:22:23.848 Cisco CallManager|MediaCoordinator - wait_MediaCoordinatorAddResource 
  - CI=16777359 count=2

拨号方案

拨号计划是告诉Cisco CallManager,等等)发送呼叫的设备编号的编号(和组的列表) (电话,网关,当有些数字串收集时。拨号方案类似于路由器中的静态路由表。请肯定您的拨号计划概念、基本的呼叫路由和规划在尝试认真考虑和适当地配置排除故障前一个潜在的拨号计划问题。经常,问题位于随着规划和配置。

请考虑以下问题,当排除故障拨号计划问题时:

  • 什么是发起呼叫的目录号(DN) ?

  • 什么是此DN呼叫搜索空间?

  • 如果适用,什么是设备的呼叫搜索空间(例如Cisco IP电话) DN关联?确保您识别正确设备;支持多个线路显示,并且有在多个设备的DN是可能的。注释设备的呼叫搜索空间。如果呼叫由Cisco IP电话发起,请记住特定线路(DN),并且该线路关联的设备其中每一个将有呼叫搜索空间。他们将被结合,当进行呼叫。为例,假设,有对此1000配置的分机有AccessLevelY作为其呼叫搜索空间的线路实例1000有AccessLevelX呼叫搜索空间,并且Cisco IP电话。所以,当进行从该线路外观的一呼叫, Cisco CallManager通过在呼叫搜索空间AccessLevelX和AccessLevelY包含的分区将搜索。

  • 什么分区关联与呼叫搜索空间?

  • 什么是呼叫应该设备的分区(或请勿应该)去?

  • 什么是拨号的编号?注意,如果和当呼叫方获得二次拨号音,在任何个阶段。并且,呼叫方听到,在所有位被输入了后什么(重新命令,忙音) ?在期望听到任何内容之前,他们是否听到进程音?确保呼叫方等待在输入最后一数字以后的至少10秒,因为他们可能必须等待interdigit计时器超时。

  • 生成一路由计划报告在Cisco CallManager管理中。请使用它检查在呼叫的呼叫搜索空间的分区的所有路由模式。

  • 如有必要,可添加或修改路由模式或路由过滤器。

  • 如果能找到呼叫被发送的路由模式,请注释模式指向的路由列表或网关。

  • 路由列表,路由组是列表的一部分,并且网关是路由组的一部分的检查。

  • 验证适用设备是否已在 Cisco CallManager 中注册。

  • 如果没有对Cisco CallManager的访问,请获得show tech获取此信息和验证。

  • 密切注意@符号。这是一种可展开以包含许多不同内容的宏。它常与过滤选项组合使用。

  • 如果设备不作为分区的部分,被认为一部分的空或默认分区。每个用户应该能调用该设备。空分区总是被搜索的为时

  • 如果拨号匹配9.@模式,并且它采取的一个外部号码10秒,在呼叫经历前,请检查过滤选项。9.@模式,当拨号一个七位数字的编号时, (默认情况下)将等10秒。您需要应用路由过滤器到说LOCAL-AREA-CODE DOES-NOT-EXIST和END-OF-DIALING DOES-NOT-EXIST的模式。

分区

路由分区继承Cisco CallManager软件的错误处理功能。即控制台和SDI文件trace为记录信息和错误消息提供。这些消息将是跟踪的数字分析组件的一部分。与跟踪,和设备是在每个分区,与其相关的呼叫搜索空间一起,是重要的在确定问题对分区和呼叫搜索空间配置的下面的了解。

下面的trace是在设备的呼叫搜索空间拨号的编号的示例。对于关于SDI跟踪的更多详细说明,请查看在本文的案例研究。

08:38:54.968 Cisco CallManager|StationInit - InboundStim - OffHookMessageID 
tcpHandle=0x6b88028

  08:38:54.968 Cisco CallManager|StationD - stationOutputDisplayText tcpHandle=0x6b88028, 
  Display= 5000

  08:38:54.968 Cisco CallManager|StationD - stationOutputSetLamp stim: 9=Line 
  instance=1 lampMode=LampOn tcpHandle=0x6b88028

  08:38:54.968 Cisco CallManager|StationD - stationOutputCallState tcpHandle=0x6b88028

  08:38:54.968 Cisco CallManager|StationD - stationOutputDisplayPromptStatus 
  tcpHandle=0x6b88028

  08:38:54.968 Cisco CallManager|StationD - stationOutputSelectSoftKeys tcpHandle=0x6b88028

  08:38:54.968 Cisco CallManager|StationD - stationOutputActivateCallPlane 
  tcpHandle=0x6b88028|

  08:38:54.968 Cisco CallManager|Digit analysis: match(fqcn="5000", cn="5000", 
  pss="RTP_NC_Hardwood:RTP_NC_Woodland:Local RTP", dd="")

在trace (见上)的数字分析组件中, “pss” (亦称分区搜索空间,呼叫搜索空间)为发出呼叫的设备是列出的。下面,您能看到那“RTP_NC_Hardwood; RTP_NC_Woodland; Local_RTP”是此设备允许呼叫的分区。

08:38:54.968 Cisco CallManager|Digit analysis: potentialMatches=PotentialMatchesExist

  08:38:54.968 Cisco CallManager|StationD - stationOutputStartTone: 33=InsideDialTone 
  tcpHandle=0x6b88028

  08:38:55.671 Cisco CallManager|StationInit - InboundStim - KeypadButtonMessageID 
  kpButton: 5 tcpHandle=0x6b88028

  08:38:55.671 Cisco CallManager|StationD - stationOutputStopTone tcpHandle=0x6b88028

  08:38:55.671 Cisco CallManager|StationD - stationOutputSelectSoftKeys tcpHandle=0x6b88028

  08:38:55.671 Cisco CallManager|Digit analysis: match(fqcn="5000", cn="5000", 
  pss="RTP_NC_Hardwood:RTP_NC_Woodland:Local RTP", dd="5")

  08:38:55.671 Cisco CallManager|Digit analysis: potentialMatches=PotentialMatchesExist

  08:38:56.015 Cisco CallManager|StationInit - InboundStim - KeypadButtonMessageID 
  kpButton: 0 tcpHandle=0x6b88028

  08:38:56.015 Cisco CallManager|Digit analysis: match(fqcn="5000", cn="5000", 
  pss="RTP_NC_Hardwood:RTP_NC_Woodland:Local RTP", dd="50")

  08:38:56.015 Cisco CallManager|Digit analysis: potentialMatches=PotentialMatchesExist

  08:38:56.187 Cisco CallManager|StationInit - InboundStim - KeypadButtonMessageID 
  kpButton: 0 tcpHandle=0x6b88028

  08:38:56.187 Cisco CallManager|Digit analysis: match(fqcn="5000", cn="5000", 
  pss="RTP_NC_Hardwood:RTP_NC_Woodland:Local RTP", dd="500")

  08:38:56.187 Cisco CallManager|Digit analysis: potentialMatches=PotentialMatchesExist

  08:38:56.515 Cisco CallManager|StationInit - InboundStim - KeypadButtonMessageID 
  kpButton: 3 tcpHandle=0x6b88028

  08:38:56.515 Cisco CallManager|Digit analysis: match(fqcn="5000", cn="5000", 
  pss="RTP_NC_Hardwood:RTP_NC_Woodland:Local RTP", dd="5003")

  08:38:56.515 Cisco CallManager|Digit analysis: analysis results

  08:38:56.515 Cisco CallManager||PretransformCallingPartyNumber=5000

从以上示例,关键您注意“PotentialMatchesExist”是编号的数字分析的结果拨号,直到找到完全匹配,并且呼叫相应地路由。

下面trace尝试拨号的地方的编号(1001)不在设备的呼叫搜索空间。再次,关键您注意到,数字分析惯例有潜在的匹配,直到仅第一个数字拨号。路由模式关联与位"1"在不在设备的呼叫搜索空间的分区, “RTP_NC_Hardwood; RTP_NC_Woodland; Local_RTP”。所以电话是被发送的交换机忙音。

08:38:58.734 Cisco CallManager|StationInit - InboundStim - OffHookMessageID 
tcpHandle=0x6b88028

  08:38:58.734 Cisco CallManager|StationD - stationOutputDisplayText tcpHandle=0x6b88028, 
  Display= 5000

  08:38:58.734 Cisco CallManager|StationD - stationOutputSetLamp stim: 9=Line 
  instance=1 lampMode=LampOn tcpHandle=0x6b88028

  08:38:58.734 Cisco CallManager|StationD - stationOutputCallState tcpHandle=0x6b88028

  08:38:58.734 Cisco CallManager|StationD - stationOutputDisplayPromptStatus 
  tcpHandle=0x6b88028

  08:38:58.734 Cisco CallManager|StationD - stationOutputSelectSoftKeys tcpHandle=0x6b88028

  08:38:58.734 Cisco CallManager|StationD - stationOutputActivateCallPlane 
  tcpHandle=0x6b88028

  08:38:58.734 Cisco CallManager|Digit analysis: match(fqcn="5000", cn="5000", 
  pss="RTP_NC_Hardwood:RTP_NC_Woodland:Local RTP", dd="")

  08:38:58.734 Cisco CallManager|Digit analysis: potentialMatches=PotentialMatchesExist

  08:38:58.734 Cisco CallManager|StationD - stationOutputStartTone: 33=InsideDialTone 
  tcpHandle=0x6b88028

  08:38:59.703 Cisco CallManager|StationInit - InboundStim - KeypadButtonMessageID 
  kpButton: 1 tcpHandle=0x6b88028

  08:38:59.703 Cisco CallManager|StationD - stationOutputStopTone tcpHandle=0x6b88028

  08:38:59.703 Cisco CallManager|StationD - stationOutputSelectSoftKeys tcpHandle=0x6b88028

  08:38:59.703 Cisco CallManager|Digit analysis: match(fqcn="5000", cn="5000", 
  pss="RTP_NC_Hardwood:RTP_NC_Woodland:Local RTP", dd="1")

  08:38:59.703 Cisco CallManager|Digit analysis: potentialMatches=NoPotentialMatchesExist

  08:38:59.703 Cisco CallManager|StationD - stationOutputStartTone: 37=ReorderTone 
  tcpHandle=0x6b88028

路由分区工作在关联分区名称旁边用在系统的每个目录号。目录号可以呼叫,只有当呼叫设备包含在其分区搜索空间允许安置呼叫分区内的列表的分区。对路由的此提供非常强大的控制。

当发出呼叫,数字分析尝试解析已拨号仅地址在分区搜索空间指定的那些分区。每分区名称包括分离子集全局dialable的地址空间。从每个列出的分区,数字分析获取该最佳匹配拨号数字顺序的模式。然后,从在匹配的模式中,数字分析选择佳匹配。如果两个模式均等地匹配拨号数字顺序,数字分析选择用分区关联的模式列出首先在分区搜索空间欲知更多信息, (请参阅关于最匹配的路由的文档)。

安全

Cisco CallManager可以配置创建用户的一个安全拨号方案。这可以通过使用分区和呼叫搜索空间执行,除根据(代表北美编号方案)的部分的更加普通的过滤之外“@”宏在一个路由模式,例如区域代码。分区和呼叫搜索空间是安全的必要组成部分并且为多租户环境和创建一个单个用户级是特别有用的。过滤是能添加另外的粒度到安全规划呼叫搜索空间/分区概念的一子集。

这是分机对Dial Plan部分,上述。当尝试解决过滤问题时,请建议,它不是可行运行SDI trace。没有足够的信息,并且在导致另外的害处的可能性是太极大的。

运行在Cisco CallManager的show tech。以下信息在Route Filter部分出现。

Show-tech
名称 dialPlanWizardG 条款
CiscoDallasInte 1 (国际
CiscoRTPTollByP 1 (区域代码== 9
CiscoRTPLongDis 1 (区域代码EXIS
CiscoDallasToll 1 (区域代码== 9
CiscoDallas911R 1 (服务== 911
CiscoRTPLocal7D 1 (区域代码
CiscoDallasLong 1 (区域代码EXIS
CiscoRTP911RF 1 (服务== 911
CiscoRTPInterna 1 (国际
CiscoDallasLoca 1 (LOCAL-AREA-COD

不幸地,此显示不完整。它,然而,给所有路由过滤器列表在系统的。show命令不允许您发现哪些过滤器关联路由模式。改善的另一个方法了解拨号计划是去Route Plan Report页。下面在更右边的一个选项“查看在文件”。

file_dl.gif

输出将是在Microsoft Excel或一相似的应用程序可以查看的一个逗号分隔的文件:

Show-tech文件输出
Pattern/DN 分区 模式使用情况 设备名 设备描述
1000 设备 SEP003094C2635E Telecaster
1010   设备 SEP003094C2635E Telecaster
1111   设备 SEP00308062CDF1 SEP00308062CDF1
1211   设备 SEP00308062CDF1 SEP00308062CDF1
2999   设备 SAA0010EB007FFE SAA0010EB007FFE
4444   设备 SEP003094C26302 访客
4500   会议  
9.@ CiscoRTPLocalPT 路由 CiscoRTPLocalRL
9.@ CiscoDallasLocalPT 路由 CiscoDallasLocalRL
9.@ CiscoRTPIntlPT 路由 CiscoRTPIntlRL
9.@ CiscoDallasLongDistPT 路由 CiscoDallasLongDistRL
9.@ CiscoRTP911PT 路由 CiscoRTP911RL
9.@ CiscoRTPLongDistPT 路由 CiscoRTPLongDistRL
9.@ CiscoTollByPassToDallasPT 路由 CiscoTollByPassToDallasRL
9.@ CiscoDallasIntlPT 路由 CiscoDallasIntlRL
9.@ CiscoDallas911PT 路由 CiscoDallas911RL
9.@ CiscoTollByPassToRTPPT 路由 CiscoTollByPassToRTPRL

这显示路由模式和他们对应的分区。它不显示路由过滤器或目录号的呼叫搜索空间。更多信息是可用的在实际路由规划报告。如果需要与Cisco TAC联系,您应该通过电子邮件发送此页(如果Cisco CallManager是不可访问的)。

下面路由模式、分区和路由列表/Route组/网关的布局。

route_plan_rpt.gif

服务器响应缓慢

如果交换机的双工不匹配Cisco CallManager服务器的双工,从服务器的慢作用可能发生。对于最佳性能,设置交换机,并且服务器到我们不推荐使用“自动”在交换机或服务器的"100/Full."。您必须重新启动Cisco CallManager服务器使更改生效。

通过网关的交换机忙音

发出呼叫的用户通过网关也许获得交换机忙音,如果他们尝试做一限制呼叫或呼叫阻塞的编号。交换机忙音可能发生,如果呼叫号码是服务中断或,如果PSTN有一设备或服务问题。请务必给交换机忙音的设备注册。并且,请检查您的拨号方案配置保证呼叫可以顺利地路由。

排除故障的交换机忙音步骤通过网关:

  1. 检查网关保证您使用最新的软件负载。

  2. 检查CCO (在www.cisco.com的Cisco在线连接)最新的软件负载、新建的补丁程序或者版本注释与问题相关。

  3. 开始SDI trace并且再现问题。交换机忙音可能是配置问题的结果用基于位置的准入控制或Cisco CallManager也许限制允许的呼叫数量的基于关守的准入控制。在SDI trace,请找出呼叫由其他配置设置确定是否故意地阻塞由路由模式或呼叫搜索空间,或者。

  4. 当呼叫通过PSTN时,交换机忙音能也发生。检查SDI trace Q.931断开消息。如果Q.931断开消息存在,含义另一个当事人导致断开,并且我们不能更正那。

网关注册问题

用在Cisco CallManager的网关遇到的多数常见问题之一是注册问题。注册可以由于各种各样的原因发生故障。

此部分涉及两类似,但是不同的,网关类别。模拟访问AS-X、AT-X和数字访问DT-24+和DE-30+属于一个类别。这些网关是没有直接地连接对网络管理处理器(NMP)的独立单元。第二个类别包括模拟访问WS-X6624和数字访问WS-X6608。这些网关是在有直接连接的一个Catalyst 6000机箱安装的前端对控制和statusing的NMP。

使用粗体的文本,在下面的示例中的,解释的消息识别。这是为了使容易为了您能发现。在实际显示输出中,文本不粗体的。示例是从WS-X6624。

检查的第一件事是网关是正在运行的。所有网关有闪烁1秒的“检测信号” LED, 1秒,当网关软件正常时运行。如果此LED根本不闪烁,也非常迅速地不闪烁,则网关软件不运行。通常,这将导致网关的自动重置。并且,如果它不能在大约2到3分钟之后,完成注册过程重置网关是正常的。因此,当设备重置时,您可以偶然查看检测信号LED。如果正常闪烁的模式没在10到15秒出现,则网关遭受严重故障。在AS-X或AT-X网关上,检测信号LED是显示在前面板的最右端绿色指示灯。在DT-24+或DE-30+网关上,它是最左端红色指示灯在卡的上缘。在模拟访问WS-X6624,它是一个绿色指示灯在刀片里面(不可视从前面板)在右边最右端卡侧缘在前面附近。最后,在数字访问WS-X6608有在刀片的8个间距中的每一个的分开的检测信号LED。有在卡(不可视从方式的前面板)大约2/3间的8个红色指示灯朝着后面。

检查的第二件事是网关接收其IP地址。独立网关必须通过DHCP或BOOTP收到其IP地址。Catalyst网关可能收到其IP地址由DHCP, BOOTP,或者由手动配置通过NMP。如果访问DHCP服务器,检查独立网关的最佳方法是验证设备有在IP地址的一未清租期。如果网关在您的服务器出现,这是一好征兆,但是不明确的。删除租期在DHCP服务器,然后重置网关。如果网关再现于有一租期的服务器在两三分钟内,则一切在此区域优良工作。否则,或者网关不能然后与DHCP服务器联系(不转发的路由器不正确地配置和DHCP广播?是服务器运行?),或者不能得到肯定答复(是IP地址池被耗尽?)。如果检查这些建议不产生答案,请使用嗅探器跟踪确定特定问题。

对于Catalyst 6000网关,您应该确保, NMP能与网关联络。您能通过ping其从NMP的内部IP地址的尝试检查此。IP地址在格式:

127.1.module.port

因此,在我们的示例,我们会执行:

Console (enable) ping 127.1.7.1

127.1.7.1 is alive

如果ping工作, show port命令然后将显示IP地址信息。确保IP地址信息,并且TFTP IP地址正确。如果网关失败得到有效DHCP信息,可以由Cisco TAC提供)的tracy工具(可以用于确定问题。发出从Cat6000 CLI的命令:

tracy_start mod端口

在本例中, WS-X6624是模块7,并且只有单个860处理器,因此它是端口1。我们会发出的命令是tracy_start 7 1

以下输出实际上是从网关板的860控制台端口。然而,输出tracy命令只不过是860控制台端口的远程复制是。

      |               |
      |               | 
    | | |           | | | 
  | | | | |       | | | | |
| | | | | | |:.:| | | | | | |:..
C i s c o S y s t e m s
CAT6K Analog Gateway (ELVIS)
APP Version : A0020300, DSP Version : A0030300, Built Jun 1 2000 16:33:01
ELVIS>> 00:00:00.020 (XA) MAC Addr : 00-10-7B-00-13-DE
00:00:00.050 NMPTask:got message from XA Task
00:00:00.050 (NMP) Open TCP Connection ip:7f010101
00:00:00.050 NMPTask:Send Module Slot Info
00:00:00.060 NMPTask:get DIAGCMD
00:00:00.160 (DSP) Test Begin -> Mask<0x00FFFFFF>
00:00:01.260 (DSP) Test Complete -> Results<0x00FFFFFF/0x00FFFFFF>
00:00:01.260 NMPTask:get VLANCONFIG
00:00:02.870 (CFG) Starting DHCP
00:00:02.870 (CFG) Booting DHCP for dynamic configuration.
00:00:06.570 (CFG) DHCP Request or Discovery Sent, DHCPState = INIT_REBOOT
00:00:06.570 (CFG) DHCP Server Response Processed, DHCPState = INIT_REBOOT
00:00:06.780 (CFG) IP Configuration Change! Restarting now...
00:00:10.480 (CFG) DHCP Request or Discovery Sent, DHCPState = INIT
00:00:14:480 (CFG) DHCP Timeout Waiting on Server, DHCPState = INIT
00:00:22:480 (CFG) DHCP Timeout Waiting on Server, DHCPState = INIT
00:00:38:480 (CFG) DHCP Timeout Waiting on Server, DHCPState = INIT

如果上述超时消息继续移动由,则有联系DHCP服务器的问题。检查Catalyst 6000网关端口在正确VLAN。

此信息在show-++ port命令从以前。如果DHCP服务器不在VLAN和Catalyst 6000网关一样,则请确保适当的IP辅助地址配置转发DHCP请求到DHCP服务器。陷在初始状态在VLAN号更改以后网关是可能的,直到网关重置。当在此状态,您能尝试重置网关。在860重置时候,您的tracy会话将失去。所以,您必须关闭您的现有的会话和通过发出以下命令重新建立新的:

tracy_close mod端口

tracy_start mod端口

如果所有这检查,并且仍然看到DHCPState = INIT消息,则看到的检查DHCP服务器是否正确地作用。如果那样,请开始嗅探器跟踪发现请求是否发送,并且服务器是否响应。

一旦DHCP正确地工作,网关将有将允许使用Tracy调试调试程序的一个IP地址。此工具是NMP set命令的一个内置的功能Catalyst网关的并且是可用的作为在独立网关的Windows 98/NT/2000运行的助手应用程序。要使用助手应用程序tracy工具,您需要" Connect "到网关通过使用分配的IP地址。此tracy应用程序在所有网关工作,为每个网关提供一个分开的trace窗口(八可能立即跟踪),并且允许将被记录的跟踪直接地对您指定的文件。

下一步是验证TFTP服务器IP地址正确地提供了给网关。这由在选项66 (名义上或IP地址),选项150 (仅IP地址),或者si_addr (仅IP地址的DHCP通常提供)。如果您的服务器有配置的多个选项, si_addr将优先于选项150,将优先于选项66。如果选项66提供TFTP server的DNS_NAME,则一定由DHCP指定DNS服务器IP地址,并且在选项输入的名称66必须解决到正确TFTP服务器IP地址。Catalyst网关可能由NMP配置禁用DHCP,并且NMP操作员必须在控制台用手然后输入所有配置参数,包括TFTP服务器地址。

另外,网关永远将尝试通过DNS解决命名"CiscoCM1"。如果成功, CiscoCM1 IP地址将优先于任何东西DHCP服务器或NMP为TFTP服务器地址告诉它,即使NMP有禁用的DHCP。

通过使用tracy工具,您能检查在网关的当前TFTP服务器IP地址。输入以下命令获得配置任务编号:

TaskID :0

Cmd :显示tl

寻找有“设置”或“CFG的”一条线路并且请使用相应的数字作为taskID下一条。例如,对于数字访问WS-X6624网关,命令转存DHCP信息是:

TaskID :6

Cmd :show dhcp

TFTP服务器IP地址清楚然后显示。如果它不正确,请验证您的DHCP选项和提供正确的其他信息。

一旦TFTP地址正确,下一步是保证网关从TFTP server获得其配置文件。如果看到以下在tracy输出中,您的TFTP服务可能不正确地工作或网关在Cisco CallManager也许不配置:

00:09:05.620 (CFG) Requesting SAA00107B0013DE.cnf File From TFTP Server

    00:09:18.620 (CFG) TFTP 
    Error: Timeout Awaiting Server Response for .cnf File!

如果不接收配置文件,网关将尝试连接到IP地址和TFTP server一样。可以没关系,除非是在网关需要接收冗余思科CallManager其列表的集群环境。如果卡不正确地接收其TFTP数据,请检查在Cisco CallManager的TFTP服务并且确保它运行。并且,请检查在Cisco CallManager的TFTP trace。

另一常见问题是网关在Cisco CallManager没有正确地配置。一个典型的错误输入网关的一个错误的MAC地址。如果这是盒, Catalyst 6000网关的,您很可能将有在NMP控制台的下列信息每两分钟:

2000 Apr 14 19:24:08 %SYS-4-MODHPRESET:Host process (860) 7/1 got reset asynchronously
2000 Apr 14 19:26:05 %SYS-4-MODHPRESET:Host process (860) 7/1 got reset asynchronously
2000 Apr 14 19:28:02 %SYS-4-MODHPRESET:Host process (860) 7/1 got reset asynchronously

这是什么tracy输出将看上去象,如果网关不在Cisco CallManager数据库:

00:00:01.670 (CFG) Booting DHCP for dynamic configuration.
00:00:05.370 (CFG) DHCP Request or Discovery Sent, DHCPState = INIT_REBOOT
00:00:05.370 (CFG) DHCP Server Response Processed, DHCPState = BOUND
00:00:05.370 (CFG) Requesting DNS Resolution of CiscoCM1
00:00:05.370 (CFG) DNS Error on Resolving TFTP Server Name.
00:00:05.370 (CFG) TFTP Server IP Set by DHCP Option 150 = 10.123.9.2
00:00:05.370 (CFG) Requesting SAA00107B0013DE.cnf File From TFTP Server
00:00:05.370 (CFG) TFTP Error: .cnf File Not Found!
00:00:05.370 (CFG) Requesting SAADefault.cnf File From TFTP Server
00:00:05.380 (CFG) .cnf File Received and Parsed Successfully.
00:00:05.380 (CFG) Updating Configuration ROM...
00:00:05.610 GMSG: GWEvent = CFG_DONE --> GWState = SrchActive
00:00:05.610 GMSG: CCM#0 CPEvent = CONNECT_REQ --> CPState = AttemptingSocket
00:00:05.610 GMSG: Attempting TCP socket with CCM 10.123.9.2
00:00:05.610 GMSG: CCM#0 CPEvent = SOCKET_ACK --> CPState = BackupCCM
00:00:05.610 GMSG: GWEvent = SOCKET_ACK --> GWState = RegActive
00:00:05.610 GMSG: CCM#0 CPEvent = REGISTER_REQ --> CPState = SentRegister
00:00:05.680 GMSG: CCM#0 CPEvent = CLOSED --> CPState = NoTCPSocket
00:00:05.680 GMSG: GWEvent = DISCONNECT --> GWState = Rollover
00:00:20.600 GMSG: GWEvent = TIMEOUT --> GWState = SrchActive
00:00:20.600 GMSG: CCM#0 CPEvent = CONNECT_REQ --> CPState = AttemptingSocket
00:00:20.600 GMSG: Attempting TCP socket with CCM 10.123.9.2
00:00:20.600 GMSG: CCM#0 CPEvent = SOCKET_ACK --> CPState = BackupCCM

另一个可能的注册问题可能是,如果负载信息不正确或负载文件损坏。如果TFTP server不工作,问题可能也发生。在这种情况下, tracy清楚显示TFTP server报告没找到文件:

00:00:07.390 GMSG: CCM#0 CPEvent = REGISTER_REQ --> CPState = SentRegister
00:00:08.010 GMSG: TFTP Request for application load A0021300
00:00:08.010 GMSG: CCM#0 CPEvent = LOADID --> CPState = AppLoadRequest
00:00:08.010 GMSG: ***TFTP Error: File Not Found***
00:00:08.010 GMSG: CCM#0 CPEvent = LOAD_UPDATE --> CPState = LoadResponse

在这种情况下,您能看到网关请求应用程序负载A0021300,虽然正确负载名称是A0020300。对于Catalyst 6000网关,当新应用负载需要获得其对应的DSP装载时,同一问题能发生。如果没找到新的DSP负载,一个相似的消息将出现。

当模拟访问WS-X6224配置获取一不正确应用程序负载时,下列显示输出。输出看似类似于在Cisco CallManager未配置的那网关:

      |               |
      |               | 
    | | |           | | | 
  | | | | |       | | | | |
| | | | | | |:.:| | | | | | |:..
C i s c o S y s t e m s
CAT6K Analog Gateway (ELVIS)
APP Version : A0020300, DSP Version : A0030300, Built Jun 1 2000 16:33:01
ELVIS>> 00:00:00.020 (XA) MAC Addr : 00-10-7B-00-13-DE
00:00:00.050 NMPTask:got message from XA Task
00:00:00.050 (NMP) Open TCP Connection ip:7f010101
00:00:00.050 NMPTask:Send Module Slot Info
00:00:00.060 NMPTask:get DIAGCMD
00:00:00.160 (DSP) Test Begin -> Mask<0x00FFFFFF>
00:00:01.260 (DSP) Test Complete -> Results<0x00FFFFFF/0x00FFFFFF>
00:00:01.260 NMPTask:get VLANCONFIG
00:00:02.030 (CFG) Starting DHCP
00:00:02.030 (CFG) Booting DHCP for dynamic configuration.
00:00:05.730 (CFG) DHCP Request or Discovery Sent, DHCPState = INIT_REBOOT
00:00:05.730 (CFG) DHCP Server Response Processed, DHCPState = BOUND
00:00:05.730 (CFG) Requesting DNS Resolution of CiscoCM1
00:00:05.730 (CFG) DNS Error on Resolving TFTP Server Name.
00:00:05.730 (CFG) TFTP Server IP Set by DHCP Option 150 = 10.123.9.2
00:00:05.730 (CFG) Requesting SAA00107B0013DE.cnf File From TFTP Server
00:00:05.730 (CFG) .cnf File Received and Parsed Successfully.
00:00:05.730 GMSG: GWEvent = CFG_DONE --> GWState = SrchActive
00:00:05.730 GMSG: CCM#0 CPEvent = CONNECT_REQ --> CPState = AttemptingSocket
00:00:05.730 GMSG: Attempting TCP socket with CCM 10.123.9.2
00:00:05.730 GMSG: CCM#0 CPEvent = SOCKET_ACK --> CPState = BackupCCM
00:00:05.730 GMSG: GWEvent = SOCKET_ACK --> GWState = RegActive
00:00:05.730 GMSG: CCM#0 CPEvent = REGISTER_REQ --> CPState = SentRegister
00:00:06.320 GMSG: CCM#0 CPEvent = LOADID --> CPState = LoadResponse
00:01:36.300 GMSG: CCM#0 CPEvent = TIMEOUT --> CPState = BadCCM
00:01:36.300 GMSG: GWEvent = DISCONNECT --> GWState = Rollover
00:01:46.870 GMSG: CCM#0 CPEvent = CLOSED --> CPState = NoTCPSocket
00:01:51.300 GMSG: GWEvent = TIMEOUT --> GWState = SrchActive
00:01:51.300 GMSG: CCM#0 CPEvent = CONNECT_REQ --> CPState = AttemptingSocket
00:01:51.300 GMSG: Attempting TCP socket with CCM 10.123.9.2
00:01:51.300 GMSG: CCM#0 CPEvent = SOCKET_ACK --> CPState = BackupCCM
00:01:51.300 GMSG: GWEvent = SOCKET_ACK --> GWState = RegActive
00:01:51.300 GMSG: CCM#0 CPEvent = REGISTER_REQ --> CPState = SentRegister
00:01:51.890 GMSG: CCM#0 CPEvent = LOADID --> CPState = LoadResponse

此处差异是网关陷在LoadResponse阶段和最终计时。此问题可以通过更正在Cisco CallManager管理Device Defaults区域的负载文件名解决。

网守问题

在开始任何网关对关守故障排除前,请验证有在网络内的IP连通性。假设,有IP连通性,请使用信息在此部分排除故障您的网关。

仅集群间中继线

注意Cisco CallManager版本的3.0(1)网守控制为集群间中继线只是可用的。网守控制为其它设备是可配置,但是不支持配置。

接纳拒绝(ARJ)

ARJs发出,当Cisco CallManager用网守时注册,但是不能发送电话。当网守发出ARJ时,在网守的配置问题应该是主要介绍。然而,下面排除故障的一般使用指南:

  1. 验证从网关的IP连通性到网守。

  2. Show gatekeeper status :验证网守状态是UP。

  3. 有没有在网守定义的区域子网?如果那样,请验证网关的子网在允许子网。

注册拒绝(RRJ)

当Cisco CallManager不能向网守登记时, RRJs发出。当网守发出RRJ时,在网守的配置问题应该是主要介绍。

然而,这是排除故障的一般使用指南:

  1. 验证从网关的IP连通性到网守。

  2. Show gatekeeper status :验证网守状态是UP。

  3. 有没有在网守定义的区域子网?如果那样,请验证网关的子网在允许子网。

当拨打语音邮件试验号码时收到快速忙音

如果终止了和开始的CallManager,在进行一些后更改,请确保您开始utel、ulite、ulogremover和upilot进程。这在实验室里测试了由提交者为CM 2.4.3和uone 4.1e。本质上,除非进程重新启动, UMS设备不会再注册与CallManager。

案例研究我:簇内部Cisco IP电话到Cisco IP电话呼叫

此案例研究详细讨论在两思科IP电话之间的呼叫流在集群内,呼叫集群内呼叫。此案例研究也着重Cisco CallManager和Cisco IP电话初始化、注册和Keepalive进程。那由集群内呼叫流的详细说明跟随。在前面部分解释使用跟踪程序和工具讨论的这些进程。

拓扑示例

以下图表表示此案例研究的拓扑示例。在图表中有名为团星1和团星的两集群2。而在团星1的两思科CallManager被命名CCM1和CCM2,在团星1的两思科CallManager呼叫CCM3和CCM4。为此案例研究收集的跟踪是从CCM1,在团星2.查找。呼叫流根据在团星2.的两思科IP电话。这两思科IP电话的IP地址分别为172.16.70.230 (目录号1000)和172.16.70.231 (目录号1001)。

ios_gatekeeper.gif

Cisco IP 电话初始化进程

Cisco IP电话初始化(或“启动”)进程下面详细解释。

  1. 在初始化, Cisco IP电话发送请求对DHCP服务器获得IP地址、DNS服务器地址和TFTP server名称或者地址,如果适当。选项在DHCP服务器(选项066,选项150设置,等等)。它在DHCP服务器(选项003)也得到默认网关地址,如果设置。

  2. 如果TFTP服务器的DNS名由DHCP发送,则DNS服务器IP地址要求映射名称到IP地址。如果DHCP服务器发送TFTP server的IP地址此步骤绕过。在这种情况下,因为DNS未配置,请学习, DHCP服务器发送TFTP的IP地址。

  3. 如果TFTP server名称在DHCP回复没有包括,则Cisco IP电话使用服务器名。

  4. 配置文件(.cnf)文件从TFTP server被检索。所有.cnf文件有命名SEP<mac_address>.cnf, “SEP”是Selsius以太网电话的一缩略语。如果这第一次是电话用Cisco CallManager注册,则默认文件, SEPdefault.cnf,下载对Cisco IP电话。在这种情况下请学习,第一Cisco IP电话使用IP地址172.16.70.230 (其MAC地址是SEP0010EB001720),并且第二Cisco IP电话使用IP地址172.16.70.231 (其MAC地址是SEP003094C26105)。

  5. 所有.cnf文件包括主要的和附属Cisco CallManager的IP地址。Cisco IP电话使用IP地址与主Cisco CallManager联系和注册。

  6. 一旦Cisco IP电话用Cisco CallManager连接并且注册, Cisco CallManager告诉Cisco IP电话哪个可执行的版本(呼叫加载ID)运行。如果指定的版本不匹配在Cisco IP电话的执行版本, Cisco IP电话将请求从TFTP server的新的可执行并且自动地重置。

以下嗅探器跟踪示例汇总电话初始化进程。此跟踪示例没有为此案例研究的拓扑示例采取,但是提供事件的系列的示例在Cisco IP电话初始化进程中发生。

sniffer_trace.gif

Skinny站注册过程

使用思科小型站协议,思科IP电话与Cisco CallManager联络。注册过程允许一个模状站,例如Cisco IP电话,通知Cisco CallManager其存在和做呼叫可能。以下图表示被交换在Cisco IP电话的不同的消息(“站点”)和Cisco CallManager之间。

/image/gif/paws/30266/skinny.gif

在模状站注册过程的主要的消息在下表里描述。

模状站注册过程说明
消息 说明
站点寄存器 站点传送此信息宣布其存在到控制的Cisco CallManager。
站点重置 Cisco CallManager传送此信息发出命令站点重置其进程。
站点IP波尔特 站点传送此信息提供Cisco CallManager用户数据报协议(UDP)端口与RTP数据流一起使用。
站点寄存器确认 Cisco CallManager传送此信息确认站点的注册。
站点寄存器拒绝 Cisco CallManager传送此信息拒绝从指示的电话的一注册尝试。
char text[StationMaxDisplayTextSize]; 

};
Where:文本是字符串,最大长度33个字节,包含原因的文本说明注册拒绝。
站点功能请求 Cisco CallManager传送此信息请求站点的当前功能。站点功能可能包括压缩标准和其他H.323功能。
站点版本请求 站点传送此信息请求软件负载的版本号站点的。
站点版本答复 Cisco CallManager传送此信息通知站点适当的软件版本编号。
站点功能答复 站点传送此信息到Cisco CallManager以回应站点功能请求。站点的功能在Cisco CallManager被缓存并且用于协商终端的功能用H.323兼容终端。
站点按钮模板请求 站点传送此信息请求该特定终端或Cisco IP电话的按钮模板定义。
站点按钮模板答复 Cisco CallManager传送此信息更新在站点包含的按钮模板信息。
站点时间伊达市请求 站点传送此信息请求当前日期和时间内部使用情况的和显示的作为文本字符串。
站点定义了时间与日期 Cisco CallManager使用此消息提供日期和时间信息给站点。它为站点提供时间同步。

集群内 Cisco IP 电话对 Cisco IP 电话呼叫流

此部分描述呼叫另一Cisco IP电话(目录号1001)在同一集群内的Cisco IP电话(目录号1000)。集群是思科的CallManager的一组有一个普通的发行商SQL数据库和许多用户SQL数据库。

在我们的拓扑示例方面, CCM1是发行商,并且CCM2是用户。两思科IP电话(1000和1001)注册对CCM1和CCM2,分别。呼叫流在下图所示中显示。使用Intra-Cluster Control Protocol (ICCP),在集群内的两思科CallManager与彼此联络。当Cisco IP电话是摘机时,开始一控制模状站会话(与TCP作为底层协议)用Cisco CallManager。在呼叫控制信令设立在两思科IP电话和他们的各自思科CallManager之间后, RTP数据流开始流直接地在两个电话之间,如下图所示所显示。此集群内呼叫的模状站呼叫流消息在下一部分解释。

/image/gif/paws/30266/1000_calls_1001.gif

呼叫流期间 Cisco IP 电话到 Cisco IP 电话小型站消息交换

以下图显示消息示例交换在两个模状站之间的。模状站或者Cisco IP电话,首次对Cisco CallManager的连接, Cisco CallManager在打开控制会话前然后执行数字分析与目的地模状站。当以下图表指示,小型站消息写入使用简单英语,因此他们可以由最终用户容易地了解。因此,这些消息在此部分没有解释。然而,当跟踪被检查时,这些呼叫流小型站消息在后面的章节较详细地解释。

/image/gif/paws/30266/call_flow.gif

Cisco CallManager 初始化进程

在此部分Cisco CallManager初始化进程在从CCM1捕获的跟踪帮助下将解释(识别由IP地址172.16.70.228)。因为他们选派每数据包发送在终端之间,如描述以前, SDI跟踪是一个非常有效故障排除工具。此部分将描述发生的事件,当Cisco CallManager初始化。知道如何读trace帮助您适当地排除故障多种Cisco CallManager进程和那些进程效果在服务的例如会议,呼叫转接,等等。

从Cisco CallManager SDI跟踪程序的下列信息显示在其中一的初始化进程思科CallManager,在这种情况下, CCM1。查看下面每个消息的说明。

  • 第一条消息表明Cisco CallManager开始其初始化进程。

  • 第二个消息表明Cisco CallManager读了默认数据库值,是主要的或发布人数据库(此案件)。

  • 第三个消息表明听的Cisco CallManager在TCP端口8002的多种消息。

  • 第四个消息显示,在侦听对这些消息以后, Cisco CallManager添加了秒钟Cisco CallManager到其列表:CCM2 (172.16.70.229)。

  • 第五个消息表明Cisco CallManager开始和运行Cisco CallManager版本3.0.20。

16:02:47.765 CCM|CMProcMon - CallManagerState Changed - Initialization Started.
16:02:47.796 CCM|NodeId: 0, EventId: 107 EventClass: 3 EventInfo: Cisco CM Database Defaults Read
16:02:49.937 CCM| SDL Info - NodeId: [1], Listen IP/Hostname: [172.16.70.228], Listen Port: [8002]
16:02:49.984 CCM|dBProcs - Adding SdlLink to NodeId: [2], IP/Hostname: [172.16.70.229]
16:02:51.031 CCM|NodeId: 1, EventId: 1 EventClass: 3 EventInfo: Cisco CallManager Version=<3.0(0.20)> started

自启动过程

一旦Cisco CallManager是正在运行的,开始在本身内的几其他进程。其中一些进程下面显示,包括MulticastPoint Manager、UnicastBridge Manager、数字分析和路由列表。当排除故障与功能涉及的问题在Cisco CallManager时,在这些进程中描述的消息可以是非常有用的。

例如,假设,路由列表不作用并且是不可用的。要排除故障此问题,您会监控这些跟踪确定Cisco CallManager是否开始RoutePlanManager,并且,如果尝试装载路由列表。在下面的配置示例中, RouteListName= " ipwan”和RouteGroupName= " ipwan”装载并且开始。

16:02:51.031 CCM|MulicastPointManager - Started
16:02:51.031 CCM|UnicastBridgeManager - Started
16:02:51.031 CCM|MediaTerminationPointManager - Started
16:02:51.125 CCM|MediaCoordinator(1) - started
16:02:51.125 CCM|NodeId: 1, EventId: 1543 EventClass: 2 EventInfo: Database manager started
16:02:51.234 CCM|NodeId: 1, EventId: 1542 EventClass: 2 EventInfo: Link manager started
16:02:51.390 CCM|NodeId: 1, EventId: 1541 EventClass: 2 EventInfo: Digit analysis started
16:02:51.406 CCM|RoutePlanManager - Started, loading RouteLists
16:02:51.562 CCM|RoutePlanManager - finished loading RouteLists
16:02:51.671 CCM|RoutePlanManager - finished loading RouteGroups
16:02:51.671 CCM|RoutePlanManager - Displaying Resulting RoutePlan
16:02:51.671 CCM|RoutePlanServer - RouteList Info, by RouteList and RouteGroup Selection Order
16:02:51.671 CCM|RouteList - RouteListName=''ipwan''
16:02:51.671 CCM|RouteList - RouteGroupName=''ipwan''
16:02:51.671 CCM|RoutePlanServer - RouteGroup Info, by RouteGroup and Device Selection Order
16:02:51.671 CCM|RouteGroup - RouteGroupName=''ipwan''

以下trace显示添加设备172.16.70.245的路由组,是在团星查找的CCM3 1并且假定有H.323设备。在这种情况下,路由组创建路由呼叫到在团星1的CCM3与Cisco IOS网守权限。如果有路由呼叫的问题对在团星查找的Cisco IP电话1,则下列信息将帮助您查找问题的原因。

16:02:51.671 CCM|RouteGroup - DeviceName=''172.16.70.245''
16:02:51.671 CCM|RouteGroup -AllPorts

一部分的初始化进程显示Cisco CallManager添加Dns。通过检查这些消息,您能确定Cisco CallManager是否读了从数据库的目录号。

16:02:51.671 CCM|NodeId: 1, EventId: 1540 EventClass: 2 EventInfo: Call control started
16:02:51.843 CCM|ProcessDb - Dn = 2XXX, Line = 0, Display = , RouteThisPattern, 
NetworkLocation = OffNet, DigitDiscardingInstruction = 1, WhereClause =
16:02:51.859 CCM|Digit analysis: Add local pattern 2XXX , PID: 1,80,1
16:02:51.859 CCM|ForwardManager - Started
16:02:51.984 CCM|CallParkManager - Started
16:02:52.046 CCM|ConferenceManager - Started

在以下跟踪Cisco CallManager的设备管理器静态正在初始化两个设备。有IP地址172.17.70.226的设备是网守,并且有IP地址172.17.70.245的设备是在不同的集群的另一Cisco CallManager。该Cisco CallManager注册作为一个H.323网关用此Cisco CallManager。

16:02:52.250 CCM|DeviceManager: Statically Initializing Device; DeviceName=172.16.70.226
16:02:52.250 CCM|DeviceManager: Statically Initializing Device; DeviceName=172.16.70.245

Cisco CallManager 注册过程

SDI trace的另一个重要部分是注册过程。当设备被加电时,通过DHCP获得信息,连接对其.cnf文件的TFTP server,然后连接到在.cnf文件指定的Cisco CallManager。设备能是MGCP网关、小型网关或者Cisco IP电话。所以,能发现是重要的设备是否在Cisco AVVID网络顺利地注册。

在以下trace, Cisco CallManager接收注册的新连接。注册设备是"MTP_nsa-cm1" (在CCM1的MTP服务)和"CFB_nsa-cm1" (在CCM1的会议桥服务)。因此这些是运作在Cisco CallManager的软件服务,但是对待内部地作为另外外部服务和分配TcpHandle、插口号和端口号以及设备名。

16:02:52.750 CCM|StationInit - New connection accepted. DeviceName=, TCPHandle=0x4fbaa00, 
Socket=0x594, IPAddr=172.16.70.228, Port=3279, StationD=[0,0,0]
16:02:52.750 CCM|StationInit - New connection accepted. DeviceName=, TCPHandle=0x4fe05e8, 
Socket=0x59c, IPAddr=172.16.70.228, Port=3280, StationD=[0,0,0]
16:02:52.781 CCM|StationInit - Processing StationReg. regCount: 1 DeviceName=MTP_nsa-cm1, 
TCPHandle=0x4fbaa00, Socket=0x594, IPAddr=172.16.70.228, Port=3279, StationD=[1,45,2]
16:02:52.781 CCM|StationInit - Processing StationReg. regCount: 1 DeviceName=CFB_nsa-cm1, 
TCPHandle=0x4fe05e8, Socket=0x59c, IPAddr=172.16.70.228, Port=3280, StationD=[1,96,2]

在以下trace,小型站消息传送在Cisco IP电话和Cisco CallManager之间。Cisco IP电话(172.16.70.231)用Cisco CallManager注册。参考小型站消息的说明前在此部分欲知更多信息。当Cisco CallManager收到从Cisco IP电话的注册请求,分配TcpHandle编号到此设备。此编号依然是同样,直到设备或Cisco CallManager重新启动。所以,您能跟随与特定设备涉及的所有事件通过搜索为或记录设备的TcpHandle编号,在十六进制出现。并且,请注意该Cisco CallManager提供加载ID给Cisco IP电话。凭此加载ID, Cisco IP电话运行对应于设备的可执行文件(获取从TFTP server)。

16:02:57.000 CCM|StationInit - New connection accepted. DeviceName=, TCPHandle=0x4fbbc30, 
Socket=0x5a4, IPAddr=172.16.70.231, Port=52095, StationD=[0,0,0]
16:02:57.046 CCM|NodeId: 1, EventId: 1703 EventClass: 2 EventInfo: Station Alarm, 
TCP Handle: 4fbbc30, Text: Name=SEP003094C26105 Load=AJ.30 Parms=Status/IPaddr 
LastTime=A P1: 2304(900) P2: -414838612(e74610ac)
16:02:57.046 CCM|StationInit - ***** InboundStim - AlarmMessageID 
tcpHandle=0x4fbbc30 Message="Name=SEP003094C26105 Load=AJ.30 Parms=Status/IPaddr LastTime=A" 
Parm1=2304 (900) Parm2=-414838612 (e74610ac)
16:02:57.093 CCM|StationInit - Processing StationReg. regCount: 1 DeviceName=SEP003094C26105, 
TCPHandle=0x4fbbc30, Socket=0x5a4, IPAddr=172.16.70.231, Port=52095, StationD=[1,85,1]
16:02:57.093 CCM|StationInit - InboundStim - IpPortMessageID: 32715(0x7fcb) 
tcpHandle=0x4fbbc30

Cisco CallManager KeepAlive 进程

两个站点、设备或者服务和Cisco CallManager使用下列信息维护通信信道的知识在他们之间的。消息用于开始保证的Keepalive顺序Cisco CallManager和站点之间的通信链路依然是活动。下列信息能起源于Cisco CallManager或站点。

16:03:02.328 CCM|StationInit - InboundStim - KeepAliveMessage - Forward KeepAlive to StationD. 
DeviceName=MTP_nsa-cm2, TCPHandle=0x4fa7dc0, Socket=0x568, IPAddr=172.16.70.229, Port=1556, 
StationD=[1,45,1]
16:03:02.328 CCM|StationInit - InboundStim - KeepAliveMessage - Forward KeepAlive to StationD. 
DeviceName=CFB_nsa-cm2, TCPHandle=0x4bf8a70, Socket=0x57c, IPAddr=172.16.70.229, Port=1557, 
StationD=[1,96,1]
16:03:06.640 CCM|StationInit - InboundStim - KeepAliveMessage - Forward KeepAlive to StationD. 
DeviceName=SEP0010EB001720, TCPHandle=0x4fbb150, Socket=0x600, IPAddr=172.16.70.230, Port=49211, 
StationD=
[1,85,2]
16:03:06.703 CCM|StationInit - InboundStim - KeepAliveMessage - Forward KeepAlive to StationD. 
DeviceName=SEP003094C26105, TCPHandle=0x4fbbc30, Socket=0x5a4, IPAddr=172.16.70.231, Port=52095, 
StationD=
[1,85,1]

在以下trace的消息表示表明的Keepalive顺序Cisco CallManager和站点之间的通信链路是活跃的。再次,这些消息能由Cisco CallManager或站点产生。

16:03:02.328 CCM|MediaTerminationPointControl - stationOutputKeepAliveAck tcpHandle=4fa7dc0
16:03:02.328 CCM|UnicastBridgeControl - stationOutputKeepAliveAck tcpHandle=4bf8a70
16:03:06.703 CCM|StationInit - InboundStim - IpPortMessageID: 32715(0x7fcb) tcpHandle=0x4fbbc30
16:03:06.703 CCM|StationD - stationOutputKeepAliveAck tcpHandle=0x4fbbc30

Cisco CallManager 集群内呼叫流跟踪

以下SDI跟踪详细测试集群内呼叫流。在呼叫流的思科IP电话可以由DN、tcpHandle和IP地址识别。在团星(DN=1001、tcpHandle=0x4fbbc30, IP address=172.16.70.231)查找的Cisco IP电话2呼叫在同样团星(DN=1000、tcpHandle= 0x4fbb150, IP地址的另一Cisco IP电话= 172.16.70.230)。切记您能通过trace跟随设备通过查看设备的TCP把柄值、时间戳或者名称。设备的TCP把柄值依然是同样,直到设备重新启动或脱机。

以下跟踪显示Cisco IP电话(1001)是摘机。下面的trace显示唯一消息、TCP把柄和被叫号码哪些在Cisco IP电话显示。因为用户未设法拨按任何数字,这时没有呼叫号码。以在思科IP电话和Cisco CallManager之间的小型站消息的形式下面的信息是。

16:05:41.625 CCM|StationInit - InboundStim - OffHookMessageID tcpHandle=0x4fbbc30
16:05:41.625 CCM|StationD - stationOutputDisplayText tcpHandle=0x4fbbc30, Display= 1001

下trace表示去从Cisco CallManager的小型站消息Cisco IP电话。第一条消息是开在主叫方的Cisco IP电话的闪亮指示。

16:05:41.625 CCM|StationD - stationOutputSetLamp stim: 9=Line instance=1 lampMode=LampOn 
tcpHandle=0x4fbbc30

Cisco CallManager用于stationOutputCallState消息通知某一相关电话的信息的站点。

16:05:41.625 CCM|StationD - stationOutputCallState tcpHandle=0x4fbbc30

Cisco CallManager在Cisco IP电话用于stationOutputDisplayPromptStatus消息造成一相关电话的提示消息显示。

16:05:41.625 CCM|StationD - stationOutputDisplayPromptStatus tcpHandle=0x4fbbc30

Cisco CallManager用于stationOutputSelectSoftKey消息造成模状站选择特定的软键。

16:05:41.625 CCM|StationD - stationOutputSelectSoftKeys tcpHandle=0x4fbbc30

Cisco CallManager用于下个消息提示模状站至于显示的正确线路上下文。

16:05:41.625 CCM|StationD - stationOutputActivateCallPlane tcpHandle=0x4fbbc30

在下列信息,数字分析进程准备识别传入的数字,并且检查他们潜在的路由在数据库匹配。条目, cn=1001,代表主叫方编号。dd= ""代表拨号数字,将显示呼叫的部件号。注意StationInit消息由电话发送, StationD信息由Cisco CallManager传送,并且数字分析由Cisco CallManager执行。

16:05:41.625 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", dd="")
16:05:41.625 CCM|Digit analysis: potentialMatches=PotentialMatchesExist

以下调试消息显示Cisco CallManager提供内部的拨号音给主叫方Cisco IP电话。

16:05:41.625 CCM|StationD - stationOutputStartTone: 33=InsideDialTone tcpHandle=0x4fbbc30

一旦Cisco CallManager在Cisco IP电话检测传入消息并且认可键盘按钮1按,立即终止输出音。

16:05:42.890 CCM|StationInit - InboundStim - KeypadButtonMessageID kpButton: 1 
tcpHandle=0x4fbbc30
16:05:42.890 CCM|StationD - stationOutputStopTone tcpHandle=0x4fbbc30
16:05:42.890 CCM|StationD - stationOutputSelectSoftKeys tcpHandle=0x4fbbc30
16:05:42.890 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", dd="1")
16:05:42.890 CCM|Digit analysis: potentialMatches=PotentialMatchesExist
16:05:43.203 CCM|StationInit - InboundStim - KeypadButtonMessageID kpButton: 0 
tcpHandle=0x4fbbc30
16:05:43.203 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", dd="10")
16:05:43.203 CCM|Digit analysis: potentialMatches=PotentialMatchesExist
16:05:43.406 CCM|StationInit - InboundStim - KeypadButtonMessageID kpButton: 0 
tcpHandle=0x4fbbc30
16:05:43.406 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", dd="100")
16:05:43.406 CCM|Digit analysis: potentialMatches=PotentialMatchesExist|
16:05:43.562 CCM|StationInit - InboundStim - KeypadButtonMessageID kpButton: 0 
tcpHandle=0x4fbbc30
16:05:43.562 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", dd="1000")

一旦Cisco CallManager接收足够的位配比,提供数字分析导致表格格式。在电话按的任何额外的位,在此点将由Cisco CallManager后忽略,因为已经找到了匹配。

16:05:43.562 CCM|Digit analysis: analysis results
16:05:43.562 CCM||PretransformCallingPartyNumber=1001
|CallingPartyNumber=1001
|DialingPattern=1000
|DialingRoutePatternRegularExpression=(1000)
|PotentialMatches=PotentialMatchesExist
|DialingSdlProcessId=(1,38,2)
|PretransformDigitString=1000
|PretransformPositionalMatchList=1000
|CollectedDigits=1000
|PositionalMatchList=1000
|RouteBlockFlag=RouteThisPattern

下trace显示Cisco CallManager派出此信息到被叫方电话(电话由tcpHandle编号识别)。

16:05:43.578 CCM|StationD - stationOutputCallInfo CallingPartyName=1001, CallingParty=1001, 
CalledPartyName=1000, 
CalledParty=1000, tcpHandle=0x4fbb150

下trace表明Cisco CallManager预定闪亮指示为在被叫方的Cisco IP电话的呼入呼叫征兆闪烁。

16:05:43.578 CCM|StationD - stationOutputSetLamp stim: 9=Line instance=1 
lampMode=LampBlink tcpHandle=0x4fbb150

在以下跟踪, Cisco CallManager提供振铃器、显示通知和其他相关电话的信息给被叫方的Cisco IP电话。再次,您能看到所有消息处理对同样Cisco IP电话,因为同样tcpHandle使用在跟踪中。

16:05:43.578 CCM|StationD - stationOutputSetRinger: 2=InsideRing tcpHandle=0x4fbb150
16:05:43.578 CCM|StationD - stationOutputDisplayNotify tcpHandle=0x4fbb150
16:05:43.578 CCM|StationD - stationOutputDisplayPromptStatus tcpHandle=0x4fbb150
16:05:43.578 CCM|StationD - stationOutputSelectSoftKeys tcpHandle=0x4fbb150

注意Cisco CallManager也提供相似的信息给主叫方的Cisco IP电话。再次, tcpHandle用于区分在思科IP电话之间。

16:05:43.578 CCM|StationD - stationOutputCallInfo CallingPartyName=1001, CallingParty=1001, 
CalledPartyName=, 
CalledParty=1000, tcpHandle=0x4fbbc30
16:05:43.578 CCM|StationD - stationOutputCallInfo CallingPartyName=1001, CallingParty=1001, 
CalledPartyName=1000, 
CalledParty=1000, tcpHandle=0x4fbbc30

在下trace, Cisco CallManager提供对主叫方的Cisco IP电话的警告或振铃音,通知连接被建立了。

16:05:43.578 CCM|StationD - stationOutputStartTone: 36=AlertingTone tcpHandle=0x4fbbc30
16:05:43.578 CCM|StationD - stationOutputCallState tcpHandle=0x4fbbc30
16:05:43.578 CCM|StationD - stationOutputSelectSoftKeys tcpHandle=0x4fbbc30
16:05:43.578 CCM|StationD - stationOutputDisplayPromptStatus tcpHandle=0x4fbbc30

这时,被叫方的Cisco IP电话是摘机。所以, Cisco CallManager停止生成振铃器音对主叫方。

16:05:45.140 CCM|StationD - stationOutputStopTone tcpHandle=0x4fbbc30

在下列信息, Cisco CallManager造成模状站开始接收单播RTP数据流。要执行如此, Cisco CallManager提供被叫方以及编码信息和数据包大小的IP地址在毫秒(毫秒)。Packetsize是包含采样时间的整数以用于的毫秒创建RTP数据包。

注意: 此值通常设置为30msec。在这种情况下,它设置为20msec。

16:05:45.140 CCM|StationD - stationOutputOpenReceiveChannel tcpHandle=0x4fbbc30 
myIP: e74610ac (172.16.70.231)
16:05:45.140 CCM|StationD - ConferenceID: 0 msecPacketSize: 20 compressionType:
(4)Media_Payload_G711Ulaw64k

同样地, Cisco CallManager提供信息给被叫方(1000)。

16:05:45.140 CCM|StationD - stationOutputOpenReceiveChannel tcpHandle=0x4fbb150 
myIP: e64610ac (172.16.70.230)
16:05:45.140 CCM|StationD - ConferenceID: 0 msecPacketSize: 20 
compressionType:(4)Media_Payload_G711Ulaw64k

Cisco CallManager接收从被叫方的应答消息设立的RTP数据流的开放信道,以及被叫方的IP地址。此消息是通知Cisco CallManager关于模状站的两个信息。首先,它包含open操作的状态。其次,它包含接收端口地址和编号发射的对远程终端。发射器的IP地址(呼叫部分) RTP数据流是IP地址,并且PortNumber是RTP数据流发射器(主叫方)的IP端口号。

16:05:45.265 CCM|StationInit - InboundStim - StationOpenReceiveChannelAckID 
tcpHandle=0x4fbb150, Status=0, 
IpAddr=0xe64610ac, Port=17054, PartyID=2

Cisco CallManager用于下列信息定购站点开始传送音频流对指示的远程思科IP电话的IP地址和端口号。

16:05:45.265 CCM|StationD - stationOutputStartMediaTransmission tcpHandle=0x4fbbc30 
myIP: e74610ac 
(172.16.70.231)
16:05:45.265 CCM|StationD - RemoteIpAddr: e64610ac (172.16.70.230) RemoteRtpPortNumber: 
17054 msecPacketSize: 20 
compressionType:(4)Media_Payload_G711Ulaw64k

在以下跟踪,以前解释的信息传送给被叫方。这些消息由指示的消息跟随RTP媒体流开始在呼叫和主叫用户名详细资料之间。

16:05:45.312 CCM|StationD - stationOutputStartMediaTransmission tcpHandle=0x4fbb150 
myIP: e64610ac 
(172.16.70.230)
16:05:45.328 CCM|StationD - RemoteIpAddr: e74610ac (172.16.70.231) RemoteRtpPortNumber: 
18448 msecPacketSize: 20 
compressionType:(4)Media_Payload_G711Ulaw64k
16:05:46.203 CCM|StationInit - InboundStim - OnHookMessageID tcpHandle=0x4fbbc30

主叫方的Cisco IP电话终于去挂机,终止在模状站和Cisco CallManager之间的所有控制消息,以及在模状站之间的RTP数据流。

16:05:46.203 CCM|StationInit - InboundStim - OnHookMessageID tcpHandle=0x4fbbc30

案例研究II :思科IP电话到Cisco IOS网关呼叫

在上一个案例研究,集群内呼叫的呼叫流和故障排除技术详细讨论。此案例研究检查呼叫通过Cisco IOS网关的Cisco IP电话对在PSTN连接的通过本地PBX或某处电话。概念上,当呼叫到达Cisco IOS网关,网关将传送呼叫到暂停其局外交换站(FXS)端口的电话,或者对PBX。如果呼叫转发对PBX,可能终止到暂停本地PBX的电话或PBX在PSTN将转发它,并且呼叫在PSTN将终止某处。

拓扑示例

以下图表显示此案例研究的拓扑示例。呼叫通过Cisco IOS网关和接口路由对PSTN,或者PBX是T1/CAS或T1/PRI。网关可以是型号26XX、36XX、53XX或者6K。

/image/gif/paws/30266/ios_gatekeeper2.gif

呼叫流跟踪

此部分讨论呼叫流经从Cisco CallManager跟踪文件CCM000000000的示例(参考文件的位置的前面部分)。跟踪在这种情况下学习仅重点在呼叫流,因为更加详细的跟踪信息在上一个案例研究(初始化、注册,保活机制已经解释,等等)。

在此呼叫流,在集群(目录号1001)查找的Cisco IP电话2在PSTN呼叫电话(目录号3333)查找某处。切记您能通过trace跟随设备通过查看设备的TCP把柄值、时间戳或者名称。设备的TCP把柄值依然是同样,直到设备重新启动或脱机。

在以下跟踪, Cisco IP电话(1001)是摘机。trace显示唯一消息、TCP把柄和呼叫号码,在Cisco IP电话显示。因为用户未设法拨按任何数字,这时没有被叫号码。

16:05:46.37515:20:18.390 CCM|StationInit - InboundStim ? OffHookMessageID tcpHandle=0x5138d98
15:20:18.390 CCM|StationD - stationOutputDisplayText tcpHandle=0x5138d98, Display=1001 

在以下跟踪,用户每次拨号3333,一个位。第3333是电话的目标号码,在PSTN网络查找某处。Cisco CallManager的数字分析进程当前活跃的和分析位发现呼叫需要路由的地方。数字分析的更多详细说明在上一个案例研究提供了。

15:20:18.390 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", dd="")
15:20:19.703 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", dd="3")
15:20:20.078 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", dd="33")
15:20:20.718 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", dd="333")
15:20:21.421 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", dd="3333")
15:20:21.421 CCM|Digit analysis: analysis results

在以下跟踪,数字分析完成,呼叫和被叫方匹配,并且信息解析。

|CallingPartyNumber=1001
|DialingPattern=3333
|DialingRoutePatternRegularExpression=(3333)
|PretransformDigitString=3333
|PretransformPositionalMatchList=3333
|CollectedDigits=3333
|PositionalMatchList=3333

在以下跟踪,第0指示产生的位置,并且第1指示目标位置。产生的位置的带宽取决于BW = 1。值1暗示带宽无限的。因为呼叫于查找的Cisco IP电话被发起了于LAN环境,带宽无限的。目标位置的带宽取决于BW = 64。呼叫目的地是到在PSTN查找的电话,并且使用编解码器类型是G.711 (64Kbps)。

15:20:21.421 CCM|Locations:Orig=0 BW=-1 Dest=1 BW=64 (-1 implies infinite bw available)

以下跟踪显示呼叫和被叫方信息。在本例中,主叫方名称和编号是相同的,因为管理员未配置显示名称,例如“John Smith”。

15:20:21.421 CCM|StationD - stationOutputCallInfo CallingPartyName=1001, CallingParty=1001, 
CalledPartyName=, 
CalledParty=3333, tcpHandle=0x5138d98

在查看以下跟踪前,知道期限H.323的含义是重要的。通过简要说明,有使用,当建立H.323会话时的几份协议。一份协议是H.225,主要使用呼叫信令并且是Q.931的一子集。另一份协议是H.245,使用功能交换。其中一个H.245的更加重要的功能是压缩机/减压器(编码)类型协商,例如G.711, G.729,等等,在呼叫和被呼叫端之间。一旦功能交换完成, H.245的下个重要功能执行在呼叫和被呼叫端之间的一次UDP端口协商。

以下trace表示H.323代码初始化了和发送H.225设置信息。您能也看到传统HDLC SAPI消息、被呼叫端的IP地址在十六进制的和端口号。

15:20:21.421 CCM|Out Message -- H225SetupMsg -- Protocol= H225Protocol
15:20:21.421 CCM|MMan_Id= 1. (iep= 0 dsl= 0 sapi= 0 ces= 0 IpAddr=e24610ac IpPort=47110)

以下trace显示呼叫和被叫方信息,以及H.225警报消息。并且显示思科IP电话的十六进制值的映射对IP地址。172.16.70.231是Cisco IP电话(1001)的IP地址。

15:20:21.437 CCM|StationD - stationOutputCallInfo CallingPartyName=1001, CallingParty=1001, 
CalledPartyName=, 
CalledParty=3333, tcpHandle=0x5138d98
15:20:21.453 CCM|In Message -- H225AlertMsg -- Protocol= H225Protocol
15:20:21.953 CCM|StationD - stationOutputOpenReceiveChannel tcpHandle=0x5138d98 myIP: 
e74610ac (172.16.70.231)

以下trace显示用于此呼叫的压缩类型(G.711 ï ¿  ½ -法律)。

15:20:21.953 CCM|StationD - ConferenceID: 0 msecPacketSize: 20 compressionType:
(4)Media_Payload_G711Ulaw64k

一旦H.225警报消息传送了, H.323下一部分是初始化:H.245。以下trace表示呼叫和被叫方信息和H.245消息。注意TCP把柄值是相同的象前面,指示此同一呼叫的继续。

15:20:22.062 CCM|H245Interface(3) paths established ip = e74610ac, port = 23752
15:20:22.062 CCM|H245Interface(3) OLC outgoing confirm ip = e24610ac, port = 16758
15:20:22.062 CCM|MediaManager - wait_AuConnectInfo - received response, forwarding

以下trace显示CONNECT信息的H.225,以及解释前的其他信息。当CONNECT信息的H.225接收时,呼叫连接。

15:20:22.968 CCM|In Message -- H225ConnectMsg -- Protocol= H225Protocol
15:20:22.968 CCM|StationD - stationOutputCallInfo CallingPartyName=1001, CallingParty=1001, 
CalledPartyName=, CalledParty=3333, tcpHandle=0x5138d98
15:20:22.062 CCM|MediaCoordinator - wait_AuConnectInfoInd
15:20:22.062 CCM|StationD - stationOutputStartMediaTransmission tcpHandle=0x5138d98 
myIP: e74610ac 
(172.16.70.231)
15:20:22.062 CCM|StationD - RemoteIpAddr: e24610ac (172.16.70.226) RemoteRtpPortNumber: 
16758 msecPacketSize: 20 
compressionType:(4)Media_Payload_G711Ulaw64k
15:20:22.062 CCM|Locations:Orig=0 BW=-1Dest=1 BW=6(-1 implies infinite bw available)

下列信息显示从Cisco IP电话(1001)的一个挂机消息接收。当一个挂机消息接收, H.225和skinny断开信息传送,并且整个H.225消息被看到。此最终消息指示呼叫终止。

15:20:27.296 CCM|StationInit - InboundStim ? OnHookMessageID tcpHandle=0x5138d98
15:20:27.296 CCM|ConnectionManager -wait_AuDisconnectRequest (16777247,16777248): STOP SESSION
15:20:27.296 CCM|MediaManager - wait_AuDisconnectRequest - StopSession sending 
disconnect to (64,5) and remove 
connection from list
15:20:27.296 CCM| Device SEP003094C26105 , UnRegisters with SDL Link to monitor NodeID= 1
15:20:27.296 CCM|StationD - stationOutputCloseReceiveChannel tcpHandle=0x5138d98 myIP:
 e74610ac (172.16.70.231)
15:20:27.296 CCM|StationD - stationOutputStopMediaTransmission tcpHandle=0x5138d98 myIP: 
e74610ac (172.16.70.231)
15:20:28.328 CCM|In Message -- H225ReleaseCompleteMsg -- Protocol= H225Protocol

Cisco IOS 网守上的 Debug消息及 show 命令

在前面部分, Cisco CallManager SDI trace详细讨论。在此案例研究的拓扑里, debug ras在Cisco IOS网守打开。

以下调试消息显示Cisco IOS网守接收Cisco CallManager的(172.16.70.228) Admission Request (ARQ),跟随由其他成功的RAS消息。最后, Cisco IOS网守传送准入已确认(ACF)信息到Cisco CallManager。

*Mar 12 04:03:57.181: RASLibRASRecvData ARQ (seq# 3365) rcvd from [172.16.70.228883] 
on sock [0x60AF038C]
*Mar 12 04:03:57.181: RASLibRAS_WK_TInit ipsock [0x60A7A68C] setup successful
*Mar 12 04:03:57.181: RASlibras_sendto msg length 16 from 172.16.70.2251719 to 172.16.70.228883
*Mar 12 04:03:57.181: RASLibRASSendACF ACF (seq# 3365) sent to 172.16.70.228

以下调试消息显示呼叫进展中。

*Mar 12 04:03:57.181: RASLibRASRecvData successfully rcvd message of length 
55 from 172.16.70.228883

以下调试消息显示Cisco IOS网守接收一被脱离的请求(DRQ)从Cisco CallManager (172.16.70.228),并且Cisco IOS网守发送被确认的服务器(DCF)到Cisco CallManager。

*Mar 12 04:03:57.181: RASLibRASRecvData DRQ (seq# 3366) rcvd from [172.16.70.228883] 
on sock [0x60AF038C]
*Mar 12 04:03:57.181: RASlibras_sendto msg length 3 from 172.16.70.2251719 to 172.16.70.228883
*Mar 12 04:03:57.181: RASLibRASSendDCF DCF (seq# 3366) sent to 172.16.70.228
*Mar 12 04:03:57.181: RASLibRASRecvData successfully rcvd message of length 124 
from 172.16.70.228883

在Cisco IOS网守的show gatekeeper endpoints命令显示全部四Cisco CallManager注册与Cisco IOS网守。在此案例研究的拓扑里切记那,那里是四思科CallManager,两在每集群。此Cisco IOS网守有两个区域,并且每个区域有两思科CallManager。

R2514-1#show gatekeeper endpoints
GATEKEEPER ENDPOINT REGISTRATION
===================================
CallSignalAddr Port RASSignalAddr Port Zone Name Type
--------------- ----- --------------- ----- --------- ---- --
172.16.70.228 2 172.16.70.228 1493 gka.cisco.com VOIP-GW
H323-ID: ac1046e4->ac1046f5
172.16.70.229 2 172.16.70.229 3923 gka.cisco.com VOIP-GW
H323-ID: ac1046e5->ac1046f5
172.16.70.245 1 172.16.70.245 1041 gkb.cisco.com VOIP-GW
H323-ID: ac1046f5->ac1046e4
172.16.70.243 1 172.16.70.243 2043 gkb.cisco.com VOIP-GW
H323-ID: ac1046f5->ac1046e4
Total number of active registrations = 4

Cisco IOS 网关上的 Debug消息及 show 命令

在前面部分, Cisco IOS网守显示命令,并且debug输出详细讨论。此部分着重debug输出并且显示on命令Cisco IOS网关。在此案例研究的拓扑里,呼叫通过Cisco IOS网关。Cisco IOS网关协调对PSTN或PBX与T1/CAS或T1/PRI接口。命令Debug输出例如debug voip ccapi inoutdebug h225 eventsdebug h225 asn1如下所示。

在以下debug输出中, Cisco IOS网关接受从Cisco CallManager (172.16.70.228)的TCP连接请求在H.225的端口2328。

*Mar 12 04:03:57.169: H225Lib::h225TAccept: TCP connection accepted from 
172.16.70.228:2328 on socket [1]
*Mar 12 04:03:57.169: H225Lib::h225TAccept: Q.931 Call State is initialized to be [Null].
*Mar 12 04:03:57.177: Hex representation of the received TPKT03000065080000100

debug输出以下表示H.225数据来自在此TCP会话的Cisco CallManager。在此debug输出中注意议标识符是重要的,指示使用的H.323版本。以下调试显示使用H.323版本2。呼叫和呼叫方号码也显示。

- Source Address H323-ID
- Destination Address e164
*Mar 12 04:03:57.177: H225Lib::h225RecvData: Q.931 SETUP received from socket 
[1]value H323-UserInformation ::=
*Mar 12 04:03:57.181: {
*Mar 12 04:03:57.181: h323-uu-pdu
*Mar 12 04:03:57.181: {
*Mar 12 04:03:57.181: h323-message-body setup :
*Mar 12 04:03:57.181: {
*Mar 12 04:03:57.181: protocolIdentifier { 0 0 8 2250 0 2 },
*Mar 12 04:03:57.181: sourceAddress
*Mar 12 04:03:57.181: {
*Mar 12 04:03:57.181: h323-ID : "1001"
*Mar 12 04:03:57.181: },
*Mar 12 04:03:57.185: destinationAddress
*Mar 12 04:03:57.185: {
*Mar 12 04:03:57.185: e164 : "3333"
*Mar 12 04:03:57.185: },
*Mar 12 04:03:57.189: H225Lib::h225RecvData: State changed to [Call Present].

下列是呼叫控制应用编程接口(CCAPI)的debug输出。Ccapi指示一呼入呼叫。被呼叫的和主叫用户名详细资料信息在以下输出中能也被看到。Ccapi匹配拨号对端0,是默认拨号对端。它匹配拨号对端0,因为Ccapi找不到呼叫号码的其他拨号对端,因此使用默认拨号对端。

*Mar 12 04:03:57.189: cc_api_call_setup_ind (vdbPtr=0x616C9F54, callInfo={called=3333, 
calling=1001, fdest=1 
peer_tag=0}, callID=0x616C4838)
*Mar 12 04:03:57.193: cc_process_call_setup_ind (event=0x617A2B18) handed call to app "SESSION"
*Mar 12 04:03:57.193: sess_appl: ev(19=CC_EV_CALL_SETUP_IND), cid(17), disp(0)
*Mar 12 04:03:57.193: ccCallSetContext (callID=0x11, context=0x61782BBC)
Mar 12 04:03:57.193: ssaCallSetupInd finalDest cllng(1001), clled(3333)
*Mar 12 04:03:57.193: ssaSetupPeer cid(17) peer list: tag(1)
*Mar 12 04:03:57.193: ssaSetupPeer cid(17), destPat(3333), matched(4), prefix(), peer(6179E63C)
*Mar 12 04:03:57.193: ccCallSetupRequest (peer=0x6179E63C, dest=, params=0x61782BD0 mode=0, 
*callID=0x617A87C0)
*Mar 12 04:03:57.193: callingNumber=1001, calledNumber=3333, redirectNumber=
*Mar 12 04:03:57.193: accountNumber=,finalDestFlag=1, 
guid=0098.89c8.9233.511d.0300.cddd.ac10.46e6

Ccapi匹配有目的地模式的dial-peer 1,是被叫号码3333。切记peer_tag含义拨号对端。注意在请求包的呼叫和被叫号码。

*Mar 12 04:03:57.193: peer_tag=1
*Mar 12 04:03:57.197: ccIFCallSetupRequest: (vdbPtr=0x617BE064, dest=, 
callParams={called=3333, calling=1001, 
fdest=1, voice_peer_tag=1}, mode=0x0)

debug输出以下表示H.225警报消息返回到Cisco CallManager。

*Mar 12 04:03:57.197: ccCallSetContext (callID=0x12, context=0x61466B30)
*Mar 12 04:03:57.197: ccCallProceeding (callID=0x11, prog_ind=0x0)
*Mar 12 04:03:57.197: cc_api_call_proceeding(vdbPtr=0x617BE064, callID=0x12, prog_ind=0x0)
*Mar 12 04:03:57.197: cc_api_call_alert(vdbPtr=0x617BE064, callID=0x12,
 prog_ind=0x8, sig_ind=0x1)
*Mar 12 04:03:57.201: sess_appl: ev(17=CC_EV_CALL_PROCEEDING), cid(18), disp(0)
*Mar 12 04:03:57.201: ssa: cid(18)st(1)oldst(0)cfid(-1)csize(0)in(0)fDest(0)
-cid2(17)st2(1)oldst2(0)
*Mar 12 04:03:57.201: ssaIgnore cid(18), st(1),oldst(1), ev(17)
*Mar 12 04:03:57.201: sess_appl: ev(7=CC_EV_CALL_ALERT), cid(18), disp(0)
*Mar 12 04:03:57.201: ssa: cid(18)st(1)oldst(1)cfid(-1)csize(0)in(0)fDest(0
)-cid2(17)st2(1)oldst2(0)
*Mar 12 04:03:57.201: ssaFlushPeerTagQueue cid(17) peer list: (empty)
*Mar 12 04:03:57.201: ccCallAlert (callID=0x11, prog_ind=0x8, sig_ind=0x1)
*Mar 12 04:03:57.201: ccConferenceCreate (confID=0x617A8808, callID1=0x11, callID2=0x12, tag=0x0)
*Mar 12 04:03:57.201: cc_api_bridge_done (confID=0x7, srcIF=0x616C9F54, srcCallID=0x11, 
dstCallID=0x12, 
disposition=0, tag=0x0)value H323-UserInformation
*Mar 12 04:03:57.201: {
*Mar 12 04:03:57.201: h323-uu-pdu
*Mar 12 04:03:57.201: {
*Mar 12 04:03:57.201: h323-message-body alerting :
*Mar 12 04:03:57.201: {
*Mar 12 04:03:57.201: protocolIdentifier { 0 0 8 2250 0 2 },
*Mar 12 04:03:57.205: destinationInfo
*Mar 12 04:03:57.205: {
*Mar 12 04:03:57.205: mc FALSE,
*Mar 12 04:03:57.205: undefinedNode FALSE
*Mar 12 04:03:57.205: },

在此数据包的公告Cisco IOS也发送H.245地址和端口号对Cisco CallManager。有时Cisco IOS网关将发送不可得到的地址,不可能导致音频或单向音频。

*Mar 12 04:03:57.205: h245Address ipAddress :
*Mar 12 04:03:57.205: {
*Mar 12 04:03:57.205: ip 'AC1046E2'H,
*Mar 12 04:03:57.205: port 011008
*Mar 12 04:03:57.205: },
*Mar 12 04:03:57.213: Hex representation of the ALERTING TPKT to send.0300003D0100
*Mar 12 04:03:57.213:
*Mar 12 04:03:57.213: H225Lib::h225AlertRequest: Q.931 ALERTING sent from socket [1]. 
Call state changed to [Call 
Received].
*Mar 12 04:03:57.213: cc_api_bridge_done (confID=0x7, srcIF=0x617BE064, srcCallID=0x12,
 dstCallID=0x11, 
disposition=0, tag=0x0)

debug输出以下表示H.245会话出来。您能为编解码器协商看到功能征兆,以及多少个字节将是存在每语音数据包。

*Mar 12 04:03:57.217: cc_api_caps_ind (dstVdbPtr=0x616C9F54, dstCallId=0x11, srcCallId=0x12,
 caps={codec=0xEBFB, 
fax_rate=0x7F, vad=0x3, modem=0x617C5720 codec_bytes=0, signal_type=3})
*Mar 12 04:03:57.217: sess_appl: ev(23=CC_EV_CONF_CREATE_DONE), cid(17), disp(0)
*Mar 12 04:03:57.217: ssa: cid(17)st(3)oldst(0)cfid(7)csize(0)in(1)fDest(1)
-cid2(18)st2(3)oldst2(1)
*Mar 12 04:03:57.653: cc_api_caps_ind (dstVdbPtr=0x617BE064, dstCallId=0x12,
 srcCallId=0x11, caps={codec=0x1, 
fax_rate=0x2, vad=0x2, modem=0x1, codec_bytes=160, signal_type=0})

debug输出以下表示两个当事人正确地协商并且同意关于G.711编码160字节的数据。

*Mar 12 04:03:57.653: cc_api_caps_ack (dstVdbPtr=0x617BE064, dstCallId=0x12, 
srcCallId=0x11, caps={codec=0x1, 
fax_rate=0x2, vad=0x2, modem=0x1, codec_bytes=160, signal_type=0})
*Mar 12 04:03:57.653: cc_api_caps_ind (dstVdbPtr=0x617BE064, dstCallId=0x12,
 srcCallId=0x11, caps={codec=0x1, 
fax_rate=0x2, vad=0x2, modem=0x, codec_bytes=160, signal_type=0})
*Mar 12 04:03:57.653: cc_api_caps_ack (dstVdbPtr=0x617BE064, dstCallId=0x12,
 srcCallId=0x11, caps={codec=0x1, 
fax_rate=0x2, vad=0x2, modem=0x1, codec_bytes=160, signal_type=0})
*Mar 12 04:03:57.657: cc_api_caps_ack (dstVdbPtr=0x616C9F54, dstCallId=0x11,
 srcCallId=0x12, caps={codec=0x1, 
fax_rate=0x2, vad=0x2, modem=0x1, codec_bytes=160, signal_type=0})
*Mar 12 04:03:57.657: cc_api_caps_ack (dstVdbPtr=0x616C9F54, dstCallId=0x11,
 srcCallId=0x12, caps={codec=0x1, 
fax_rate=0x2, vad=0x2, modem=0x1, codec_bytes=160, signal_type=0})

H.323连接,并且断开消息能下面被看到。

*Mar 12 04:03:59.373: cc_api_call_connected(vdbPtr=0x617BE064, callID=0x12)
*Mar 12 04:03:59.373: sess_appl: ev(8=CC_EV_CALL_CONNECTED), cid(18), disp(0)
*Mar 12 04:03:59.373: ssa: cid(18)st(4)oldst(1)cfid(7)csize(0)in(0)fDest(0)
-cid2(17)st2(4)oldst2(3)
*Mar 12 04:03:59.373: ccCallConnect (callID=0x11)
*Mar 12 04:03:59.373: {
*Mar 12 04:03:59.373: h323-uu-pdu
*Mar 12 04:03:59.373: {
*Mar 12 04:03:59.373: h323-message-body connect :
*Mar 12 04:03:59.373: {
*Mar 12 04:03:59.373: protocolIdentifier { 0 0 8 2250 0 2 },
*Mar 12 04:03:59.373: h245Address ipAddress :
*Mar 12 04:03:59.373: {
*Mar 12 04:03:59.377: ip 'AC1046E2'H,
*Mar 12 04:03:59.377: port 011008
*Mar 12 04:03:59.377: },
*Mar 12 04:03:59.389: Hex representation of the CONNECT TPKT to send.03000052080
*Mar 12 04:03:59.393: H225Lib::h225SetupResponse: Q.931 CONNECT sent from socket [1]
*Mar 12 04:03:59.393: H225Lib::h225SetupResponse: Q.931 Call State changed to [Active].
*Mar 12 04:04:08.769: cc_api_call_disconnected(vdbPtr=0x617BE064, callID=0x12, cause=0x10)
*Mar 12 04:04:08.769: sess_appl: ev(12=CC_EV_CALL_DISCONNECTED), cid(18), disp(0)

带有 T1/PRI 接口的 Cisco IOS 网关

如前所述,有通过Cisco IOS网关的呼叫的两种类型:Cisco IOS网关协调对PSTN或PBX,与T1/CAS或T1/PRI接口。当Cisco IOS网关使用T1/PRI接口时,下列是debug输出。

debug isdn q931命令在Cisco IOS网关打开。这启用Q.931, D-channel的一个层三信令协议在ISDN环境。每次呼叫发出在T1/PRI接口外面,必须发送设置数据包。设置数据包总是有(协议描述符) pd = 8,并且创造callref的一随机的十六进制值。callref用于跟踪呼叫。例如,如果发出两呼叫, callref值能确定RX的呼叫(已接收)消息打算。载体功能0x8890含义一次64kb/s数据呼叫。如果它是0x8890218F,它是56kb/s数据呼叫。如果它是语音呼叫,它是0x8090A3。在下面的debug输出中,载体功能是0x8090A3,是为语音。呼叫和呼叫方号码也显示。

callref使用一个不同的值第一个数字(区分在TX和RX之间),并且第二个值是相同的(设置有一0最后一数字的,并且CONNECT_ACK也有一0)。路由器是完全依赖于PSTN或PBX分配承载信道(B信道)。如果PSTN或PBX不分配信道到路由器,呼叫不会路由。在我们的情况中, CONNECT信息从交换机接收用参考编号和一样为警告接收(0x800B)。最后,当呼叫被断开,您能看到版本和RELEASE_COMP消息跟随的断开消息的交换。RELEASE_COMP消息由呼叫拒绝的原因ID跟随。原因ID是十六进制值。原因的含义可以通过解码十六进制值和进一步进行您的供应商找到。

*Mar 1 225209.694 ISDN Se115 TX -> SETUP pd = 8 callref = 0x000B
*Mar 1 225209.694 Bearer Capability i = 0x8090A3
*Mar 1 225209.694 Channel ID i = 0xA98381
*Mar 1 225209.694 Calling Party Number i = 0x2183, ?1001'
*Mar 1 225209.694 Called Party Number i = 0x80, ?3333'
*Mar 1 225209.982 ISDN Se115 RX <- ALERTING pd = 8 callref = 0x800B
*Mar 1 225209.982 Channel ID i = 0xA98381
*Mar 1 225210.674 ISDN Se115 RX <- CONNECT pd = 8 callref = 0x800B
*Mar 1 225210.678 ISDN Se115 TX -> CONNECT_ACK pd = 8 callref = 0x000B
*Mar 1 225215.058 ISDN Se115 RX <- DISCONNECT pd = 8 callref = 0x800B
*Mar 1 225215.058 Cause i = 0x8090 - Normal call clearing 225217 %ISDN-6
DISCONNECT Int S10 disconnected from unknown , call lasted 4 sec
*Mar 1 225215.058 ISDN Se115 TX -> RELEASE pd = 8 callref = 0x000B
*Mar 1 225215.082 ISDN Se115 RX <- RELEASE_COMP pd = 8 callref = 0x800B
*Mar 1 225215.082 Cause i = 0x829F - Normal, unspecified or Special intercept,
 call blocked group restriction 

带有 T1/CAS 接口的 Cisco IOS 网关

如前所述,有通过Cisco IOS网关的呼叫的两种类型:对PSTN或PBX的Cisco IOS网关接口,与T1/CAS或T1/PRI接口。当Cisco IOS网关有T1/CAS接口时,下列是debug输出。在Cisco IOS网关的debug cas打开。

以下调试消息显示Cisco IOS网关发送挂机信号到交换机。

Apr 5 17:58:21.727: from NEAT(0): (0/15): Tx LOOP_CLOSURE (ABCD=1111) 

以下调试消息指示交换机在接收从Cisco IOS网关的封闭环路信号以后发送闪烁。

Apr 5 17:58:21.859: from NEAT(0): (0/15): Rx LOOP_CLOSURE (ABCD=1111)
Apr 5 17:58:22.083: from NEAT(0): (0/15): Rx LOOP_OPEN (ABCD=0000)

以下调试消息指示Cisco IOS网关去摘机。

Apr 5 17:58:23.499: from NEAT(0): (0/15): Rx LOOP_CLOSURE (ABCD=1111)

当呼叫进展中时,下列是show call active voice brief的输出在Cisco IOS网关的。呼叫和呼叫方号码和其他有用的信息也显示。

R5300-5#show call active voice brief
<ID>: <start>hs.<index> +<connect> pid: <peer_id> <dir> <addr> <state> tx: <packets>/<bytes>
 rx:<packets>/<bytes>
<state>
IP <ip>:<udp> rtt:<time>ms pl:<play>/<gap>ms lost:<lost>/<early>/<late> 
delay:<last>/<min>/<max>ms <codec>
FR <protocol> [int dlci cid] vad:<y/n> dtmf:<y/n> seq:<y/n> sig:<on/off> <codec> (payload size)
Tele <int>: tx:<tot>/<v>/<fax>ms <codec> (payload size) 
Tele <int>: tx:<tot>/<v>/<fax>ms <codec> noise:<l> acom:<l> i/o:<l>/<l> dBm
511D : 156043737hs.1 +645 pid:0 Answer 1001 active
tx:1752/280320 rx:988/158080
IP172.16.70.228:18888 rtt:0ms pl:15750/80ms lost:0/0/0 delay:25/25/65ms g711ulaw
511D : 156043738hs.1 +644 pid:1 Originate 3333 active
tx:988/136972 rx:1759/302548 
Tele 1/0/0 (30): tx:39090/35195/0ms g711ulaw noise:-43 acom:0 i/0:-36/-42 dBm

在拨打国际号码后收到占线信号

问题

用户有与适当的路由模式的CM 2.4.4分配到他的DT-24+网关。他能拨号本地和美国长途号码没有问题。然而,当他猛击国际号码的时位,他听到暂停然后占线信号。

解决方案

这以前被看到了CO交换机不会适当地涉及呼叫IE的地方(信息元素)。这可以通过设置CallManager主叫方IE类型修复“集呼叫和对未知的呼叫的类型DN”在DT24+间距参数下。

案例研究III :集群间Cisco IP电话到Cisco IP电话呼叫

在上一个案例研究,集群内呼叫和Cisco IP电话呼叫的呼叫流和故障排除技术通过Cisco IOS网关对暂停本地PBX的电话或某处在PSTN详细讨论。此案例研究在不同的集群检查呼叫另一Cisco IP电话的Cisco IP电话查找。亦称此种呼叫是一集群间Cisco IP电话呼叫。

拓扑示例

下列是在这种情况下使用的拓扑示例学习。此拓扑有两集群,有中的每一两思科CallManager。也有到位Cisco IOS网关和Cisco IOS网守。

/image/gif/paws/30266/ios_gatekeeper3.gif

集群之间的 H.323 通信

正如你在拓扑看到,在集群1的Cisco IP电话进行对Cisco IP电话的一呼叫在集群集群间Cisco CallManager通信发生使用H.323协议第2版的2。也有准入控制的一个Cisco IOS网守。debug输出的详细说明和显示命令,并且Cisco IOS网守之间的交互作用和Cisco IOS网关和Cisco CallManager设备,在前面部分可以查看。

呼叫流流程进程在下图所示中显示。Cisco IP电话能与Cisco CallManager谈通过小型站协议,并且Cisco CallManager能与使用H.323 RAS协议的Cisco IOS网守谈。Admission Request信息(ARQ)发送给Cisco IOS网守,传送准入已确认信息(ACF)使用H.323协议第2版,在确保以后中间聚集呼叫可以被做。一旦完成,音频路径做使用在思科IP电话之间的RTP协议在不同的集群。

/image/gif/paws/30266/gatekeeper_flow.gif

呼叫流跟踪

此部分在CCM000000000文件讨论呼叫流使用SDI跟踪示例捕获。此文件的位置可以在前面部分找到。在这种情况下讨论的学习仅重点跟踪在呼叫流,因为更加详细的跟踪信息在上一个案例研究(初始化、注册,保活机制已经解释,等等。)

在此呼叫流,在团星(2002)查找的Cisco IP电话2在团星1.呼叫Cisco IP电话(1001)查找记住您能通过trace跟随设备通过查看设备的TCP把柄值、时间戳或者名称。设备的TCP把柄值依然是同样,直到设备重新启动或脱机。

在以下跟踪, Cisco IP电话(2002)是摘机。trace显示唯一消息、TCP把柄和呼叫号码,在Cisco IP电话显示。被叫号码(1001), H.225连接,并且H.245确认消息在以下debug输出中能被看到。编解码器类型是G.711 ï ¿  ½ -法律。

16:06:13.921 CCM|StationInit - InboundStim - OffHookMessageID tcpHandle=0x1c64310
16:06:13.953 CCM|Out Message -- H225ConnectMsg -- Protocol= H225Protocol
16:06:13.953 CCM|Ie - H225UserUserIe IEData= 7E 00 37 05 02 C0 06
16:06:13.953 CCM|StationD - stationOutputCallInfo CallingPartyName=, CallingParty=2002, 
CalledPartyName=1001, CalledParty=1001, tcpHandle=0x1c64310
16:06:14.015 CCM|H245Interface(2) OLC indication chan number = 2
16:06:14.015 CCM|StationD - stationOutputOpenReceiveChannel tcpHandle=0x1c64310 
myIP: e74610ac (172.16.70.231)
16:06:14.015 CCM|StationD - ConferenceID: 0 msecPacketSize: 20 compressionType:
(4)Media_Payload_G711Ulaw64k
16:06:14.062 CCM|StationInit - InboundStim - StationOpenReceiveChannelAckID tcpHandle=0x1c64310,
 Status=0, 
IpAddr=0xe74610ac, Port=20444, PartyID=2
16:06:14.062 CCM|H245Interface(2) paths established ip = e74610ac, port = 20444
16:06:14.187 CCM|H245Interface(2) OLC outgoing confirm ip = fc4610ac, port = 29626

呼叫和被叫号码,关联与IP地址和十六进制值,在以下跟踪能被看到。

16:06:14.187 CCM|StationD - stationOutputStartMediaTransmission tcpHandle=0x1c64310
 myIP: e74610ac 
(172.16.70.231)
16:06:14.187 CCM|StationD - RemoteIpAddr: fc4610ac (172.16.70.252) 

以下跟踪显示数据包大小和Cisco IP电话的MAC地址(2002)。这些跟踪由断开跟随,然后挂机消息。

RemoteRtpPortNumber: 29626 msecPacketSize: 20 compressionType:(4)Media_Payload_G711Ulaw64k
16:06:16.515 CCM| Device SEP003094C26105 , UnRegisters with SDL Link to monitor NodeID= 1
16:06:16.515 CCM|StationD - stationOutputCloseReceiveChannel tcpHandle=0x1c64310 
myIP: e74610ac (172.16.70.231)
16:06:16.515 CCM|StationD - stationOutputStopMediaTransmission tcpHandle=0x1c64310 
myIP: e74610ac (172.16.70.231)
16:06:16.531 CCM|In Message -- H225ReleaseCompleteMsg -- Protocol= H225Protocol
16:06:16.531 CCM|Ie - Q931CauseIe -- IEData= 08 02 80 90
16:06:16.531 CCM|Ie - H225UserUserIe -- IEData= 7E 00 1D 05 05 80 06
16:06:16.531 CCM|Locations:Orig=1 BW=64 Dest=0 BW=-1 (-1 implies infinite bw available)
16:06:16.531 CCM|MediaManager - wait_AuDisconnectRequest - StopSession sending disconnect to 
(64,2) and remove 
connection from list
16:06:16.531 CCM|MediaManager - wait_AuDisconnectReply - received all disconnect replies, 
forwarding a reply for party1(16777219) and party2(16777220)
16:06:16.531 CCM|MediaCoordinator - wait_AuDisconnectReply - removing MediaManager(2)
 from connection list
16:06:16.734 CCM|StationInit - InboundStim - OnHookMessageID tcpHandle=0x1c64310

失败的呼叫流

以下部分描述一个不成功中间聚集呼叫流,如在SDI trace中看到。在下面跟踪, Cisco IP电话(1001)是摘机。TCP把柄分配到Cisco IP电话。

16:05:33.468 CCM|StationInit - InboundStim - OffHookMessageID tcpHandle=0x4fbbc30
16:05:33.468 CCM|StationD - stationOutputDisplayText tcpHandle=0x4fbbc30, Display= 1001
16:05:33.484 CCM|StationD - stationOutputSetLamp stim: 9=Line instance=1 
lampMode=LampOn tcpHandle=0x4fbbc30

在以下跟踪用户拨号被叫号码(2000) Cisco IP电话,并且数字分析进程尝试匹配编号。

16:05:33.484 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", dd="")
16:05:33.484 CCM|Digit analysis: potentialMatches=PotentialMatchesExist
16:05:35.921 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", dd="2")
16:05:35.921 CCM|Digit analysis:potentialMatches=ExclusivelyOffnetPotentialMatchesExist
16:05:36.437 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", dd="20")
16:05:36.437 CCM|Digit analysis:potentialMatches=ExclusivelyOffnetPotentialMatchesExist
16:05:36.656 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", dd="200")
16:05:36.656 CCM|Digit analysis:potentialMatches=ExclusivelyOffnetPotentialMatchesExist
16:05:36.812 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", dd="2000")

数字分析当前完成,并且结果在以下跟踪显示。请注意下面PotentialMatches=NoPotentialMatchesExist的参考表明Cisco CallManager无法匹配此目录号。最后,交换机忙音被发送对主叫方(1001),由一个挂机消息跟随。

16:05:36.812 CCM|Digit analysis: analysis results
16:05:36.812 CCM||PretransformCallingPartyNumber=1001
|CallingPartyNumber=1001
|DialingPattern=2XXX
|DialingRoutePatternRegularExpression=(2XXX)
|PotentialMatches=NoPotentialMatchesExist
|CollectedDigits=2000
16:05:36.828 CCM|StationD - stationOutputCallInfo CallingPartyName=1001, 
CallingParty=1001, CalledPartyName=, 
CalledParty=2000, tcpHandle=0x4fbbc30
16:05:36.828 CCM|StationD - stationOutputStartTone: 37=ReorderTone tcpHandle=0x4fbbc30
16:05:37.953 CCM|StationInit - InboundStim - OnHookMessageID tcpHandle=0x4fbbc30

呼叫详细记录

此部分提供关于呼叫详细记录(CDR)和呼叫管理记录(亦称CMRs,诊断CDR)的详细信息。

CDR记录写入对一个数据库用于后加工活动。这些活动包括许多功能,但是主要发单和网络分析。

数据库是Microsoft SQL Server 7.0数据库。对数据库的访问可以通过开放数据库连接(ODBC)做。

访问在一个读/写方式提供给在数据库的所有表在一个只读方式和给CDR和CMR表。

要使用CDR记录数据,您可以要读在数据库的其他表得到关于CDR的设备类型的信息。设备在设备表里和在CDR记录列出的IP地址之间的此相关性不是直接的和列出作为已知问题后在此部分。

写记录

Cisco CallManager写CDR记录对SQL数据库和呼叫使有些一致与每单个Cisco CallManager的配置。此配置通过Service Parameters屏幕在Cisco CallManager管理中被做。

所有记录写入对集群的主数据库。如果主数据库不是可用的,记录将写入对任何其他备份数据库。一旦主数据库变得可用,然后文字新记录在主数据库将继续,并且本地写入记录将移动向主要的。

读记录

读从SQL数据库的数据的简便的方法可能是使用ODBC。连接状态良好字符串将看起来象:

DRIVER= {SQL Server};SERVER=machineX;DATABASE=CCM0300

请务必使用正确数据库名称。如果软件的Cisco CallManager版本3.0(1)版本在现有安装安装,数据库也许被移植,如果呼叫为由新的安装。在这种情况下旧有数据库将存在,并且新的数据库也将存在。名称将通过加一有所不同到名称的编号。例如,原始名称是CCM0300。在迁移以后,更新的数据库名称将是CCM0301。应该使用较高的值数据库。

主数据库(计算机和名称)正在使用中由集群可以通过单击找到在Cisco CallManager管理详细信息按钮(请点击帮助到达详细信息按钮查找)的欢迎屏幕。在主机数据库的机器的注册可能也被检查。查看注册表项:\ \ HKEY_LOCAL_MACHINE \软件\ Cisco系统公司\ DBL项目的呼叫DBConnection0。此字符串项目包含连接字符串类似于以主数据库的机器名字和数据库名称表示的如上那。

访问利用SQL用户被控制。下表指定应该使用,当访问Cisco CallManager数据库时的用户名和密码。

SQL UserID 密码 功能
通话细节记录, CallDetailRecordDiagnostic CiscoCCMCDR dipsy 读取/写入
(其他) CiscoCCMReader 牛仔 只读

删除记录

因为Cisco CallManager在第三方应用程序取决于后加工CDR数据,您应该取消CDR数据,当所有应用程序完成与数据时。因为这介入正在修改数据库, CiscoCCMCDR用户应该使用。

如果CDR记录累计对配置的最大值(10,000,000个CDR记录),最旧的CDR记录与相关CMR记录一起将删除一次每天。

当删除CDR数据在分析以后时,请务必删除所有相关CMR记录。

表模式

关于格式和使用的详细信息CDR的每个字段是提供的以后在此部分。

使用的是有CDR记录)的主要的表通话细节记录表(和有CMR记录)的CallDetailRecordDiagnostic表(。通话细节记录表与CallDetailRecordDiagnostic表涉及通过两GlobalCallID列、GlobalCallID_callManagerId和GlobalCallID_callId。可能有超过每个CDR一个CMR。

通话细节记录表保持关于呼叫和呼叫的其他呼叫控制/路由方面的终端的信息。CallDetailRecordDiagnostic表保持关于呼叫的被放出的音频的质量的信息。

已知问题

Cisco CallManager版本3.0(1)有与CDR数据的几个已知问题。一些这些下面是列出的。

对设备名转换的IP

CDR表列出呼叫的终端的IP地址。这些IP地址没有容易地转换对设备名,以便可以确定设备类型。

OnNet与网外

知道呼叫是否在IP网络坚持完全是很难的,或者至少内部对本地系统。一个线索是检查呼叫的两端设备类型。如果两个是电话,则您能假设,它坚持OnNet。然而,如果一个是网关,必须做更多假定。如果网关是一模拟访问设备类型用POTS或站端口,呼叫也许已经去一个本地模拟电话或者也许已经出去了到PSTN。如果呼叫去网外,请查看拨号的并且编号与已知拨号计划预计关联此。否则,呼叫很可能去OnNet。

网外位拨号程序

如果发出呼叫网关,位拨号达到网关可能不是位发送对PSTN。网关可能智能和进一步修改目录号。如果这是实际情形, Cisco CallManager不知道,并且CDR不会反射实际位发送的网外。

呼叫详细记录中的字段

此部分定义了所有当前录音的字段。字段类型是Cisco CallManager不一定使用的那些和那些定义在CDR记录在数据库。数据库字段定义是足够的存储数据,但是数据的解释应该考虑到字段类型定义此处。

所有无符号整数是32bit无符号整数。

字段数据数据转换

有要求从十进制形式的转换到显示的另一个格式的一些字段。此部分在哪里定义了他们的值,和如何转换他们或获得关于如何的信息转换他们。

时间值

所有时间值表示作为未签名的32个位整数。此无符号整数值从数据库显示作为签名整数。

此字段是从Windows NT的time_t值(2000)系统惯例得到。值是世界统一时间(UTC)值并且代表秒钟数量从午夜(00:00:00) 1970年1月1日。

解密时间戳

使用Microsoft Excel,您能写入公式使转换此时间戳更加容易。如果值在信元A1,您能做另一个信元:

=A1/86400+DATE(1970,1,1)

有86400秒在一天。

然后,请格式化发生的信元作为Excel的一个日期/时间字段。

IP 地址

所有IP地址在系统存储作为无符号整数。数据库显示他们作为签名整数。要变换签字的十进制值到IP地址,首先请变换值到一个六角形的编号(考虑到它确实是无符号数字)。32bit十六进制值表示四个字节。四个字节按顺序反向顺序(英特尔标准)。要获得IP地址,请倒转字节的命令并且转换每个字节到十进制数字。发生的四个字节代表IP地址的四字节的字段在点分符号的。

注意: 当IP地址的低字节有最高有效位设置时,数据库显示它作为负数。

转换IP地址

  • 示例 1:

    例如, IP地址192.168.18.188请显示如下:

    数据库显示= -1139627840。

    这转换对十六进制值0xBC12A8C0。

    倒转六角形的字节= C0A812BC

    CO A8 12 BC

    字节从十六进制转换到十进制= 192 168 18 188,将显示作为192.168.18.188。

  • 示例 2:

    IP地址192.168.18.59

    数据库显示= 991078592

    这转换对十六进制值0x3B12A8C0

    反向字节顺序= C0A8123B

    C0 A8 12个3B

    字节从十六进制转换到十进制=将显示作为192.168.18.59的192 168 18 59。

CDR字段定义

下表为CDR提供字段定义。

字段定义
字段 定义
cdrRecordType 此记录无符号整数的类型指定此特定记录种类。它能是起始呼号record(0)、终止呼叫record(1)或者CMR record(2)。
globalCallIdentifier 全局呼叫标识符全局呼叫标识符包括是两无符号整数的两个字段。值必须把无符号整数看作。两个字段是:无符号整数GlobalCallID_callId无符号整数GlobalCallID_callManagerId这是分配到整个呼叫的呼叫标识符。所有记录关联与标准呼叫将有同一个全局呼叫标识符。
origLegcallIdentifier Origination段呼叫标识符无符号整数这是使用跟踪呼叫的起源段的唯一标识符。它在集群内是唯一。
dateTimeOrigination 日期/时间呼叫始发无符号整数这代表时间呼叫的始发设备去挂,或者时间外部呼叫由系统(首先认可接收设置信息)。值是世界统一时间(UTC)值,并且代表秒钟数量从午夜(00:00:00) 1970年1月1日。
origNodeId 创建人的节点ID无符号整数此字段代表在呼叫始发者在此呼叫时注册的Cisco CallManager集群内的节点。
origSpan 如果呼叫通过网关,产生创建人的间距或端口无符号整数此字段包含创建人的端口或间距编号。否则,此字段包含零(0)。
callingpartynumber 至25个字符的主叫方编号这是呼叫产生设备的目录号。
origIpPort 主叫方的IP端口无符号整数此字段包含呼叫产生设备的IP端口。
origIpAddr 主叫方的IP地址无符号整数此字段包含呼叫产生设备的IP地址。
originalCallingPartyNumberPartition 至50个字符的主叫方的分区此字段包含分区关联与主叫方。
origCause_location ISDN位置值无符号整数此字段包含从原因信息元素的位置值。
origCause_value 呼叫终止无符号整数的主叫方原因此原因代表对始发设备的呼叫终止的原因。一旦转移,转发,等等,呼叫终止的原因可以是不同的为始发设备和终端设备。因此,有两个原因字段关联与每呼叫。通常他们将是相同的。
origMediaTransportAddress_IP 创建人的媒介连接无符号整数的IP地址这是从创建人的媒体流连接的目的IP地址。
origMediaTransportAddress_Port 创建人的媒介连接无符号整数的端口这是从创建人的媒体流连接的目的地端口。
origMediaCap_payloadCapability 编解码器类型由此字段包含在此呼叫期间,创建人在发送端使用。的编解码器类型的创建人无符号整数使用了(压缩或有效载荷类型)它跟在其接收端使用的编解码器类型可能不同。
origMediaCap_maxFramesPerPacket 毫秒数量每个小包数据无符号整数此字段包含毫秒数量数据每个小包发送对目的地,由此呼叫创建人。实际数据大小取决于编解码器类型使用生成数据。
origMediaCap_g723BitRate G.723无符号整数将使用的比特率定义了G.723将使用的比特率。有微不足道的速率值:1 =5.3K比特率和2 = 6.3K比特率。
lastRedirectDn 持续当事人的目录号重定向此召集对25个字符这是最后设备的目录号重定向此呼叫。此字段仅适用于重定向,例如电话会议,呼叫转发呼叫的呼叫,等等。
lastRedirectDnPartition 持续电话的分区重定向此召集对50个字符这是最后设备的分区重定向此呼叫。此字段仅适用于重定向例如电话会议,呼叫转发呼叫,等等的呼叫。
destLegIdentifier 呼叫无符号整数的目的地段的呼叫标识符这是使用跟踪此呼叫的目的地段的唯一标识符。它在集群内是唯一。
destNodeId 呼叫目的地是注册的无符号整数在Cisco CallManager集群内的节点目的地设备在此呼叫时注册的节点的节点标识符
目的间距 如果呼叫通过网关,终止目的地SPAN或端口无符号整数此字段包含目的地端口或间距编号。否则,此字段包含a (0)零。
destIpAddr 呼叫是传送的无符号整数此字段的IP地址包含信令连接的IP地址在终止呼叫的设备的。
destIpPort 呼叫是传送的无符号整数此字段的IP端口包含信令连接的IP端口在终止呼叫的设备的。
originalCalledPartyNumber 目的地从呼叫始发者接收至此字段包含目录号呼叫根据位最初被扩展由呼叫的创建人拨号的25个字符。如果呼叫正常完成(含义它未转发),此目录号应该总是相同的象“finalCalledPartyNumber”。如果呼叫转发,此字段包含呼叫的原始目的地,在转发前。
originalCalledPartyNumberPartition 至50个字符的被叫方的分区此字段包含分区关联与被叫方。
finalCalledPartyNumber 呼叫传送至25个字符此字段的目的地包含呼叫实际上被扩展的目录号。如果呼叫正常完成(含义它未转发),此目录号应该总是相同的象“originalCalledPartyNumber”。如果呼叫转发,此字段包含呼叫的最终目的地的目录号,在所有转发完成后。
finalCalledpartyNumberPartition 分区关联与呼叫的最终目的地。50个字符此字段包含分区关联与呼叫实际上被扩展的目的地。在正常呼叫,此字段应该是相同的作为“originalCalledPartyNumberPartition”。如果呼叫转发,此字段包含呼叫的最终目的地的分区,在所有转发完成后。
destCause_location 被叫方原因位置无符号整数这是从原因信息元素的ISDN位置值。
destCause_value 呼叫终止无符号整数的被叫方原因此原因代表对终端设备的呼叫为什么终止。一旦转移,转发,等等,呼叫终止的原因可以是不同的为呼叫的收件人和呼叫的创建人。因此,有两个原因字段关联与每呼叫。通常他们将是相同的。当尝试做出对转发的繁忙的设备扩大呼叫,原因代码将反射" BUSY ",即使呼叫连接对一个向前目的地。
destMediaTransportAddress_IP 目的地向外的媒体连接无符号整数的IP地址这是从目的地的媒体流连接的起源IP地址。
destMediaTransportAddress_Port 目的地向外的媒体连接无符号整数的端口这是从目的地的媒体流连接的创建人的端口。
destMediaCap_payloadCapability 编解码器类型由在此字段包含在此呼叫期间,目的地在其发送端使用。的编解码器类型的发送端无符号整数的目的地使用了(压缩或有效载荷类型)它跟在其接收端使用的编解码器类型可能不同。
destMediaCap_maxFramesPerPacket 毫秒数量每个小包数据无符号整数此字段包含毫秒数量数据每个小包发送对创建人由此呼叫的目的地。实际数据大小取决于编解码器类型使用生成数据。
destMediaCap_g723BitRate G.723无符号整数将使用的比特率定义了G.723将使用的比特率。有微不足道的速率值:1 =5.3K比特率和2 = 6.3K比特率。
datetimeconnect 日期/时间连接无符号整数这是的日期和时间呼叫连接在始发和终接设备之间。值是世界统一时间(UTC)值,并且代表秒钟数量从午夜(00:00:00) 1970年1月1日。
dateTimeDisconnect 日期/时间断开无符号整数这是时间呼叫被断开了在始发和终接设备之间,或者,当呼叫被切断了时,即使未曾连接。值是世界统一时间(UTC)值,并且代表秒钟数量从午夜(00:00:00) 1970年1月1日。
持续时间 呼叫持续时间这是呼叫连接秒钟的数量。它是日期/时间之间的差异连接和日期/时间断开。

CMR字段定义

下表为CMRs (诊断CDR)提供字段定义。

字段定义
字段 定义
cdrRecordType 此记录无符号整数的类型指定此特定记录种类。它将设置为CMR记录。
globalCallIdentifier 此呼叫的全局呼叫标识符全局呼叫标识符包括是两无符号整数的两个字段。值必须把无符号整数看作。两个字段是:无符号整数GlobalCallID_callId无符号整数GlobalCallID_callManagerId这是分配到整个呼叫的呼叫标识符。所有记录关联与标准呼叫将有同一个全局呼叫标识符。
nodeid Cisco CallManager节点标识符在此记录生成的Cisco CallManager集群内的节点。
callIdentifier 呼叫标识符无符号整数这是识别到的呼叫段标识符哪个呼叫段此记录适合于。
directoryNum 在此呼叫使用的目录号这是这些诊断收集设备的目录号。
directoryNumPartition 用目录号关联的分区这是目录号的分区在此记录的。
dateTimeStamp 日期/时间呼叫终止这代表大致时间设备在挂去。当电话回答申请信息诊断信息时,时间被放到记录。这是time_t值。
numberPacketsSent 发送的数据包编号RTP数据包的总数设备传送的从开始在此连接的发射。如果连接在"receive only"模式,设置值是零。
numberOctetsSent 编号八位位组(字节)数据发送对另一个当事人在RTP数据包(即不包括报头或填充符)传送的有效载荷八位组的总数由设备从开始在此连接的发射。如果连接在"receive only"模式,设置值是零。
numberPacketsReceived RTP数据包的总数由设备接收从开始此连接的接收的此呼叫期间接收的数据包数量。如果这是组播呼叫,计数包括从不同的来源接收的数据包。如果连接在"send only"模式,设置值是零。
numberOctetsReceived 数量八位位组(字节在此呼叫期间接收的)数据在RTP数据包(即不包括报头或填充符)接收的有效载荷八位组的总数由设备从开始此连接的接收。如果这是组播呼叫,计数包括从不同的来源接收的数据包。如果连接在"send only"模式,设置值是零。
numberPacketsLost 丢失的RTP数据包在此连接时的RTP数据包总数丢失自接收之始。此编号定义作为数据包数量预计,数据包数量实际上接收,其中数据包数量接收包括晚的任何或复制。因此,晚期到达的数据包没有算作是丢失和损耗可能是负的,如果有重复项。预计的数据包数量定义是作为定义下接收的,延长的最后序号,初始序号接收。如果连接在"send only"模式,设置值是零。(关于详细信息,请参阅RFC 1889)
抖动 两次输入的抖动在此连接时,测量用毫秒和被表示为无符号整数RTP数据包到达间隔时间的统计差异的估计。两次输入的抖动J定义是平均边差(使光滑的绝对值)在数据包间距的差异D在接收方与一个对的发送方比较数据包。详细的计算算法在RFC 1889被找到。如果连接在"send only"模式,设置值是零。
延迟 延迟在值是网络延迟的估计的此连接时体验,表示以毫秒。这是区别的平均值在RTP控制协议(RTCP)消息的发送方表示的网络时间协议(NTP)时间戳和接收方的NTP时间戳的之间,被测量,当这些消息接收时。平均值通过合计所有估计,然后分开获取由的RTCP消息数量接收。(关于详细信息请参阅请求注释(RFC) 1889)

根据呼叫类型记录的呼叫记录

在双方之间的每正常呼叫记录一个CDR结束呼叫记录。每个结束呼叫记录包含识别的所有字段以上,但是不可以使用一些字段。如果没有使用字段,将是空白,如果它是ASCII字符串字段,否则"0",如果它是数字域。当附加服务在呼叫时涉及,更多结束呼叫记录可能写入。

除CDR结束呼叫记录之外,可能有每个在呼叫涉及的终端一个CMR记录。在双方之间的正常呼叫其中每一使用Cisco IP电话,将有两个CMR记录写入:一创建人的和一个呼叫的目的地的。

此部分描述为在系统的不同的呼叫类型写入的记录。

正常呼叫(Cisco IP电话到Cisco IP电话)

正常呼叫记录每呼叫三个记录。他们是结束加上两个诊断记录,一个每个终端的。在结束记录,所有字段可能包含有效信息。持续时间永远将是非零,除非“CdrLogCallsWithZeroDurationFlag”标志启用(对真的集)。" originalCalledPartyNumber "字段将包含目录号和" finalCalledPartyNumber "字段一样。

放弃的呼叫

呼叫记录日志与零的持续时间的可选。通常,这些记录不会被记录。如果记录与零的持续时间的呼叫启用,以下事应该是要注意的。

  • 如果呼叫放弃(例如,当电话是离开的挂和被放置的上一步在挂),多种字段不会包含数据。在这种情况下, “originalCalledPartyNumber”, “finalCalledPartyNumber”,分区关联与他们, “destIpAddr”,和datetimeconnect字段将是空白的。未连接的所有呼叫将有一“持续时间”零秒。当呼叫放弃时,原因代码是"0"。

  • 如果用户拨号目录号然后放弃呼叫,在连接前, “第一目的”和“最终目的”字段和他们相关的分区将包含呼叫将被扩展的目录号和分区。" Dest Ip "字段将是空白的,并且持续时间将是零。

转发的或重定向的呼叫

转发呼叫的呼叫记录将是相同的象那些为正常呼叫除了" originalCalledPartyNumber "字段和“originalCalledPartyNumberPartition”字段。这些字段将包含目录号和分区由呼叫的创建人最初拨号的目的地的。如果呼叫转发, “finalCalledPartyNumber”和“finalCalledpartyNumberPartition”字段不同的,并且请包含呼叫的最终目的地的目录号和分区。并且,当呼叫转发, “lastRedirectDn”和“lastRedirectDnPartition”字段将包含转发的或重定向此呼叫最后电话的目录号和分区。

与忙碌或Bad目的地的呼叫

这些呼叫将被记录作为与包含数据的所有相关字段的正常呼叫。Called Party Cause字段将包含指示呼叫为什么的原因代码未连接,并且被叫方IP和日期/时间连接字段将是空白的。如果创建人放弃呼叫,原因将是“NO_ERROR” (0)。持续时间永远将是零秒。除非“CdrLogCallsWithZeroDurationFlag”启用,这些呼叫不会被记录。

根据呼叫类型记录的呼叫管理记录

在确切两本思科IP电话日志之间的每正常呼叫两个CMR记录。每个呼叫CMR记录包含所有字段识别以上。当附加服务在呼叫时涉及,超过一个记录可能写入。当诊断记录为在系统时的不同的呼叫类型写入此部分描述。

正常呼叫

正常呼叫正确地记录每呼叫两个CMR记录,一个在呼叫涉及的每个电话的。目前,仅思科IP电话和MGCP网关能够响应对诊断信息请求。所有字段将包含有效信息。

放弃的呼叫

如果呼叫放弃(例如,当电话被采取在挂的摘机和已拨上一步),与放出数据涉及的所有字段将是空白(零)。这是因为流连接未被建立,并且数据未转接。如果“CdrLogCallsWithZeroDurationFlag”禁用,与空白字段的记录不会被记录。

转发呼叫

转发呼叫的呼叫记录将是相同的象那些为正常呼叫。

与忙碌或Bad目的地的呼叫

正常情况,代表呼叫实际上连接仅的记录将被记录。为了记录与坏目的地的呼叫,您必须启用“CdrLogCallsWithZeroDurationFlag”。如果它启用,则所有呼叫将被记录包括用户再去摘机然后挂机的案件。

如果呼叫被记录,他们将被记录作为与包含数据的所有相关字段的正常呼叫。因为呼叫未曾连接对目的地,只将有每呼叫一个记录。记录将是为呼叫的创建人。

编解码类型(压缩/有效载荷类型)

下表为编解码器类型提供值和说明。

编码说明
编码 说明
1 非标准
2 G711A-law 64k
3 G711A-law 56k
4 G711ï ¿  ½ -法律64k
5 G711ï ¿  ½ -法律56k
6 G722 64k
7 G722 56k
8 G722 48k
9 G7231
10 G728
11 G729
12 G729AnnexA
13 Is11172AudioCap
14 Is13818AudioCap
15 G729AnnexB
32 数据64k
33 数据56k
80 GSM
81 ActiveVoice
82 G726_32K
83 G726_24K
84 G726_16K

原因代码

下表提供可能在原因字段出现原因代码的列表。

原因代码说明
原因代码 说明
0 无错误
1 未指定(未分配)号码
2 没有指向指定转接网络(国家使用)的路由
3 没有指向目标的路由
4 发送特殊信息音
5 拨错号码的中继线前缀(国家使用)
6 信道不可接受
7 呼叫已判定,正在通过已建立的信道传输
8 Preemption
9 优先占用 - 线路保留,可以重用
16 正常呼叫清除
17 用户忙
18 无用户应答
19 用户无应答(用户已告警)
20 用户不在
21 呼叫被拒绝
22 号码已改变
26 未选择的用户清除
27 目标故障
28 号码格式无效(地址不完整)
29 设备被拒绝
30 响应状态查询
31 正常,不明
34 无可用线路/信道
38 网络无序
39 永久的帧模式连接不在服务中
40 永久的帧模式连接正在进行中
41 临时失败
42 交换设备拥塞
43 访问信息被丢弃
44 没有请求的线路/信道
46 优先呼叫被堵塞
47 资源不可用,不明
49 服务质量不可用
50 请求的设备未预订
53 违反服务操作规定
54 来电受阻
55 在封闭的用户组(CUG)内禁止的呼入呼叫
57 载体功能未授权
58 承载能力当前不可用
62 指定的流出访问信息和用户类别不一致
63 服务或选项不可用,不明
65 承载能力未实现
66 信道类型未实现
69 请求的功能未实现
70 仅受限的数字信息载体能力可用(国家使用)
79 服务或选项未实现,不明
81 呼叫参考值无效
82 识别的信道不存在
83 一个暂停的呼叫存在,但此呼叫标识不存在
84 呼叫标识正在使用
85 无呼叫挂起
86 具有请求的呼叫标识的呼叫已经被清除
87 封闭的用户组(CUG)的不是用户成员
88 目标不兼容
90 目标号码丢失,而且 DC 未预订
91 转接网络选择无效(国家使用)
95 消息无效,不明
96 必需的信息元素缺失
97 消息类型不存在或未实现
98 消息与呼叫状态不兼容,或者消息类型不存在或未实现
99 信息元素或参数不存在或未被实施
100 信息元素内容无效
101 消息与呼叫状态不兼容
102 呼叫终止,当计时器超时,并且恢复例程被执行从错误恢复
103 参数不存在或未实现 - 已传递(国家使用)
110 带无法识别的参数的消息被丢弃
111 协议错误,不明
126 呼叫已分解。这是一个CISCO专用的代码。使用它,当呼叫在转发操作时时终止,因为拆分并且终止(不是一部分的最终转接呼叫)。这可帮助确定作为转发操作一部分,哪些呼叫终止。
127 互通,不明

报警

报警发出,当CDR或诊断数据启用时,并且系统无法写数据到数据库。

无法写CDR数据。(报警# 1711 -重要警报)

尝试的打开系统数据库,和不成功。可能原因包括:

  • Cisco CallManager没有足够的权限打开写入的文件到数据库。确保Cisco CallManager有将允许写入操作的权限。

  • 路径没有设置,或者数据库服务器发生故障。

呼叫 Cisco 技术支持中心 (TAC)

如果有不可以是解决的通过您自己的故障排除的一问题,请呼叫协助的TAC。在呼叫TAC前,请有以下有用的资料:

  • Cisco CallManager详细信息

  • 拓扑

  • 在故障排除期间,包括SDI和SDL跟踪,日志和跟踪您运行了

  • Stackwalk.txt文件从WINNT\system32目录和Cisco CallManager跟踪子目录

  • 在Cisco IOS网关的sh-tech,如果适用

  • 在Cisco CallManager的sh-tech

  • 如果问题是呼叫通过Cisco IOS网关,也请提供:

    • 调试语音ccapi inout

    • debug isdn q931

    • 仅[AS5300]嘘vfc xboard

    • 仅[AS5300] sh vfc x version dspware

    • 仅[AS5300]嘘vfc x版本VCWARE


相关信息


Document ID: 30266