Cisco IP テレフォニー ソリューション リファレンス ネットワーク デザイン ガイド Cisco CallManager Release 3.3

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

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

• ユニキャスト

• マルチキャスト

ユニキャスト MoH は、MoH サーバから MoH オーディオ ストリームを要求するエンドポイントに直接送信されるストリームで構成されます。ユニキャスト MoH ストリームは、サーバとエンドポイント デバイス間のポイントツーポイント片方向オーディオ RTP（Real-Time Transport Protocol）ストリームです。ユニキャスト 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 サイトで入手可能なオンラインの『Cisco AVVID Network Infrastructure IP Multicast Design』資料を参照してください。

http://cisco.com/go/srnd

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

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

• 共存配置

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

• スタンドアロン配置

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

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

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

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

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

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

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

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

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

MoH は、クラスタを形成している TFTP（Trivial File Transfer Protocol）サーバ上に保存されているオーディオ ファイルから生成され、MoH サーバが必要とするときに呼び出されます。オーディオ ファイルは、次の形式のいずれかでなければなりません。

• G.711 A-law または mu-law（サンプリング レート 8 KHz で録音）

• G.729 Annex A

• ワイドバンド

これらのファイルは、Cisco MoH オーディオ トランスレータ サービスを使用して作成できます。このサービスは、オーディオ ソース ファイル（たとえば、.wav または .mp3 ファイル）を、指定されたコーデック タイプに適した MoH ソース ファイルに変換し、フォーマットします。MoH サーバは、設定されたオーディオ ソースに基づいてこれらのファイルを要求し、初期化時またはオーディオ ソースの要求時に、それらのファイルをメモリにロードします。MoH イベントが発生すると、設定されたオーディオ ソース ファイルは、保留中の要求側デバイスにストリーミングされます。

録音済みまたはライブ オーディオが必要である場合、固定ソースから MoH を生成できます。このタイプの MoH の場合、サウンド カードが必要です。固定オーディオ ソースは、通常、搭載しているサウンド カードにリンクしている Microsoft Windows オーディオ入力によって再生されます。

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

固定またはライブ オーディオ ソースに対して、次のサウンド カードがサポートされています。

• Soundblaster PCI 16

• Telex P-800 USB

Windows 2000（OS 2000 バージョン 2.5）の Cisco CallManager リリース 3.3(3) でサポートされる USB サウンド デバイス。このデバイスをサポートするプラットフォームは
MCS-7825H-2.2-EVV1、MCS-7835H-2.4-EVV1、MCS-7835I-2.4-EVV1 MCS-7845H-2.4-EVV1、および MCS-7835-1266 です。

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

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

MoH 機能を利用するには、各 MoH サーバが Cisco CallManager クラスタに含まれている必要があります。すべての MoH サーバは、パブリッシャ サーバと設定を共有し、SQL レプリケーション スキーマに加わる必要があります。具体的には、MoH サーバは、SQL データベースを使用して、Cisco CallManager Administration を使用して設定された次の情報を共有する必要があります。

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

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

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

MoH サーバは、Cisco CallManager クラスタの一部になり、自動的に SQL データベースのレプリケーションに加わります。スタンドアロン MoH サーバを設定するには、そのサーバ上で通常の Cisco CallManager インストール作業から始めてください。次に、Cisco CallManager サービスを使用不可にし（設定中のスタンドアロン MoH サーバ上でのみ）、Cisco IP 音声メディア ストリーミング アプリケーションを使用可能にします。

基本的な MoH

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

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

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

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

MoH 構成の設定値

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

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

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

2. デバイス設定値

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

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

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

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

1. デバイス設定値

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

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

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

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

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

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

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

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

図 5-1 ユーザ保留の基本的な例

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

• コール転送

• コール パーク

• 会議セットアップ

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

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

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

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

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

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

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

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

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

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

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

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

図 5-3 外部のライブ オーディオ ソースの例

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

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

状況に応じて、管理者は、1 つの Cisco 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 サーバをマルチキャスト有効に設定してください。さらに、ユニキャスト専用サーバで 1 つ以上の非マルチキャスト MoH オーディオ ソースを設定し、マルチキャスト サーバで 1 つ以上のマルチキャスト MoH オーディオ ソースを設定します。ユニキャスト専用 MoH サーバのユニキャスト オーディオ リソースをユニキャスト MRG に、マルチキャスト MoH サーバのマルチキャスト オーディオ リソースをマルチキャスト MRG に、それぞれ割り当てます。マルチキャスト MRG には Use Multicast for MoH Audio ボックスにチェックマークが付き、ユニキャスト MRG にはチェックマークが付いていないことを確認してください。また、これらのユニキャスト MRG とマルチキャスト MRG をそれぞれの MRGL に割り当てます。この場合、MoH ストリームを流す元のオーディオ ソースとサーバ、および MRG がマルチキャストを使用するように設定されているかどうかに基づいて、MoH ストリームのユニキャストまたはマルチキャストが行われます。

同一 MoH サーバに別々の MRG を設定する場合、サーバとオーディオ ソースはマルチキャスト用に設定してください。同じオーディオ ソースをユニキャスト 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 サーバに障害が発生したり、要求を処理するために必要なリソースがなくなったために使用不能になると、2 番目のサーバが自動的に MoH 機能を引き継ぎ、要求に応答します。適切な冗長構成のために、クラスタ内の 2 つ以上の MoH サーバから各 MRG にリソースを割り当ててください。

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

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

QoS（Quality of Servece）

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

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

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

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

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

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

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

［（MCS 7835 または 7845 スタンドアロン サーバごとに 250 セッション）∗（スタンドアロン サーバ 2 台）］+［（共存サーバごとに 20 セッション）∗（共存サーバ 5 台）］= 600 セッション

一方、たとえば、100 の固有 MoH オーディオ ストリームがあるマルチキャスト専用 MoH 環境には、次のように、5 つの共存 MoH サーバだけが必要です。

（共存サーバごとに 20 セッション）∗（共存サーバ 5 台）= 100 セッション

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

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

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

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

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

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

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

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

集中型マルチサイト配置

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

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

IP テレフォニー トラフィックが WAN リンク上を流れる場合は、コール アドミッション制御（CAC）が必要です。このようなリンク上では使用可能な帯域幅が制限されているので、音声メディア トラフィックの遅延または損失が起きる可能性が高くなります。Cisco CallManager ロケーション ベースのコール アドミッション制御メカニズムを使用すると、他のロケーションとの WAN リンクを介した決まった数のコールだけを受け入れるか、許可して、WAN 帯域幅のオーバーサブスクリプション、または音声パケットの遅延や損失を防ぐように、IP テレフォニー環境内の各ロケーションを設定することができます。WAN リンクに帯域幅値を指定すると、リンクの速度に基づいてコール数を制限できます。コール数が決められていた数に達するか、その数を超えると、Cisco CallManager は、そのリンクを介して処理されようとするその他のコールをすべて拒否します。

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

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

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

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

フラッシュからのマルチキャスト MoH を使用した SRST（Survivable Remote Site Telephony）

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

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

• この設定により、WAN を介してリモート事業所のサイトに MoH を転送する必要がなくなります。

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

例5-1 ルータのフラッシュからのマルチキャスト MoH を使用可能にする

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

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

フラッシュからの非 SRST マルチキャスト MoH

事業所のルータが SRST モードで動作していない場合でも、フラッシュからすべてのローカル デバイス（IP フォンを含む）に、マルチキャスト MoH ストリームを流すことができます。事業所のルータに対して、フラッシュからの非 SRST マルチキャスト MoH を設定する方法は、SRST モードでの設定と同じです（例5-1 を参照）。ただし、中央サイトの MoH サーバには、さらに設定が必要です。事業所のルータ上で設定された内容と同じマルチキャスト IP アドレスとポート番号をもつオーディオ ソースを使用して、中央サイトのサーバを設定する必要があります。マルチキャスト MoH オーディオ ストリームが、ルータのフラッシュから発信されるので、中央サイトの MoH サーバのオーディオ ソースが WAN を通過する必要はありません。

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

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

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

• WAN インターフェイス上のアクセス コントロール リスト（ACL）

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

図 5-5 では、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 で保留ソフトキーを押すと、電話機 C は、SRST ルータから発信された MoH オーディオ ストリームを受信します。

図 5-5 SRST ルータ フラッシュからのマルチキャスト MoH

分散型マルチサイト配置

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

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

分散型クラスタ間環境では、適切なマルチキャスト アドレス管理も、設計上の重要な考慮事項です。分散型ネットワーク全体で流れるリソースのオーバーラップを防止するために、いかなる MoH オーディオ ソース マルチキャスト アドレスも、配置内のすべての Cisco 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 リソースを指定しておく必要があります。