Cisco IP Contact Center Enterprise Edition ネットワーク デザイン(SRND) Releases 5.0/6.0

基本的な IPCC コールおよびメッセージのフロー

図1-1は基本的な IPCC コールのフローを示しています。このシナリオでは、コールが着信したときにすべてのエージェントが「受信不可」であるとみなされているため、コールは ICM によって IP IVR にルーティングされます。コールが IP IVR に接続されると、コールのキューイング処理（応答メッセージ、音楽など）が提供されます。エージェントが受信可能になると、ICM が IP IVR に対して、そのエージェントの電話にコールを転送するように指示します。コールの転送と同時に、ICM は Automatic Number Identification（ANI; 発信者番号）や Directory Number（DN; ディレクトリ番号）などの発信者データをエージェント デスクトップ ソフトウェアに送信します。

図1-1 基本的な IPCC コール フロー

図1-1のコール フローは、次のように処理されます。

1. PSTN から音声ゲートウェイへコールが配信される。

2. Cisco CallManager に MGCP または H.323 のルート要求が送信される。

3. ICM に JTAPI のルート要求が送信される。

4. ICM がルーティング スクリプトを実行。対応できるエージェントが見つからず、ルーティング スクリプトは IP IVR のラベルを返す。

5. ICM が Cisco CallManager に対してコールを IP IVR に転送するように指示し、Cisco CallManager はその指示に従う。

6. IP IVR は ICM にコールが届いたことを通知する。

7. ICM は IP IVR に、応答メッセージを再生するように指示する。

8. エージェントが対応可能になる（直前のコールが完了または業務に復帰した）。

9. ICM は選択したエージェントの画面にコールのデータを送信し、IP IVR にはそのエージェントにコールを転送するよう指示する。

10. IP IVR は指定されたエージェントの電話に VoIP 音声パスを転送する。

11. エージェントがコールに応答する。

ICM ソフトウェア モジュール

Cisco ICM ソフトウェアは、複数のサーバ上で稼働可能なモジュールの集合です。1 台のサーバ上で稼働可能なソフトウェアの数は、主に、Busy Hour Call Attempt（BHCA; 最頻時発呼数）および使用されているサーバのサイズ（CPU がシングル、デュアル、クアッドのいずれであるか）によって異なります。ハードウェアのサイジングに影響を与える他の要因としては、エージェントの人数、各エージェントのスキルの数、IP IVR ポートの数、ICM ルーティング スクリプト内の VRU スクリプト ノードの数、およびエージェントがデスクトップで必要とする統計情報エージェントの種類があります。

ICM ソフトウェアのコア モジュールは次のとおりです。

• Router

• Logger

• Cisco CallManager ペリフェラル インターフェイス マネージャ（PIM）

• IP IVR PIM

• CTI サーバ

• アドミン ワークステーション（AW）

Router は、コールまたは顧客からのコンタクトのルーティング方法に関するすべての決定を行うモジュールです。Logger は、コンタクト センターの設定およびレポート データを保存するデータベース モジュールです。Cisco CallManager PIM は、JTAPI プロトコルで Cisco CallManager クラスタとのインターフェイスを処理するモジュールです。IP IVR PIM は、Service Control Interface（SCI）プロトコルで IP IVR/ISN とのインターフェイスを処理するモジュールです。CTI サーバは、IPCC エージェント デスクトップ アプリケーションとのインターフェイスを処理するモジュールです。

ICM の各ソフトウェア モジュールはリダンダント構成で配置できます。モジュールをリダンダント構成で配置する場合、各系統はそれぞれサイド A およびサイド B と呼ばれます。たとえば、Router A および Router B は、2 つの異なるサーバ上で稼働する Router モジュール（プロセス）のリダンダント インスタンスです。このリダンダント モードは「デュプレックス」設定と呼ばれ、非リダンダント プロセスは「シンプレックス」モードで稼働していると言います。プロセスがデュプレックス設定で稼働している場合、ロード バランシングは行われていません。サイドA とサイド B は、両方とも同じメッセージ セットを実行しています。そのため、同じ結果が生成されます。この設定では、論理的には Router は 1 つだけに見えます。

ほとんどの ICM ソフトウェア モジュールは、複数の論理インスタンスをサポートしてスケーラビリティを実現します。複数のインスタンスをサポートしないソフトウェア モジュールは、Router と Logger だけです。Router と Logger を組み合わせてセントラル コントローラと呼ぶことがあります。セントラル コントローラは、IPCC のハブアンドスポーク アーキテクチャのハブに当たります。セントラル コントローラがあることによって、IPCC システムではすべてのエージェントとキューにあるすべてのコンタクトをまとめて 1 つの「エンタープライズ ビュー」で捉えることができます。このエンタープライズ ビューがあることにより、IPCC では複数の場所に配置されたコンタクトとエージェントを単独の論理 ACD で管理することが可能になります。

Router モジュールと Logger モジュールが同一サーバ上で稼働している場合、そのサーバは Rogger と呼ばれます。

IPCC 環境にあるすべての Cisco CallManager クラスタに対して、1 つずつの Cisco CallManager PIM が必要です。各 Cisco CallManager PIM では、その Cisco CallManager クラスタの電話と関連付けられたデスクトップと通信するための CTI サーバを 1 つずつ必要とします。各 IP IVR には、対応する IP IVR PIM が 1 つずつ必要です。Cisco CallManager PIM、CTI サーバ、および IP IVR PIM を稼働させているサーバは、Peripheral Gateway（PG; ペリフェラル ゲートウェイ）と呼ばれます。多くの場合、Cisco CallManager PIM、CTI サーバ、および複数の IP IVR PIM は、同一サーバ上で稼働します。PG 内部は PG エージェントと呼ばれるプロセスで、PG からセントラル コントローラへの通信を行います。PG の内部プロセスとしては、この他に Open Peripheral Controller（OPC; オープン ペリフェラル コントローラ）があります。これは他のプロセスの相互通信を可能にするとともに、リダンダントな PG 配置における各 PG の同期化にも関係しています。図1-2に、さまざまな PG ソフトウェア プロセス間の通信を示します。

図1-2 ペリフェラル ゲートウェイ ソフトウェア プロセス間の通信

より大きな複数サイト（複数クラスタ）の環境では、通常は複数の PG が配置されます。
Cisco CallManager クラスタは、PG と同一サイト上に配置する必要があります。 ICM ソフトウェアの機能により、複数の Cisco CallManager クラスタを配置している場合でもすべてのクラスタが統合された単一のエンタープライズ コンタクト センターとして取り扱うことができ、キューもエンタープライズ全体で 1 つとみなして処理できます。

IPCC エージェント デスクトップ

IPCC エージェント デスクトップ アプリケーションは、エージェントによるエージェントの状態の制御（ログイン、ログアウト、受信可能、受信不可、ラップアップなど）や、コール制御（応答、リリース、保留、復帰、転送、会議、発信など）を可能にするエージェント インターフェイスです。コール制御はすべて、エージェント デスクトップ アプリケーションを使用して実行する必要があります。

エージェント デスクトップには終端メディアとして機能する「ソフトフォン」オプションがあり、これによってハードウェアの IP Phone は不要になります（図1-3を参照してください。エージェント デスクトップのソフトフォン オプションと、Cisco IP SoftPhone などの他のソフトフォン アプリケーションとを混同しないように注意してください）。エージェント デスクトップのソフトフォン オプションを使用する場合、PC にヘッドセットを接続し、この PC で VoIP パケットの符号化/復号化および LAN とのパケット送受信を行います。

図1-3 Cisco Agent Desktop

使用できるエージェントおよびスーパーバイザ デスクトップ オプションは、次の 3 種類です。

• Cisco Agent Desktop。ソフトウェア開発不要のデスクトップです（図1-3に表示）。

• Cisco Toolkit Desktop。CTI Object Server（CTI OS）上に構築されるソフトウェア開発ツールキットです。Cisco Toolkit Desktop は、カスタム デスクトップ、または他のアプリケーション（カスタマー データベース アプリケーションなど）と統合されたデスクトップ用として実装します。

• Cisco Siebel Desktop などの組み込み CRM デスクトップ。Cisco Siebel Desktop は、Siebel デスクトップ アプリケーションに完全に組み込まれている IPCC エージェント デスクトップです。Cisco Siebel Desktop はシスコから提供されます。また他の多数の組み込み CRM デスクトップはシスコのパートナーから入手できます。

エージェント デスクトップの他に、スーパーバイザ デスクトップもこれらの各オプションで使用できます。

「エージェント デスクトップおよびスーパーバイザ デスクトップ」の章で、デスクトップの選択と設計の考慮事項の詳細について説明します。

アドミン ワークステーション

アドミン ワークステーション（AW）は、ICM ソフトウェアの設定を管理する管理ツールの集合を提供します。AW の 2 つの主要な設定ツールは、コンフィギュレーション マネージャとスクリプト エディタです。コンフィギュレーション マネージャ ツールは、ICM データベースを設定して、エージェントの追加、スキル グループの追加、エージェントのスキル グループへの割り当て、ダイヤル番号の追加、コール タイプの追加、ダイヤル番号のコール タイプへの割り当て、コール タイプの ICM ルーティング スクリプトへの割り当てなどを行うために使用します。スクリプト エディタ ツールは、ICM ルーティング スクリプトの作成に使用します。ICM ルーティング スクリプトは、コンタクトのルーティングおよびキューイングの方法を指定します（スクリプトによって、特定のコンタクトを処理するエージェントを指定します）。

これらのツールの使用法の詳細については、次の URL で入手できる『IP Contact Center Administration Guide』を参照してください。日本語マニュアル『Cisco ICM ソフトウェア：IP Contact Center 管理ガイド Release 5.0』については、
http://www.cisco.com/japanese/warp/public/3/jp/service/manual_j/ccs/ipcceo/ipccag/ を参照してください。

http://www.cisco.com/univercd/cc/td/doc/product/icm/ipccente/index.htm

AW は、他の IPCC ソフトウェア モジュールとは別のサーバで稼働させる必要のある唯一のソフトウェア モジュールです。ICM のインストールでは AW の数に上限はなく、ICM セントラル コントローラと同一システム、または別システムのどちらでも配置できます。各 AW はそれぞれ独立しており、複数の AW を配置することで冗長性を実現できます。

ICM セントラル コントローラと直接通信する AW もあり、これらはディストリビュータ AW と呼ばれます。ICM 環境には、ディストリビュータ AW が 1 つ以上必要です。AW（ディストリビュータまたはクライアント）を追加すると、冗長性（プライマリおよびセカンダリ ディストリビュータ）の実現や、サイトの AW クライアントによるアクセス増加も可能になります。他のサイトでも、1 つ以上のディストリビュータとクライアント AW（上限なし）を配置できます。ただし、クライアント AW は常に AW ディストリビュータと同一システム上に配置する必要があります。

クライアント AW はディストリビュータ AW と通信して、ICM セントラル コントローラ データベースの表示と変更、およびリアルタイム レポート データの受信を行います。セントラル コントローラ（リアルタイムのコール処理エンジン）は、ディストリビュータ AW によって、リアルタイムのコンタクト センター データをクライアント AW に常に配布するというタスクから解放されます。

AW は 2 つのソフトウェア オプションでインストールできます。

• Historical Data Server（HDS）

• WebView サーバ

Historical Data Server（HDS）オプションは、履歴レポート データのコピーを作成します。 ディストリビュータ AW は HDS でインストールします。 WebView サーバ オプションは、ブラウザ ベースのレポートを作成します。このオプションを選択すると、ブラウザ機能のあるすべてのコンピュータからレポートを作成できます。 WebView サーバは、HDS を設定されたディストリビュータ AW にインストールします。 WebView サーバを追加すると、ディストリビュータ AW がウェブ サーバに変わります。

AW を本稼働システムと別のサーバで稼働させるのは、複雑なレポーティング クエリーによって、Router や Logger のプロセスのリアルタイム コール処理が中断されないようにするためです。ラボやプロトタイプのシステムの場合は、AW（WebView サーバ オプションを設定された）を Router や Logger と同一のサーバにインストールできます。AW を Logger と同一のサーバにインストールすると、Logger データベースの完全コピーがすでにサーバ上に存在するため、HDS は不要になります。

AW の設計および設定の詳細については、www.cisco.com/jp/ で入手できる ICM 製品オンライン マニュアルを参照してください。

JTAPI 通信

Cisco CallManager と、IPCC や IP IVR などの外部アプリケーション間で JTAPI 通信を行うには、JTAPI のユーザ ID とパスワードを Cisco CallManager 内で設定する必要があります。Cisco CallManager PIM または IP IVR の始動時に、JTAPI のユーザ ID とパスワードを使用して Cisco CallManager にログインします。アプリケーション（Cisco CallManager PIM または IP IVR）によるログイン プロセスによって、Cisco CallManager クラスタとそのアプリケーションとの JTAPI 通信が確立されます。Cisco CallManager クラスタ全体と ICM 間のすべての通信で、1 つの JTAPI ユーザ ID を使用します。各 IP IVR サーバ用には別の JTAPI ユーザ ID も必要です。1 つの Cisco CallManager クラスタと 2 つの IP IVR という構成の IPCC を配置するには、3 つの JTAPI ユーザ ID が必要です。ICM アプリケーション用に 1 つ、2 つの IP IVR 用に 2 つの JTAPI ユーザ ID が必要になるためです。

Cisco CallManager ソフトウェアには、CTI マネージャと呼ばれるモジュールが含まれています。これは、JTAPI 経由で ICM や IP IVR などのアプリケーションと通信するソフトウェアのレイヤです。クラスタ内の各ノードは、CTI マネージャのプロセスのインスタンスを実行できますが、PG 上の Cisco CallManager PIM は、Cisco CallManager クラスタの 1 つの CTI マネージャ（つまり 1 つのノード）とだけ通信します。CTI マネージャのプロセスは、クラスタ内の他のノードと CTI メッセージの受け渡しを行います。たとえば、クラスタのノード 1 に音声ゲートウェイがあり、ノード 2 が CTI マネージャのプロセスを実行して ICM と通信すると仮定します。新しいコールがこの音声ゲートウェイに届き、ICM によってルーティングされる必要があると、ノード 1 はクラスタ内メッセージをノード 2 に送信します。これによってルート要求が ICM に送信され、ICM がコールのルーティング方法を決定します。

各 IP IVR も、クラスタ内の 1 つの CTI マネージャ（またはノード）とだけ通信します。前述の例の Cisco CallManager PIM と 2 つの IP IVR は、それぞれ別の CTI マネージャ（ノード）と通信することも、すべてが同一の CTI マネージャ（ノード）と通信することも可能です。ただし、それぞれの通信では別のユーザ ID を使用します。ユーザ ID によって、CTI マネージャが異なるアプリケーションをどのようにトラッキングするかが決まります。

Cisco CallManager PIM がリダンダント構成の場合、1 つのサイドだけがアクティブになり、Cisco CallManager クラスタと通信します。Cisco CallManager PIM のサイド A とサイド B は、それぞれ異なる Cisco CallManager ノードの CTI マネージャと通信します。IP IVR にはリダンダントなサイドはありませんが、IP IVR には、プライマリ CTI マネージャがアウト オブ サービスのときにクラスタ内の別の CTI マネージャ（ノード）にフェールオーバーする機能があります。フェールオーバーの詳細については、「アベイラビリティを高めるための設計上の注意点」の章を参照してください。

Cisco CallManager と IPCC 間の JTAPI 通信には、次の 3 種類のメッセージ タイプが含まれます。

• ルーティング制御

ルーティング制御メッセージは Cisco CallManager に、IPCC からルーティング方法を要求する手段を提供します。

• デバイスとコールの監視

デバイス監視メッセージは Cisco CallManager に、デバイス（IP Phone）またはコールの状態の変更を IPCC に通知する手段を提供します。

• デバイスとコール制御

デバイス制御メッセージは Cisco CallManager に、デバイス（IP Phone）またはコールの制御方法に関する指示を IPCC から受け取る手段を提供します。

一般的な IPCC コールは、数秒間でこの 3 種類すべての JTAPI 通信を含みます。新しいコールが届くと、Cisco CallManager は ICM に対してルーティング方法を要求します。たとえば、Cisco CallManager が ICM からルーティング応答を受け取ると、Cisco CallManager はエージェントの電話を呼び出してコールをエージェントの電話に配信しようとします。この時点で Cisco CallManager は ICM に、デバイス（IP Phone）が呼び出しを始めたことと、それにともないデスクトップ アプリケーションのエージェント応答ボタンが使用可能になったことを通知します。エージェントが［応答］ボタンをクリックすると、ICM が Cisco CallManager にデバイス（IP Phone）をオフ フックにしてコールに応答するよう指示します。

ルーティング制御の通信を行わせるために、Cisco CallManager は CTI ルート ポイントの設定を要求します。CTI ルート ポイントは特定の JTAPI ユーザ ID と関連付けられ、この関連付けによって、Cisco CallManager はどのアプリケーションがその CTI ルート ポイントにルーティング制御を提供しているかを認識できます。その後で Directory (Dialed) Number（DN; ディレクトリ番号）が CTI ルート ポイントに関連付けられます。DN が、ICM JTAPI ユーザ ID と関連付けられた CTI ルート ポイントに関連付けられ、これによって Cisco CallManager は、その DN にコールが届いたときに ICM にルート要求を送信できます。

IP Phone（デバイス）を監視および制御するためには、Cisco CallManager で IP Phone（デバイス）を JTAPI ユーザ ID に関連付ける必要もあります。IPCC 環境では、IP Phone は ICM JTAPI ユーザ ID に関連付けられています。エージェントがデスクトップからログインすると、Cisco CallManager PIM は Cisco CallManager に、そのデバイス（IP Phone）の監視および制御の開始を許可するように要求します。ログインが行われるまで、Cisco CallManager は ICM にその IP Phone の監視または制御を許可しません。デバイスが ICM JTAPI ユーザ ID に関連付けられていないと、エージェントのログイン要求は失敗します。

IP IVR も同じ JTAPI プロトコルを使用して Cisco CallManager と通信するため、この 3 種類の通信タイプは IP IVR でも発生します。ICM とは異なり、IP IVR はアプリケーションそのものと、監視および制御されるデバイスの両方を提供します。

ICM が監視および制御するデバイスは、物理的な IP Phone です。IP IVR には従来の IVR のような実際の物理ポートはありません。IP IVR のポートは論理ポート（IP IVR アプリケーション サーバ上で稼働する独立したソフトウェア タスクまたはスレッド）で、CTI ポートと呼ばれます。IP IVR の各 CTI ポートは、Cisco CallManager で定義された CTI ポート デバイスにする必要があります。

従来の PBX やテレフォニーのスイッチとは異なり、Cisco CallManager はコールの送信先となる IP IVR ポートを選択しません。その代わり、IP IVR JTAPI ユーザに関連付けられた CTI ルート ポイントに関連付けられた DN にコールを行う必要がある場合、Cisco CallManager は IP IVR に（JTAPI ルーティング制御経由で）、どの CTI ポート（デバイス）でコールを処理するかを確認します。IP IVR に使用可能な CTI ポートがあれば、IP IVR は Cisco CallManager のルーティング制御要求に対して、そのコールを処理する CTI ポートの Cisco CallManager のデバイス ID で応答します。

使用可能な CTI ポートがコールに割り当てられたら、IP IVR ワークフローが IP IVR 内で開始されます。IP IVR ワークフローが承認手順を実行すると、CTI ポート（デバイス）に代わってコールに応答する JTAPI メッセージが、Cisco CallManager に送信されます。IP IVR ワークフローでコールの転送またはリリースが必要になった場合、JTAPI メッセージが再度 Cisco CallManager に、コールに対する処理の内容を指示します。これらのシナリオは、IP IVR が実行するデバイスとコール制御の例です。

発信者が IP IVR と対話しながらコールをリリースすると、音声ゲートウェイは発信者がリリースしたことを検出します。続いて H.323 または Media Gateway Control Protocol（MGCP; メディア ゲートウェイ コントロール プロトコル）で Cisco CallManager に通知し、JTAPI 経由で IP IVR に通知します。音声ゲートウェイが DTMF トーンを検出すると H.245 または MGCP で Cisco CallManager に通知し、CallManager はこれを JTAPI 経由で IP IVR に通知します。これらのシナリオは、IP IVR が実行するデバイスとコールの監視の例です。

CTI ポート デバイスの制御および監視を行わせるためには、Cisco CallManager の CTI ポート デバイスを適切な IP IVR JTAPI ユーザ ID に関連付ける必要があります。150 ポートの IP IVR を 2 つ所有している場合、CTI ポートは 300 あります。CTI ポートの半分（150）を JTAPI ユーザ IP IVR #1 に関連付け、残りの 150 の CTI ポートを JTAPI ユーザ IP IVR #2 に関連付けます。

Cisco CallManager の設定によって、それ自体の IP IVR にコールをルーティングさせることは可能ですが、IPCC 環境での IP IVR へのコールのルーティングは、ICM で行う必要があります（IP IVR が 1 つだけで、すべてのコール要求に IVR の初期処理が必要な場合でも）。これによって、適切な IPCC レポートが保証されます。複数の IP IVR を配置している場合、このルーティング手法によって、ICM は複数の IP IVR 全体にコールの負荷を分散させることが可能です。

ICM ルーティング クライアント

ICM ルーティング クライアントとは、ICM セントラル コントローラにルート要求を送信できるあらゆるものを指します。Cisco CallManager PIM（Cisco CallManager クラスタ全体を表す）や、各 IP IVR/ISN PIM がルーティング クライアントです。ルーティング クライアントは、ルート要求を ICM セントラル コントローラに送信します。ICM セントラル コントローラはこれを受けてルーティング スクリプトを実行し、ルーティング ラベルをルーティング クライアントに返します。リダンダント PIM も論理上は 1 つのルーティング クライアントとみなされるため、アクティブになるのは常に PIM の片方のサイドだけです。1 つの Cisco CallManager クラスタ（ノードの数はいくつでも可）と 2 つの IP IVR という構成の IPCC を配置するには、3 つのルーティング クライアントが必要です。つまり、Cisco CallManager PIM と 2 つの IP IVR/ISN PIM が必要になります。

Public Switched Telephone Network（PSTN; 公衆電話交換網）も、ルーティング クライアントとして機能します。ICM は Network Interface Controller（NIC; ネットワーク インターフェイス コントローラ）と呼ばれるソフトウェア モジュールをサポートします。このモジュールによって ICM は、PSTN によるコールのルーティング方法を制御できます。コールが顧客宅内機器に送信される前にコールをインテリジェントにルーティングすることを、プレルーティングといいます。ICM によってサポートされている NIC を搭載しているのは、特定の PSTN だけです。PSTN NIC の詳細なリストや、ICM プレルーティングの詳細については、次の URL で入手できる標準の ICM 製品マニュアルを参照してください。日本語マニュアルについては、
http://www.cisco.com/japanese/warp/public/3/jp/service/manual_j/index_ccs.shtml を参照してください。

http://www.cisco.com/univercd/cc/td/doc/product/icm/

Cisco メディア ブレンダ、Cisco コラボレーション サーバ、Cisco E-Mail Manager などのその他のアプリケーションもルーティング クライアントとして機能し、ICM を複数チャネルのコンタクト ルーティング エンジンとして動作させることが可能です。現在利用可能な複数チャネル ルーティングの詳細は、cisco.com から入手できます。

デバイス ターゲット

各 IP Phone は、ICM セントラル コントローラ データベースでデバイス ターゲットとして設定する必要があります。ICM デバイス ターゲットとして設定できるのは、IP Phone の 1 つの内線番号だけです。IP Phone には複数の内線を設定することもできますが、2 本目以降の内線は ICM ソフトウェアには認識されないため監視または制御は行われません。ICM はコール処理で Reroute On No Answer（RONA）を実行するため、Cisco CallManager の IP Phone の設定で、無応答時の自動転送を設定する必要がありません。コール センターのポリシーでウォーム（エージェントからエージェント）転送が許可されていない限り、IPCC 内線番号が直接発行またはダイヤルされることはなく、この IPCC 内線番号にコールをルーティングするのは ICM ソフトウェアだけです。

エージェントがログインすると、エージェント ID と IP Phone の内線番号が関連付けられ、この関連付けはエージェントがログアウトすると解放されます。この機能によって、エージェントが他の電話にログインすることや、他のエージェントが同じ電話にログインすることが可能になります。エージェントがログインすると、Cisco CallManager PIM が Cisco CallManager に、その IP Phone の監視を開始し、その IP Phone のデバイス制御とコール制御を行うように要求します。前述のように、エージェントがログインできるようにするには各 IP Phone を ICM JTAPI ユーザ ID に対応させる必要があります。

ラベル

ラベルは、ルーティング クライアントからのルート要求に対する応答です。ラベルは、コールのルーティング先を示すポインタです（基本的に、ルーティング クライアントがダイヤルする番号）。IPCC 環境の多くのラベルが IPCC 内線番号に対応しているため、Cisco CallManager および IP IVR は、コール用に選択されたエージェントの電話に、すぐにコールをルーティングまたは転送できます。

多くの場合、コールがどのように宛先にルーティングされるかは、コールの発信元や終端先によって異なります。そのため IPCC ではラベルを使用します。たとえば、2 つの Cisco CallManager クラスタ（サイト 1 とサイト 2）が別の場所に配置された環境があると仮定します。サイト 1 の IP Phone ユーザがサイト 1 の他の IP Phone ユーザに電話をかける場合は、通常、4 桁の内線番号をダイヤルします。サイト 1 からサイト 2 の IP Phone ユーザに電話をかけるには、ユーザは 7 桁の番号をダイヤルする必要があります。公衆電話交換網の電話からどちらかのサイトの IP Phone ユーザに電話をかけるには、ユーザは 10 桁の番号をダイヤルする必要があります。この例から、コールの発信元と終端先に応じて、どのように異なるラベルが必要になるかがわかります。

デバイス ターゲットとルーティング クライアントのそれぞれの組み合せに、ラベルを付ける必要があります。たとえば、2 つのノードの Cisco CallManager クラスタと 2 つの IP IVR がある IPCC 環境のデバイス ターゲットは、3 つのラベルが必要になります。デバイス ターゲット（IP Phone）が 100 台ある場合は、300 のラベルが必要になります。2 つの Cisco CallManager クラスタが離れた場所にあり、それぞれのサイトに 2 つの IP IVR と 100 のデバイス ターゲットがある場合、6 つのルーティング クライアントと 200 のデバイス ターゲット用に 1200 のラベルが必要です（すべてのルーティング クライアントからすべてのデバイス ターゲットにコールをルーティングできるようにすると仮定した場合）。コールをルーティング クライアントと同じサイトのデバイス ターゲットにだけルーティングする場合は、必要なラベルは 600 です（100 のデバイス ターゲットに対して 3 つのルーティング クライアントで、これをサイト 2 用に 2 倍にした数）。

ラベルは IP IVR CTI ポートにコールをルーティングする際にも使用されます。ラベルの設定の詳細事項は、Cisco.com で入手できる「IPCC インストレーション ガイド」に記載されています。ラベルの設定を容易にする一括設定ツールも利用できます。

エージェント デスク設定

エージェント デスク設定は、自動応答を有効にするかどうか、コールの無応答 (RNA) 時に再ルーティングするまでの待機時間、再ルーティングで使用する DN、ログアウト時や受信不可になる際に理由コードが必要かどうかなどのパラメータを指定するプロファイルを提供します。各エージェントは、ICM の設定でエージェント デスク設定プロファイルと関連付ける必要があります。1 つのエージェント デスク設定プロファイルは、複数のエージェントで共有できます。エージェントのログイン中に、そのエージェントのデスク設定プロファイルを変更しても、その変更内容は、エージェントがログアウトして再度ログインするまで有効になりません。

エージェント

エージェントは ICM 内で設定され、1 つの特定の Cisco CallManager PIM（つまり 1 つの Cisco CallManager クラスタ）と関連付けられます。ICM の設定で、エージェントがログインに使用するパスワードも設定します。

スキル グループ

ICM 内でスキル グループを設定すると、同様のスキルを持ったエージェントをグループ化できます。エージェントは 1 つまたは複数のスキル グループに割り当てることが可能です。エージェントのログイン中に、そのエージェントのスキル グループの関連付けを変更しても、その変更内容は、エージェントがログアウトして再度ログインするまで有効になりません。

スキル グループは特定の Cisco CallManager PIM と関連付けられます。複数の PIM のスキル グループをエンタープライズ スキル グループにグループ化できます。エンタープライズ スキル グループを作成して使用すると、一部のシナリオではルーティングとレポーティングが容易になります。

ディレクトリ（ダイヤル）番号とルーティング スクリプト

Cisco CallManager から ICM にルート要求を送信するには、Cisco CallManager は、ICM JTAPI ユーザに関連付けられた CTI ルート ポイントに DN を関連付ける必要があります。DN は ICM でも設定が必要です。ICM が DN を持つルート要求を受け取ると、その DN は ICM コール タイプに対応付けられ、次に ICM ルーティング スクリプトに対応付けられます。

エージェントのログインと状態の制御

エージェントは、自分の IPCC エージェント デスクトップ アプリケーションから IPCC にログインします。ログインすると、このログイン セッションで使用するエージェント ID、パスワード、および IPCC 内線番号の入力を要求するダイアログ ボックスがエージェントに表示されます。エージェント ID、内線番号（デバイス ターゲット）、エージェント デスク設定プロファイル、スキル、およびデスクトップ IP アドレスは、ログイン時に動的に関連付けられます。この関連付けは、エージェントがログアウトすると解放されます。

トランスレーション ルーティングとキューイング

受信可能なエージェントがない場合は、Router は［Select（選択）］ノードを終了してコールを IP IVR に転送し、キューイング処理を開始します。転送は、［Translation Route to VRU（VRU トランスレーションルート）］ノードを使用することで完了します。［Translation Route to VRU（VRU トランスレーションルート）］ノードは、最初のルーティング クライアントである Cisco CallManager クラスタに一意のトランスレーション ルート ラベルを戻します。このトランスレーション ルート ラベルは、Cisco CallManager で設定された DN と同じになります。Cisco CallManager では、その DN は、コールの転送先である IP IVR の JTAPI ユーザに関連付けられた CTI ルート ポイントに対応付けられています。

Cisco CallManager と IP IVR が JTAPI ルーティング制御メッセージ機能を実行して、使用できる CTI ポートを選択します。

コールが IP IVR に転送されると、IP IVR トランスレーション ルーティング アプリケーションはまず、SCI 経由で IP IVR から ICM に要求指示メッセージを送信します。ICM は、その DN がトランスレーション ルート ラベルと同一であることを確認し、このコールを、以前にルーティングされたコールと再度関連付けできるようになります。その後、ICM は以前このコールに対して実行されたルーティング スクリプトを再度指定します。再指定するポイントは、［Translation Route to VRU（VRU トランスレーションルート）］ ノードから正常に出たパスです。（図1-5を参照してください）。この時点で、ルーティング クライアントは Cisco CallManager クラスタから IPIVR1 に変更されています。

コールが転送されている間、ルーティング スクリプトが一時的に停止されます。IP IVR への転送が完了すると、IP IVR がこのルーティング スクリプトのルーティング クライアントになります。次にルーティング スクリプトが BoatSales スキル グループにコールをキューイングし、［Run VRU Script（VRU スクリプト実行）］ノード経由で特定のキューイング処理を実行するように IP IVR に指示します。エージェント 111 が受信可能になると、前述の例で説明したように、ルーティング クライアントに戻されるラベルは、デバイス ターゲットとルーティング クライアントの組み合わせに基づいて特定されます。これで IP IVR がルーティング クライアントになりました。エージェント 111 が受信可能になったときに戻されたラベル（1234）によって、IP IVR はコールをエージェント 111（内線番号は 1234）に転送します。

図1-5 トランスレーション ルーティングとキューイング

Cisco CallManager クラスタと IP IVR の各組み合せには、トランスレーション ルートとラベルのセットが必要です。たとえば、Cisco CallManager クラスタが 1 つと IP IVR が 4 つある配置の場合、4 つのトランスレーション ルートと数セットのラベルが必要です。

IP IVR が複数ある配置の場合、ICM ルーティング スクリプトでアイドル状態の IP IVR ポートの数が最も多い IP IVR を選択して、その IP IVR にコールをトランスレーション ルーティングする必要があります。使用可能な IP IVR ポートがない場合は、スクリプトは［Busy（ビジー）］ノードを実行します。［Busy（ビジー）］ノードを実行しているコールの数が多い場合は、IP IVR ポートのキャパシティのサイズを変更する必要があります。

Reroute On No Answer（RONA）

コールがエージェントにルーティングされた後、指定した時間内にそのエージェントがコールに応答しなかった場合、応答しなかったエージェントの Cisco CallManager PIM はそのエージェントの状態を「受信不可」に変更して（このエージェントがこれ以上コールを受け取らないように）、他のエージェントを見つけるためにルート要求を送信します。コール データはすべて保存され、次のエージェントのデスクトップに表示されます。受信可能なエージェントがいない場合、コールは IP IVR に戻され、再度キューイング処理が実行されます。ここでもコール データはすべて保存されます。この RONA 処理のルーティング スクリプトは、呼優先度を「高」に設定して、次に受信可能になったエージェントがこの発信者に割り当てられるようにする必要があります。エージェント デスク設定では、RONA タイマーと、RONA 処理のための一意のコール タイプとルーティング スクリプトの指定に使用される DN を設定できます。

ダイヤル番号計画

その後、Cisco CallManager PIM はダイヤル番号をダイヤル番号計画のエントリと対応させようとします。ICM Dialed Number Plan（DNP; ダイヤル番号計画）は現在、ICM アドミン ワークステーション（AW）の Bulk Configuration ツールによって管理されています。DNP のエントリはペリフェラル（PIM）ごとに入力されており、特定の PIM のすべての DNP エントリは PIM の始動時に PIM にダウンロードされます。DNP への変更や追加も PIM に動的に転送されます。これらの設定はただちに有効になり、次に転送されたコールに使用されます。ICM が転送をルーティングし、すべてのコール データを転送とともに移動させて、コールが発生してから完了するまでの全体のレポート用に保存するためには、ダイヤル番号に一致するエントリが、エージェントが現在ログインしている PIM の DNP で見つかる必要があります。

DNP 内では、ダイヤル番号文字列のファジー（ワイルドカード）マッチングが可能です。DNP は、ICM Router が使用する、AW コンフィギュレーション マネージャ ツールで管理されているダイヤル番号表とは異なります。ICM Router はダイヤル番号をコール タイプに対応させます。コール タイプは ICM ルーティング スクリプトに対応しています。このようにして、特定のダイヤル番号は ICM Router のルーティング スクリプトに対応付けられます。ダイヤル番号、コール タイプ、およびルーティング スクリプトの編集の管理に関する詳細については、次の URL で入手できる『IP Contact Center Administration Guide』を参照してください。日本語マニュアル『Cisco ICM ソフトウェア：IP Contact Center 管理ガイド Release 5.0』については、
http://www.cisco.com/japanese/warp/public/3/jp/service/manual_j/ccs/ipcceo/ipccag/ を参照してください。

http://www.cisco.com/univercd/cc/td/doc/product/icm/ipccente/index.htm

特定の IPCC 配置のダイヤル プランの設計については、シスコシステムズのエンジニア（SE）に問い合せてください。

ダイヤル プラン タイプ

ダイヤル番号計画のエントリは、ダイヤル プラン タイプとともに設定する必要があります。リスト ボックスから事前定義された DNP タイプは 6 種類あり、これらはエージェント デスク設定プロファイルで指定されたタイプに対応します。コールまたは転送を先に進めるには、そのコールの DNP タイプが、転送元のエージェントが使用しているエージェント デスク設定プロファイルで許可されている必要があります。Cisco CallManager のコーリング サーチ スペースはデスクの設定に優先されるため、エージェント デスク設定ですべてのダイヤル プラン タイプを許可しておくことをお勧めします。

（注） エージェント デスク設定プロファイルに対する変更は、エージェントがログアウトして再度ログインするまで有効になりません。

ポスト ルート

ダイヤル番号計画のエントリは、ポスト ルートが必要かどうかも示すように設定する必要があります。シスコでは、転送のシナリオでダイヤル番号を使用する場合は、転送のポスト ルート オプションを [Yes] に設定することをお勧めします。このフィールドを [Yes] に設定する場合、ルート要求に使用されるダイヤル番号を、Dialed Number Plan Editor の [Dialed Number] カラムに入力する必要があります。

ルート要求

転送の DNP で一致するエントリが見つかり、その DNP タイプが転送元のエージェントで許可されている場合、ポスト ルート オプションが [Yes] に設定されていれば、PIM のロジックは、この同一 DNP エントリに指定されているダイヤル番号を使用して、ICM セントラル コントローラにルート要求を送信します。

ルート要求を受け取ると、ICM Router はダイヤル番号をコール タイプに対応させ、適切なルーティング スクリプトを実行して、そのコールに適したターゲット エージェントを見つけます。ルーティング スクリプト内では、それまでに収集したすべてのコール データを、コールのインテリジェント ルーティングに使用できます。ICM Router は、エージェントがログインしているデバイス ターゲット（内線電話およびデスクトップ）を判別し、そのデバイス ターゲットを示すラベルを Cisco CallManager PIM に返します。

この時点では、実行している転送のタイプに応じて、次のセクションで説明するようなさまざまなシナリオが考えられます。

• 「シングル ステップ（ブラインド）転送」

• 「コンサルテイティブ転送」

シングル ステップ（ブラインド）転送

ブラインド転送は、転送元のエージェントがターゲット エージェントと会話する必要がない場合に使用します。エージェント デスクトップの［転送］ダイアログ ボックスでブラインド転送を指定した後、転送元のエージェントは DN を入力して、［転送開始］ボタンをクリックします。デスクトップから Cisco CallManager PIM に転送要求が送信されます。DNP で一致するエントリが見つかり、DNP タイプが有効で、ポスト ルートが選択されていれば、Cisco CallManager PIM はルート要求を送信してルーティング ラベルを取得し、その後で Cisco CallManager に、シングル ステップ転送を実行する（転送元のエージェントのこれ以上のアクションを必要とせずに）ように指示します。転送元のエージェントのデスクトップからコールが消え、転送元のエージェントのエージェント デスク設定に応じて、各エージェントは次のエージェントの状態（ラップアップ、受信可能、または受信不可）に移行します。コールがターゲット エージェントに発信されている間、最初の発信者は一時的に保留状態になります。ターゲット エージェントの電話が呼び出しを始めると、最初の発信者には呼び出し音が聞こえます（自動応答が有効になっていない場合）。ターゲット エージェントのデスクトップには、すべてのコール データを含んだスクリーン ポップが表示され、電話が呼び出しを始めると、エージェント デスクトップの［応答］ボタンが有効になります。ターゲット エージェントはコールに応答して最初の発信者と会話し、これで転送は完了します。ターゲット エージェントが応答しない場合は、RONA（Reroute On No Answer）コールの再ルーティング ロジックが後の処理を引き継ぎます。

自動応答が有効になっている場合は、最初の発信者とターゲット エージェントには呼び出し音は聞こえません。そのまま最初の発信者とターゲット エージェントの間でコールが接続されます。

エージェントがコールをスキルグループに割り当てられた番号に転送して、特定のスキルを持つ受信可能なエージェントを探しますが、現在適切なエージェントが受信可能でない場合、ICM ルーティング スクリプトを設定して、キューイング処理を行う IP IVR にコールをトランスレーション ルーティングする必要があります。コールはほぼ瞬時に転送元のエージェントのデスクトップからリリースされます。転送元のエージェントが収集したすべてのデータが、自動的に IVR に渡されます。IP IVR CTI ポートがすぐに応答するため、発信者にリングバック トーンは聞こえません。ターゲット エージェントが受信可能になると、ICM は IVR にコールを転送するように指示し、ICM はエージェント デスクトップにすべてのコール データを表示させます。

エージェントが、ICM ダイヤル番号計画に存在しない番号にコールを転送した場合でも、発信者は転送されます。転送されたコールの宛先は、ダイヤルされた番号と、Cisco CallManager ダイヤル プランでの設定によって異なります。エージェントのローミングの制約事項や、コール データがコールに付随しないこと、レポーティングの制約などの理由から、ダイヤル番号計画を使用しない転送は推奨されていません。

コンサルテイティブ転送

コンサルテイティブ転送のメッセージ フローの一部は、ブラインド転送のメッセージ フローに似ています。Cisco CallManager PIM が、コールの転送先を示すラベルを ICM Router から受け取ると、Cisco CallManager PIM は Cisco CallManager に、コンサルテイティブ転送をラベルに指定された番号に発信するように指示します。Cisco CallManager は最初の発信者を保留にして、ラベルに指定された番号にコンサルテイティブ コールを発信します。多くの場合、転送が完了するまで、発信者には保留音が聞こえます。

ターゲット エージェントの電話が呼び出しを始めると、Cisco CallManager は Consult Call Confirmation メッセージと Device Ringing メッセージを送信します。

Consult Call Confirmation メッセージを受け取ると、Cisco CallManager PIM は転送元のエージェントのデスクトップにコールが転送されていることを通知し、これによって [Transfer Complete] ボタンが有効になります。転送元のエージェントにターゲット エージェントの電話の呼び出し音が聞こえます（ターゲット エージェントの自動応答が有効になっていない場合）。この後、エージェントが [Transfer Complete] ボタンをクリックすると、転送が完了します（ターゲットが電話に応答する前でも後でも可）。

Device Ringing メッセージを受け取ると、Cisco CallManager PIM はターゲット エージェントのデスクトップにコール データを表示し、これによって［応答］ボタンが有効になります（自動応答が有効になっていない場合）。ターゲット エージェントが［応答］ボタンをクリックする（または自動応答が起動する）と、転送元のエージェントとターゲット エージェントの間に音声パスが確立されます（転送元のエージェントが [Transfer Complete] ボタンをクリックしなかった場合）。

通常、ターゲット エージェントが応答する前に、転送元のエージェントが [Transfer Complete] ボタンをクリックすることはありません。エージェントがコンサルテイティブ転送を使用したのは、転送が完了する前にターゲット エージェントと会話をする必要があるためだと考えられるからです。ただし転送元のエージェントは、[Transfer Complete] ボタンが有効になれば、いつでもこのボタンをクリックできます。

エージェントがコールをスキル グループに割り当てられた番号に転送して、特定のスキルを持つ受信可能なエージェントを探しますが、現在適切なエージェントが受信可能でない場合、ICM ルーティング スクリプトを設定して、キューイングを行う IVR にコールをルーティングする必要があります。このシナリオでは、転送元のエージェントに IP IVR の応答メッセージが流れます。転送元のエージェントは、いつでも [Transfer Complete] ボタンを押して、転送を完了させることが可能です。転送を完了させると、発信者に IP IVR の応答メッセージが流れます。適切なスキルを持つエージェントが受信可能になると、IP IVR はこのターゲット エージェントにコールを転送し、そのエージェントの画面にすべてのコール データを表示させます。

エージェントが、ICM ダイヤル番号計画に存在しない番号や、Cisco CallManager で有効でない番号にコールを転送した場合、転送元のエージェントにコンサルテイティブ コールが失敗した音が聞こえ、「再接続」のセクションで説明するように、最初の発信者に再接続できるようになります。

再接続

コンサルテイティブ転送の consultation leg の間、転送元のエージェントは発信者と再接続して、 consultation call leg をリリースできます。この操作は、エージェントが［再接続］ボタンをクリックするだけで行えます。この操作でエージェント デスクトップから Cisco CallManager PIM に対して指示が出され、その指示を受けて Cisco CallManager PIM が Cisco CallManager に、consultation call leg をリリースして、エージェントを最初の発信者に再接続するように指示します。

これは基本的に、コンサルテイティブ コールを発信しても転送を完了するつもりがないという場合に、エージェントが使用するプロセスです。コールの再接続が成功すると、転送元のエージェントのデスクトップの機能は、この転送を再要求する前とまったく同じになります。そのため、転送元のエージェントはその後で他の転送を要求することが可能で、1 人のエージェントが発信できるコンサルテイティブ コールの数に上限はありません。

コンサルテイティブ転送と再接続は、すべてのエージェント デスクトップから行われ、IPCC と関連付けられている 1 つの Cisco CallManager 内線を使用します。IPCC システムは、転送元のエージェントが最初の発信者を保留状態にして、ハードウェアの電話の 2 つ目の内線を使用してコンサルテイティブ コールを発信する機能はサポートしません。ハードウェアの電話には、こうした転送を可能にするボタンがありますが、IPCC 環境ではサポートされません。エージェントがこの方法でコールを転送すると、ICM によるコールのルーティングは行われないため、すべてのコール データは失われます。

切替

切替は、エージェントが consultation call leg を保留状態にして、コンサルテイティブ転送の最中に最初の call leg に復帰できる機能です。その後、エージェントは、最初の発信者を再度保留状態に戻して、consultation call leg に復帰できます。エージェントは何度でもコールを切り替えられます。

転送元のエージェントが最初の発信者に戻った場合、有効になるコール コントロール（ボタン）は、［切断］と［切替］だけです。［転送］（完了）コントロールと［再接続］ コントロールは使用できません。［切替］コントロールを押すと、転送元のエージェントはコンサルト会議の通話に戻ります。エージェントが consultation leg に戻った場合、［切断］、［切替］、［転送］、および［再接続］のコール コントロールが有効になります。［切替］コントロールを押すと、転送元のエージェントは最初の発信者との通話に戻ります。［転送］コントロールを押すと転送が完了し、［再接続］ボタンを押すとコンサルト会議が終了して、エージェントは最初の発信者に再接続されます。

ICM 以外の転送

DNP に存在しない番号や、ポスト ルートを [No] に設定している DNP で設定されている番号への転送は可能ですが、そのコールは ICM によってルーティングされていることにはなりません。これらのシナリオでは、PIM はただコールの転送要求を直接 Cisco CallManager に送信して、エージェント デスクトップの［転送］ダイアログボックスにあるダイヤル番号を使用します。ICM がコールをルーティングしないと、コール データは失われます。シスコでは、転送のすべてのダイヤル番号を DNP のエントリと一致させ、ポスト ルートを可能にし、このダイヤル番号の DNP タイプを転送元のエージェントで許可しておく（エージェント デスクの設定に基づいて）ことをお勧めします。

エージェント間の転送

転送が特定のエージェント宛ての場合、その転送を要求するエージェントは、［転送］ダイアログ ボックスにエージェント ID を入力する必要があります。ダイヤル番号（エージェント ID）に一致する DNP エントリの DNP タイプは、PBX と一致することが必要です。これによって PIM は、ICM Router にルート要求を送信する前に、ダイヤル番号（エージェント ID）を［発信者入力番号］フィールドに入力します。スクリプト エディタで、エージェント間ルーティング ノードを使用して、エージェント ID の場所として［発信者入力番号］フィールドを指定します。これによって ICM Router はこのコールを正しくルーティングします。

エージェント ID は、Cisco CallManager クラスタのいずれの内線にも一致しません。すべてのエージェント ID が同じ番号で始まり、長さもすべて同じ場合、すべてのエージェント ID に一致する一般的なワイルドカード文字列を設定できるため、エージェント間のルーティングに必要な DNP のエントリは 1 つだけです。

環境に複数の PIM が存在する場合は、エージェント ID 番号プランを使用して、このエージェントを含む PIM を見つける必要があります。エージェント ID はそれだけでは一意ではありません。エージェント ID は特定の PIM と関連付けられ、他の PIM での再利用が可能です。企業全体でエージェント ID を重複させず、一貫性のあるエージェント ID の割り当てプラン（PIM 1 のエージェント ID はすべて 1 で始まり、PIM 2 のエージェント ID はすべて 2 で始まるなど）を設定することで、スクリプト エディタの［発信者入力番号］フィールドを解析して、そのエージェントを含む PIM を見つけることが可能になります。解析は、スクリプト エディタの一連の「if」ノードや、「route select」ノードで行えます。エージェント間のノードでは、PIM を指定する必要があります。

ターゲット エージェントが受信可能状態でない場合、エージェント間のスクリプト エディタ ノードによって、そのコールの代替ルーティングが可能になります。

IVR から特定のエージェントへの転送

多くのコンタクト センターでは、注文番号などの情報を発信者に求め、その注文番号を処理しているエージェントにそのコールをルーティングする必要があります。IPCC では、Router にデータベース検索を行わせ、ペリフェラルの変数フィールドのいずれかにエージェント ID を入力し、エージェント間スクリプト エディタ ノードを使用してコールをその特定のエージェントにルーティングすることで、この処理を可能にします。エージェント間ノードは、IVR がエージェント ID を入力した［ペリフェラル変数］フィールドのエージェント ID 値を探すように設定されている必要があります。複数の PIM が存在する場合、前のセクションで説明したのと同じ設定が必要になります。

このタイプのシナリオは、発信者に特定のエージェント ID を求めて、そのエージェント ID に発信者をルーティングする場合にも使用できます。

転送レポーティング

コールの転送が完了すると、最初の call leg の呼詳細レコードが存在し、さらに新しい call leg 用に新しいコールの詳細レコードが開かれます。この 2 つのコール レコードは、ICM が割り当てた共通のコール ID によって、互いに関連付けられます。転送が完了する前の、consultation call leg の継続時間は、転送元のエージェントの通話時間とみなされます。

詳細については、Cisco.com で入手できるオンライン マニュアル「IPCC レポーティング ガイド」を参照してください。

転送の組み合せまたは複数の転送

コンサルテイティブ転送において、転送を受けたエージェントはそのコンサルテイティブ コールをさらに別のエージェントに転送できます。その後、転送元のエージェントが [Transfer Complete] ボタンを押すと、最初の発信者は 2 番目の転送先エージェントに接続されます。

コールは正常に転送されると、再度転送することが可能です。call leg ごとの呼詳細レコードが ICM に生成され、call leg の通話時間は、そのコールを受け取ったエージェントに関連付けられます。すべての呼詳細レコードは、ICM が割り当てた共通のコール ID によって、互いに関連付けられます。これによって、コールが発生してから完了するまでの全体のレポーティングが行えます。

会議コールの転送

エージェントによって会議が設定されると、会議の参加者がリリースされても、転送は有効な操作ではなくなります。

PSTN 転送（Takeback N Transfer、または転送接続）

多くの PSTN サービス提供会社は、ネットワーク ベースの転送サービスを提供します。これらのサービスは通常、一連の DTMF トーンを発信する Customer Premises Equipment（CPE; カスタマー宅内機器）によって呼び出されます。PSTN は、これらのトーンを検出して、検出したトーンに基づく特定のロジックを実行するようにプロビジョニングされています。一般的な発信シーケンスは、*827500 のようになります。この DTMF 文字列は、「このコールをサイト 2 に転送して、コールをサイト 2 に送信する際の DNIS 値として 7500 を使用する」という内容を意味します。IPCC には、これらのタイプの転送を呼び出す機能があります。

ゲートキーパーによる制御

ゲートキーパー制御は、ゲートキーパーとして動作する独立したエンティティがある場合の方法です。ゲートキーパー制御モデルは、分散コール処理の配置に使用されます。ゲートウェイまたはインタークラスタ トランクからコールを送信する前に、Cisco CallManager はゲートキーパーに、コールが WAN を通過して他のサイトに到達できるだけの帯域幅があるかどうかをたずねます（図1-6を参照してください）。

図1-6 分散コール処理モデルの重要な部分

ゲートキーパーがコールを拒否した場合、Cisco CallManager はダイヤルされた番号を操作して、このコールを透過的に PSTN に送信できます。

IPCC では、ゲートキーパーが WAN へのコールの送信を拒否した場合の代替ルートと番号操作を、ダイヤル プランで定義しておく必要があります。こうした事前定義が重要なのは、コールはルーティング クライアント（CTI デスクトップ、IVR、または CTI ルート ポイント）経由でエージェントと IVR に送信されますが、これらはコールを切ったり、リダイヤルしたりできないためです。そのため、発信者はビジー トーンを受信し、ペリフェラル ターゲット（エージェントまたは IVR）にルーティングされません。

コールを PSTN に送信することの欠点は、2 つのポートが使用されることです。コールは音声ゲートウェイ ポート経由でメイン サイトまたはブランチ サイトに出入りする必要があり、その後にコールがネットワーク内の他のサイトの他のエージェントまたは IVR ポートに転送されると、ポートが使用されたままになるためです。

ゲートキーパーは、コール センターのトラフィックが通過できる十分な帯域幅を提供できるように設定する必要があります。必要となる帯域幅の総量は、PSTN からの着信トラフィックが WAN を使用してルーティングされるかどうか、または WAN がサイト間の転送やエージェント間の会議に使用されるかどうかによって異なります。

Location による制御

中央コール処理の配置では、Location の制御モデルが使用されます。このモデルでは、Cisco CallManager（ゲートキーパーでなく）が、コールの送信に十分な帯域幅が WAN で使用可能かどうかを判断します。十分な帯域幅がない場合、コールは失敗します。PSTN への透過的なフェールオーバーは、Location に基づくコール アドミッション コントロールでは使用できません（図1-7を参照してください）。

図1-7 中央コール処理モデルの重要な部分

IPCC では、帯域幅が不十分なためにコールが失敗した場合、コールは IVR または CTI デスクトップ アプリケーションによってルーティングされるため、発信者はビジー トーンを受信します。またルーティング クライアントがコールを切断してリダイヤルするメカニズムはありません。

そのため、各ブランチ オフィスの帯域割り当てを適切に計算することが重要です。各ブランチへの同時コール数は計算する必要があります。サイト間の転送と会議の状況も、通常のオフィス トラフィックと同様に考慮する必要があります。エージェントの電話を Cisco CallManager の Location の設定内で 1 つの「Location」として割り当て、オフィスの従業員の電話関連のトラフィックが、コール センターのトラフィックに割り当てられた帯域幅に影響を与えることがないようにすることが理想です。