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

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

Cisco Unified CallManager は、次の 2 つのタイプの MoH トランスポート メカニズムをサポートします。

• ユニキャスト

• マルチキャスト

ユニキャスト MoH は、MoH サーバから MoH オーディオ ストリームを要求するエンドポイントに直接送信されるストリームで構成されます。ユニキャスト MoH ストリームは、サーバとエンドポイント デバイス間のポイントツーポイント片方向オーディオ Real-Time Transport Protocol（RTP）ストリームです。ユニキャスト MoH は、ユーザまたは接続ごとに別々のソース ストリームを使用します。ユーザまたはネットワーク イベントを介して保留になるエンドポイント デバイスが増えるにつれて、MoH ストリームの本数も増加します。したがって、20 台のデバイスが保留になっている場合、サーバとこれらのエンドポイント デバイス間のネットワーク上で、RTP トラフィックとしてストリームが 20 本生成されます。このような MoH ストリームが生成されると、ネットワークのスループットと帯域幅に対してマイナスの影響を与える可能性があります。しかし、ユニキャスト MoH が非常に役立つのは、マルチキャストが使用可能になっていないネットワークの場合や、デバイスがマルチキャスト対応になっていないネットワークの場合です。このようなときに、管理者はユニキャスト MoH を使用することで、MoH 機能を利用できます。

マルチキャスト MoH は、MoH サーバからマルチキャスト グループ IP アドレスに送信されるストリームで構成されます。MoH オーディオ ストリームを要求するエンドポイントは、必要に応じてこの IP アドレスに加わることができます。マルチキャスト MoH ストリームは、MoH サーバとマルチキャスト グループ IP アドレス間の、ポイントツーマルチポイント片方向オーディオ RTP ストリームです。マルチキャスト Music on Hold では、複数のユーザが同じオーディオ ソース ストリームを使用して Music on Hold を提供できるようにするので、システム リソースと帯域幅を節約できます。したがって、20 台のデバイスが保留中であっても、ネットワーク上で 1 つの RTP トラフィックのストリームだけしか生成されない場合もあります。したがって、マルチキャストは、ソース デバイスに対する CPU の影響を大幅に削減し、共通パス上の伝送の帯域幅使用量も大幅に削減するので、MoH などのサービスの配置に非常に魅力的なテクノロジーです。しかし、ネットワークがマルチキャスト対応になっていない状況や、エンドポイント デバイスがマルチキャストを処理できない状況では、マルチキャスト MoH に問題が生じます。

IP マルチキャスト ネットワークの設計については、次の Web サイトで入手可能なオンラインの『IP Multicast SRND』資料を参照してください。

http://www.cisco.com/go/srnd

推奨されるユニキャスト/マルチキャスト ゲートウェイ

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

• Cisco 6624 および 6608 ゲートウェイ モジュールと、MGCP および Cisco Unified CallManager Release 3.3(3) 以降の組み合せ

• Cisco Communication Media Module（CMM; コミュニケーション メディア モジュール）と、MGCP または H.323、および Cisco Unified CallManager Release 4.0、Cisco IOS Release 12.2(13)ZP3 以降、または Catalyst OS Release 8.1(1) 以降の組み合せ

• Cisco 2600、2800、3600、3700、および 3800 シリーズ ルータと、MGCP または H.323、および Cisco IOS Release 12.2(8)T 以降の組み合せ

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

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

• 共存配置

共存配置では、MoH 機能は Cisco Unified CallManager ソフトウェアも実行している、クラスタ内の任意のサーバ（パブリッシャまたはサブスクライバ）で実行されます。このタイプの設定では、MoH と Cisco Unified CallManager はサーバ リソースを共有するので、MoH サーバが送信できる同時ストリーム数が大幅に減少します。

• スタンドアロン配置

スタンドアロン配置では、MoH 機能は Cisco Unified CallManager クラスタ内の専用サーバに置かれます。この専用サーバの機能は、MoH ストリームをネットワーク内のデバイスに送信することだけです。スタンドアロン配置では、1 台の MoH サーバから最大数のストリームを送信できます。

MoH の固定ソースとオーディオ ファイル ソース

MoH のソースは、次のいずれかの方法で設定できます。

• Cisco Unified CallManager または MoH サーバ上のオーディオ ファイルを使用した MoH

–オーディオ ファイルを使用したユニキャスト MoH

–オーディオ ファイルを使用したマルチキャスト MoH

• 固定音楽ソースを使用した MoH（サウンド カード経由）

–固定ソースを使用したユニキャスト MoH

–固定ソースを使用したマルチキャスト MoH

MoH は、MoH サーバ上に格納されているオーディオ ファイルから生成できます。オーディオ ファイルは、次の形式のいずれかでなければなりません。

• G.711 A-law または mu-law

• G.729 Annex A

• ワイドバンド

MoH オーディオ ファイルは、MoH Audio File Management ページ（または Music On Hold Audio Source Configuration ページ）でファイル アップロード機能を使用して、.wav フォーマットのオーディオ ファイルを MoH サーバにアップロードすると、Cisco Unified CallManager によって自動的に生成されます。次に、Cisco Unified CallManager は、オーディオ ソース ファイルを指定されたコーデック タイプに適した MoH ソース ファイルに変換し、フォーマットします。MoH イベントが発生すると、MoH サーバは、設定されたオーディオ ソース ファイルを保留中の要求側デバイスにストリーミングします。

（注） MoH オーディオ ソースの設定前に、.wav フォーマットのオーディオ ソース ファイルをクラスタ内の各 MoH サーバにアップロードしておく必要があります。オーディオ ソース ファイルをアップロードするには、管理者がクラスタ内の各 MoH サーバ上で Cisco Unified CallManager Administration インターフェイスに移動し、MoH Audio File Management ページでファイルのアップロード機能を使用する必要があります。この手順は、オーディオ ソース ファイルごとに実行する必要があります。オーディオ ソースを MoH オーディオ ストリーム番号に割り当て、MoH オーディオ ソースとして設定するには、事前にクラスタ内のすべての MoH サーバにオーディオ ソース ファイルをアップロードしておく必要があります。

録音済みまたはライブ オーディオが必要である場合、固定ソースから MoH を生成できます。このタイプの MoH の場合、サウンド カードが必要です。固定オーディオ ソースは、ローカル サウンド カードのオーディオ入力に接続されます。

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

固定またはライブ オーディオ ソースを MoH サーバに接続するには、Cisco MoH USB オーディオ サウンド カード（MOH-USB-AUDIO=）を使用する必要があります。この USB サウンド カードは、Cisco Unified CallManager Release 5.0 をサポートするすべての MCS プラットフォームと互換性があります。

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

Cisco Unified CallManager クラスタに含まれる MoH サーバ

MoH 機能を利用するには、各 MoH サーバが Cisco Unified CallManager クラスタに含まれている必要があります。すべての MoH サーバは、パブリッシャ サーバと設定を共有し、データベース複製スキーマに加わる必要があります。具体的には、MoH サーバはデータベースによって次の情報を共有する必要があります（これらの情報は Cisco Unified CallManager Administration で設定されます）。

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

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

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

MoH サーバは、Cisco Unified CallManager クラスタの一部になり、自動的にデータベースの複製に加わります。スタンドアロン MoH サーバを設定するには、最初に、そのサーバに Cisco Unified CallManager を通常どおりにインストールします。次に、Cisco CallManager サービスを無効にし（スタンドアロン MoH サーバ上でのみ）、Cisco IP Voice Media Streaming Application を有効にします。

基本的な MoH

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

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

簡単に言えば、保留側の設定により、再生されるオーディオ ファイルが決まり、被保留側の設定により、そのファイルを再生するリソースまたはサーバが決まります。図7-1 の例に示すように、電話機 A および B が通話中であるときに、電話機 B（保留側）で電話機 A（被保留側）を保留にする場合、電話機 A には、電話機 B に対して設定された MoH オーディオ ソース（Audio-source2）が聞こえます。ただし、電話機 A はこの MoH オーディオ ストリームを、電話機 A に対して設定された MRGL（リソースまたはサーバ）（MRGL A）から受信します。

図7-1 ユーザ保留オーディオ ソースとメディア リソース グループ リスト（MRGL）

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

MoH 構成の設定値

MRGL、およびユーザ保留オーディオ ソースとネットワーク保留オーディオ ソースの設定値は、Cisco Unified CallManager Administration 内の複数の個所で指定できます。それぞれの個所で別々の（おそらく、競合する）設定値を設定できます。

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

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

2. デバイス設定値

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

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

特定の保留側のオーディオ ソースを決定しようとする場合、Cisco Unified CallManager はまず、ディレクトリまたは回線レベルで設定されたユーザ（またはネットワーク）オーディオ ソースを調べます。このレベルが定義されていない場合、Cisco Unified CallManager は、保留側デバイスで設定されたユーザ（またはネットワーク）オーディオ ソースを調べます。このレベルが定義されていない場合、Cisco Unified CallManager は、保留側デバイスのデバイス プールに対して設定されたユーザ（またはネットワーク）オーディオ ソースを調べます。このレベルが定義されていない場合、Cisco Unified CallManager は、Cisco Unified CallManager システム パラメータで設定された、クラスタ全体のデフォルト オーディオ ソース ID を調べます（デフォルトでは、このオーディオ ソース ID は、ユーザ保留オーディオ ソースとネットワーク保留オーディオ ソースの両方に対して 1 に設定されています。これは、SampleAudioSource です）。

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

1. デバイス設定値

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

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

特定の被保留側の MRGL を決定しようとする場合、Cisco Unified CallManager は、デバイス レベルで設定された MRGL を調べます。このレベルが定義されていない場合、Cisco Unified CallManager は、被保留側デバイスのデバイス プールに対して設定された MRGL を調べます。このレベルが定義されていない場合、Cisco Unified CallManager は、システムのデフォルト MoH リソースを使用します。システムのデフォルト MoH リソースとは、MRG に割り当てられていないリソースであり、これらのリソースは常にユニキャストです。

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

ユーザ保留には、次の 2 つの基本的なタイプがあります。

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

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

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

図7-2 ユーザ保留の基本的な例

ネットワーク保留には次のタイプがあります。

• コール転送

• コール パーク

• 会議セットアップ

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

図7-3 は、コール転送のコール フローを示しています。電話機 A が公衆網電話機 C からコールを受信する（ステップ 1）と、電話機 A はそのコールに応答し、電話機 B に転送します（ステップ 2）。転送プロセス時に、電話機 C は、ゲートウェイを介して MoH サーバから MoH ストリームを受信します（ステップ 3）。電話機 A が転送アクションを完了した後、電話機 C は音楽ストリームから切り離され、電話機 B（転送の宛先）に転送されます。このプロセスは、コール パークや会議セットアップなどの他のネットワーク保留操作の場合と同じです。

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

ユニキャストとマルチキャスト MoH コール フロー

MoH 操作は、通常の電話のコール フローに非常によく似ています。MoH サーバは、被保留側デバイスが必要に応じて接続または切断されるエンドポイント デバイスの役目をします。しかし、ユニキャストとマルチキャストの MoH コール フローの動作には、明らかな相違点があります。ユニキャスト MoH コール フローは、Cisco Unified CallManager から MoH サーバへのメッセージによって初期化されます。このメッセージは、被保留側デバイスの IP アドレスにオーディオ ストリームを送信するように、MoH サーバに指示します。一方、マルチキャスト MoH コール フローは、Cisco Unified CallManager から被保留側デバイスへのメッセージによって初期化されます。このメッセージは、設定されたマルチキャスト MoH オーディオ ストリームのマルチキャスト グループ アドレスに加わるように、エンドポイント デバイスに指示します。

MoH コール フローの詳細については、「ユニキャストとマルチキャスト MoH コール フローの詳細」の項を参照してください。

コーデックの選択

MoH 配置に複数のコーデックが必要な場合、Cisco CallManager Service Parameters Configuration の IP Voice Streaming Media App サービス パラメータでコーデックを設定します。Clusterwide Parameters セクションの下の Supported MoH Codecs リストの中から、必要なコーデック タイプを選択してください。デフォルトでは、G.711 mu-law のみが選択されています。別のコーデック タイプを選択するには、リストをスクロールさせて該当するコーデックをクリックしてください。複数選択する場合は、CTRL キーを押したまま、マウスを使用して、リストをスクロールさせて複数のコーデックを選択します。選択終了後、Update ボタンをクリックしてください。

（注） 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 オーディオ ソース

オーディオ ソースは、Cisco Unified CallManager クラスタ内の すべての MoH サーバ間で共有されます。クラスタごとに最大 51 の固有オーディオ ソースを設定できます（50 のオーディオ ファイル ソースと、サウンド カードを介した 1 つの固定/ライブ ソース）。この制限の例外については、「複数の固定またはライブ オーディオ ソースの使用」および 「支店ルータのフラッシュからのマルチキャスト MoH」の項を参照してください。

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

各 MoH サーバは、1 つの固定オーディオ ソースしか流すことができません。大部分の場合、複数の固定またはライブ オーディオ ソースが必要な場合は、ソースごとに別々の MoH サーバが必要です。しかし、固定またはライブ ソースからマルチキャストを流すことができる外部の非 MoH サーバまたはデバイスを使用すると、複数の固定ソース MoH オーディオ ストリームを提供することが可能です。

外部ソースごとに、外部ソース サーバまたはデバイスによってマルチキャストされるオーディオ ソース ストリームと同じマルチキャスト IP アドレス、およびポート番号を持つオーディオ ソースを使用して、MoH サーバを設定する必要があります。さらに、最大ホップ カウントを 1 に設定するか、アクセス コントロール リスト（ACL）を使用して、パケットがローカル サブネットの外に流れないようにすることによって、この設定された（非外部）オーディオ ソースが WAN を通過しないようにすることも必要です。

図7-4 は、MoH ストリームとして使用される外部ライブ ソースの例を示しています。この図では、MoH サーバは、239.1.1.1（RTP ポート 16384 上で）にマルチキャスト オーディオ ソースを流します。このストリームは、最大ホップ カウント 1 に制限されているので、ローカル MoH サーバのサブネットから外に出ないことが保証されます。同時に、メディア サーバは、ラジオ局のライブ フィードから取得したオーディオ ストリームをマルチキャストします。このストリームも、マルチキャスト アドレスとして 239.1.1.1 を使用し、RTP ポート番号として 16384 を使用します。ただし、電話機 A で Hold ソフトキーを押したときに、このストリームが電話機 B に到達できるようにするために、このストリームのホップ カウントまたは Time to Live（TTL; 存続可能時間）は 2 以上必要です。

（注） マルチキャストの TTL の値が減少する（または満了する）のは、パケットがレイヤ 3 インターフェイスを通過するときのみです。

図7-4 外部のライブ オーディオ ソースの例

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

多数のストリームを、1 つまたは複数の外部メディア サーバからマルチキャストできます。これを行うには、追加のオーディオ ソースを複数の MoH サーバに設定し、MoH サーバに設定された同一のマルチキャスト グループ アドレスを使用して外部サーバからオーディオ ストリームを発信します。ただし、エンドポイント デバイスで聞こえる MoH ストリームは、保留側のユーザ/ネットワーク保留オーディオ ソースと被保留側の MRGL との組み合せによって決まるため、重複しているマルチキャスト グループ アドレスが多数存在する環境では、具体的にどのストリームをエンドポイントが受信するかを予測することは困難になる場合があります。このため、設定するマルチキャスト オーディオ ソースは MoH サーバごとに 1 つのみとすることをお勧めします。この推奨事項により、エンドポイントが受信するオーディオ ソースが、ユーザ/ネットワーク保留オーディオ ソースと MRGL の単一の組み合せによって一意に識別できることが保証されます。

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

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

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

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

• 同一 MoH サーバに対して別々のメディア リソース グループ（MRG）を設定します。オーディオ ストリームに対して、一方の MRG ではマルチキャストを使用するように設定し、もう一方の MRG ではユニキャストを使用するように設定します。

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

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

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

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

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

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

冗長性

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

MRG 内のリソースは、リストされている順に使用されます。デバイスが MoH オーディオ リソースを要求すると、Cisco Unified CallManager は、MRG 内の最初の MoH リソースをそのデバイスに送信しようとします。最初のリソースがサーバ障害またはリソースの不足により使用不能である場合、Cisco Unified CallManager は、MRG 内の次の MoH リソースを使用しようとします。

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

QoS

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

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

表7-1 は、サーバ プラットフォームと、そのプラットフォームがサポートできる最大同時 MoH セッション数をリストしています。MoH セッションがこの最大同時セッション数を超えてから、さらに負荷が増えると、MoH 品質の低下、不規則な MoH 動作、または MoH 機能の喪失までも発生する恐れがあるので、ネットワークのコール量が最大同時セッション数を超えないようにしてください。

MoH Server 設定ページの Maximum Half Duplex Streams フィールドと Maximum Multicast Connections フィールドを、 表7-1 に示されているキャパシティと一致するように設定する必要があります。これらのフィールドは、デフォルトで 250 と 30 にそれぞれ設定されていますが、表に示されているサーバ プラットフォームのタイプとサーバ配置のタイプ（共存またはスタンドアロン）に応じて設定変更する必要があります。推奨されるキャパシティの数値に一致させないと、サーバ リソースが十分に使用されない、またはサーバがネットワーク負荷を処理できないといった問題が発生する可能性があります。

（注） 表7-1 にリストされている最大セッションの上限は、ユニキャスト、マルチキャスト、またはユニキャストとマルチキャストの同時セッションに適用されます。この上限は、トランスポート メカニズムに関係なく、プラットフォームがサポートできる推奨最大セッション数を示しています。

リソースのプロビジョニングとキャパシティ プランニング

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

たとえば、30,000 台の電話機のあるクラスタがあり、保留率が 2% である（すべてのエンドポイント デバイスの 2% だけが、常に保留になる）場合、600 の MoH ストリームまたはセッションが必要です。ユニキャスト専用の MoH 環境の場合、次の計算で示されているように、この負荷を処理するには、2 つの共存（またはスタンドアロン）MoH サーバが必要です。

［（MCS 7815 または 7845 共存サーバごとに 500 セッション）∗（共存サーバ 1 台）］+［（MCS 7835 または 7845 共存サーバごとに 250 セッション）∗（共存サーバ 1 台）］> 600 セッション

一方、たとえば、36 の固有 MoH オーディオ ストリームがあるマルチキャスト専用 MoH 環境には、次の計算で示されているように、1 つの共存 MoH サーバ（MCS 7815 または 7825）だけが必要です。

（MCS 7815 または 7825 共存サーバごとに 250 セッション）∗（共存サーバ 1 台）> 36 セッション

36 の固有マルチキャスト ストリームは、次のいずれかの方法でプロビジョニングできます。

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

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

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

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

上記の例で示されているように、マルチキャスト MoH は、ユニキャスト MoH よりも、サーバ リソースを大幅に節約できます。

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

上記の計算では、MoH サーバの冗長性を見込んでいません。MoH サーバに障害が発生する場合、またはユーザの 2% 以上が同時に保留になる場合、このシナリオでは、オーバーフローが発生したり負荷が増えたときに処理するための MoH リソースがありません。MoH リソースの計算には、冗長性に配慮して十分に余裕のあるキャパシティを含める必要があります。

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

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

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

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

ネットワーク テクノロジーの多様性が増すにつれて、大規模な単一サイト キャンパスでは、一部のエンドポイント デバイスがマルチキャストをサポートできなくなる可能性があります。このため、ユニキャストとマルチキャストの両方の MoH リソースを配置する必要があります。たとえば、無線 IP Phone は、無線テクノロジーの動作により、マルチキャストをサポートしません。したがって、無線 IP Phone を配置する場合は、マルチキャストとユニキャストの両方の MoH を設定する必要があります。

オフネット コールとアプリケーション処理コールが、保留時に期待された 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 コーデックを使用するには、Cisco Unified CallManager リージョンにすべての MoH サーバだけを配置し、そのリージョンが他のリージョンとの間で G.711 を使用するように設定します。この設定により、WAN の一方の側にある 2 つの電話機間でコールを発信するときは、それぞれのリージョンの間で G.729 コーデックが使用されます。ただし、一方の通話者がコールを保留にした場合、MoH オーディオ ストリームは G.711 を使用して符号化されます。これは、G.711 が、MoH サーバのリージョンと、保留にされた電話機のリージョンとの間で使用するコーデックとして設定されているためです。

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

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

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

図7-5 は、集中型マルチサイト配置におけるコール アドミッション制御と MoH の例を示しています。この例の場合、IP Phone C が公衆網電話機（電話機 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 をお勧めします。

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

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

Cisco IOS Release 12.2(15)ZJ および SRST Release 3.0 から、MoH は支店のルータのフラッシュを介して、リモートまたは支店のサイト内でマルチキャストできるようになりました。Cisco IOS ルータのフラッシュからのマルチキャスト MoH は、次の理由で MoH 機能を向上させます。

• 支店のゲートウェイまたはルータが SRST モードのときに、支店のデバイスが中央サイトの Cisco Unified CallManager との接続を失った場合、支店のゲートウェイまたはルータが MoH をマルチキャストします。

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

例7-1 は、ルータのフラッシュからのマルチキャスト MoH を可能にするために、Cisco IOS ルータ設定（SRST セクションの下）で使用するコマンドを示しています。

例7-1 支店ルータのフラッシュからのマルチキャスト MoH を有効にする

例7-1 では、ルータのフラッシュ上のオーディオ ファイルの名前は music-on-hold.au です。設定されたマルチキャスト アドレスとポート番号は、それぞれ 239.192.240.1 と 16384 です。オプションの route コマンドは、マルチキャスト ストリーム用のソース インターフェイス アドレスを指定します。route オプションを指定しない場合、マルチキャスト ストリームは、設定されている SRST のデフォルト アドレスから発信されます。このアドレスは、SRST 設定モードで ip source-address コマンドによって指定されたものです。フラッシュから流すことのできるオーディオ ファイルは 1 つのみで、ルータごとに使用可能なマルチキャスト アドレスとポート番号は 1 つのみです。

支店ルータが SRST モードで動作している場合、シャーシ内のすべてのアナログ ポートとデジタル ポートに、マルチキャスト MoH を流すことができます。これによりアナログ電話機および公衆網電話機に MoH を流すことができます。このとき、SRST モードの IP Phone は、SRST ルータのフラッシュからマルチキャスト MoH を受信できないので、代わりに保留音を受け取ります。

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

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

支店ルータのフラッシュからのマルチキャスト MoH が常に必要になる場合は、支店ルータ上で設定された内容と同じマルチキャスト IP アドレスとポート番号をもつオーディオ ソースを使用して、中央サイトのサーバを設定する必要があります。このシナリオでは、マルチキャスト MoH オーディオ ストリームが、常にルータのフラッシュから発信されるので、中央サイトの MoH サーバのオーディオ ソースが WAN を通過する必要はありません。

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

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

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

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

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

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

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

図7-6 は、SRST モードでないときにリモート ルータのフラッシュからマルチキャスト 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 オーディオ ストリームを受信します。

図7-6 支店ルータのフラッシュからのマルチキャスト MoH

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

フラッシュからマルチキャスト MoH を流すように設定された複数の支店ルータを含むネットワークでは、クラスタ内に 51 を超える固有 MoH オーディオ ソースを含めることができます。支店サイトの各ルータは、フラッシュから固有オーディオ ソースをマルチキャストできます。ただし、すべてのルータが同じマルチキャスト グループ アドレス上でこのオーディオをマルチキャストする必要があります。また、中央サイトの MoH サーバは、この同じマルチキャスト グループ アドレス上で MoH ストリームをマルチキャストできます。したがって、100 の支店サイトそれぞれがフラッシュからオーディオ ファイルをマルチキャストする場合、クラスタには 101 の固有 MoH オーディオ ソース（100 の支店ストリームと 1 つの中央サイト ストリーム）を含めることができます。中央サイトで複数の固有オーディオ ストリームが必要な場合は、追加の MoH サーバまたは外部メディア サーバから固定/ライブ ソースを流すことができます（「複数の固定またはライブ オーディオ ソースの使用」を参照）。ただし、サーバごとに複数のオーディオ ソースを設定しないでください。

分散型マルチサイト配置

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

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

さらに、Cisco Unified CallManager クラスタ間のコール（クラスタ間コール）では、マルチキャスト MoH はサポートされません。したがって、クラスタ間トランクまたは SIP トランク上で MoH が必要な場合は、各 Cisco Unified CallManager クラスタで少なくとも 1 つのユニキャスト MoH リソースを設定する必要があります。

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

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 リソースを指定しておく必要があります。

SCCP コール フロー

ここでは、Skinny Client Control Protocol（SCCP）エンドポイントでの Music On Hold のコール フローについて説明します。

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

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

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

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

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

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

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

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

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

SIP コール フロー

ここでは、Session Initiation Protocol（SIP）エンドポイントでの Music On Hold のコール フローについて説明します。

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

図7-9 は、標準的な SIP マルチキャスト コール フローを示しています。この図に示されているように、電話機 A で Hold ソフトキーが押されると、電話機 A は SIP INVITE を送信します。このときの Session Description Protocol（SDP）接続情報は電話機 A の IP アドレスを示し、メディア属性は sendonly を示しています。Cisco Unified CallManager は、SDP 接続情報が 0.0.0.0、メディア属性が recvonly を示す SIP 200 OK Response を介して、RTP ストリームを切断するように電話機 A に指示します。電話機 B は、Cisco Unified CallManager からの SIP INVITE を介して RTP ストリームを切断するように指示されます。このときの SDP 接続情報は 0.0.0.0 を示し、メディア属性は inactive です。電話機 B から Cisco Unified CallManager に、SDP メディア属性が inactive を示す SIP 200 OK Response が返されると、Cisco Unified CallManager は SIP INVITE を電話機 B に送信します。このときの SDP 接続情報は MoH マルチキャスト グループ アドレス（この場合は 239.23.1.1）を示し、メディア属性は sendonly です。

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

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

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

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

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

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

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

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

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

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

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

SIP メディア保留コール フロー

図7-11 は、RFC 2543 のメディア保留コール フローを示しています。このコール フローが発生するのは、コールを保留にする電話機（この場合は電話機 A）が Cisco Unified IP Phone 7905、7912、またはサードパーティ製の SIP 電話機の場合だけです。この図に示されているように、電話機 A で Hold ソフトキーが押されると、電話機 A は SIP INVITE を送信します。このときの SDP 接続情報は 0.0.0.0 を示し、メディア属性は sendonly を示しています。電話機 B は、Cisco Unified CallManager からの SIP INVITE を介して RTP ストリームを切断するように指示されます。このときの SDP 接続情報は 0.0.0.0 を示し、メディア属性は inactive です。次に、電話機 B から Cisco Unified CallManager に SIP 200 OK Response が返されます。この応答の SDP 接続情報は電話機 B の IP アドレスを示し、メディア属性は電話機 B の受信 RTP ポート番号および inactive を示します。そして、Cisco Unified CallManager は、電話機 A の最初の保留 SIP INVITE に応答して、SIP 200 OK Response を電話機 A に返します。この応答の SDP 接続情報は電話機 B の IP アドレスを示し、メディア属性は電話機 B の受信 RTP ポートおよび inactive を示します。

この時点で、電話機 B は保留状態ですが MoH を受信していないため、電話機 B のユーザには何も聞こえません。

図7-11 SIP メディア保留コール フローの詳細

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

（注） メディア保留が以上のように発生するのは、Cisco Unified IP Phone 7905 または 7912 およびサードパーティ製の SIP 電話機がコールを保留にする場合だけです。また、これらの電話機は、他の Cisco Unified IP Phone モデルによって保留にされたときに MoH を受信し、そのシナリオのコール フローは、図7-9 および図7-10 に示したフローとほぼ同じようになります。