瞭解UCCX中的JTAPI體系結構和呼叫流

簡介

本文檔介紹JTAPI的基本功能、其體系結構以及與UCCX相關的呼叫流。

必要條件

需求

思科建議瞭解以下工具和功能：

• JTAPI - Java電話API
• API -應用程式設計介面
• UCCX -統一聯絡中心快捷版
• CUCM -思科統一通訊管理器
• CTI -電腦電話整合

思科建議瞭解以下主題：

• 思科統一通訊管理器(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所使用的Provider模式：

JTAPI提供程式模型提供程式模型

JTAPI提供程式是從應用程式到Call Manager或CTI Manager的連線。提供者用於將觀察者附加至物件。您也可以將觀察器附加至提供者。提供者可用來取得有關對物件採取之動作的通知。(您也可以控制附加了觀察器的裝置（來自附加了觀察器的提供商）。

JTAPI使用者

以下螢幕截圖來自CUCM（左）和UCCX（右），用於說明JTAPI應用使用者。

• 當您啟動應用程式並要連線至CTI管理員時，請開啟提供者。
• 打開提供商的原因是為了監控對裝置、終端等執行的操作。
• 在CUCM中實施的方式是透過應用使用者。
• 您建立此使用者並提供憑證，以便其可以首先透過CTI向CUCM進行身份驗證。
• 因此，在CUCM中建立的JTAPI應用使用者是提供商。
• 除了進行監控外，您需要確保這些裝置位於關聯的裝置下，以確保您可以控制這些裝置。

P1與P2控制代碼

P1和P2是提供商控制代碼。當您要從同一應用程式中開啟多個提供者時，這些選項會變得重要。在UCCX中，您將建立兩個提供商，其中一個提供商控制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上建立Trigger時，它將被增加到兩個JTAPI使用者。兩個節點分別開啟一個提供者。因此，在路由點上執行的任何操作都會在兩個CCX節點上收到通知。

除此之外，次要節點就停留在原處，並不斷通知它仍是次要節點。每個節點都有一組單獨的CTI埠。節點1的CTI埠由jtapi_1控制。節點2的CTI埠由jtapi_2控制。

當呼叫到達CTI路由點時，兩個CCX節點都會收到關於新呼叫事件的通知，但主用CCX節點會向呼叫管理器回覆一個重定向請求，請求其控制的一個CTI埠。

如果您在CUCM的CTI路由點看到IP，它是CCX的IP之一，但這並不意味著特定節點正在路由呼叫。

您經常會做的一件事是，我們取消裝置與JTAPI使用者的關聯，然後重新新增裝置。其原因在於，當您取消關聯時，提供商會收到通知，並刪除與其的所有連線，然後當重新增加它時，觀察程式會再次增加，提供商會使用打開的提供商請求重新開始監視它。您可以看到，除了增加到受控裝置清單中的裝置外，還有另一個稱為「允許透過CTI控制裝置」覈取方塊的裝置位於個人裝置上。這是為了帶來更精細的層次。因此，如果您在控制清單中增加了「路由點」，但未選中「CTI」覈取方塊，您仍然可以獲取有關該路由點上事件的通知，但無法對呼叫控制執行任何操作。

呼叫流程

以下是UCCX呼叫流程中涉及的事件的順序：

1. 當呼叫到達CTI路由點時，會被重定向到CTI埠。
2. CTI埠打開帶有uccx盒上的ipvms驅動程式的媒體通道。
3. 一旦您決定座席需要接聽呼叫，就會從埠向座席進行諮詢轉接。
4. 新的呼叫事件被傳送到CTI路由點。
5. 重定向請求轉到CTI埠。
6. 呼叫ID的狀態變為空閒。
7. 然後，另一個新的呼叫事件將接到CTI埠的呼叫。
8. 如果重新導向回應為0，表示正常；如果不是0，表示失敗。
9. 然後，您將傳送呼叫接受請求（此請求未被應答，只是在埠上被接受）。
10. 然後接受指令碼中的步驟命中，即在Jtapi中發出呼叫應答請求時。

11. 然後從埠獲得應答響應。

12. 呼叫狀態更改為「已連線」。

13. 從連線埠取得應答回應後，就會進行媒體交涉。

14. 埠傳送open_logical_channel請求，在該請求中它共用其埠以及它希望遠端方傳送RTP的ip。

15. 在打開邏輯通道之前，它會與UCCX盒上的IPVMS驅動程式建立連線並打開RTP流。

16. 下一個事件是start_reception事件，它告訴我們遠端資訊（即呼叫裝置的ip和埠）。

17. 然後您會像收到任何其他媒體訊號一樣收到start_transmission事件。

18. 現在您正在收聽IVR和提示。

19. 現在，當呼叫到達指令碼中使呼叫轉接至座席的某個步驟時，您會看到CallSetupTransferRequest。

20. 與第一條資訊不同，這是諮詢轉賬，而不是重新導向。

21. 這是諮詢轉接的原因在於，如果座席已準備就緒，但不在座席的座位，並且我們重定向了呼叫，則呼叫仍未應答，但如果我們執行了諮詢轉接，那麼如果座席不在座位，則呼叫會再次進入隊列。

22. 就像任何其他諮詢轉接一樣，這是CTI埠首次按下電話上的轉接按鈕。

23. 在定期諮詢轉接中，A和C之間有一個媒體路徑，但在本例中，您指示CUCM不要這樣做，因為在UCCX和代理之間沒有建立媒體的感覺。

24. 因此，您將在代理和CTI埠之間不進行媒體切換的情況下進行諮詢轉接。

25. 此時，CTI埠將呼叫方置於保持狀態，我們看到呼叫狀態已更改，事件=保持。

26. 現在您會看到從CTI埠到座席裝置的新呼叫事件。（使用原始呼叫ID，但使用它的一個子集和P2事件。）

27. 如果您搜尋P2事件呼叫ID，您會看到下一條消息作為CallAnswer請求，這意味著座席接聽了呼叫。

28. 一旦您知道座席已接聽呼叫（使用P2），並且CTI埠側呼叫也處於連線狀態（使用P1），則路由點會看到CallDirectTransferRequest(這意味著已再次按下轉接按鈕)。

29. 現在，由於CTI埠知道座席已接聽呼叫，因此沒有必要等待，它會立即傳送一條CallDirectTransferRequest ，即為CTI埠，再次按下轉接按鈕（如上所述）。

30. 現在，原來的呼叫段（處於保持狀態的呼叫段）是倖存的呼叫段。

31. 另一個呼叫段被破壞（埠和座席之間）。

32. 此時，CUCM和UCCX脫離了畫面，呼叫方和座席之間透過網關建立RTP。

下圖以概要方式說明了前面提到的呼叫流。

JTAPI呼叫流摘要

疑難排解

啟用和收集JTAPI日誌

啟用JTAPI調試

請檢查以下步驟以啟用JTAPI調試級別。

1. 登入UCCX。
2. 轉到CCX Serviceability。
3. 轉到Trace。
4. 轉到Configuration。
5. 從選擇服務下拉選單中，選擇Cisco Unified CM Telephony Client。
6. 選中Debugging覈取方塊。
7. 選中除MISC_DEBUGGING之外的所有覈取方塊。

收集JTAPI調試

請檢查以下步驟以從RTMT或CLI啟用JTAPI調試級別。

從RTMT

1. 登入CCX即時監控工具。
2. 按一下Trace & Log Central。
3. 按一下Collect Files。
4. 為所有伺服器選擇JTAPI Client。
5. 按「Next」（下一步）。
6. 選取要儲存記錄檔的時間戳記和位置。

在CLI上

JTAPI日誌位置

activelog /uccx/log/JTAPI

用於收集JTAPI日誌的命令：

檔案get activelog /uccx/log/JTAPI/*重複壓縮

語法：

檔案取得{activelog|inactivelog|install} file-spec [選項]

要傳輸的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跟蹤級別