Cisco IP テレフォニー ソリューション リファレンス ネットワーク デザイン Cisco CallManager Release 4.0 および 4.1
IP テレフォニー配置モデル
IP テレフォニー配置モデル
発行日;2012/02/06 | ドキュメントご利用ガイド | ダウンロード ; この章pdf , ドキュメント全体pdf (PDF - 10MB) | フィードバック

目次

IP テレフォニー配置モデル

単一サイト

単一サイト モデルの利点

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

集中型コール処理を使用するマルチサイト WAN

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

リモート サイトのサバイバビリティ(存続可能性)

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

AAR を使用する VoPSTN

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

分散型コール処理を使用するマルチサイト WAN

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

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

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

IP WAN を介したクラスタ化

WAN の考慮事項

クラスタ内通信

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

Cisco CallManager パブリッシャ

コール詳細レコード(CDR)

遅延のテスト

エラー率

トラブルシューティング

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

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

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

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

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

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

U. S. Section 508 準拠についての設計上の考慮事項

IP テレフォニー配置モデル

各 Cisco IP テレフォニー ソリューションは、次に説明する主要配置モデルに基づいて実現されています。

「単一サイト」

単一サイトで IP テレフォニーを実現する場合のモデルは、その単一サイトに配置されるコール処理エージェント、およびそのサイト全体に音声トラフィックを伝送するための LAN または MAN(メトロポリタンエリア ネットワーク)から構成されています。コールが LAN または MAN を超えて発信される場合は、PSTN(公衆電話交換網)が使用されます。IP WAN が単一サイト モデルに組み込まれている場合、IP WAN はデータ トラフィック専用です。テレフォニー サービスは WAN を介して行われることはありません。

このモデルは、キャンパスが 1 個所の場合、または回線数が 30,000 未満のサイトの場合に適用されます。

「集中型コール処理を使用するマルチサイト WAN」

集中型コール処理を使用するマルチサイト WAN モデルは、単一のコール処理エージェントから構成されています。このコール処理エージェントは、多数のサイトにサービスを行い、IP WAN を使用してサイト間で音声トラフィックを転送します。また、IP WAN は、中央サイトとリモート サイト間のコール制御信号も伝送します。

このモデルは、次のようなメイン サイトに適用されます。QoS 対応 WAN 経由で接続されている、小規模のリモート サイトが多数あり、WAN の故障中はそれらのリモート サイトにフル機能が要求されない場合です。

「分散型コール処理を使用するマルチサイト WAN」

分散型コール処理を使用するマルチサイト WAN モデルでは、複数の独立したサイトから構成されています。各サイトには独自のコール処理エージェントがあり、そのエージェントは、分散サイト間の音声トラフィックを伝送する IP WAN に接続されます。このモデルの IP WAN は、各サイトに独自のコール処理エージェントがあるので、サイト間のコール制御信号を伝送しません。

このモデルは、回線数が 30,000 を超える大規模の中央サイトの場合、または、6 個所以上に分散している大規模サイトの合計回線数が 30,000 を超えていて、そのサイト間が QoS 対応 WAN で相互接続されている場合に適用されます。

「IP WAN を介したクラスタ化」

このモデルでは、単一の Cisco CallManager クラスタが配置されていて、複数のサイト間は QoS 機能に対応している IP WAN によって接続されています。

このモデルは、最大で 6 個所に分散している大規模サイトの合計回線数が 30,000 以内で、そのサイト間が QoS 対応 WAN で相互接続されている場合に適用されます。


) このマニュアルは、読者が前述の配置モデルの内容を理解していることを前提としています。したがって、配置モデルについて十分に理解した上で、読み進むことをお勧めします。


また、「U. S. Section 508 準拠についての設計上の考慮事項」の項では、IP テレフォニー ネットワークを設計するときに、身体に障害のあるユーザに対して U.S. Section 508 に従ってアクセシビリティ機能を組み込む場合のガイドラインを示します。


推奨されるハードウェア プラットフォームとソフトウェア リリースに関する最新情報については、次の Web サイトにあるドキュメントを参照してください。
http://www.cisco.com/univercd/cc/td/doc/product/voice/c_callmg/ccmcomp.htm


単一サイト

単一サイトで IP テレフォニーを実現する場合のモデルは、その単一サイト(キャンパス)に配置される 1 つのコール処理エージェントから構成されています。テレフォニー サービスは、IP WAN を使用して行われることは ありません 。企業は、一般的に、LAN または MAN に対しては単一サイト モデルを配置して、サイト内の音声トラフィックを伝送しています。このモデルでは、コールが LAN または MAN を越えて発信される場合は、PSTN(公衆電話交換網)が使用されます。

単一サイト モデルの設計上の特長は、次のとおりです。

単一の Cisco CallManager または Cisco CallManager クラスタ

クラスタごとに最大 30,000 台の IP Phone

すべての外部コールに対して公衆網で対応

会議、トランスコーディング、および Media Termination Point(MTP; メディア ターミネーション ポイント)に対してデジタル シグナル プロセッサ(DSP)リソースで対応

ボイスメールとユニファイド メッセージング コンポーネント

すべての IP Phone コールに対して G.711 コーデックのみで対応(コールごとに 80 Kbps の IP 帯域幅、圧縮なし)

レガシー Private Branch Exchange(PBX; 構内交換機)システムおよびボイスメール システムとの統合機能

図2-1 は、単一キャンパスまたは単一サイト内の IP テレフォニー ネットワークのモデルを示しています。

図2-1 単一サイト モデル

 

単一サイト モデルの利点

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

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

配置しやすい

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

ダイヤル プランが単純

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

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

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

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

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

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

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

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

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

集中型コール処理を使用するマルチサイト WAN

集中型コール処理を使用するマルチサイト WAN モデルは、単一のコール処理エージェントから構成されています。このコール処理エージェントは、多数のサイトにサービスを行い、IP WAN を使用してサイト間の IP テレフォニー トラフィックを転送します。また、この IP WAN は、中央サイトとリモート サイト間のコール制御シグナリングも伝送します。図2-2 は、一般的な集中型コール処理配置を示しています。この配置では、中央サイトのコール処理エージェントとして Cisco CallManager クラスタを使用し、すべてのサイトを接続するために、QoS 対応の IP WAN を使用します。リモート サイトでは、コール処理に集中型 Cisco CallManager クラスタを使用します。ボイスメール システムや IVR システムなどのアプリケーションも、管理と保守にかかる全体的なコストを削減するために、一般に中央に配置されます。


) このマニュアルで説明する集中型コール処理モデルを適用した各ソリューションでは、さまざまなサイトは、QoS 対応の IP WAN に接続されています。


図2-2 集中型コール処理配置モデル

 

IP WAN の接続オプションは、次のとおりです。

専用回線

フレーム リレー

非同期転送モード(ATM)

ATM とフレーム リレーのサービス インターワーキング(SIW)

Multiprotocol Label Switching(MPLS)バーチャル プライベート ネットワーク(VPN)

音声およびビデオ対応 IP Security Protocol VPN(IPSec VPN(V3PN))

WAN エッジに置かれているルータには、プライオリティ キューイングやトラフィック シェーピングなどの QoS メカニズムが装備されていて、WAN の帯域幅が恒常的に不足している場合に、データ トラフィックから音声トラフィックを保護しています。さらに、コール アドミッション制御方式も導入されていて、音声トラフィックによる WAN リンクのオーバーサブスクリプションを防いだり、確立済みのコール品質が低下するのを防いだりしています。集中型コール処理配置の場合、Cisco CallManager 内にコール アドミッション制御を行う ロケーション が構築されます(ロケーションの詳細については、「Cisco CallManager ロケーション」の項を参照してください)。

リモート サイトでは、さまざまな Cisco ゲートウェイにより、公衆網を介したアクセスが可能です。IP WAN に障害が起きた場合、または IP WAN 上で使用可能な帯域幅がすべて消費されてしまった場合でも、リモート サイトのユーザは、公衆網アクセス コードをダイヤルして、公衆網を利用してコールを発信できます。Cisco IOS ゲートウェイ上で Survivable Remote Site Telephony(SRST) 機能を利用すると、WAN に障害が発生している支店でのコール処理が可能になります。

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

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

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

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

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

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

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

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

機能セットの必要性

スケーラビリティ

管理の容易性

コスト

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

リモート サイトのサバイバビリティ(存続可能性)

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

 

表2-1 リモート サイトの高可用性を提供する方法

方法
データ サービスの
高可用性
音声サービスの
高可用性

支店ルータにおける冗長 IP WAN リンク

あり

あり

支店ルータの冗長プラットフォーム + 冗長 IP WAN リンク

あり

あり

SRST(Survivable Remote Site Telephony)のみ

なし

あり

データのみの ISDN バックアップ + SRST

あり

あり

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

あり

あり
(下記の規則を参照)

表2-1 にリストされている最初の 2 つのソリューションは、IP WAN アクセス ポイントに冗長性を追加して、リモート IP Phone と中央の Cisco 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 CallManager クラスタとコール信号情報を交換し、IP WAN を介してコールを発信します。支店のルータまたはゲートウェイは、両方のタイプのトラフィック(コール信号と音声)を透過的に転送し、IP Phone を認識しません。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


) VoPSTN 配置モデル バリエーションでは、まさにその性質のために、Cisco 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 サーバが中央サイトに配置されている場合は、中央サイトのデバイスによって保留にされたコールのみが保留音を受信します。

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

支店サイトの外部の宛先にコール転送すると、支店のゲートウェイを介したヘアピンコールが発生します。支店の外部にあるボイスメール システムにコール転送する場合も同様です。

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

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

集中型 Music On Hold(MOH)サーバ

IVR

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

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

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

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

全転送機能を使用すると、次のどちらかの場合に、ローカルの支店ゲートウェイを介したヘアピン コールが発生します。

外部の公衆網番号にコールが転送される場合

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

これらの場合は、転送先として公衆網番号を入力するようユーザに要求することをお勧めします。

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

「AAR を使用する VoPSTN」

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

AAR を使用する VoPSTN

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

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

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

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

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

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

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

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

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

分散型コール処理を使用するマルチサイト WAN

分散型コール処理を使用するマルチサイト WAN モデルでは、複数の独立したサイトから構成されています。各サイトには独自のコール処理エージェントがあり、そのエージェントは、分散サイト間の音声トラフィックを伝送する IP WAN に接続されます。図2-4 は、一般的な分散型コール処理配置を示しています。

図2-4 分散型コール処理の配置

 

分散型コール処理モデルの各サイトは、次のいずれかになります。

独自のコール処理エージェントを使用する単一サイト。コール処理エージェントは、次のいずれかになります。

Cisco CallManager

Cisco CallManager Express

その他の IP PBX

集中型コール処理サイトと、それに関連したすべてのリモート サイト。

Voice over IP(VoIP) ゲートウェイを備えたレガシー PBX。

IP WAN は、分散型コール処理のサイトをすべて相互接続します。一般に、公衆網は、IP WAN 接続に障害が起きたか、使用可能な帯域幅がすべて消費されてしまった場合に、サイト間のバックアップ接続の役目を果たします。公衆網のみで接続されているサイトは、独立サイトであり、分散型コール処理モデルには含まれません(「単一サイト」を参照)。

IP WAN の接続オプションは、次のとおりです。

専用回線

フレーム リレー

非同期転送モード(ATM)

ATM とフレーム リレーのサービス インターワーキング(SIW)

Multiprotocol Label Switching(MPLS)バーチャル プライベート ネットワーク(VPN)

音声およびビデオ対応 IP Security Protocol VPN(IPSec VPN(V3PN))

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

分散型コール処理を使用するマルチサイト 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 CallManager は、E.164 番号の使用のみをサポートします。

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

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

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

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

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

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

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

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

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

 

表2-2 推奨されるコール処理エージェント

コール処理エージェント
推奨規模
備考

Cisco CallManager Express(CME)

最大 120 台の電話機

小規模なリモート サイト用

キャパシティは Cisco IOS プラットフォームに依存する

Cisco CallManager

50 ~ 30,000 台の電話機

Cisco CallManager クラスタの規模に応じて、小規模から大規模までのサイト

集中型または分散型コール処理をサポートする

VoIP ゲートウェイを備えた従来の PBX

PBX に依存する

IP WAN コール数と機能は、PBX と VoIP ゲートウェイを接続するプロトコルおよびゲートウェイ プラットフォームによって異なる

IP WAN を介したクラスタ化

QoS 機能に対応している IP WAN によって相互接続される複数サイト間で、単一の Cisco CallManager クラスタを配置できます。ここでは、WAN を介したクラスタ化の概要を簡潔に説明します。詳細については、「コール処理」を参照してください。

WAN を介したクラスタ化では、次の 2 種類の配置方法がサポートされます。

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

ローカル フェールオーバーでは、Cisco CallManager サブスクライバ サーバとバックアップ サーバを同じサイトに配置し、これらのサーバ間に WAN を置かないことが必要です。この配置モデルは、Cisco CallManager を備えた 2 ~ 4 つのサイトに理想的です。

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

リモート フェールオーバーでは、WAN を介してバックアップ サーバを配置できます。この配置モデルを使用すると、Cisco CallManager サブスクライバ サーバを備えた最大 8 つのサイトを、別のサイトにある Cisco CallManager サブスクライバでバックアップすることが可能です。

また、2 つの配置モデルを組み合せて、特定のサイト要件を満たすことも可能です。たとえば、2 つのメイン サイトにプライマリ サブスクライバとバックアップ サブスクライバを配置し、別の 2 つのサイトにはそれぞれプライマリ サーバのみを配置し、2 つのメイン サイトにある共用バックアップまたは専用バックアップのどちらかを使用することができます。

WAN を介したクラスタ化の主な利点は、次のとおりです。

クラスタ内の全サイトに対してユーザを 1 か所で管理

機能の透過性

シェアドライン アピアランス

クラスタ内のエクステンション モビリティ

統一ダイヤル プラン

これらの機能により、このソリューションは、ビジネスが継続して行われるサイトの障害回復プランとして、または最大 8 つの中小規模サイト用の単一ソリューションとして理想的なものになります。

WAN の考慮事項

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

遅延

すべての優先 ICCS トラフィックに対する、任意の Cisco 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 プロセスとの通信を提供します。

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

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

Lightweight Directory Access Protocol(LDAP) ディレクトリからのディレクトリ トラフィック。このトラフィックは、ユーザとアプリケーションを認証し、特定のユーザまたはアプリケーションの追加設定情報を提供します。デフォルトで、LDAP トラフィックはベストエフォートで送信されます。

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

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

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

Cisco CallManager Release 3.1 および 3.2 では、フェールオーバーの動作は、パブリッシャの到達可能性、およびサブスクライバとパブリッシャ間の遅延によって異なります。パブリッシャが通信可能である場合、サブスクライバは、デバイスの登録時に、関連したデバイス設定レコードをパブリッシャに直接要求します。ラウンドトリップ遅延、および SQL データベース トラフィックに使用可能な帯域幅は、登録の速度に影響を与えます。この結果、リモート ロケーションのデバイスから、パブリッシャへのフェールオーバーには、約 20 分の遅延が発生する場合があります。その後、フル サーバ上のすべてのデバイスは、フェールオーバー プロセスを完了します。フェールオーバー時にパブリッシャが通信不能である場合、サブスクライバは、データベースの最新のコピーを設定情報に使用します。サブスクライバが自身のデータベースにアクセスするには遅延は生じないので、この場合のフェールオーバー時間は、フル サーバの場合、約 5 分です。

Cisco CallManager Release 3.3 以降では、フェールオーバー時のパブリッシャに対する遅延の影響は最小限に抑えられます。これは、初期化時またはブートアップ時に、設定情報がキャッシュされるためです。その結果、Cisco CallManager の最初の起動時間が長くなることはありますが、それ以降は、パブリッシャ データベースへのアクセス時の遅延によってフェールオーバーとフェールバックが影響を受けることはありません。

Cisco CallManager パブリッシャ

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

コール処理

フェールオーバー

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

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

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

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

ユーザ短縮ダイヤル

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

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

全転送の変更

メッセージ待機インジケータ(MWI)の状態

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

コール詳細レコード(CDR)

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

遅延のテスト

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

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

Access_SW#ping
Protocol [ip]:
Target IP address: 10.10.10.10
Repeat count [5]:
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]:y
Source address or interface:
Type of service [0]: 3
Set DF bit in IP header?[no]:
Validate reply data?[no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.10.10, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
 

エラー率

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

トラブルシューティング

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

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

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

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

Busy Hour Call Completions(BHCC)が低い場合があります。

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

RemoteCMOutOfService:Ip address:VO30-7835-8 remoteClusterId VO30-7835-1-Cluster|<CLID::VO30-7835-1-Cluster><NID::VO30-7835-2>
|Delete entries from SsManagerTable, now this table has 75 entries|<CLID::VO30-7835-1-Cluster><NID::VO30-7835-2><CT::0,0,0,0.0><IP::><DEV::>
|Delete entries from FeatActTable, now this table has 70 entries|<CLID::VO30-7835-1-Cluster><NID::VO30-7835-2><CT::0,0,0,0.0><IP::><DEV::>
|Digit analysis:Remove remote pattern /5000020 , PID:7:34:1|<CLID::VO30-7835-1-Cluster><NID::VO30-7835-2><CT::0,0,0,0.0><IP::><DEV::>
|Digit analysis:Remove remote pattern /5000066 , PID:7:34:2|<CLID::VO30-7835-1-Cluster><NID::VO30-7835-2><CT::0,0,0,0.0><IP::><DEV::>
.
.
.
|Digit analysis:Remove remote pattern /5001002 , PID:7:34:106|<CLID::VO30-7835-1-Cluster><NID::VO30-7835-2><CT::0,0,0,0.0><IP::><DEV::>
 

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

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

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

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

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

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

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

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

 

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

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

Cisco 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 26 または PHB AF31) が付けられます。ベストエフォート型 ICCS トラフィックには、IP Precedence 0(DSCP 0 または PHB BE)が付けられます。

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

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

ローカル フェールオーバー モデルには、Cisco CallManager Release 3.1 またはそれ以降が必要です。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Cisco Unity や他のボイスメール システムは、すべてのサイトに配置が可能で、Cisco 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 CallManager サブスクライバを含め、バックアップ サブスクライバを必要に応じて配置します。このモデルでは、最大 8 つのサイトを配置できます。また、「コール処理」で説明されている 1:1 冗長性と 50/50 ロードバランシング オプションを使用すると、IP Phone やその他のデバイスは、通常、ローカル サブスクライバに登録されます。バックアップ サブスクライバは、他の 1 つ以上のサイトで、WAN を介して配置されます(図2-6を参照)。

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

 

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

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

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

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

U. S. Section 508 準拠についての設計上の考慮事項

どの配置モデルを選択するかにかかわらず、IP テレフォニー ネットワークを設計する場合は、障害者の方が利用しやすいテレフォニー機能になるように、Telecommunications Act Section 255 電気通信法および U.S. Section 508 に定める基準に準拠する必要があります。

IP テレフォニー ネットワークを構成する際は、次に説明する基本設計ガイドラインに従い、Section 508 を遵守してください。

ネットワーク上の Quality of Service(QoS) を使用可能にします。

ターミナル テレタイプ(TTY) デバイスまたは Telephone Device for the Deaf(TDD) に接続する電話には、G.711 コーデックのみを設定します。G.729 のような低ビット レートのコーデックを音声通信に適用している場合でも、Total Character Error Rate(TCER) が 1% を超えている場合は、TTY/TDD デバイスが適切に作動しないことがあります。

必要に応じて、TTY/TDD デバイスに G.711 を設定し、WAN に対応します。

Echo Cancellation を使用可能(ON )にし、パフォーマンスを最適化します。

Voice Activity Detection(VAD; 音声アクティビティ検出)は、TTY/TDD 接続に影響を与えるため、使用されることはありません。したがって、設定は使用可能、使用不可のどちらであっても関係ありません。

Cisco CallManager 内の リージョン および デバイス プール を適切に設定して、TTY/TDD デバイスが常時 G.711 コードを使用するようにします。

TTY/TDD の IP テレフォニー ネットワークへの接続は、次のいずれかの方法で行います。

直接接続(推奨方式)

RJ-11 アナログ回線用 TTY/TDD を直接 Cisco FXS ポートに接続します。FXS ポートはすべて動作します。たとえば、Cisco IP Phone 7900 シリーズ、Cisco VG248、Catalyst 6000、Cisco ATA 188 モジュール、または FXS ポートを備えている他の Cisco 音声ゲートウェイ上で動作します。シスコは、この接続方式をお勧めします。

アコースティック カップル

IP Phone のハンドセットをTTY/TDD に接続しているカップリング機器に置きます。アコースティック カップルは、RJ-11 接続に比較すると信頼性が劣ります。カップリング方式は部屋の周囲の雑音やその他の要素で、一般的に通信エラーを起こしやすい方式です。

stutter ダイヤルトーンをサポートする必要がある場合は、アナログ電話を Cisco VG248 または ATA 188 上に備えている FXS ポートに接続します。