Cisco IP Contact Center Enterprise Edition ネットワーク デザイン(SRND) Releases 5.0/6.0
偏向のない言語
この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
翻訳について
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
- Updated:
- 2017年6月6日
章のタイトル： 配置モデル
配置モデル
IPCC の配置方法は数多く存在しますが、一般的には次のモデルに分類できます。
これらの配置モデルを基本として、多様なバリエーションや組み合わせが可能です。それぞれのモデルにおいて、以下に示す要因に基づく複数のバリエーションが生じます。
•
長距離通信会社（IXC）と地域通信会社（LEC）のいずれのトランクを使用するかの選択
この章では、これらのうちサイジング以外の要因が、ネットワーク デザイン上の意思決定に及ぼす影響について説明します。また、配置モデルごとに、費用便益分析を使用して評価する必要のある検討事項とリスクについても述べます。さらに、各配置モデルに合致するベスト プラクティスのシナリオを紹介します。
これらの配置モデルを組み合わせたモデルも考えられます。たとえば、マルチサイトの配置では、小規模なサイトのように集中コール処理を採用しているサイトと、大規模なサイトのように分散コール処理を採用しているサイトを混在させることが可能です。このようにモデルを複合的に組み合わせたシナリオの例については、対応する各セクションで紹介します。
さらにこの章では、PBX/ACD のハイブリッド配置を含む、従来型の ACD システムと IVR システムを IPCC 配置に統合する手法についても説明します。サイジングと冗長性については、この IPCC 設計ガイドの後半の章で取り上げます。IPCC ソリューションのサポートに必要なネットワーク インフラストラクチャについての詳細は、次の URL にある『Cisco Network Infrastructure Quality of Service Design』のガイドを参照してください。
IPCC および IP テレフォニーの配置モデルについての詳細は、次の URL にある『Cisco IP Telephony Solution Reference Network Design (SRND)』を参照してください。
単一サイト
単一サイト配置とは、音声ゲートウェイ、エージェント、デスクトップ、IP Phone、およびコール処理の各サーバ（Cisco CallManager、Intelligent Contact Management（ICM）、および IP IVR または Internet Service Node（ISN））がすべて同一のサイトに存在し、IPCC ソフトウェア モジュール相互間で WAN 接続が使用されていないシナリオを指します。図2-1 は、このタイプの配置を示しています。
図2-1 の例では、2 つの IP IVR、Cisco CallManager クラスタ、冗長系のある ICM PROGGERS、アドミン ワークステーション（AW）および Historical Data Server（HDS）で構成され、音声ゲートウェイは PSTN に直接接続されています。このシナリオの ICM PROGGER で処理されている主なソフトウェア プロセスは、次のとおりです。
• Cisco CallManager ペリフェラル インターフェイス マネージャ（PIM）
• CTI Object Server（CTI OS）または Cisco Agent Desktop Server
このモデルでは、数多くのバリエーションが可能です。たとえば、ICM セントラル コントローラとペリフェラル ゲートウェイ（PG）は、別々のサーバに分離できます。どのような状況で ICM セントラル コントローラと PG を別々のサーバにインストールするかについては、「IPCC のコンポーネントとサーバのサイジング」を参照してください。
ICM は、冗長化せず、シンプレックスな形態で配置することも可能です。IPCC の冗長化で得られる利点とその設計方法については、「アベイラビリティを高めるための設計上の注意点」を参照してください。
Cisco CallManager のノード数や使用するハードウェアの型番は、IP IVR や ISN のサーバ数を決めただけでは決定されません。必要なサーバの台数と型番を決定するための情報については、「IPCC のコンポーネントとサーバのサイジング」を参照してください。
また、このモデルでは LAN に必要なデータ スイッチング インフラストラクチャ、音声ゲートウェイの種類、音声ゲートウェイとトランクの数も特定していません。これらのコンポーネントを設計する際の手引きとしてシスコでは、キャンパス向けの各種デザイン ガイドおよび IP テレフォニーに関するデザイン ガイドを提供しています。「コール センターのリソース サイジング」では、ゲートウェイのポート数を決定する方法を説明しています。
このモデルのバリエーションとして、音声ゲートウェイを PSTN に接続する代わりに PBX のライン側に接続するシナリオも考えられます。一箇所の単一サイトから複数の PSTN と PBX に接続する配置も可能です。たとえば、ローカルな PSTN、フリーダイヤルの PSTN、従来型の PBX/ACD からのトランクをすべて備えた配置も可能です。詳細は、「従来の ACD の統合」および「従来の IVR の統合」を参照してください。
この配置モデルでは、PSTN と音声ゲートウェイとの間で使用するシグナリングの種類（ISDN、MF、R1 など）や、音声ゲートウェイと Cisco CallManager との間で使用するシグナリングの種類（H.323 と MGCP のいずれか）を特定していません。
また、このモデルでは、コールの保留、別窓口への転送、および電話会議に必要なデジタル信号プロセッサ（DSP）リソースの規模についても、指定はありません。これらのリソースのサイジングについては、次の URL にある『Cisco IP Telephony Solution Reference Network Design (SRND)』を参照してください。
単一サイト配置モデルの大きな長所は、WAN 接続が不要な点です。WAN が存在しないので、この配置モデルでは一般的に G.729 などの圧縮した Real-Time Transport Protocol（RTP）ストリームを使用する必要がなく、その結果、トランスコーディングが不要になります。
IP IVR による処理とキューイング
この配置モデルでは、最初のキューイングとそれに続くキューイングはすべて IP IVR で実行されます。複数の IP IVR が配置されている場合は、ICM を使用してこれらの IP IVR 間でコールのロード バランシングを行う必要があります。
ISN による処理とキューイング
この配置モデルでは、最初のキューイングとそれに続くキューイングはすべて ISN を使用して実行されます。すべての ISN プロセスを同一のサーバ上で実行すれば、サーバが 1 台で済む可能性もあります。一方、サーバを複数台使用すれば、スケーリングが可能となり冗長性も得られるようになります。詳細は、「ISN コンポーネントのサイジング」および「アベイラビリティを高めるための設計上の注意点」を参照してください。
転送
この配置モデルでは、（複数のサイトに対する集中型コール処理モデルの場合も同様ですが）転送元エージェントとターゲット エージェントが同一の PIM 上に存在しています。これは、ルーティング クライアントとペリフェラル ターゲットが同一のペリフェラル（あるいは PIM）であることを意味しています。転送元エージェントは、特定のダイヤル番号宛てに転送を生成します（たとえば、スキルグループに属する専門家を探します）。
その転送要求と一致する内容がダイヤル番号計画（DNP）に見つかり、その DNP タイプが転送元エージェントにとって使用可能なもので、さらにポストルーティング オプションが yes に設定されていれば、Cisco CallManager PIM のロジックにより、ICM Router 宛てにルーティング要求が生成されます。ICM Router では、ダイヤル番号とコール タイプが照合され、適切なルーティング スクリプトが実行されます。このルーティング スクリプトでは、応答可能な専門家が検索されます。
転送されたコールを受信するターゲット エージェント（専門家）が存在すれば、ICM Router からルーティング クライアント（Cisco CallManager PIM）に適切なラベルが返送されます。このシナリオの場合、ターゲット エージェントが現在ログインしている電話の内線番号がラベルとして使用されるのが普通です。このルーティング応答（ラベル）を受信した Cisco CallManager PIM から Cisco CallManager に JTAPI 転送要求が送信されることで、転送処理が始まります。
ルーティング クライアントにラベルが返送されると同時に、目的のコールから収集されたあらゆるコール データを含むプレコール データが、ペリフェラル ターゲットに送信されます。このシナリオの場合、ルーティング クライアントとペリフェラル ターゲットは同一の Cisco CallManager PIM です。これは、転送元エージェントとターゲット エージェントが同一の PIM にアソシエートされているためです。ルーティング クライアントとペリフェラル ターゲットが異なるような、より複雑なシナリオは、後半のセクションで紹介します。
転送されたコールを受信するターゲット エージェントが存在しない場合、そのコールはキュー処理を行う IVR に転送されるように ICM ルーティング スクリプトを設定するのが普通です。このシナリオでは、Cisco CallManager に対して IVR へのコール転送を指示するダイヤル番号がラベルとして使用されます。この場合、ルーティング クライアントとペリフェラル ターゲットは異なったものになります。ルーティング クライアントは Cisco CallManager ですが、ペリフェラル ターゲットはコールの転送先として指定された IVR PIM です。
複数のサイトに対する集中型コール処理
複数のサイトに対する集中型コール処理とは、コール処理サーバ（Cisco CallManager、ICM、および IP IVR または ISN）が同一のサイトに存在し、音声ゲートウェイ、エージェント、デスクトップ、および IP Phone が任意の組み合わせで、WAN リンクを介した別の場所、または集中管理された別の場所にあるようなあらゆるシナリオを指します。図2-2 は、このタイプの配置を示しています。
音声ゲートウェイを集中させる場合
大都市圏に小規模なリモート サイト群やオフィス群を持っているために、コール処理サーバや音声ゲートウェイを複数設置することが効率的ではない企業には、このモデルが最適です。サイトの規模が大きくなったり地理的に離れた場所に設置されるようになると、音声ゲートウェイを分散して配置する方が好結果につながることもあります。
このモデルを図2-2 に示します。
図2-2 複数のサイトに対して集中型コール処理と集中型音声ゲートウェイを配置した場合
• エージェントが数人だけのリモート サイトで必要となるのは小規模なデータ スイッチ、ルータ、IP Phone、エージェント デスクトップだけであり、そこで必要となるシステム管理とネットワーク管理のスキルもごく限られたものになります。
• このような小規模なサイトとオフィスでは、WAN リンクの障害に備えた緊急連絡用の POTS 回線を除き、PSTN と直接接続するトランクが不要です。
• PSTN トランクでは小規模なリモート サイト用のトランクを集約できるため、より効率的な運用が可能になります。
• IPCC キュー ポイント（IP IVR または ISN）にはすべてのキュー ポイントが集約されているので、効率的な運用を図ることができます。
• コールのキューイング（最初のキューイングとそれに続くキューイング）中は、VoIP の WAN 帯域幅が消費されません。
このモデルには、単一サイト配置モデルと同様のバリエーションがすべて存在します。たとえばマルチサイト配置でも、ICM ソフトウェアをすべて同一のサーバで実行する場合や複数のサーバで実行する場合があり得ます。ICM ソフトウェアは、冗長系を構成してインストールする場合と冗長系を構成せずにインストールする場合があり得ます。この配置モデルでは、Cisco CallManager および IP IVR サーバまたは ISN サーバの数は指定されていません。同様に、LAN/WAN インフラストラクチャ、音声ゲートウェイ、PSTN 接続についても指定はありません。他のバリエーションについては、「単一サイト」を参照してください。
• リモート サイトのエージェントの電話への RTP トラフィックには VoIP WAN の接続が必要です。
• VoIP WAN の帯域幅消費を抑えるために、リモートサイトのエージェントの電話までの RTP トラフィックを圧縮する必要があるかもしれません。サイト内のコールは非圧縮とすることが望ましいので、IP テレフォニーの配置デザインによっては、トランスコーディングが必要となります。
• IP Phone から Cisco CallManager クラスタへの Skinny Client Control Protocol（SCCP）コール制御トラフィックは、WAN を経由して流れます。
• IPCC Agent Desktop で送受信される CTI データは、WAN を経由して流れます。これらのリンクでは、十分な帯域幅と QoS のプロビジョニングが不可欠です。
• リモート サイトには音声ゲートウェイがありません。したがって、もしもトランクと組み合わせた音声ゲートウェイがリモート サイトにあれば公衆電話交換網の電話による市内通話が可能な番号に対しても、顧客は市外電話番号をダイヤルする必要があります。中央サイトにおけるフリー ダイヤルで受け付けることが可能な業務であれば、この問題を回避することも可能です。その場合、顧客にフリー ダイヤル番号を提供し、その番号へのコールはすべて集中型の音声ゲートウェイのある場所にルーティングさせます。ただしこの方法では、コール センターがフリー ダイヤル料金を負担する必要があります。この事態は顧客が PSTN の市内局番でダイヤルできるようにすれば避けられます。
• PSTN トランクと組み合わせたローカル音声ゲートウェイがないため、緊急電話（119、110）へのアクセスに問題があります。この問題は、Cisco CallManager のダイヤル プランで管理する必要があります。ほとんどの場合、ローカル トランクでは緊急電話（119、110）は地元の緊急連絡先に接続されます。
• Cisco CallManager による Location に基づくコール アドミッション コントロールが失敗すると、ルーティングされたコールが接続解除されます。したがって、リモート サイトと接続する帯域幅は十分余裕を持ってプロビジョニングすることが重要です。また、WAN の QoS を適切に設計することは欠かせません。
IP IVR による処理とキューイング
中央サイトが一箇所のみの配置では、単一サイト配置の場合と同様にすべてのコールに対するキューイングが IP IVR で行われます。コールがキューイングされている間は、WAN 上に RTP トラフィックが流れません。無応答時の転送や再ルーティングで再キューイングが必要になっても、キュー処理で RTP トラフィック フローが WAN 上を流れることはありません。これにより、リモート サイトとの接続に必要な WAN 帯域幅を抑えることができます。
ISN による処理とキューイング
転送
このシナリオの場合、転送元エージェントとターゲット エージェントは同一の Cisco CallManager クラスタと Cisco CallManager PIM に存在しています。したがって、転送元エージェントがターゲット エージェントと同じ LAN にいるか、別の LAN にいるかに関係なく、単一サイト モデルの場合と同じコールとメッセージのフローが発生します。違うのは、QoS を確保する必要があることと、適切な LAN/WAN ルーティングを設定する必要があることだけです。QoS に配慮した WAN のプロビジョニングについての詳細は、次の URL にある『Cisco Network Infrastructure Quality of Service Design』を参照してください。
（発信者ではなく）エージェントがコンサルテイティブ転送を行なった結果が IP IVR ポートにルーティングされてキューイング処理の対象となる場合はトランスコーディングが必要になります。これは、IP IVR で生成できるのが G.711 メディア ストリームのみであるためです。
音声ゲートウェイを分散させる場合
集中型コール処理モデルでは、複数の音声ゲートウェイを別々の場所に設置するバリエーションも可能です。この分散型音声ゲートウェイのモデルが適するのは、小規模なサイトを数多く持ち、それぞれのサイトで市内からの電話に対応するローカルな PSTN トランクを必要とする企業です。このモデルは、市内電話用のローカルな PSTN 接続とローカルな緊急電話へのアクセスを提供します。図2-3 にこのモデルを示します。
図2-3 複数のサイトに対して集中型コール処理と IP IVR を備えた分散型音声ゲートウェイを配置した場合
キューイングと処理に使用する IP IVR を持つこの配置モデルでは、各サイトにインバウンドしたコールをそのサイトにいるエージェントだけで処理するように制限することが望ましいとも言えますが、必ずしもそうしなければならないということはありません。インバウンド コールを同一サイト内で処理するよう制限した場合、次の影響が考えられます。
• エージェント向けのコールで消費される VoIP WAN 帯域幅を節約できます。
• コールのキュー時間と処理時間が長くなるため、サイトに着信するコールに対して顧客サービス レベルが低下する可能性があります。
• キュー時間が長くなる可能性があります。これは、この IPCC の設定では、他のサイトのエージェントが利用可能であっても、現在のローカル サイトのエージェントに空きが出るまで待つためです。
• 処理時間が長くなる可能性があります。これは、より適したエージェントが他のサイトに存在しても、WAN 帯域幅の消費を抑えるためにコールはローカル エージェントにルーティングされるためです。
配置を担当するチームにとっては、運用コストと顧客の満足度との妥協点を慎重に評価し、各顧客の事情に合った適切なバランスを確立することが重要になります。たとえば、特定の重要顧客からのコールは他のサイトにルーティングしてキュー時間を短縮したうえで経験豊かな担当者の手に委ねられるようにし、それ以外の顧客からのコールは着信したサイトのエージェントによる扱いに限定するという方法も可能です。
IPCC の実際の配置で集中型の音声ゲートウェイと分散型の音声ゲートウェイを組み合わせることも可能です。フリー ダイヤル サービスを提供する 1 つの PSTN キャリアに集中型の音声ゲートウェイを接続し、市内電話サービスを提供するそれ以外の PSTN キャリアに分散型の音声ゲートウェイを接続するという方法もあります。
市内 PSTN からのインバウンド コールには、ダイヤルイン方式（DID; Direct Inward Dial）とコンタクト センター コールの両方が可能です。すべてのインバウンド コールとアウトバウンド コールに対する要件を把握し、音声ゲートウェイの最も効率的な設置場所を決めることが重要です。どのような人たちが、何の目的で、どこから、どのような方法で電話しているのかを特定します。
分散型音声ゲートウェイを使用した複数サイト配置では、ICM のプレルーティング機能を利用し、複数のサイト間でコールを動的にロード バランシングできます。ICM のプレルーティング機能を提供している PSTN キャリアのリストは、次の URL にある ICM の関連ドキュメントに掲載されています。
http://www.cisco.com/univercd/cc/td/doc/product/icm/
ローカルな PSTN トランクと、それとは独立したフリー ダイヤル トランクの両方を備える音声ゲートウェイでコンタクト センターへのコールを受ける複数サイト環境では、ICM プレルーティング ソフトウェアを使用してフリー ダイヤル コンタクト センターへのコールとローカル コンタクト センターへのコールとの間でのロード バランシングが可能です。たとえば、サイト 1 とサイト 2 の 2 つのサイトによる配置を考えます。サイト 1 では現在すべてのエージェントでコールを処理中であり、数多くのコールがキューにあるとします。一方、サイト 2 ではキューにあるコールがわずかであるか、あるいは一部のエージェントが空いている状況であるとします。このシナリオでは、ICM を通じてフリー ダイヤル プロバイダーが抱えているフリー ダイヤル コールのほとんどまたはすべてをサイト 2 にルーティングできます。ICM が提供するこのタイプの複数サイト間ロード バランシングは動的で、すべてのサイトの呼量変動に伴って自動的に調整されます。
前述の 2 つの配置モデル同様、数多くのバリエーションが存在します。これらのバリエーションでは、ICM、Cisco CallManager、IP IVR サーバまたは ISN サーバの数とタイプ、LAN/WAN インフラストラクチャ、音声ゲートウェイ、PSTN 接続などがそれぞれ異なります。
• リモート サイトで必要となるシステム管理スキルがごく限られたもので済みます。これは、サーバ、各種機器、およびシステムのほとんどの設定が 1 か所から集中管理されるためです。
• ICM プレルーティング オプションにより、サイト間でコールのロード バランシングが可能です。ローカル PSTN トランクを使用しているサイトのほか、フリー ダイヤル PSTN トランクを使用しているサイトもロード バランシングに参加できます。
• 各リモート サイトに着信してそのサイトのエージェントにより処理されるコールに関しては、WAN RTP トラフィックが不要です。
• IP IVR または ISN、Cisco CallManager、および PG（Cisco CallManager および IVR/ISN の双方で使用）は、同じ場所に設置します。このモデルで WAN を介して分離できる IPCC 通信は次の項目に限られます。
–ICM セントラル コントローラと ICM PG 間の通信
–ICM PG と IPCC Agent Desktop 間の通信
–Cisco CallManager と音声ゲートウェイ間の通信
–Cisco CallManager と IP Phone 間の通信
• コールの処理がインバウンド 先サイトだけに制限されない場合や、サイト間でコールが取り交わされる場合は、WAN を通じて流れる RTP トラフィックが増加します。この場合はサイトの間や場所の間を流れるコールの最大量を見極めることが重要です。Location に基づいて Cisco CallManager で実行されるコール アドミッション コントロールが失敗すると、ルーティングされたコールが接続解除されます（Cisco CallManager 内での再ルーティングは現在サポートされていません）。このため、リモート サイトとの接続帯域幅には十分な余裕をもってプロビジョニングし、WAN の QoS を適切に設計することが重要です。
• 分散した音声ゲートウェイと集中した Cisco CallManager サーバとの間に、WAN を経由して H.323 シグナリング トラフィックまたは MGCP シグナリング トラフィックが流れます。WAN の QoS を適切に実現することが不可欠です。また、シグナリングの遅延は次の URL にある『Cisco IP Telephony Solution Reference Network Design (SRND)』に示されている許容値の範囲内に収める必要があります。
IP IVR による処理とキューイング
中央サイトで処理およびキューイングされるすべてのコールをサポートできるように、WAN の帯域幅をプロビジョニングする必要があります。
IP IVR を集中配置することで、IP IVR を小規模な複数サイトに分散配置する場合と比べて、IP IVR のポート利用効率を高めることができます。
ISN による処理とキューイング
コールの処理とキューイングに ISN を使用することで、WAN を経由して流れる音声トラフィックの量を削減できます。コールはリモート ゲートウェイで ISN によってキューイングおよび処理されるので、中央サイトで音声トラフィックの処理を終了させる必要がありません。ここでも、他の場所にいるエージェントが関与する転送と会議に合わせて、WAN の帯域幅をプロビジョニングする必要があります。
転送
VoIP WAN を使用してサイト間で RTP ストリームを送信するサイト内転送やサイト間転送は、単一サイトでの転送や集中型の音声ゲートウェイを持つ配置での転送と基本的に同じ方法で実行されます。
サイト間のコール ルーティングでは、VoIP WAN を使用する代わりに、キャリアが提供する PSTN 転送サービスを利用することもできます。このサービスを利用すると、IPCC 音声ゲートウェイから DTMF トーンをパルス出力し、PSTN に対して、他の音声ゲートウェイが設置された場所にコールを再ルーティング（転送）するよう指定できます。各サイトは、独立したペリフェラルとして ICM 内で設定可能です。転送がサイト内であるかサイト間であるかは、Takeback N Transfer（TNT）を使用してラベルに示されます。
複数のサイトに対する分散型コール処理
互いに遠隔地に存在する中規模から大規模のサイトを複数持つ企業では、分散型コール処理モデルが採用される傾向にあります。このモデルでは、Cisco CallManager クラスタ、コールの処理とキューを行う装置、PG、CTI サーバが各サイトに配置されます。ただし音声ゲートウェイについては、集中型コール処理モデルと同様、各サイトに配置するか一箇所に集中して配置するかを選択できます。分散型の音声ゲートウェイと集中型の音声ゲートウェイを組み合わせて、たとえば前者で市内局番向けのローカル コール、後者でフリー ダイヤル宛てのコールを処理したり、同様にコールの処理とキューにおいても集中型と分散型のポイントを組み合わせることが可能です。
配置するサイトの数に関係なく、この場合も論理的な ICM セントラル コントローラは 1 つだけです。ICM セントラル コントローラにも冗長性を適用して配置する場合、サイド A とサイド B を隣接して配置することも可能ですが、地理的に離れたサイトに配置してリモートの冗長性を実現することも可能です。リモートの冗長性の詳細は、次の URL で ICM の関連ドキュメントを参照してください。
http://www.cisco.com/univercd/cc/td/doc/product/icm/
分散型音声ゲートウェイにおける処理とキューイングを IP IVR で行う場合
この配置モデルは、中規模から大規模のサイトを複数持つ企業において望ましい選択肢となり得ます。このモデルでは、PSTN トランクを組み合わせた音声ゲートウェイにより、処理が各サイト内で終了します。分散型音声ゲートウェイを備えた集中型コール処理モデルの場合と同様に、コールのルーティング先をインバウンド サイトのエージェントに限定すれば、WAN の帯域幅消費を抑えられる利点があります。コールをサイト内に制限するかどうかは、顧客サービス レベルの向上から得られる利点と WAN のコスト低減から得られる利益を比較分析して判断する必要があります。図2-4 にこのモデルを示します。
図2-4 複数のサイトに対して分散型コール処理と IP IVR を備えた分散型音声ゲートウェイを配置した場合
前述のモデル同様、数多くのバリエーションが可能です。ICM サーバ、Cisco CallManager サーバ、IP IVR サーバの台数と型番が変更可能です。さらにこの配置モデルでは、LAN/WAN インフラストラクチャ、音声ゲートウェイ、PSTN トランク、冗長性なども変更可能な要素です。セルフサービス、フリー ダイヤル コール、小規模サイトのサポートなどのために、集中処理とゲートウェイを追加できます。そのほか、プレルーティング PSTN ネットワーク インターフェイス コントローラ（NIC）も選択可能です。
• 各独立サイトは、Cisco CallManager クラスタごとに最大 2,000 人のエージェントを配置可能な規模まで拡張できます。また、企業全体の単一コンタクト センターを形成するために ICM セントラル コントローラで組み合わせ可能なサイトの数に、ソフトウェア上の制限はありません（PG は 80 台まで設置可能）。
• 必要に応じて、VoIP トラフィックのすべてまたはほとんどを、各サイトの LAN の範囲で扱うことができます。サイト間で音声コールを転送するには、図2-4 に示す QoS WAN が必要です。しかし、Takeback N Transfer のような PSTN 転送サービスを利用すればそれも必要ありません。それが必要と判断すれば、特定のサイトに着信したコールの一部を他のサイトのエージェント リソースで処理できるようにキューイングして、顧客サービス レベルを向上させることができます。
• ICM プレルーティングを使用して需要が多いサイトへのコールをロード バランシングし、VoIP トラフィックによる WAN の使用率を下げることができます。
• いずれか 1 か所のサイトで障害が発生しても、他のサイトの運用に影響はありません。
• ICM セントラル コントローラにより、企業内ですべてのコールをルーティングするための設定を集中管理できます。
• ICM セントラル コントローラにより、企業全体の単一キューを作成する機能が提供されます。
• ICM セントラル コントローラにより、すべてのサイトに対する一括レポート処理が可能です。
• PG、Cisco CallManager クラスタ、IP IVR を同じ場所に置く必要があります。
• ICM セントラル コントローラから PG への通信リンクは適切なサイジングを実施し、帯域幅と QoS をプロビジョニングする必要があります（詳細は、「帯域幅のプロビジョニングおよび QoS に関する考慮事項」を参照してください）。
• WAN の帯域幅が利用できない場合は、ゲートキーパーに基づくコール アドミッション コントロールを使用し、PSTN を経由してサイト間でコールを再ルーティングできます。発生が見込まれるコールの最大量に見合った WAN 帯域幅をサイト間で確保するのが最善です。
• PG と ICM セントラル コントローラ間の通信リンクが失われると、そのサイトではコールに対するコンタクト センターのルーティング機能も失われます。したがって、耐障害性を備えた WAN の実装が重要になります。耐障害性を備えた WAN を実装していても、ICM セントラル コントローラと PG 間の通信が失われた場合に備え、コール処理とルーティングについて緊急時計画を策定しておくことが重要です。たとえば、ICM セントラル コントローラとの接続が失われると、Cisco CallManager CTI ルーティング拠点ではコールが IP IVR ポートに送信され、基本的なアナウンスメント処理ができるようにしたり、他のサイトへの PSTN 転送を呼び出したりできるようになっています。また、接続が失われた Cisco CallManager クラスタから、ICM セントラル コントローラとの接続が有効な PG を持つ他の Cisco CallManager クラスタにコールをルーティングする方法もあります。
• 同一のコールに対してクラスタ内コール レッグが 2 つ存在しても、不要な RTP ストリームが発生することはありません。ただし、その場合は 2 つの独立したコール シグナリング制御パスが、2 つのクラスタ間にそのまま維持されます（これによってヘアピン ルーティングが生成され、クラスタ内トランクの数が 2 つ減少します）。
• ICM セントラル コントローラとリモート PG 間の遅延は片道で 200 ミリ秒以下（往復で 400 ミリ秒以下）でなければなりません。
処理とキューイング
コールに対する最初のキューイングは、音声ゲートウェイと同じ場所にある IP IVR で実行されるので、トランスコーディングは不要です。コールが転送された後、引き続いてキューイングが要求されると、そのキューイングは、元のコールが現在処理されているサイトの IP IVR で実行される必要があります。たとえば、サイト 1 に着信したコールがサイト 2 のエージェントにルーティングされたものの、このエージェントは受け取ったコールを存在場所が不明な他のエージェントに転送する必要があるとします。この場合、クラスタ内で余分なコールが発生しないように、このコールはサイト 2 の IP IVR でキューイングされる必要があります。2 回目のクラスタ内コールが発生するのは、コールの転送先としてサイト 1 のエージェントが選択された場合だけです。この場合の RTP フローは、サイト 1 の音声ゲートウェイからサイト 1 のエージェントが使用している IP Phone に直接流れます。ただし、2 つの Cisco CallManager クラスタでは、それらの間で進行中の 2 つのコールが論理的に認識されています。
転送
サイト内の転送は、単一サイトでの転送と同様に機能します。Cisco CallManager クラスタ間の転送では、VoIP WAN または PSTN サービスを利用します。
VoIP WAN を使用する場合は、クラスタ間トランクを十分に設定する必要があります。サイト間のコール ルーティングでは、VoIP WAN を使用する代わりに、PSTN 転送サービスを利用することもできます。このサービスを利用すると、IPCC 音声ゲートウェイから DTMF トーンをパルス出力し、PSTN に対して、他の音声ゲートウェイが設置された場所にコールを再ルーティング（転送）するよう指定できます。もう 1 つの方法として、サイト 1 の Cisco CallManager クラスタから逆に PSTN にアウトバウンド コールを送信する方法があります。そのコールは PSTN からサイト 2 にルーティングされます。ただし、サイト 1 ではコールの残りを処理するために 2 つの音声ゲートウェイ ポートが使用されます。
分散型音声ゲートウェイにおける処理とキューイングを ISN で行う場合
この配置モデルは、コール処理とキューイングで IP IVR の代わりに ISN が使用されている点を除けば、直前のモデルと同じです。このモデルでは、PSTN トランクを組み合わせた音声ゲートウェイにより、処理が各サイト内で終了します。分散型音声ゲートウェイを備えた集中型コール処理モデルの場合と同様に、コールのルーティング先を着信サイトのエージェントに限定すれば、WAN の帯域幅消費を抑えられる利点があります。コールの処理とキューイングも着信したサイトで完了できるようにすれば、WAN 帯域幅をさらに節約できます。図2-5 は、このモデルを示しています。
図2-5 複数のサイトに対して分散型コール処理と ISN を備えた分散型音声ゲートウェイを配置した場合
前述のモデル同様、数多くのバリエーションが可能です。ICM サーバ、Cisco CallManager サーバ、ISN サーバの台数と型番が変更可能です。さらにこの配置モデルでは、LAN/WAN インフラストラクチャ、音声ゲートウェイ、PSTN トランク、冗長性なども変更可能な要素です。セルフサービス、フリー ダイヤル コール、小規模サイトのサポートなどのために、集中処理とゲートウェイを追加できます。そのほか、プレルーティング PSTN ネットワーク インターフェイス コントローラ（NIC）も選択可能です。
• ISN サーバの設置場所は、中央でもリモートでもかまいません。ISN サーバの位置に関係なく、コール処理とキューイングは分散され、ローカルのゲートウェイで実行されます。図2-5 では ISN を中央に配置しています。
• 各独立サイトは、Cisco CallManager クラスタごとに最大 2,000 人のエージェントを置ける規模まで拡張できます。また、企業全体の単一コンタクト センターを形成するために ICM セントラル コントローラで組み合わせ可能なサイトの数に、ソフトウェア上の制限はありません。
• 必要に応じて、VoIP トラフィックのすべてまたはほとんどを、各サイトの LAN の範囲で扱うことができます。サイト間で音声コールを転送するには QoS WAN が必要です。しかし、Takeback N Transfer のような PSTN 転送サービスを利用すればそれも必要ありません。それが必要と判断すれば、特定のサイトに着信したコールの一部を他のサイトのエージェント リソースで処理できるようにキューイングして、顧客サービス レベルを向上させることができます。
• ICM プレルーティングを使用して需要が多いサイトへのコールをロード バランシングし、VoIP トラフィックによる WAN の使用率を下げることができます。
• いずれか 1 か所のサイトで障害が発生しても、他のサイトの運用に影響はありません。
• ICM セントラル コントローラにより、企業内ですべてのコールをルーティングするための設定を集中管理できます。
• ICM セントラル コントローラにより、企業全体の単一キューを作成する機能が提供されます。
• ICM セントラル コントローラにより、すべてのサイトに対する一括レポート処理が可能です。
• Cisco CallManager PG と Cisco CallManager クラスタを同じ場所におく必要があります。また、ISN PG と ISN サーバを同じ場所におく必要があります。
• ICM セントラル コントローラから PG への通信リンクは適切なサイジングを実施し、帯域幅と QoS をプロビジョニングする必要があります。シスコでは、VRU PG と ICM 間に必要な帯域幅を計算するためのパートナー ツールとして、VRU Peripheral Gateway to ICM Central Controller Bandwidth Calculator を用意しています。このツールは、次の URL からオンラインで入手できます。
http://www.cisco.com/partner/WWChannels/technologies/resources/IPCC_resources.html
• PG と ICM セントラル コントローラ間の通信リンクが失われると、そのサイトではコールに対するコンタクト センターのルーティング機能も失われます。したがって、耐障害性を備えた WAN の実装が重要になります。耐障害性を備えた WAN を実装していても、ICM セントラル コントローラと PG 間の通信が失われた場合に備え、コール処理とルーティングについて緊急時計画を策定しておくことが重要です。
• ICM セントラル コントローラとリモート PG 間の遅延は片道で 200 ミリ秒以下（往復で 400 ミリ秒以下）でなければなりません。
処理とキューイング
コールはリモート ゲートウェイで ISN によってキューイングおよび処理されるので、中央サイトで音声トラフィックの処理を終了させる必要がありません。ISN サーバは、中央サイトに配置できるほか、リモート サイトに分散配置することもできます。ここでも、他の場所にいるエージェントが関与する転送と会議に合わせて、WAN の帯域幅をプロビジョニングする必要があります。
IP IVR と異なり、ISN ではコール レッグはいったん切断された後、接続し直されます。これにより、ヘアピン ルーティングを避けることができます。IP IVR では、2 つの独立したコール シグナリング制御パスが、2 つのクラスタ間でそのまま維持されます（これによりヘアピン ルーティングが生成され、インタークラスタ トランクの数が 2 つ減少します）。
転送
サイト内の転送は、単一サイトでの転送と同様に機能します。Cisco CallManager クラスタ間の転送では、VoIP WAN または PSTN サービスを利用します。
VoIP WAN を使用する場合は、インタークラスタ トランクを十分に設定する必要があります。サイト間のコール ルーティングでは、VoIP WAN を使用する代わりに、PSTN 転送サービスを利用することもできます。このサービスを利用すると、IPCC 音声ゲートウェイから DTMF トーンをパルス出力し、PSTN に対して、他の音声ゲートウェイが設置された場所にコールを再ルーティング（転送）するよう指定できます。もう 1 つの方法として、サイト 1 の Cisco CallManager クラスタから逆に PSTN にアウトバウンド コールを送信する方法があります。そのコールは PSTN からサイト 2 にルーティングされます。ただし、サイト 1 ではコールの残りを処理するために 2 つの音声ゲートウェイ ポートが使用されます。
分散型 ICM オプションを採用した分散型のコール処理モデル
図2-6 に、この配置モデルを示します。
図2-6 IP-IVR を使用した場合の分散型 ICM オプション
分散型 ICM オプションの主な利点は、ICM セントラル コントローラを 2 個所のサイトに配置することで得られる冗長性です。
• ICM セントラル コントローラ（Router と Logger）は、2 つの冗長サイト間でプライベート通信を行うための専用リンクを備えている必要があります。非分散型 ICM モデルの場合、プライベート トラフィックは通常、ICM セントラル コントローラのサイド A コンポーネントとサイド B コンポーネントを直接接続するイーサネット クロスケーブル、つまり LAN 上を流れます。一方、分散型 ICM モデルでは、サイド A の ICM コンポーネントとサイド B の ICM コンポーネント間のプライベート通信は、T1 のような専用リンクを媒介とする必要があります。
• プライベート専用リンクの遅延は片道で 100 ミリ秒以下（往復で 200 ミリ秒以下）でなければなりません。
• ICM セントラル コントローラとリモート PG 間の遅延は片道で 200 ミリ秒以下（往復で 400 ミリ秒以下）でなければなりません。
• プライベート リンクは、パブリックなトラフィックとパスを共用できません。プライベート リンクは、パス ダイバーシティを必要とするので、ICM のパブリックなトラフィックから完全に独立したパスを持つリンクに存在する必要があります。
WAN 経由のクラスタリング
IPCC で WAN 経由のクラスタリングを使用すると、中央サイトの停止に備え、エージェントは完全な冗長性を持つことができます。IPCC に対する WAN 経由のクラスタリングの実装には、他のモデルの場合とは異なる厳格な要件がいくつかあります。ICM のパブリック トラフィックとプライベート トラフィック、Cisco CallManager のイントラクラスタ コミュニケーション（ICC）、および他の音声関連のメディアとシグナリングすべてを処理できるように、QoS を有効にして中央サイト間の帯域幅を適切にプロビジョニングする必要があります。独立した ICM（PG およびセントラル コントローラ）のプライベート リンクを使用して、中央サイト間の WAN に高アベイラビリティ（高可用性、HA）を確保するようにします。
• 中央サイト全体の停止につながるようなシングル ポイント障害が発生しません。
• サイトやリンクが停止しても、リモート エージェントの業務を維持するための再設定が必要になることがありません。サイトやリンクが停止すると、エージェントとそのデバイスは自動的に冗長サイトに接続されます。
• ICM と Cisco CallManager の両方に対するセンター集中管理が可能です。
• 中央サイト間に設置する高アベイラビリティ（HA）WAN は、シングル ポイント障害がなく、完全冗長であることが必要です（サイト間の冗長性オプションの詳細は、 http://cisco.com/go/srnd で入手できる、WAN インフラストラクチャと QoS の設計ガイドを参照してください）。高アベイラビリティ WAN で部分的な障害が発生した場合に備え、冗長リンクには、すべての QoS パラメータを満足させた状態で、中央サイトが受け持つすべての負荷を処理できる能力が必要です。詳細は、「WAN 経由の IPCC クラスタリングに対する帯域幅と QoS の要件」を参照してください。
• ポイントツーポイント テクノロジを採用した高アベイラビリティ（HA）WAN は、2 つの独立したキャリアにわたる実装に最適です。ただし、リング テクノロジを採用する場合、これは必ずしも必要ではありません。
• 高アベイラビリティ（HA）WAN で発生する遅延に対する要件は、WAN 経由のクラスタリングに対する現在の Cisco IP テレフォニーの要件を満たす必要があります。現在許容されている遅延は、片道 20 ミリ秒以下（往復で 40 ミリ秒以下）です。この遅延は、理想的な条件下での送信距離で約 3,000km に相当します。この送信距離は、遅延の原因となる別のネットワーク条件が発生することで短くなります。仕様の詳細は、次の URL にある『Cisco IP Telephony Solution Reference Network Design (SRND)』を参照してください。
• IP テレフォニーの要件に適合することで、IPCC の遅延に対する要件を満たします。ただし、Cisco CallManager のイントラクラスタ コミュニケーションで必要な帯域幅は、IPCC の場合と IP テレフォニーの場合では異なります。詳細は、「WAN 経由の IPCC クラスタリングに対する帯域幅と QoS の要件」を参照してください。
• 高アベイラビリティ（HA）WAN での帯域幅要件には、以下に示す通信に対する帯域幅と QoS のプロビジョニングが含まれます（「WAN 経由の IPCC クラスタリングに対する帯域幅と QoS の要件」を参照）。
–Cisco CallManager のイントラクラスタ コミュニケーション（ICC）
–CTI オブジェクト サーバ（CTI OS）を使用している場合は、CTI OS と CTI サーバ間の通信
• パス ダイバーシティを実現するには、ICM セントラル コントローラのサイド A とサイド B の間、および PG のサイド A とサイド B の間に、ICM プライベート通信専用の独立したリンクが必要です。ICM のアーキテクチャ上、パス ダイバーシティが必要になります。パス ダイバーシティがないと、パブリック通信とプライベート通信が重複する障害が発生する可能性があります。一時的にではあっても重複の障害が発生すると、ICM が不安定となり、データが失われることがあります。Logger データベースが破損する場合もあります。
• 専用プライベート リンクは、セントラル コントローラのプライベート通信用と Cisco CallManager PG のプライベート通信用の 2 つの独立した専用リンクで構成できます。また、セントラル コントローラと PG のプライベート通信を 1 つのリンクにまとめて、専用プライベート リンクとすることも可能です。詳細は、「サイト間 ICM プライベート通信のオプション」を参照してください。
• エージェントのサイトから各中央サイトの間には、独立したパスが存在している必要があります。どちらのパスにも、一方のパスに障害が発生した場合に備え、シグナリング、メディアなどのすべてのトラフィックの全負荷を処理できる能力が必要です。これらのパスは、複数の相手先固定接続（PVC）を使用したフレーム リレーなどの WAN テクノロジによって、エージェント サイト側と同一の物理リンク上に置くことができます。
• 処理とキューイングのプラットフォームとして IP IVR を使用するクラスタの最小サイズは、5 ノードです（パブリッシャが 1 ノード、登録者が 4 ノード）。各サイトの IP IVR が、WAN を経由せずにローカルでクラスタへの冗長接続を実現するためには、この最小サイズが必要です。Cisco CallManager と IP IVR 間の WAN を経由した JTAPI 接続はサポートされていません。ローカル ゲートウェイでも、Cisco CallManager へのローカル冗長接続が必要です。
• 処理とキューイングのプラットフォームとして ISN を使用するクラスタの最小サイズは、3 ノードです（パブリッシャが 1 ノード、登録者が 2 ノード）。ただし、特に、ローカルへのフェールオーバー機能を必要とする中央サイト、中央集中ゲートウェイ、または中央集中メディア リソースにローカル接続された IP Phone（コンタクト センターのものであるかどうかに関係なく）が存在する場合は、最小ノード数を 5 とすることをお勧めします。
集中型音声ゲートウェイにおける処理とキューイングを IP IVR で行う場合
このモデルでは、音声ゲートウェイが中央サイトに配置されています。それぞれのサイトに IP IVR が集中配置され、コールの処理とキューイングに使用されます。図2-7 は、このモデルを示しています。
図2-7 IP IVR を使用した集中コール処理とキューイングの機能を持つ集中型音声ゲートウェイ
• コールはローカルで処理およびキューイングされるので、WAN 接続を経由してキューイングする必要がありません。
• 音声、制御、CTI に合わせ、エージェント サイトへの WAN 接続の帯域幅をプロビジョニングする必要があります。詳細は、「WAN 経由の IPCC クラスタリングに対する帯域幅と QoS の要件」を参照してください。
• リモート サイトでは、ローカルでのコール発信と緊急連絡（119、110）利用のためにローカルの音声ゲートウェイが必要になることがあります。詳細は、次の URL にある『Cisco IP Telephony Solution Reference Network Design (SRND)』を参照してください。
• ロード バランシングされた配置の場合、中央サイトが停止すると着信ゲートウェイの機能の半分が失われることになります。一方のサイトに障害が発生した場合に備え、ゲートウェイと IVR は単独のサイトですべての負荷を処理できる規模にしておくことが必要です。
• サイトやゲートウェイの機能が失われた場合は、キャリアのコール ルーティングにより、コールが代替のサイトにルーティングされる必要があります。プレルーティングはロード バランシングに有効ですが、障害が発生している中央サイトにもコールがルーティングされる可能性があります。したがって、プレルーティングはお勧めできません。
集中型音声ゲートウェイにおける集中型のコール処理とキューイングを ISN で行う場合
このモデルの音声ゲートウェイは、中央サイトに配置された Voice XML（VXML）ゲートウェイです。ISN が集中配置され、コールの処理とキューイングに使用されます。図2-8 にこのモデルを示します。
図2-8 集中型音声ゲートウェイにおける集中型のコール処理とキューイングを ISN で行う場合
• コールはローカルで処理およびキューイングされるので、WAN 接続を経由してキューイングする必要がありません。
• プライマリ ルート ポイントは ISN なので、Cisco CallManager にかかる負荷が軽減されます。これにより、IP IVR による実装に比べてクラスタ当たりのスケーラビリティを高めることができます。詳細は、「IPCC のコンポーネントとサーバのサイジング」を参照してください。
• 音声、制御、CTI に合わせ、エージェント サイトへの WAN 接続の帯域幅をプロビジョニングする必要があります。詳細は、「WAN 経由の IPCC クラスタリングに対する帯域幅と QoS の要件」を参照してください。
• リモート サイトでは、ローカル コールの発信と緊急連絡（119、110）利用のために、ローカルの音声ゲートウェイが必要になることがあります。
分散型音声ゲートウェイにおける分散型のコール処理とキューイングを ISN で行う場合
このモデルの音声ゲートウェイは、エージェントの場所に分散配置された VXML ゲートウェイです。リモート ゲートウェイに ISN が集中配置され、コールの処理とキューイングに使用されます。図2-9 にこのモデルを示します。
図2-9 分散型音声ゲートウェイにおける分散型のコール処理とキューイングを ISN で行う場合
• 着信コールと着信ゲートウェイが、そのローカル エージェントを重点的にサポートするようにプロビジョニングされていれば、WAN リンク上の音声 RTP トラフィックはゼロあるいは最小限になります。他のサイトへの転送と会議は、WAN 上を流れます。
• コールはエージェント サイトで処理およびキューイングされるので、WAN 接続を経由してキューイングする必要がありません。
• 市内電話の着信と発信は、緊急連絡（119、110）も含め、ローカル VXML ゲートウェイを共有できます。
• プライマリ ルート ポイントは ISN なので、Cisco CallManager にかかる負荷が軽減されます。これにより、IP IVR による実装に比べてクラスタ当たりのスケーラビリティを高めることができます。詳細は、「IPCC のコンポーネントとサーバのサイジング」を参照してください。
• 分散型ゲートウェイでは、集中型ゲートウェイの場合に加え、最小限のメンテナンスと管理を追加で実行する必要があります。
• ISN のメディア サーバは、中央に配置してもエージェント サイトに配置しても、どちらでもかまいません。ゲートウェイのフラッシュからメディアを実行することもできます。メディア サーバをエージェント サイトに配置することで、帯域幅の要件を軽減できますが、非集中型モデルに対する要件は増加します。
サイト間 ICM プライベート通信のオプション
ICM プライベート通信は、ICM コンポーネント間のパブリック通信から分離されたパスを流れる必要があります。このパス分離のために、デュアル リンクとシングル リンクという 2 種類のオプションがあります。
デュアル リンクを経由する ICM セントラル コントローラのプライベート トラフィックと Cisco CallManager PG のプライベート トラフィック
図2-10 に示すデュアル リンクでは、ICM セントラル コントローラのプライベート トラフィックが、VRU/CM PG のプライベート トラフィックから分離されています。
図2-10 デュアル リンクを経由する ICM セントラル コントローラのプライベート トラフィックと Cisco CallManager PG のプライベート トラフィック
• 1 つのリンクに障害が発生しても、ICM セントラル コントローラと PG の両方がシンプレックス モードになることはありません。これにより、システムが停止する可能性が二重故障の水準程度にまで低くなります。
• QoS の設定がリンクごとに 2 種類に制限されるので、リンクの設定とメンテナンスが簡素化されます。
• 配置モデルとコール フローのサイズ再設定や変更があっても、その影響が及ぶのは 1 つのリンクだけです。これにより、正常な機能を確保するために必要な QoS とサイズの変更が少なくなります。
• コール フローや設定に対して予期しない変更（誤設定など）が発生しても、独立したプライベート リンクで問題が発生する可能性が低くなっています。
• リンクは、独立した専用回線を利用する必要があります。ただし、これらのリンクに冗長性は不要です。また、お互いに一方のリンクに対する冗長性を持たないようにします。
• コールの負荷、コール フロー、配置の設定を大幅に変更する場合は、事前にリンクのサイズと設定の妥当性を確認しておく必要があります。
• リンクは専用回線であることが必要です。高アベイラビリティ（HA）WAN に設定したトンネル回線は使用しないでください。パス ダイバーシティの詳細は、「WAN 経由のクラスタリング」の冒頭にある「ベスト プラクティス」を参照してください。
シングル リンクを経由する ICM セントラル コントローラのプライベート トラフィックと Cisco CallManager PG のプライベート トラフィック
図2-11 に示すシングル リンクでは、ICM セントラル コントローラのプライベート トラフィックと VRU/CM PG のプライベート トラフィックの両方が流れます。デュアル リンク実装に比べると、シングル リンク実装は普及しており、低い費用で実現できます。
図2-11 シングル リンクを経由する ICM セントラル コントローラのプライベート トラフィックと Cisco CallManager PG のプライベート トラフィック
• メンテナンスするリンク数が少なくて済みます。ただし、複雑さは増加します。
• リンクを冗長化する必要はありません。冗長リンクを使用する場合は、フェールオーバー時の遅延を 500 ミリ秒以下に抑える必要があります。
• セントラル コントローラおよび PG で発生する高優先順位通信に対しては、QoS 分類と予約された帯域幅が別途必要になります。詳細は、「帯域幅のプロビジョニングおよび QoS に関する考慮事項」を参照してください。
• コールの負荷、コール フロー、配置の設定を大幅に変更する場合は、事前にリンクのサイズと設定の妥当性を確認しておく必要があります。これは、シングル リンク モデルでは特に重要です。
• リンクは、高アベイラビリティ（HA）WAN から完全に分離された専用回線であることが必要です。高アベイラビリティ（HA）WAN に設定したトンネル回線は使用しないでください。パス ダイバーシティの詳細は、「WAN 経由のクラスタリング」の冒頭にある「ベスト プラクティス」を参照してください。
WAN 経由の IPCC クラスタリングに対する帯域幅と QoS の要件
リンクの適切なサイジングと、そのリンク内での帯域幅の予約のために、帯域幅をプロビジョニングする必要があります。次の各セクションでは、ICM プライベート トラフィック、ICM パブリック トラフィック、Cisco CallManager、CTI トラフィックに対する帯域幅の要件を詳しく説明しています。
高アベイラビリティ WAN
すべての ICM パブリック通信、CTI 通信、および Cisco CallManager のイントラクラスタ コミュニケーション（ICC）で使用される帯域幅を、高アベイラビリティ（HA）WAN 上で保証する必要があります。さらに、高アベイラビリティ WAN を流れるあらゆるコールで使用される帯域幅を保証することも必要です。高アベイラビリティ WAN ですべての IPCC シグナリングを扱うために最低限必要な全帯域幅は、2Mbps です。
QoS の設計とプロビジョニングの詳細は、次の URL にある QoS 設計ガイドを参照してください。
次の各接続について、シグナリング通信を保証する必要があります。
• 「ICM セントラル コントローラと Cisco CallManager PG 間の通信」
• 「ICM セントラル コントローラと IP IVR PG 間または ISN PG 間の通信」
• 「IP IVR PG または ISN PG と IP IVR または ISN 間の通信」
• 「Cisco CallManager のイントラクラスタ コミュニケーション（ICC）」
ICM セントラル コントローラと Cisco CallManager PG 間の通信
シスコでは、Cisco CallManager PG と ICM 間に必要な帯域幅を計算するためのパートナー ツールとして、ACD/CallManager Peripheral Gateway to ICM Central Controller Bandwidth Calculator を用意しています。このツールは、次の URL からオンラインで入手できます。
http://www.cisco.com/partner/WWChannels/technologies/resources/IPCC_resources.html
ICM セントラル コントローラと IP IVR PG 間または ISN PG 間の通信
ICM セントラル コントローラと IP IVR PG 間に必要な帯域幅を計算するためのパートナー ツールも用意されています。このツールは、シスコのパートナーと社員向けに次の URL で入手できます。
http://www.cisco.com/partner/WWChannels/technologies/resources/IPCC_resources.html
現在のところ、ICM セントラル コントローラと ISN PG 間の通信を扱う専用のツールは存在しません。ただし、テストによれば、ICM セントラル コントローラと IP IVR 間リンク向けのツールを使用すれば、正確な計算結果が得られることがわかっています。正確な値を得るには、「Average number of RUN VRU script nodes」（RUN VRU スクリプト ノードの平均数）というフィールドを、「Number of ICM script nodes that interact with ISN」（ISN と対話する ICM スクリプト ノードの数）に置き換えて考えます。
IP IVR PG または ISN PG と IP IVR または ISN 間の通信
現在のところ、IP IVR PG または ISN PG と IP IVR または ISN 間の通信を扱う専用のツールは存在しません。ただし、この前の 2 つのセクションで紹介したツールを使用すれば、この通信に必要な帯域幅を妥当な精度で計算できます。ICM セントラル コントローラと IP IVR PG 間または ISN PG 間の通信で消費される帯域幅は、IP IVR PG または ISN PG と IP IVR または ISN 間の通信で消費される帯域幅にかなり近い数値となります。
このツールは、シスコのパートナーと社員向けに次の URL で入手できます。
http://www.cisco.com/partner/WWChannels/technologies/resources/IPCC_resources.html
IP IVR PG または ISN PG が WAN を介して分割されている場合、必要な全帯域幅は、ICM セントラル コントローラと IP IVR PG 間または ISN PG 間の値と、IP IVR PG または ISN PG と IP IVR または ISN 間の値を加算した数値となります。
PG 間のパブリック通信は最小限の「相互間のテスト」メッセージで構成され、PG のペアごとに約 10kbps の帯域幅を消費します。
CTI OS と CTI サーバ間の WAN リンクで帯域利用率が最大となるのは、CTI OS と CTI サーバがお互いに遠く離れた場所に存在する場合です。このような場合は、帯域幅のキューを利用してアベイラビリティを保証するようにします。
このモデルの場合、次の簡単な数式を使用すると、ワーストケースで必要な帯域幅を計算できます。
• Extended Call Context（ECC; 拡張コール コンテキスト）変数もコール変数も存在しない場合
• ECC 変数またはコール変数（あるいはその両方）が存在する場合
BHCA ∗（20 +（（変数の個数 ∗ 変数の平均長さ）/40）= bps
例： BHCA の値が 10,000 で、平均長さ 40 の ECC 変数が 20 個ある場合は、次のようになります。
10,000 ∗ (20 + ((20 ∗ 40) / 40) = 10,000 ∗ 40 = 400,000 bps = 400 kbps
Cisco CallManager のイントラクラスタ コミュニケーション（ICC）
『Cisco IP Telephony Solution Reference Network Design (SRND)』では、10,000 の BHCA ごとに 900kbps の帯域幅を予約するように指定しています。 この値は、イントラクラスタ コミュニケーションで扱われるコール リダイレクト数と追加で発生する CTI/JTAPI 通信の数を考慮すると、IPCC ではかなり高い帯域幅となります。
10,000 の BHCA ごとに予約が必要な帯域幅は、約 2,000kbps（2Mbps）です。この要件は、この IPCC 設計ガイドの推奨事項に基づいて適切な設計と配置が行われていることを前提としたものです。サイト 1 への着信コールがサイト 2 で処理されるような効率の低い設計では、余分なイントラクラスタ コミュニケーションが発生するため、ここで定義されている要件では不十分なこともあります。
ICM プライベート WAN
表2-1 は、リンク サイズとキュー サイズの計算に便利なワークシートです。この表に続いて、定義と例を示します。
（注） どの場合でも、リンクの最小サイズは 1.5Mbps（T1）です。
|
|
|
|
|
|
|
|
|---|---|---|---|---|---|---|
|
|
||||||
| これらのうち 3 つの値を加算し、その合計を下のグレー背景のボックスに記入して、PG の高優先度キューのサイズとします。 |
||||||
|
|
|
プライベート通信に使用するサイト間で専用リンクを 1 つ使用している場合は、すべてのリンク サイズを合算し、 表2-1 の最下行にある合計リンク サイズに記入して要件として使用します。Router/Logger プライベートに 1 つのリンク、PG プライベートに 1 つのリンクを使用した独立リンクの場合は、最初の行を Router/Logger の要件に使用し、その下の 4 行のうち 3 行の値を合算して PG プライベートの要件に使用します。
WAN を介して分割されている類似のコンポーネントすべてに対する実効 BHCA（実効負荷）は、次のように定義されます。
この値はコール センターに対する BHCA の合計で、会議と転送も含まれます。たとえば、BHCA の着信数が 10,000 で、これに 10 % の会議または転送を加味すると、実効 BHCA は 11,000 になります。
この値には、Cisco CallManager で制御されている ICM ルート ポイントを通じて着信するすべてのコール、および最終的にエージェントに転送されるすべてのコールが含まれます。これは、各コールがルート ポイントに着信し、最終的にエージェントに送信されることを前提としています。たとえば、ルート ポイントに着信してエージェントに転送される BHCA 着信コールが 10,000 で、これに 10 % の会議または転送を加味すると、実効 BHCA は 11,000 になります。
この値は、コール処理とキューイングに対する BHCA の合計です。たとえば、BHCA 入力コールが 10,000 で、これらすべてが処理され、うち 40 % がキューイングされると、実効 BHCA は 14,000 になります。
この値は、ISN 経由の着信に対するコール処理とキューイングの BHCA の合計です。計算では、すべてのコールが処理されることを前提としています。たとえば、BHCA 着信コールが 10,000 で、これらすべてが処理され、うち 40 % がキューイングされると、実効 BHCA は 14,000 になります。
この値は、コール変数と ECC 変数の数、および IP IVR と ISN のうち実装に使用されているテクノロジを通じてルーティングされるすべてのコールに関連する変数長を示しています。
表2-2 は、次の特性を持つ、組み合せた専用プライベート リンクの計算例を示しています。
• コンタクト センターに着信するコールの BHCA は 10,000 です
• コールの 100 % が IP IVR で処理され、うち 40 % がキューイングされます。
• コールは放棄されない限り、すべてエージェントに送信されます。エージェントへのコールのうち、10 % は転送または会議です。
• コールを処理およびキューイングする IP IVR は 4 つで、これらは 1 つの PG でサポートされています。
• 合計 900 名のエージェントに対して 1 ペアの Cisco CallManager PG が設置されています。
• コールには、40 バイトのコール変数が 10 個と、40 バイトの ECC 変数が 10 個あります。
|
|
|
|
|
|
|
|
|---|---|---|---|---|---|---|
|
|
||||||
| これらのうち 3 つの値を加算し、その合計を下のグレー背景のボックスに記入して、PG の高優先度キューのサイズとします。 |
||||||
|
|
|
この例にある組み合わせた専用プライベート リンクの計算結果は次のとおりです。
• Router と Logger の高優先度帯域幅キュー = 297,000bps
• PG の高優先度帯域幅キュー = 1,888,000bps
Router/Logger プライベートと PG プライベートに独立した 2 つのリンクでこの例を実装すると、リンク サイズとキューは次のようになります。
• Router/Logger リンクは 330,000bps で（前述のとおり、実際の最小リンクは 1.5Mb）、高優先度帯域幅キューは 297,000bps です。
WAN 経由の IPCC クラスタリングの障害分析
このセクションでは、IPCC で実行している WAN 経由のクラスタリングで特定の障害が発生したときの動作について説明します。この配置モデルでは、高アベイラビリティ（HA）WAN の安定性がきわめて重要です。高アベイラビリティ WAN で発生する障害は、通常発生する障害と同列には扱えないと考えられています。
このセクションで扱う配置モデルの概要については、「WAN 経由のクラスタリング」で示した図を参照してください。
中央サイト全体の喪失
中央サイト全体の喪失とは、サイトの電源が切断された場合のように中央サイトとの通信がすべて失われた状態をいいます。この障害の主な原因として考えられるのは、自然災害、電源の問題、重要な接続に発生した問題、人為的なミスなどです。中央サイトとの接続が部分的に失われている場合は、サイトの喪失ではなく、接続の部分的な喪失です。このシナリオについては、この次のセクションで扱います。
WAN 経由の IPCC クラスタリングが中央サイト全体で完全に失われると、リモート エージェントは冗長サイトに適切にフェールオーバーされます。フェールオーバーに要する時間は、エージェントから見て 1 ～ 60 秒の範囲で変わります。この時間の違いは、エージェントの人数、電話の登録場所、エージェントが使用しているデスクトップ サーバの違いによるものです。
分散 VXML ゲートウェイと ISN を使用している場合に、このゲートウェイのプライマリ サイトが失われたとき、ゲートウェイはあるサイトから別のサイトにフェールオーバーする必要があります。このフェールオーバーには約 30 秒の時間がかかります。したがって、この 30 秒の間にリモート ゲートウェイに着信したコールは失われます。
サイト 1 とサイト 2 の間のプライベート接続
ICM セントラル コントローラのサイド A とサイド B の間のプライベート接続に障害が発生すると、どちらかの ICM Router はサービスを停止し、残った ICM Router はリンクが復旧するまでシンプレックス モードで動作します。この状況が原因でコールの損失や障害が発生することはありません。
PG のサイド A とサイド B の間のプライベート接続に障害が発生すると、非アクティブな PG はサービスを停止し、アクティブな PG はリンクが復旧するまでシンプレックス モードで動作します。この状況が原因でコールの損失や障害が発生することはありません。
組み合わせたプライベート リンクを使用している場合、このリンクが失われると、ICM セントラル コントローラと PG のプライベート接続が失われます。その結果、両方のコンポーネントの動作は、前述のシンプレックス モードに切り替わります。この状況が原因でコールの損失や障害が発生することはありません。
リモート エージェント サイトから中央サイトへの接続
いずれかの中央サイトへの接続がリモート エージェント サイトから失われると、すべての電話とエージェント デスクトップはただちに別の中央サイトに接続され、コールの処理が再開されます。通常、フェールオーバーには 1 ～ 60 秒の時間がかかります。
高アベイラビリティ WAN の障害
名前の定義上は、通常の状況で高アベイラビリティ（HA）WAN に障害は発生しません。本来のとおりに HA WAN がデュアル パス構成を持ち、完全冗長であれば、このタイプの障害の発生はきわめてまれです。このセクションでは、このようにきわめてまれなシナリオで発生する現象について説明します。
その原因に関係なく、HA WAN が失われると、Cisco CallManager クラスタは分割されます。この障害によって重点的に発生する問題は、エージェントの電話の半分と ICM との接続が失われるということです。ICM から通信できるのはクラスタの半分だけとなり、残りの半分に登録されている電話とは通信できないか、場合によっては認識もできなくなります。その結果、ICM から認識できなくなっている電話を使用しているすべてのエージェントは、ただちにログアウトされます。これらのエージェントは、高アベイラビリティ WAN が復元されるか、使用している電話の接続先クラスタ サイドを切り替えない限り、ログインして復帰することはできません。
ブロードバンド経由のリモート エージェント
IPCC を採用している企業では、そのネットワークで、Cisco IP Phone を使用しているリモート在宅エージェントをサポートすることが必要になる場合があります。このセクションでは、デスクトップ ブロードバンドによる Asymmetric Digital Subscriber Line（ADSL; 非対称デジタル加入者線）またはケーブル接続をリモート ネットワークとして使用して配置できる IPCC リモート エージェント ソリューションについて説明します。
Cisco Voice and Video Enabled IPSec VPN（V3PN）の ADSL 接続またはケーブル接続では、Cisco 830 シリーズのルータをブロードバンド ネットワークのエッジ ルータとして使用します。Cisco 830 シリーズのルータは、V3PN、暗号化、Network Address Translation（NAT）、ファイアウォール、IOS Intrusion Detection System（IDS; 侵入検知システム）、および QoS を、IPCC キャンパスとのブロードバンド ネットワーク リンク上でリモート エージェントに提供します。キャンパスでのリモート エージェントの V3PN 集約は、LAN 間 VPN ルータを介して提供されます。
• コンタクト センター企業では、リモート エージェントの配置により経費節減を図ることができ、その結果、Return On Investment（ROI; 投資回収率）が向上します。
• リモート エージェントは、標準的な IPCC のエージェント デスクトップ アプリケーションを使用して配置できます。このアプリケーションとしては、Cisco CTI OS、Cisco Agent Desktop、Customer Relationship Management（CRM; 顧客関係管理）デスクトップなどがあります。
• このモデルは、ADSL またはケーブルのブロードバンド ネットワークで機能します。
• エージェントのデスクトップをブロードバンドで常時接続することにより、ホーム オフィスで企業 LAN を使用するための安全な拡張機能が得られます。
• 在宅エージェントはそのホーム オフィスで、IPCC 企業のコンタクト センターで作業する場合に使用しているものと同じ IPCC アプリケーションにアクセスでき、IPCC 機能のほとんどを利用できます。これらの機能には、コンタクト センターでの作業とまったく同じ方法でアクセスできます。
• このモデルは、IP Phone を使用して高品質な音声を実現し、既存のブロードバンド サービスを通じて音声と同時にエージェントのデスクトップにデータを提供します。
• IPCC 企業ユーザには VPN トンネルへのアクセスを提供して、認証機能を実現します。これにより、IPCC 在宅エージェントとその家族は、ブロードバンドによるケーブル接続や DSL 接続を安全に共有できます。
• 在宅エージェント ソリューションでは、低価格な Cisco 831 シリーズ ルータを使用します。
• このモデルは、Dynamic Host Configuration Protocol（DHCP; ダイナミック ホスト コンフィギュレーション プロトコル）または Point-to-Point Protocol over Ethernet（PPPoE）を介して、動的な IP アドレス割り当てをサポートしています。
• Cisco 831 シリーズのルータを使用することで、VPN トンネルの生成機能、エッジでの Quality of Service（QoS）、およびファイアウォールなどのセキュリティ機能が得られるので、管理するデバイス数を削減できます。
• 企業側では、CiscoWorks のような高いスケーラビリティと柔軟性を備えた管理製品を使用することで、リモート エージェントのルータを集中管理できます。
• このリモート エージェント ソリューションは、復元力、高いアベイラビリティ、および高いスケーラビリティのためのビルディングブロック手法のサイドで、Cisco IOS VPN ルータを基本にしています。このルータは、数千人もの在宅エージェントをサポートできます。
• データや音声を初めとするすべてのトラフィックは、Triple Data Encryption Standard（3DES）を使用して暗号化されます。
• このモデルは、既存の Cisco CallManager インストール環境の中で配置できます。
• 在宅エージェントでも、キャンパス エージェントと同じタイプの拡張機能を利用できます。
• 次の URL にあるドキュメンテーションに示されている、V3PN および Business Ready Teleworker の設計ガイドラインに従います。
http://www.cisco.com/go/teleworker
• 最小限の帯域幅限度を設定した G.729 を使用するようにリモート エージェントの IP Phone を設定します。G.711 コーデックを使用すれば、より高い音声品質を得ることができます。G.711 をサポートするために必要な最小帯域幅は、アップロード側で 512kbps です。
• NetFlow、サービス保証エージェント（SAA）、Internetwork Performance Monitor（IPM）など、障害マネジメント ツールとパフォーマンス マネジメント ツールを実装します。
• ワイヤレス アクセス ポイントがサポートされていますが、リモート エージェントによる利用の可否は、企業のセキュリティ ポリシーによって判断します。
• 1 世帯あたりでサポートされるリモート エージェントは 1 人だけです。
• DSP ハードウェア デバイスに会議ブリッジを設定することをお勧めします。DSP 会議ブリッジを使用すれば、会議の音声品質が損なわれることはありません。IP テレフォニーだけの配置であっても、これは推奨される解決策です。
• ブロードバンド ソリューションを介したリモート エージェントは、中央集中型の IPCC および Cisco CallManager クラスタだけでサポートされています。
• ADSL リンクやケーブル リンクでは障害が発生することがあります。バック アップ リンクがある場合は、ADSL モデムまたはケーブル モデム、Cisco 831 シリーズ ルータ、および IP Phone をリセットすることが必要な場合があります。リモート エージェントがこの作業を実行するには、トレーニングが必要です。
• ユニキャストの Music on Hold（MoH）ストリームだけがサポートされています。
• リモート エージェントのデスクトップ用に Domain Name System（DNS; ドメイン ネーム システム）のエントリを作成する必要があります。このエントリがないと、リモート エージェントは CTI サーバに接続できません。DNS のエントリは動的に更新できます。または、静的更新の際に入力できます。
• リモート エージェントのワークステーションと IP Phone は、Dynamic Host Configuration Protocol（DHCP; ダイナミック ホスト コンフィギュレーション プロトコル）を使用するように設定する必要があります。
• リモート エージェントのコンピュータに使用するオペレーティング システムには Windows XP Pro が必要です。さらに、XP リモート デスクトップ コントロールをインストールする必要があります。
• Cisco 7960 IP Phone には電源が必要です。Cisco 831 シリーズ ルータから、この IP Phone に電源は供給されません。
• 在宅エージェントが使用するブロードバンドの帯域幅として、アップロード側では 256kbps 以上、ダウンロード側では ADSL で 1.4Mbps 以上、ケーブルで 1Mbps 以上が必要です。実際の配置で、帯域幅が適切であることを確認してください。ケーブルで配置する場合は、回線が混雑する時間帯を考慮します。リンク速度が上記で指定された帯域幅以下に低下すると、クリッピングなどの音声品質上の問題が在宅エージェントに発生します。
• リモート エージェントと IPCC キャンパス間の往復遅延は、ADSL で 180 ミリ秒以下、ケーブルで 60 ミリ秒以下とする必要があります。この遅延が長くなると、音声ジッタ、会議ブリッジの問題、エージェントのデスクトップへの画面表示遅れなどが発生することがあります。
• Music on Hold サーバに G.729 コーデックのストリーミングが設定されていない場合は、外部の発信者が MoH を受信できるようにトランスコーダを設定する必要があります。
• Cisco Supervisor Desktop の場合、在宅エージェントの IP Phone を対象としたサイレント モニタリング、介入、代行受信、および音声録音では、スーパーバイザに対する制限があります。Cisco Agent Desktop（Enterprise および Express）の在宅およびキャンパスのスーパーバイザは、在宅エージェントを音声モニタできません。スーパーバイザが送受信できるのはテキスト メッセージだけです。また、どの在宅エージェントがオンラインになっているかを確認でき、それらエージェントをログ アウトできます。
• Cisco Agent Desktop を使用した IPCC Express ではデスクトップ ベースのモニタリングはサポートされていません。デスクトップ ベースのモニタリングは、IPCC Enterprise エディションでのみ適用できます。
• CTI OS Supervisor の在宅とキャンパスのスーパーバイザは、在宅エージェントに対するサイレント モニタ、介入、および代行受信が可能ですが、音声録音はできません。CTI OS の在宅とキャンパスのスーパーバイザは、テキスト メッセージの送受信、エージェントの準備、および在宅エージェントのログアウトが可能です。
• エージェントのデスクトップは、IP Phone の背面にある RJ45 ポートに接続します。この接続がないと、CTI OS Supervisor でエージェントの電話を音声モニタできません。
• Cisco IPCC と互換性のある IP Phone だけがサポートされています。互換性の詳細は、次のドキュメンテーションを参照してください。
http://www.cisco.com/univercd/cc/td/doc/product/icm/ccbubom/60bom.pdf
http://cisco.com/application/pdf/en/us/guest/products/ps1844/c1609/ccmigration_09186a008031a0a7.pdf
http://www.cisco.com/univercd/cc/td/doc/product/voice/sw_ap_to/apps_3_5/english/admn_app/rn35_2.pdf
• http://www.Broadbandreports.com には、ブロードバンドの回線速度のテスト方法が示されています。この Web サイトでは、アップロードとダウンロードの両方について、在宅エージェントの回線速度をテスト サーバから測定できます。
• V3PN についての質問は、ask-ese-vpn@cisco.com まで電子メールでお送りください。
Business Ready Teleworker Solution を介して配置された IP Phone を使用するリモート エージェント
このモデルでは、リモート エージェントの IP Phone とワークステーションが、VPN トンネルを介してメインの IPCC キャンパスに接続されています。リモート エージェントにルーティングされた顧客からのコールは、キャンパス エージェントにルーティングされた場合と同じように扱われます（図2-12を参照してください）。
図2-12 Business Ready Teleworker Solution を介して配置された IP Phone を使用するリモート エージェント
• 高速なブロードバンドにより、コスト効果の高いオフィス アプリケーションが実現します。
• 高度なセキュリティ機能により、企業 LAN をホーム オフィスまで拡張できます。
• CTI データ、高品質音声など、音声・データ統合デスクトップ アプリケーションを幅広くサポートしています。
• ケーブルでサポートされているブロードバンド接続速度は、アップロードで 256kbps 以上、ダウンロードで 1.0Mbps 以上です。
• ADSL では、アップロードで 256kbps 以上、ダウンロードで 1.4Mbps 以上のブロードバンド接続速度がサポートされています。
• エージェントのワークステーションは、動作クロックが 500MHz 以上で、512MB 以上の RAM を搭載している必要があります。
• IP Phone は、最低のブロードバンド接続速度でも G.711 を使用するように設定する必要があります。
• QoS は、Cisco 831 ルータのエッジだけで有効になります。現在のところ、サービス プロバイダーは QoS を提供していません。
• Cisco 831 シリーズのルータで、セキュリティ機能を有効にします。
• Cisco 7200 VXR および Catalyst 6500 IPSec VPN Services Module（VPNSM）を使用することで、エージェントは優れた LAN 間パフォーマンスを得られます。
• リモート エージェントの自宅にある電話は、緊急連絡（119、110）へ接続可能でなければなりません。
• リモート エージェントがログインしていて業務できる状態でも、電話に出られない場合は、Redirect On No Answer（RONA）機能が使用されるようにします。
IPCC アウトバウンド（ブレンディッド エージェント）オプション
エージェントがインバウンドとアウトバウンドの両方のコンタクトを処理できれば、コンタクト センターのリソースの最適化を図ることができます。多機能コンタクト センターで Cisco アウトバウンド オプションを使用すると、ICM による企業管理の利点を生かすことができます。アウトバウンド キャンペーン ソリューションを必要とするコンタクト センターの管理者は、エージェント リソースの全体を管理対象にできるという Cisco ICM Enterprise および Cisco IPCC Enterprise の特長を活用できます。
• IP ダイヤラは仮想 IP Phone を使用し、音声ゲートウェイから Cisco CallManager 経由でコールを発信します。このダイヤラはソフトウェアだけで構成されているソリューションであり、テレフォニー カードを必要としません。
• アウトバウンド オプション ソリューションは、次の 3 つの主要プロセスから構成されます。
–Campaign Manager プロセス：サイド A の Logger で実行され、企業内のすべてのダイヤラに設定と顧客レコードを送信します。
–インポート プロセス：顧客レコードと Do Not Call レコードをシステムにインポートします。
–ダイヤラ プロセス：ダイヤラ プロセスを複数使用することで、複数のサイトにある Campaign Manager サーバに接続できます。
• アウトバウンドの用途でエージェントを確保するには、ダイヤラごとに Media Routing PIM が必要です。
• アウトバウンド オプションのダイヤラはエージェントの CTI 管理のために CTI サーバとの接続を維持し、構成と顧客レコードのために Campaign Manager との接続を維持します。また、コールの発信と転送に使用する Skinny Client Control Protocol 接続のために Cisco CallManager との接続を維持し、エージェントの確保のために Media Routing PG との接続を維持します。
• アウトバウンド オプションのダイヤラ、IPCC PG、CTI サーバ、および CTI OS が 1 台のサーバに共存する設定で、最大 200 人のエージェント（インバウンドとアウトバウンドのエージェントの自由な組み合わせ）。
• PG サーバ上の CTI OS が 200 人以下のエージェント向けに設定されている状況で、1 つの PG 上で最大 300 人のエージェント（インバウンドとアウトバウンドのエージェントの自由な組み合わせ）。
図2-13 は、200 人以上のエージェントを配置した IPCC アウトバウンド オプションのモデルを示しています。
図2-13 200 人以上のエージェントを配置した IPCC アウトバウンド オプション
Cisco アウトバウンド オプションのダイヤラ ソリューションでは、エージェントは、ソフトウェアだけで構成された IP ベースのダイヤラを使用することで、アウトバウンド キャンペーンおよびインバウンド業務に参加できます。
要約すると、IPCC アウトバウンド オプションの主な利点は次のようになります。
• IPCC アウトバウンド オプションでは、IP ダイヤラを複数のコール センター サイトに配置することで、企業全体のダイヤリング機能が実現します。Campaign Manager サーバは、中央サイトに置かれます。
• このオプションでは、ICM アドミン ワークステーションから集中管理と集中設定が可能です。
• IPCC Release 6.0 以降では、留守番電話検出などの Enhanced Call Progress Analysis 機能が利用できます。
• このオプションにより、インバウンド コールとアウトバウンド コールを、正確にコールごとにブレンドできるようになります。
• このオプションでは、ICM スクリプト エディタを使用してアウトバウンド モードを制御し、アウトバウンド処理で使用するスキルを持つエージェントの比率を設定することで、アウトバウンド モードを柔軟に制御できます。
• IPCC Release 6.0 以降では、IVR モード（エージェント不要のキャンペーン）およびダイレクト プレビュー（Direct Preview）モードに転送できます。
• このオプションでは、アウトバウンド固有のレポート テンプレートによる統合 WebView レポートが可能です。
IPCC アウトバウンド オプションの実装では、次のガイドラインとベスト プラクティスに従ってください。
• メディア ルーティング PG が必要です。また、ダイヤラごとにメディア ルーティング PIM が必要です。
• 1 台の IPCC PG サーバに IP ダイヤラを 1 つインストールし、総数 200 人のブレンディッド エージェント（インバウンド、アウトバウンド、またはブレンディッド）に対応できます。1 つのペリフェラルに複数のダイヤラを配置することで、ある程度の耐障害性を実現できます。ただし、本来のホットスタンバイ モデルではありません。
• 顧客からのコールに対して、IP ダイヤラがサポートしているコーデックは G.711 音声コーデックだけです。G.729 コーデックが使用されている地域にアウトバウンド エージェントを配置することはできますが、コーデックの切り替えにより、エージェントと顧客間の転送に最長で 1.5 秒の時間差が発生することがあります。したがって、この方法はお勧めできません。
• IP ダイヤラは、そのダイヤラの登録先である Cisco CallManager クラスタに近い場所に配置する必要があります。
• アウトバウンド オプションで Cisco Media Termination 電話を使用すると、顧客からのコールをエージェントに転送する時間が 0.5 秒長くなることがあります。
• IPCC アウトバウンド オプションのダイヤラでテスト済みのゲートウェイは次のとおりです。
–Cisco AS5300、AS5350、および AS5400 シリーズ
• 特定のペリフェラルのアウトバウンド オプションのダイヤラはすべて、設定済みポートと同じ番号を持っている必要があります。
• アウトバウンド オプションのダイヤラで実行される膨大な件数のコール転送のために、Cisco CallManager サーバに対するパフォーマンス負荷が増大します。アウトバウンド オプションのダイヤラをインストールする際は、Cisco CallManager サーバのサイジングが適切であることを確認してください。また、Cisco CallManager サーバが過負荷にならないように、ダイヤラに対してコールを適切に制限する必要もあります。使用している特定の Cisco CallManager サーバに対する適切な制限値は、次の URL にある『Outbound Option Setup and Configuration Guide』を参照してください。
http://www.cisco.com/univercd/cc/td/doc/product/icm/icmentpr/icm60doc/icm6out/
アウトバウンド ソフトウェアのインストールと設定の詳細は、次のドキュメントを参照してください。
• 『 Cisco ICM/IP Contact Center Enterprise Edition Outbound Option Setup and Configuration Guide 』
• 『 Cisco ICM/IP Contact Center Enterprise Edition Outbound Option User Guide 』
上記のドキュメントはいずれも次の URL からオンラインで入手できます。
http://www.cisco.com/univercd/cc/td/doc/product/icm/icmentpr/icm60doc/icm6out/
従来の ACD の統合
従来の ACD を IPCC 配置に統合することが必要な企業には、次のような選択肢があります。従来の ACD サイトと IPCC サイトの間でコールをロード バランシングするには、プレルーティングのネットワーク インターフェイス コントローラ（NIC）を追加します（図2-14を参照してください）。この場合、ICM には PSTN サービス プロバイダーをサポートしている NIC が必要です。このシナリオでは、PSTN から NIC 経由で ICM セントラル コントローラに対し、最適なサイトを決定するための問い合せが行われます。ICM から PSTN への返答により、PSTN からどのサイトにコールを送信するかが指定されます。PSTN から ICM に提供されたあらゆるコール データが、エージェントのデスクトップ（従来の ACD または IPCC）に渡されます。
2 つのサイト（ACD サイトと IPCC サイト）間でコールを転送するために、PSTN 転送サービスを利用できます。PSTN 転送サービスを利用することにより、どちらのサイトでもコールのトランキングの重複がなくなります。PSTN 転送サービスを利用する代わりに、従来の ACD と IPCC 音声ゲートウェイの間に TDM 音声回線を配置する方法もあります。この環境では、コール発信元のサイトにコールバックが転送されると、2 つのサイト間にトランキングの重複が発生します。サイト間で追加の転送が行われるたびに、TDM 音声回線が追加で利用されます。
コールを PSTN からプレルーティングする代わりに、PSTN から 1 つのサイトだけにコールを送信する方法や、PSTN でプロビジョニングされたいくつかの静的ルールに基づいて、2 つのサイト間でコールを分割する方法があります。どちらかのサイトにコールが着信すると、そのコールを扱う最適なサイトを決定するために、従来の ACD または Cisco CallManager から ICM 宛てにルート要求が生成されます。コールのルーティング元である他方のサイトにいるエージェントにそのコールを送信する必要がある場合は、サイト間に TDM 回線が必要になります。コールをどこにルーティングするか、コールを転送するかどうか、およびコールをいつ転送するかは、企業のビジネス環境、目的、および原価構成で決定します。
従来の IVR の統合
従来の IVR を IPCC 配置に統合するには、いくつかの方法があります。以降のセクションで説明する数多くの要因を考慮してどの方法が最適かを決定します。重要な検討事項として、IVR からコールを転送するときに発生するトランキングの重複をどのように排除または低減するかという点があります。
PBX 転送の使用
多くのコール センターには、書き直されることが考慮されていない、従来からの既存 IVR アプリケーションが配置されています。これらの IVR アプリケーションを温存した上で IPCC 環境に統合するには、IVR に ICM へのインターフェイスを備える必要があります（図2-15を参照してください）。
ICM への IVR インターフェイスには 2 種類のバージョンがあります。1 つは単なるポストルーティング インターフェイスです。このインターフェイスでは、IVR から ICM にコール データ付きでポストルート要求を送信できます。ICM から IVR に、コールの転送を指示するルート応答が送信されます。このシナリオでは、従来の IVR は PBX 転送を呼び出し、そのポートをリリースしてコールを IPCC に転送します。IVR から渡されたあらゆるコール データは、ICM によってエージェントのデスクトップまたは IP IVR に渡されます。
ICM への IVR インターフェイスのもう 1 つは、シリアル ポート通信インターフェイス（SCI）です。SCI を使用すると、ICM からのキューイング指示を IVR で受け取ることができます。PBX モデルでは、SCI が不要です。
IVR が SCI インターフェイスを備えていても、すべてのコールのキューイングには IP IVR を配置することをお勧めします。それは、IP IVR を配置しておくことで、従来の IVR ポートを余分に使用せずに済むためです。さらに、キューイングに IP IVR を使用すれば、続いて実行する転送や RONA 処理でコールを再キューイングできるようになります。
PSTN 転送の使用
このモデルは、直前のセクションのモデルにきわめて似ています。違う点は、従来の IVR のポートをリリースするために IVR から呼び出されるものが PBX 転送ではなく、PSTN 転送であるという点です（図2-16を参照してください）。この場合も、従来の IVR ポートを余分に使用する必要がないように、また IVR でトランキングの重複が発生しないように、すべてのキューイングで IP IVR が使用されます。従来の IVR アプリケーションで収集されたあらゆるコール データは、ICM によってエージェントのデスクトップまたは IP IVR に渡されます。
図2-16 PSTN 転送を使用した、従来の IVR の統合
IVR でのトランキングの重複の使用
従来から使用している IVR アプリケーションの完成度が高く、ほとんどの発信者は従来の IVR によるセルフサービスで全面的にサポートされている場合を考えます。このような場合、エージェントに転送することが必要な発信者は限られた比率にとどまっているので、そのわずかな比率のコールを処理するためだけであれば、従来の IVR でトランク処理の重複が発生しても問題にならないことがあります（図2-17を参照してください）。前のセクションのモデルと異なり、従来の IVR が SCI インターフェイスを備えていれば、最初のコールのキューイングはその IVR で実行できます。これが有利なのは、IP IVR でコールをキューイングするために、別の従来の IVR ポートが使用されるためです。最初のキューイングを従来の IVR で実行することにより、そのコールの最初のキューイングで使用されるポートは、従来の IVR ポート 1 つだけで済みます。ただし、転送または RONA 処理の結果、続けて発生するキューイングは、トランキングの重複を避けるために IP IVR で実行する必要があります。従来の IVR が SCI インターフェイスを備えていない場合、その IVR では、コールの転送先を判断するため、ICM 宛てに単なるポストルーティング要求が生成されます。このシナリオでのキューイングはすべて、IP IVR で実行する必要があります。
図2-17 IVR でのトランキングの重複を使用した従来の IVR の統合
Cisco CallManager による転送と IVR でのトランキングの重複の使用
運用していく中で、従来の IVR アプリケーションから IP IVR へのマイグレーションが必要になることがあります。ただし、きわめて限定されたシナリオで従来の IVR アプリケーションを使用する必要性がわずかに残っている場合は、その IVR を追加の音声ゲートウェイに接続します（図2-18を参照してください）。PSTN から音声ゲートウェイに着信したコールは、Cisco CallManager によってルーティングされます。Cisco CallManager では、特定の DN を従来の IVR にルーティングできるほか、コールを従来の IVR に転送するタイミングを ICM または IP IVR で決定することもできます。従来の IVR にあるコールを IPCC エージェントに転送することが必要な場合、そのコールの接続中は、別の IVR ポート、トランク、および音声ゲートウェイ ポートが使用されます。複数のループが発生しない転送シナリオとなるように注意する必要があります。複数のループが発生すると、音声の品質が低下することがあります。
図2-18 Cisco CallManager による転送と IVR でのトランキングの重複を使用した従来の IVR の統合
フィードバック