简介
本文档介绍JTAPI的基本功能、其架构以及与UCCX相关的呼叫流程。
先决条件
要求
思科建议了解以下工具和功能:
- JTAPI - Java电话API
- API — 应用编程接口
- UCCX — 统一联系中心快捷版
- CUCM - Cisco Unified Communications Manager
- CTI — 计算机电话集成
建议掌握下列主题的相关知识:
- Cisco Unified Communications Manager(CUCM)配置
- 统一联系中心快捷版(UCCX)配置
使用的组件
本文档中的信息基于以下软件版本:
- UCCX版本12.5.1.11002-481
- CUCM 版本 12.5.1.11900-146
本文档中的信息都是基于特定实验室环境中的设备编写的。本文档中使用的所有设备最初均采用原始(默认)配置。如果您的网络处于活动状态,请确保您了解所有命令的潜在影响。
背景信息
本文档介绍JTAPI架构、呼叫流程、启用调试和收集日志。
JTAPI概述
Cisco Unified JTAPI是Sun Microsystems开发的编程接口标准,用于基于Java的计算机电话应用。Cisco JTAPI通过其他Cisco扩展实现Sun JTAPI 1.2规范。您需要使用Cisco JTAPI开发具有以下特点的应用:
JTAPI和UCCX
Cisco Unified JTAPI用于联系中心,以监控设备状态,并发布路由指令,在正确的时间将呼叫发送到正确的位置。此外,JTAPI还用于在检索呼叫统计信息以进行分析时开始和停止记录指令,并用于将弹出屏幕呼叫记录到CRM应用程序、自动脚本编写和远程呼叫控制中。
JTAPI架构
在企业环境中使用的Cisco Unified JTAPI将用户可用性、位置和首选项相结合,为基于在线状态的路由提供独特的定制环境。
以下是JTAPI的应用:
- JTAPI可以监控或收到有关两个或多个电话与线路组合的通知。
- 联系中心应用使用JTAPI的完整呼叫模型。
- JTAPI提供以下功能:
JTAPI观察器模型
下图说明JTAPI运行的Provider-Observer模型。
观察员
观察器接口
JTAPI基于观察者的思想。按观察者来说,它指的是观察事件的人的观点。您可以让多个观察者置于系统内的不同事物上。JTAPI使用观察者来了解对象的状态变化。
例如,您可以将观察者置于线路、电话、终端、地址等上,并了解其状态变化。
注意:如果没有将观察器置于对象上,则无法收到有关对其执行的操作的通知。
JTAPI提供商模型
下图说明JTAPI运行的提供商模型:
JTAPI提供商模型提供商模型
JTAPI提供程序是从应用程序到Call Manager或CTI Manager的连接。提供程序用于将观察器附加到对象。还可以将观察者附加到提供者。提供程序用于获得有关对对象所执行操作的通知。(您还可以控制连接观察者的设备(来自连接该观察者的提供商)。
JTAPI用户
接下来的屏幕截图取自CUCM(左)和UCCX(右),用于说明JTAPI应用用户。
- 当您启动应用程序并要连接到CTI管理器时,您打开了提供商。
- 打开提供商的原因是为了监控在设备、终端等上执行的操作。
- 在CUCM中实施的方式是通过应用用户。
- 您可以创建此用户并提供凭证,使其可以首先通过CTI向CUCM进行身份验证。
- 因此,在CUCM中创建的JTAPI应用用户是提供商。
- 除了仅监控外,您需要确保这些设备位于Associated Devices下,以确保您可以控制这些设备。
注意:您不会在cucm上创建JTAPI用户,这是由应用(UCCX)通过CUCM上的AXL创建的。
P1和P2句柄
P1和P2是提供商句柄。当您要从同一应用打开多个提供商时,这些变得很重要。从UCCX中,您可以创建2个提供商,其中一个提供商控制CTI端口和路由点,另一个提供商控制称为RM-JTAPI提供商的座席电话。您在UCCX创建提供商时,首先控制CTI端口和路由点,即JTAPI P1提供商。在P1之后创建的另一个提供程序是P2提供程序或处理代理设备的RmCm提供程序。
如果看到P1新呼叫事件,您知道这是来自CTI端口或CTI路由点的呼叫事件。如果看到P2新呼叫事件,则表明这是来自实际电话的呼叫事件。您在CCX端创建了一个RM-JTAPI用户和一个JTAPI用户,但在CUCM端,您看到创建了2个JTAPI用户。这是因为每个CCX节点都有自己的JTAPI用户,但它们共享一个RM-JTAPI用户。在UCCX上创建触发器时,触发器将添加到两个JTAPI用户。两个节点分别打开一个提供程序。因此,在路由点上执行的任何操作都会在两个CCX节点上收到通知。
除此之外,辅助节点只是停留在那里并不断通知它仍然是辅助节点。每个节点都有一组单独的CTI端口。节点1的CTI端口由jtapi_1控制。节点2的CTI端口由jtapi_2控制。
当呼叫到达CTI路由点时,两个CCX节点都会收到有关新呼叫事件的通知,但活动CCX节点会向呼叫管理器回复一个重定向请求,请求其控制的一个CTI端口。
如果您在CUCM中看到针对CTI路由点的IP,它是CCX的IP之一,但这并不意味着特定节点正在路由呼叫。
您经常做的一件事是,我们从JTAPI用户取消关联设备并重新添加设备。其原因是取消关联后,提供程序会收到有关它的通知并删除与其的所有连接,然后当重新添加它时,观察程序会再次添加,提供程序会开始使用打开的提供程序请求再次监视它。您可以看到,除了要添加到受控设备列表中的设备外,在单个设备上还有另一个称为Allow Control of Device from CTI复选框的事物。这是为了带来更高级别的粒度。因此,如果您在受控列表中添加了Route Point,但未选中CTI复选框,您仍然可以获取有关该路由点上事件的通知,但呼叫控制操作无法进行。
呼叫流
以下是UCCX呼叫流程中涉及的事件的顺序:
- 当呼叫到达CTI路由点时,会重定向到CTI端口。
- CTI端口使用uccx盒上的ipvms驱动程序打开媒体通道。
- 一旦您确定座席需要接听呼叫,则从端口到座席进行咨询转接。
- 新的呼叫事件将发送到CTI路由点。
- 重定向请求转到CTI端口。
- 呼叫id的状态变为空闲。
- 然后,另一个新呼叫事件将接到CTI端口的呼叫。
- 如果重定向响应为0,则表示正常;如果非零,则表示失败。
- 然后,您发送呼叫接受请求(此请求不会被应答,只是端口上被接受)。
- 然后,在脚本上接受分步命中,这时呼叫应答请求进入Jtapi。
注意:这种情况发生得非常快,而且有时同时发生多个事件,例如来自Cisco Unity Connection的呼叫或从CUCM转移花费的时间,这可能导致accept步骤中的RACE条件,这也是您要降低速度的原因。为此,您可以在接受步骤之前添加延迟步骤。
11.然后从该端口获得应答响应。
12.呼叫状态更改为“已连接”。
注意:CTI与sip或瘦电话不同,后者在发送新请求之前等待响应,因此JTAPI CTI消息中的消息顺序可以混乱。
13.从端口收到应答响应后,便会发生介质协商。
14.端口发送open_logical_channel请求,在该请求中它共享其端口以及它希望远程方向其发送RTP的ip。
15.在打开逻辑通道之前,它会与UCCX盒上的IPVMS驱动程序建立连接并打开RTP流。
16.下一个事件是start_receiving事件,它告诉我们远端信息(即呼叫设备的ip和端口)。
17.然后您会像任何其他媒体信号一样收到start_transmission事件。
18.现在您正在收听IVR和提示。
19.现在,当呼叫到达脚本中的某个步骤后,该步骤使呼叫能够转接至座席,您将看到CallSetupTransferRequest。
20.与第一条消息不同的是,这是咨询转接,而不是重新定向。
21.这是咨询转接的原因在于,如果座席已就绪,但不在座位,并且我们重新定向呼叫,则呼叫仍未应答,但如果我们进行咨询转接,则如果座席不在座位,则呼叫将再次置于队列中。
22.与任何其他咨询转接一样,这是CTI端口首次在电话上按转接按钮。
注意ConsultWithoutMedia
:用于咨询传输的API。
23.在常规咨询转接中,A和C之间存在介质路径,但在本例中,您指示CUCM不要执行此操作,因为在UCCX和代理之间没有建立介质的感觉。
24.因此,您将进行咨询转接,而无需在座席和CTI端口之间执行介质切换。
25.此时,CTI端口将呼叫者置于保持状态,我们看到呼叫状态已更改,event=HOLD。
26.现在您会看到从CTI端口到座席设备的新呼叫事件。(使用原始呼叫ID,但使用其中的一个子集和P2事件。)
27.如果您搜索P2事件呼叫ID,则会看到下一条消息作为CallAnswer请求,这意味着座席已接听呼叫。
28.一旦您知道座席已接听呼叫(使用P2),并且呼叫在CTI端口侧也处于连接状态(使用P1),则路由点会看到一个CallDirectTransferRequest
,这意味着已再次按下转接按钮。
29.现在,由于CTI端口知道座席已接听呼叫,无需等待,它立即发送一个消息,即CTI端口第二次按转接按钮,如上文所述CallDirectTransferRequest
。
30.现在,原来的呼叫段(处于保持状态的呼叫段)是幸存的呼叫段。
31.另一个呼叫段被破坏(端口和座席之间)。
32.此时,CUCM和UCCX脱离了图象,RTP通过网关在呼叫方和座席之间建立。
下图以总结的方式说明了前面提到的呼叫流程。
JTAPI呼叫流摘要
故障排除
启用和收集JTAPI日志
启用JTAPI调试
请检查以下步骤以启用JTAPI调试级别。
- 登录UCCX。
- 转至CCX Serviceability。
- 转到Trace。
- 转到Configuration。
- 从Select Service下拉列表中选择Cisco Unified CM Telephony Client。
- 选中Debugging复选框。
- 选中除MISC_DEBUGGING之外的所有复选框。
收集JTAPI调试
请检查以下步骤以从RTMT或CLI启用JTAPI调试级别。
从RTMT
- 登录CCX实时监控工具。
- 单击Trace & Log Central。
- 单击收集文件。
- 为所有服务器选择JTAPI Client。
- 单击 Next。
- 选择要保存日志文件的时间戳和位置。
从CLI
JTAPI日志位置
activelog /uccx/log/JTAPI
用于收集JTAPI日志的命令:
file get activelog /uccx/log/JTAPI/* recurs compress
语法:
file get {activelog|inactivelog|install} file-spec [options]
要传输的file-spec必需文件
选项可选剩余月份|周|天|小时|分钟时间值
abstime hh:mm:MM/DD/YY hh:mm:MM/DD/YY
match regex
循环
压缩
根据时间戳下载日志的5种方法
reltime — 相对时间段,指定为分钟 | 小时 | 天 | 周 | 月份值
abstime — 绝对时间段,指定为hh:mm:MM/DD/YY hh:mm:MM/DD/YY
match — 匹配文件名中的特定字符串,指定为字符串值
recurs — 获取所有文件,包括子目录
compress选项允许您以压缩格式下载文件。
提示:要下载文件,请确保外部安全文件传输协议(SFTP)服务器已配置且可访问。
提示:recurs选项允许您遍历所有子目录和文件的目录。如果要从目录提取所有日志,则使用此命令。
参考链接