Cisco Unified Customer Voice Portal（CVP）ソリューション リファレンス ネットワーク デザイン（SRND）Release 8.0(x)
偏向のない言語
この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
翻訳について
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
- Updated:
- 2017年5月26日
章のタイトル： GKTMP NIC の使用方法
GKTMP NIC の使用方法
Cisco ゲートキーパーの外部インターフェイス
Cisco H.323 ゲートキーパーは、Registration Admission Status（RAS）要求の処理を外部アプリケーションにハンドオフするために、Gatekeeper Transaction Message Protocol（GKTMP）を使用する外部インターフェイスを提供します。この機能により、組織はゲートキーパーのオンボード機能を補足でき、外部管理されるダイヤル プランおよび H.323 音声ネットワークでのインテリジェント コール ルーティングのサポートを提供できます。
GKTMP は RAS に基づいており、Cisco IOS ゲートキーパーと外部アプリケーション間の TCP 接続による情報交換に使用できる一連の ASCII 要求および応答メッセージを提供します。
詳細については、次の URL から入手可能な『 Cisco Gatekeeper External Interface Reference 』を参照してください。
http://www.cisco.com/en/US/docs/ios/12_3/gktmpv4_3/guide/gktmp4_3.html
Unified ICM GKTMP NIC
Unified ICM は、その GKTMP NIC を使用することでゲートキーパーの GKTMP サーバとして機能でき、GKTMP 要求メッセージをルート要求として処理し、ルーティング スクリプトを通常の方法で実行します。RAS の sourceInfo エイリアスおよび destinationInfo エイリアスが Unified ICM スクリプトでそれぞれ発呼者回線 ID および着信番号として使用可能になり、後者は通常、Unified ICM ルータによるスクリプト選択のために使用されます。Unified ICM スクリプトは、データベースやバックエンド システム アクセスなどの数多くの異なる機能を実行する場合があり、ゲートキーパーに戻すために、そして最終的に要求元エンドポイントに変更された destinationInfo エイリアスとして戻すために、最後はラベルを NIC に返信します。Unified ICM スクリプトは、sourceInfo エイリアスを変更することもできます。ただし、すべての要求元エンドポイントが、返された変換後の sourceInfo エイリアスを使用するわけではありません。Cisco IOS ゲートウェイはそれを使用しますが、Unified CVP コール サーバおよび Cisco Unified Communications Manager は無視します。
ゲートキーパーが Admission Request（ARQ; アドミッション要求）を無視して Admission Reject（ARJ; アドミッション拒否）を要求元エンドポイントに返すようにするために、Unified ICM スクリプトは BUSY ラベルと、オプションで追加の理由コード（DESTINATION_UNKNOWN など）を返すことができます。
GKTMP NIC の設定方法については、次の URL から入手可能な『 ICM Setup and Installation Guide 』を参照してください。
http://www.cisco.com/en/US/products/sw/custcosw/ps1001/tsd_products_support_series_home.html
Unified CVP を使用する GKTMP の一般的なアプリケーション
GKTMP NIC は、プレルーティングとポストルーティング両方のコール シナリオで Unified CVP とともに使用できます。前者はコールが Unified CVP コール サーバ（コール サーバ）にルーティングされて応答される前に入力ゲートウェイからのアドミッション要求を処理するために使用され、後者は Unified CVP コール サーバによって実行される転送用です。
•
コールが Unified CVP によって応答される前のインテリジェント拒否
コール サーバは、H.225 SETUP メッセージを受信すると、即座に CONNECT メッセージを返してコールに応答します。コールを Unified CVP に配信する前およびコールが応答される前に、ルーティング決定を行う必要がある場合があります。1 つの例として、look-ahead ルーティングの使用があります。このルーティングでは、Unified ICM スクリプトは、コールが Unified CVP に配信された後にコール シナリオ全体で必要となる他の Unified ICM ペリフェラルのアベイラビリティと到達可能性を判別します。GKTMP NIC を使用すると、コールに応答した後でリソースにコールを処理させないのではなく、TDM ネットワークを介した代替ルーティングのためにコールをインテリジェントに拒否できます。
ゲートキーパーのスタティック コンフィギュレーションは、着信コールを処理する最適なコール サーバの選択には不十分な場合があります。たとえば、発呼者回線 ID または送信元シグナリング アドレスに基づいてルーティング決定を行う必要がある場合があります。
トランスレーション ルーティングが不可能な宛先エンドポイントによって必要とされる追加情報で発呼者回線 ID をオーバーロードするために、sourceInfo エイリアスの変更が有効な場合があります。
Unified ICM は、集中型の H.323 音声ネットワーク ダイヤル プランを実装し、個々のゲートキーパーでのダイヤル プラン コンフィギュレーションの必要性を減らします。このアプローチは、ダイヤル プランが大規模、複雑、動的で、複数のゲートキーパーにわたって保持するのが困難な場合にのみ適切です。
この機能により、日時に基づく決定でゲートキーパー ルーティングが補足され、時間に依存するリソースのアベイラビリティを処理できます。
Unified ICM データベース ルックアップまたは外部システムからのアプリケーション ゲートウェイ機能データを、ルーティング決定に組み込むことができます。
• 使用可能な宛先に直接送信されて Unified CVP をバイパスした可能性があるコールのフィルタ
このアプローチは、コール サーバ リソースの使用を回避する方法に見えますが、使用可能な機能が制限されます。たとえば、ring-no-answer において代替宛先のインテリジェントな再クエリーを行うことはできず、このアプローチで後続のコール処理および転送のためにコールを Unified CVP に戻すこともできません。
• Unified CVP にコンテキストを渡すプレルーティング
この方式は、GKTMP NIC を介したスタンドアロン ルーティング要求を単純に実行するのではなく、コールのプレルーティング フェーズで収集されたコール コンテキストを Unified CVP に渡す必要がある場合に使用されます。この例では、コール サーバは、コールがコール サーバにトランスレーション ルーティングされるようにタイプ 2 VRU として設定される必要があり、さらに後続の転送を実行する必要があります。
Protocol-Level コール フロー
基本的には、GKTMP によって、Unified ICM ルーティング スクリプトが外部ビジネス ルールを追加できるようになります。外部ビジネス ルールは、着信番号またはラベルを指定して、コールの代替宛先ラベルまたはターゲット IP アドレスを選択するためにゲートキーパーによって呼び出されます。ただし、次の各ケースで説明されているように、Protocol-Level コール フローは、GKTMP 要求の使用目的によって異なります。
• 「着信コールのプレルーティング（ただし、コール コンテキストを渡す必要なし）」
この動作モードでは、入力ゲートウェイに到達するコールが、特定の Unified CVP コール サーバ ターゲットまたは非 CVP ターゲットを選択することを Unified ICM に要求します。コール サーバが選択されると、コールはまったく新しいコールとして Unified CVP に配信されます。Unified ICM スクリプトへのリンクは GKTMP ベースのルーティング ステップに含まれません。
• 「着信コールのプレルーティング（コール コンテキストを渡す必要あり）」
この場合には、入力ゲートウェイに到達するコールが、特定の Unified CVP コール サーバ ターゲットに配信される前に GKTMP NIC を介して Unified ICM に要求します。この初期 Unified ICM ルーティング スクリプトによって取得される情報は維持され、コールがコール サーバに配信されて処理が再開されるときに Unified ICM スクリプトで使用可能になります。
これは、ICM ルーティング スクリプトによって Unified CVP に返された宛先ラベルに転送されているコールのルーティングを変更するためのものです。前のルーティング スクリプトによって取得された情報は、GKTMP 要求によって起動された新しいスクリプトでは使用できません。新しいスクリプトは完全にスタンドアロンで機能します。
着信コールのプレルーティング（ただし、コール コンテキストを渡す必要なし）
2. 入力ゲートウェイが、ターゲット Unified CVP コール サーバ（または他の IP 宛先）を特定するようにゲートキーパーに要求します。
3. ゲートキーパーは、GKTMP 要求 ARQ を GKTMP NIC を介して Unified ICM に発行します。
4. Unified ICM は、着信番号、ANI、時間帯などに基づいてルーティング スクリプトを開始します。
5. Unified ICM ルーティング スクリプトは、応答 ARQ または応答 ACF をゲートキーパーに返します。前者の場合、Unified ICM は変更された情報を応答で返し、ゲートキーパーは ARQ 処理を再開して IP エンドポイントを選択します。このアプローチは、Unified ICM が宛先ラベルだけを返し、必要な宛先 IP エンドポイント アドレスを明示的に選択しない場合に採用されます。後者の場合、Unified ICM は要求の処理を完了し、変更された情報と選択されたターゲット IP エンドポイントを返します。この場合、ゲートキーパーは要求が完了したと見なし、要求の処理をそれ以上は行わず、ARQ を発行したエンドポイントに ACF を返します。Unified ICM ルーティング スクリプトはこの時点で終了します。
6. ゲートキーパーは、選択された IP アドレスを入力ゲートウェイに返します。
7. ターゲットが Unified CVP デバイスではない場合、入力ゲートウェイはそのターゲットへの VoIP コールを設定します。
8. ターゲットが Unified CVP コール サーバの場合、入力ゲートウェイは Unified CVP コール サーバへの新しいコールを設定します。
9. Unified CVP コール サーバは、New Call メッセージを Unified ICM に送信します。
10. Unified ICM は、着信コールを処理する独立したルーティング スクリプトを開始します。
11. 通常のコール フローが続行されます。VRU レッグへの転送、エージェントへの転送、およびセカンダリ エージェントまたは return-to-queue への後続のブラインド VRU ネットワーク転送が完全にサポートされます
着信コールのプレルーティング（コール コンテキストを渡す必要あり）
2. 入力ゲートウェイが、ターゲット Unified CVP コール サーバ（または他の IP 宛先）を特定するようにゲートキーパーに要求します。
3. ゲートキーパーは、GKTMP 要求 ARQ を GKTMP NIC を介して Unified ICM に発行します。
4. Unified ICM は、着信番号、ANI、時間帯などに基づいてルーティング スクリプトを開始します。
5. Unified ICM ルーティング スクリプトは、TranslationRouteToVRU を実行し、ターゲット Unified CVP コール サーバを選択します。
6. Unified ICM は、GKTMP NIC を介して GKTMP 応答 ARQ または ACF で、選択されたトランスレーション ルート ラベル（およびオプションで宛先エンドポイント IP アドレス）を返します。
7. ゲートキーパーは、選択された IP アドレスを入力ゲートウェイに返します。
8. 入力ゲートウェイは、選択された Unified CVP コール サーバに対して新しいコールを設定します。
9. Unified CVP コール サーバは、RequestInstruction メッセージを Unified ICM に送信します。
10. Unified ICM ルーティング スクリプトが TranslationRouteToVRU ノードの後から再開されます。
11. 通常のコール フローが続行されます。VRU レッグへの転送、エージェントへの転送、およびセカンダリ エージェントまたは return-to-queue への後続のブラインド VRU ネットワーク転送が完全にサポートされます（Unified ICM 7.0(0) よりも前のバージョンにおける制限については、「展開の意味」を参照してください）。
1. Unified ICM が、ターゲット エージェントまたは他の宛先ラベルを選択します。Unified ICM ルーティング スクリプトはこの時点で終了します。
2. Unified ICM は、選択されたラベルを Unified CVP コール サーバに返します。
3. Unified CVP コール サーバは、そのラベルに関連付けられたエンドポイント IP アドレスをゲートキーパーに要求します。
4. ゲートキーパーは、GKTMP 要求 ARQ を GKTMP NIC を介して Unified ICM に発行します。
5. Unified ICM は、選択されたラベル、ANI、時間帯などに基づいて完全に独立したルーティング スクリプトを開始します。
6. この新しい Unified ICM ルーティング スクリプトは、コールの適切なターゲットを選択します。
7. Unified ICM は、GKTMP NIC を介して GKTMP 応答 ARQ または ACF 応答で、選択されたラベル（およびオプションで宛先エンドポイント IP アドレス）を返します。Unified ICM ルーティング スクリプトはこの時点で終了します。
8. ゲートキーパーは、選択されたエンドポイント IP アドレスを Unified CVP コール サーバに返します。
9. Unified CVP コール サーバは、Empty Capability Set 転送を実行し、入力ゲートウェイおよび転送宛先エンドポイントと通信して、それらの間で VoIP コールを確立します。
展開の意味
GKTMP は単純な要求/応答プロトコルです。Unified ICM の観点からは、このことは、GKTMP NIC は単一のラベルおよびエンドポイント IP アドレスを返すこと以外の呼制御を実行できないことを意味します。その単一の宛先が返されると、GKTMP NIC によるサードパーティ呼制御が不可能になります。ただし、呼制御の責任が Unified CVP にハンドオフされる場合は可能です。次に、前の項で説明した 3 つのタイプのコール フローごとに、これらの呼制御の意味について説明します。
• 「着信コールのプレルーティング（ただし、コール コンテキストを渡す必要なし）」
• 「着信コールのプレルーティング（コール コンテキストを渡す必要あり）」
• 「その他の意味」
着信コールのプレルーティング（ただし、コール コンテキストを渡す必要なし）
このオプションには、2 つの ICM ルーティング スクリプトが必要です。最初のスクリプトは、着信コールの初期ターゲットを特定します。2 番めのスクリプトは、Unified CVP でのコール処理用の通常のルーティング スクリプトであり、これについてはこのマニュアルの別の箇所で説明します。1 つのスクリプトからもう 1 つのスクリプトへの転送は通常のラベル経由です。トランスレーション ルート転送または VRU レッグ転送ではありません。GKTMP で開始されたスクリプトは、キューイングまたは他の VRU アクティビティを実行できません。アドミッション要求のコンテンツを変更し、オプションでエンドポイント IP アドレスを返すことだけが可能です。
プレルーティング スクリプトが Unified CVP コール サーバ以外のエンドポイントに関連付けられたラベルを返す場合、それ以上の呼制御は不可能です。例外は、エンドポイントが Unified ICM への独自のポストルーティング インターフェイスおよび呼制御操作を実行する独自の機能を持つ ACD または VRU である場合です。
着信コールのプレルーティング（コール コンテキストを渡す必要あり）
このオプションでは、GKTMP で開始されたルーティング スクリプトと Unified CVP で開始されたルーティング スクリプトは同一です。コールをタイプ 2 Unified CVP ネットワーク VRU に送信するために TranslationRouteToVRU ノードを使用する必要があります。適切なエージェントがすでに使用可能な場合でも、後続のエージェントからエージェントへの転送を実行する機能が顧客に必要な場合、このノードは Queue ノードよりも前にある必要があります。この処理は無関係な転送に見えるかもしれませんが、Unified CVP への呼制御のハンドオフを強制するために必要です。
TranslationRouteToVRU の後、RunExternalScript ノードの実行の前に、VoiceXML ゲートウェイへの VRU コール レッグを確立するために SendToVRU ノードを使用して別の VRU 転送が必要です。
このシナリオでは、2 つの完全に独立した Unified ICM ルーティング スクリプトが使用されます。2 つのルーティング スクリプト間の唯一のつながりは、最初のルーティング スクリプトから返されたラベルが、2 番めのルーティング スクリプトを起動するためにゲートキーパーが使用する着信番号になることです。この転送はトランスレーション ルートまたは VRU レッグ経由ではなく、2 番めのスクリプトでコール コンテキストは使用できません（ゲートキーパー要求自体に含まれているものを除く）。
GKTMP NIC をコール フローに挿入すると、この方法で処理されるコールごとに追加ルート要求が Unified ICM ルータによって処理されること、および追加のコール詳細レコードが Unified ICM ロガーによって書き込まれることに注意してください。可能な場合は、GKTMP NIC によって提供される追加ルーティング機能を特に必要とするコールだけが Unified ICM への要求 ARQ を生成するように、ゲートキーパーで GKTMP サーバ トリガーを設定します。
フィードバック