Cisco Unified Communication ソリューション リファレンス ネットワーク デザイン (SRND) Cisco Unified CallManager Release 5.0

単一サイト モデルの利点

統合されたネットワーク ソリューションの単一インフラストラクチャには、コスト上の大きな利点があります。また、このソリューションの IP テレフォニーでは、企業の多くの IP ベース アプリケーションを利用できるようになります。単一サイトの配置では、各サイトを完全に独立させることも可能です。IP WAN の障害の場合、または帯域幅不足の場合、各サイト間のサービスの依存関係はなくなります。また、コール処理サービスまたは機能が失われることもありません。

要約すると、単一サイト モデルの主な利点は次のとおりです。

• 配置しやすい

• 集中ソリューション用の共通インフラストラクチャである

• ダイヤル プランが単純

• G.711 コーデックのみを使用するので、トランスコーディング リソースの必要がない

単一サイト モデルのベスト プラクティス

単一サイト モデルを実装する場合は、次のガイドラインに従い、ベスト プラクティスを参考にしてください。

• 一般的なインフラストラクチャ 構想に基づいて可用性および耐障害性を高めます。IP テレフォニーへの迅速な移行、アプリケーションにビデオ ストリーミングやビデオ会議などを容易に統合、および IP テレフォニー配置を拡張し、WAN または複数の Cisco Unified CallManager クラスタへのアクセスを可能にするには、インフラストラクチャを適切に構築する必要があります。

• 自社内のコール パターンを知っておく必要があります。単一サイト モデルは、大部分のコールが社内の同一サイトから発信されている場合、または社外の公衆網ユーザ宛てに発信されている場合に適用します。

• すべてのエンドポイントに G.711 コーデックを使用します。この方式を実施すると、トランスコーディングに対してデジタル シグナル プロセッサ（DSP）リソースを消費する必要がなくなり、その分のリソースは、会議やメディア ターミネーション ポイント（MTP）などの他の機能に割り当てることができます。

• H.323 機能を必要と しない 場合は、公衆網に Media Gateway Control Protocol（MGCP; メディア ゲートウェイ コントロール プロトコル）ゲートウェイを使用します。この方式を実施すると、ダイヤル プランの設定が容易になります。H.323 は、特定の機能（たとえば、Signaling System 7（SS7）や Non-Facility Associated Signaling（NFAS））をサポートするために必要な場合があります。

• 高可用性、電話機用の接続オプション（インライン パワー）、Quality of Service（QoS）メカニズム、およびセキュリティ用の推奨ネットワーク インフラストラクチャを実装しています（「ネットワーク インフラストラクチャ」を参照）。

• 「コール処理」の章にリストされているプロビジョニングの推奨事項を実行します。

集中型コール処理モデルのベスト プラクティス

集中型コール処理を使用したマルチサイト WAN モデルを実装する場合は、次のガイドライン、およびベスト プラクティスを参考にしてください。

• 音声のカットスルー遅延（クリッピングとも呼ばれます）を減らすために、Cisco Unified CallManager とリモート ロケーション間の遅延を最小限に抑えます。

• リモート支店とのコール アドミッションを制御するには、Cisco Unified CallManager 内のロケーション メカニズムを使用します。このメカニズムをさまざまな WAN トポロジに適用する方法については、「コール アドミッション制御」の章を参照してください。

• ロケーション メカニズムは、Cisco Unified CallManager 3.1 およびそれ以降のリリースで実行される複数サーバに対して作動します。この設定では、Cisco Unified CallManager がサポートされているサーバ上で実行されている場合、最大 30,000 台の IP Phone（または 20,000 台のデバイス ユニット）をサポートできます。

• 各リモート サイトでの Survivable Remote Site Telephony（SRST）モードでサポートされている IP Phone およびライン アピアランスの数は、その支店内にあるルータのプラットフォーム、取り付け済みメモリ容量、および Cisco IOS リリースにより異なります（SRST プラットフォームおよびコード仕様に関する詳細は、Cisco.com から入手できる SRST 文書を参照してください）。一般的には、特定サイトに対して集中型コール処理か、分散コール処理かを決定するには、次に示す種々の要素によります。

–IP WAN 帯域幅、または遅延制限

–音声ネットワークに関する臨界状況

–機能セットの必要性

–スケーラビリティ

–管理の容易性

–コスト

カスタマーのビジネス ニーズに分散型コール処理モデルがふさわしいと判断する場合は、2 つの選択肢があります。ローカルに Cisco Unified CallManager サーバをインストールする方法と、支店ルータ上で Cisco Unified CallManager Express を稼働する方法です。

リモート サイトのサバイバビリティ（呼処理の継続）

集中型コール処理モデルで WAN を介した IP テレフォニーを配置する場合、リモート サイトのデータ サービスと音声サービスの高可用性を確保するために、追加の処置が必要です。 表2-1 では、リモート サイトでの高可用性を提供するためのさまざまな方法をまとめています。これらの方法のどれを選択するかは、ビジネスまたはアプリケーションの特殊な要件、可用性が高いデータ サービスと音声サービスに関連した優先順位、コストの考慮事項などの複数の要素によって異なります。

表2-1 にリストされている最初の 2 つのソリューションは、IP WAN アクセス ポイントに冗長性を追加して、リモート IP Phone と中央の Cisco Unified CallManager との間の IP 接続を常に保持することによって、ネットワーク インフラストラクチャ層に高い可用性を提供します。これらのソリューションは、データ サービスと音声サービスの両方に適用され、コール処理層からはまったく見えません。このオプションは、支店ルータでの冗長 IP WAN リンクの追加から、冗長 IP WAN リンクを備えた 2 つ目の支店ルータ プラットフォームの追加までにわたります。

表2-1 にリストされている 3 番目のソリューションでは、WAN 障害が検出された場合、SRST（Survivable Remote Site Telephony）が、リモート オフィスのルータ内でコール処理機能のサブセットを提供し、IP Phone を拡張して、ローカル ルータ内のコール処理機能に「re-home」機能を提供することによって、音声サービスのみの高い可能性を提供します。図2-3 では、SRST を使用した典型的なコールのシナリオを示しています。

図2-3 Survivable Remote Site Telephony（SRST）アプリケーションのシナリオ

図2-3 の左側に表示されている通常の動作では、支店は、データ トラフィック、音声トラフィック、およびコール シグナリングを伝送する IP WAN を経由して、中央サイトに接続されます。支店の IP Phone は、中央サイトの Cisco Unified CallManager クラスタとコール信号情報を交換し、IP WAN を介してコールを発信します。支店のルータまたはゲートウェイは、両方のタイプのトラフィック（コール信号と音声）を透過的に転送し、IP Phone を認識しません。

支店との WAN リンクに障害が起きた場合、またはその他のなんらかのイベントにより、Cisco Unified CallManager クラスタとの接続が失われた場合、支店の IP Phone は支店のルータに再登録されます。支店のルータは、設定について IP Phone に照会し、この情報を使用して独自の設定を自動的に作成します。支店の IP Phone は、内部で、または公衆網を介してコールの発信と受信を行うことができます。電話機は「Unified CM fallback mode」というメッセージを表示し、Cisco Unified CallManager の一部の拡張機能が利用不能になり、電話機のディスプレイでグレー表示されます。

中央サイトとの WAN 接続が再度確立されると、支店の IP Phone は、Cisco Unified CallManager クラスタに自動的に再登録され、正常な動作に戻ります。支店のルータは、IP Phone についての情報を削除し、標準のルーティングまたはゲートウェイ設定に戻ります。

表2-1 の最後の 2 つのソリューションでは、ISDN バックアップ リンクを使用して、WAN 障害時の存続可能性を提供します。ISDN バックアップ用には、次の 2 つの配置オプションがあります。

• データのみの ISDN バックアップ

このオプションでは、ISDN はデータのみの存続可能性の確保に使用され、一方 SRST は音声の存続可能性の確保に使用されます。IP Phone からの信号が中央サイトの Cisco Unified CallManager に到達しないようにするために、SCCP（Skinny Client Control Protocol）トラフィックが ISDN インターフェイスに入るのを防ぐように、支店ルータでアクセス コントロール リストを設定する必要があることに注意してください。

• データと音声の ISDN バックアップ

このオプションでは、ISDN はデータと音声の両方の存続性を確保するのに使用されます。この場合、IP Phone は常に Cisco Unified CallManager クラスタとの IP 接続を保持するので、SRST は使用されません。しかし、データと音声のトラフィックの転送に ISDN を使用するのは、次の条件がすべて満たされる場合だけにすることをシスコはお勧めします。

–ISDN リンク上で音声トラフィックに割り当てられた帯域幅が、IP WAN リンク上で音声トラフィックに割り当てられた帯域幅と同じである。

–ISDN リンクの帯域幅が固定されている。

–必要なすべての QoS 機能が、ルータの ISDN インターフェイスに配置されている。QoS の詳細については、「ネットワーク インフラストラクチャ」の章を参照してください。

集中型コール処理のバリエーションとしての Voice Over the PSTN

集中型コール処理配置モデルは、サイト間音声メディアが WAN の代わりに公衆網を介して送信されるように調整できます。このように設定された場合、すべてのテレフォニー エンドポイントのシグナリング（コール制御）は、引き続き中央の Cisco Unified CallManager クラスタによって制御されます。したがって、この Voice over the PSTN（VoPSTN）モデル バリエーションでも、シグナリング トラフィック用に設定された適切な帯域幅を持つ、QoS 対応の WAN が必要になります。

VoPSTN は、次のいずれかの方法で実装できます。

• Automated Alternate Routing（AAR; 自動代替ルーティング）機能を使用する（AAR の詳細については、「Automated Alternate Routing」の項を参照してください）。

• Cisco Unified CallManager と公衆網ゲートウェイの両方のダイヤル プラン構成要素を組み合せて使用する。

VoPSTN が魅力的なオプションとなる可能性があるのは、IP WAN 帯域幅が不足しているか、または公衆網料金と比較して高価である配置や、IP テレフォニー システムがすでに配置されている状況で IP WAN 帯域幅のアップグレードを計画している配置です。

（注） VoPSTN 配置モデル バリエーションでは、まさにその性質のために、Cisco Unified CallManager 機能セットの一部を削減した基本的な音声機能が提供されます。

システム設計者は、実装時の選択内容に関係なく、特に次の問題に対処する必要があります。

• 集中型ボイスメールには、次の要件があります。

–配置に含まれているすべてのロケーションに対して Redirected Dialed Number Identification Service（RDNIS）エンドツーエンドをサポートする、テレフォニー ネットワーク プロバイダー。RDNIS は、ボイスメールにリダイレクトされるコールがリダイレクト元の DN を搬送するために必要となります。その結果、ボイスメール ボックスが正しく選択されることが保証されます。

–ボイスメール システムが MGCP ゲートウェイを介してアクセスされる場合、ボイスメールのパイロット番号は完全修飾 E.164 番号である必要があります。

• エクステンション モビリティ機能は、単一の支店サイトにある IP Phone に制限されます。

• オンネット（クラスタ内）コールはすべて、オフネット（公衆網）コールと同じコール処理によって宛先の電話機に送信されます。この対象には、Missed Calls や Received Calls などのコール ディレクトリに送信される桁数も含まれます。

• 支店間コールはそれぞれ、2 つの独立した Call Detail Record（CDR; コール詳細レコード）を生成します。1 つは、発信側の電話機から公衆網へのコール レッグに対応するもので、もう 1 つは、公衆網から着信側の電話機へのコール レッグに対応するものです。

• オンネット コールとオフネット コールの呼出音タイプを区別する手段はありません。

• 宛先の電話機すべてにおいて、直接発信できる完全修飾 Direct Inward Dial（DID; ダイヤルイン方式）の公衆網番号が必要になります。DID 以外の DN に別の支店サイトから直接到達することはできません。

• VoPSTN を使用する際、Music On Hold（MoH）は、保留側が MoH リソースと同じ場所にある場合に限り使用されます。MoH サーバが中央サイトに配置されている場合は、中央サイトのデバイスによって保留にされたコールのみが保留音を受信します。

• 支店サイトの外部の宛先に着信転送すると、支店のゲートウェイを介したヘアピンコールが発生します。支店のゲートウェイのトラフィック エンジニアリングを、必要に応じて調整する必要があります。

• 支店のゲートウェイに着信するコールを支店サイトの外部の宛先にコール転送すると、ゲートウェイを介したヘアピンコールが発生し、2 つのトランク ポートが使用されます。この動作は、次の場合に発生します。

–支店の外部にあるボイスメール システムにコールが転送される場合

–別の支店にあるオンネットの内線番号にコールが転送される場合

支店と公衆網を接続するトランクのサイズを選定するときは、このコール転送フローによるゲートウェイ ポートの使用率を考慮する必要があります。

• 会議リソースは、会議を開始する電話機と同じ場所にある必要があります。

• VoPSTN は、中央サイトに IP オーディオのストリーミングを要求する（つまり、ゲートウェイを通過しない）アプリケーションをサポートしません。このアプリケーションには、次のようなものがあります。

–集中型 Music On Hold（MoH）サーバ

–IVR

–CTI ベースのアプリケーション

• 中央サイトの外部で Attendant Console を使用する場合、リモート サイトがキャッシングしないで大規模なユーザ アカウント ディレクトリにアクセスする必要があるときは、かなり大きな帯域幅が必要になることがあります。

• 支店間メディア（着信転送を含む）はすべて公衆網を介して送信されるため、支店間トラフィック、着信転送、および集中型ボイスメール アクセスのすべてを収容できるように、ゲートウェイ トランク グループの回線数を調整する必要があります。

• シェアドラインを支店間に配置して、回線を共有するデバイスを別々の支店に配置することは避けるようお勧めします。

このような一般的な考慮事項のほか、以降の項では、次の実装方法のそれぞれに固有の推奨事項や問題について説明します。

• 「AAR を使用する VoPSTN」

• 「ダイヤル プランを使用する VoPSTN」

AAR を使用する VoPSTN

この方法では、Cisco Unified CallManager ダイヤル プランを従来の集中型コール処理配置として設定し、さらに自動代替ルーティング（AAR）機能を正しく設定します。コール アドミッション制御のロケーション メカニズムによって、新たなコールを受け入れるのに十分な WAN 帯域幅がないと判別された場合、AAR は、サイト間コールを公衆網を介して透過的に再ルーティングします。

公衆網をプライマリ（および唯一の）音声パスとして使用するには、各ロケーション（支店サイト）のコール アドミッション制御の帯域幅を 1 Kbps に設定します。この設定により、 すべての コールが WAN を通過することが防止されます。このように設定されている場合、サイト間コールはすべて AAR 機能をトリガーし、AAR 機能は公衆網を介してコールを再ルーティングします。

VoPSTN の AAR 実装方法には、次の利点があります。

• 完全な IP テレフォニー配置に簡単に移行できます。WAN を介した音声メディアをサポートする帯域幅が使用可能になった場合、ダイヤル プランはそのまま保持できるため、変更作業としては、サイトごとにロケーション帯域幅の値をアップデートするだけで済みます。

• 通話中のコールバックなど、一部の補足機能がサポートされます。

AAR 実装方法には、VoPSTN について示した一般的な考慮事項のほかに、次の設計ガイドラインが適用されます。

• AAR 機能を正しく設定する必要があります。

• 一般に、サポートされているデバイスには、IP Phone、ゲートウェイ、およびアナログ電話機を収容するゲートウェイがあります。

• 支店間コールが AAR を使用できるのは、宛先デバイスが IP Phone または Cisco Unity ポートの場合のみです。

• 他のエンドポイントに対する支店間コールは、完全修飾 E.164 番号を使用する必要があります。

• すべてのオンネット支店間コールでは、「Network congestion, rerouting」というメッセージが表示されます。

• 宛先の電話機が登録から外れている場合（たとえば、WAN 接続の通信断が原因で）、AAR 機能は起動されないため、省略ダイヤリングは使用できなくなります。宛先の電話機が SRST ルータに登録されている場合は、その公衆網 DID 番号を直接ダイヤルすることで、宛先に到達できます。

• 発信側の電話機が登録から外れている場合（たとえば、WAN 接続の通信断が原因で）、その電話機は SRST モードに移行します。このような状況で省略ダイヤリング機能を保持するには、SRST ルータに適切なトランスレーション ルールを設定します。

• 同じ支店内のシェアドラインは、その支店のコーリング サーチ スペースのみに含まれているパーティション内に設定される必要があります。シェアドラインへのサイト間アクセスには、次のどちらかの操作が必要です。

–発信側サイトでシェアドラインの DID 番号をダイヤルします。

–シェアドラインへのサイト間省略ダイヤリングが必要な場合は、ユーザがダイヤルした省略ストリングをシェアドラインの DID 番号へと変換するトランスレーション パターンを使用します。

（注） この場合、シェアドラインの DN を別の支店から直接ダイヤルすると、AAR ベースの公衆網コールが複数トリガーされます。

ダイヤル プランを使用する VoPSTN

この方法は、Cisco Unified CallManager 内の特定のダイヤル プラン設定と公衆網ゲートウェイを利用して、すべてのサイト間コールを公衆網を介してルーティングします。ダイヤル プランでは、各サイトの IP Phone の DN を別のパーティションに配置する必要があります。また、その DN のコーリング サーチ スペースは、サイトの内部パーティションと、ローカル公衆網ゲートウェイが関連付けられているルート パターンのみにアクセスする必要があります。

サイト間省略ダイヤリングは、各支店サイトの変換セット（支店サイトごとに 1 セット）からも使用可能です。この変換は、Cisco IOS 内の H.323 ゲートウェイと変換規則を使用して行うのが最適です。

VoPSTN のダイヤル プラン実装方法には、次の利点があります。

• AAR が必要ないため設定が容易になります。

• 発信側または宛先側のどちらかで WAN 障害が発生した状態でも、省略ダイヤリングは自動的に動作します。これは、H.323 ゲートウェイ内の Cisco IOS 変換規則が SRST モードで有効になるためです。

ダイヤル プラン実装方法には、VoPSTN について示した一般的な考慮事項のほかに、次の設計ガイドラインが適用されます。

• 通話中のコールバックなど、補足機能はサポートされません。

• CTI ベースのアプリケーションの中には、重複している内線番号（つまり、別々のパーティションにあるが、同じ DN が設定されている複数の電話機）をサポートしないものがあります。

• 完全な IP テレフォニー配置に簡単に移行することはできません。これは、ダイヤル プランの再設計が必要になるためです。

分散型コール処理モデルの利点

分散型コール処理を使用するマルチサイト WAN モデルには、次の利点があります。

• サイト間のコールに IP WAN を使用する場合の公衆網コール コストの節約。

• IP WAN を使用し、公衆網着信番号に近いリモート サイトのゲートウェイを通じてのコールの転送による通話料金の回避。この方法は Tail-End Hop-Off（TEHO）と呼ばれます。

• 音声トラフィックが他のタイプのトラフィックと IP WAN を共有できるようにすることによる、使用可能な帯域幅の最大限の利用。

• 各サイトのコール処理エージェントの存在による、IP WAN の障害時の機能の保全。

• 数百のサイトへのスケーラビリティ。

分散型コール処理モデルのベスト プラクティス

分散型コール処理を使用するマルチサイト WAN 配置には、単一サイト、または集中型コール処理を使用するマルチサイト WAN 配置と同じ要件が少なからずあります。分散型コール処理モデルについては、ここでリストされているベスト プラクティスに加えて、他のモデルのベスト プラクティスにも従ってください（「単一サイト」および 「集中型コール処理を使用するマルチサイト WAN」を参照）。

ゲートキーパーまたは Session Initiation Protocol（SIP）プロキシ サーバは、分散型コール処理を使用するマルチサイト WAN モデルの重要な要素です。どちらもダイヤル プランの解決を行います。さらに、ゲートキーパーは、コール アドミッション制御も行います。ゲートキーパーは、コール アドミッション制御と E.164 ダイヤル プラン解決を実行する H.323 デバイスです。

ゲートキーパーの使用には、次のベスト プラクティスが適用できます。

• Cisco IOS ゲートキーパーを使用して、各サイトとのコール アドミッションを制御します。

• ゲートキーパーの有効性を高めるには、HSRP（ホットスタンバイ ルータ プロトコル）ゲートキーパー ペア、ゲートキーパーのクラスタ化、および代替ゲートキーパー サポートを使用します。さらに、ネットワーク内の冗長性を確実にするために複数のゲートキーパーを使用します（「ゲートキーパーの設計上の考慮事項」を参照）。

• プラットフォームの規模を適切に調整して、パフォーマンスとキャパシティの要件が満たされることを確認します。

• WAN 上のコーデックは 1 つのタイプに限定して使用します。これは、H.323 仕様では、レイヤ 2、IP、UDP（User Data Protocol）、または RTP（Real-time Transport Protocol）ヘッダーのオーバーヘッドが、帯域幅要求で許可されないからです（ヘッダーのオーバーヘッドは、パケットのペイロードまたは符号化された音声部分のみで許可されます）。WAN 上で使用するコーデックを 1 つのタイプに限定すると、最悪のシナリオに備えて IP WAN を過剰にプロビジョニングする必要がなくなるので、キャパシティ プランニングが簡単になります。

• ゲートキーパー ネットワークは、数百単位のサイトにスケーラブルです。また、設計上の制限は WAN トポロジからしか受けません。

ゲートキーパーが実行する各種機能の詳細については、次の項を参照してください。

• ゲートキーパーのコール アドミッション制御については、「コール アドミッション制御」を参照してください。

• ゲートキーパーのスケーラビリティと冗長性については、「コール処理」を参照してください。

• ゲートキーパーのダイヤル プラン解決については、「ダイヤル プラン」を参照してください。

SIP デバイスは、E.164 番号と SIP ユニフォーム リソース識別子（URI）を解決して、エンドポイント間で相互にコールを発信できるようにします。Cisco Unified CallManager は、E.164 番号の使用のみをサポートします。

SIP プロキシの使用には、次のベスト プラクティスが適用できます。

• SIP プロキシの適切な冗長性を確保します。

• SIP プロキシのキャパシティが、ネットワークに必要なコール レートおよびコール数に対応していることを保証します。

• コール アドミッション制御のプランニングは、このドキュメントの対象外です。

分散型コール処理モデルのコール処理エージェント

コール処理エージェントの選択は、多くの要素によって異なります。設計での主な要素は、サイトの規模および機能要件です。

分散型コール処理配置の場合、各サイトには独自のコール処理エージェントがあります。各サイトの設計は、コール処理エージェント、必要な機能、および必要な耐障害性によって変わります。たとえば、500 台の電話機を備えたサイトでは、2 つのサーバを含む Cisco Unified CallManager クラスタは、1 対 1 の冗長性を提供することができ、バックアップ サーバは、パブリッシャおよび TFTP（トリビアル ファイル転送プロトコル）サーバとして使用されます。

IP ベース アプリケーションの要件も、コール処理エージェントの選択に大きな影響を与えます。これは、多くの Cisco IP アプリケーションをサポートするのは、Cisco Unified CallManager だけであるからです。

表2-2 は、推奨されるコール処理エージェントを示しています。

WAN の考慮事項

WAN を介したクラスタ化が成功するには、WAN 自体のさまざまな特性を慎重に計画し、設計し、実装する必要があります。Cisco Unified CallManager サーバ間の Intra-Cluster Communication Signaling（ICCS）は、複数のトラフィック タイプから構成されます。ICCS のトラフィック タイプは、優先またはベストエフォートのどちらかとして分類されます。優先 ICCS トラフィックには、IP Precedence 3（DSCP 24 または PHB CS3）が付けられます。ベストエフォート型 ICCS トラフィックには、IP Precedence 0（DSCP 0 または PHB BE）が付けられます。さまざまなタイプの ICCS トラフィックについては、「クラスタ内通信」で説明されています。この項では、プロビジョニングについてのさらに詳しいガイドラインも記述されています。WAN の特性には、次の設計上のガイドラインが適用されます。

• 遅延

すべての優先 ICCS トラフィックに対する、任意の Cisco Unified CallManager サーバ間の片方向の最大遅延は 20 ms、つまり 40 ms Round-Trip Time（RTT; ラウンドトリップ時間）以下でなければなりません。その他の ICCS トラフィックの遅延は、タイムリーにデータベースとディレクトリにアクセスするために、妥当なものでなければなりません。遅延の測定については、「遅延のテスト」を参照してください。2 つのサイト間の伝搬遅延は、他のネットワーク遅延を考慮しない場合、1 キロメートル当たり 6 マイクロ秒になります。これは、20 ms 遅延に対して理論的な最大距離約 3000 km、つまり約 1860 マイルに相当します。この距離は、相対的なガイドラインとしてのみ記載されています。実際には、ネットワーク内の他の遅延により、これより短くなります。

• ジッタ

ジッタは、処理、キュー、バッファ、輻輳、またはパス変動遅延により、パケットがネットワークを介して受ける変動遅延です。IP Precedence 3 ICCS トラフィックのジッタは、QoS 機能を使用して最小限に抑える必要があります。

• パケット損失とエラー

ネットワークは、すべての ICCS トラフィック、特に優先 ICCS トラフィックに対して、十分な優先順位付き帯域幅を提供するように設計される必要があります。標準的な QoS メカニズムを実装して、輻輳とパケット損失を回避する必要があります。回線エラーや他の「現実的な」状況によってパケットが損失した場合、ICCS パケットは再送信されます。これは、高信頼性伝送のために TCP プロトコルが使用されているからです。再送信が行われると、セットアップ、接続解除（終了）、または他の補足サービスの実行中に、コールが遅延する場合があります。パケット損失の状況によっては、コールが失われる可能性があります。ただし、このシナリオ以上に、T1 または E1 上でエラーが発生することが考えられます。このエラーは、トランクを介した公衆網/ISDN へのコールに影響を及ぼします。

• 帯域幅

予想されるコール ボリューム、デバイスのタイプ、およびデバイス数に対して、各サーバ間で適切な帯域幅を提供してください。この帯域幅は、サイト間の音声や映像のトラフィックを含めて、ネットワークを共有する他のアプリケーション用のその他の帯域幅とは別に必要です。提供される帯域幅では、さまざまなクラスのトラフィックに優先順位付けとスケジューリングを行うために、QoS が使用可能になっていなければなりません。帯域幅は、一般的に多めに設定し、少なめにサブスクライブします。

• QoS

ネットワーク インフラストラクチャは、QoS 技術を使用して、一貫した予測可能なエンドツーエンド レベルのサービスをトラフィックに提供します。QoS も帯域幅も、それだけでは解決法になりません。QoS が使用可能になった帯域幅を、ネットワーク インフラストラクチャに設計する必要があります。

クラスタ内通信

一般に、クラスタ内通信とは、サーバ間のすべてのトラフィックを意味します。Intra-Cluster Communication Signaling（ICCS）と呼ばれるリアルタイム プロトコルもあります。このプロトコルは、クラスタ内の各サーバまたはノードにおけるコール処理の中心である、Cisco CallManager Service プロセスとの通信を提供します。

サーバ間のクラスタ内トラフィックは、次のものから構成されます。

• 主な設定情報を提供する IBM Informix Dynamic Server（IDS）データベースからのデータベース トラフィック。IDS データベースは、ベストエフォートを使用して、パブリッシャ サーバから、クラスタ内の他のすべてのサーバに複製されます。IDS トラフィックは、Cisco QoS の推奨事項に沿って再優先順位付けが行われ、より高い優先順位のデータ サービスになります（たとえば、特定のビジネス ニーズによって必要な場合は IP Precedence 1）。この一例は、IDS データベース設定を使用する、エクステンション モビリティの拡張使用です。

• サブスクライバをパブリッシャに認証し、パブリッシャのデータベースにアクセスするために使用されるファイアウォール管理トラフィック。管理トラフィックは、クラスタ内のすべてのサーバ間を通過します。管理トラフィックは、Cisco QoS の推奨事項に沿って優先順位付けが行われ、より高い優先順位のデータ サービスになります（たとえば、特定のビジネス ニーズによって必要な場合は IP Precedence 1）。

• ICCS リアルタイム トラフィック。このトラフィックは、シグナリング、コール アドミッション制御、および開始と終了時のコールについてのその他の情報から構成されます。ICCS は、Cisco CallManager Service が使用可能になっているすべてのサーバ間で、伝送制御プロトコル（TCP）接続を使用します。この接続は、これらのサーバ間でフルメッシュです。クラスタには、Cisco CallManager Service が使用可能になっているサーバが 8 つしかないので、各サーバには最大 7 つの接続が可能です。このトラフィックは、優先 ICCS トラフィックであり、Cisco CallManager リリースおよびサービス パラメータ設定に応じてマークされます。

• CTI Manager リアルタイム トラフィック。このトラフィックは、コールに関係する CTI デバイスに使用されるか、Cisco Unified CallManager サーバ上のその他のサードパーティ製デバイスの制御または監視に使用されます。このトラフィックは、優先 ICCS トラフィックとしてマークされ、CTI Manager を備えた Cisco Unified CallManager サーバと、CTI デバイスを備えた Cisco Unified CallManager サーバとの間に存在します。

サブスクライバ サーバ間のフェールオーバー

Cisco Unified CallManager 5.0 を使用すると、初期化時またはブートアップ時にデバイス設定レコードがキャッシュされます。その結果、Cisco Unified CallManager の初期化に時間がかかることはありますが、パブリッシャ データベースへのアクセス時の遅延によって、すべてのデバイスのフェールオーバーまたはフェールバックが影響を受けることはありません。

Cisco Unified CallManager パブリッシャ

パブリッシャは、マスター データベースの読み取り専用コピーをクラスタ内の他のすべてのサーバに複製します。クラスタ内の別のサーバが通信不能である期間に、パブリッシャのマスター データベースに変更が加えられた場合、パブリッシャは、通信が再確立されたときに、更新されたデータベースを複製します。パブリッシャが通信不能であるか、オフラインになっている期間、コンフィギュレーション データベースに変更を加えることはできません。サブスクライバ データベースはすべて、読み取り専用であり、変更できません。クラスタの通常の操作の大部分は、以下を含めて、この期間には影響を受けません。

• コール処理

• フェールオーバー

• 設定済みデバイスのインストレーション登録

一部の機能には、パブリッシャ上のマスター データベースへのアクセス権が必要です。これは、これらの機能がレコードに変更を加えるために書き込みアクセス権が必要であるからです。パブリッシャは、コンフィギュレーション データベースへの読み取りと書き込みアクセス権がある、Cisco Unified CallManager クラスタ内の唯一のサーバです。パブリッシャへの書き込みアクセス権が必要な主な機能には、次のものがあります。

• 設定の追加、変更、および削除

• エクステンション モビリティ

• ユーザ短縮ダイヤル

• データベースを必要とする Cisco Unified CallManager User ページのオプション

• Cisco Unified CallManager ソフトウェアのアップグレード

• 全転送の変更

• メッセージ待機インジケータ（MWI）の状態

これ以外のサービスやアプリケーションも影響を受ける場合があります。したがって、パブリッシャなしで機能するかどうかを配置時に確認する必要があります。

コール詳細レコード（CDR）

コール詳細レコードが使用可能である場合、各サブスクライバによって収集され、定期的にパブリッシャにアップロードされます。パブリッシャが通信不能である間、CDR は、サブスクライバのローカル ハードディスクに保存されます。パブリッシャとの接続が再確立されると、未処理の CDR はすべて、パブリッシャにアップロードされます。

遅延のテスト

任意の 2 つのサーバ間の最大ラウンドトリップ時間（RTT）は、常に 40 ms 以下でなければなりません。この制限には、この 2 つのサーバ間の伝送パスの遅延がすべて含まれる必要があります。Cisco Unified CallManager サーバで ping ユーティリティを使用してラウンドトリップの遅延を確認しても、正確な結果は得られません。ping は、ベストエフォート型のパケットとして送信されます。ICCS トラフィックと同じ QoS 対応パスを使用して転送されません。したがって、遅延を確認するには、Cisco Unified CallManager サーバに最も近いネットワーク デバイスを使用することをお勧めします。理想的には、サーバが接続されているアクセス スイッチです。Cisco IOS は、ICCS トラフィックが通過するのと同じ QoS 対応パス上で ping パケットが送信されるように、レイヤ 3 タイプ オブ サービス（ToS）ビットを設定できる拡張 ping を備えています。拡張 ping によって記録される時間は、ラウンドトリップ時間（RTT）、つまり通信パスを通過して戻るのに要する時間です。任意の 2 つの Cisco Unified CallManager サーバ間の最大 RTT は 40 ms です。したがって、片方向の最大遅延は 20 ms になります。この遅延は、Cisco Unified CallManager クラスタのコール処理機能のパフォーマンスに非常に重要であり、厳密に実行する必要があります。

次の例は、ToS ビット（IP Precedence）が 3 に設定された、Cisco IOS 拡張 ping です。

エラー率

予想されるエラー率はゼロでなければなりません。エラー、パケットのドロップ、または IP ネットワークに対するその他の障害は、クラスタのコール処理パフォーマンスに影響を与える可能性があります。これは、ダイヤル トーンの遅延、IP Phone 上のキーやディスプレイの反応の遅れ、またはオフフックしてから音声パスの接続までの遅れによって気付く場合があります。Cisco Unified CallManager はランダム エラーに対する許容性がありますが、クラスタのパフォーマンス低下を避けるために、エラーを回避する必要があります。

トラブルシューティング

クラスタ内の Cisco Unified CallManager サブスクライバが、予想より高い遅延、エラー、またはパケットのドロップにより、ICCS 通信の障害を検出する場合、次の症状のいくつかが発生する場合があります。

• クラスタ内のリモート Cisco Unified CallManager サーバ上にある IP Phone、ゲートウェイ、またはその他のデバイスが、一時的に通信不能になることがあります。

• コールの接続が切断されたり、コールのセットアップ中に失敗する場合があります。

• ユーザにダイヤル トーンが聞こえるまでに、予想以上に長い遅延が起こる場合があります。

• Busy Hour Call Completions（BHCC）が低い場合があります。

• ICCS（SDL セッション）がリセットされたり、接続が切断されることがあります。次に、Cisco Unified CallManager SDL トレースの例を示します。このトレースでは、リモート サーバ VO30-7835-8 がサービス休止になり、そのサーバが通信可能であったデバイスが、「利用可能な」宛先として除去されます。

要約すると、ICCS 通信の問題のトラブルシューティングを行うには、次のタスクを実行します。

• サーバ間の遅延を検証する

• エラーやパケットのドロップがないかどうか、すべてのリンクを調べる

• QoS が正常に設定されていることを確認する

• すべてのトラフィックをサポートするために、キューに対して、WAN を介した十分な帯域幅が提供されることを確認する

ローカル フェールオーバー配置モデル

ローカル フェールオーバー配置モデルは、WAN を介したクラスタ化に対する最大の復元性があります。このモデルの各サイトには、少なくとも 1 つのプライマリ Cisco Unified CallManager サブスクライバと 1 つのバックアップ サブスクライバがあります。この設定では、最大 4 つのサイトをサポートできます。電話機および他のデバイスの最大数は、配置されているサーバの数とタイプによって異なります。全サイトの IP Phone の最大総数は 30,000 です（図2-5 を参照）。

図2-5 ローカル フェールオーバー モデルの例

リモート フェールオーバー モデルを実装する場合は、次のガイドラインに従ってください。

• 少なくとも 1 つのプライマリ Cisco Unified CallManager サブスクライバと 1 つのバックアップ サブスクライバを含むように、各サイトを設定します。

• Cisco Unified CallManager の グループ と デバイス プール を設定して、サイト内のデバイスが、あらゆる状況でそのサイトのサーバだけに登録されるようにします。

• 各サイトで主要なサービス（TFTP、DNS、DHCP、LDAP、および IP Phone サービス）、すべてのメディア リソース（コンファレンス ブリッジと Music On Hold）、およびゲートウェイを複製します。複製を確実に行い、最大レベルの復元性を得るよう、シスコは強くお勧めします。また、この方法を拡張して、各サイトにボイスメール システムを組み込むこともできます。

• WAN 障害が発生した場合、パブリッシャ データベースへのアクセスがないサイトでは、次に示すように、いくつかの機能を使用できないことがあります。

–ローカル サイトのシステム管理者は、設定を一切追加、変更、または削除することができません。

–エクステンション モビリティ ユーザは、IP Phone のログインまたはログアウトを行うことができません。

–全コール転送を変更することはできません。

• WAN 障害が発生した状態では、コールを発信するサブスクライバと現在通信していない電話番号にコールを発信すると、ファースト ビジー音が聞こえるか、またはコール転送されます（転送先の電話番号のロケーションによっては、ボイスメールに転送される可能性があります）。このような場合、ユーザは公衆網を介してその番号を手動でダイヤルする必要があります。

• WAN を介してクラスタ化されているサイト間で 10,000 BHCA（Busy Hour Call Attempt）が発生するたびに、Intra-Cluster Communication Signaling（ICCS）に 900 Kbps の帯域幅が必要です。これは、帯域幅の最小必要量であり、帯域幅は、900 kbps の倍数で割り当てられます。ICCS のトラフィック タイプは、優先またはベストエフォートのどちらかとして分類されます。優先 ICCS トラフィックには、IP Precedence 3（DSCP 24 または PHB CS3）が付けられます。ベストエフォート型 ICCS トラフィックには、IP Precedence 0（DSCP 0 または PHB BE）が付けられます。

• WAN を介してクラスタ化されているサイト間の推奨される最小帯域幅は、1.544 Mbps です。この量にすると、ICCS 用に最小 900 Kbps が確保され、データベースおよび他のサーバ間トラフィック用に最小 644 Kbps が確保されます。

• Cisco Unified CallManager クラスタ内の任意の 2 つのサーバ間では、最大ラウンドトリップ時間（RTT）として 40 ms まで許容されます。この時間は、単方向で最大 20 ms の遅延、または理想的な条件下での約 1860 マイル（3000 km）の伝送距離に相当します。

• 集中型コール処理を使用するリモート支店を、WAN を介したクラスタ化を使用してメイン サイトに接続する場合は、WAN を介したクラスタ化に使用されるリンクがオーバーサブスクリプションにならないよう、慎重にコール アドミッション制御を設定します。

–WAN を介したクラスタ化に使用されるリンク上で帯域幅が制限されていない場合（つまり、リンクへのインターフェイスが OC-3s または STM-1s で、コール アドミッション制御に関する要件がない場合）は、リモート サイトがメイン サイトのいずれかに接続される場合があります。これは、すべてのメイン サイトでロケーションを Hub_None として設定する必要があるためです。この設定が行われても、コール アドミッション制御に使用するハブアンドスポーク トポロジは保持されます。

–Multiprotocol Label Switching（MPLS）バーチャル プライベート ネットワーク（VPN）機能を使用している場合は、Cisco Unified CallManager ロケーションとリモート サイトにあるすべてのサイトが、メイン サイトのいずれかに登録される場合があります。

–メイン サイト間の帯域幅が制限されている場合は、サイト間でコール アドミッション制御を使用し、ロケーションが Hub_None として設定されているメイン サイトにすべてのリモート サイトを登録する必要があります。このメイン サイトはハブ サイトと見なされ、それ以外のリモート サイトと、WAN を介してクラスタ化されたサイトはすべて、スポーク サイトとなります。

• ソフトウェア アップグレード時は、ソフトウェア リリース ノートで説明されている標準のアップグレード手順を使用して、クラスタ内のすべてのサーバを同じ保守期間内にアップグレードする必要があります。

ローカル フェールオーバーに対する Cisco Unified CallManager のプロビジョニング

ローカル フェールオーバー モデルに対する Cisco Unified CallManager クラスタのプロビジョニングは、「コール処理」の章で説明されているキャパシティについての設計上のガイドラインに従う必要があります。WAN を介してサイト間の音声コールまたはビデオ コールが可能である場合、サイト間のコール アドミッション制御を提供するために、他のサイトのデフォルト ロケーションに加えて、Cisco Unified CallManager の ロケーション も設定する必要があります。デバイス数に対して帯域幅が余分にプロビジョニングされる場合でも、ロケーションに基づくコール アドミッション制御を設定するのが最良の方法です。ロケーションベースのコール アドミッション制御によってコールが拒否された場合は、自動代替ルーティング（AAR）機能によって公衆網への自動フェールオーバーを行うことができます。

冗長性とアップグレード時間を改善するために、2 つの Cisco Unified CallManager サーバで Cisco TFTP サービスを使用可能にすることをお勧めします。また、低速 WAN リンクを介して、パブリッシャーからリモートとなるロケーションにある複数のサーバで、Cisco TFTP サービスを使用可能にしないでください。クラスタ内に複数の TFTP サーバを配置できますが、そのような構成ではすべての TFTP サーバ上ですべての TFTP ファイルを再構築するために時間がかかります。

サイトやサーバの利用可能なキャパシティに応じて、パブリッシャ サーバまたはサブスクライバ サーバのどちらかで、TFTP サービスを実行できます。TFTP サーバ オプションは、サイトごとに DHCP サーバ上で正しく設定する必要があります。DHCP を使用していないか、TFTP サーバが手動で設定される場合、ユーザが、サイトの正しいアドレスを設定する必要があります。パブリッシャから離れた TFTP サーバでは、クラスタのアップグレード時や Cisco TFTP サービスの再起動時に、すべての設定ファイルをアップグレードおよび再構築するためにより多くの時間がかかります。この時間は、TFTP サーバとパブリッシャ間の遅延や、データベースに設定されているデバイスの数によって異なります。

WAN の障害時に Cisco Unified CallManager の正常な動作に影響を与える可能性がある他のサービスも、連続したサービスを確保するために、すべてのサイトで複製されなければなりません。これらのサービスには、DHCP サーバ、DNS サーバ、社内電話帳、および IP Phone サービスがあります。各 DHCP サーバで、ロケーションごとに DNS サーバ アドレスを正しく設定してください。

IP Phone は、サイト間のシェアドライン アピアランスを備えている場合があります。サイト間に提供される ICCS 帯域幅により、追加の ICCS トラフィックをシェアドライン アピアランスを生成することができます。WAN の障害時に、各ライン アピアランスのコール制御は分割されますが、WAN が回復された後、コール制御は 1 つの Cisco Unified CallManager サーバに戻ります。WAN の回復中に、2 つのサイト間には追加のトラフィックがあります。コール量が多い時期にこの状態が起きると、その期間中、共有ラインが予想通りに動作しない場合があります。この状態が数分以上続くことはありませんが、これが問題になる場合は、影響を最小限に抑えるために、追加の優先順位付き帯域幅を設定することができます。

ローカル フェールオーバー用のゲートウェイ

ゲートウェイは、通常、どのサイトにも配置されていて、公衆網へのアクセスに対応しています。ゲートウェイを同一サイトの Cisco Unified CallManager サーバに登録するために、デバイス プールを設定する必要があります。サイトのローカル ゲートウェイを公衆網アクセス用の第一選択肢として選択し、他のサイトのゲートウェイをオーバーフロー用の第二選択肢として選択するために、パーティションとコーリング サーチ スペースも設定する必要があります。各サイトで緊急用サービスへのアクセスを確保するように特に注意してください。

WAN 障害時にアクセスが必要のない場合、および WAN を介したコール数に対して十分な追加帯域幅が設定される場合、公衆網ゲートウェイへのアクセスを集中させることができます。E911 要件に対応するために、各サイトで追加のゲートウェイが必要な場合があります。

ローカル フェールオーバー用のボイスメール

Cisco Unity や他のボイスメール システムは、すべてのサイトに配置が可能で、Cisco Unified CallManager クラスタに組み込むことができます。この設定では、WAN 障害時に公衆網を使用しなくても、ボイスメールにアクセスできます。ボイスメール プロファイルを使用すると、同じロケーションにある IP Phone に、サイトに適したボイスメール システムを割り当てることができます。SMDI プロトコルを使用するボイスメール システム、サブスクライバ上の COM ポートに直接接続されたボイスメール システム、および Cisco Messaging Interface（CMI）を使用するボイスメール システムを、クラスタごとに最大 4 つ設定できます。

ローカル フェールオーバーに対する Music On Hold とメディア リソース

各サイトでは、Music On hold（MoH）サーバや、他のコンファレンス ブリッジなどのメディア リソースに、ユーザのタイプおよび数に十分なキャパシティをプロビジョニングする必要があります。Media Resource Group（MRG; メディア リソース グループ）と Media Resource Group List（MRGL; メディア リソース グループ リスト）の使用により、メディア リソースは、オンサイト リソースによって提供され、WAN 障害時に使用できます。

リモート フェールオーバー配置モデル

リモート フェールオーバー配置モデルでは、バックアップ サーバを柔軟に配置できます。各サイトには、少なくとも 1 つのプライマリ Cisco Unified CallManager サブスクライバを含め、バックアップ サブスクライバを必要に応じて配置します。このモデルでは、最大 8 つのサイトを配置できます。また、「コール処理」の章で説明されている 1:1 冗長性と 50/50 ロードバランシング オプションを使用すると、IP Phone やその他のデバイスは、通常、ローカル サブスクライバに登録されます。バックアップ サブスクライバは、他の 1 つ以上のサイトで、WAN を介して配置されます（図2-6 を参照）。

図2-6 4 サイト構成のリモート フェールオーバー モデル

リモート フェールオーバー モデルを実装する場合は、ローカル フェールオーバー モデルのガイドライン（「ローカル フェールオーバー配置モデル」を参照）と、次の変更点に従ってください。

• 少なくとも 1 つのプライマリ Cisco Unified CallManager サブスクライバと、必要に応じてオプションのバックアップ サブスクライバを含むように、各サイトを設定します。

• Cisco Unified CallManager の グループ と デバイス プール を設定して、WAN を介してサーバにデバイスを登録できるようにします。

• デバイスが、WAN を介して同じクラスタ内のリモート Cisco Unified CallManager サーバに登録される場合、シグナリング トラフィックまたはコール制御トラフィックのために帯域幅を追加する必要があります。この帯域幅は、ICCS トラフィックより大きくなる場合があります。また、シグナリングに関する帯域幅のプロビジョニング計算を使用して計算する必要があります（「帯域幅のプロビジョニング」を参照）。