UCCXでのJTAPIアーキテクチャとコールフローの理解

はじめに

このドキュメントでは、JTAPIの基本機能、そのアーキテクチャ、およびUCCXに関するコールフローについて説明します。

前提条件

要件

次のツールと機能に関する知識があることが推奨されます。

• JTAPI:Java Telephony API（ジャバテレフォニーAPI）
• API:Application Programming Interface（アプリケーションプログラミングインターフェイス）
• UCCX:Unified Contact Center Express（ユニファイドコンタクトセンターエクスプレス）
• CUCM:Cisco Unified Communications Manager
• CTI:Computer Telephony Integration（コンピュータテレフォニーインテグレーション）

次の項目に関する知識があることが推奨されます。

• Cisco Unified Communications Manager(CUCM)の設定
• Unified Contact Center Express(UCCX)の設定

使用するコンポーネント

このドキュメントの情報は、次のソフトウェアのバージョンに基づいています。

• UCCX バージョン 12.5.1.11002-481
• CUCM バージョン 12.5.1.11900-146

このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、クリアな（デフォルト）設定で作業を開始しています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。

背景説明

このドキュメントでは、JTAPIアーキテクチャ、コールフロー、デバッグの有効化、およびログの収集について説明します。

JTAPIの概要

Cisco Unified JTAPIは、Javaベースのコンピュータテレフォニーアプリケーション用にSun Microsystemsが開発したプログラミングインターフェイス規格として機能します。Cisco JTAPIは、Sun JTAPI 1.2仕様と追加のシスコ拡張機能を実装しています。Cisco JTAPIを使用して、次のようなアプリケーションを開発する必要があります。

• Cisco Unified Communications Manager電話機を制御および監視します。

• コンピュータテレフォニーインテグレーション(CTI)ポートとルートポイント（仮想デバイス）を使用してコールをルーティングします。

JTAPIおよびUCCX

コンタクトセンターでは、Cisco Unified JTAPIを使用してデバイスのステータスを監視し、適切なタイミングで適切な場所にコールを送信するためのルーティング指示を発行します。さらに、JTAPIは、分析用のコール統計情報を取得する際の記録指示の開始と停止、およびCRMアプリケーションへのコールのスクリーンポップ、自動スクリプト、リモートコール制御に使用されます。

JTAPIアーキテクチャ

エンタープライズ環境で使用されるCisco Unified JTAPIは、ユーザのアベイラビリティ、ロケーション、およびプリファレンスを組み合わせて、プレゼンスベースのルーティング用にカスタマイズされた環境を実現します。

JTAPIのアプリケーションを次に示します。

• JTAPIは、2つ以上の電話と回線の組み合わせをモニタしたり、通知を受けたりすることができます。
• コンタクトセンターアプリケーションは、JTAPIのフルコールモデルを使用します。
• JTAPIは次の機能を提供します。
  • コール制御
  • メディア制御
  • メディア ネゴシエーション

JTAPIオブザーバモデル

次の図は、JTAPIが動作するProvider-Observerモデルを示しています。

オブザーバ

オブザーバインターフェイス

JTAPIはオブザーバーのアイデアに基づいています。オブザーバーによって、それは出来事を観察する人の考えを参照します。複数のオブザーバをシステム内の異なるオブジェクトに配置できます。JTAPIはオブザーバを使用して、オブジェクトの状態変化について知ります。

たとえば、回線、電話、端末、アドレスなどにオブザーバを配置し、その状態の変化について学習できます。

JTAPIプロバイダーモデル

次の図は、JTAPIが動作するプロバイダーモデルを示しています。

JTAPIプロバイダーモデルプロバイダーモデル

JTAPIプロバイダーは、アプリケーションからCall ManagerまたはCTI Managerへの接続です。プロバイダは、オブジェクトにオブザーバをアタッチするために使用されます。オブザーバをプロバイダに接続することもできます。プロバイダは、オブジェクトに対して実行されたアクションに関する通知を受け取るために使用されます。(オブザーバーが接続されているデバイスを制御することもできます（オブザーバーを接続しているプロバイダーから）。

JTAPI ユーザ

次のスクリーンショットは、JTAPIアプリケーションユーザについて説明するCUCM（左）およびUCCX（右）から取得したものです。

• アプリケーションを起動してCTIマネージャに接続するには、プロバイダーを開きます。
• プロバイダーを開く理由は、デバイスや端末などで実行されるアクションを監視できるようにするためです。
• CUCMで実装される方法は、アプリケーションユーザを通じて行われます。
• このユーザを作成してクレデンシャルを付与すると、最初にCTIを介してCUCMに対して認証を行うことができます。
• したがって、CUCMで作成されるJTAPIアプリケーションユーザがプロバイダーになります。
• 単に監視するだけでなく、デバイスを確実に制御できるようにするため、それらのデバイスがAssociated Devicesの下にあることを確認する必要があります。

P1およびP2ハンドル

P1とP2はプロバイダーハンドルです。これらは、同じアプリケーションから複数のプロバイダーを開く場合に重要になります。UCCXから、2つのプロバイダーを作成します。1つはCTIポートとルートポイントを制御し、もう1つはRM-JTAPIプロバイダーと呼ばれるエージェントの電話を制御します。UCCXは、CTIポートとルートポイントを最初に制御するプロバイダー（JTAPI P1プロバイダー）を作成します。P1の後に作成する他のプロバイダは、エージェントデバイスを処理するP2プロバイダまたはRmCmプロバイダです。

P1の新しいコールイベントが表示された場合は、それがCTIポートまたはCTIルートポイントからのコールイベントであることがわかります。P2の新しいコールイベントが表示された場合は、実際の電話機からのコールイベントであることがわかります。CCX側に1つのRM-JTAPIユーザと1つのJTAPIユーザを作成しますが、CUCM側には2つのJTAPIユーザが作成されたことが表示されます。これは、各CCXノードが独自のJTAPIユーザを取得しますが、1つのRM-JTAPIユーザを共有するためです。UCCXでトリガーを作成すると、両方のJTAPIユーザに追加されます。両方のノードがプロバイダーを個別に開きます。したがって、ルートポイントで実行されたアクションは、両方のCCXノードで通知されます。

それ以外の場合、セカンダリノードはセカンダリノードであることを通知し続けます。各ノードには、CTIポートの個別のグループがあります。ノード1のCTIポートはjtapi_1によって制御されます。ノード2のCTIポートはjtapi_2によって制御されます。

コールがCTIルートポイントに到着すると、両方のCCXノードに新しいコールイベントが通知されますが、アクティブなCCXノードは、自身が制御するCTIポートの1つに対するリダイレクト要求をCall Managerに返信します。

CUCMでCTIルートポイントに対するIPが表示される場合、これはCCXのIPの1つですが、特定のノードがコールをルーティングしているわけではありません。

一般的に、JTAPIユーザからデバイスの関連付けを解除し、再度追加します。関連付けを解除すると、プロバイダはその通知を受け取り、それに対するすべての接続を削除します。その後、オブザーバが再度追加されると、プロバイダはopen provider requestを使用して再度モニタを開始します。制御デバイスリストに追加されるデバイスとは別に、個々のデバイスにも「Allow Control of Device from CTI」チェックボックスが表示されていることがわかります。これにより、さらに細かい設定が可能になります。したがって、ルートポイントが制御リストに追加されていても、CTIチェックボックスがオンになっていない場合は、そのルートポイントのイベントについて通知を受け取ることはできますが、コール制御のアクションは実行できません。

コールフロー

UCCXコールフローに関連するイベントのシーケンスを次に示します。

1. コールがCTIルートポイントに到着すると、そのコールはCTIポートにリダイレクトされます。
2. CTIポートは、uccxボックスのipvmsドライバでメディアチャネルを開きます。
3. エージェントがコールを受ける必要があると判断すると、ポートからエージェントへの打診転送が行われます。
4. 新しいコールイベントがCTIルートポイントに送信されます。
5. リダイレクト要求がCTIポートに送信されます。
6. コールIDの状態はアイドルになります。
7. 次に、CTIポートへのコールに対する別の新しいコールイベントが発生します。
8. リダイレクト応答が0の場合は良好であり、0以外の場合は失敗したことを意味します。
9. 次に、call accept要求を送信します（これは応答されず、ポートで受け入れられただけです）。
10. 次に、スクリプトでステップヒットを受け入れます。これは、コール応答要求がJtapiに着信したときです。

11.次に、ポートから応答が返されます。

12.コール状態がconnectedに変わります。

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の間にメディアパスがありますが、UCCXとエージェントの間にメディアを確立する意味がないため、ここではCUCMにこれを行わないように指示します。

24.したがって、エージェントとCTIポートの間でメディアカットオーバーを実行せずに、打診転送を実行することになります。

25.この時点で、CTIポートは発信者を保留にし、コール状態が変更されたevent=HOLDを確認します。

26.次に、CTIポートからエージェントデバイスへの新しいコールイベントが表示されます（元のコールIDを使用しますが、そのサブセットとP2イベントを使用します）。

27. P2イベントコールIDを検索すると、次のメッセージがCallAnswer requestとして表示されます。これは、エージェントがコールをピックアップしたことを意味します。

28.エージェントが（P2を使用して）コールをピックアップし、CTIポート側でもコールが接続状態になっていること（P1を使用して）がわかったら、ルートポイントにはCallDirectTransferRequest、転送ボタンが2回目に押されたことを意味するが表示されます。

29.エージェントがコールをピックアップしたことをCTIポートが認識したため、待機する必要がなくなり、即座にCallDirectTransferRequest CTIポートが上記のように2回目に転送ボタンを押す状態になったことを送信します。

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 Real Time Monitoring Toolにログインします。
2. Trace & Log Centralをクリックします。
3. Collect Filesをクリックします。
4. すべてのサーバに対してJTAPI Clientを選択します。
5. [Next] をクリックします。
6. ログファイルを保存するタイムスタンプと場所を選択します。

CLIから

JTAPIログの場所

activelog /uccx/log/JTAPI

JTAPIログを収集するコマンド：

file get activelog /uccx/log/JTAPI/*はcompressを繰り返します。

構文：

file get {activelog|inactivelog|install} file-spec [オプション]

転送するファイル仕様の必須ファイル

オプションreltime months|weeks|days|hours|minutes timevalue

                                 abstime hh:mm:MM/DD/YY hh:mm:MM/DD/YY

                                 正規表現に一致

                                 再発

                                 圧縮する

タイムスタンプに基づくログの5つのダウンロード方法

reltime：相対時間（分で指定） | 時間 | 日 | 週 | 月の値

abstime：絶対時間（hh:mm:MM/DD/YY hh:mm:MM/DD/YYで指定）

match：ファイル名で文字列値として指定された特定の文字列を照合します

recurs：サブディレクトリを含むすべてのファイルを取得する

compressオプションを使用すると、zip形式でファイルをダウンロードできます。

参照リンク

• JTAPI開発者ガイド
• UCCXトレースレベル