协作 : Cisco ICM 路由器软件

了解期待延迟 (ED)

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


目录


简介

本文列出与预期延迟涉及的一些常见问题,并且解释如何计算ED,数据来自和如何排除故障问题。

先决条件

要求

Cisco 建议您了解以下主题:

使用的组件

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

  • Cisco ICM 4.6.2和以后

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

规则

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

背景信息

ED是在Cisco ICM、Cisco网络应用管理器(NAM)和IP Contact Center (IPCC)环境的一使用的度量。

概括地说, ED是预期延迟(以秒钟)其中任一的新的呼叫被添加到队列服务的。只有当代理程序不是可用的, ED有效。

注意: 如果代理程序是可用的, ED是零。

最小预期延迟(MED)是在精选的一标准选择规则联机并且路由脚本编辑器。ï ¿  ½的挑选节点,如果从多个服务挑选,并且使用标准MED规则, CallRouter选择与最小的值的服务MED的(最低)。

为了充分地了解ED,您必须知道ED如何计算。

注意: ED是一个仅服务计算。

您不能路由与MED到一套技能组。这是标准ED公式:

((CallsQNow + 1) * AHTto5) / Max (Agents Talking [OR] Ready)
  • CallsQNow是当前排队的呼叫的一计数服务的在外围。

  • +1用于指示可以是潜在已添加对队列的呼叫。

  • AHTto5在实时。ï AHT的值计算如下的¿  ½定义作为平均处理时间(以秒钟)对服务的呼叫的在当前五分钟间隔。ï ¿  ½ AHTto5期间是“最近”五分钟平均数(从现在起,和最最近的五分钟)和计算:

    HandleTimeTo5/CallsHandledto5

  • HandleTime为计数的入站ACD呼叫仅被跟踪如被处理为服务。ï ¿  ½ HandleTime是指在呼叫上花费的总时间。所以, HandleTime是总呼叫量持续时间,从代理程序应答呼叫对时间代理程序完成工作。ï ¿  ½ HandleTime包括所有TalkTime的时间, Holdtime和WorkTime关联与呼叫(从Termination_Call_Detail)。当代理程序完成所有工作关联与呼叫时, ï ¿  ½ AvgHandleTime值在数据库更新。

注意: 在最最近的五分钟间隔期间,如果没有服务的入站ACD已处理呼叫, Cisco ICM在您不能配置此默认AHT值。ï ¿  ½在router.exe应用程序硬编码的ED公式。ï ¿  ½使用默认AHT值120秒。

在分母, CallRouter使用AgentsTalking值或者AgentsReady值(值当前更加高)。

  • AgentsTalking的值当前是服务座席数量在通话状态。AgentsTalking值在服务中包括所有技能组(如对Service_Member定义)。

  • AgentsReady值在READY状态。ï ¿  ½ Ready在工作来自Skill_Group_Real_Time表,并且包括代理程序是代理程序被注册到系统的状态,并且当前在呼叫或者介入或者是可用处理一新的呼叫。ï ¿  ½如以前被提及, ED假设,代理程序不是可用的。AgentsReady值在作为主要的定义的技能组中包括仅那些代理程序在Service_Member。

注意: 在多subskill的一些ACD支持代理程序,与另外优先级。ï ¿  ½ CallRouter考虑AgentsReady和只包括是subskill第一(1)的成员的那些代理程序。

排除故障预期延迟

当您知道时ED如何计算,您能排除故障ED公式导致意外的值。ï ¿  ½许多次的情况,您能描述与ED的一问题到在Cisco ICM的一不匹配,并且ACD配置,因为问题适合于对外围Service.ï ¿  ½保证服务和技能组Peripheral number正确,并且Service_Member信息是准确。ï ¿  ½请保证代理程序登录成员技能组。ï ¿  ½,如果使用subskill,保证代理程序登录subskill第一(1)。

如果配置是准确的, enable (event)特定跟踪为了查明问题。

推测

这是路由器的推测机制的简要说明。此部分说明推测为什么是必要的,并且如何实现。

推断示例

假设,一个简单路由脚本尝试装载根据排队的呼叫数量仅的平衡呼叫,并且发送呼叫到有少量呼叫的站点。

注意: 虽然此示例是指排队的呼叫,同一机制使用一定数量的其他变量,列出以后在本文。

  1. 呼叫到达。

  2. 路由器选择站点,并且发送呼叫。

  3. 网络提供呼叫。

  4. ACD看到呼叫到达,并且运行发出排队的呼叫的一份内部脚本。

  5. Cisco ICM (通过PIM和OPC)注意呼叫和变化在队列统计信息上。

  6. Cisco ICM报告回到路由器,排队的呼叫数量更新。

所有此需要时间发生。它能用所有这些步骤的七秒能发生。对于那些七秒,路由器仍然认为排队的呼叫数量是最初值。如果路由器给路由的一新的呼叫,路由器仍然认为同一个站点是最好的站点。在一大容积应用程序,在您终于接收从PG前的更新队列计数您能容易地发送数十呼叫到站点。那时,某个其他站点突然查找好,并且路由器发送所有呼叫到该站点。现象呼叫“灭火水龙带路由”。

这是示例。时间依靠网络、介入的ACD或者VRU。路由器有解决的有限信息此问题。特别是,没有办法匹配的路由器从PG的流入的数据与路由的实际呼叫。例如,所以没有办法知道呼叫在排队的呼叫量度包括,当PG报告队列计数。

在路由器的推测机制是在Cisco ICM实现的解决方案。机制用于设法预计实时值。这是推测如何为一变量工作类似服务的CallsQueueNow :

在内部, CallsQueueNow在两部分中管理:

  • CallsQueueNow基础值,是值为时由PG报告。

  • CallsQueueNow调整,由路由器管理。

当路由脚本参考CallsQueueNow时,看到基础值和调整的总和。当CallsQueueNow在实时供给发送对AW,只有基础值被发送。为了管理调整,路由器加1,当呼叫路由对服务时,然后设置计时器。计时器的默认值是10秒。当计时器超时时,路由器从调整减去1。

这是一示例用实际编号:

假设,有3个排队的呼叫:

  1. 起初, base=3, adjustment=0

  2. 呼叫到达和路由对服务, base=3, adjustment=1。这时路由的其他呼叫看到3+1=4排队的呼叫。

  3. 七几秒后,那里PG报告是4个排队的呼叫。现在base=4, adjustment=1 (仍然)。这时路由的呼叫看到一个过高估计的值5个排队的呼叫。

  4. 三几秒后, 10秒钟的推测计时器超时。现在base=4, adjustment=0。

此示例指示排队的呼叫数量的过高估计。

相似的机制在一定数量的路由参数使用。此表列出被外推的变量:

对象 菲尔茨 方向
服务 CallsQNow
ExpectedDelay
CallsInProgress
CallsInNow
技能组 AgentsAvailable 下来
NetworkTrunkGroup TrunksIdle 下来
CallsInNow

方向列指示调整做[+1的方向()或– 1 (下来)]。推测机制也用于管理代理程序。

特别是, LongestAvailableAgent变量通过是完全不同的与的机制管理什么描述此处。路由器接收在单个代理程序的状态从PG。在内部,当代理程序变得可用时,它维护所有可用座席列表,指令,当的时候。

当代理程序选择(例如在LAA),路由器指示代理程序在列表的题头作为“临时地不可用”在10秒。在此时间, PG忽略状态报道,并且路由器假设,代理程序不可用。从那以后,座席状态恢复对什么PG为时报告。如果ACD偶然发送呼叫到错误的代理程序,此机制允许路由器占使用特定代理程序,并且启用恢复。这种路由比其他量度可以准确。这是因为调整没有做,只要ACD发送呼叫到路由器猜测的代理程序。

有时,可以有关于AgentsAvailable和LongestAvailable行为的混乱。AgentsAvailable由up/down算法调节,并且能低估可用座席编号。LongestAvailable从可用座席列表独立地被计算。LongestAvailable能显示可用座席,即使AgentsAvailable指示零。所以, LongestAvailable是准确,如前面提到。

设置预期延迟跟踪

预期延迟跟踪显示“被外推”的值,并且您能通过rttest实现跟踪。

trace_ed N

那里N是服务的SkillTargetID。此命令打开trace。

trace_ed N /off

此命令关掉trace。

当您启用此trace时, CallRouter在控制台窗口放置调试级别日志条目,并且在查看工具的.EMS日志文件。ï ¿  ½使用DumplogInspectLog查看日志文件输出。ï ¿  ½路由器打印此消息:

ED RR NAME(ID) xNN B=(qNN rNN tNN aNN hNN eNN) E=(qNN rNN tNN aNN hNN eNN)

RR代表trace的原因。这是多种代码说明:

代码 说明
T+
Trace打开。
T-
Trace关掉。
E+
推测开始(这导致,当呼叫路由)时。
E-
推测结束(10秒钟的超时)。
SK
更新,因为技能组变量更改(PG报告更改)。
SV
更新,因为服务变量更改(PG报告更改)。

  • NAME (ID)代表服务的名称和ID。

  • XNN是进展中的推测数量。这是呼叫数量在最后10秒内。

这是一些代码说明:

代码 说明
QNN
排队的呼叫。
Rnn
就绪的代理程序。
Tnn
代理谈话。
Ann
可用座席。
Hnn
平均处理时间到5。
Enn
预期延迟。

有两套这些变量:

  • B= ()集是“基本”从他们计算的套所有变量,如报告由PG和ED。

  • E()集是“被外推的”集,根据最近已路由呼叫。

排除故障预期延迟的其他工具

您能使用脚本编辑器的显示实时数据功能排除故障MED.ïÂ的¿  ½知道在脚本编辑器显示的数据可以是一样旧有象十五秒或更多是重要的和经常只显示基础值,而不是被外推的值。

查看数据在实时排除故障ED.ïÂ此的¿  ½,请使用dump_vars命令从rttest的内部,查看CallRouter知道的多种值和变量。

Rttest: dump_vars /?

注意: 是列出的值可以被外推。

语法示例

rrtest,请运行:

dump_vars /service <Service.SkillTargetID>

dump_vars /group <Skill_Group.SkillTargetID>

您能通过ISQL/W确定SkillTargetID或快速查询功能在模式帮助程序查找。

如果输入服务或技能组SkillTargetID的一个适当的值, rttest显示变量名称的列表(例如, AgentsAvailable和AgentsReady)和与值的列通常每变量。ï ¿  ½,值是正整数,并且明显。ï ¿  ½ -1表明值取消定义。

当您排除故障时,比较在rttest看到的值,与有用的资料的dump_vars从ACD.ï ¿  ½,当您比较数据,寻找可以是问题的原因的可能的不规则性。

一些Cisco用户技术支持工程师(CSes)也有与例如观察命令使您评估所有可适用的表达式。ï ¿  ½观察命令是最有用的排除故障自定义公式的观察in命令rttest。ï ¿  ½的成功(自定义“ExpectedDelay”计算)。ï ¿  ½,如果更改表达式值, CallRouter在Router Process窗口立即包括条目(和在.ems文件)与当前值。

这是您如何必须发出观察命令:

rttest: watch <expression>

where:

  • 例如“表达式”是所有有效表达式, :

    rttest: watch Service.Boston_Aspect.Support.AgentsReady 
    Watch 0 added.
  • 例如您能通过/delete交换机删除观察, :

    rttest: watch 0 /delete

OPCtestProcmon也有允许您列出代理程序和呼叫。ï ¿  ½参照与的多种子例行程序什么的这些值您了解ACD和CallRouter。寻找可以是问题的原因的可能的不规则性。

如果最近已安装Cisco ICM和第一次启动一新的服务, MED可以不同的从什么您期待。ï ¿  ½许多次, MED是不同的由于这些原因之一:

  • 推测的作用。

  • 呼叫没有被处理(默认是AHT的120秒,并且不可能预计)。

  • 少量呼叫进展中或在队列。

ED是最准确的,当有平均为。ï ¿  ½时的许多项目,当更多代理程序在成员技能组中时是可用的,并且更多呼叫被处理, MED结果是更加好。


相关信息


Document ID: 29522