了解UCCX中的JTAPI体系结构和呼叫流程

简介

本文档介绍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开发具有以下特点的应用：

• 控制和观察Cisco Unified Communications Manager电话。

• 使用计算机电话集成(CTI)端口和路由点（虚拟设备）路由呼叫。

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下，以确保您可以控制这些设备。

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呼叫流程中涉及的事件的顺序：

1. 当呼叫到达CTI路由点时，会重定向到CTI端口。
2. CTI端口使用uccx盒上的ipvms驱动程序打开媒体通道。
3. 一旦您确定座席需要接听呼叫，则从端口到座席进行咨询转接。
4. 新的呼叫事件将发送到CTI路由点。
5. 重定向请求转到CTI端口。
6. 呼叫id的状态变为空闲。
7. 然后，另一个新呼叫事件将接到CTI端口的呼叫。
8. 如果重定向响应为0，则表示正常；如果非零，则表示失败。
9. 然后，您发送呼叫接受请求（此请求不会被应答，只是端口上被接受）。
10. 然后，在脚本上接受分步命中，这时呼叫应答请求进入Jtapi。

11.然后从该端口获得应答响应。

12.呼叫状态更改为“已连接”。

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端口首次在电话上按转接按钮。

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调试级别。

1. 登录UCCX。
2. 转至CCX Serviceability。
3. 转到Trace。
4. 转到Configuration。
5. 从Select Service下拉列表中选择Cisco Unified CM Telephony Client。
6. 选中Debugging复选框。
7. 选中除MISC_DEBUGGING之外的所有复选框。

收集JTAPI调试

请检查以下步骤以从RTMT或CLI启用JTAPI调试级别。

从RTMT

1. 登录CCX实时监控工具。
2. 单击Trace & Log Central。
3. 单击收集文件。
4. 为所有服务器选择JTAPI Client。
5. 单击 Next。
6. 选择要保存日志文件的时间戳和位置。

从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选项允许您以压缩格式下载文件。

参考链接

• JTAPI开发人员指南
• UCCX跟踪级别