 |
この章では、Cisco CallManager Release 3.0(5) を中央集中型コール処理に使用する、複数サイト WAN システムを設計するためのガイドラインを記述します。ここでは、中央集中型コール処理モデルに特有の問題について、このマニュアルの他のセクションに記載されている関係資料を参照して、詳しく説明します。
中央集中型コール処理システム（ 中央集中型コール処理を行う複数サイト WAN を参照）では、Cisco CallManager がハブあるいは集約サイトの中央に配置され、営業所では、ローカルのコール処理が行われません。
中央集中型コール処理を行う複数サイト WAN では、Cisco CallManager クラスタが中央サイトに配置されています。このクラスタ内のすべての IP 電話は、単一の Cisco CallManager に登録される必要があるので、このソリューションで拡大できるユーザ数は、クラスタ当たり 2500 までです。複数のクラスタを集約サイトにインストールしてソリューションをさらに拡大でき、H.323 を使用してこれらのクラスタを相互接続できます。
このモデルの主な利点は、コールを中央で集中処理できることです。このソリューションは、リモートの営業所に必要とされる機器を減らすと同時に、従来から使用され続けている複数の PBX、あるいはキー システムの管理を削減します。 中央集中型コール処理を行う複数サイト WAN は、IP WAN が、サービス統合デジタルネットワーク（ISDN）接続でバックアップされ、この接続は、コール処理に冗長な IP WAN パスを提供できることを示しています。この方式は、20 人以下の小規模な営業所、および在宅勤務者にとって非常に魅力的です。ライフライン サービスは、専用 POTS 線、あるいはセルラー電話によって提供できます。
中央処理型コール処理を使用する場合、コール アドミッション制御は、
「locations」の構成体を使用して提供されます。この方式では、ロケーションを営業所のような地理的な対応付けで作成します。たとえば、ロケーションを、Branch 1、Moutain View Office として指定できます（郵便番号の使用も可能）。ロケーションは、広域リンクでサービスを受けられる地理的な場所と関連していなければなりません。ロケーション間の音声コールで使用される最大の帯域幅は、そのロケーションに対して指定します。そのロケーション内のデバイスは、ロケーションに属するデバイスとして指示されます。
Cisco CallManager のロケーション設定
を参照してください。
中央集中型 Cisco CallManager は、所定のロケーションからのロケーション間音声コールによって消費される帯域幅の現在量を追跡し続けます。IP WAN 上の新しいコールが、帯域幅の設定値を超えようとすると、表示機能のあるデバイス上に「All Trunks Busy（すべてのトランクを使用中）」のような設定可能な可視表示が送られるだけではなく、発信者に対して、使用中信号が送出されます。発信者は使用中信号を取得した場合は、その電話を切り、そのロケーションの PSTN ゲートウェイへのアクセス コードをダイヤルして、発信コールを実行できるようにする必要があります。
Cisco CallManager の以前のバージョンと異なり、Cisco CallManager Release 3.0 を使用する各ロケーションは、そのローカル PSTN ゲートウェイに対して共通のアクセス コードを使用できます。詳細は、 ダイヤル プランの考慮事項 で説明します。さらに、Cisco CallManager Release 3.0 では、Skinny Gateway Protocol に基づくゲートウェイの使用に関する制限がなくなりました。現在では、H.323 あるいは MGCP に基づく Cisco IOS ゲートウェイをメディア ストリームの終端に使用でき、メディア終端点（MTP）を使用する必要はなくなりました。
IOS ゲートウェイ プラットフォームに必要最低限の Cisco IOS リリース は、共通の営業所ゲートウェイ、および必要最低限の Cisco IOS リリースを示しています。
さらに、所定のロケーションに設定する帯域幅は、広域リンク上の音声に設定するキュー以下にする必要があります。キューイングの方式は、 QoS で詳しく説明する低遅延キューイングを優先的に使用しています。
ロケーションベースのコール アドミッション制御を使用する場合は、次の注意事項を考慮してください。
中央集中型コール処理クラスタでは、次の 3 つの主要なタイプのコールを処理できる必要があります。
このセクションでは、これらのケースのそれぞれに対応する一般的な設計ガイドラインを記述します。
ロケーション間コールは、一般的に、IP 電話と、ファックスやアナログ電話などのその他のデバイスとの間で実行されます。これらのデバイスは、メディア ゲートウェイ コントロール プロトコル（MGCP）、あるいは Skinny Gateway Protocol に基づくゲートウェイ デバイスに接続されています。1 つのクラスタ内に存在する場合のように、すべてのデバイスは単一の Cisco CallManager に登録され、すべてのデバイスのアベイラビリティが認知されます。コールが試行されると、その結果は次のいずれかとなります。
クラスタ間コールは H.323 を使用して実行され、PSTN へのコールのルーティングを含め、代替ルーティングを使用できます。WAN を介して接続されているクラスタ間には、コール アドミッション制御に使用するゲートキーパーが必要です。クラスタ間コールでの問題については、 分散型コール処理を行う複数サイト WAN に詳しい説明があります。 中央集中型コール処理クラスタと 2 つのクラスタ間の相互接続 も参照してください。
各サイトは、単一の番号をダイヤルしてローカル PSTN にアクセスできます。同じコードを PSTN アクセスに使用して、パーティションとコール検索スペースに基づいて、ローカル ゲートウェイを選択できます。
3 つの営業所をもつ IP WAN で示したネットワークでは、望まれるオペレーションは、すべてのユーザがクラスタ内でお互いをコールすることを許され、ユーザのサブセットが PSTN コールを行うことも許可されることです。 3 つの営業所をもつ IP WAN に続く文章は、これを実現する方法を説明しています。
3 つの営業所をもつ IP WAN の場合、 クラスタ内アクセスとローカル ゲートウェイ アクセスに必要なパーティション に記載されているパーティションを設定して、ユーザが、クラスタ内のすべてのロケーション、あるいはクラスタ内のすべてのロケーションとローカル ゲートウェイ、のいずれかにアクセスできるようにします。
次に、 コール検索スペースとパーティションの設定 のコール検索スペースを定義する必要があります。これらのコール検索スペースを使用して、クラスタ内の番号だけへダイヤル、あるいはローカル ゲートウェイを介した PSTN コールだけではなく、クラスタ内のすべての番号へのダイヤル、のいずれかがダイヤルできる能力をユーザに割り当てることができます。
この例は、複数サイト WAN のローカル コール処理に対して最も簡単な設定の 1 つを示しています。ダイヤル プランは、本質的には PSTN コールの単一パターン、一般的に 9 で構成されます。ゲートウェイの選択は、前述したように、発信デバイスのパーティションとコール検索スペースに全面的に依存します。
より意欲的なダイヤル プランを作成する場合に必要な追加考慮事項は、 コール検索スペース に記載されています。
Cisco CallManager Release 3.0(5) を使用する中央集中型コール処理環境では、Cisco CallManager クラスタに次の設計パラメータが適用されます。
WAN に Cisco CallManager クラスタを使用する場合、アクティブなデバイスはすべて、単一の Cisco CallManager に登録する必要があります。これにより、
Cisco CallManager は、すべてのコールのコール状態を保持し、その結果、ロケーションへの指定帯域幅が超過しないようにできます。
クラス内の単一 Cisco CallManager への登録 は、単一の Cisco CallManager に登録されているデバイスを示しています。
2500 以上のリモート デバイスが必要な場合、複数の WAN クラスタを設定し、H323 を使用して相互接続できます。詳細については、 Cisco CallManager クラスタ を参照してください。
このモデルでは、単一の Cisco CallManager 冗長性グループを設定して、そのグループをデフォルトの Cisco CallManager 冗長性グループにする必要があります。その後、すべてのデバイスをこのグループに割り当てて、これらのデバイスが同じ Cisco CallManager に登録されるようにします。
中央集中型コール処理は、一般的に、専用のコール処理をサイトごとにプロビジョニングすることがコスト効果がない環境で、あるいは管理上許容できない環境で行われます。このような設定は、ロケーションが多くのサイトに広がった時に、その中央管理と低コストが利点となります。デジタル信号プロセッサ（DSP）リソースは、コールのトランスコーディングと電話会議に必要です。これらのリソースは、1 つ 1 つ個別の Cisco CallManager に専用で、集約サイトに配置される必要があります。
DSR リソースの割り当て は、DSP リソースの割り当てを表しています。
割り当てるリソースの数は、音声メールへのトランスコーディング、および電話会議のような他のアプリケーションのための G.711 へのトランスコーディングの要件に基づきます。これらの数量は、音声メールのポート数、および実行される電話会議コール量とユーザとの比率に基づいて計算されます。リソースを Cisco CallManager 別に配置することが、コスト的に無理だと思われる場合、プライマリ Cisco CallManager の故障時、リソースを WAN クラスタ内で静的に移動できます。
中央集中型で音声メールへトランスコードされるコールのコール フロー は、中央集中型のトランスコーディング リソースを示しています。ここでは、当初、G.729a、または G.723.1 を使用して開始されたコールが、G.711 アプリケーションだけで作動する音声メールに進むとき、G.729a あるいは G.733.1 から G.711 への変換を行います。
電話会議については、G.711 だけを使用する別のアプリケーション例を説明します。電話会議を始めたい参加者が、低ビット レートのコーデックだけを使用して、WAN を介し通信できるようにする場合、コールを G.711 にトランスコードしてから、電話会議を開始する必要があります。 電話会議のために中央集中型でトランスコードされるコールのコール フロー を参照してください。
電話会議のために中央集中型でトランスコードされるコールのコール フロー で示したシナリオでは、営業所からのコールは、G.729a を使用して WAN を通過しますが、電話会議リソースに追加される前に、G.711 にトランスコードされる必要があります。
コール処理のような音声メールは、営業所のロケーションでは、多くの場合コスト効果がありません。音声メールを中央に配置することにより、IP 電話のプロビジョニングだけではなく、音声メールの管理も簡素化します。
レガシー システム、あるいは IP ベースの音声メール システムのいずれに相互接続するかに関係なく、低ビット レートのコーデックが、ワイドエリア ネットワーク全体で必要とされる場合、ユーザは、同時音声メール セッションに対して適切な容量を計画し、関連するトランスコーディング リソースを提供する必要があります。 中央集中型コール処理の音声メール クラスタの配置 を参照してください。
中央集中型コール処理の音声メール クラスタの配置 では、ハブのロケーションに 5 つのアプリケーション サーバがあり、それらのサーバが、 2500 までのリモート ユーザに音声メールを提供できます。低ビット レートのコーデックがロケーション間で使用され、アプリケーションが G.711 だけの場合、DSP リソースは、G.729 から G.711 にトランスコードすることを要求されます。
All contents copyright (C) 1992--2003 Cisco Systems K.K.