この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
ネットワーク インフラストラクチャが Cisco Unified Communications および Collaboration システムに配置されると、呼制御およびルーティングのアプリケーション、コンポーネント、およびサービスをネットワーク インフラストラクチャの最上位で階層化できるようになります。ネットワーク インフラストラクチャ上に配置できる、また場合によっては配置する必要があるアプリケーションと機能は、数多く存在します。
本 SRND のこの章では、上記の機能、コンポーネント、およびサービスについて説明します。各章では、コンポーネントまたはサービスの概要を示したあと、アーキテクチャ、ハイ アベイラビリティ、および設計上の考慮事項について説明します。各章では、アプリケーションおよびサービスの設計関連の側面を中心に説明します。製品固有のサポートおよび設定情報については、関連する製品マニュアルを参照してください。
この章では、帯域幅管理方法と、コールの音声およびビデオ品質が許容できなくなる原因となる、IP リンクの潜在的なオーバーサブスクリプションについて説明します。また、オーバーサブスクリプションを回避するために、所定の時間にネットワーク上で特定の数の同時コールだけを許可するためのコール アドミッション制御の使用についても説明します。この章では、Quality of Service(QoS)およびコール アドミッション制御タイプ(ロケーションベースのコール アドミッション制御など)、さらに QoS とアドミッション制御サービスを適切に配置するための設計と配置のガイドラインについて説明します。
この章では、呼処理アプリケーションがコールを適切な宛先にルーティングできるようにする、ダイヤル プランの機能と機能性について説明します。この章では、ダイヤル プラン サービスのさまざまな側面(ダイヤル プラン構成要素、ダイヤル プラン番号オプションと設計上の考慮事項、制限クラス、着信コールと発信コールの機能、ダイヤル プランとコール ルーティング冗長メカニズムなど)について検討します。
この章では、企業の IP コミュニケーション環境から PSTN 上の Public Safety Answering Point(PSAP)を介して緊急サービスにアクセスする方法について説明します。この内容は、医療、火災、およびその他の緊急応答サービスが重要なニーズとなる可能性があるため、ほとんどの配置において重要となります。この章では、企業の内外におけるさまざまな緊急サービス コンポーネントの概要について説明します。また、立案、911 ネットワーク サービス プロバイダー、ゲートウェイ インターフェイス、および番号とロケーションのマッピングについても説明します。
この章では、Cisco Unified Communications Manager のディレクトリ アーキテクチャ自体や LDAP の同期化および認証に関する設計上の考慮事項など、Unified Communications および Collaboration と LDAP ディレクトリとの統合について説明します。Unified Communications および Collaboration エンドポイントからのディレクトリ アクセス、およびシングル サインオンなどのセキュリティ上の考慮事項についても説明します。
コール ルーティング コンポーネントとサービス(呼処理エージェント、IP ゲートウェイと PSTN ゲートウェイなど)は、基盤となるネットワーク インフラストラクチャを使用して、ネットワークに接続およびアクセスします。コール ルーティングのコンポーネントおよび機能は、基盤となるネットワーク インフラストラクチャに接続することで、エンドツーエンドのネットワーク接続および Quality of Service を利用して、企業ネットワークと公衆電話網の両方にアクセスできます。一方、コール ルーティングのアプリケーションとサービスは、基本的な Unified Communications および Collaboration 機能(呼制御、ダイヤル プラン、コール アドミッション制御、ゲートウェイ サービスなど)を配置内のその他のアプリケーションとサービスに提供します。たとえば、Unified CM クラスタは、スイッチを介して IP ネットワークに接続し、ネットワーク内のその他のデバイスおよびアプリケーションと通信する以外に、その他のロケーション内のその他のデバイスおよびサービスにアクセスします。同時に、Unified CM クラスタは、IP Phone などの呼制御コンポーネントとサービスに対して、電話登録、メディア リソースのプロビジョニングと割り当てなどのサービスを提供します。
また、コール ルーティング コンポーネントがネットワーク インフラストラクチャに依存してネットワーク接続を行っているのと同様、コール ルーティングのコンポーネントとサービスも、多くの場合、完全に機能するために相互依存しています。たとえば、Unified CM は、ネットワーク内のさまざまな IP エンドポイントに登録サービスおよびコール ルーティング サービスを提供する一方で、企業の外側にコールをルーティングするために、ゲートウェイおよびゲートウェイ サービスに完全に依存しています。
ネットワーク インフラストラクチャの場合と同様に、重要な Unified Communications および Collaboration コール ルーティング サービスでは、ネットワークまたは個々のコール ルーティング コンポーネントで障害が発生した場合でも必要な機能を引き続き使用できるように、ハイ アベイラビリティを実現する必要があります。発生する可能性のあるさまざまなタイプの障害、およびこれらの障害に関する設計上の考慮事項を理解することが重要となります。Unified CM クラスタリング メカニズムには冗長な性質が備えられているため、単一のサーバまたはコンポーネント(Unified CM クラスタのサブスクライバ ノードなど)に障害が発生しても、その影響がほとんどまたはまったくない場合があります。ただし、その他の場合には、単一の障害が複数のコンポーネントまたはサービスに影響を及ぼすことがあります。たとえば、PSTN ゲートウェイまたは IP ゲートウェイの障害によって、公衆電話網にアクセスできなくなる可能性があります。また、Unified CM など呼処理エージェントが引き続き使用可能で、ほとんどの機能とサービスを提供できる場合でも、ゲートウェイに障害が発生してパスを使用できなくなると、コールを PSTN にルーティングできません。このようなタイプの状況を回避するためには、複数の PSTN ゲートウェイを配置して、冗長なゲートウェイ サービスを提供し、コール ルーティングを必要に応じて両方のゲートウェイで処理できるように、呼処理エージェントを設定する必要があります。
ダイヤル プランや帯域幅管理などの機能とサービスの場合、ハイ アベイラビリティに関する考慮事項には、ネットワーク接続または呼処理エージェント アプリケーション サーバの障害によって機能が一時的に失われ、コール エージェントがコールをルーティングできなくなり、これにより、発信者がコールを発信できなくなることが含まれます。また、QoS などのコール アドミッション制御サービスが、コールを開始するエンドポイントで使用できない場合は、ネットワークのオーバーサブスクリプションが発生することもあります。たとえば、コール アドミッション制御エージェントに障害またはネットワークへの接続の切断が発生すると、コールは依然として通過できますが、コール アドミッション制御サービスではそのコールが認識されないため、品質が低下する可能性があります。このようなタイプのシナリオを回避するには、複数のコール アドミッション制御エージェントを配置することにより、コール アドミッション制御の復元性を提供します。
また、ハイ アベイラビリティの考慮事項は、ビデオ エンドポイントやリモート サイトのサバイバビリティなどのコンポーネントとサービスに関する考慮事項でもあります。デバイスが中央サイトのエージェントから呼処理サービスを利用する、ネットワーク接続リモート サイトが含まれた配置の場合、たとえば、SRST を使用するリモート サイトのサバイバビリティによって、中央サイトへの接続が切断された場合でも、リモート サイト内のローカル電話機が引き続き呼処理サービスを受信するようにできます。同様に、ビデオ エンドポイントのハイ アベイラビリティを確保するために、複数のマルチポイント コントロール ユニット(MCU)を配置して、いずれかに障害が発生した場合に備えることができます。
ネットワーク インフラストラクチャは、個々のコンポーネントおよびシステム全体のキャパシティとスケーラビリティを考慮して設計および配置する必要があります。同様に、コール ルーティング コンポーネントとサービスの配置についても、キャパシティとスケーラビリティを考慮して設計する必要があります。さまざまなコール ルーティング アプリケーションとサービスを配置する場合、それらのアプリケーションとサービス自体のスケーラビリティの考慮が重要となるだけでなく、基盤となるネットワーク インフラストラクチャのスケーラビリティを考慮する必要があります。ネットワーク インフラストラクチャは、使用可能な帯域幅を持ち、コール ルーティング コンポーネントによって発生する追加のトラフィック負荷を処理できる必要があります。同様に、コール ルーティング インフラストラクチャおよびそのコンポーネントは、必要なすべてのデバイス設定と登録以外に、コール負荷または最繁時呼数(BHCA)を処理できる必要があります。
たとえば、Unified CM などの呼処理エージェントの場合は、ユーザ数、エンドポイント数、および時間あたりのユーザごとのコール数という観点で配置のサイズを評価し、必要な負荷を処理するために十分なリソースを配置することが重要です。呼処理エージェントのサイズが小さく、十分なリソースがない場合は、負荷の増加に伴い、機能とサービスが失敗するようになります。呼処理の配置のサイズを設定する場合の 2 つの主な考慮事項は、呼処理タイプと呼処理ハードウェアです。これらは両方とも、ユーザ、ロケーション、デバイスなどの数を考慮して、システムのサイジングを適切に設定するために重要です。例として、Cisco Unified Communications Manager は、Cisco Unified Communications Manager Express よりもキャパシティが大幅に高いため、大規模な配置への使用に適しています。また、呼処理エージェントを実行するために選択されたサーバ プラットフォームによって、多くの場合、最大の負荷が決まります。
リモート サイトのサバイバビリティのためのキャパシティ プランニングは、バックアップ呼処理ハードウェアに依存するという点で、ほとんど同じです。バックアップまたは存続可能な呼処理サービスを提供するために、適切な Cisco IOS プラットフォームを選択する場合は、通常、中央サイトへの接続が切断されたときにそのサイトでサポートする必要があるデバイスとユーザの数を決定することから開始します。このサイジングで同等に重要となるのは、ローカル PSTN ゲートウェイ サービスです。中央サイトへの接続が切断された場合、ローカル PSTN ゲートウェイには、最も忙しい時間に、すべてのコールをブロックされることなくルーティングできる十分な回線がありますか。これに対する回答がいいえである場合、呼処理をバックアップできるようにリモート サイトを適切にサイジングするには、ゲートウェイまたはトランクを追加する必要があります。
PSTN ゲートウェイと IP ゲートウェイについても、配置のサイズを適切に設定して、最も忙しい時間におけるすべてのコールを処理するために、十分なキャパシティを使用できるようにする必要があります。場合によっては、十分なリソースを提供するために、複数の PSTN ゲートウェイまたは IP ゲートウェイを配置する必要がある場合があります。
QoS およびコール アドミッション制御サービスの設定とサイジングを行う場合は、必要なコール数をサポートするために、ネットワーク接続上およびプライオリティ キューで十分な帯域幅を使用できるようにしてください。十分な帯域幅を使用できない場合、追加のネットワーク キャパシティ、ゲートウェイ、および IP トランクまたはテレフォニー トランクが必要となる場合があります。
ダイヤル プラン サービスのサイジングも重要となります。ただし、多くの場合、エンドポイントや電話番号の数、ルート パターン、またはその他のダイヤル プラン構成要素の観点からのダイヤル プラン キャパシティは、使用される呼処理エージェントおよびプラットフォームに完全に依存します。
ビデオ テレフォニーなどのコンポーネントおよびサービスの場合、適切なサイジングが同様に重要となります。ビデオ テレフォニーのキャパシティ プランニングに関する考慮事項では、主に、ネットワークの帯域幅、使用可能なビデオ ポート、および MCU セッションが重要となります。基盤となるネットワーク インフラストラクチャが追加の負荷を処理できると想定すると、ほとんどの場合、アプリケーション サーバおよび MCU を増やしたり、サーバまたは MCU ハードウェアを大容量モデルにアップグレードしたりすることで、キャパシティを追加できます。
システム サイジング、キャパシティ プランニング、およびサイジングに関連する配置上の考慮事項の詳細については、コラボレーション ソリューション サイジング ガイダンスの章を参照してください。