协作 : Cisco ICM 路由器软件

ICM/IPCC CallRouter不同步情况

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


目录


简介

本文略述必要的推荐的步骤和跟踪级别排除故障在Cisco Unified Contact Center智能联络管理(ICM)用双工制的CallRouters的一个失调的事件。

先决条件

要求

Cisco 建议您了解以下主题:

  • Cisco ICM

  • 对ICM中央控制器功能的高层次了解

  • Regedit

  • Microsoft SQL

使用的组件

本文档中的信息根据Cisco ICM版本5.x和以上。

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

规则

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

说明

在极少数情况下, ICM CallRouters能变得失调与其双工对方。此事件的主要触发是在CallRouter和其对等体之间的一个失效校验和。当CallRouters变得失调时,是路由器内存转储在失败的一个标准的对象转储(草皮)文件生成。

一个失调的事件可能导致CallRouter误转的呼叫。

这些方法中的任一个可以用于检查失调的情况:

  • CallRouters自动地执行在双方之间的一同步检查每15秒。如果它检测一个失调的情况, CallRouter创建在此目录内的一个草皮文件:

    <drive>:\icm\<instance>ra 
    and 
    <drive>:\icm\<instance>rb
  • 此消息在Windows事件查看器内的应用程序日志生成在CallRouter。这是消息详细信息:

    the router has detected that it no longer synchronized with its partner

    SNMP陷阱也生成。

  • 从CallRouter (rtr)记录(仅示例) :

    ra-rtr The router has detected that it is no longer synchronized with its partner 
    ra-rtr Trace: RunningSyncCheck failure: SideA reported 0A7FDF68, B reported FF1319C5 
    ra-rtr Trace: Wrote 719296 records to sync32932.sod, total length = 1871522788 bytes 
    ra-rtr Trace: Router dump created in sync32932.sod 
    rb-rtr The router has detected that it is no longer synchronized with its partner 
    rb-rtr Trace: RunningSyncCheck failure: Side A reported 0A7FDF68, B reported FF1319C5 
    rb-rtr Trace: Wrote 719296 records to sync32932.sod, total length = 187152790 bytes 
    rb-rtr Trace: Router dump created in sync32932.sod

另外的记录日志

注意: 生成结果的标准的草皮文件,当CallRouters是失调时有他们的限制和那里是时期,当设计要求一个更加粒状的级别调试改善查出原因时。如果运行ICM 5.0 (0个) SR8或以上,您有可以启用增加草皮文件的调试的两注册表项。

启用在两CallRouters的这些注册调试:

HKEY_LOCAL_MACHINE\SOFTWARE\Cisco Systems, Inc.\ICM\
<cust_instance>\RouterX\Router\CurrentVersion\Debug

有两条目、MessageTrackingEnabled和MessageTrackingLimit。

设置这些值:

  • MessageTrackingEnabled = 1

  • MessageTrackingLimit = 10000 (十进制值)

注意: 这些是动态值并且立即生效。这不引起与ICM的任何反常行为。当您集这些跟踪位时,启用更加详细的草皮文件调试如果另一个失调的情况发生。没有需要禁用这两个trace位,他们应该保持。然而,这些trace位恢复回到默认值(即),如果设置在CallRouters运行。如果这发生,他们需要手工重新授权给

数据收集

当您请求中断的时, Cisco TAC技术支持此数据和信息是需要的:

  1. 注释确切的时间失败。

  2. 收集从两边(rtr的CallRouter日志, mds, nm, ccag)中断的时间段的。

  3. 收集事件查看器(系统和应用程序)在文本格式导出的日志由在各自日志文件夹鼠标点击并且选择保存。选择文本在保存下作为下拉的类型。

  4. 收集从两CallRouters的草皮文件。

  5. 收集请跨过的CallTypeHalfHour、TCD和RCD记录2.5小时,在路由器去失调,并且前1个小时,在恢复后。

    这些需要在选项卡分隔的格式从记录器的两边,并且他们需要被转存。从记录器的两边,这些记录必须来。

    这是示例SQL查询:

    SELECT * FROM Call_Type_Half_Hour 
    WHERE DateTime >= 'yyyy-mm-dd hh:mm' /* At least 2.5 hours before the 
    out of sync error occurred */ 
    AND DateTime < 'yyyy-mm-dd hh:mm' /* At least 1 hour after the 
    out of sync error occurred or less 
    if run within an hour of the problem happening */ 
    
    SELECT * FROM Termination_Call_Detail 
    WHERE DateTime >= 'yyyy-mm-dd hh:mm' /* At least 2.5 hours before the 
    out of sync error occurred */ 
    AND DateTime < 'yyyy-mm-dd hh:mm' /* At least 1 hour after the 
    out of sync error occurred or less 
    if run within an hour of the problem happening */ 
    
    SELECT * FROM Route_Call_Detail 
    WHERE DateTime >= 'yyyy-mm-dd hh:mm' /* At least 2.5 hours before the 
    out of sync error occurred */ 
    AND DateTime < 'yyyy-mm-dd hh:mm' /* At least 1 hour after the 
    out of sync error occurred or less 
    if run within an hour of the problem happening*/
  6. 在每个语音应答单元外围设备接口管理器(VRUPIM)的收集的vrutrace文件在该的外围通路(PG)的两边包括时间段至少1个小时,在路由器是失调的,并且前30分钟,在恢复后。

    欲知更多信息,参考如何使用vrutrace实用程序

  7. 在他们以后前,去失调对时间请执行dumpcfg工具两记录器数据库从时间。

    参考使用dumpcfg管理工具跟踪ICM配置更改欲知更多信息。

  8. 请使用ICMDBA为了导出从两台记录器的配置。

  9. 从CallRouters的两边,导出整个ICM注册分组。

    HKEY_LOCAL_MACHINE\SOFTWARE\Cisco Systems,Inc.

解决方法

这些是两个应急方案选项:

  • 通过再关闭两个CallRouter进程然后开始他们循环CallRouters备份。这是最干净的方式在此情况附近工作。

  • CallRouters的重新启动一端。

这两个选项造成CallRouters同时再同步和运行。这意味着两CallRouter侧再将路由呼叫同一个方式。

选项1是首选方法并且导致正确地路由所有呼叫的两CallRouters一个高可能性,当重新启动。然而,如果不能利用机会的有两CallRouters下来同时,可以使用选项2。

选项2能导致作为选项1.选项2造成CallRouters再同步,并且两边路由呼叫同一个方式的同一个级别成功。然而,如果CallRouter有一个不正确的状态在未重新启动的再同步以后, CallRouter在两边陈述不正确。此案件可以导致两CallRouters,虽然同步,不正确地路由一些呼叫。机会这将发生也许轻微高于,如果在选项1的步骤采取。

注意: 思科强烈建议安排维护窗口为了进行这些恢复操作至于减轻影响到制作呼叫路由。


相关信息


Document ID: 81904