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