メディア リソース
メディア リソース
発行日;2013/04/24 | ドキュメントご利用ガイド | ダウンロード ; この章pdf , ドキュメント全体pdf (PDF - 38MB) | フィードバック

目次

メディア リソース

この章の新規情報

メディア リソースのアーキテクチャ

メディア リソース マネージャ

Cisco IP Voice Media Streaming Application

音声インターフェイス

中複雑度モードと高複雑度モード

フレックス モード

会議

オーディオ会議

ビデオ会議

セキュア会議

トランスコーディング

トランスコーディング リソース

メディア ターミネーション ポイント(MTP)

ストリームの再パケット化

DTMF 変換

エンドポイント間の DTMF リレー

SIP トランク上の DTMF リレー

SIP トランクの MTP に関する要件

SIP ゲートウェイおよび Cisco Unified Border Element での DTMF リレー

H.323 トランクおよびゲートウェイ

H.323 付加サービス

H.323 発信時の Fast Connect

DTMF 変換

H.323 ゲートウェイおよび Cisco Unified Border Element での DTMF リレー

CTI ルート ポイント

会議ブリッジでの MTP の使用

MTP リソース

信頼されたリレー ポイント

アナンシエータ

Cisco RSVP Agent

保留音(Music on Hold)

ユニキャストおよびマルチキャスト MoH

MoH 選択プロセス

ユーザ保留とネットワーク保留

MoH ソース

オーディオ ファイル

固定ソース

MoH の選択

MoH コール フロー

SCCP コール フロー

SIP コール フロー

メディア リソースのキャパシティ プランニング

Cisco 2900 および 3900 シリーズ プラットフォームの考慮事項

Cisco 2800 および 3800 シリーズ プラットフォーム

保留音のキャパシティ プランニング

共存 MoH サーバとスタンドアロン MoH

サーバ プラットフォームの最大同時セッション数

リソースのプロビジョニング

メディア リソースのハイ アベイラビリティ

メディア リソース グループとメディア リソース グループ リスト

CiscoIOS ベースのメディア リソースの冗長性とフェールオーバーに関する考慮事項

保留音のハイ アベイラビリティ

メディア リソースの設計に関する留意点

配置モデル

単一サイト配置

集中型呼処理を使用するマルチサイト配置

分散型呼処理を使用するマルチサイト配置

メディアの機能と音声品質

保留音の設計に関する留意点

コーデックの選択

マルチキャスト アドレッシング

MoH オーディオ ソース

複数の固定またはライブ オーディオ ソースの使用

同一 UnifiedCM クラスタ内のユニキャストとマルチキャスト

Quality of Service(QoS)

コール アドミッション制御と MoH

保留音の配置モデル

単一サイト キャンパス(すべての配置に関連)

集中型マルチサイト配置

分散型マルチサイト配置

WAN を介したクラスタリング

メディア リソース

メディア リソースとは、ソフトウェア ベースまたはハードウェア ベースのエンティティであり、接続中のデータ ストリームに対してメディア処理を行うものです。メディア処理機能には、複数のストリームを混合して 1 つの出力ストリームを作成する機能(会議)、ある接続から別の接続にストリームを渡す機能(メディア ターミネーション ポイント)、ある圧縮タイプから別の圧縮タイプにデータ ストリームを変換する機能(トランスコーディング)、保留中の発信者への音楽のストリーミング(保留音)、エコー キャンセレーション、シグナリング、TDM 回線からの音声インターフェイス(コーディング/デコーディング)、ストリームのパケット化、オーディオのストリーミング(アナンシエータ)などが含まれます。ソフトウェアベースのリソースは、Unified CM IP Voice Media Streaming サービス(IP VMS)によって提供されます。デジタル シグナル プロセッサ(DSP)カードでは、ソフトウェア ベースとハードウェア ベースの両方のリソースが提供されます。

この章では、メディア リソース アーキテクチャおよび Cisco IP Voice Media Streaming Application サービスについての概要を説明し、さらに次のメディア リソースについて重点的に説明します。

「音声インターフェイス」

「会議」

「トランスコーディング」

「メディア ターミネーション ポイント(MTP)」

「信頼されたリレー ポイント」

「アナンシエータ」

「Cisco RSVP Agent」

「保留音(Music on Hold)」

この章を使用して、各メディア リソース タイプの機能を理解し、配置に必要なリソースを確認してください。

Cisco Integrated Service Router(ISR)ゲートウェイの適切な DSP のサイジングを行うために、Cisco Unified Communications Sizing Tool(Unified CST)を使用できます。このツールはシスコの従業員およびシスコ パートナーが http://tools.cisco.com/cucst から入手できます。シスコ パートナーまたはシスコの従業員でない場合は、 http://www.cisco.com/go/dspcalculator から DSP Calculator を使用できます。他のシスコの非 ISR ゲートウェイ プラットフォーム(Cisco 1700、2600、3700、AS5000 シリーズなど)や Cisco IOS の 12.4 以前の主要なリリースについては、 http://www.cisco.com/pcgi-bin/Support/DSP/cisco_dsp_calc.pl からレガシーの DSP Calculator にアクセスできます。

この章の新規情報

表 17-1 に、この章に新しく追加されたトピック、またはこのマニュアルの以前のリリースから大幅に改訂されたトピックの一覧を示します。

表 17-1 新規情報、またはこのマニュアルの以前のリリースからの変更情報

新規トピックまたは改訂されたトピック
説明箇所
改訂日

メディア リソース グループ(MRG)の割り当て

「メディア リソース グループとメディア リソース グループ リスト」

2012 年 10 月 31 日

Music on Hold(MoH)のキャパシティ プランニング

「保留音のキャパシティ プランニング」

2012 年 8 月 31 日

Cisco Unified Communications システム Release 9.0 向けに変更なし

2012 年 6 月 28 日

メディア リソースのアーキテクチャ

会社のメディア リソース割り当て方針を適切に策定するには、さまざまなメディア リソースコンポーネントの Cisco Unified CM アーキテクチャを理解しておくことが重要です。次の各項では、Unified CM を使用したメディア リソース設計の重要な特徴を中心に説明します。

メディア リソース マネージャ

Unified CM のソフトウェア コンポーネントであるメディア リソース マネージャ(MRM)は、メディア リソースの割り当ておよびメディア パスの挿入が必要であるかどうかを判別します。このメディア リソースは、Unified CM IP Voice Media Streaming Application サービスまたはデジタル シグナル プロセッサ(DSP)カードによって提供されます。MRM は、メディア リソースのタイプを判別および特定すると、当該デバイスに関連付けられているメディア リソース グループ リスト(MRGL)およびメディア リソース グループ(MRG)の構成の設定値に応じて、使用可能なリソース全体を検索します。MRGL および MRG は、割り当てを行うためにメディア リソースの関連するグループをまとめて保持する構成概念です。詳細については、「メディア リソース グループとメディア リソース グループ リスト」の項を参照してください。

図 17-1 は、IP 電話と Cisco Unified Border Element 間で一般的なコーデックが使用できない場合に、トランスコーダなどのメディア リソースが、これらの間のメディア パスにどのように配置されるかを示しています。

図 17-1 一般的なコーデックが使用できない場合のトランスコーダの使用

 

Unified CM は、Skinny Client Control Protocol(SCCP)を使用して、メディア リソースと通信します。このメッセージングは、Unified CM と通信エンティティ間で使用されている可能性のあるプロトコルに依存しません。図 17-2 にメッセージ フローの例を示します。ただし、この例は、エンティティ間で交換されるすべての SCCP メッセージおよび SIP メッセージを示しているわけではありません。

図 17-2 コンポーネント間のメッセージ フロー

 

Cisco IP Voice Media Streaming Application

Cisco IP Voice Media Streaming Application は、ソフトウェアベースの次のメディア リソースを提供します。

会議ブリッジ

保留音(MoH)

アナンシエータ

メディア ターミネーション ポイント(MTP)

これらのリソースの詳細については、下記のそれぞれの項で説明します。

IP Voice Media Streaming Application をアクティブにすると、上記の各リソースが 1 つずつ自動的に設定されます。必要に応じて、会議、アナンシエータ、および MTP サービスを無効にできます。これらのリソースが不要な場合は、Unified CM 設定の適切なサービス パラメータを変更して無効にすることを推奨します。サービス パラメータには、各サービスが処理できる最大接続数のデフォルト設定があります。サービス パラメータの変更方法については、次の Web サイトで入手可能な『 Cisco Unified Communications Manager Administration Guide 』の適切なバージョンを参照してください。

http://www.cisco.com/en/US/products/sw/voicesw/ps556/prod_maintenance_guides_list.html

複数のリソースが必要になる状況や、それらのリソースによって IP Voice Media Streaming Application にかかる負荷を慎重に検討してください。メディア リソースは、Unified CM と同じサーバ、または Unified CM 呼処理サービスを実行していない専用サーバに配置できます。配置にデフォルト数よりも多いリソースが必要な場合は、そのリソースを専用のサーバで実行するように設定することを推奨します。配置内でメディア リソースを頻繁に使用することが予測される場合は、専用の Unified CM メディア リソース ノード(クラスタ内で呼処理を実行しない非パブリッシャ ノード)を配置するか、ハードウェアベースのメディア リソースに依存することを推奨します。Unified CM ノード上のソフトウェアベースのメディア リソースは、メディア リソースの必要性が限られている小規模な配置に向いています。


) Cisco Business Edition 3000 では、MoH およびアナンシエータ ソフトウェアベースのメディア リソースのみ提供されます。会議および MTP に使用できるソフトウェアベースのメディア リソースはありません。ハードウェアベースの会議および MTP リソースは、Cisco MCS 7890 C2 プラットフォームのオンボード DSP カードによって提供されます。


音声インターフェイス

音声インターフェイスは、時分割多重(TDM)インターフェイス上のレッグと VoIP(Voice over IP)接続上のレッグの 2 つのコール レッグを持つコールに適用されます。TDM レッグは、エンコーディング/デコーディングとストリームのパケット化を実行するハードウェアで必ず終端します。この終端機能は、同じハードウェア モジュール、ブレード、またはプラットフォーム上にあるデジタル シグナル プロセッサ(DSP)リソースによって実行されます。

Cisco TDM ゲートウェイ上の DSP ハードウェアはすべて、音声ストリームを終端できます。また、特定のハードウェアは、会議やトランスコーディングなどの他のメディア リソース機能を実行することもできます(「会議」および 「トランスコーディング」を参照)。DSP ハードウェアには、アップグレードおよび変更ができない固定 DSP リソース、またはアップグレード可能なモジュラ DSP リソースのどちらかが搭載されています。

サポートされる DSP 当たりのコールの数は、コールに使用されるコーデックの計算の複雑度や、DSP に設定された複雑度モードによって異なります。Cisco IOS を使用すると、ハードウェア モジュールの複雑度モードを設定できます。PVDM2 や PVDM3 DSP のようなハードウェア プラットフォームは、3 つの複雑度モード(中複雑度モード、高複雑度モード、フレックス モード)をサポートします。他のハードウェア プラットフォームには、中複雑度モードと高複雑度モードのみをサポートするものもあります。

中複雑度モードと高複雑度モード

各 DSP は、中複雑度モード、高複雑度モード、またはフレックス モード(PVDM3 DSP および C5510 に基づく DSP)のいずれかとして個別に設定できます。DSP は、コールのコーデックに関する実際の複雑度に関係なく、設定されている複雑度に応じてすべてのコールを処理します。着信コールの実際の複雑度と同じかそれ以上の複雑度が設定されたリソースが使用可能になっている必要があります。そうでない場合、コールは失敗します。たとえば、コールに高複雑度コーデックが必要な場合、DSP リソースが中複雑度モードに設定されていると、コールは失敗します。ただし、高複雑度モードに設定された DSP に対して中複雑度コールが試行された場合、コールは成功し、Cisco IOS は高複雑度モードのリソースを割り当てます。

フレックス モード

フレックス モードは、C5510 チップセットを使用するハードウェア プラットフォーム上、および PVDM3 DSP 上だけで使用可能であり、このモードでは、設定時にコーデックの複雑度を指定する必要がありません。フレックス モードの DSP は、処理能力が足りる限り、サポートされているすべてのコーデック タイプのコールを受け入れます。

C5510 ベースの DSP の場合は、Millions of Instructions Per Second(MIPS)単位の処理能力を計算することで動的にトラッキングされます。Cisco IOS は、受信されたコールごとに MIPS の計算を実行し、新しいコールが開始されるたびにそのバジェットから MIPS クレジットを差し引きます。コールで消費される MIPS 数は、コールのコーデックによって異なります。着信コールに必要な MIPS 以上の MIPS クレジットが残っている限り、DSP は新しいコールを許可します。

同様に、PVDM3 DSP モジュールでは、クレジットベースのシステムを使用します。各モジュールには、メディア ストリームを処理するモジュールのキャパシティの単位を表す固定数の「クレジット」が割り当てられています。音声インターフェイス、トランスコーディングなどの各メディア動作には、クレジットによるコストが割り当てられています。DSP リソースはメディア処理用に割り当てられているため、そのコスト値は、使用可能なクレジットから差し引かれます。使用可能なクレジットが使い果たされると、DSP モジュールのキャパシティがなくなり、要求された操作に対応できなくなります。PVDM3 DSP のクレジット割り当て規則は、より複雑です。

Cisco ISR ゲートウェイの適切な DSP のサイジングを行うために、Cisco Unified Communications Sizing Tool(Unified CST)を使用できます。このツールはシスコの従業員および代理店が http://tools.cisco.com/cucst から入手できます。シスコ代理店でない場合は、 http://www.cisco.com/go/dspcalculator から DSP Calculator を使用できます。他のシスコの非 ISR ゲートウェイ プラットフォーム(Cisco 1700、2600、3700、AS5000 シリーズなど)や Cisco IOS の 12.4 以前の主要なリリースについては、 http://www.cisco.com/cgi-bin/Support/DSP/cisco_dsp_calc.pl からレガシーの DSP Calculator にアクセスできます。

フレックス モードは、同じハードウェアで複数のコーデックのコールをサポートする必要がある場合に便利です。これは、フレックス モードでは、DSP が中複雑度または高複雑度として設定されている場合よりも多くのコールをサポートできるためです。ただし、フレックス モードではリソースのオーバーサブスクリプションが許可されています。オーバーサブスクリプションになると、すべてのリソースが使用された場合にコール障害が発生するリスクが生じます。フレックス モードを使用すると、物理 TDM インターフェイスを使用する場合よりも DSP リソースの数を削減できます。

中複雑度モードまたは高複雑度モードと比べると、フレックス モードには、DSP ごとに最も多くの G.711 コールをサポートできるという利点があります。たとえば、PVDM2-16 DSP は、中複雑度モードで 8 つの G.711 コールを、またはフレックス モードで 16 の G.711 コールをサポートできます。

会議

会議ブリッジとは、複数の参加者を 1 つのコール(音声またはビデオ)に参加させるリソースです。そのデバイス上で 1 つの会議に許可される最大ストリーム数まで、所定の会議用に任意の数の接続を受け入れることができます。会議に接続されているメディア ストリームと、その会議に接続されている参加者との間には、1 対 1 の対応があります。会議ブリッジは、ストリームを混合し、接続されている通話者ごとに一意の出力ストリームを作成します。所定の通話者の出力ストリームは、接続されている全通話者からのストリームの合成から、当事者の入力ストリームを除いたものです。一部の会議ブリッジは、会議で通話量が最も多い 3 名の通話者だけを混合し、その合成ストリーム(通話量が最も多い通話者の 1 人である場合は、当事者の入力ストリームをマイナスしたもの)を各参加者に配信します。

オーディオ会議

音声会議は、ソフトウェアベースとハードウェアベースの両方の会議リソースで実行できます。ハードウェア会議ブリッジは、ソフトウェア会議ブリッジのすべての機能を備えています。さらに、一部のハードウェア会議ブリッジは、G.729 や G.723 などの複数の Low Bit-Rate(LBR; 低ビット レート)ストリーム タイプをサポートできます。この機能により、一部のハードウェア会議ブリッジが混合モードの会議を処理できるようになります。混合モードの会議では、ハードウェア会議ブリッジは、G.729 および G.723 のストリームを G.711 ストリームにトランスコードし、混合します。その後、混合したストリームを、ユーザに戻すために適切なストリーム タイプにエンコードします。G.711 会議しかサポートしないハードウェア会議ブリッジもあります。

Unified CM の制御下にあるすべての会議ブリッジは、Unified CM との通信に Skinny Client Control Protocol(SCCP)を使用します。

Unified CM は、Unified CM クラスタに登録されている会議リソースから、会議ブリッジを割り当てます。ハードウェアとソフトウェアの両方の会議リソースを同時に Unified CM に登録でき、Unified CM は、どちらのリソースからでも、会議ブリッジを割り当て、使用できます。Unified CM は、会議割り当て要求を処理するときに、これらの会議ブリッジのタイプを区別しません。

リソースがサポートできる会議の数、および 1 つの会議の最大参加者数は、リソースによって異なります。

Unified CM システムでは、次のタイプの会議ブリッジ リソースが使用されます。

「ソフトウェア オーディオ会議ブリッジ(Cisco IP Voice Media Streaming Application)」

「ハードウェア オーディオ会議ブリッジ(Cisco NM-HDV2、NM-HD-1V/2V/2VE、PVDM2、および PVDM3 DSP)」

「ハードウェア オーディオ会議ブリッジ(Cisco WS-SVC-CMM-ACT)」

「ハードウェア オーディオ会議ブリッジ(Cisco NM-HDV および 1700 シリーズ ルータ)」

ソフトウェア オーディオ会議ブリッジ(Cisco IP Voice Media Streaming Application)

ソフトウェア ユニキャスト会議ブリッジは、G.711 音声ストリームと Cisco Wideband オーディオ ストリームを混合できる標準の会議ミキサーです。Wideband または G.711 a-law および mu-law ストリームの任意の組み合わせが、同じ会議に接続される場合があります。所定の設定でサポートできる会議数は、会議ブリッジ ソフトウェアが実行されるサーバと、アプリケーションで有効になっている他の機能によって決まります。Cisco IP Voice Media Streaming Application は、複数の機能に使用することもできるリソースで、設計ではすべての機能を同時に考慮する必要があります(「Cisco IP Voice Media Streaming Application」を参照)。

ハードウェア オーディオ会議ブリッジ(Cisco NM-HDV2、NM-HD-1V/2V/2VE、PVDM2、および PVDM3 DSP)

Cisco IOS で会議リソースとして設定されている DSP は、会議機能のみに特化した DSP にファームウェアをロードします。このような DSP は、他のメディア機能には使用できません。NM-HDV2 などの PVDM2 ベースまたは PVDM3 ベースのハードウェアは、単一のシャーシで同時に音声インターフェイスに使用できますが、同時に他のメディア リソース機能には使用できません。PVDM-256K および PVDM2 に基づく DSP は、異なる DSP ファーム設定を持つため、ルータで同時に設定できるのは 1 つだけです。PVDM2 ハードウェアの DSP は、音声インターフェイス、会議、メディアの終端、またはトランスコーディングとして個別に設定されます。そのため、1 つの PVDM の複数の DSP を異なるリソース タイプとして使用できます。DSP は、まず音声インターフェイスに割り当ててから、必要に応じて他の機能に割り当ててください。

Cisco IOS Release 12.4(15)T から、参加者数の上限は 32 に増えました。これらの DSP に基づく会議には、最大 8、16、または 32 人が参加できるように設定できます。会議用の DSP リソースは、プロファイル属性に基づいて、実際の参加者数に関係なく、設定の間予約されています。モジュールのキャパシティおよび機能の正確な情報については、次のモジュール データ シートを参照してください。

PVDM2 モジュールのキャパシティ情報については、次の Web サイトで入手可能な『 High-Density Packet Voice Digital Signal Processor Module for Cisco Unified Communications Solutions 』データ シートを参照してください。

http://www.cisco.com/en/US/prod/collateral/routers/ps5854/product_data_sheet0900aecd8016e845_ps3115_Products_Data_Sheet.html

PVDM3 モジュールのキャパシティ情報については、次の Web サイトで入手可能な『 High-Density Packet Voice Video Digital Signal Processor Module for Cisco Unified Communications Solutions 』データ シートを参照してください。

http://www.cisco.com/en/US/prod/collateral/modules/ps3115/data_sheet_c78-553971.html


) Cisco Business Edition 3000 用の Cisco MCS 7890 C2 プラットフォームの統合ゲートウェイでは、最大で 24 個の会議ストリームがサポートされます。


ハードウェア オーディオ会議ブリッジ(Cisco WS-SVC-CMM-ACT)

この DSP リソースには、次のガイドラインおよび考慮事項が適用されます。

このハードウェアの DSP は、音声インターフェイス、会議、メディアの終端、またはトランスコーディングとして個別に設定されます。そのため、1 つのモジュールの複数の DSP を異なるリソース タイプとして使用できます。DSP は、まず音声インターフェイスに割り当ててください。

各 ACT ポート アダプタには、個別に設定可能な 4 つの DSP が含まれています。各 DSP は、32 人の会議参加者をサポートします。CMM モジュールごとに最大 4 つの ACT ポート アダプタを設定できます。

この Cisco Catalyst ベースのハードウェアには、ブリッジごとに 128 人まで参加できる会議ブリッジを提供できる DSP リソースが用意されています。1 つの会議ブリッジが単一の ACT ポート アダプタ上にある複数の DSP にまたがることはできますが、会議ブリッジが複数の ACT ポート アダプタにまたがることはできません。

これらの会議ブリッジでは、追加のトランスコーダ リソースなしで、G.711 コーデックおよび G.729 コーデックがサポートされます。ただし、その他のコーデックを使用する場合は、トランスコーダ リソースが必要になることがあります。

ハードウェア オーディオ会議ブリッジ(Cisco NM-HDV および 1700 シリーズ ルータ)

これらの DSP リソースには、次のガイドラインおよび考慮事項が適用されます。

このハードウェアは、C549 DSP チップセットに基づく PVDM-256K タイプのモジュールを利用します。

このハードウェアを使用する会議は、1 つのブリッジで 6 人まで参加可能なブリッジを提供します。

リソースは DSP ごとに会議ブリッジとして設定されます。

NM-HDV は 5 つまでの PVDM-256K モジュールを使用でき、Cisco 1700 シリーズ ルータは、1 つまたは 2 つの PVDM-256K モジュールを使用できます。

各 DSP は、G.711 コールまたは G.729 コールを受け付け可能な 1 つの会議ブリッジを提供します。

Cisco 1751 は、シャーシ 1 つで 5 つの電話会議に制限されています。Cisco 1760 は、シャーシごとに 20 の電話会議をサポートします。


) NM-HDV2 などの PVDM2 ベースのハードウェアは、単一のシャーシで同時に音声インターフェイスに使用できますが、同時に他のメディア リソース機能には使用できません。PVDM-256K および PVDM2 に基づく DSP は、異なる DSP ファーム設定を持つため、ルータで同時に設定できるのは 1 つだけです。


ビデオ会議

ビデオ対応エンドポイントには、オーディオ会議と同じように使用できるビデオ会議の機能があります。ビデオ会議は、SCCP デバイスから [Conf]、[Join]、または [cBarge] ソフトキーを使用してアドホック会議として呼び出すことができます。

会議のビデオ部分は次の 2 つのモードで操作できます。

Voice-Activated(話者切り替え)

このモードでは、主要参加者(最後に発言した参加者または最も声の大きい参加者)がビデオ エンドポイントに表示されます。この方法では、ビデオ部分は音声部分に追随(または音声部分を追跡)します。このモードは、1 人の参加者がほとんどの時間発言し続けるような場合(講師による講習やグループ トレーニングなど)に最適です。

Continuous-Presence(分割表示)

このモードでは、すべての(または選択した)ビデオ エンドポイントが同時に継続して表示されます。会議の音声部分は主要発言者に追随(または主要発言者を追跡)します。Continuous-Presence はより一般的なモードで、さまざまなサイトの発言者間で会議や討論を行う場合に最適です。

ビデオ会議リソースには次の 2 種類があります。

ソフトウェア ビデオ会議ブリッジ

ソフトウェア ビデオ会議ブリッジは、ソフトウェアだけを使用して会議のビデオと音声を処理します。Cisco Unified MeetingPlace Express メディア サーバは、アドホック ビデオ会議をサポートするソフトウェア ビデオ会議ブリッジです。Cisco Unified MeetingPlace Express メディア サーバでサポートされるのは、Voice-Activated モードのビデオ会議だけです。

ハードウェア ビデオ会議ブリッジ

ハードウェア ビデオ会議ブリッジには、ビデオ会議に使用されるハードウェア DSP が搭載されています。Cisco 3500 シリーズ Multipoint Control Unit(MCU; マルチポイント コントロール ユニット)および Cisco IOS Release 15.1.4M 以降では PVDM3 DSP で、このタイプのビデオ会議ブリッジが提供されます。ほとんどのハードウェア ビデオ会議ブリッジは、音声専用の会議ブリッジとしても使用できます。ハードウェア ビデオ会議ブリッジには、ビデオ トランスレーティング、高いビデオ解像度、およびスケーラビリティといった利点があります。

ビデオ会議ブリッジには、オーディオ会議のリソースと同じように、デバイス プールまたはエンドポイント用の Media Resource Group(MRG; メディア リソース グループ)および Media Resource Group List(MRGL; メディア リソース グループ リスト)について同様の特性を設定できます。

Cisco Unified CM には、インテリジェント ブリッジ選択機能があります。この機能を使用すると、会議のエンドポイントの能力に基づいて、会議リソースを選択できます。この機能の詳細については、「インテリジェント ブリッジ選択機能」を参照してください。

セキュア会議

セキュア会議は、通常の会議機能を使用して会議用メディアのセキュリティを確保し、メディアが危険にさらされないようにする手法です。会議のセキュリティ レベルはさまざまです(承認レベルや暗号化レベルなど)。セキュア会議では、デバイスおよび会議リソースを認証して、信頼できるデバイスにすることができます。また、すべての認証された参加者がその会議の暗号化されたメディアを送受信するように、会議メディアを暗号化できます。ほとんどの場合、会議のセキュリティ レベルは、会議の参加者の最低のセキュリティ レベルによって決まります。たとえば、ある 1 人の参加者がセキュアなエンドポイントを使用していない場合は、その会議全体が非セキュアになります。また、いずれかのエンドポイントが、認証はされているものの暗号化に対応していない場合には、その会議は認証モードになります。

セキュア会議は、拡張されたセキュリティ レベルの会議機能を提供し、認証されていない取り込みや電話会議の復号化を防ぎます。

セキュア会議を設計する際は、次の要素について検討してください。

デバイス(電話機や会議リソース)のセキュリティ レベル

コール シグナリングやセキュアな(SRTP)メディアのセキュリティ オーバーヘッド

帯域利用率に対する影響(セキュアな参加者が WAN 経由で参加する場合)

NAT などの中間デバイス、およびこれらのデバイス間のセキュア コールをサポートしないファイアウォール

セキュア会議は、次の制約や制限を受ける場合があります。

セキュア会議は、オーディオ会議に対してのみサポートされます。ビデオ会議はサポートされません。

セキュア会議では、Cisco IOS DSP は 1 つの会議で最大 8 人の参加者をサポートします。

また、セキュア会議は非セキュア会議よりも多くの DSP リソースを使用することがあるため、DSP Calculator に従って DSP をプロビジョニングする必要があります。

コール シグナリングのセキュリティ保護について、一部のプロトコルが IPSec に依存する場合があります。

セキュア会議は、Unified CM と Unified CM Express の間でカスケードできません。

MTP とトランスコーダはセキュア コールをサポートしません。したがって、会議へ参加しているいずれかのコールで MTP またはトランスコーダが呼び出された場合、その会議はセキュアでなくなる可能性があります。

細かいセキュリティ ポリシーが必要となる場合があります。

セキュア会議は、すべてのコーデックで使用できるとは限りません。

トランスコーディング

トランスコーダは、あるコーデックからの入力ストリームを、別のコーデックを使用する出力ストリームに変換するデバイスです。Cisco IOS Release 15.0.1M から、トランスコーダは、同じコーデックを異なるパケット サイズで利用する 2 つのストリームを接続するトランスレーティングもサポートします。

G.711 から他のコーデックへのトランスコーディングは、従来のトランスコーディングと呼ばれます。2 つの非 G.711 コーデック間のトランスコーディングは、ユニバーサル トランスコーディングと呼ばれ、Universal Cisco IOS トランスコーダが必要です。ユニバーサル トランスコーディングは、Cisco IOS Release 12.4.20T からサポートされます。ユニバーサル トランスコーディングは、従来のトランスコーディングよりも DSP の密度が低いです。

Unified CM システムでは、通常、G.711 音声ストリームと低ビットレート圧縮音声ストリームの G729a との間の変換を行うために、トランスコーダを使用します。次の場合には、どのようなときにトランスコーダ リソースが必要かが決まります。

システム全体で単一のコーデックが使用されている。

一般に、単一のコーデックは、帯域幅の節約を通常必要としない単一サイト配置で使用されます。システムのすべてのコールに対して単一のコーデックが設定されている場合、トランスコーダ リソースは必要ありません。このシナリオでは、すべてのベンダーでサポートされている G.711 を選択するのが最も一般的です。

システムで複数のコーデックが使用され、すべてのエンドポイントがすべてのコーデック タイプに対応している。

複数のコーデックを使用する最も一般的な理由は、LAN コールには G.711 を使用してコール品質を最大にし、帯域幅が制限されている WAN を通過するコールには低帯域幅コーデックを使用して帯域幅効率を最大にするためです。低帯域幅コーデックには、G.729a を使用することを推奨します。G.729a は、すべての Cisco Unified IP Phone モデル、およびその他のほとんどの Cisco Unified Communications デバイスでサポートされるため、トランスコーディングの必要がなくなります。Unified CM では、リージョン間でその他の低帯域幅コーデックも設定できますが、一部の電話機モデルはこのコーデックをサポートしないため、トランスコーダが必要になります。ゲートウェイへのコールには 1 つのトランスコーダが必要で、別の IP Phone へのコールには 2 つのトランスコーダが必要です。すべてのデバイスが G.711 と G.729 の両方をサポートし、両方で設定されている場合は、デバイスがコールごとに適切なコーデックを使用するため、トランスコーダを使用する必要はありません。

システムで複数のコーデックが使用され、一部のエンドポイントが G.711 だけをサポートしているか、または G.711 だけを使用するように設定されている。

この条件は、システムで G.729a を使用し、このコーデックをサポートしないデバイスがある場合、または G.729a をサポートするデバイスが G.729a を使用するように設定されていない場合に発生します。この場合はトランスコーダが必要です。サードパーティ ベンダーのデバイスは、G.729 をサポートしない場合があります。


) Release 2.0 以前の Cisco Unified MeetingPlace Express は、G.711 だけをサポートしています。以前のバージョンの Cisco Unified MeetingPlace Express へのコールに対して G.729 が設定されている環境では、トランスコーダ リソースが必要です。


トランスコーダは、メディア ターミネーション ポイント(MTP)と同じ機能も実行できます。トランスコーダ機能と MTP 機能の両方が必要な場合、トランスコーダがシステムによって割り当てられます。MTP 機能が必要な場合、Unified CM はトランスコーダまたは MTP をリソース プールから割り当てます。リソースの選択はメディア リソース グループによって決まります(「メディア リソース グループとメディア リソース グループ リスト」の項を参照)。

設計を最終決定するには、必要なトランスコーダの数と、トランスコーダを配置する場所を検討する必要があります。マルチサイト配置の場合は、トランスコーダを必要な各サイトにローカルに配置することを推奨します。複数のコーデックが必要な場合は、すべてのコーデックをサポートしないエンドポイントの数、これらのエンドポイントを配置する場所、これらのリソースにアクセスする他のグループ、これらのデバイスがサポートする同時コールの最大数、およびネットワーク上でこれらのリソースを配置する場所を検討する必要があります。

トランスコーディング リソース

トランスコーディングを実行するには、DSP リソースが必要です。これらの DSP リソースは、音声モジュール、および次の項で示すトランスコーディング用のハードウェア プラットフォームに配置できます。

ハードウェア トランスコーダ(Cisco NM-HDV2、NM-HD-1V/2V/2VE、および PVDM2 DSP)

DSP ごとにサポートされるセッション数は、ユニバーサル トランスコーディング モードで使用されるコーデックによって決定されます。これらの DSP リソースには、次のガイドラインおよび考慮事項が適用されます。

トランスコーディングは、G.711 mu-law または a-law と G.729a、G.729ab、G.722、および iLBC との間で使用できます。1 つの PVDM2-16 では、低複雑度コーデックと中複雑度コーデック間(G.711 と G.729a または G.722 など)のトランスコーディングに 8 セッション、または低複雑度コーデックと高複雑度コーデック間(G.711 と G.729 または iLBC など)のトランスコーディングに 6 セッションをサポートできます。


) G.711 と G.722 との間にトランスコーディングが必要ない場合は、Cisco IOS の dspfarm profile 設定に G.722 を入れないことを推奨します。これは、Unified CM が、トランスコーディングを必要とするコールのコーデックとして G.722 を選択しないようにするためです。G.722 と他のコーデック間のトランスコーディングでは、ユニバーサル トランスコーダとして設定された DSP リソースが必要です。


Cisco Unified IP Phone は、G.729 コーデックの G.729a バリアントだけを使用します。新規 DSP ファーム プロファイルのデフォルトは、G.729a/G.729ab/G.711u/G.711a です。単一の DSP が同時に提供できる機能は 1 つだけなので、プロファイルで設定する最大セッション数は、リソースを無駄にしないように、8 の倍数で指定する必要があります。

PVDM2 モジュールのキャパシティ情報については、次の Web サイトで入手可能な『 High-Density Packet Voice Digital Signal Processor Module for Cisco Unified Communications Solutions 』データ シートを参照してください。

http://www.cisco.com/en/US/prod/collateral/routers/ps5854/product_data_sheet0900aecd8016e845_ps3115_Products_Data_Sheet.html

ハードウェア トランスコーダ(Cisco WS-SVC-CMM-ACT)

この DSP リソースには、次のガイドラインおよび考慮事項が適用されます。

トランスコーディングは、G.711 mu-law または a-law と G.729a、G.729b、または G.723 との間で使用できます。

1 つの ACT ごとに、個別に DSP プールに割り当て可能な 4 つの DSP があります。

CCM-ACT は、DSP ごとに 16(ACT ごとに 64)のトランスコーディングされたコールをサポートします。ACT は、リソースをコールではなくストリームとしてレポートします。単一のトランスコーディングされたコールは、2 つのストリームで構成されます。

ハードウェア トランスコーダ(Cisco NM-HDV および 1700 シリーズ ルータ)

これらの DSP リソースには、次のガイドラインおよび考慮事項が適用されます。

このハードウェアは PVDM-256K タイプのモジュールを利用し、各 DSP は 2 つのトランスコーディング セッションを提供します。

NM-HDV は 4 つまでの PVDM-256K モジュールを使用でき、Cisco 1700 シリーズ ルータは、1 つまたは 2 つの PVDM-256K モジュールを使用できます。Cisco 1751 ルータのシャーシは 16 セッションに制限されています。Cisco 1760 ルータのシャーシは 20 セッションに制限されています。

NM-HDV モジュールと NM-HDV2 モジュールは、単一のシャーシで同時に音声インターフェイスに使用できますが、同時に他のメディア リソース機能には使用できません。会議、MTP、またはトランスコーディングに対して同時にアクティブにできる DSP ファームのタイプは 1 つだけです(NM-HDV または HM-HDV2)。

G.711 mu-law または a-law から G.729、G.729a、G.729b、または G.729ab コーデックへのトランスコーディングがサポートされます。

ハードウェア トランスコーダ(PVDM3 DSP)

PVDM3 DSP は、Cisco 2900 シリーズおよび 3900 シリーズのサービス統合型ルータによってホストされており、任意のコーデックとのセキュアなトランスコーディングと非セキュア トランスコーディングの両方をサポートしています。音声インターフェイスおよび会議と同様に、各トランスコーディング セッションでは、各 PVDM3 DSP タイプの使用可能なクレジットが差し引かれます。使用可能なクレジットによって、DSP の合計キャパシティが決まります。

たとえば、1 つの PVDM3-16 では、低複雑度コーデックと中複雑度コーデック間(G.711 と G.729a または G.722 など)のトランスコーディングに 12 セッション、または低複雑度コーデックと高複雑度コーデック間(G.711 と G.729 または iLBC など)のトランスコーディングに 10 セッションをサポートできます。


) Cisco Business Edition 3000 では、デフォルト ゲートウェイ設定は、Cisco MCS 7890 アプライアンスごとに 10 のトランスコーディング セッションのみをサポートします。


PVDM3 モジュールのキャパシティ情報については、次の Web サイトで入手可能な『 High-Density Packet Voice Video Digital Signal Processor Module for Cisco Unified Communications Solutions 』データ シートを参照してください。

http://www.cisco.com/en/US/prod/collateral/modules/ps3115/data_sheet_c78-553971.html

メディア ターミネーション ポイント(MTP)

メディア ターミネーション ポイント(MTP)は、2 つの全二重メディア ストリームを受け入れるエンティティです。MTP はこの 2 つのストリームをブリッジし、これらのストリームを個々にセットアップおよび終了できるようにします。ある接続の入力ストリームから受信されるストリーミング データは、他の接続の出力ストリームに渡され、逆も同様です。MTP には次のような多くの用途があります。

「ストリームの再パケット化」

「DTMF 変換」

プロトコル固有の用途

「SIP トランク上の DTMF リレー」

「H.323 付加サービス」

「H.323 発信時の Fast Connect」

ストリームの再パケット化

MTP は、G.711 a-law 音声パケットから G.711 mu-law パケット(およびその逆)にトランスコードしたり、パケット化周期が異なる(使用するサンプル サイズが異なる)2 つの接続をブリッジしたりできます。再パケット化するには、Cisco IOS MTP に DSP リソースが必要です。

DTMF 変換

コール中にメニュー システムのナビゲート、データの入力、またはその他の操作の目的で遠端のデバイスに信号を送信する際は、DTMF トーンが使用されます。これらは、呼制御の一部としてコール セットアップ中に送信される DTMF トーンとは異なる方法で処理されます。IP 上で DTMF を送信する方法はいくつかありますが、2 つの通信エンドポイントで共通の手順がサポートされていない場合があります。このような場合、Unified CM はメディア パスに動的に MTP を挿入して、DTMF 信号をエンドポイント間で変換できます。残念ながら、このようなコールには MTP リソースが 1 つずつ必要となるため、この方法は拡張性に欠けています。必要な MTP リソースの最適な量は、以降の項に従い、システム内のエンドポイント、トランク、およびゲートウェイの組み合わせに基づいて判断してください。

MTP の挿入が必要であると判断された場合に使用可能な MTP リソースがないとき、Unified CM はサービス パラメータ [Fail call if MTP allocation fails] の設定に従って、そのコールを続行するかどうかを決定します。

エンドポイント間の DTMF リレー

次の方法を使用して、DTMF を 1 つのエンドポイントから別のエンドポイントにリレーします。

Named Telephony Event(RFC 2833)

RFC 2833 で規定されている Named Telephony Event(NTE)は、コール メディアが確立された後で、あるエンドポイントから別のエンドポイントに DTMF を送信する方式です。トーンは、すでに確立されている RTP ストリームを使用して、パケット データとして送信されます。これらのトーンは、RTP ペイロード タイプ フィールドによってオーディオとは区別されます。たとえば、コールのオーディオをセッションで送信する際は、そのオーディオを G.711 データとして識別する RTP ペイロード タイプを使用できます。DTMF パケットの送信時には、そのパケットを NTE として識別する RTP ペイロード タイプが使用されます。ストリームの受信側は、G.711 パケットと NTE パケットを別々に利用します。

Key Press Markup Language(RFC 4730)

Key Press Markup Language(KPML)は RFC 4730 で規定されています。DTMF をインバンドで送信する NTE とは異なり、KPML はシグナリング チャネルを使用して(つまり、アウトオブバンド(OOB)で)、DTMF 番号を含む SIP メッセージを送信します。

KPML 手順では、DTMF 番号の登録に SIP SUBSCRIBE メッセージが使用されます。DTMF 番号自体は、XML で符号化された本体を含む NOTIFY メッセージで送信されます。

Unsolicited Notify(UN)

Unsolicited Notify 手順は、主に Cisco IOS SIP ゲートウェイにおいて、SIP NOTIFY メッセージを使用して DTMF 番号を転送するために使用されます。KPML とは異なり、これらの NOTIFY メッセージは非請求メッセージで、これらのメッセージを受信するために事前に SIP SUBSCRIBE メッセージで登録が行われることはありません。ただし、KPML と同様に、Unsolicited Notify メッセージもアウトオブバンドです。

また、KPML には XML で符号化されたメッセージ本体が含まれますが、Unsolicited Notify の NOTIFY メッセージの本体はそれとは異なり、DTMF イベントを表す 10 文字の符号化された数字、ボリューム、および継続時間です。

H.245 Signal、H.245 Alphanumeric

H.245 は、H.323 ネットワークで使用されるメディア制御プロトコルです。メディア特性のネゴシエートに使用されるほか、DTMF 転送用のチャネルも提供します。H.245 はシグナリング チャネルを利用するため、DTMF 番号はアウトオブバンド(OOB)で送信されます。Signal 方式は、Alphanumeric 方式よりも多くの DTMF イベント情報(DTMF イベントの実際の継続時間など)を伝送します。

シスコ独自の RTP

この方法は DTMF 番号をインバンドで(つまり、RTP パケットと同じストリームで)送信します。ただし、DTMF パケットはメディア パケットとは符号化方法が異なり、別のペイロード タイプが使用されます。この方法は Unified CM ではサポートされていませんが、Cisco IOS ゲートウェイではサポートされています。

Skinny Client Control Protocol(SCCP)

SCCP は、Unified CM により、Unified CM に登録されている SCCP ベースの各種デバイスを制御するために使用されます。SCCP は、Unified CM と制御デバイス間で DTMF 番号を転送するアウトオブバンド メッセージを定義します。

同じ Unified CM クラスタのエンドポイント間での DTMF リレー

同じクラスタ内の Unified CM サーバに登録されたエンドポイントには、次の規則が適用されます。

SIP 以外の 2 つのエンドポイント間のコールには、MTP は必要ありません。

SIP 以外のすべての Cisco Unified Communications エンドポイントはさまざまなシグナリング パスによって DTMF を Unified CM に送信し、Unified CM は受け取った DTMF を異なるエンドポイント間で転送します。たとえば、IP Phone は Unified CM への SCCP メッセージを使用して DTMF を送信します。この DTMF は H.245 シグナリング イベントによって H.323 ゲートウェイに送信されます。Unified CM は、異なるシグナリング方式の間で DTMF を転送できます。

2 つの Cisco SIP エンドポイント間のコールには、MTP は必要ありません。

Cisco SIP エンドポイントはすべて NTE をサポートしているため、DTMF はエンドポイント間で直接送信され、変換は不要です。

SIP エンドポイントと SIP 以外のエンドポイントの組み合わせの場合、MTP が必要になることがあります。

ご使用のデバイスで NTE がサポートされるかどうかは、そのデバイスの製品マニュアルを参照してください。NTE のサポートは SIP に限定されていないため、その他の呼制御プロトコルを使用するデバイスでサポートされていることがあります。Unified CM は、エンドポイントのペアの機能に基づき、MTP をコール単位に動的に割り当てることができます。

SIP トランク上の DTMF リレー

SIP トランク設定は、SIP ユーザ エージェント(別の Cisco Unified CM クラスタや SIP ゲートウェイなど)との通信をセットアップする際に使用されます。

SIP はセッション記述プロトコル(SDP)によってメディア情報をネゴシエートします。これにより、一方が提示したメディア セットに他方が応答する形で、使用するメディアがある組み合わせに決定します。SIP では、発信側が初期 INVITE メッセージ(アーリー オファー)によって初期のオファーを送信するか、発信側がそうしなかった場合は着信側が最初の信頼性のある応答(ディレイド オファー)で初期のオファーを送信できます。

デフォルトで、Unified CM SIP トランクは、初期のオファー(ディレイド オファー)を伴わない INVITE を送信します。Unified CM には、SIP トランクが INVITE でオファー(アーリー オファー)を送信できるようにする 2 つの設定可能なオプションがあります。

メディア ターミネーション ポイントが必須(Media Termination Point Required)

SIP トランク上でこのオプションをオンにすると、すべての発信コールに対して 1 つの MTP が割り当てられます。静的に割り当てられるこの MTP は、G.711 コーデックまたは G.729 コーデックしかサポートしません。つまり、メディアが音声コールに限定されます。

音声コールとビデオ コールに対するアーリー オファーのサポート(必要な場合は MTP を挿入)

SIP トランクに関連付けられた SIP プロファイル上でこのオプションをオンにすると、発信元のデバイスが Unified CM にアーリー オファーの作成に必要なメディア特性を提供できない場合(たとえば、Unified CM に対する着信コールがディレイド オファー SIP トランクまたは Slow Start H.323 トランク上で受信される場合)にのみ MTP が挿入されます。このオプションは、Unified CM 8.5 以降のリリースでのみ使用できます。

通常、[Early Offer support for voice and video calls (insert MTP if needed)] 設定オプションは MTP の使用を抑えるため、このオプションの使用を推奨します。SIP アーリー オファー トランク経由で Unified CM に登録された旧式の SCCP 電話機からのコールでは、オファー SDP の作成に MTP が使用されます。このようなコールでは、音声、ビデオ、および暗号化がサポートされます。SIP ディレイド オファーまたは H.323 Slow Start を使用した呼が、SIP アーリー オファーを使用するトランクに着信する場合、オファー SDP の情報を MTP を使用して生成します。ただし、このようなコールの初期コール セットアップでは音声しかサポートされませんが、着信側または発信側のデバイスがビデオ通話を呼び出した場合にそれをサポートするようにコールをエスカレーションできます。

また、INVITE メッセージに初期のオファーが含まれているかどうかにかかわらず、着信 INVITE メッセージに MTP リソースは必須ではないことにも注意してください。

Unified CM によって MTP が割り当てられるかどうかは、両方の通信エンドポイントの機能と中間デバイスの設定(該当する場合)によって決まります。たとえば、SIP トランクでの DTMF 交換の処理について特定の方法(KPML を使用して DTMF を伝送する、NTE を使用するように通信エンドポイントに指示する、など)が設定されている場合があります。


) この項に記載されているように、SIP アーリー オファーは、SIP トランク上で [Media Termination Point Required] オプションをオンにすることによっても有効にできます。ただし、このオプションでは、MTP が、必要に応じてではなく、すべての発信コールに対して割り当てられるため、MTP の使用が増大します。


SIP トランクの MTP に関する要件

デフォルトでは、SIP トランク パラメータの [Media Termination Point Required] と SIP プロファイル パラメータの [Early Offer support for voice and video calls (insert MTP if needed)] は選択されていません。

SIP トランクで MTP リソースが必要かどうかを判断するには、次の手順に従います。

1. この SIP トランクで定義されている対向の SIP デバイスが、SIP アーリー オファーを含まない着信コールを受け入れられるかどうかを確認します。

受け入れられない場合、このトランクに関連付けられた SIP プロファイルで、[Early Offer support for voice and video calls (insert MTP if needed)] チェックボックスをオンにして有効にします。発信 SIP トランク コールでは、アーリー オファーの作成に必要なメディア特性を持つ Unified CM を発信側デバイスが提供できない場合、または DTMF 変換が必要な場合にのみ、MTP が挿入されます。

受け入れられる場合は、[Early Offer support for voice and video calls (insert MTP if needed)] チェックボックスをオンにせず、ステップ 2. に進んで、MTP が DTMF 変換に対して動的に挿入されるかどうかを判断します。MTP による DTMF 変換は、どのコーデックを使用している場合でも実行できます。


) [Early Offer support for voice and video calls (insert MTP if needed)] のオプションは、Unified CM 8.5 以降のリリースでのみ使用できます。


2. トランクの DTMF Signaling Method を選択します。このパラメータは、そのトランクでの DTMF 選択の動作を制御します。すべてのコールについて、DTMF 方式を一致させるために、必要に応じて使用可能な MTP が割り当てられます。

a. DTMF Signaling Method:No Preference

このモードでは、Unified CM は、最も適切な DTMF シグナリング方式を選択することで、MTP の使用を最小限に抑えようとします。

両方のエンドポイントが NTE をサポートしている場合は、MTP は必要ありません。

両方のデバイスがいずれかのアウトオブバンド DTMF メカニズムをサポートしている場合、Unified CM は SIP トランク上で KPML または Unsolicited Notify を使用します。たとえば、上記のように設定された SIP トランク上で、SCCP を使用する Cisco Unified IP Phone 7936(SCCP メッセージングだけを使用して DTMF をサポートします)が、SIP を使用する Cisco Unified IP Phone 7970(NTE および KPML を使用して DTMF をサポートします)と通信する場合がこれに該当します。MTP が必要となるのは、片方のエンドポイントがアウトオブバンドのみをサポートし、もう片方が NTE のみをサポートする場合に限られます(たとえば、SIP Cisco Unified IP Phone 7970 と通信する SCCP Cisco Unified IP Phone 7936 など)。

b. DTMF Signaling Method:RFC 2833

トランク全体の DTMF シグナリング方式を制限することにより、一方または両方のエンドポイントが NTE をサポートしていない場合に MTP を強制的に割り当てます。この設定では、MTP が割り当てられないのは、両方のエンドポイントが NTE をサポートしている場合だけです。

c. DTMF Signaling Method:OOB and RFC 2833

このモードでは、SIP トランクを通じて KPML(または Unsolicited NOTIFY)と NTE ベースの両方の DTMF が送信されます。これは MTP の使用される可能性が最も高いモードです。MTP リソースが必要とされない唯一のケースは、両方のエンドポイントが NTE といずれかの OOB DTMF 方式(KPML または SCCP)の両方をサポートしている場合です。


) Cisco Unified IP Phone は、DTMF を SCCP 経由で受信した場合、エンド ユーザに対して DTMF を再生しますが、NTE で受信したトーンは再生しません。ただし、DTMF を別のエンド ユーザに送信する必要はありません。DTMF を必要とするエンドポイント(PSTN ゲートウェイ、アプリケーション サーバなど)と対応するコールを発信するエンドポイントについてのみ検討する必要があります。


SIP ゲートウェイおよび Cisco Unified Border Element での DTMF リレー

Cisco SIP ゲートウェイは、その設定に応じて、DTMF メカニズムとして KPML、NTE、または Unsolicited Notify をサポートします。システムにはさまざまなエンドポイントが混在している場合があるため、複数の方式をゲートウェイに同時に設定することで、MTP の要件を最小限に抑えることができます。

Cisco SIP ゲートウェイでは、SIP ダイヤル ピアの DTMF リレー方式として、 sip-kpml rtp-nte の両方を設定します。このように設定すると、NTE だけをサポートするものや OOB 方式だけをサポートするものも含めて、すべてのタイプのエンドポイント間で MTP リソースなしに DTMF 交換を実現できます。この設定では、ゲートウェイは NTE と KPML の両方を Unified CM とネゴシエートします。Unified CM のエンドポイントで NTE がサポートされていない場合は、DTMF 交換に KPML が使用されます。両方の方式のネゴシエーションが成功した場合、ゲートウェイは NTE を使用して DTMF 番号を受信し、KPML へのサブスクライブは行いません。

Cisco SIP ゲートウェイでは、DTMF に独自の Unsolicited Notify(UN)方式を使用することもできます。UN 方式は、DTMF トーンを表すテキストをメッセージ本体に含む SIP Notify メッセージを送信します。この方式は Unified CM でもサポートされており、 sip-kpml が有効でない場合に使用されます。DTMF リレー方式として sip-notify を設定します。この方式はシスコ独自のものである点に注意してください。

NTE だけをサポートする SIP ゲートウェイでは、NTE をサポートしないエンドポイントと通信する場合、MTP リソースの割り当てが必要となります。

H.323 トランクおよびゲートウェイ

H.323 ゲートウェイおよびトランクでは、次の 3 つの理由で MTP が呼び出されます。

「H.323 付加サービス」

「H.323 発信時の Fast Connect」

「DTMF 変換」

H.323 付加サービス

H.323v2 で規定された Empty Capabilities Set(ECS)で使用する OpenLogicalChannel および CloseLogicalChannel 要求機能をサポートしていない H.323 エンドポイントでも、MTP を利用することでこれらの機能をサポートすることができます。この要件はあまり発生しません。すべての Cisco H.323 エンドポイント、およびほとんどのサードパーティのエンドポイントが ECS をサポートしています。必要に応じて、MTP が割り当てられ、H.323 エンドポイントに代わってコールに接続されます。MTP が H.323 コールで要求され、使用できるものがない場合、コールは処理されますが、付加サービスを呼び出すことはできません。

H.323 発信時の Fast Connect

H.323 では、Fast Connect という手順が定義されています。これは、コール セットアップ時に交換されるパケット数を削減し、メディアを確立する時間を短縮します。この手順では、制御チャネルのシグナリングに Fast Start 要素を使用します。H.323 を利用する 2 つのデバイスのネットワーク遅延が高いときは、この遅延がメディアを確立する時間に影響を与えるため、この手順が役立ちます。Unified CM は、コール セットアップの方向に基づき、着信 Fast Start と発信 Fast Start を区別します。MTP 要件が同じではないため、この区別は重要です。着信 Fast Start の場合、MTP は必要ありません。H.323 トランクの発信コールは、Fast Start が有効なとき、MTP を必要とします。多くの場合、問題になるのは、着信コールだけです。問題を解決するには、発信 Fast Start を有効にせずに着信 Fast Start を使用します。

DTMF 変換

H.323 トランクは、H.245 アウトオブバンド方式による DTMF のシグナリングをサポートします。H.323 クラスタ間トランクは、NTE による DTMF もサポートします。H.323 トランクには DTMF 設定オプションはありません。DTMF 転送方式は Unified CM によって動的に選択されます。

異なるクラスタにある 2 つのエンドポイントが H.323 トランクを使用して接続する場合は、次のケースが起こり得ます。

両方のエンドポイントが SIP の場合は、NTE が使用されます。DTMF のために MTP は必要ありません。

一方のエンドポイントが SIP で、KPML と NTE の両方をサポートしていて、他方のエンドポイントが SIP でない場合は、SIP エンドポイントから Unified CM に KPML で DTMF が送信され、トランクでは H.245 が使用されます。DTMF のために MTP は必要ありません。

一方のエンドポイントが SIP で、NTE だけをサポートしていて、他方のエンドポイントが SIP でない場合は、トランクで H.245 が使用されます。この場合はコールに対して使用可能な MTP が割り当てられます。MTP は、SIP エンドポイントがある Unified CM クラスタで割り当てられます。

たとえば、SIP を使用する Cisco Unified IP Phone 7970 が、SCCP を使用する Cisco Unified IP Phone 7970 と通信する場合は、SIP トランク経由で接続されるときは NTE が使用され、H.323 トランク経由で(H.245 方式を使用するトランクを使用して)通信するときは OOB 方式が使用されます。

コールがある H.323 トランクから着信し、そのコールを別の H.323 トランクにルーティングする場合、両方のエンドポイントが SIP のときは、DTMF 用に NTE が使用されます。どちらか一方のエンドポイントが SIP でないときは、H.245 が使用されます。一方が NTE だけをサポートする SIP エンドポイントで、他方が SIP でない場合は、MTP が割り当てられます。

H.323 ゲートウェイおよび Cisco Unified Border Element での DTMF リレー

H.323 ゲートウェイは、H.245 Alphanumeric、H.245 Signal、NTE、およびメディア ストリームのオーディオによる DTMF リレーをサポートします。現時点では、H.323 ゲートウェイ用の Unified CM において NTE オプションはサポートされていないため、使用できません。これに適したオプションは H.245 Signal です。他のエンドポイントに Unified CM と共通のシグナリング機能がない場合、H.323 ゲートウェイへのコールを確立するために、MTP が必要です。たとえば、SIP スタックを実行している Cisco Unified IP Phone 7960 は NTE だけをサポートするため、H.323 ゲートウェイを使用する場合は MTP が必要です。

CTI ルート ポイント

CTI ルート ポイントは、CTI イベントを使用して CTI アプリケーションと通信します。DTMF の観点では、CTI ルート ポイントは、すべての OOB 方式をサポートし、RFC 2833 はサポートしないエンドポイントと見なすことができます。そのようなエンドポイントで DTMF 変換に MTP が必要となるケースは、RFC 2833 だけをサポートする別のエンドポイントと通信する場合だけです。

電話コールのファーストパーティ制御を持つ CTI ルート ポイントは、コールのメディア ストリームに参加し、MTP の挿入を必要とします。CTI によるコールのサードパーティ制御が可能で、メディアが CTI で制御されているデバイスを通過する場合、MTP が必要かどうかは制御されるデバイスの機能によって異なります。

例 17-1 NTE 変換用に MTP を必要とするコール フロー

例として、ファーストパーティ制御(CTI ポートがメディアの終端)の CTI ルート ポイントがあり、IVR メニューをナビゲートするために DTMF を使用するシステムに統合されているシステムを考えます。システムのすべての電話機が SCCP を実行している場合、MTP は必要ありません。この場合、Unified CM が CTI ポートを制御し、IP Phone からの DTMF を SCCP 経由で受信します。Unified CM が、DTMF 変換を提供します。

ただし、SIP スタックを実行している電話機(NTE だけをサポートしていて、KPML をサポートしていない電話機)がある場合は、MTP が必要です。NTE はメディア ストリームの一部なので、Unified CM は受信しません。MTP がメディア ストリームの中に呼び出され、SCCP を使用する 1 つのコール レッグと NTE を使用する 2 番めのコール レッグを持ちます。MTP は Unified CM によって SCCP 制御下に置かれ、NTE から SCCP への変換を実行します。KPML をサポートしている新しい電話機では、MTP は必要ありません。

会議ブリッジでの MTP の使用

MTP は、会議の参加者のデバイスの中に RFC 2833 を使用するデバイスがある場合に使用されます。会議機能が呼び出されると、Unified CM が、コールに含まれており、RFC 2833 だけをサポートするすべての会議参加者のデバイスに MTP リソースを割り当てます。これは、会議ブリッジの DTMF 機能が使用されているかどうかにかかわらず行われます。

MTP リソース

次のタイプのデバイスは、MTP として使用できます。

ソフトウェア MTP(Cisco IP Voice Media Streaming Application)

ソフトウェア MTP とは、Unified CM サーバ上で Cisco IP Voice Media Streaming Application を有効にすることによって設定されるデバイスです。インストールされたアプリケーションが、MTP アプリケーションとして設定されると、そのアプリケーションは、Unified CM ノードに登録され、サポートする MTP リソース数を Unified CM に知らせます。ソフトウェア MTP デバイスは、G.711 ストリームだけをサポートします。IP Voice Media Streaming Application は、複数の機能に使用することもできるリソースで、設計ガイダンスではすべての機能を同時に考慮する必要があります(「Cisco IP Voice Media Streaming Application」を参照)。

ソフトウェア MTP(Cisco IOS に基づく)

ルータでソフトウェアベースの MTP を提供する機能は、Cisco 3800 シリーズ ルータでは Cisco IOS Release 12.3(11)T、Cisco 2900 シリーズおよび 3900 シリーズ ルータでは Release 15.0(1)M、ASR1002、1004、および 1006 ルータでは、Release IOS-XE、ASR1001 ルータでは、Release IOS-XE 3.2、その他のルータ モデルでは、Release 12.3(8)T4 から使用できるようになりました。

この MTP によって、G.711 mu-law および a-law、G.729a、G.729、G.729ab、G.729b、およびパススルーのコーデックを設定できます。ただし、同時に設定できるコーデックは 1 つだけです。これらの内の一部のコーデックは、Unified CM では実装していません。

ルータ設定では、最大 1,000 の個別ストリームが可能で、500 のトランスコーディングされたセッションをサポートします。この数の G.711 ストリームを使用すると、10 MB のトラフィックが生成されます。Cisco ISR G2 および ASR ルータでは、これよりもはるかに大きな数をサポートできます。

ハードウェア MTP(PVDM2、Cisco NM-HDV2 および NM-HD-1V/2V/2VE)

このハードウェアは、PVDM-2 モジュールを使用して DSP を提供します。

各 DSP は、16 の G.711 mu-law または a-law MTP セッション、8 つの G.729a または G.722 MTP セッション、または 6 つの G.729 または G.729b MTP セッションを提供できます。

ハードウェア MTP(PVDM3 を搭載した Cisco 2900 および 3900 シリーズ ルータ)

これらのルータでは、マザーボード上の PVDM3 DSP をネイティブに使用するか、またはマザーボード上やサービス モジュール上のアダプタによる PVDM2 を使用します。

各 DSP タイプのキャパシティの範囲は、16 G.711 a-law または mu-law セッション(PVDM3-16 の場合)から、256 G.711 セッション(PVDM3-256 の場合)までとなります。


) Cisco IOS でハードウェア MTP リソースを設定している場合は、G.729 または G.729b コーデックは設定できません。ただし、他のすべての MTP リソースが使い果たされた場合、または使用できない場合には、Unified CM はハードウェア トランスコーディング リソースを MTP として使用できます。


信頼されたリレー ポイント

信頼されたリレー ポイント(TRP)はメディア ストリームに挿入可能なデバイスの一種で、そのストリームのコントロール ポイントとして機能します。TRP を使用すると、そのストリームにさらに処理を加えることができます。また、ストリームが任意の特定のパスを通るようにする手段として TRP を使用することも可能です。TRP 機能を使用するためには 2 つの要素が存在します。1 つは CUCM 上で論理的に TRP を設定すること。もう 1 つは実際に TRP として動作するコールのアンカーポイントとなるデバイスです。TRP 機能は MTP デバイスをアンカーポイントとして使用する際に使うことができます。

Unified CM の個々の電話機に関する設定に、その電話機へのコールまたはその電話機からのコールに対して TRP を呼び出すための設定パラメータが新しく追加されました。TRP リソースの管理には、メディア リソース プール メカニズムが利用されます。その電話機のメディア リソース プールには、TRP として呼び出し可能なデバイスが含まれている必要があります。

TRP を QoS 強制メカニズムとして使用する例については、「ネットワーク インフラストラクチャ」の章を参照してください。冗長ファイアウォールを備えた冗長なデータセンターでメディア ストリームのアンカー ポイントとして TRP を利用する例については、「Unified Communications のセキュリティ」の章を参照してください。

アナンシエータ

アナンシエータは Cisco IP Voice Media Streaming Application のソフトウェア機能で、これを使用すると、音声メッセージや各種コール プログレス トーンをシステムからユーザに流すことができます。これは、SCCP メッセージを使用して RTP ストリームを確立します。また、複数の一方向 RTP ストリームを Cisco IP Phone またはゲートウェイなどのデバイスに送信できます。この機能を使用するには、デバイスが SCCP に対応している必要があります。SIP 電話機およびデバイスは、これまでどおりアナンシエータによって提供されるさまざまなメッセージをすべて受信できます。SIP デバイスの場合、これらのメッセージおよびトーンはすべて、必要に応じて Unified CM からの SIP シグナリング メッセージで呼び出せるように、登録時にデバイスにダウンロード(プッシュ)されます。

トーンとアナウンスは、システムで事前に定義されています。アナウンスでは、ローカリゼーションがサポートされています。また、適切な .wav ファイルを置き換えて、アナウンスをカスタマイズすることもできます。アナンシエータは、トランスコーディング リソースを使用しないで、G.711 a-law および mu-law、G.729、および Wideband コーデックをサポートできます。

次の機能には、アナンシエータ リソースが必要です。

Cisco Multilevel Precedence Preemption(MLPP)

この機能には、次のようなコール失敗の状態に応じて再生されるストリーミング メッセージが用意されています。

優先順位の高い既存のコールが原因で、プリエンプション処理できない。

優先順位アクセス制限に到達した。

試行された優先順位レベルが許可されていない。

着信番号が、プリエンプション処理またはコール ウェイティングに対応していない。

SIP トランクを介した統合

SIP エンドポイントには、トーンを生成し、RTP ストリームでインバンドで送信する機能があります。SCCP デバイスにはこの機能がないため、SIP エンドポイントと統合した場合、DTMF トーンの生成または受け入れ時にはアナンシエータと MTP が併用されます。次のタイプのトーンがサポートされます。

コール プログレス トーン(ビジー、アラート、およびリングバック)

DTMF トーン

Cisco IOS ゲートウェイとクラスタ間トランク

これらのデバイスには、コール プログレス トーン(リングバック トーン)のサポートが必要です。

システム メッセージ

次のようなコール失敗の状態では、システムはエンド ユーザにストリーミング メッセージを再生します。

ダイヤル番号をシステムが認識できない。

サービスが中断したためコールがルーティングされない。

番号が通話中で、その番号がプリエンプション処理またはコール ウェイティング用に設定されていない。

会議

電話会議の間、システムは、参加者がブリッジに参加、またはブリッジから退出したことをアナウンスするときに、割り込み音を再生します。

Cisco IP Voice Media Streaming Application をサーバ上でアクティブにすると、アナンシエータがシステム内に自動的に作成されます。Media Streaming Application を非アクティブにすると、アナンシエータも削除されます。単一のアナンシエータ インスタンスは、パフォーマンス要件を満たす場合は、Unified CM クラスタ全体にサービスを提供できます(「アナンシエータのパフォーマンス」を参照)。そうでない場合は、追加のアナンシエータをクラスタ用に設定する必要があります。追加のアナンシエータを設定するには、クラスタ内の他のサーバ上で Cisco IP Voice Media Streaming Application をアクティブにします。

アナンシエータは、そのデバイス プールで定義されたとおり、一度に 1 つの Unified CM に登録されます。デバイス プールに対してセカンダリが設定されている場合、アナンシエータは自動的にセカンダリ Unified CM にフェールオーバーします。障害発生時に再生されるアナウンスはいずれも保持されません。

アナンシエータはメディア デバイスと見なされるため、メディア リソース グループ(MRG)に含めて、電話機およびゲートウェイで使用されるアナンシエータの選択を制御できます。

アナンシエータのパフォーマンス

デフォルトでは、アナンシエータは 48 のストリームを同時にサポートするように設定されています。この設定値は、Unified CM サービスが同一のサーバ(共存)上で動作するアナンシエータに推奨される最大値です。サーバの接続性が 10 Mbps しかない場合は、設定を下げて同時ストリームを 24 にします。

Cisco CallManager Service を含まないスタンドアロン サーバでは、最大 255 のアナウンス ストリームを同時にサポートできます。デュアル CPU と高性能ディスク システムを持つ高性能サーバでは、最大 400 のストリームをサポートできます。複数のスタンドアロン サーバを追加して、必要な数のストリームをサポートできます。

Cisco RSVP Agent

トポロジ対応型のコール アドミッション制御を提供するために、Unified CM は 1 つまたは 2 つの RSVP Agent をコール セットアップ時に呼び出し、IP WAN で RSVP 予約を実行します。これらのエージェントは、RSVP 機能を提供するように設定された MTP またはトランスコーダ リソースです。RSVP リソースは、Unified CM による MTP またはトランスコーダ リソースの割り当てという観点から見て、通常の MTP またはトランスコーダと同様に処理されます。

Cisco RSVP Agent 機能は、Cisco IOS Release 12.4(6)T で最初に導入されました。RSVP および Cisco RSVP Agent の詳細については、「コール アドミッション制御」の章を参照してください。

保留音(Music on Hold)

保留音(MoH)機能を利用するには、各 MoH サーバが Unified CM クラスタに含まれ、データ レプリケーション スキーマに参加している必要があります。特に、MoH サーバは、データベース レプリケーション プロセスを通じて、次の情報を Unified CM クラスタと共有する必要があります。

オーディオ ソース:設定されたすべての MoH オーディオ ソースの数と ID

マルチキャストまたはユニキャスト:これらのソースそれぞれに設定されたトランスポートの種類

マルチキャスト アドレス:マルチキャストとしてストリーミングするように設定されたソースのマルチキャスト ベース IP アドレス

MoH サーバを設定するには、1 つ以上の Unified CM ノードで Cisco IP Voice Media Streaming Application サービスを有効にします。MoH サーバは、Unified CM とともに同じサーバに配置することも、スタンドアロン モードで配置することもできます。

ユニキャストおよびマルチキャスト MoH

Unified CM は、ユニキャストおよびマルチキャストの MoH トランスポート メカニズムをサポートしています。

ユニキャスト MoH ストリームは、MoH サーバから MoH を要求しているエンドポイントへの、ポイントツーポイントの片通話のリアルタイム転送プロトコル(RTP)ストリームです。これは、ユーザまたは接続ごとに別々のソース ストリームを使用します。したがって、20 台のデバイスが保留になっている場合、サーバとこれらのエンドポイント デバイス間のネットワーク上で、ストリームが 20 本生成されます。ユニキャスト MoH が非常に役立つのは、マルチキャストが使用可能になっていないネットワークの場合や、デバイスがマルチキャスト対応になっていないネットワークの場合です。このようなときに、管理者はユニキャスト MoH を使用することで、MoH 機能を利用できます。ただし、このような MoH ストリームが生成されると、ネットワークのスループットと帯域幅に対してマイナスの影響を与える可能性があります。

マルチキャスト MoH ストリームは、MoH サーバとマルチキャスト グループ IP アドレス間の、ポイントツーマルチポイント片方向オーディオ RTP ストリームです。MoH オーディオ ストリームを必要とするエンドポイントは、必要に応じてマルチキャスト グループに参加できます。このモードの MoH では、複数のユーザが同じオーディオ ソース ストリームを使用して保留音を提供できるようになるので、システム リソースと帯域幅を節約できます。このため、マルチキャストは、ソース デバイスに対する CPU の影響を大幅に削減し、共通パス上の伝送の帯域幅使用量も大幅に削減するので、MoH などのサービスの配置に非常に魅力的なトランスポート メカニズムです。しかし、ネットワークがマルチキャスト対応になっていない状況や、エンドポイント デバイスがマルチキャストを処理できない状況では、マルチキャスト MoH に問題が生じます。

コール フローの動作に関して、ユニキャストとマルチキャストの MoH には明らかな相違点があります。ユニキャスト MoH コール フローは、Unified CM から MoH サーバへのメッセージによって始まります。このメッセージは、被保留側デバイスの IP アドレスにオーディオ ストリームを送信するように、MoH サーバに指示します。一方、マルチキャスト MoH コール フローは、Unified CM から被保留側デバイスへのメッセージによって始まります。このメッセージは、設定されたマルチキャスト MoH オーディオ ストリームのマルチキャスト グループ アドレスに加わるように、エンドポイント デバイスに指示します。

MoH コール フローの詳細については、「MoH コール フロー」の項を参照してください。

サポートされるユニキャストおよびマルチキャスト ゲートウェイ

次のゲートウェイは、ユニキャスト MoH とマルチキャスト MoH の両方をサポートします。

Cisco IOS 15.0.1M 以降のリリースを搭載した Cisco 2900 シリーズおよび Cisco 3900/3900E シリーズ ISR G2 ルータ

MGCP または H.323 を使用し、Cisco IOS 12.3.14T 以降のリリースを搭載した Cisco 2800 シリーズおよび 3800 シリーズ ルータ

SIP を使用する Cisco 2800 シリーズおよび 3800 シリーズ ルータと、Cisco IOS 12.4(24)T 以降のリリース

MGCP を使用し、Cisco IOS 12.3.14T 以降のリリースを搭載した Cisco VG224 アナログ音声ゲートウェイ

MGCP または SCCP を使用する Cisco VG204 および VG202 Analog Voice Gateway と、Cisco IOS 12.4(22)T 以降のリリース

Cisco VG248 Analog Phone Gateway

Cisco ASR 1000 シリーズ Aggregation Services Router


) Cisco 2800 シリーズ、3800 シリーズ、および VG248 ゲートウェイは、販売終了(EoS)となっています。ユニキャスト MoH およびマルチキャスト MoH をサポートするレガシー ゲートウェイは他にもあります。



) Cisco ASR 1000 シリーズ Aggregation Services Router 上の Cisco Unified Border Element は、Cisco Unified Communications Manager の保留音(MoH)機能による音楽またはアナウンスの一方向のストリーミングをサポートしていない場合があります。詳細については、ご使用のバージョンの Cisco Unified Communications Manager のリリース ノート(http://www.cisco.com/en/US/products/sw/voicesw/ps556/prod_release_notes_list.html で入手可能)を参照してください。


MoH 選択プロセス

この項では、Unified CM に実装するときの MoH 選択プロセスについて説明します。

Cisco Unified Communication 環境における基本的な MoH の動作は、保留側と被保留側から構成されます。 保留側 とは、通話を保留にするエンドポイント ユーザまたはネットワーク アプリケーションです。一方、 被保留側 とは、保留にされたエンドポイント ユーザまたはデバイスです。

エンドポイントが受信する MoH ストリームは、エンドポイントを保留にするデバイス(保留側)のユーザ保留 MoH オーディオ ソースと、保留にされたエンドポイント(被保留側)に設定されたメディア リソース グループ リスト(MRGL)との組み合わせによって決まります。保留側に対して設定されたユーザ保留 MoH オーディオ ソースによって、保留側が通話を保留にしたときに流されるオーディオ ファイルが決まります。被保留側に設定された MRGL は、被保留側が MoH ストリームを受信する元のリソースまたはサーバを指定します。

図 17-3 の例に示すように、電話機 A および B が通話中であるときに、電話機 B(保留側)で電話機 A(被保留側)を保留にする場合、電話機 A には、電話機 B に対して設定された MoH オーディオ ソース(オーディオソース 2)が聞こえます。ただし、電話機 A はこの MoH オーディオ ストリームを、電話機 A に対して設定された MRGL(リソースまたはサーバ)(MRGL A)から受信します。

図 17-3 ユーザ保留オーディオ ソースとメディア リソース グループ リスト(MRGL)

 

設定した MRGL により、ユニキャスト専用デバイスが MoH ストリームを受信するサーバが決まるので、ユニキャスト専用デバイスを設定する場合は、ユニキャスト MoH リソースまたはメディア リソース グループ(MRG)を指定する MRGL を使用する必要があります。同様に、マルチキャスト機能を持つデバイスは、マルチキャスト用に設定された MoH サーバが含まれたマルチキャスト MRG を指定する MRGL を使用して設定する必要があります。

ユーザ保留とネットワーク保留

ユーザ保留には次のタイプがあります。

IP Phone またはその他のエンドポイント デバイスでのユーザ保留

MoH がゲートウェイにストリーミングされる PSTN でのユーザ保留

図 17-4 は、これらの 2 つのタイプのコール フローを示しています。電話機 A が電話機 B と通話中であるときに、電話機 A(保留側)で [Hold] ソフトキーを押すと、MoH サーバから電話機 B(被保留側)に音楽ストリームが送信されます。この音楽ストリームは、IP ネットワーク内の被保留側だけでなく、電話機 A が電話機 C を保留にする場合と同様に、PSTN 上の被保留側にも送信できます。電話機 C の場合、MoH ストリームは音声ゲートウェイ インターフェイスに送信され、PSTN 電話機に適したフォーマットに変換されます。電話機 A が [Resume] ソフトキーを押すと、被保留側(電話機 B または C)は、音楽ストリームから切り離され、電話機 A に再び接続されます。

図 17-4 ユーザ保留の基本的な例

 

ネットワーク保留は、次のようなシナリオで発生する可能性があります。

コール転送

コール パーク

会議セットアップ

アプリケーションベースの保留

図 17-5 に、コール転送中のネットワーク保留の例を示します。コール フローは、次の手順で構成されます。

1. 電話機 A が PSTN 電話機 C からのコールを受信します。

2. 電話機 A がコールに応答し、電話機 B に転送します。転送プロセスの間、電話機 C はネットワーク保留状態になります。

3. 電話機 C は、MoH サーバからゲートウェイ経由で MoH ストリームを受信します。電話機 A が転送アクションを完了したあと、電話機 C は音楽ストリームから切り離され、電話機 B に転送されます。

このプロセスは、コール パークや会議セットアップなどの他のネットワーク保留操作の場合と同じです。

図 17-5 コール転送のネットワーク保留の基本的な例

 

MoH ソース

Unified CM MoH サーバでは、オーディオ ファイルと固定ソースの 2 つのタイプのソースから MoH ストリームを生成でき、これら 2 つのタイプのいずれかをユニキャストまたはマルチキャストとして送信できます。Unified CM クラスタごとに最大で 51 個の MoH オーディオ ソースを設定できます。51 個のうち、最大で 50 個をオーディオ ファイルにできますが、固定ソースにできるのは 1 個のみです。

オーディオ ファイル

オーディオ ファイル(.wav 形式)を Unified CM にアップロードし、指定したコーデックの MoH オーディオ ファイルを自動的に生成することができます。Unified CM では、MoH ストリーム用に G711(a-law および mu-law)、G.729 Annex A、およびワイドバンド コーデックをサポートしています。


) MoH オーディオ ソースを設定する前に、Unified CM Administration インターフェイスのファイルのアップロード機能を使用して、クラスタ内のすべての MoH サーバに .wav 形式のオーディオ ソース ファイルをアップロードする必要があります。最初にオーディオ ソース ファイルをクラスタ内の各 MoH サーバにアップロードし、次にそのオーディオ ファイルをパブリッシャ(MoH サーバでなくてもかまいません)にアップロードし、最後にそのパブリッシャ上の Unified CM Administration インターフェイスで MoH オーディオ ストリーム番号を割り当て、MoH オーディオ ソースを設定することを推奨します。


固定ソース

録音されたオーディオまたはライブ オーディオが必要な場合、ローカル サウンド カードのオーディオ入力に接続されている固定ソースから MoH を生成できます。固定またはライブ オーディオ ソースを MoH サーバに接続するには、Cisco MoH USB オーディオ サウンド カード(MOH-USB-AUDIO=)を使用する必要があります。この USB サウンド カードは、Cisco Unified CM をサポートするすべての Cisco MCS プラットフォームと互換性があります。

このメカニズムにより、ラジオ、CD プレーヤー、または互換性があるその他のサウンド ソースを使用して、MoH をストリーミングできます。固定オーディオ ソースからのストリームは、リアルタイムで変換され、Unified CM Administration によって設定されたコーデックに対応します。固定オーディオ ソースは、G.711(A-law または mu-law)、G.729 Annex A、およびワイドバンドに変換することができる、リアルタイムで変換可能な唯一のオーディオ ソースです。


) 保留音を送信するときに固定オーディオ ソースを使用する場合は、事前に、著作権のあるオーディオ素材の再ブロードキャストについて、その適法性および問題を検討しておく必要があります。起こりうる問題については、貴社の法務部門に相談してください。


MoH の選択

個々のケースにユーザ オーディオ ソース設定値とネットワーク オーディオ ソース設定値のいずれかを適用するか決定するために、Unified CM は、次の優先順位で、 保留側 デバイスに対するこれらの設定値を使用します。

1. ディレクトリまたは回線設定(ゲートウェイなど、回線定義のないデバイスには、このレベルはありません)

2. デバイス設定値

3. 共通のデバイス設定

4. クラスタ全体のデフォルト設定

Unified CM は、 被保留側 デバイスの MRGL 設定値も、次の優先順位で使用します。

1. デバイス設定値

2. デバイス プールの設定値

3. システムのデフォルト MoH リソース

システムのデフォルト MoH リソースは、MRG に割り当てられていないリソースで、常にユニキャストであることに注意してください。

MoH コール フロー

次の各項では、SCCP および SIP エンドポイントの両方について、ユニキャストとマルチキャスト MoH コール フローの詳細な図と説明を示します。

SCCP コール フロー

ここでは、Skinny Client Control Protocol(SCCP)エンドポイントでの、保留音のマルチキャストおよびユニキャストのコール フローについて説明します。

SCCP マルチキャスト コール フロー

図 17-6 は、標準的な SCCP マルチキャスト コール フローを示しています。この図に示されているように、電話機 A で [Hold] ソフトキーが押されると、Unified CM は、Close Receive Channel(受信チャネルのクローズ)と Stop Media Transmission(メディア送信の停止)を電話機 A と電話機 B の両方に指示します。このアクションは、実質的に、RTP 双方向オーディオ ストリームを停止させます。次に、Unified CM は、マルチキャスト グループ アドレス 239.192.240.1 から、Start Multicast Media Reception(マルチキャスト メディア受信の開始)を電話機 B(被保留側)に指示します。その後、電話機 B はインターネット グループ管理プロトコル(IGMP)V2 の Membership Report メッセージを発行して、電話機 B がこのグループに加わることを示します。

図 17-6 SCCP マルチキャスト MoH コール フローの詳細

 

一方、MoH サーバがこのマルチキャスト グループ アドレスに RTP オーディオを送信しているので、電話機 B はそのマルチキャスト グループに加わった後、MoH ストリームの受信を開始します。電話機 A で [Resume] ソフトキーが押されると、Unified CM は、電話機 B に Stop Multicast Media Reception(マルチキャスト メディア受信の停止)を指示します。電話機 B は、マルチキャスト ストリームが必要なくなったことを示すために、IGMP V2 の Leave Group メッセージを 224.0.0.2 に送信します。これにより、実質的に MoH セッションが終了します。次に、Unified CM は、電話機 A と電話機 B 間の通話の開始時に送信するように、両方の電話機に一連の Open Receive Channel(受信チャネルのオープン)メッセージを送信します。その後すぐに、Unified CM は、互いの IP アドレスへの Start Media Transmission(メディア送信の開始)を両方の電話機に指示します。電話機は、RTP 双方向オーディオ ストリームによって再び接続されます。


図 17-6図 17-7 のコール フロー図では、電話機 A と電話機 B の間に双方向 RTP オーディオ ストリームがあるコールを前提としています。これらの図は、コール フローを示しているので、適切な MoH 動作に必要な関連トラフィックのみが記載されています。したがって、インタラクションがわかりやすいように、キープアライブ、確認応答、およびその他のトラフィックは省略されています。各図の初期化イベントは、電話機 A によって実行される [Hold] ソフトキー アクションです。


SCCP ユニキャスト コール フロー

図 17-7 は、SCCP ユニキャスト MoH コール フローを示しています。このコール フロー図では、電話機 A で [Hold] ソフトキーが押されると、Unified CM は、Close Receive Channel(受信チャネルのクローズ)と Stop Media Transmission(メディア送信の停止)を電話機 A と電話機 B の両方に指示します。このアクションは、実質的に、RTP 双方向オーディオ ストリームを停止させます。この時点まで、ユニキャストとマルチキャストの MoH コール フローは、まったく同じように動作します。

図 17-7 SCCP ユニキャスト MoH コール フローの詳細

 

次に、Unified CM は、Open Receive Channel(受信チャネルのオープン)を電話機 B(被保留側)に指示します。これは、マルチキャストの場合とまったく異なっています。マルチキャストでは、Unified CM は、Start Multicast Media Reception(マルチキャスト メディア受信の開始)を被保留側に指示します。次に、Unified CM は、MoH サーバに、電話機 B の IP アドレスへの Start Media Transmission(メディア送信の開始)を指示します。これも、マルチキャスト MoH コール フローとはまったく異なる動作です。マルチキャストの場合、マルチキャスト グループ アドレスに加わるように、電話機に指示します。この時点で、MoH サーバは、片方向ユニキャスト RTP 音楽ストリームを電話機 B に送信します。電話機 A で [Resume] ソフトキーが押されると、Unified CM は、Stop Media Transmission(メディア送信の停止)を MoH サーバに指示し、Close Receive Channel(受信チャネルのクローズ)を電話機 B に指示して、実質的に MoH セッションを終了させます。マルチキャスト シナリオの場合と同じように、Unified CM は、一連の Open Receive Channel(受信チャネルのオープン)メッセージおよび Start Media Transmissions(メディア送信の開始)メッセージを電話機 A と電話機 B に相互の IP アドレスを使用して送信します。電話機は、RTP 双方向オーディオ ストリームによって再び接続されます。

SIP コール フロー

ここでは、Session Initiation Protocol(SIP)エンドポイントでの、保留音のマルチキャストおよびユニキャストのコール フローについて説明します。

SIP マルチキャスト コール フロー

図 17-8 は、標準的な SIP マルチキャスト コール フローを示しています。この図に示されているように、電話機 A で [Hold] ソフトキーが押されると、電話機 A は SIP INVITE を送信します。このときのセッション記述プロトコル(SDP)接続情報は電話機 A の IP アドレスを示し、メディア属性は sendonly を示しています。Unified CM は、SDP 接続情報が 0.0.0.0、メディア属性が recvonly を示す SIP 200 OK Response によって、RTP ストリームを切断するよう電話機 A に指示します。 電話機 B は、Unified CM からの SIP INVITE によって RTP ストリームを切断するように指示されます。このときの SDP 接続情報は 0.0.0.0 を示し、メディア属性は inactive です。電話機 B から Unified CM に、SDP メディア属性が inactive を示す SIP 200 OK Response が返されると、Unified CM は SIP INVITE を電話機 B に送信します。このときの SDP 接続情報は MoH マルチキャスト グループ アドレス(この場合は 239.23.1.1)を示し、メディア属性は recvonly です。

図 17-8 SIP マルチキャスト MoH コール フローの詳細

 

次に、図 17-8 の電話機 B は IGMP V2 の Membership Report メッセージを発行して、電話機 B がこのマルチキャスト グループに加わることを示します。さらに、電話機 B は、前の SIP INVITE に応答して、SDP メディア属性が sendonly を示す SIP 200 OK Response を Unified CM に返します。一方、MoH サーバがこの MoH マルチキャスト グループ アドレスに RTP オーディオを送信しているので、電話機 B はそのマルチキャスト グループに加わった後、一方向 MoH ストリームの受信を開始します。

電話機 A のユーザが [Resume] ソフトキーを押すと、電話機 A は SIP INVITE を送信します。このときの SDP 接続情報は電話機 A の IP アドレスを示し、メディア属性は電話機 A の受信 RTP ポートおよび sendrecv を示しています。Unified CM は、SDP 接続情報が 0.0.0.0、メディア属性が inactive を示す SIP INVITE によって、電話機 B にマルチキャスト MoH ストリームから切断するように指示します。電話機 B から Unified CM に、SDP メディア属性が inactive を示す SIP 200 OK Response が返されます。

次に、Unified CM は電話機 B に SIP INVITE を送信し、電話機 B はそれに対して、SDP 接続情報が電話機 B の IP アドレスを示し、メディア属性が電話機 B の受信 RTP ポートおよび sendrecv を示す SIP 200 OK Response で応答します。Unified CM はそれに応答し、SDP 接続情報が電話機 A の IP アドレスを示し、メディア属性が電話機 A の受信 RTP ポート番号の SIP ACK を電話機 B に送信します。同様に、Unified CM は、SIP 200 OK Response を電話機 A の最初の保留解除 SIP INVITE に転送します。この応答の SDP 接続情報は電話機 B の IP アドレスを示し、メディア属性は電話機 B の受信 RTP ポート番号です。電話機 B は、マルチキャスト ストリームが必要なくなったことを示すために、IGMP V2 の Leave Group メッセージを 224.0.0.2 に送信します。最後に、電話機 A と電話機 B の間に RTP 双方向オーディオ ストリームが再確立されます。


図 17-8図 17-9 のコール フロー図では、電話機 A と電話機 B の間に双方向 RTP オーディオ ストリームがあるコールを前提としています。これらの図は、コール フローを示しているので、適切な MoH 動作に必要な関連トラフィックのみが記載されています。したがって、インタラクションがわかりやすいように、キープアライブ、一部の確認応答、進行状況表示、およびその他のトラフィックは省略されています。各図の初期化イベントは、電話機 A によって実行される [Hold] ソフトキー アクションです。


SIP ユニキャスト コール フロー

図 17-9 は、SIP ユニキャスト MoH コール フローを示しています。この図に示されているように、電話機 A で [Hold] ソフトキーが押されると、電話機 A は SIP INVITE を送信します。このときの SDP 接続情報は電話機 A の IP アドレスを示し、メディア属性は sendonly を示しています。Unified CM は、SDP 接続情報が 0.0.0.0、メディア属性が recvonly を示す SIP 200 OK Response によって、RTP ストリームを切断するよう電話機 A に指示します。電話機 B は、Unified CM からの SIP INVITE によって RTP ストリームを切断するように指示されます。このときの SDP 接続情報は 0.0.0.0 を示し、メディア属性は inactive です。次に、電話機 B から Unified CM に、SDP メディア属性が inactive を示す SIP 200 OK Response が返されます。この時点まで、ユニキャストとマルチキャストの MoH コール フローはまったく同じです。

図 17-9 SIP ユニキャスト MoH コール フローの詳細

 

Unified CM は電話機 B に SIP INVITE を送信し、電話機 B は、それに対して、SDP 接続情報が電話機 B の IP アドレスを示し、メディア属性が電話機 B の受信 RTP ポート番号および sendrecv を示す SIP 200 OK Response で応答します。Unified CM は、SCCP の StartMediaTransmission メッセージを MoH サーバに送信して、電話機 B のアドレスおよび受信 RTP ポート番号を伝えます。この後、Unified CM から電話機 B への SIP ACK が続き、このときの SDP 接続情報には Unified CM の IP アドレス、メディア属性には sendonly が示されます。一方、MoH サーバが RTP オーディオを送信しているので、電話機 B は一方向 MoH ストリームの受信を開始します。

電話機 A のユーザが [Resume] ソフトキーを押すと、電話機 A は SIP INVITE を送信します。このときの SDP 接続情報は電話機 A の IP アドレスを示し、メディア属性は電話機 A の受信 RTP ポートおよび sendrecv を示しています。Unified CM は、SDP 接続情報が 0.0.0.0、メディア属性が inactive を示す SIP INVITE によって、電話機 B にマルチキャスト MoH ストリームから切断するように指示します。電話機 B から Unified CM に、SDP メディア属性が inactive を示す SIP 200 OK Response が返されます。その後、Unified CM は、SCCP の StopMediaTransmission メッセージを MoH サーバに送信します。これによって、MoH サーバは電話機 B への MoH ストリームの転送を停止します。

次に、Unified CM は電話機 B に SIP INVITE を送信し、電話機 B はそれに対して、SDP 接続情報が電話機 B の IP アドレスを示し、メディア属性が電話機 B の受信 RTP ポートおよび sendrecv を示す SIP 200 OK Response で応答します。Unified CM はそれに応答し、SDP 接続情報が電話機 A の IP アドレスを示し、メディア属性が電話機 A の受信 RTP ポート番号の SIP ACK を電話機 B に送信します。同様に、Unified CM は、SIP 200 OK Response を電話機 A の最初の保留解除 SIP INVITE に転送します。この応答の SDP 接続情報は電話機 B の IP アドレスを示し、メディア属性は電話機 B の受信 RTP ポートです。最後に、電話機 A と電話機 B の間に RTP 双方向オーディオ ストリームが再確立されます。

メディア リソースのキャパシティ プランニング

この項では、DSP を含む各種ネットワーク モジュールおよびシャーシのキャパシティ、ネットワーク モジュールを含むシャーシのキャパシティ、およびハードウェアに対するソフトウェアの依存性に関する情報を提供します。

すべての Cisco ISR G1 および G2 のキャパシティ プランニングには、 http://www.cisco.com/go/dspcalculator で入手できる DSP Calculator を使用します。他のプラットフォーム(Cisco 1700、2600、および 3700 シリーズ ルータなど)については、 http://www.cisco.com/cgi-bin/Support/DSP/cisco_dsp_calc.pl からレガシーの DSP Calculator を使用します。

ユニファイド コミュニケーション ソリューションの DSP リソースは、NM-HD、NM-HDV、および PVDM モジュールによって提供されます。NM-HD および NM-HDV2 モジュールは、Cisco ISR G1 および G2 シリーズのプラットフォームでサポートされています。これらのモジュールのキャパシティ情報については、それぞれの製品データ シートを参照してください。

PVDM モジュールは、PVDM-256K、PVDM2、および最新の PVDM3 の 3 つのモデルで使用できます。それぞれのモデルに、異なる密度をサポートする複数のモジュールがあります。たとえば、PVDM-256K-4 および PVDM2-16 は、それぞれのカテゴリ内の単一の DSP モジュールです。PVDM2 モジュールは、Cisco ISR G1 および ISR G2 プラットフォームでサポートされています(Cisco ISR G2 シリーズには、Cisco IOS Release 15.0(1)M 以降が必要です)。PVDM3 DSP モジュールは、Cisco 2900 シリーズおよび 3900 シリーズ プラットフォームでサポートされており、Cisco IOS Release 15.0(1) M 以降が必要です。PVDM3 モジュールでは、音声とビデオの両方の DSP リソースが提供されます。PVDM3 モジュールは、PVDM2 モジュールと PVDM-256K モジュールよりも新しく、これらの 3 つのタイプは互いに交換できません。

ハードウェアベースのメディア リソースに対してキャパシティ プランニングを行う場合に考慮する点として、モジュールの密度、基盤となるプラットフォーム(Cisco ISR G1 または G2)、および必要な Cisco IOS の最小バージョンがあります。

PVDM2 モジュールのキャパシティ情報については、次の Web サイトで入手可能な『 High-Density Packet Voice Digital Signal Processor Module for Cisco Unified Communications Solutions 』データ シートを参照してください。

http://www.cisco.com/en/US/prod/collateral/routers/ps5854/product_data_sheet0900aecd8016e845_ps3115_Products_Data_Sheet.html

PVDM3 モジュールのキャパシティ情報については、次の Web サイトで入手可能な『 High-Density Packet Voice Video Digital Signal Processor Module for Cisco Unified Communications Solutions 』データ シートを参照してください。

http://www.cisco.com/en/US/prod/collateral/modules/ps3115/data_sheet_c78-553971.html

Cisco 2900 および 3900 シリーズ プラットフォームの考慮事項

次のガイドラインおよび考慮事項は、これらのプラットフォームでホストされる DSP リソースに適用されます。

Cisco 2900 および 3900 シリーズ ルータでは、オンボード(マザーボード)の DSP スロットに挿入された PVDM3 DSP だけがサポートされます。PVDM2 DSP は、アダプタ カードを使用することで、これらのスロットで使用できます。NM-HD および NM-HDV2 カードは、アダプタ カードを使用することで、サービス モジュール スロットで使用できます。

PVDM2 モジュールと PVDM3 モジュールは、同じマザーボード上で同時に使用することはできません。

DSP は、同じ DSP タイプ間でだけ共有できます。たとえば、マザーボードに PVDM3 DSP が挿入されており、サービス モジュールに PVDM2 DSP が挿入されている場合、サービス モジュールの複数の DSP は相互に共有できますが、マザーボード上の DSP は、サービス モジュールの DSP とは共有できません。

PVDM3 DSP では、Cisco FAX リレーを除き、PVDM2 DSP がサポートしているすべての機能がサポートされます。

PVDM2 とは異なり、PVDM3 DSP は、すべてのメディア機能の単一ソフトウェア イメージを提供します。

Cisco 2800 および 3800 シリーズ プラットフォーム

次のガイドラインおよび考慮事項は、これらのプラットフォームでホストされる DSP リソースに適用されます。

Cisco 2800 および 3800 シリーズ ルータはすべて 2 つの AIM スロットを備えていますが、これらは AIM-VOICE-30 または AIM-ATM-VOICE-30 カードをサポートしていません。これは、マザーボードに搭載されている PVDM2 モジュールがこの機能を提供していないためです。

製品データ シートの指示に従って、Cisco IOS プラットフォームに NM-HDV2、NM-HD- xx 、および NM-HDV モジュールを搭載できます。

3 つのモジュール ファミリすべてを単一のシャーシに搭載できます。ただし、会議機能とトランスコーディング機能は、NM-HDV ファミリと、残りのファミリのどちらか(NM-HD- xx または NM-HDV2)との両方で同時に使用することはできません。また、NM-HDV(TI-549)、NM-HD- xx 、および NM-HDV2(TI-5510)を、1 つのシャーシ内で同時に会議およびトランスコーディングに使用することはできません。

同じシャーシ内で NM-HDV モジュールと NM-HDV-FARM モジュールを組み合わせることができますが、これらのモジュールですべてのシャーシの装備を完了できるわけではありません。

保留音のキャパシティ プランニング

MoH リソースのキャパシティ プランニングを行う場合は、MoH リソースのハードウェア キャパシティを認識し、このキャパシティとの関連からマルチキャストとユニキャストの MoH の役割を考慮することが重要です。MoH サーバのキャパシティは、配置モデル(共存またはスタンドアロン)、基盤となるサーバ プラットフォームなどの複数の要因に依存します。

共存 MoH サーバとスタンドアロン MoH

MoH 機能を利用するには、Unified CM クラスタに含まれているサーバを使用する必要があります。MoH サーバは、次のいずれかの方法で設定できます。

共存配置

共存 」という用語は、同じサーバ上で複数のサービスまたはアプリケーションが実行されている状態を指します。共存配置では、MoH 機能は Unified CM ソフトウェアも実行している、クラスタ内の任意のサーバ(パブリッシャまたはサブスクライバ)で実行されます。

スタンドアロン配置

スタンドアロン配置では、MoH 機能は Unified CM クラスタ内の専用のメディア リソース サーバ ノードに置かれます。このサーバは、パブリッシャとしてもサブスクライバとしても機能しません。つまり、Cisco IP Voice Media Streaming Application サービスが、そのサーバ上で使用できる唯一のサービスとなります。この専用サーバの機能は、MoH ストリームをネットワーク内のデバイスに送信することだけです。

サーバ プラットフォームの最大同時セッション数

Cisco Unified Communications Manager Release 9.0 以降では、最大 1,000 MoH ストリームは、スタンドアロンと共存展開の MCS 7835 および MCS 7845 サーバまたは同等 OVA プラットフォームでサポートされます。他のプラットフォームでは、Unified CM は、その他のサービスがサーバでアクティブであるかによって、その量の半分以下をサポートできます。MoH セッションがこの最大同時セッション数を超えてから、さらに負荷が増えると、MoH 品質の低下、不規則な MoH 動作、または MoH 機能の喪失までも発生するおそれがあるので、ネットワークのコール量が最大同時セッション数を超えないようにしてください。Unified CM クラスタごとに最大 51 の固有オーディオ ソースを設定できることに注意してください。

サポートされているサーバのプラットフォームの詳細については、次の Web サイトで入手可能な『 Supported Servers for Releases of Cisco Unified Communications Manager (Including Business Edition 3000/5000/6000 and Session Manager Edition) and Cisco Intercompany Media Engine 』を参照してください。

http://www.cisco.com/en/US/prod/collateral/voicesw/ps6790/ps5748/ps378/prod_brochure0900aecd8062a4f9.html

次の 2 つの MoH サーバ設定パラメータは、MoH サーバのキャパシティに影響を与えます。

Maximum Half Duplex Streams

このパラメータにより、ユニキャスト MoH に配置できるデバイスの数が決まります。デフォルトでは、この値は 250 に設定されています。

Maximum Half Duplex Streams パラメータは、次の公式から得られた値に設定する必要があります。

(サーバおよび配置キャパシティ)-([マルチキャスト MoH ソースの数] × [有効な MoH コーデックの数])

次に、例を示します。

MCS-7835 スタンドアロン MoH サーバ(または同等 OVA)

マルチキャスト MoH オーディオ ソース

有効な MoH コーデック(G.711 mu-law と G.729)

Maximum Half Duplex Streams

1,000

- (12

∗ 2)

= 976

したがって、この例では、Maximum Half Duplex Streams パラメータは 976 以下の値で設定されます。

Maximum Multicast Connections

このパラメータにより、マルチキャスト MoH に配置できるデバイスの数が決まります。

Maximum Multicast Connections パラメータは、必要に応じてすべてのデバイスを確実にマルチキャスト MoH に配置できるような数に設定する必要があります。MoH サーバが生成できるマルチキャスト ストリームは有限ですが、多数の保留デバイスを各マルチキャスト ストリームに加えることができます。このパラメータは、同時にマルチキャスト MoH に配置される可能性のあるデバイスの数、またはそれよりも大きい数に設定する必要があります。一般的なマルチキャスト トラフィックは、生成されるストリームの数に基づいて決まりますが、Unified CM では、マルチキャスト MoH に実際に配置されたデバイスの数または各マルチキャスト MoH ストリームに接続されたデバイスの数が保持されます。この方式は、マルチキャスト トラフィックが通常トラッキングされる方法と異なりますが、このパラメータを適切に設定することが重要です。


) Unified CM クラスタごとに設定できる固有オーディオ ソースの上限は 51 で、MoH ストリームに使用可能なコーデックの上限は 4 つであるため、MoH サーバごとのマルチキャスト ストリームの最大数は 204 です。


これらのパラメータを適切に設定しないと、MoH サーバ リソースが十分に使用されない、またはサーバがネットワーク負荷を処理できないといった問題が発生する可能性があります。サービス パラメータの設定方法については、次の Web サイトで入手可能な『 Cisco Unified Communications Manager Administration Guide 』を参照してください。

http://www.cisco.com/en/US/products/sw/voicesw/ps556/prod_maintenance_guides_list.html


) MOH サーバごとに 1,000 セッションの最大限度数は、ユニキャスト、マルチキャスト、またはユニキャストとマルチキャストの同時セッションに適用されます。制限は、トランスポート メカニズムに関係なく、プラットフォームがサポートできるセッションの推奨最大数を表します。


リソースのプロビジョニング

共存またはスタンドアロンの MoH サーバ設定のプロビジョニングを行う場合、ネットワーク管理者は、MoH オーディオ ストリームに使用されるトランスポート メカニズムのタイプを考慮する必要があります。ユニキャスト MoH を使用する場合、保留される各デバイスには、別々の MoH ストリームが必要です。しかし、マルチキャスト MoH と単一のオーディオ ソースのみを使用する場合、保留にするタイプのデバイス数に関係なく、設定されているコーデック タイプごとに必要な MoH ストリームは 1 つだけです。

たとえば、30,000 台の電話機のあるクラスタがあり、保留率が 2% である(すべてのエンドポイント デバイスの 2% だけが、常に保留になる)場合、600 の MoH ストリームまたはセッションが必要です。ユニキャスト専用 MoH 環境では、MCS 7845(または OVA 同等)で動作する 1 つの共存(またはスタンドアロン)MOH サーバがこの負荷を処理するために必要です。

比較すると、36 の固有 MoH オーディオ ストリームがあるマルチキャスト専用 MoH 環境は、たとえば、1 つの共存 MoH サーバ(MCS 7816、7825、または 7878)が必要です。36 の固有マルチキャスト ストリームは、次のいずれかの方法でプロビジョニングできます。

単一のコーデックを使用して 36 の固有オーディオ ソースをストリーミングする。

2 つのコーデックだけを使用して 18 の固有オーディオ ソースをストリーミングする。

3 つのコーデックだけを使用して 12 の固有オーディオ ソースをストリーミングする。

4 つのコーデックすべてを使用して 9 つの固有オーディオ ソースをストリーミングする。

上記の例では、2% の保留率は、30,000 台の電話機に基づくものであり、保留になる可能性があるネットワーク内のゲートウェイまたはその他のエンドポイント デバイスを考慮していません。こうしたその他のデバイスは、電話機と同じように保留になる可能性があるので、保留率を計算するときは、これらのデバイスも考慮する必要があります。

上記の計算では、MoH サーバの冗長性を見込んでいません。MoH サーバに障害が発生する場合、またはユーザの 2% 以上が同時に保留になる場合、このシナリオでは、オーバーフローが発生したり負荷が増えたときに処理するための MoH リソースがありません。MoH リソースの計算には、冗長性に配慮して十分に余裕のあるキャパシティを含める必要があります。追加の MoH サーバは、「メディア リソースのハイ アベイラビリティ」で説明されているように、冗長性またはハイ アベイラビリティ用にプロビジョニングできます。

メディア リソースのハイ アベイラビリティ

Unified CM のメディア リソース グループ(MRG)とメディア リソース グループ リスト(MRGL)のコンストラクトは、この章で説明されているリソースの編成とアクセスの方法を制御するために使用されます。この項では、これらのコンストラクトを効率的に利用する方法について説明します。

メディア リソース グループとメディア リソース グループ リスト

メディア リソース グループ(MRG)とメディア リソース グループ リスト(MRGL)は、リソースの割り当て方法を制御する方式を提供するもので、リソースに対するアクセス権、リソースの場所、特定のアプリケーションのリソース タイプが含まれます。この項では、読者がメディア リソース グループおよびメディア リソース グループ リストを理解しているものとして、次の設計上の考慮事項について詳しく説明します。

ユーザ インターフェイスに表示されないデフォルトのメディア リソース グループがシステムによって定義されます。すべてのリソースが、作成時にこのデフォルトの MRG のメンバーになります。MRG を使用してリソースへのアクセスを制御する場合は、リソースを明示的に別の MRG に設定することによって、デフォルト MRG の外に移動する必要があります。すべてのコールに対する最後の手段としてのみリソースを使用できるようにする場合は、そのリソースをデフォルト グループに残しておくことができます。また、リソースの制御が必要ない場合も、デフォルト グループに残しておくことができます。

メディア リソースの使用側は、まず、設定で指定されている任意のメディア リソース グループ(MRG)またはメディア リソース グループ リスト(MRGL)のリソースを使用します。必要なリソースが使用できない場合、デフォルト MRG でリソースが検索されます。単純な配置では、デフォルトの MRG だけを使用することがあります。

メディア リソース グループ(MRG)とメディア リソース グループ リスト(MRGL)を使用して、複数の Unified CM 間でリソースを共有します。MRG と MRGL を使用しない場合、リソースは、1 つの Unified CM からしか使用できません。

MRGL は、設定にリストされている順序で MRG を使用します。ある MRG に必要なリソースがない場合、次の MRG が検索されます。すべての MRG が検索され、リソースが見つからない場合、検索は終了します。

Unified CM Administration で MRG 内のデバイスがアルファベット順に表示されていても、MRG 内では、リソースは設定順序に基づいて割り当てられます。メディア リソースを特定の順序で割り当てるには、リソースごとに別の MRG を作成し、MRGL を使用して割り当て順序を指定することを推奨します。

MRG 内に同じタイプのリソースを提供するデバイスが複数存在する場合、そのリソースを割り当てるアルゴリズムによって、これらすべてのデバイス間でロード バランシングが行われます。Cisco Unified CM は、MTP をロード バランシングと MTP またはトランスコーダ リソースのパーセンテージとして、設定された数を定義する [MTP and Transcoder Resource Throttling Percentage] サービス パラメータを使用してトランスコーダ リソースにスロットリング メカニズムを使用します。アクティブな MTP またはトランスコーダ リソースの数がこのパラメータに設定されている割合以上である場合、Cisco Unified CM はコールの両端で一致するコーデックを使用するリソースを検出するために、1 回このリソースおよびハントに MRGL(デフォルトを含む MRG)によってコールの送信を停止します。Cisco Unified CM が一致するコーデックの使用可能なリソースを検出できない場合、調整された状態にコールの機能の小さいサブセットと一致し、これらのリソースを含む検索を繰り返す場合は、MRGL の最上位に戻されます。Cisco Unified CM は、コールに最適な一致であるリソースにこのようなリソースが使用可能なときにコールをリソースに発信します。コールは、Cisco Unified CM がコールのリソースを割り当てることができない場合に失敗します。

Unified CM サーバベースのソフトウェア MTP はデフォルトでパススルーがイネーブルです。Cisco IOS Enhanced MTP デバイスは、コーデック パススルー モードまたは非コーデック パススルー モードをサポートするように設定できます。コーデック パススルー MTP が必要とされているが、MRGL(デフォルト MLG を含む)内にコーデック パススルー MTP が検出されない場合には、コーデック パススルー機能を無視して MRGL を再度検索します。

MRG には、複数のタイプのリソースが含まれていることがあります。必要な機能に基づいて、適切なリソースがグループから割り当てられます。MTP とトランスコーダは、特別な例です。トランスコーダは MTP としても使用できます。たとえば、MTP とトランスコーダの両方が同じ MRG に存在していて MTP が要求されている場合、リソースが MRG に出現する順序に基づいて割り当てが行われます。トランスコーダ デバイスが MRG 内で MTP よりも前に出現している場合、トランスコーダ リソースが使い果たされるまでトランスコーダ リソースが MTP 要求に割り当てられ、その後、MTP の割り当てが開始されます。このため、MRG および MRGL を作成するときにリソースの順序を考慮することが重要です。

MRG を使用して、同様のタイプのリソースをグループ化することもできます。上記の例で説明したように、トランスコーダがより高価なリソースであるため、シスコでは、トランスコーダおよび MTP を別の MRG にグループ化し、適切な順序で MRGL に MRG を追加して、正しいリソースを呼び出すことを推奨します。もう 1 つの例には会議ブリッジが関係しています。会議ブリッジ リソースがサポートする参加者の数はそれぞれに異なります。別々の MRG を使用して、会議ブリッジのサイズ別に会議リソースをグループ化できます。

また、MRG と MRGL を使用すると、地理的なロケーションに基づいてリソースを分離できます。その結果、WAN 帯域幅を節約できる場合もあります。

メディア リソース自身には、別のメディア リソースを呼び出さない設定が必要です。たとえば、MTP がコールに挿入され、この MTP で設定されているコーデックが、このコールに対して Unified CM が必要とするコーデックと異なる場合、トランスコーダも呼び出されます。よくある間違いは、Unified CM が G.729a を必要とする場合に、MTP を G.729 または G.729b に設定することです。

Cisco IOS ベースのメディア リソースの冗長性とフェールオーバーに関する考慮事項

メディア リソースに関するハイ アベイラビリティ設計には、冗長なメディア リソースを含める必要があります。これらのリソースが Cisco IOS ベースのリソースである場合は、単一プラットフォームの障害を防ぐために各リソースを複数の Cisco IOS プラットフォームに分散できます。また、各リソースを異なるプライマリ Unified CM サーバに登録することも可能です。

Cisco IOS は、フェールオーバー機能のモードとして「グレースフル」と「即時」の 2 種類をサポートしています。デフォルトのフェールオーバー方法はグレースフルで、この場合はすべてのメディア アクティビティが停止して初めてリソースがバックアップ Unified CM サーバに登録されます。それに対して即時フェールオーバーでは、プライマリの障害が検出されるとすぐにリソースがバックアップ Unified CM サーバに登録されます。冗長性のない 1 組のメディア リソースしかない状況では、即時フェールオーバーを使用することを推奨します。

保留音のハイ アベイラビリティ

完全な冗長性のある MoH 動作を確保するために複数の MoH サーバを設定し、配置することを推奨します。最初の MoH サーバに障害が発生したり、要求を処理するために必要なリソースがなくなったために使用不能になると、2 番めのサーバが自動的に MoH 機能を引き継ぎ、要求に応答します。適切な冗長構成のために、クラスタ内の 2 つ以上の MoH サーバから各 MRG にリソースを割り当ててください。

マルチキャストとユニキャストの両方の MoH が必要な環境では、ネットワーク内のすべてのエンドポイントの MoH 冗長性が確保されるように、必ず両方のトランスポート タイプに冗長性をもたせてください。

メディア リソースの設計に関する留意点

この項では、さまざまな Unified CM 配置モデルと一緒に使用するメディア リソースの配置に関する留意点について検討します。また、Unified CM 実装でのメディア リソース割り当てに関する堅牢なソリューションの設計に役立つ、設定上の留意点とベスト プラクティスについても取り上げます。

配置モデル

ここでは、MTP リソースとトランスコーディング リソースが、いつどの場所で使用されるかについて説明します。具体的には、次の 3 つの企業 IP テレフォニー配置のモデルで示します。

「単一サイト配置」

「集中型呼処理を使用するマルチサイト配置」

「分散型呼処理を使用するマルチサイト配置」

単一サイト配置

単一サイト配置では、低ビット レート(LBR)コーデックを使用する根拠となっている低速リンクが不要のため、トランスコーディングの必要はありません。H.323v2 に準拠していない相当数のデバイス(旧バージョンの Microsoft NetMeeting や特定のビデオ デバイスなど)が存在する場合、何らかの MTP リソースが必要なことがあります。SIP エンドポイントがある場合は、DTMF 変換用に MTP リソースが必要になることがあります(「Named Telephony Event(RFC 2833)」を参照)。

集中型呼処理を使用するマルチサイト配置

集中型呼処理配置では、Unified CM クラスタとアプリケーション(たとえば、ボイスメールや IVR)は、中央サイトに置かれ、複数のリモート サイトが IP WAN を介して接続されます。リモート サイトでは、呼処理に中央の Unified CM を使用します。

WAN 帯域幅は一般に制限されるので、WAN を通過するときは、G.729 などの低ビット レート コーデックを使用するようにコールが設定されます (図 17-10 を参照)。

IP Phone 間の音声圧縮は、Unified CM の リージョン ロケーション を使用して簡単に設定されます。リージョンは、そのリージョン内のデバイスが使用する圧縮のタイプ(たとえば、G.711 または G.729)を指定します。ロケーションは、そのロケーションのデバイスに出入りするコールに使用可能な、合計帯域幅量を指定します。

図 17-10 集中型呼処理を使用する WAN のトランスコーディング

 

Unified CM は、MRG(メディア リソース グループ)を使用して、クラスタ内の Unified CM サーバ間で、MTP リソースとトランスコーディング リソースの共有を可能にします。さらに、異なるリージョンを通過するコールに LBR コーデック(たとえば、G.729a)を使用する場合、トランスコーディング リソースが使用されるのは、エンドポイントの一方(または両方)が、LBR コーデックを使用できない場合だけです。

図 17-10 では、Unified CM がトランスコーダが必要であることを認識し、高帯域幅コーデックを使用するデバイスの MRGL または MRG に基づいてトランスコーダを割り当てます。この場合、VM/UM サーバが、使用するトランスコーダ デバイスを決定します。この Unified CM の動作は、トランスコーダ リソースが高帯域幅デバイスの近くに正しく配置されていることを前提としています。VM/UM サーバ用のトランスコーダがリモート サイトに配置されるようにこのシステムが設計されていた場合、G.711 は WAN を経由して送信されるため、設計の意図が失われます。結果として、G.711 のみのデバイスを使用する複数のサイトがある場合に WAN で LBR が実行されていると、これらの各サイトがトランスコーダ リソースを必要とします。

その他のリソースの配置も重要です。たとえば、リモート サイトの 3 つの電話機で会議が発生し、会議リソースが中央(呼処理)サイトにある場合、3 つのメディア ストリームが WAN で伝送されます。会議リソースがローカルにあれば、コールは WAN を経由しません。WAN の帯域幅とコール アドミッション制御を設計するときは、この要素を考慮する必要があります。

分散型呼処理を使用するマルチサイト配置

分散型呼処理配置では、IP WAN を介して複数のサイトが接続されます。各サイトには Unified CM クラスタが含まれ、単一サイト モデルか、集中型呼処理モデルになります。サイト間のコール アドミッション制御には、ゲートキーパーを使用できます。

WAN 帯域幅は一般に制限されているので、WAN を通過するときは、LBR コーデック(たとえば、G.729a)を使用するように、サイト間のコールが設定されていることがあります。H.323v2 クラスタ間トランクは、Unified CM クラスタの接続に使用されます。Unified CM は、ハードウェア MTP が使用される場合、MTP サービスを通じた圧縮音声コール接続もサポートします (図 17-11 を参照)。

次の状況では、分散型呼処理配置に、トランスコーディング サービスと MTP サービスが必要になる場合があります。

現行バージョンの Cisco アプリケーションを使用する場合は、トランスコーディング リソースの使用を回避できるため、回避することを推奨します。特別な例として、特定のデバイスの G.711 を回避できないことがあります。

一部のエンドポイント(たとえば、映像エンドポイント)が、H.323v2 機能をサポートしません。

図 17-11 トランスコーディングを使用したクラスタ間コール フロー

 

Unified CM は、MRG(メディア リソース グループ)を使用して、クラスタ内の Unified CM サーバ間で、MTP リソースとトランスコーディング リソースの共有を可能にします。さらに、クラスタ間トランクを介したコールの場合、MTP リソースとトランスコーディング リソースは、必要な場合だけ使用されます。したがって、LBR コーデックをサポートしないアプリケーションに対して MTP サービスを設定する必要がなくなります。

次の特性が、分散型呼処理配置に適用されます。

トランスコーディングを必要とするクラスタ間コールだけが、MTP サービスを使用します。たとえば、コールの両方のエンドポイントが G.729 コーデックを使用できる場合、トランスコーディング リソースは使用されません。

クラスタ内のサーバ間で MTP リソースを共有すると、リソースの使用効率が向上します。

メディアの機能と音声品質

メディアを操作するいずれのプロセスも、メディアの品質を低下させる可能性があります。たとえば、ネットワーク(IP または TDM)上で送信するための音声ストリームのエンコーディングと、相手側でのデコーディングは情報の損失を招き、結果として音声ストリームは元の音声を正確に再生しません。同じ音声ストリームの複数のエンコーディングおよびデコーディングの手順を含む、ネットワーク経由のメディア通過パスが存在する場合、エンコーディングおよびデコーディングの操作が繰り返されるたびに音声品質は低下していきます。通常、このようなパスは回避する必要があります。このことは特に、G.729 などの低帯域幅コーデック(LBC)に当てはまります。

このようなパスが回避できない場合には、G.711 または G.722 コーデックなどの帯域幅が比較的高く、低圧縮のコーデックを使用することによって通常、音声品質を向上させることができます。このようなパスが予想される場合には、これらのコーデックの使用を推奨します。このようなシナリオで、低帯域幅で高圧縮のコーデックを使用することは推奨できません。

保留音の設計に関する留意点

ここでは、堅牢な MoH ソリューションの設計に役立つ、MoH 設定上の考慮事項とベスト プラクティスについて説明します。

コーデックの選択

MoH 配置に複数のコーデックが必要な場合、クラスタ全体の Unified CM サービス パラメータ設定にある IP Voice Media Streaming Application サービス パラメータ [Supported MoH Codecs] で設定します。[Clusterwide Parameters] の下の [Supported MoH Codecs] リストの中から、MoH ストリームに許可する、必要なコーデック タイプをすべて選択します。デフォルトでは、G.711 mu-law のみが選択されています。別のコーデック タイプを選択するには、リストをスクロールさせて該当するコーデックをクリックしてください。複数選択する場合は、CTRL キーを押したまま、マウスを使用して、リストをスクロールさせて複数のコーデックを選択します。MoH イベントに使用される実際のコーデックは、MoH サーバおよび保留にされるデバイス(IP Phone、ゲートウェイなど)のリージョン設定によって決まります。したがって、適切なリージョン設定を MoH サーバに割り当て、必要なリージョンの関係を設定して、MoH インタラクションのコーデック選択を制御します。


) MoH オーディオ ストリームに G.729 コーデックを使用する場合、このコーデックは会話用に最適化されているので、音楽用としては最低限のオーディオ品質であることに注意してください。


マルチキャスト アドレッシング

マルチキャスト MoH を設定するには、適切な IP アドレッシングが重要です。IP マルチキャストのアドレス範囲は 224.0.1.0 ~ 239.255.255.255 です。しかし、IANA(Internet Assigned Numbers Authority)は、公衆マルチキャスト アプリケーション用に 224.0.1.0 ~ 238.255.255.255 の範囲のアドレスを割り当てています。公衆マルチキャスト アドレスを MoH に使用しないことを強く推奨します。代わりに、プライベート ネットワーク上の管理制御アプリケーション用に予約されている、239.1.1.1 ~ 239.255.255.255 の範囲内の IP アドレスを使用するように、マルチキャスト MoH オーディオ ソースを設定することを推奨します。

さらに、次の理由で、ポート番号ではなく、IP アドレスでインクリメントするように、マルチキャスト オーディオ ソースを設定することも必要です。

保留にされた IP Phone は、ポート番号ではなく、マルチキャスト IP アドレスに加わる。

Cisco IP Phone には、マルチキャスト ポート番号という概念はありません。したがって、特定のオーディオ ストリームに対して設定されているすべてのコーデックが、同じマルチキャスト IP アドレス(別々のポート番号であっても)に送信される場合、1 本のストリームしか必要ない場合であっても、すべてのストリームが IP Phone に送信されます。IP Phone は 1 本の MoH ストリームしか受信できないので、不必要なトラフィックでネットワークが飽和状態になる可能性があります。

IP ネットワーク ルータは、ポート番号ではなく、IP アドレスに基づいて、マルチキャストをルーティングする。

ルータには、マルチキャスト ポート番号という概念はありません。したがって、同じマルチキャスト グループ アドレス(別々のポート番号であっても)に送信される複数のストリームを検出すると、ルータは、そのマルチキャスト グループのすべてのストリームを転送します。必要なストリームは 1 本だけなので、ネットワーク帯域幅が過剰に利用され、その結果、ネットワークの輻輳が発生する可能性があります。

MoH オーディオ ソース

オーディオ ソースは、Unified CM クラスタ内の すべての MoH サーバ間で共有されるため、各オーディオ ソース ファイルはクラスタ内の各 MoH サーバにアップロードしておく必要があります。クラスタごとに最大 51 の固有オーディオ ソースを設定できます(50 のオーディオ ファイル ソースと、サウンド カードを介した 1 つの固定/ライブ ソース)。追加のソースを提供する方法については、「複数の固定またはライブ オーディオ ソースの使用」および「支社ルータからのマルチキャスト MoH」の項を参照してください。

マルチキャストストリームに使用する、これらのオーディオ ソースには、[Allow Multicasting] と [Play continuously (repeat)] を必ず有効にしてください。オーディオ ソースの連続再生を指定していない場合、MoH オーディオ ソースは、最初の保留にされた通話者のみが受け取り、追加された通話者は受け取りません。

複数の固定またはライブ オーディオ ソースの使用

Unified CM では、1 つのオーディオ ソースのみ設定できることに留意することが重要です。ただし、Unified CM クラスタ内の各 MoH サーバは、Cisco MoH USB オーディオ サウンド カード(MOH-USB-AUDIO)を使用して、1 つの固定オーディオ ソースをストリーミングできます。複数の固定オーディオ ソースが必要な場合、追加の MoH サーバを追加して、これら複数のソースを提供できます。各 MoH サーバのサウンド カードには、同じ、または別のオーディオを提供できます。管理者は、MRG および MRGL の選択に基づいて、どの MoH サーバを選択するかを決定できます。複数のオーディオ ソースがこの方式で設定された場合、保留側の [User/Network Hold MoH Audio Source] は、固定オーディオ ソース(Unified CM に設定された 1 つの固定オーディオ ソース)に設定する必要があります。次に、被保留側の MRGL がその固定オーディオ ソースをデバイスにストリームする MoH サーバを決定します。

オーディオ ソースが同じ場合、この方式は固定オーディオ ソースの冗長性にも備えています。たとえば、図 17-12 には、2 つの MoH サーバがあり、それぞれは、ラジオ局のライブ フィードからのオーディオをストリームするオーディオ ソースに接続された MOH-USB-AUDIO サウンド カードを備えています。電話機 B の MRGL には、まず MOH1 サーバを含む MRG が、次に MOH2 サーバを含む MRG が含まれます。電話機 A のユーザ/ネットワーク保留オーディオ ソースが固定オーディオ ソースに設定されているときに、コールが電話機 A と電話機 B の間で確立され、電話機 B が電話機 A によって保留にされた場合、電話機 B は、MOH1 サーバからライブ フィード オーディオ ソースを受信します。MOH1 サーバがダウンしている(または利用可能なキャパシティがない)ときに、電話機 A が電話機 B を保留にすると、電話機 B は MOH2 サーバからライブ フィード オーディオ ソースを受信します。

図 17-12 固定オーディオ ソース冗長性の例

 


) マルチキャスト オーディオ ソースとしてラジオのライブ ブロードキャストを使用すると、法律上の問題が発生するおそれがあります。起こりうる問題については、貴社の法務部門に相談してください。


同一 Unified CM クラスタ内のユニキャストとマルチキャスト

管理者は、1 つの Unified CM クラスタでユニキャストとマルチキャスト両方の MoH ストリームを処理するように設定できます。この設定が必要なのは、マルチキャストをサポートしないデバイス、またはエンドポイントがテレフォニー ネットワークに含まれている場合、あるいはネットワークの一部でマルチキャストが使用可能になっていない場合です。

クラスタがユニキャストとマルチキャストの両方の MoH オーディオ ストリームをサポートできるようにするには、次のいずれかの方法を使用してください。

別々の MoH サーバを配置します。一方のサーバをユニキャスト MoH サーバとして設定し、もう一方のサーバをマルチキャスト MoH サーバとして設定します。

2 つのメディア リソース グループ(MRG)を備えた 1 台の MoH サーバを配置します。各グループには同じ MoH サーバが含まれますが、1 つの MRG はオーディオストリームはマルチキャスト用に設定し、もう 1 つはユニキャスト用に設定します。

どちらの場合も、少なくとも 2 つの MRG、および少なくとも 2 つのメディア リソース グループ リスト(MRGL)を設定する必要があります。ユニキャスト MoH を必要とするエンドポイントには、1 つのユニキャスト MRG と 1 つのユニキャスト MRGL を設定します。同様に、マルチキャスト MoH を必要とするエンドポイントには、1 つのマルチキャスト MRG と 1 つのマルチキャスト MRGL を設定します。

別々の MoH サーバを配置する場合、一方のサーバをマルチキャスト無効(ユニキャスト専用)に設定し、もう一方の MoH サーバをマルチキャスト有効に設定してください。ユニキャスト専用 MoH メディア リソースとマルチキャスト使用可能 MoH メディア リソースを、ユニキャスト MRG とマルチキャスト MRG にそれぞれ割り当てます。マルチキャスト MRG には [Use Multicast for MoH Audio] ボックスにチェックマークが付き、ユニキャスト MRG にはチェックマークが付いていないことを確認してください。また、これらのユニキャスト MRG とマルチキャスト MRG をそれぞれの MRGL に割り当てます。この場合、MRG がマルチキャストを使用するように設定されているかどうか、また MoH ストリームを流す元のサーバに基づいて、MoH ストリームのユニキャストまたはマルチキャストが行われます。

単一の MoH サーバをユニキャスト MoH とマルチキャスト MoH の両方に対して配置する場合は、サーバをマルチキャスト用に設定します。同じオーディオ ソースをユニキャスト MRG とマルチキャスト MRG の両方に割り当て、マルチキャスト MRG に対して [Use Multicast for MoH Audio] ボックスにチェックマークを付けます。この場合は、MRG がマルチキャストを使用するように設定されているかどうかだけで、MoH ストリームがユニキャストかマルチキャストかが決まります。


) ユニキャスト MRG を設定する場合は、混乱しないようにしてください。これは、MoH メディア リソースをユニキャスト MRG に追加する場合であっても、リソース名の最後に、[Multicast] が追加されるからです。このラベルは、リソースがマルチキャスト対応であるという単なる表示です。リソースがユニキャストとして送信されるか、マルチキャストとして送信されるかを決定するのは、[Use Multicast for MoH Audio] ボックスのチェックの有無です。


さらに、適切な MRGL を使用するように、個々のデバイスまたはデバイス プールを設定する必要があります。1 つまたは複数のデバイス プールにすべてのユニキャスト デバイスを含め、ユニキャスト MRGL を使用するようにこれらのデバイス プールを設定できます。あるいは、1 つまたは複数のデバイス プールにすべてのマルチキャスト デバイスを含め、マルチキャスト MRGL を使用するようにこれらのデバイス プールを設定することもできます。オプションとして、該当するユニキャスト MRGL またはマルチキャスト MRGL を使用するように、個々のデバイスを設定できます。最後に、個々のデバイス、または(電話デバイスの場合)個々の回線かディレクトリ番号ごとに、ユーザ保留オーディオ ソースおよびネットワーク保留オーディオ ソースを設定して、適切なオーディオ ソースを割り当ます。

マルチキャスト MoH とユニキャスト MoH の両方を同じクラスタに配置する方法を選択する場合は、必要なサーバの数を考慮することが重要です。単一の MoH サーバをユニキャストとマルチキャストの両方に使用すると、クラスタ全体に必要な MoH サーバの数が減ります。マルチキャスト MoH サーバとユニキャスト MoH サーバを別々に配置すると、クラスタ内に必要なサーバの数が明らかに増えます。

Quality of Service(QoS)

時間に依存する重要なリアルタイム アプリケーション(音声など)に遅延または損失がないように、1 つのネットワーク上のデータと音声のコンバージェンスには、適切な QoS が必要です。音声トラフィック用の適切な QoS を確保するには、ストリームがネットワークに入り、通過するときに、ストリームのマーク付け、分類、およびキューイングを行って、音声ストリームを重要度の低いトラフィックよりも優先的に処理する必要があります。MoH サーバは、Diffserv コード ポイント(DSCP)値 46 または PHB(Per Hop Behavior)値 EF(ToS 値 0xB8 に相当)を使用して、オーディオ ストリーム トラフィックに、音声ベアラトラフィックと同じマークを自動的に付けます。したがって、ネットワーク上で QoS が適切に設定されている限り、MoH ストリームは、音声 RTP メディア トラフィックとして分類され、プライオリティ キューイングとして扱われます。

MoH サーバと Unified CM サーバ間のコール シグナリング トラフィックは、デフォルトで DSCP 値 24 または PHB 値 CS3(ToS of 0x60 に相当)を使用して自動的にマーキングされます。したがって、ネットワーク上で、QoS が適切に設定されている限り、他のすべてのコール シグナリングと同様、ネットワーク内で、このコール シグナリング トラフィックは、適切に分類されキューに入れられます。

コール アドミッション制御と MoH

IP テレフォニー トラフィックが WAN リンク上を流れる場合は、コール アドミッション制御(CAC)が必要です。このようなリンク上では使用可能な帯域幅が制限されているので、適切なコール アドミッション制御がないと、音声メディア トラフィックの遅延または損失が起きる可能性が高くなります。詳細については、「コール アドミッション制御」を参照してください。

Unified CM の(静的ロケーションまたは RSVP 対応ロケーションのいずれかに基づく)コール アドミッション制御は、WAN を通過するユニキャスト MoH ストリームをトラッキングできますが、マルチキャスト MoH ストリームはトラッキングできません。したがって、WAN 帯域幅が完全にサブスクライブされた場合であっても、マルチキャスト MoH ストリームは、コール アドミッション制御によって WAN へのアクセスを拒否されません。ストリームは WAN を介して送信され、その結果、オーディオ ストリームの品質が低下し、WAN を通過するその他のすべてのコールの品質も低下する可能性があります。マルチキャスト MoH ストリームがこのオーバーサブスクリプション状態にならないようにするには、帯域幅を追加して低遅延キューイング(LLQ)音声プライオリティ キューを設定することによって、すべてのダウンストリーム WAN インターフェイス上で QoS 設定に余裕を持ってプロビジョニングする必要があります。MoH ストリームは単方向であるため、ダウンストリーム インターフェイス(中央サイトからリモート サイトへ)の音声プライオリティ キューのみを余分にプロビジョニングする必要があります。WAN リンクを通過する可能性があるすべての固有マルチキャスト MoH ストリームに対して、十分な帯域幅を追加してください。たとえば、4 つの固有マルチキャスト オーディオ ストリームが WAN を通過する可能性がある場合、音声プライオリティ キューに 96 Kbps を追加します(4 ∗ 24 Kbps(G.729 オーディオ ストリームごと)= 96 Kbps)。

図 17-13 は、集中型マルチサイト配置におけるコール アドミッション制御と MoH の例を示しています。この例の場合、IP Phone C が PSTN 電話機(電話機 B)とコール中であると想定します。この時点では、WAN 上で帯域幅は消費されていません。電話機 C で [Hold] ソフトキーを押すと(ステップ 1)、電話機 B は、WAN を介して中央サイトの MoH サーバから MoH ストリームを受信するので、リンク上の帯域幅を消費します。コール アドミッション制御でこの帯域幅を考慮すべきかどうかは、MoH ストリームのタイプに応じて決まります。マルチキャスト MoH が流れる場合、コール アドミッション制御は、24 Kbps が消費されているとは見なしません(したがって、ダウンストリーム WAN インターフェイス上の QoS はそれに応じてプロビジョニングされなければなりません)。しかし、ユニキャスト MoH が流れる場合、コール アドミッション制御は、使用可能な WAN 帯域幅から 24 Kbps を差し引きます(ステップ 2)。


) 上記の例では、ユニキャスト MoH を WAN 上で流すことを示唆しているように見えますが、 これは、MoH とのロケーションベースのコール アドミッション制御をわかりやすく示すための例に過ぎません。また、この設定の推奨または保証を意味するものではありません。前述のように、WAN を介した MoH オーディオ ストリームの送信用のトランスポート メカニズムには、マルチキャスト MoH を推奨します。


図 17-13 ロケーションベースのコール アドミッション制御と MoH

 

保留音の配置モデル

各種 Unified Communications 呼処理配置モデルにより、MoH の構成設計にはさらに考慮事項が発生します。配置モデルの選択が、MoH のトランスポート メカニズム(ユニキャストまたはマルチキャスト)、リソースのプロビジョニング、およびコーデックの決定に影響を与える場合があります。ここでは、各種配置モデルに関連した問題について説明します。

配置モデルの詳細については、「Unified Communications の配置モデル」の章を参照してください。

単一サイト キャンパス(すべての配置に関連)

単一サイト キャンパス配置は、通常、LAN インフラストラクチャに基づくものであり、大量のトラフィックに対して十分な帯域幅が用意されています。LAN インフラストラクチャでは一般に帯域幅が制限されないので、単一サイト配置内のすべての MoH オーディオ ストリームには、G.711(A-law または mu-law)コーデックの使用を推奨します。G.711 は、IP テレフォニー環境に、最適な音声と音楽のストリーミング品質を提供します。

MoH サーバの冗長性も考慮する必要があります。MoH サーバが過負荷になるか、使用不能になった場合でも、複数の MoH サーバを設定し、それらのサーバを優先順に MRG に割り当てておくと、別のサーバが制御を引き継いで、MoH ストリームを流すことができます。

ネットワーク テクノロジーの多様性が増すにつれて、大規模な単一サイト キャンパスでは、一部のエンドポイント デバイスまたはネットワーク領域がマルチキャストをサポートできなくなる可能性があります。このため、ユニキャストとマルチキャストの両方の MoH リソースを配置する必要があります。詳細については、「同一 Unified CM クラスタ内のユニキャストとマルチキャスト」の項を参照してください。

オフネット コールとアプリケーション処理コールが、保留時に期待された MoH ストリームを受け取るには、適切な MRGL とオーディオ ソースを使用してすべてのゲートウェイとその他のデバイスを設定するか、それらを適切なデバイス プールに割り当ててください。

集中型マルチサイト配置

集中型呼処理を使用するマルチサイト IP テレフォニー配置には、一般的に、中央以外の複数のサイトとの WAN 接続が含まれます。これらの WAN リンクは、通常、帯域幅とスループットの障害になります。これらのリンク上での帯域幅使用量を最小限にするには、WAN を通過するすべての MoH オーディオ ストリームとして G.729 コーデックを使用することを推奨します。G.729 コーデックは、音楽アプリケーションではなく、音声用に最適化されています。したがって、MoH トランスポートに G.729 がもたらす品質の低下よりも、帯域幅の節約がはるかに重要な問題である WAN 上でのみ、G.729 を使用してください。さらに、マルチキャスト トラフィックにより、帯域幅を大幅に節約できるので、WAN を介してエンドポイントにオーディオを流す場合は、常にマルチキャスト MoH を使用する必要があります。

WAN を介して G.729 を使用するときに MoH ストリームの音声品質が問題になる場合は、WAN を介した MoH オーディオ ストリームに G.711 コーデックを使用し、音声コールには引き続き G.729 を使用します。WAN を介した MoH ストリームの送信に G.711 コーデックを使用し、WAN を介した音声コールの送信に G.729 コーデックを使用するには、Unified CM リージョンにすべての MoH サーバだけを配置し、そのリージョンが他のリージョンとの間で G.711 を使用するように設定します。 この設定により、WAN の一方の側にある 2 つの電話機間でコールを発信するときは、それぞれのリージョンの間で G.729 コーデックが使用されます。ただし、一方の通話者がコールを保留にした場合、MoH オーディオ ストリームは G.711 を使用して符号化されます。これは、G.711 が、MoH サーバのリージョンと、保留にされた電話機のリージョンとの間で使用するコーデックとして設定されているためです。

支社ルータからのマルチキャスト MoH

Cisco Unified Survivable Remote Site Telephony(SRST)機能を使用して配置された支社ルータは、支社の SRST ルータのフラッシュ、またはアナログ ポートに接続されているライブ フィードからの MoH ストリーミングを使用して、リモート サイトや支社サイトでマルチキャスト MoH を提供できます。これらの 2 つの方式によって支社のルータから MoH をマルチキャストすると、Cisco Unified Communications MoH の機能が次のシナリオの両方において向上します。

非フォールバック モード

WAN が稼働中で、電話機が Unified CM で制御されている場合、この設定では、ローカルに発信される MoH を提供し、WAN を介してリモート支社サイトに MoH を転送する必要がなくなります。

フォールバック モード

SRST がアクティブで、支社のデバイスが中央サイトの Unified CM との接続を失った場合、支社のルータが継続して MoH をマルチキャストします。

いずれかのシナリオでライブ フィード オプションを使用している場合、ライブ フィードの入力をモニタすることにより、SRST ルータでは冗長性が確保され、ライブ フィードの接続が切断されても、フラッシュ内のファイルから MoH をストリームするようになります。マルチキャスト MoH を流す際に使用できるマルチキャスト アドレスとポート番号は、SRST ルータごとに 1 つのみです。このため SRST ルータではライブフィードとフラッシュ ファイルの両方からのストリーミングを同時に実行することはできません。また、SRST ルータでは、フラッシュから流すことのできるオーディオ ファイルは 1 つのみです。


) SRST 機能が実際に使用されるかどうかに関係なく、SRST ライセンスが必要です。ライセンスが必要なのは、支社ルータのフラッシュから MoH を流すための設定が SRST コンフィギュレーション モードで行われるため、および SRST 機能が使用されない場合でも少なくとも 1 つの max-ephones と 1 つの max-dn を設定する必要があるためです。


非フォールバック モード

非フォールバック モード中(WAN が稼働していて、SRST がアクティブでない場合)、支社の SRST ルータは、マルチキャスト MoH をすべてのローカル Cisco Unified Communications デバイスに流すことができます。これを実現するには、支社ルータ上で設定された内容と同じマルチキャスト IP アドレスとポート番号をもつオーディオ ソースを使用して、Unified CM MoH サーバを設定する必要があります。このシナリオでは、マルチキャスト MoH オーディオ ストリームが、常に SRST ルータから発信されるので、中央サイトの MoH サーバのオーディオ ソースが WAN を通過する必要はありません。

中央サイトのオーディオ ストリームが WAN を通過しないようにするには、次のいずれかの方法を使用してください。

最大のホップ カウントを設定する

中央サイトの MoH オーディオ ソースが、中央サイトの LAN より先に流れないように、最大ホップ カウントまたは TTL を十分に小さく設定します。

WAN インターフェイス上でアクセス コントロール リスト(ACL)を設定する

中央サイトの WAN インターフェイス上で ACL を設定して、マルチキャスト グループ アドレス宛のパケットがインターフェイスから発信されないようにします。

WAN インターフェイス上でマルチキャスト ルーティングを無効にする

WAN インターフェイス上ではマルチキャスト ルーティングを設定しないでください。設定しなければ、マルチキャスト ストリームが WAN に転送されないことが保証されます。

図 17-14 は、フォールバック モードでないときに支社のルータからマルチキャスト MoH を流す仕組みを示しています。電話機 A で電話機 C を保留にすると、電話機 C は、ローカル SRST ルータからマルチキャスト MoH を受信します。この図では、MoH サーバは、(RTP ポート 16384 上で)239.192.240.1 にマルチキャスト オーディオ ソースを流します。しかし、最大ホップ数が 1 に制限されているので、このストリームは、ローカル MoH サーバのサブネットから WAN を通過して外に出ないことが保証されています。同時に、支社の SRST ルータまたはゲートウェイは、フラッシュまたはライブ フィードからオーディオ ストリームをマルチキャストします。このストリームも、マルチキャスト アドレスとして 239.192.240.1 を使用し、RTP ポート番号として 16384 を使用します。電話機 A で [Hold] ソフトキーを押すと、電話機 C は、SRST ルータから発信された MoH オーディオ ストリームを受信します。

図 17-14 支社ルータからのマルチキャスト MoH

 

この方法を使用してマルチキャスト MoH を配信する場合は、Unified CM クラスタ内のすべてのデバイスが、同じユーザ保留およびネットワーク保留オーディオ ソースを使用するように設定し、すべての支社ルータに同じマルチキャスト グループ アドレスとポート番号を設定します。保留側のユーザまたはネットワーク保留オーディオ ソースは、オーディオ ソースを特定するときに使用されるため、クラスタ内に複数のユーザまたはネットワーク保留オーディオ ソースを設定する場合、リモートの被保留側が常にローカルの MoH ストリームを受信することを保証する手段はありません。たとえば、中央サイトの電話機に設定されているオーディオ ソースが、そのユーザおよびネットワーク保留オーディオ ソースとして、グループ アドレス 239.192.254.1 を使用するものとします。この電話機がリモート デバイスを保留にすると、ローカル ルータのフラッシュの MoH ストリームがマルチキャスト グループ アドレス 239.192.240.1 に送信される場合でも、リモート デバイスは 239.192.254.1 に加わろうとします。代わりに、ネットワーク内のすべてのデバイスがマルチキャスト グループ アドレス 239.192.240.1 でユーザ/ネットワーク保留オーディオ ソースを使用するように設定し、すべての支社ルータが 239.192.240.1 でフラッシュからマルチキャストするように設定すると、リモート デバイスはすべて、そのローカル ルータから MoH を受信します。

マルチキャスト MoH を流すように設定された複数の支社ルータを含むネットワークでは、Unified CM クラスタ内に 51 を超える固有 MoH オーディオ ソースを含めることができます。支社サイトの各ルータは、固有オーディオ ソースをマルチキャストできます。ただし、すべてのルータが同じマルチキャスト グループ アドレス上でこのオーディオをマルチキャストする必要があります。また、中央サイトの MoH サーバは、この同じマルチキャスト グループ アドレス上で MoH ストリームをマルチキャストできます。したがって、100 の支社サイトそれぞれがオーディオをマルチキャストする場合、クラスタには実際には 101 の固有 MoH オーディオ ソース(100 の支社ストリームと 1 つの中央サイト ストリーム)が含まれることになります。中央サイトで 51 を超える固有オーディオ ストリームが必要な場合は、「複数の固定またはライブ オーディオ ソースの使用」で説明されている方法を参照してください。

フォールバック モード

フォールバック モード中(WAN がダウンしていて SRST がアクティブな場合)、支社の SRST ルータはシャーシ内のすべてのアナログ ポートとデジタル ポートに、マルチキャスト MoH を流すことができます。これによりアナログ電話機および PSTN 電話機に MoH を流すことができます。

支社のルータに対して、フォールバック モードのマルチキャスト MoH を設定する方法は、通常の設定方法と同じです。ただし、ルータに対して設定するマルチキャスト アドレスは、目的の動作によって異なります。支社のルータから、デバイスにマルチキャスト MoH をフォールバック モードでのみ流す必要がある場合(たとえば、リモート デバイスで受信する MoH が非フォールバック モード中に中央サイトの MoH サーバから発信される場合)、SRST ルータに設定したマルチキャスト アドレスとポート番号が、中央サイトの MoH サーバのいずれのオーディオ ソースと重複しないようにする必要があります。重複していると、リモート デバイスは、設定されているユーザ/ネットワーク保留オーディオ ソースに応じて、ローカル ルータのフラッシュから MoH を継続的に受信することがあります。

支社の SRST/ゲートウェイ ルータに、マルチキャスト MoH を設定すると、ルータはフォールバック モードでないときにも、MoH ストリームのマルチキャストを継続することに注意してください。

フォールバック モードを設定して、Cisco Unified Communications Manager Express(Unified CME)を SRST モードで使用することもできます。フォールバック モードの動作は同じですが、コンフィギュレーション コマンドが多少異なります。SRST コマンドは、Cisco IOS call-manager-fallback コンストラクトで入力しますが、SRST モードの Unified CME では、コマンドは t elephony-service で入力します。

SRST を介して MoH をマルチキャストする方法は 4 つあります。

支社ルータのフラッシュからの SRST マルチキャスト MoH

ライブ フィードからの SRST マルチキャスト MoH

SRST モードの Unified CME での支社ルータ フラッシュからのマルチキャスト MoH

SRST モードの Unified CME でのライブ フィードからのマルチキャスト MoH

Cisco Unified SRST と Unified CME の設定方法については、次のマニュアルを参照してください。

次のサイトで入手可能な『 Cisco Unified SRST System Administrator Guide

http://www.cisco.com/en/US/products/sw/voicesw/ps2169/products_installation_and_configuration_guides_list.html

次の Web サイトで入手可能な『 Cisco Unified Communications Manager Express System Administrator Guide

http://www.cisco.com/en/US/products/sw/voicesw/ps4625/products_installation_and_configuration_guides_list.html

分散型マルチサイト配置

分散型呼処理を使用するマルチサイト IP テレフォニー配置には、通常、サイト間の WAN または MAN 接続が含まれます。これらの低速リンクは、通常、帯域幅とスループットの障害になります。リンク上での帯域幅使用量を最小限にするには、リンクを通過するすべての MoH オーディオ ストリームとして G.729 コーデックを使用することを推奨します。ただし G.729 コーデックは、音楽用ではなく、音声用に最適化されているので、MoH トランスポートに G.729 がもたらす品質の低下よりも、帯域幅の節約がはるかに重要な問題である WAN/MAN 上でのみ、G.729 を使用してください。

集中型マルチサイト配置の場合とは異なり、WAN を介して流れる MoH オーディオ ストリーム用に G.711 が必要になる可能性がある状況では、分散型マルチサイト環境で MoH オーディオ ストリームが G.711 を使用するように強制することはできません。MoH サーバが別の Unified CM リージョンに配置されている状況で、このリージョンとクラスタ間トランクまたは SIP トランクのリージョンとの間で G.711 コーデックが設定されている場合でも、2 つのクラスタ間のコールが一方の電話機によって保留にされたときは、元の音声コールのコーデックが保持されます。これらのクラスタ間コールは、一般に、帯域幅の節約のために G.729 を使用して符号化されるため、一方のクラスタからの MoH ストリームも G.729 を使用して符号化されます。

もう 1 つのオプションでは、マルチキャスト MoH をクラスタ間トランク(ICT)または SIP トランク経由でクラスタ間コールにプロビジョニングします。これにより、1 つの Unified CM クラスタ内のエンドポイントで別の Unified CM クラスタからストリーミングされたマルチキャスト MoH を聞くことができるようになるとともに、クラスタ間帯域幅をより効率的に使用できるようになります。この機能を活かすには、適切に設計された IP マルチキャスト環境が必要です。IP マルチキャストの詳細については、次の Web サイトで入手可能なマニュアルを参照してください。

http://www.cisco.com/en/US/products/ps6552/products_ios_technology_home.html

分散型クラスタ間環境では、適切なマルチキャスト アドレス管理も、設計上の重要な考慮事項です。分散型ネットワーク全体で流れるリソースの重複を防止するために、いかなる MoH オーディオ ソース マルチキャスト アドレスも、配置内のすべての Unified CM クラスタに対して一意でなければなりません。

WAN を介したクラスタリング

その名前が示すように、WAN を介したクラスタリングの展開には、他のマルチサイト配置と同様、低速 WAN リンクを含みます。したがって、これらの配置にも、G.729 コーデック、マルチキャスト トランスポート メカニズム、および低速 WAN リンクを介した MoH トラフィックに対して欠かせない安定した QoS の、3 つの要件が必要です。

さらに、このタイプの設定では、WAN の各端部に MoH サーバ リソースを配置することも必要です。WAN に障害が発生した場合には、WAN の各端部のデバイスは、ローカルに配置された MoH サーバから、引き続き MoH オーディオ ストリームを受信できます。さらに、適切な MoH 冗長設定がきわめて重要です。WAN の各端部のデバイスには、MRGL を指定する必要があります。この MRGL の MRG には、少なくとも 1 つのローカル リソースが最優先になった MoH リソースの優先順位リストが必要です。プライマリ サーバが使用不能になるか、要求を処理できない場合に備えて、この MRG に対して、MoH リソースを追加設定しておく必要があります。WAN のローカル側のリソースは使用不能になった場合に備えて、リスト内で他に少なくとも 1 つの MoH リソースは、リモート側の MoH リソースを指定しておく必要があります。