この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
IPCC は、顧客の要件に基づいて複数の方法で設定できます。この章に示す設定は、IPCC 設定のサンプルを表しています。設定例に基づいて、実際の IPCC の設定を決定できます。
(注) Cisco Architecture for Voice、Video、and Integrated Data(AVVID)および CallManager ネットワーク設計に関する特定の情報は、『Cisco AVVID IP Telephony Network Design Guide』を参照してください。
IPCC とともに従来の ACD およびレガシー電話も存在する場合がありますが、これらは Cisco IPCC アーキテクチャには含まれません。従来の ACD では ACD ペリフェラル ゲートウェイ(たとえば Aspect や Nortel 用)を使用している場合があります。ACD PG および IPCC コンポーネント(つまり、CallManager PG や IVR PG など)は、すべて同じ LAN 上にインストールでき、同じ ICM セントラル コントローラを共有できます。
単一のサイトの設定では、コンタクト センター サイトに従来の ACD の代わりに IPCC を使用します。単一のサイトの設定は、一般に顧客が複数の地理的に分散したコンタクト センター サイトに接続する必要がない場合に使用されます。
IPCC を使用すると、コールはVOIP ゲートウェイでターミネートし、IP IVR または CallManager に送信されます。IP IVR または CallManager に着信する各コールについて、関連付けられた PG でポストルーティング リクエストが生成され、生成されたリクエストは ICM セントラル コントローラに転送されます。ICM ソフトウェアからの応答でコールの宛先またはコールの処置が戻されます。オプションで、コールを従来のTDM IVR でターミネートすることもできます。この場合、ポストルーティング リクエストは Cisco IVR PG によって生成されます。図 2-1 は、単一のサイトの IPCC 設定のサンプルを示しています。
(注) わかりやすくするために、図 2-1 では IPCC コンポーネントは個別のマシンの上に示されています。実際の設定では必ずしもこのようにはなりません。たとえば、CTI サーバは、通常、PG と同じプラットフォームで実行されます。CallManager PG および IP IVR ペリフェラル インターフェイス ソフトウェアは、同じハードウェア プラットフォームにインストールされる場合があります。
この設定では、すべての IPCC コンポーネントが同じ物理サイトに配列されます。IPCC ノードは、ICM のビジブル LAN 上の 1 つ以上のコンピュータに分散されます。次に示すように、単一のサイトの設定には、複数の設計上の特性があります。
• 配列された ICM セントラル コントローラ。図 2-1 では、二重 ICM セントラル コントローラの両側が、CallManager、IP IVR、およびエージェント電話と同じサイトに配置されています。サイトにあるその他の PG(たとえば従来の ACD)でも、同じ ICM セントラル コントローラを共有できます。オプションで、ICM セントラル コントローラの一方の側をリモート サイトに配置することもできます。単一のサイトの ICM セントラル コントローラの設定には、ICM ソフトウェアのフォールト トレラント アーキテクチャに関連したいくつかの制限があります。具体的には、ICM セントラル コントローラの両側が同じサイトに配置されるため、火事や洪水のような自然災害が発生した場合は、システムの両側がサービス不能になります。
(注) 可能な ICM セントラル コントローラ設定およびフォールト トレランスの詳細は、『ICM Software Pre-installation Planning: Network and Site
Requirements』を参照してください。
これは単一のサイトの設定であるため、ICM NIC は 必要ありません 。この設定では、ICM ソフトウェアによるコールのプレルーティングは行われません。単一のサイトの IPCC コンタクト センターでは、すべてのコールが同じサイトでターミネートするため、一般にプレルーティングは必要ありません。
• Peripheral Gateways(PG; ペリフェラル ゲートウェイ)。コールを処理する各 CallManager クラスタに、ICM ソフトウェアと通信するための CallManager Peripheral Interface Manager(PIM; ペリフェラル インターフェイス マネージャ)が必要です。たとえば、図 2-1 では 2 つの CallManager でコールが処理されており、一方はバックアップとして機能します。ただし、いずれも単一のクラスタであるため、CallManager PG は 1 つしか必要ありません。フォールト トレランスを確保するために、冗長な CallManager PG が配置されています。A の側と B の側の CallManager PG は、クラスタ内の独立した CallManager 上の CTI Manager プロセスと通信します。
IPCC に実装された各 IP IVR には IP IVR Peripheral Interface Manager(PIM; ペリフェラル インターフェイス マネージャ)が必要です。IP IVR PIM は、専用のプラットフォームにインストールするか、または CallManager PG などの別の PG プラットフォームにインストールできます。わかりやすくするために、図 2-1 は、1 つの IP IVR PG 兼 PIM で 1 つの IP IVR をサポートする例を示しています。この PG は、他の PG と同様に二重化されています。1 つの CallManager は最大 4 つの IP IVR に接続できます。1 つの IP IVR は複数の CallManager で共有できます。
図 2-1 に示されている PG は二重設定になっています。この設定では、コンピュータの障害やネットワーク接続の問題が発生した場合にフォールト トレランスが確保されます。単一の PG の設定は、低コストで基幹業務以外のアプリケーションにだけ使用されます。二重 PG 設定では、各 PG に二重化された対(たとえば CallManager PG1A、その二重パートナーとしての CallManager PG1B)があります。B 側の PG は、ICM の B 側のビジブル LAN 上に配置されます。二重 PG ペアの間には、別個のプライベート ネットワーク接続が必要です(PG のフォールト トレランスの詳細は、この章の「フォールト トレランス」を参照してください)。
• CTI サーバ。エージェントのデスクトップ アプリケーションに ICM インターフェイスを提供するために、少なくとも 1 つの CTI サーバが IPCC サイトに必要です。CTI サーバは、CTI ゲートウェイと呼ばれる専用マシン上で稼動するか、または CallManager PG か IP IVR PG プラットフォームにインストールできます。CTI サーバも二重化できます。
• CTI OS サーバ。CTI OS は、CTI アプリケーションを導入するための、高パフォーマンス、スケーラブル、かつフォールト トレラントなサーバベースのソリューションであり、このようなアプリケーションの統合のシングル ポイントとして動作します。CTI OS は CTI サーバのクライアントです。CTI OS では、Cisco CTI サーバへのすべてのイベントが 1 つの接続を通過します。CTI OS では、セッション インターフェイス、エージェント インターフェイス、およびコール インターフェイスを使用してクライアント接続を順に受け付けます。図 2-1 では、二重 CTI-OS サーバも CallManager PG とともに配列されています。
• CallManager。IPCC サイトにある単一の CallManager または CallManager クラスタでは、IP Phone に従来の PBX テレフォニー機能が提供されています。図 2-1 は、単一の CallManager クラスタを示しています。その他の CallManager クラスタもこのサイトにインストールできます。
CallManager クラスタでは、最大 8 台のサーバが使用されます。CallManager サーバは、主なコール処理用に 4 台、バックアップ コール処理用に 2 台、データベース パブリッシャ用に 1 台、および TFTP サーバ用に 1 台が使用されます。同時に 4 台以上の CallManager サーバがコールを処理することはできません。冗長性を持たせるために、スキル セットはこれらの CallManager に分散されています。1 つの CallManager に障害が発生しても、バックアップ CallManager のエージェントによって呼処理が引き継がれます。
(注) CallManager の設定および CallManager クラスタの設定の詳細は、『Cisco AVVID IP Telephony Network Design Guide』を参照してください。
• IP Phone および PSTN。IP Phone およびエージェント デスクトップ システムは、ICM LAN に接続されます。2 つの IP アドレスが必要です。1 つは IP Phone 用、もう 1 つはデスクトップ システム用です。Cisco IP Phone では、すべての IP Phone コールで G.711 または G.729 がサポートされています。音声の品質を保つには、最低で 2 つのキューで Cisco LAN スイッチを使用してください。IP Phone を使用するには、電話 1 通話あたり 80 Kbps のネットワーク帯域幅が必要です。Digital Signal Processing(DSP; デジタル シグナル プロセッシング)リソースを介して、会議通話がサポートされています。すべての外部コールは PSTN を経由します。
• Voice Over IP ゲートウェイ。単一のサイトの設定では、少なくとも 1 つの VoIP ゲートウェイが必要です。PSTN とのインターフェイスをとる設定では、PRI ベースのゲートウェイが必要になります。
• IVR およびキュー ポイント 。IPCC 設定にインストールした各 IVR には IVR PG が必要です。顧客が適切な電話番号をダイヤルすると、コールはネットワークを介して顧客施設の CallManager に直接配信されます。指定した DNIS に着信するコールを顧客施設の IVR に転送するように、CallManager をプログラムできます。使用する IVR は、Cisco IP IVR、または IVR ベンダーから供給される Cisco サービス制御インターフェイスをサポートする別の IVR とすることができます。
IVR は、IPCC システム内のキュー ポイントとして使用します。この場合は、キュー ポイント IVR PG から ICM CallRouter に、特定の DNIS 値および ANI 値を持つコールが着信したことが通知されます。CallRouter では、宛先エージェントを選択する前にコールが処置されます。たとえば、IVR で 1 件以上のアナウンスメントが再生されたり、番号が収集されます。適切なエージェントが応答可能になると、CallRouter は、IVR に対して、選択されたエージェントにコールを転送するように(キュー ポイント PG を介して)指示します。次に、IVR では、CallManager に対して適切な手順が発行され、選択したエージェントにコールが転送されます。同時に、CallRouter では、
CallManager PG に対してコールを転送中であることが通知されます。
マルチサイトの IPCC 設定は IPCC アーキテクチャの柔軟性を表します。この設定は、地理的に分散しているコンタクト センターをグループ化する場合に使用します。フォールト トレランスを強化するために、ICM コンポーネントも地理的に分散されます。図 2-2 に示されているマルチサイト設定では、それぞれが 1,000 エージェントをサポートする 3 つの CallManager クラスタが結合されています。
図 2-2 ネットワーク コールに PSTN を使用するマルチサイト設定
この設定では、地理的に分散したコンタクト センター サイトに IPCC コンポーネントが配置されます。PSTN は、サイト間のネットワーク コールに使用します。この設定では、ICM セントラル コントローラは一般に二重化され、地理的に分散されます(つまり、セントラル コントローラの A の側があるサイトに配置され、B の側が別のサイトに配置されます)。ICM セントラル コントローラ サイトには、1 つ以上の CallManager または CallManager クラスタ、IVR、IP Phone 、および関連する ICM PG および CTI サーバが含まれています。次に示すように、この設定には、複数の設計上の特性があります。
• サポートされるサイト数。IPCC では、図 2-2 に示されている PSTN 設定のマルチサイトでサポートするコンタクト センター サイトの数に固定の制限はありません。たとえば、このタイプの設定では、40 以上のサイトを設置できます。ただし、IPCC 設定で配置できる Peripheral Gateways(PG; ペリフェラル ゲートウェイ)の数は最大 80 です。
• ペリフェラル ゲートウェイおよび NIC。コールを処理する各 CallManager クラスタに、ICM ソフトウェアと通信するための ICM CallManager の Peripheral Interface Manager(PIM; ペリフェラル インターフェイス マネージャ)が必要です。
IPCC に実装された各 IP IVR には ICM IP IVR Peripheral Interface Manager(PIM; ペリフェラル インターフェイス マネージャ)が必要です。IP IVR PIM は、通常、専用の PG プラットフォームにインストールします。わかりやすくするために、図 2-2 は 1 つの IP IVR PG を示しています。この PG も、他の PG と同様に二重化できます。図 2-2 は、PG および NIC を単一として示しています。ただし、通常、これらのコンポーネントは二重化されます。
(注) 可能なペリフェラル ゲートウェイ設定およびフォールト トレランスの詳細は、『ICM Software Pre-installation Planning: Switch Preparation』を参照してください。また、このマニュアルの第 3 章「フォールト トレランス」では、PG のフォールト トレランスを詳細に説明します。
• CTI サーバ。エージェントのデスクトップ アプリケーションに ICM インターフェイスを提供するために、少なくとも 1 つの CTI サーバが IPCC サイトに必要です。CTI サーバは、CTI ゲートウェイと呼ばれる専用マシン上で稼動するか、または CallManager PG か IP IVR PG プラットフォームにインストールできます。
• CTI OS サーバ。CTI OS は、CTI アプリケーションを導入するための、高パフォーマンス、スケーラブル、かつフォールト トレラントなサーバベースのソリューションであり、このようなアプリケーションの統合のシングル ポイントとして動作します。CTI サーバのクライアントである CTI OS には、Cisco CTI サーバへのすべてのイベント用の接続があります。CTI OS では、セッション インターフェイス、エージェント インターフェイス、およびコール インターフェイスを使用してクライアント接続を順に受け付けます。
• プレルーティングおよびポストルーティングのサポート。図 2-2 に示されている設定では複数のコンタクト センター サイトが結合されているため、プレルーティングを有効にするための ICM NIC が含まれています。ポストルーティングは、コールをサイトで終了した後にルーティングする機能であり、この設定でも使用できます。
• CallManager。IPCC サイトにある単一の CallManager クラスタでは、IP Phone に従来の PBX テレフォニー機能が提供されています。図 2-2 は、各サイトに単一の CallManager クラスタを示しています。マルチサイト配置では、実装可能な CallManager クラスタの数に制限はありません。
CallManager ソフトウェアは、サーバクラス PC にインストールします。バックアップ CallManager は、通常、フォールト トレランスを実現するために使用します。CallManager クラスタでは、最大 8 台のサーバが使用されます。
CallManager サーバは、主なコール処理用に 4 台、バックアップ コール処理用に 2 台、データベース パブリッシャ用に 1 台、および TFTP サーバ用に 1 台が使用されます。同時に 4 台以上の CallManager サーバがコールを処理することはできません。冗長性を持たせるために、スキル セットはこれらの CallManager に分散されています。1 つの CallManager に障害が発生しても、バックアップ CallManager のエージェントによって呼処理が引き継がれます。
(注) CallManager の設定の詳細は、『Cisco AVVID IP Telephony Network Design Guide』を参照してください。
• IP および PSTN テレフォニー。PSTN は、複数のサイトをネットワークで接続する場合や外部コール(つまり、エージェントの IP Phone から発信されるコール)に対して使用します。IP Phone は Model 7960G Cisco IP Phone です。これらの IP Phone では、すべての IP Phone コールで G.711(非圧縮)がサポートされています。これらの電話を使用するには、電話1通話あたり 80 Kbps のネットワーク帯域幅が必要です。音声の品質を保つには、最低で 2 つのキューで Cisco LAN スイッチを使用してください。
また、Digital Signal Processing(DSP; デジタル シグナル プロセッシング)リソースを介して、会議通話がサポートされています。
IP ハード電話の代わりに、IPCC Media Termination コンポーネントを使用できます。このソフトウェアはエージェント デスクトップのソフトフォンと連携して動作し、IP 接続を経由した音声の送受信が実行されます(このオプションの詳細は、第 1 章「アーキテクチャの概要」を参照してください)。
• VoIP ゲートウェイ。マルチサイトの設定では、各サイトに少なくとも 1 つの VoIP ゲートウェイが必要です。PSTN とのインターフェイスをとる設定では、PRI ベースのゲートウェイが必要になります。
IP WAN を使用してコールを分散させるマルチサイトの設定もサポートされています。この設定では、分散したサイト間でのネットワーク コール用に IP WAN が優先的に使用されます。PSTN は、任意のオーバーフロー コールに使用できます。図 2-3 は、このタイプの設定の例を示しています。
図 2-3 分散コール処理に IP WAN を使用するマルチサイトの設定
この設定は図 2-2 に示されているマルチサイトの設定に似ていますが、音声コールのプライマリ パスとしての PSTN の代わりに、IP WAN および IOS Gatekeeper が実装されています。この WAN は、プライマリ音声パスとして使用します。各 IPCC サイトでは、オーバーフロー コール用に必要となる場合に備えて、PSTN との接続も維持されます。また、ICM ソフトウェアでは、コールのプレルーティングおよびポストルーティングに PSTN が使用されます。次に示すように、マルチサイト IP WAN の分散コール処理設定には、その他の設計上の特性がいくつかあります。
• CallManager クラスタ。PSTN だけを使用するマルチサイトの設定の場合と同様に、IP WAN 設定では CallManager または CallManager クラスタを各サイトに配置して、スケーラブルなコール制御が可能になります。
CallManager ソフトウェアは、サーバクラス PC にインストールします。バックアップ CallManager は、通常、フォールト トレランスを実現するために使用します。CallManager クラスタでは、最大 8 台のサーバが使用されます。
CallManager サーバは、主なコール処理用に 4 台、バックアップ コール処理用に 2 台、データベース パブリッシャ用に 1 台、および TFTP サーバ用に 1 台が使用されます。同時に 4 台以上の CallManager サーバがコールを処理することはできません。冗長性を持たせるために、スキル セットはこれらの CallManager に分散されています。1 つの CallManager に障害が発生しても、バックアップ CallManager のエージェントによって呼処理が引き継がれます。
図 2-3 は、2 つの CallManager クラスタだけを示しています。実際は、数多くの CallManager クラスタおよびサイトをサポートできます。ICM セントラル コントローラは、二重化されて地理的に分散された設定のままです。
• サポートされるサイト数。この設定では、ハブおよびスポークのテクノロジを使用して、IP WAN 経由で相互接続された最大 80 のサイトがサポートされています(これは ICM における PIM あたりの PG 数の制限です)。この設定では、CallManager クラスタが 1 つのキャンパスに集約されます。
CallManager クラスタが WAN にまたがることはできません。CallManager クラスタを構築する場合は、1 つの CallManager をパブリッシャ(TFTP サーバ)として定義します。他の CallManager はサブスクライバとして定義します。リモート WAN で接続した CallManager パブリッシャへの CallManager サブスクライバはサポートされていません。クラスタ内のすべての
CallManager を LAN に接続する必要があります。
• プライマリ パスとしての IP WAN。この設定では、IP WAN が CallManager サイト間のプライマリ音声パスとして機能します。PSTN は、セカンダリ パスとして機能するとともに、ICM プレルーティングおよびポストルーティングに使用されます。IP WAN が使用不可になった場合、PSTN が使用されることは透過的です。音声パスネットワークおよび ICM のビジブル ネットワークの両方を WAN に実装する場合は、両方のネットワークに適切な容量の専用帯域幅が確保されていることを確認してください。シスコ セールス エンジニアに問い合せ、WAN およびネットワーク要件を決定します。
• Cisco IOS Gatekeeper。IOS Gatekeeper は、E.164 アドレス解決および IP WAN へのアドミッション制御を行う場合に、この設定に実装します。リモート サイトでは、ゲートウェイとともに Skinny ゲートウェイ protocol に基づく
Cisco IOS を使用できます。
• 圧縮音声コール。マルチサイト IP WAN 設定では、IP WAN 経由の圧縮音声コールがサポートされています。
• シングル WAN codec。シングル WAN codec がサポートされています。
• 会議。各サイトでは、会議および WAN トランス コーディングに DSP リソースが使用されます。
• 帯域幅の注意事項。この設定の音声およびデータ トラフィック用に必要な最低限の帯域幅は、56 Kbps です。音声、対話形式ビデオ、およびデータの場合、最低限の要件は 768 Kbps です。いずれの場合も、音声、ビデオ、およびデータに割り当てる帯域幅が全体容量の 75 % 以下である必要があります。シスコ セールス エンジニアに問い合せ、WAN およびネットワーク要件を決定します。
IP WAN および中央 CallManager クラスタを使用するマルチサイト設定もサポートされています。IP WAN は、サイト間のネットワーク コールに使用します。PSTN はオーバーフロー コールのバックアップとして使用します( を参照)。
図 2-4 中央コール処理を行う IP WAN のマルチサイト設定
中央コール処理を行うマルチサイト IP WAN には、次の設計上の特性があります。
• CallManager 中央コール処理。中央 CallManager サイトでは、アクティブな Cisco CallManager が 1 つだけサポートされています。CallManager クラスタでは、クラスタで処理されるすべての IP Phone がある特定の時点で同じ Cisco CallManager に登録されている限り、第 2、第 3 の CallManager を含めることができます。このタイプの CallManager クラスタは、中央コール処理クラスタと呼ばれます。中央 CallManager クラスタは、中央サイト(つまり、ICM セントラル コントローラも配置されているサイト)にだけ実装します。このため、地理的に分散された ICM 設定では、2 つの中央 CallManager クラスタを配置し、二重 ICM セントラル コントローラのそれぞれの側に 1 つの CallManager クラスタを配置できます。
CallManager サイトでは G.711(非圧縮、80 Kbps)または G.729(非圧縮、24 Kbps)がサポートされています。サイトで G.729 を使用する場合、IP IVR は G.711 専用であるため、DSP リソースを使用する必要があります。
• プレルーティングおよびポストルーティングのサポート。中央 CallManager クラスタ間でのプレルーティングおよびポストルーティングがサポートされています。
• スキル セット サポート。スキル セットは、中央 CallManager クラスタ間で分散されています。中央 CallManager クラスタ内でのエージェントのフェールオーバーがサポートされています。
• VoIP ゲートウェイ。単一のサイトの設定では、PSTN とのインターフェイスとして少なくとも 1 つの VoIP ゲートウェイが必要です。
• リモート エージェント サイト(テレコミューター) 。リモート テレコミューター サイトから IPCC システム(つまり、CallManager、PG、CTI サーバ)へのインターネット アクセスが必要です。このアクセスは、Internet Service Provider(ISP; インターネット サービス プロバイダ)を介して取得できます。ホーム エージェントは、次の Cisco の中小規模ビジネス ソリューションのいずれかを備えたホーム オフィスの LAN を使用することもできます。
–Cisco SOHO 77 Router。小規模オフィスおよびホーム オフィスの顧客向けに、安価で安全なマルチユーザの Digital Subscriber Line(DSL; デジタル加入者回線)アクセス ソリューションを提供するとともに、サービス プロバイダの配置および運用のコストを削減します。
–Cisco 700 シリーズ アクセス ルータ。小規模オフィスおよびホーム オフィスの複数ユーザに安価で高速なインターネット アクセスを提供する ISDN ネットワーク装置です。最大 5 ユーザまでの場合に推奨され、Cisco 700 シリーズのルータで複数のモデム、ISDN カード、および複数の電話回線を 1 本の ISDN 接続に統合します。
–Cisco 800 シリーズ ルータ。ルータを直接指定の設定にすると、小規模なオフィスおよびテレコミューター用に調整した Cisco IOS ソフトウェアによって、セキュリティの強化、所有コストの低下、信頼性の確保、および安全な投資を実現できます。Cisco 800 シリーズによって、ISDN、シリアル接続(フレーム リレー、専用回線、X.25 または非同期ダイヤルアップ)、IDSL、および ADSL を経由してインターネットまたは企業 LAN にユーザが接続されます。
• ブランチ オフィス サイト。ブランチ オフィスのエージェントは、IP ルータまたは企業イントラネットを使用して、IPCC システムと通信します。
• リモート サイトにある電話。リモート サイトにある IP Phone にはローカルの Cisco CallManager がありません。Call Admission Control(CAC; コール アドミッション コントロール)のメカニズムは、場所別の帯域幅に基づいています(コール アドミッション コントロールの詳細は、『Cisco AVVID IP Telephony Network Design Guide』を参照)。リモート サイトでは、ゲートウェイとともに Skinny Station Protocol に基づく Cisco IOS を使用できます。音声メール、ユニファイド メッセージング、および DSP リソース コンポーネントは、セントラル サイトでだけ使用できます。
• 音声コール 。IP WAN を経由した圧縮音声コールがサポートされています。音声およびデータ トラフィックの最低限の帯域幅の要件は 56 Kbps です。音声、対話形式ビデオ、およびデータの場合、最低限の要件は 768 Kbps です。いずれの場合も、音声、ビデオ、およびデータに割り当てる帯域幅が WAN の全体容量の 75 % 以下である必要があります。
• ICM セントラル コントローラ 。ICM セントラル コントローラ(CallRouter および Logger)は、二重化して 1 つのサイトに配列することも、地理的に分散することもできます。わかりやすくするために、ここでは、セントラル コントローラが二重化して配列された形で示されており、必要なビジブル プライベート LAN の詳細は省略されています。
• ペリフェラル ゲートウェイ 。この設定の PG は、二重化して 1 つのサイトに配列されています。わかりやすくするために、 では、ペリフェラル ゲートウェイが二重化して配列された形で示されていますが、必要なプライベート LAN PG 接続の詳細は省略されています。
• PSTN の使用状況。IP WAN が音声トラフィック用に完全にサブスクライブされている場合は、PSTN を手動で使用できます(手動の場合は、話中信号の後に PSTN アクセス コードをダイヤルする必要があります)。IP WAN が停止した場合に備えて、WAN 経由の IP Phone サービス用にダイヤル バックアップが必要です。
ネットワーク事業者は、顧客へのサービスとして IPCC を提供できます。ネットワーク設定では、Network Applications Manager(NAM)環境に IPCC が組み込まれています(NAM は ICM ソフトウェアの事業者クラス バージョン)。NAM 環境では、個々の顧客が独自の Customer ICM(CICM)システムを持つか、または CICM システムを共有できます。
ネットワーク事業者設定は、事業者およびその顧客の両方にとって利点があります。事業者は複数の顧客にサービスを提供できるため、システム リソース(IVR キュー ポイントなど)を共有できます。顧客は事業者に CICM の管理を任せ、
ICM Admin Workstation(AW)を介してシステムにアクセスします。AW を使用すると、顧客は顧客自身の施設にシステムを維持し、システム リソースを制御して ICM レポートを生成できます。
(注) Network Applications Manager(NAM)の詳細は、『Cisco Network Applications
Manager Product Description』を参照してください。
図 2-5 は、ネットワーク事業者設定の サンプル を示しています。サービス プロバイダ環境では、その他の数多くの設定を行うことができます。Cisco AVVID および CallManager ネットワークの可能な設定の詳細は、『Cisco AVVID IP Telephony Network Design Guide』を参照してください。
図 2-5 は、事業者ネットワークに実装されたキュー ポイント IVR を示しています。各顧客は Customer ICM(CICM)システムのほか、CallManager PG、CTI サーバ、および関連するエージェント デスクトップと IP Phone を持ちます。ネットワーク事業者には、二重化された Network Interface Controllers(NIC; ネットワーク インターフェイス コントローラ)が実装されています。つまり、各顧客へのコールは NAM CallRouter によってプレルーティングされます。顧客 1 および 2 は、ネットワーク キュー ポイント IVR および関連する二重キュー ポイント IVR PG ペアを共有できます。顧客 1 の CICM システムがコンタクト センター サイトに配置されているのに対して、顧客 2 の CICM システムは事業者ネットワークに配置されています。これは標準の NAM オプションです。
従来の ACD 環境では、ACD によってコールをキューイングし、IVR にコールを送信することを含むコールの処置を実行できます。IPCC 環境では、設定に ACD を必要とせずに、ICM 自体で IVR へのコールをキューイングできます。キュー ポイント IVR は、処理待ちのコールを保持する場所(キュー)を提供する場合に IPCC で使用します。コールをキュー ポイント IVR に保持して、顧客から情報を収集したり、リソースが使用可能になるのを待っている顧客に対するコールの処置を実行できます。
キュー ポイント IVR は、事業者電話ネットワーク内に配置するか、または顧客施設に配置できます。事業者ネットワークでは、Cisco Internet Service Node(ISN)を使用できます。顧客のサイトで、IVR は通常、TDM または IP IVR です。顧客施設における IP IVR と TDM IVR の選択は、IVR を VoIP ゲートウェイの前面に配置するか、または背後に配置するかに応じて決定します。
キュー ポイント IVR PG は、キュー ポイント IVR と ICM セントラル コントローラ間のインターフェイスです。キュー ポイント IVR PG は、基本的に、ICM GED-125 に定義されているように ICM サービス制御インターフェイスを実行する IVR PG です(Telera は、ICM サービス制御仕様に基づいて IVR 用のコードを作成しているネットワークベースの IVR ベンダーの一例です)。
コールは、キュー ポイント IVR にプレルーティングしたり、電話ネットワークによってキュー ポイント IVR に直接配信できます。コールがキュー ポイント IVR に着信すると、キュー ポイント PG から ICM CallRouter に、コールが着信したこと、および IVR が指示を待機していることを示すメッセージが送信されます。通常、ICM コール ルーティング スクリプトによって RunScript ノードが実行され、これにより、IVR でアナウンスメントが再生されたり、番号が収集されます。または、ICM でターゲットとなる宛先をただちに選択することもできます。ターゲットとなる宛先を(使用可能なリソースの不足などの理由により)選択できない場合は、コール ルーティング スクリプトで 1 つ以上のキュー ノードを実行できます。キュー ノードによって、CallRouter は選択されたターゲット(スキル グループまたはサービス)にコールをキューイングします。
ICM コール ルーティング スクリプトは、目的のリソースが使用可能になるまで、定期的に RunScript リクエストを実行することで続行されます。実際は、ICM コール ルーティング スクリプトによって、エージェントが応答可能になるのを待つ顧客に処置を提供する遅延ループが作成されます。エージェントが応答可能になると、CallRouter によってキュー ポイント PG にメッセージが送信され、IVR がコールをターゲット エージェントに移動します。ICM コール ルーティング スクリプトによって、コールの処置およびリソース選択が制御されます。これらは、従来 ACD または顧客施設の IVR スクリプトによって処理されていたタスクです。
ネットワーク キュー ポイントはコスト上の利点があります。コールを処置するためのリソースが実際に使用可能になるまで、特定のコール センターまたはエージェント デスクトップがある場所でコールを終了させる必要がないからです。たとえば、ICM ルーティング スクリプトは、数多くのコール センター間で最も長く応答可能になっているエージェント(LAA)を最初に検索するように設定できます。いずれのエージェントも応答可能ではない場合は、いずれかのエージェントが応答可能になるまで、CallRouter からコールをネットワーク キュー ポイント IVR に送信してコールの処置を受けることができます。エージェントが応答可能になると、CallRouter によって、応答可能なエージェントにコールが送信されます。
これは、キュー ポイント IVR を使用していない IPCC 以外のシステムとは異なります。従来の ACD 環境では、通常、ICM CallRouter によって、次にエージェントが応答可能になる可能性が最も大きい場所が選択されます。これは、ACD PG によって指定されるデータに基づいた Minimum Expected Delay(MED; 最小遅延予測値)の計算を使用して行われます。ACD または顧客施設の IVR では、CallRouter の入力なしでコールの処置が提供されます。
ネットワーク キュー ポイント IVR は、地理的に分散された複数の顧客が共有できるため、通常はサービス プロバイダ IPCC 設定で使用します。また、顧客が独自の顧客施設 IVR を維持する代わりにネットワーク IVR サービスを使用する、単一のサイトの設定および分散 IPCC 設定でも使用できます。図 2-6 は、ネットワーク キュー ポイント IVR を使用する IPCC 設定を示しています。
顧客施設キュー ポイント IVR と比較した場合のネットワーク キュー ポイント IVR の利点は、コストで測定できます。特に、1 分あたりのコストは、長距離通信事業者がネットワークにコールを保持するため、一般にネットワーク キュー ポイント IVR の方が安価です。このため、顧客施設の終了に関連した Local Exchange Carrier(LEC; 地域通信事業社)の課金が発生しません。また、コールをネットワーク キュー ポイント IVR に配置する場合、特定の顧客施設の終了ポイントが優先されることはありません。
キュー ポイント IVR は、顧客施設がある場所に配置することもできます。これは、通常、ネットワーク IVR サービスの購入を希望しない顧客、または IVR の完全制御を希望する顧客向けのオプションです。図 2-7 は、顧客施設キュー ポイント IVR を使用する IPCC 設定を示しています。
図 2-7 は、IPCC サイト 1 の顧客施設に配置された従来の Time Division
Multiplexing(TDM; 時分割多重化)IVR を示しています。そのサイトにある ICM LAN 上のキュー ポイント IVR PG に注意してください。IPCC サイト 2 は、ICM LAN 上に配置された Cisco IP IVR を示しています。この設定では、関連するキュー ポイント IVR PG も必要です。
顧客施設キュー ポイント IVR を使用すると、キュー ポイント IVR に着信するコールおよび ICM コール ルーティング スクリプトによって、コールの処置が決定されます。応答可能なエージェントが存在しない場合は、エージェントがコールを処理できる応答可能状態になるまで、CallRouter からコールをキュー ポイント IVR に送り返して処置を受けることができます。エージェントが応答可能になると、CallRouter によって、応答可能なエージェントにコールが送信されます。
エージェントがローカルである場合、コールはエージェントが応答可能になったときに配信されます。ただし、ローカル エージェントが応答可能ではない場合は、ICM ルーティング スクリプトによって、コンタクト センター エンタープライズの別の場所で応答可能なエージェントが検索されます。このエージェントは、離れた場所に存在する場合があります。このような場合、CallManager は、IP IVR に対して、1 つの IP コールを破棄して新しい別のコールを作成するように指示します。
ICM サービス制御インターフェイス(ICM GED-125 に定義されている)がサポートされているサービス施設ベースの IVR は、次のとおりです。
(注) Conversant IVR は、SpanLink Communications, Inc. から購入できます。