この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
メディア リソースとは、ソフトウェア ベースまたはハードウェア ベースのエンティティであり、接続中のデータ ストリームに対してメディア処理を行うものです。メディア処理機能には、複数のストリームを混合して 1 つの出力ストリームを作成する機能(会議)、ある接続から別の接続にストリームを渡す機能(メディア ターミネーション ポイント)、ある圧縮タイプから別の圧縮タイプにデータ ストリームを変換する機能(トランスコーディング)、保留中の発信者への音楽のストリーミング(保留音)、エコー キャンセレーション、シグナリング、TDM 回線からの音声インターフェイス(コーディング/デコーディング)、ストリームのパケット化、オーディオのストリーミング(Annunciator)などが含まれます。ソフトウェア ベースのリソースは、Cisco Unified Communications Manager(Unified CM)IP Voice Media Streaming サービス(IP VMS)を通じて提供されます。デジタル シグナル プロセッサ(DSP)カードでは、ソフトウェア ベースとハードウェア ベースの両方のリソースが提供されます。
この章では、Cisco Unified CM メディア リソース アーキテクチャおよび Cisco IP Voice Media Streaming Application サービスについての概要を説明し、さらに次のメディア リソースについて重点的に説明します。
この章を使用して、Unified CM で使用可能な各メディア リソース タイプの機能を理解し、配置に必要なリソースを確認してください。会議リソースの詳細については、Cisco Rich Media Conferencingの章を参照してください。
Cisco Integrated Service Router(ISR)ゲートウェイの DSP サイジングを適切に行うために、有効なログイン アカウントを持つシスコの従業員およびシスコ パートナーは次のツールを使用できるようになっています。
会社のメディア リソース割り当て方針を適切に策定するには、さまざまなメディア リソースコンポーネントの Cisco Unified CM アーキテクチャを理解しておくことが重要です。次の各項では、Unified CM を使用したメディア リソース設計の重要な特徴を中心に説明します。
Unified CM のソフトウェア コンポーネントであるメディア リソース マネージャ(MRM)は、メディア リソースの割り当ておよびメディア パスの挿入が必要であるかどうかを判別します。このメディア リソースは、Unified CM IP Voice Media Streaming Application サービスまたはデジタル シグナル プロセッサ(DSP)カードによって提供されます。MRM は、メディア リソースのタイプを判別および特定すると、当該デバイスに関連付けられているメディア リソース グループ リスト(MRGL)およびメディア リソース グループ(MRG)の構成の設定値に応じて、使用可能なリソース全体を検索します。MRGL および MRG は、割り当てを行うためにメディア リソースの関連するグループをまとめて保持する構成概念です。詳細については、メディア リソース グループとメディア リソース グループ リストの項を参照してください。
図 7-1 は、IP フォンと Cisco Unified Border Element 間で一般的なコーデックが使用できない場合に、トランスコーダなどのメディア リソースが、これらの間のメディア パスにどのように配置されるかを示しています。
図 7-1 一般的なコーデックが使用できない場合のトランスコーダの使用
Unified CM は、Skinny Client Control Protocol(SCCP)を使用して、メディア リソースと通信します。このメッセージングは、Unified CM と通信エンティティ間で使用されている可能性のあるプロトコルに依存しません。図 7-2 にメッセージ フローの例を示します。ただし、この例は、エンティティ間で交換されるすべての SCCP メッセージおよび SIP メッセージを示しているわけではありません。
Cisco IP Voice Media Streaming Application は、ソフトウェアベースの次のメディア リソースを提供します。
IP Voice Media Streaming Application をアクティブにすると、上記の各リソースが 1 つずつ自動的に設定されます。必要に応じて、会議、Annunciator、IVR、および MTP サービスを無効にできます。これらのリソースが不要な場合は、Unified CM 設定で適切なサービス パラメータを変更して無効にすることを推奨します。サービス パラメータには、各メディア サービスが処理できる最大接続数がデフォルトで設定されています。サービス パラメータの変更方法については、次の URL で入手可能な適切なバージョンの『 Cisco Unified Communications Manager Administration Guide 』を参照してください。
https://www.cisco.com/en/US/products/sw/voicesw/ps556/prod_maintenance_guides_list.html
複数のリソースが必要になる状況や、それらのリソースによって IP Voice Media Streaming Application にかかる負荷を慎重に検討してください。メディア リソースは、Unified CM と同じサーバ、または Unified CM 呼処理サービスを実行していない専用サーバを設置することができます。デフォルト数よりも多いリソースが必要な場合は、専用のサーバで実行するように設定することを推奨します。Cisco Unified CM のパフォーマンスに悪影響が及ぼされる可能性があるため、呼処理の負荷が大きい Cisco Unified CM ノードでは Cisco IP Voice Streaming Media Application をアクティブにしないことを強くお勧めします。展開内でメディア リソースを頻繁に使用することが予測される場合は、専用の Unified CM メディア リソース ノード(クラスタ内で呼処理を実行しない非パブリッシャ ノード)を配置するか、ハードウェアベースのメディア リソースに依存することを推奨します。Unified CM ノード上のソフトウェアベースのメディア リソースは、メディア リソースの必要性が限られている小規模な展開向けです。
音声インターフェイスは、時分割多重(TDM)インターフェイス上のレッグと VoIP(Voice over IP)接続上のレッグの 2 つのコール レッグを持つコールに適用されます。TDM レッグは、エンコーディング/デコーディングとストリームのパケット化を実行するハードウェアで必ず終端します。この終端機能は、同じハードウェア モジュール、ブレード、またはプラットフォーム上にあるデジタル シグナル プロセッサ(DSP)リソースによって実行されます。
Cisco TDM ゲートウェイ上の DSP ハードウェアはすべて、音声ストリームを終端できます。また、特定のハードウェアは、会議やトランスコーディングなどの他のメディア リソース機能を実行することもできます(トランスコーディングおよびトランスコーディングを参照)。DSP ハードウェアには、アップグレードまたは変更ができない固定 DSP リソース、またはアップグレード可能なモジュラ DSP リソースのどちらかが搭載されています。
DSP ごとにサポートされるコール数は、コールに使用されるコーデックの計算の複雑度や、DSP に設定された複雑度モードによって異なります。Cisco IOS を使用すると、ハードウェア モジュールの複雑度モードを設定できます。PVDM2、PVDM3、PVDM4 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 のクレジット割り当て規則は、より複雑です。
フレックス モードは、同じハードウェアで複数のコーデックのコールをサポートする必要がある場合に便利です。これは、フレックス モードでは、DSP が中複雑度または高複雑度として設定されている場合よりも多くのコールをサポートできるためです。ただし、フレックス モードではリソースのオーバーサブスクリプションが許可されています。オーバーサブスクリプションになると、すべてのリソースが使用された場合にコール障害が発生するリスクが生じます。フレックス モードを使用すると、物理 TDM インターフェイスを使用する場合よりも DSP リソースの数を削減できます。
中複雑度モードまたは高複雑度モードと比べると、フレックス モードには、DSP ごとに最も多くの G.711 コールをサポートできるという利点があります。たとえば、PVDM2-16 DSP は、中複雑度モードで 8 つの G.711 コールを、フレックス モードでは 16 の G.711 コールをサポートできます。
トランスコーダは、あるコーデックからの入力ストリームを、別のコーデックを使用する出力ストリームに変換するデバイスです。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 音声ストリームと低ビットレート圧縮音声ストリームの G.729a との間の変換を行うために、トランスコーダを使用します。次の場合には、どのようなときにトランスコーダ リソースが必要かが決まります。
一般に、単一のコーデックは、帯域幅の節約を通常必要としない単一サイト配置で使用されます。システムのすべてのコールに対して単一のコーデックが設定されている場合、トランスコーダ リソースは必要ありません。このシナリオでは、すべてのベンダーでサポートされている 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.729a を使用し、このコーデックをサポートしないデバイスがある場合、または G.729a をサポートするデバイスが G.729a を使用するように設定されていない場合に発生します。この場合はトランスコーダが必要です。サードパーティ ベンダーのデバイスは、G.729 をサポートしない場合があります。
トランスコーダは、メディア ターミネーション ポイント(MTP)と同じ機能も実行できます。トランスコーダ機能と MTP 機能の両方が必要な場合、トランスコーダがシステムによって割り当てられます。MTP 機能が必要な場合、Unified CM はトランスコーダまたは MTP をリソース プールから割り当てます。リソースの選択はメディア リソース グループによって決まります(メディア リソース グループとメディア リソース グループ リストの項を参照)。
設計を最終決定するには、必要なトランスコーダの数と、トランスコーダを配置する場所を検討する必要があります。マルチサイト配置の場合は、トランスコーダを必要な各サイトにローカルに配置することを推奨します。複数のコーデックが必要な場合は、すべてのコーデックをサポートしないエンドポイントの数、これらのエンドポイントを配置する場所、これらのリソースにアクセスする他のグループ、これらのデバイスがサポートする同時コールの最大数、およびネットワーク上でこれらのリソースを配置する場所を検討する必要があります。
トランスコーディングを実行するには、デジタル シグナル プロセッサ(DSP)リソースが必要です。DSP リソースは、音声モジュールまたは、Cisco サービス統合型ルータ(ISR)で使用可能なオンボード Cisco Packet Voice/Fax Digital Signal Processor(PVDM2、PVDM3、または PVDM4)のスロットに配置できます。
音声ゲートウェイとサポートされる音声モジュールの詳細については、次の URL で入手可能なシスコ音声モジュールおよびインターフェイス カードに関する情報を参照してください。
https://www.cisco.com/c/en/us/products/interfaces-modules/voice-modules-interface-cards/index.html
ビデオの相互運用性とは、Cisco TelePresence System(CTS)エンドポイント、他の Cisco Unified Communications ビデオ エンドポイント、およびサードパーティ製ビデオ エンドポイント間でポイントツーポイント コールの音声とビデオをサポートすることです。Cisco Unified CM 8.5 よりも前のリリースでは、さまざまなビデオ エンドポイント間におけるビデオの相互運用性は、ビデオ トランスコーダやマルチポイント コントロール ユニット(MCU)などのビデオ コンポーネントをエンドポイントの間に挿入した場合にのみ実現できました。
Cisco Unified CM 8.5 以降のリリースでは、さまざまなタイプのエンドポイント間(ポイントツーポイント)のネイティブなビデオの相互運用性が提供されるだけでなく、SIP および H.323 プロトコルでの H.264 コーデック ネゴシエーションによってビデオの相互運用性が全体的に向上し、利用可能な場合は高品位(HD)解像度でネゴシエートできるようになりました。ただし、ビデオの相互運用性は相互運用をサポートするエンドポイントによって異なります。詳細については、次の URL で入手可能な『 Interoperability Between CTS Endpoints and Other Cisco Endpoints or Devices 』を参照してください。
https://www.cisco.com/en/US/docs/telepresence/interop/endpoint_interop.html
メディア ターミネーション ポイント(MTP)は、2 つの全二重メディア ストリームを受け入れるエンティティです。MTP はこの 2 つのストリームをブリッジし、これらのストリームを個々にセットアップおよび終了できるようにします。ある接続の入力ストリームから受信されるストリーミング データは、他の接続の出力ストリームに渡され、逆も同様です。MTP には次のような多くの用途があります。
MTP は、G.711 a-law 音声パケットから G.711 mu-law パケット(およびその逆)にトランスコードしたり、パケット化周期が異なる(使用するサンプル サイズが異なる)2 つの接続をブリッジしたりできます。
コール中にメニュー システムのナビゲート、データの入力、またはその他の操作の目的で遠端のデバイスに信号を送信する際は、DTMF トーンが使用されます。これらは、呼制御の一部としてコール セットアップ中に送信される DTMF トーンとは異なる方法で処理されます。IP 上で DTMF を送信する方法はいくつかありますが、2 つの通信エンドポイントで共通の手順がサポートされていない場合があります。このような場合、Unified CM はメディア パスに動的に MTP を挿入して、DTMF 信号をエンドポイント間で変換できます。残念ながら、このようなコールには MTP リソースが 1 つずつ必要となるため、この方法は拡張性に欠けています。必要な MTP リソースの最適な量は、以降の項に従い、システム内のエンドポイント、トランク、およびゲートウェイの組み合わせに基づいて判断してください。
MTP の挿入が必要であると判断された場合に使用可能な MTP リソースがないとき、Unified CM はサービス パラメータ [MTP 割り当てが失敗した場合コールが失敗する(Fail call if MTP allocation fails)] の設定に従って、そのコールを続行するかどうかを決定します。このサービス パラメータは、[いいえ(False)] のデフォルト値に設定されています。このデフォルト設定では、SIP アーリー オファー トランクの着信コールは、発信側でディレイド オファーになります。
次の方法を使用して、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 手順は、主に 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 イベントの実際の継続時間など)を伝送します。
この方法は 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 以外のすべての Cisco Unified Communications エンドポイントはさまざまなシグナリング パスによって DTMF を Unified CM に送信し、Unified CM は受け取った DTMF を異なるエンドポイント間で転送します。たとえば、IP Phone は Unified CM への SCCP メッセージを使用して DTMF を送信します。この DTMF は H.245 シグナリング イベントによって H.323 ゲートウェイに送信されます。Unified CM は、異なるシグナリング方式の間で DTMF を転送できます。
Cisco SIP エンドポイントはすべて NTE をサポートしているため、DTMF はエンドポイント間で直接送信され、変換は不要です。
ご使用のデバイスで NTE がサポートされるかどうかは、そのデバイスの製品マニュアルを参照してください。NTE のサポートは SIP に限定されていないため、その他の呼制御プロトコルを使用するデバイスでサポートされていることがあります。Unified CM は、エンドポイントのペアの機能に基づき、MTP をコール単位に動的に割り当てることができます。
SIP トランク設定は、SIP ユーザ エージェント(別の Cisco Unified CM クラスタや SIP ゲートウェイなど)との通信をセットアップする際に使用されます。
SIP はセッション記述プロトコル(SDP)によってメディア情報をネゴシエートします。これにより、一方が提示したメディア セットに他方が応答する形で、使用するメディアがある組み合わせに決定します。SIP では、発信側が初期 INVITE メッセージ(アーリー オファー)によって初期のオファーを送信するか、発信側がそうしなかった場合は着信側が最初の信頼性のある応答(ディレイド オファー)で初期のオファーを送信できます。
デフォルトで、Unified CM SIP トランクは、初期のオファー(ディレイド オファー)を伴わない INVITE を送信します。Unified CM には、SIP トランクが INVITE でオファー(アーリー オファー)を送信できるようにする次の 3 つの設定可能なオプションがあります。
メディア ターミネーション ポイントが必須(Media Termination Point Required)
SIP トランク上でこのオプションを有効にすると、すべての発信コールに対して 1 つの MTP が割り当てられます。このオプションは、SIP トランク上で単一のコーデック(G.711 または G.729)の制限を課すコーデックのパススルー モードをサポートしないので、メディアを音声コールのみに制限します。このオプションが有効な場合、トランクを介したコールは、同じシグナリング パスに従うようにメディアを強制する発信デバイス MTP を使用せずに、トランクに割り当てられている MTP を使用します。
(注) SIP トランク上で [メディア ターミネーション ポイントが必須(Media Termination Point Required)] オプションを有効にすると、MTP 使用率が上がります。必要に応じてではなく、すべての着信コールおよび発信コールに対して MTP が割り当てられるためです。
[音声コールとビデオ コールに対する早期オファー サポートが必須(必要な場合は MTP を挿入)(Early Offer support for voice and video calls Mandatory (insert MTP if needed))]
SIP トランクに関連付けられた SIP プロファイルでこの Unified CM 設定オプションを有効にすると、MTP が挿入されるのは、発信デバイスが発信アーリー オファーの作成に必要なメディア特性を Unified CM に提示できない場合のみです(たとえば、Unified CM への着信コールがディレイド オファー SIP トランクまたは Slow Start H.323 トランクで受信される場合、Unified CM に登録された Cisco Unified IP Phone 7940 または 7960 などの古い SCCP ベースの電話機からコールなど)。Unified CM は、エンドポイントおよび MTP コーデック機能のスーパーセットを作成し、適用可能なリージョンペア設定に基づいてコーデックのフィルタリングを適用します。発信オファー SDP は、MTP の IP アドレスとポート番号、発信電話でサポートされる音声コーデックを使用します。
Unified CM が H.323 Slow Start または SIP ディレイド オファー トランクで着信を受信した場合、コールの開始時に発信デバイスのメディア機能を使用できません。この場合、Unified CM は、MTP を挿入し、その IP アドレスと UDP ポート番号を使用して、(リージョンペアのフィルタリング後の)サポートされるすべてのオーディオ コーデックを、発信 SIP トランク上で送信される初期 INVITE のオファー SDP にアドバタイズする必要があります。アンサー SDP が SIP トランク上で受信される場合、その SDP に発信エンドポイントでサポートされるコーデックが含まれていれば、追加のオファー/アンサー トランザクションは不要です。コーデックが一致しない場合、Unified CM は、トランスコーダを挿入してその不一致に対処するか、Re-INVITE または UPDATE を送信してメディア ネゴシエーションをトリガーできます。H.323 Slow Start トランクまたは SIP ディレイド オファー トランクからのコールは、初期コール セットアップ時に音声のみをサポートしますが、コール メディアが再ネゴシエートされれば(保留/再開後など)、ビデオと SRTP をサポートするようにコール中にアップグレードされる可能性があります。
トランクの SIP プロファイルに [音声コールとビデオ コールに対する早期オファー サポートが必須(必要な場合は MTP を挿入)(Early Offer support for voice and video calls Mandatory (insert MTP if needed))] を設定した場合、古い SCCP ベースの電話機、SIP ディレイド オファー トランク、および H.323 Slow Start トランクからのコールは、すでに別の理由で MTP またはトランスコーダが割り当てられていなければ、Unified CM によって MTP が割り当てられます。この MTP を使用して、有効なメディア ポート番号と IP アドレスを含むオファー SDP が生成されます。この MTP は、発信 SIP トランクのメディア リソースからではなく、発信デバイスに関連付けられているメディア リソースから割り当てられます。(この処理で、メディア パスが発信 SIP トランクの MTP にアンカーされるのを回避します)。発信デバイスのメディア リソース グループ リスト(MRGL)から MTP を割り当てることができない場合、MTP の割り当ては SIP トランクの MRGL から試行されます。
(注) MTP リソースを使用できない場合、コールは、ディレイド オファー コールとして処理されます。
Unified CM は、次のいずれかの手段で着信コールを受信する場合は、SIP トランク上で発信アーリー オファー コールを作成するために MTP を挿入する必要はありません。
[音声コールとビデオ コールに対する早期オファーのサポートはベスト エフォート(MTP の挿入なし)(Early Offer support for voice and video calls Best Effort (No MTP inserted))]
この Unified CM SIP プロファイルの設定オプションが有効になっている場合、SIP トランクは MTP を使用してアーリー オファーを作成することはありませんが、発信側デバイスの機能に応じて、アーリー オファーまたはディレイド オファーを送信します。
ベスト エフォートのアーリー オファー SIP トランクは、次の状況において発信コールをアーリー オファー(SDP コンテンツを含む INVITE)として送信します。
ベスト エフォートのアーリー オファー トランクは、次の状況において発信コールをディレイド オファー(SDP コンテンツを含まない INVITE)として送信します。
ベスト エフォートのアーリー オファー SIP トランクを介したコールは、音声、ビデオ、および暗号化されたメディアをサポートしています。
通常、すべての Unified CM および Unified CM Session Management Edition の SIP トランクに対し、[音声コールとビデオ コールに対する早期オファーのサポートはベスト エフォート(MTP の挿入なし)(Early Offer support for voice and video calls Best Effort (No MTP inserted))] が推奨されます。
このオプションの詳細については、ベスト エフォートのアーリー オファー [音声コールとビデオ コールに対する早期オファーのサポートはベスト エフォート(MTP の挿入なし)(Early Offer support for voice and video calls Best Effort (No MTP inserted))]の項を参照してください。
デフォルトでは、SIP トランク パラメータの [メディア ターミネーション ポイントが必須(Media Termination Point Required)] と SIP プロファイル パラメータの [音声コールとビデオ コールに対する早期オファー サポート(Early Offer support for voice and video calls)] は選択されていません。
SIP トランクで MTP リソースが必要かどうかを判断するには、次の手順に従います。
1. この SIP トランクで定義されている対向の SIP デバイスが、SIP アーリー オファーを含まない着信コールを受け入れられるかどうかを確認します。
受け入れられない場合、このトランクに関連付けられた SIP プロファイルで、[音声コールとビデオ コールに対する早期オファーのサポート(必要な場合は MTP を挿入)(Early Offer support for voice and video calls (insert MTP if needed))] チェックボックスをオンにします。発信 SIP トランク コールでは、アーリー オファーの作成に必要なメディア特性を持つ Unified CM を発信側デバイスが提供できない場合、または DTMF 変換が必要な場合にのみ、MTP が挿入されます。
その場合は、[音声コールとビデオ コールに対する早期オファーのサポートはベスト エフォート(MTP の挿入なし)(Early Offer support for voice and video calls Best Effort (No MTP inserted))] をオンにして、ステップ 2. に進んで、MTP が DTMF 変換に対して動的に挿入されるかどうかを判断します。MTP による DTMF 変換は、どのコーデックを使用している場合でも実行できます。
2. トランクの DTMF Signaling Method を選択します。このパラメータは、そのトランクでの DTMF 選択の動作を制御します。すべてのコールについて、DTMF 方式を一致させるために、必要に応じて使用可能な MTP が割り当てられます。
a. DTMF Signaling Method:No Preference
このモードでは、Unified CM は、エンドポイントによってサポートされる DTMF シグナリング方式を選択することで、MTP の使用を最小限に抑えようとします。
両方のデバイスが RFC 2833 をサポートしている場合は、MTP は必要ありません。
両方のデバイスがいずれかのアウトオブバンド DTMF メカニズムをサポートしている場合、Unified CM は SIP トランク上で KPML を使用します。MTP が必要となる唯一のケースは、エンドポイントの 1 つがアウトオブバンドのみをサポートし、もう一方が RFC 2833 のみをサポートする場合です。
両方のデバイスが RFC 2833 とアウトオブバンド DTMF メカニズムをサポートしている場合、Unified CM は RFC 2833 と KPML の両方をネゴシエートしますが、番号を受信する際は RFC 2833 に依存します。
(注) Unified CM の DTMF 設定で SIP トランクが [設定なし(No Preference)] に設定されている場合、Unified CM は Unsolicited Notify に対してネゴシエーションを行いません。たとえば、遠端の SIP ゲートウェイまたは Cisco Unified Border Element が dtmf-relay sip-notify 用に設定されていて、Cisco Unified Border Element に接続する Unified CM SIP トランクが [設定なし(No Preference)] に設定されていると、DTMF は機能しません。この場合に推奨される方法は、DTMF 設定で Unified CM SIP トランクを OOB および RFC 2833 に接続するよう設定することです。こうすることで、Unified CM が SIP ゲートウェイまたは Cisco Unified Border Element と Unsolicited Notify で DTMF 方式をネゴシエートできるようになります。
b. DTMF Signaling Method:RFC 2833
トランク全体の DTMF シグナリング方式を制限することにより、Unified CM は、一方または両方のエンドポイントが RFC 2833 をサポートしていない場合に MTP を強制的に割り当てます。この設定では、MTP が割り当てられないのは、両方のエンドポイントが RFC 2833 をサポートしている場合だけです。
c. DTMF Signaling Method:OOB and RFC 2833
このモードでは、SIP トランクを通じて KPML 方式と RFC 2833 DTMF 方式の両方が送信されます。これは MTP の使用される可能性が最も高いモードです。MTP リソースが必要とされない唯一のケースは、両方のエンドポイントが RFC 2833 といずれかの OOB DTMF 方式(KPML または SCCP)をサポートしている場合です。
(注) Cisco Unified IP Phone は、DTMF を SCCP 経由で受信した場合、エンド ユーザに対して DTMF を再生しますが、RFC 2833 で受信したトーンは再生しません。ただし、DTMF を別のエンド ユーザに送信する必要はありません。DTMF を必要とするエンドポイント(PSTN ゲートウェイ、アプリケーション サーバなど)と対応するコールを発信するエンドポイントについてのみ検討する必要があります。
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.323v2 で規定された Empty Capabilities Set(ECS)で使用する OpenLogicalChannel および CloseLogicalChannel 要求機能をサポートしていない H.323 エンドポイントでも、MTP を利用することでこれらの機能をサポートすることができます。この要件はあまり発生しません。すべての Cisco H.323 エンドポイント、およびほとんどのサードパーティのエンドポイントが ECS をサポートしています。必要に応じて、MTP が割り当てられ、H.323 エンドポイントに代わってコールに接続されます。MTP が H.323 コールで要求され、使用できるものがない場合、コールは処理されますが、付加サービスを呼び出すことはできません。
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 を使用します。
H.323 トランクは、H.245 アウトオブバンド方式による DTMF のシグナリングをサポートします。H.323 クラスタ間トランクは、NTE による DTMF もサポートします。H.323 トランクには DTMF 設定オプションはありません。DTMF 転送方式は Unified CM によって動的に選択されます。
異なるクラスタにある 2 つのエンドポイントが H.323 トランクを使用して接続する場合は、次のケースが起こり得ます。
たとえば、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 ゲートウェイは、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 アプリケーションと通信します。DTMF の観点では、CTI ルート ポイントは、すべての OOB 方式をサポートし、RFC 2833 はサポートしないエンドポイントと見なすことができます。そのようなエンドポイントで DTMF 変換に MTP が必要となるケースは、RFC 2833 だけをサポートする別のエンドポイントと通信する場合だけです。
電話コールのファーストパーティ制御を持つ CTI ルート ポイントは、コールのメディア ストリームに参加し、MTP の挿入を必要とします。CTI によるコールのサードパーティ制御が可能で、メディアが CTI で制御されているデバイスを通過する場合、MTP が必要かどうかは制御されるデバイスの機能によって異なります。
例 7-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 は、会議の参加者のデバイスの中に RFC 2833 を使用するデバイスがある場合に使用されます。会議機能が呼び出されると、Unified CM が、コールに含まれており、RFC 2833 だけをサポートするすべての会議参加者のデバイスに MTP リソースを割り当てます。これは、カンファレンス ブリッジの DTMF 機能が使用されているかどうかにかかわらず行われます。
ソフトウェア 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を参照)。
音声モジュールまたは、Cisco サービス統合型ルータ(ISR)で使用可能なオンボード Cisco Packet Voice/Fax Digital Signal Processor(PVDM2、PVDM3、または PVDM4)のスロットに配置された DSP リソースは、MTP リソースとしても使用できます。
各 PVDM モジュールでサポートされるセッションの詳細については、メディア リソースのキャパシティ プランニングの項を参照してください。
(注) Cisco IOS MTP リソースがコール フローのために Unified CM によって呼び出されると、コール フローのメディア レッグにトランスレーティングを必要とする場合を除き、ハードウェア DSP セッション以外のソフトウェア セッションが消費されます。したがって、MTP を呼び出すフローの場合、トランスレーティング(コーデックは同じだがパケット化の時間が異なるメディア レッグ間の変換)が必要な場合にのみ DSP セッションが使用されます。
Trusted Relay Point(TRP)はメディア ストリームに挿入可能なデバイスの一種で、そのストリームのコントロール ポイントとして機能します。TRP を使用すると、そのストリームにさらに処理を加えることができます。また、ストリームが任意の特定のパスを通るようにする手段として TRP を使用することも可能です。TRP 機能を使用するためには 2 つの要素が存在します。1 つは CUCM 上で論理的に TRP を設定すること。もう 1 つは実際に TRP として動作するコールのアンカーポイントとなるデバイスです。TRP 機能は MTP デバイスをアンカーポイントとして使用する際に使うことができます。
Unified CM の個々の電話機に関する設定に、その電話機へのコールまたはその電話機からのコールに対して TRP を呼び出すための設定パラメータが新しく追加されました。TRP リソースの管理には、メディア リソース プール メカニズムが利用されます。その電話機のメディア リソース プールには、TRP として呼び出し可能なデバイスが含まれている必要があります。
TRP を QoS 強制メカニズムとして使用する例については、ネットワーク インフラストラクチャの章を参照してください。冗長ファイアウォールを備えた冗長なデータセンターでメディア ストリームのアンカー ポイントとして TRP を利用する例については、Cisco Collaboration Securityの章を参照してください。
アナンシエータは Cisco IP Voice Media Streaming Application のソフトウェア機能で、これを使用すると、音声メッセージや各種コール プログレス トーンをシステムからユーザに流すことができます。これは、SCCP メッセージを使用して RTP ストリームを確立し、また、Cisco IP Phone またはゲートウェイなどのデバイスに複数の片方向 RTP ストリームを送信できます。ほとんどの SIP デバイスでは、コール プログレス トーンは登録時にデバイスにダウンロード(プッシュ)され、必要に応じて Unified CM からの SIP シグナリング メッセージで呼び出せるようにします。クラスタ間 SIP トランクなどの一部の SIP デバイスは、引き続きコール プログレス トーンに Annunciator を使用する場合があります。Annunciator は、SIP を使用しているか SCCP を使用しているかに関係なく、ほとんどのデバイスで口頭メッセージに使用できます。
一部のインストールでは、Annunciator との双方向メディア接続を確立する必要がある場合があります。この機能を有効にするには、Cisco Unified CM サービス パラメータ [デュプレックス ストリーミング有効(Duplex Streaming Enabled)] を [はい(True)] に設定します。これは、ファイアウォール トラバーサルまたは SIP アーリー オファーのシナリオで必要となる場合があります。
トーンとアナウンスは、システムで事前に定義されています。アナウンスでは、ローカリゼーションがサポートされており、また、適切な.wav ファイルを置き換えて、アナウンスをカスタマイズすることもできます。Annunciator は、トランスコーディング リソースを使用しないで、G.711 a-law および mu-law、G.729、および Cisco L16 Wideband コーデックをサポートできます。
この機能には、次のようなコール失敗の状態に応じて再生されるストリーミング メッセージが用意されています。
– 優先順位の高い既存のコールが原因で、プリエンプション処理できない。
– 着信番号が、プリエンプション処理またはコール ウェイティングに対応していない。
SIP エンドポイントには、トーンを生成し、RTP ストリームでインバンドで送信する機能があります。SCCP デバイスにはこの機能がないため、SIP エンドポイントと統合した場合、DTMF トーンの生成または受け入れ時には Annunciator と MTP が併用されます。次のタイプのトーンがサポートされます。
– コール プログレス トーン(ビジー、アラート、順番の変更、およびリングバック)
これらのデバイスには、コール プログレス トーン(リングバック トーン)のサポートが必要です。
次のようなコール失敗の状態では、システムはエンド ユーザにストリーミング メッセージを再生します。
– 番号が通話中で、その番号がプリエンプション処理またはコール ウェイティング用に設定されていない。
電話会議の間、システムは、参加者がブリッジに参加、またはブリッジから退出したことをアナウンスするときに、割り込み音を再生します。
Cisco IP Voice Media Streaming Application をサーバ上でアクティブにすると、Annunciator がシステム内に自動的に作成されます。Media Streaming Application を非アクティブにすると、Annunciator も非アクティブになります。単一の Annunciator インスタンスは、パフォーマンス要件を満たす場合は、Unified CM クラスタ全体にサービスを提供できます(Annunciator のパフォーマンスを参照)。そうでない場合は、追加の Annunciator をクラスタ用に設定する必要があります。追加の Annunciator を設定するには、クラスタ内の他のサーバ上で Cisco IP Voice Media Streaming Application をアクティブにします。
Annunciator は、そのデバイス プールおよび CM グループで定義されたとおり、一度に 1 つの Unified CM に登録されます。デバイス プールに対してセカンダリが設定されている場合、Annunciator は自動的にセカンダリ Unified CM にフェールオーバーします。障害発生時に再生されるアナウンスはいずれも保持されません。
Annunciator はメディア デバイスと見なされるため、メディア リソース グループ(MRG)に含めて、電話機およびゲートウェイで使用される Annunciator の選択を制御できます。
デフォルトでは、Annunciator は 48 のストリームを同時にサポートするように設定されています。この設定値は、Unified CM サービスが同一のサーバ(共存)上で動作する Annunciator に推奨される最大値です。サーバの接続性が 10 Mbps しかない場合は、設定を下げて同時ストリームを 24 にします。
各サーバ プラットフォームでサポートされる Annunciator セッションの詳細については、コラボレーション ソリューション サイジング ガイダンスの章で、メディア リソースの項を参照してください。
トポロジ対応型のコール アドミッション制御を提供するために、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 の詳細については、帯域幅管理の章を参照してください。
保留音(MoH)機能を利用するには、各 MoH サーバが Unified CM クラスタに含まれ、データ レプリケーション スキーマに参加している必要があります。特に、MoH サーバは、データベース レプリケーション プロセスを通じて、次の情報を Unified CM クラスタと共有する必要があります。
MoH サーバを設定するには、1 つ以上の Unified CM ノードで Cisco IP Voice Media Streaming Application サービスを有効にします。MoH サーバは、Unified CM とともに同じサーバに配置することも、スタンドアロン モードで配置することもできます。
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 は、IPv4 でのみ使用可能です。IPv6 でのマルチキャストは、MoH サーバで現在サポートされていません。
MoH コール フローの詳細については、MoH コール フローの項を参照してください。
この項では、Unified CM に実装するときの MoH 選択プロセスについて説明します。
Cisco Unified Communication 環境における基本的な MoH の動作は、保留側と被保留側から構成されます。 保留側 とは、通話を保留にするエンドポイント ユーザまたはネットワーク アプリケーションです。一方、 被保留側 とは、保留にされたエンドポイント ユーザまたはデバイスです。
エンドポイントが受信する MoH ストリームは、エンドポイントを保留にするデバイス(保留側)のユーザ保留 MoH オーディオ ソースと、保留にされたエンドポイント(被保留側)に設定されたメディア リソース グループ リスト(MRGL)との組み合わせによって決まります。保留側に対して設定されたユーザ保留 MoH オーディオ ソースによって、保留側が通話を保留にしたときに流されるオーディオ ファイルが決まります。被保留側に設定された MRGL は、被保留側が MoH ストリームを受信する元のリソースまたはサーバを指定します。
図 7-3 の例に示すように、電話機 A および B が通話中であるときに、電話機 B(保留側)で電話機 A(被保留側)を保留にする場合、電話機 A には、電話機 B に対して設定された MoH オーディオ ソース(オーディオソース 2)が聞こえます。ただし、電話機 A はこの MoH オーディオ ストリームを、電話機 A に対して設定された MRGL(リソースまたはサーバ)(MRGL A)から受信します。
図 7-3 ユーザ保留オーディオ ソースとメディア リソース グループ リスト(MRGL)
設定した MRGL により、ユニキャスト専用デバイスが MoH ストリームを受信するサーバが決まるので、ユニキャスト専用デバイスを設定する場合は、ユニキャスト MoH リソースまたはメディア リソース グループ(MRG)を指定する MRGL を使用する必要があります。同様に、マルチキャスト機能を持つデバイスは、マルチキャスト用に設定された MoH サーバが含まれたマルチキャスト MRG を指定する MRGL を使用して設定する必要があります。
図 7-4 は、これらの 2 つのタイプのコール フローを示しています。電話機 A が電話機 B と通話中であるときに、電話機 A(保留側)で [Hold] ソフトキーを押すと、MoH サーバから電話機 B(被保留側)に音楽ストリームが送信されます。この音楽ストリームは、IP ネットワーク内の被保留側だけでなく、電話機 A が電話機 C を保留にする場合と同様に、PSTN 上の被保留側にも送信できます。電話機 C の場合、MoH ストリームは音声ゲートウェイ インターフェイスに送信され、PSTN 電話機に適したフォーマットに変換されます。電話機 A が [Resume] ソフトキーを押すと、被保留側(電話機 B または C)は、音楽ストリームから切り離され、電話機 A に再び接続されます。
ネットワーク保留は、次のようなシナリオで発生する可能性があります。
図 7-5 に、コール転送中のネットワーク保留の例を示します。コール フローは、次の手順で構成されます。
1. 電話機 A が PSTN 電話機 C からのコールを受信します。
2. 電話機 A がコールに応答し、電話機 B に転送します。転送プロセスの進行中に、電話機 C はネットワーク保留になります。
3. 電話機 C は、MoH サーバからゲートウェイ経由で MoH ストリームを受信します。電話機 A が転送アクションを完了したあと、電話機 C は音楽ストリームから切り離され、電話機 B に転送されます。
このプロセスは、コール パークや会議セットアップなどの他のネットワーク保留操作の場合と同じです。
Unified CM MoH サーバでは、2 つのタイプのソースから MoH ストリームを生成できます。
Unified CM クラスタごとに最大で 501 個の MoH オーディオ ソースを設定できます。そのうちの 1 つ(51 番目)は固定ライブ ソースとして識別されます。IPv4 またはデュアルモードの IPv4/IPv6 メディア アドレスのサポートを提供するために、MoH サーバは Unified CM クラスタに登録します。
オーディオ ファイル(.wav 形式)を Unified CM にアップロードし、MoH コーデックの MoH オーディオ ソース ファイルを自動的に生成することができます。Unified CM では、MoH ストリーム用に G711(a-law および mu-law)、G.729 Annex A、および Cisco L16 ワイドバンド コーデックをサポートしています。アップロードしたオーディオ ファイルは、16 ビットの PCM 形式または 8 ビットの G.711(a-law/mu-law)形式にする必要があります。
(注) MoH オーディオ ソースを設定する前に、Unified CM Administration インターフェイスのファイルのアップロード機能を使用して、クラスタ内のすべての MoH サーバに.wav 形式のオーディオ ソース ファイルをアップロードする必要があります。最初にオーディオ ソース ファイルをクラスタ内の各 MoH サーバにアップロードし、次にそのオーディオ ファイルをパブリッシャ(MoH サーバでなくてもかまいません)にアップロードし、最後にそのパブリッシャ上の Unified CM Administration インターフェイスで MoH オーディオ ストリーム番号を割り当て、MoH オーディオ ソースを設定することを推奨します。これによって、各 MoH サーバは、MoH オーディオ ストリーム番号に割り当てられている場合に MoH オーディオ ファイルを使用できるようになります。
録音されたオーディオまたはライブ オーディオが必要な場合、マルチキャストをサポートする Cisco IOS ルータまたサードパーティ デバイスのアナログ インターフェイスに接続されている固定ライブ ソースからマルチキャスト MoH を生成できます。
(注) Unified CM ノードが仮想化される際の MoH 用の USB ポートがサポートされていないため、Cisco Unified CM は、MOH サーバへの固定ライブ オーディオ ソース接続用 USB サウンド カードをサポートしなくなりました。
このメカニズムにより、ラジオ、CD プレーヤー、または互換性があるその他のサウンド ソースを使用して、マルチキャスト MoH をストリーミングできます。固定オーディオ ソースからのストリームは、Cisco IOS ルータによってリアルタイムにトランスコードされます。
(注) 保留音を送信するときに固定オーディオ ソースを使用する場合は、事前に、著作権のあるオーディオ素材の再ブロードキャストについて、その適法性および問題を検討しておく必要があります。起こりうる問題については、貴社の法務部門に相談してください。
Cisco IOS ルータからのライブ MoH の詳細については、次の URL で入手可能な最新バージョンの『 Cisco Unified SCCP and SIP SRST System Administrator Guide 』の「 MoH from a Live Feed 」の項を参照してください。
https://www.cisco.com/en/US/products/sw/voicesw/ps2169/products_installation_and_configuration_guides_list.html
Cisco Unified CM 11.5 から、Cisco IOS ルータは.wav ファイルまたは外付けオーディオ ソースからマルチキャスト オーディオ RTP ストリームを提供するように設定できるようになりました。オーディオ ソースは.wav ファイル、CD プレーヤー、ラジオ、または Cisco IOS ルータに接続されている他のオーディオ デバイスから取得できます。
(注) この機能は、既存の Unified CM の「固定オーディオ ソース」(#51)に影響しません。そのソースはそのまま維持され、Cisco IOS ルータからストリームされる固定ライブ ソースまたはオーディオ ファイル マルチキャストとして使用できます。
この機能では、Unified CM MOH オーディオ ソース設定オプション内に 1 つ以上の外部マルチキャスト ソースを設定する機能が提供されます。この機能を使用して、Unified CM は外部オーディオ ソースが接続されている Cisco IOS ルータから 1 つ以上のマルチキャスト RTP ストリームを受信します。次に、Unified CM は、受信したマルチキャスト RTP ストリームを保留された発信者に送信します。
Unified CM MoH オーディオ ソースの設定内で、.wav ファイルをオーディオ ソースとして使用するように MoH オーディオ ソースを設定する代わりに、外部(マルチキャスト)の IP: PORT をオーディオ ソースとして使用するように割り当てることができます。これによって、発信者は Cisco IOS ルータの E&M ポートに接続された外部マルチキャスト ソースからストリーミングされた保留音を聞くことができます。(図 7-6 を参照)。複数の Unified CM MoH オーディオ ソースで同じ外部マルチキャスト オーディオ ソースを使用できます。
図 7-6 に、外部マルチキャスト MoH ソースを使用する場合のネットワーク フローを示します。示されているように、音楽ソースが Cisco SRST ルータの E&M ポートに接続され(A)、ネットワーク マルチキャスト グループ 239.1.1.1:16384(B)に音声がブロードキャストされるように設定されています。MoH サーバは、マルチキャスト グループ(C)を受信し、ユニキャスト RTP MoH ストリーム(D)を保留された電話機 A に再ブロードキャストするように設定されています。
オプションで、MoH サーバは、Cisco SRST ルータが外部オーディオ ソースをブロードキャストするために使用しているものと同じマルチキャスト グループ アドレスで設定されたオーディオ ソースを持つことができます。マルチキャスト MoH サーバとオーディオ ソースが同じマルチキャスト グループ アドレスで設定されている場合、電話機 B が保留中になると、電話機 B は SRST ルータ経由の元のマルチキャスト ストリーム(B)ブロードキャストからのマルチキャスト RTP オーディオ ストリーム(E)を受信します。この場合、宛先マルチキャスト IP アドレス グループが SRST ルータ経由の外部オーディオ ソース マルチキャスト ストリーム(B)ブロードキャストと同じであることが認識されるため、MoH サーバは音声を送信しません。また、Unified CM でオーディオ ソースに対して別のマルチキャスト IP アドレスを指定することもできます。この場合、MoH サーバは、ネットワークから受信する元のマルチキャスト ブロードキャスト オーディオ ストリーム(C)を使用して別個のマルチキャスト ストリームを再ブロードキャストします。
個々のケースにユーザ オーディオ ソース設定値とネットワーク オーディオ ソース設定値のいずれかを適用するか決定するために、Unified CM は、次の優先順位で、 保留側 デバイスに対するこれらの設定値を使用します。
1. ディレクトリまたは回線設定(ゲートウェイなど、回線定義のないデバイスには、このレベルはありません)
Unified CM は、 被保留側 デバイスの MRGL 設定値も、次の優先順位で使用します。
システムのデフォルト MoH リソースは、MRG に割り当てられていないリソースで、常にユニキャストであることに注意してください。
次の各項では、SCCP および SIP エンドポイントの両方について、ユニキャストとマルチキャスト MoH コール フローの詳細な図と説明を示します。次に示すすべてのコール フローは、Unified CM MOH サーバの MoH ストリーミングを示しています。Cisco IOS ルータからのマルチキャスト MoH のストリーミングは示されていませんが、これらのマルチキャスト シナリオのコール フローは通常、Unified CM MoH サーバのマルチキャスト コール フローと同じです。
ここでは、Skinny Client Control Protocol(SCCP)エンドポイントでの、保留音のマルチキャストおよびユニキャストのコール フローについて説明します。
図 7-7 は、標準的な 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 がこのグループに加わることを示します。
図 7-7 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 双方向オーディオ ストリームによって再び接続されます。
(注) 図 7-7 と図 7-8 のコール フロー図では、電話機 A と電話機 B の間に双方向 RTP オーディオ ストリームがあるコールを前提としています。これらの図は、コール フローを示しているので、適切な MoH 動作に必要な関連トラフィックのみが記載されています。したがって、インタラクションがわかりやすいように、キープアライブ、確認応答、およびその他のトラフィックは省略されています。各図の初期化イベントは、電話機 A によって実行される [Hold] ソフトキー アクションです。
図 7-8 は、SCCP ユニキャスト MoH コール フローを示しています。このコール フロー図では、電話機 A で [Hold] ソフトキーが押されると、Unified CM は、Close Receive Channel(受信チャネルのクローズ)と Stop Media Transmission(メディア送信の停止)を電話機 A と電話機 B の両方に指示します。このアクションは、実質的に、RTP 双方向オーディオ ストリームを停止させます。この時点まで、ユニキャストとマルチキャストの MoH コール フローは、まったく同じように動作します。
図 7-8 SCCP ユニキャスト MoH コール フローの詳細
次に、Unified CM は、Open Receive Channel(受信チャネルのオープン)を電話機 B(被保留側)に指示します。(これは、マルチキャストの場合とまったく異なっています。マルチキャストでは、Unified CM は、Start Multicast Media Reception(マルチキャスト メディア受信の開始)を被保留側に指示します)。次に、Unified CM は、MoH サーバに、電話機 B の IP アドレスへの Start Media Transmission(メディア送信の開始)を指示します。(これもまた、マルチキャスト MoH コール フローの動作とは異なります。マルチキャストでは、マルチキャスト グループ アドレスに参加するように電話機にプロンプト表示されます)。この時点で、MoH サーバは電話機 B に一方向のユニキャスト RTP 音楽ストリームを送信しています。電話機 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 双方向オーディオ ストリームによって再び接続されます。
ここでは、Session Initiation Protocol(SIP)エンドポイントでの、保留音のマルチキャストおよびユニキャストのコール フローについて説明します。
図 7-9 は、標準的な 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 です。
図 7-9 SIP マルチキャスト MoH コール フローの詳細
次に、図 7-9 の電話機 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 双方向オーディオ ストリームが再確立されます。
(注) 図 7-9 と図 7-10 のコール フロー図では、電話機 A と電話機 B の間に双方向 RTP オーディオ ストリームがあるコールを前提としています。これらの図は、コール フローを示しているので、適切な MoH 動作に必要な関連トラフィックのみが記載されています。したがって、インタラクションがわかりやすいように、キープアライブ、一部の確認応答、進行状況表示、およびその他のトラフィックは省略されています。各図の初期化イベントは、電話機 A によって実行される [Hold] ソフトキー アクションです。
図 7-10 は、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 コール フローはまったく同じです。
図 7-10 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 双方向オーディオ ストリームが再確立されます。
一部のシナリオでは、保留にされたデバイス(被保留側)と MOH サーバ間に双方向のメディア接続が必要です。Cisco Unified CM サービス パラメータ [デュプレックス ストリーミング有効(Duplex Streaming Enabled)] は、このタイプの接続を有効にするために使用可能です。MoH サーバは、保留にされたエンドポイントから受信した音声をすべて破棄します。たとえば、MoH メディア ストリームが保留にされたデバイスに到達するためにファイアウォールを通過する必要がある場合に、この [デュプレックス ストリーミング有効(Duplex Streaming Enabled)] オプションが必要になります。
この項では、DSP を含む各種ネットワーク モジュールおよびシャーシのキャパシティ、ネットワーク モジュールを含むシャーシのキャパシティ、およびハードウェアに対するソフトウェアの依存性に関する情報を提供します。
すべての Cisco ISR G1 および G2 のキャパシティ プランニングには、 https://www.cisco.com/go/dspcalculator から入手できる DSP Calculator を使用します。
ユニファイド コミュニケーション ソリューションの DSP リソースは、NM-HD、NM-HDV、および PVDM モジュールによって提供されます。NM-HD および NM-HDV2 モジュールは、Cisco ISR G1 および G2 シリーズのプラットフォームでサポートされています。これらのモジュールのキャパシティ情報については、それぞれの製品データ シートを参照してください。
PVDM モジュールは、PVDM-256K、PVDM2、PVDM3、および PVDM4 の 4 つのモデルで使用できます。それぞれのモデルに、異なる密度をサポートする複数のモジュールがあります。
ハードウェアベースのメディア リソースに対してキャパシティ プランニングを行う場合に考慮する点として、モジュールの密度、基盤となるプラットフォーム(Cisco ISR G1 または G2)、および必要な Cisco IOS の最小バージョンがあります。
PVDM2 モジュールのキャパシティ情報については、次の URL で入手可能な『 High-Density Packet Voice Digital Signal Processor Module for Cisco Unified Communications Solutions 』データ シートを参照してください。
https://www.cisco.com/en/US/prod/collateral/routers/ps5854/product_data_sheet0900aecd8016e845_ps3115_Products_Data_Sheet.html
PVDM3 モジュールのキャパシティ情報については、次の URL で入手可能な PVDM3 プロビジョニング情報を参照してください。
https://www.cisco.com/c/en/us/products/collateral/ios-nx-os-software/ios-ip-service-level-agreements-slas/whitepaper_C11-718333.html
PVDM4 モジュールのキャパシティ情報については、次の URL で入手可能な『 Cisco Fourth-Generation Packet Voice Digital Signal Processor Module for Cisco Unified Communications Solutions Data Sheet 』を参照してください。
https://www.cisco.com/c/en/us/products/routers/4000-series-integrated-services-routers-isr/datasheet-listing.html
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 は、スタンドアロン配置で 7.5K または 10K の Open Virtualization Archive(OVA)テンプレートを使用して、Cisco Unified Computing System(UCS)の C シリーズまたは B シリーズで最大 1,000 の MoH ストリームをサポートします。他のプラットフォームでは、Unified CM は、その他のサービスがサーバでアクティブであるかによって、その量の半分以下をサポートできます。MoH セッションがこの最大同時セッション数を超えてから、さらに負荷が増えると、MoH 品質の低下、不規則な MoH 動作、または MoH 機能の喪失までも発生するおそれがあるので、ネットワークのコール量が最大同時セッション数を超えないようにしてください。Unified CM クラスタごとに最大 500 の固有オーディオ ソースを設定できることに注意してください。
各サーバ プラットフォームでサポートされる MoH オーディオ ソースおよびセッションの詳細については、コラボレーション ソリューション サイジング ガイダンスの章で、メディア リソースの項を参照してください。
次の 2 つの MoH サーバ設定パラメータは、MoH サーバのキャパシティに影響を与えます。
このパラメータにより、ユニキャスト MoH に配置できるデバイスの数が決まります。デフォルトでは、この値は 250 に設定されています。
Maximum Half Duplex Streams パラメータは、次の公式から得られた値に設定する必要があります。
(サーバおよび配置キャパシティ)–((マルチキャスト MoH ソースの数) ∗ (有効な MoH コーデックの数))
|
|
|
|
---|---|---|---|
したがって、この例では、Maximum Half Duplex Streams パラメータは 976 未満の値で設定されます。マルチキャスト MoH オーディオ ソースのそれぞれに、有効な各 MoH コーデック用に作成された自動マルチキャスト RTP ストリームがあります。
このパラメータにより、マルチキャスト MoH に配置できるデバイスの数が決まります。
Maximum Multicast Connections パラメータは、必要に応じてすべてのデバイスを確実にマルチキャスト MoH に配置できるような数に設定する必要があります。MoH サーバはマルチキャスト ストリームの有限数だけを生成することができますが、多数の保留デバイスを各マルチキャスト ストリームに加えることもできます。このパラメータは、同時にマルチキャスト MoH に配置される可能性のあるデバイスの数、またはそれよりも大きい数に設定する必要があります。一般的なマルチキャスト トラフィックは、生成されるストリームの数に基づいて決まりますが、Unified CM では、マルチキャスト MoH に実際に配置されたデバイスの数または各マルチキャスト MoH ストリームに加えられたデバイスの数が適用されます。この方式は、マルチキャスト トラフィックが通常トラッキングされる方法と異なりますが、このパラメータを適切に設定することが重要です。
これらのパラメータを適切に設定しないと、MoH サーバ リソースが十分に使用されない、またはサーバがネットワーク負荷を処理できないといった問題が発生する可能性があります。サービス パラメータの設定方法については、次の URL で入手可能な『 Cisco Unified Communications Manager Administration Guide 』を参照してください。
https://www.cisco.com/en/US/products/sw/voicesw/ps556/prod_maintenance_guides_list.html
(注) MOH サーバごとに 1,000 セッションの最大限度数は、ユニキャスト、マルチキャスト、またはユニキャストとマルチキャストの同時 RTP ストリームに適用されます。制限は、トランスポート メカニズムに関係なく、プラットフォームがサポートできる MoH ストリームの推奨最大数を表します。
共存またはスタンドアロンの MoH サーバ設定のプロビジョニングを行う場合、ネットワーク管理者は、MoH オーディオ ストリームに使用されるトランスポート メカニズムのタイプを考慮する必要があります。ユニキャスト MoH を使用する場合、保留される各デバイスには、別々の MoH ストリームが必要です。しかし、マルチキャスト MoH と単一のオーディオ ソースのみを使用する場合、保留にするタイプのデバイス数に関係なく、設定されている MoH コーデック タイプごとに必要な MoH ストリームは 1 つだけです。
たとえば、30,000 台の電話機のあるクラスタがあり、保留率が 2 % である(すべてのエンドポイント デバイスの 2 % だけが、常に保留になる)場合、600 の MoH ストリームまたはセッションが必要です。ユニキャスト専用の MoH 環境の場合、この負荷を処理するために、10K OVA テンプレートを使用した Cisco Unified Computing System(UCS)で動作する 1 つの共存(またはスタンドアロン)MoH サーバが必要です。
比較すると、36 の固有 MoH オーディオ ストリームがあるマルチキャスト専用 MoH 環境は、たとえば、1 つの共存 MoH サーバが必要です。36 の固有マルチキャスト ストリームは、次のいずれかの方法でプロビジョニングできます。
上記の例では、2 % の保留率は、30,000 台の電話機に基づくものであり、保留になる可能性があるネットワーク内のゲートウェイまたはその他のエンドポイント デバイスを考慮していません。こうしたその他のデバイスは、電話機と同じように保留になる可能性があるので、保留率を計算するときは、これらのデバイスも考慮する必要があります。
上記の計算では、MoH サーバの冗長性を見込んでいません。MoH サーバに障害が発生する場合、またはユーザの 2% 以上が同時に保留になる場合、このシナリオでは、オーバーフローが発生したり負荷が増えたときに処理するための MoH リソースがありません。MoH リソースの計算には、冗長性に配慮して十分に余裕のあるキャパシティを含める必要があります。追加の MoH サーバは、メディア リソースのハイ アベイラビリティの項で説明されているように、冗長性またはハイ アベイラビリティ用にプロビジョニングできます。
Unified CM のメディア リソース グループ(MRG)とメディア リソース グループ リスト(MRGL)のコンストラクトは、この章で説明されているリソースの編成とアクセスの方法を制御するために使用されます。この項では、これらのコンストラクトを効率的に利用する方法について説明します。
メディア リソース グループ(MRG)とメディア リソース グループ リスト(MRGL)は、リソースの割り当て方法を制御する方式を提供するもので、リソースに対するアクセス権、リソースの場所、特定のアプリケーションのリソース タイプが含まれます。この項では、読者がメディア リソース グループおよびメディア リソース グループ リストを理解しているものとして、次の設計上の考慮事項について詳しく説明します。
メディア リソースに関するハイ アベイラビリティ設計には、冗長なメディア リソースを含める必要があります。これらのリソースが Cisco IOS ベースのリソースである場合は、単一プラットフォームの障害を防ぐために各リソースを複数の Cisco IOS プラットフォームに分散できます。また、各リソースを異なるプライマリ Unified CM サーバに登録することも可能です。
Cisco IOS は、フェールオーバー機能のモードとして「グレースフル」と「即時」の 2 種類をサポートしています。デフォルトのフェールオーバー方法はグレースフルで、この場合はすべてのメディア アクティビティが停止して初めてリソースがバックアップ Unified CM サーバに登録されます。それに対して即時フェールオーバーでは、プライマリの障害が検出されるとすぐにリソースがバックアップ Unified CM サーバに登録されます。冗長性のない 1 組のメディア リソースしかない状況では、即時フェールオーバーを使用することを推奨します。
次のトランスコーダのフェールオーバー プロセスは、デバイスが登録されている Cisco Unified CM が使用できなくなると実行されます。
プライマリ Unified CM に障害が発生した場合、トランスコーダ デバイスは、そのデバイスの Cisco Unified CM グループに定義されているセカンダリ Unified CM ノードに登録しようとします。トランスコーダ デバイスは、プライマリ Unified CM が再度使用可能になるとすぐにフォールバックします。その Unified CM にあったコールがリスト内の次の Unified CM に登録されます。
完全な冗長性のある 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 が SCCP ベースの Cisco Unified IP Phone 7940 または 7960 からの着信コールを受信した場合、コールが開始されると発信デバイスのメディア機能を使用できず、SIP PSTN サービス プロバイダーのほとんどにアーリー オファーが必要になります。この場合、Unified CM は、MTP を挿入し、その IP アドレスと UDP ポート番号を使用して、(リージョンペアのフィルタリング後の)サポートされるすべてのオーディオ コーデックを、発信 SIP トランク上で送信される初期 INVITE のオファー SDP にアドバタイズする必要があります。
集中型呼処理配置では、Unified CM クラスタとアプリケーション(たとえば、ボイスメールや IVR)は、中央サイトに置かれ、複数のリモート サイトが IP WAN を介して接続されます。リモート サイトでは、呼処理に中央の Unified CM を使用します。
WAN 帯域幅は一般に制限されるので、WAN を通過するときは、G.729 などの低ビット レート コーデックを使用するようにコールが設定されます(図 7-11 を参照)。
IP Phone 間の音声圧縮は、Unified CM の リージョン と ロケーション を使用して簡単に設定されます。リージョンは、そのリージョン内のデバイスが使用する圧縮のタイプ(たとえば、G.711 または G.729)を指定します。ロケーションは、そのロケーションのデバイスに出入りするコールに使用可能な、合計帯域幅量を指定します。
図 7-11 集中型呼処理を使用する WAN のトランスコーディング
Unified CM は、MRG(メディア リソース グループ)を使用して、クラスタ内の Unified CM サーバ間で、MTP リソースとトランスコーディング リソースの共有を可能にします。さらに、異なるリージョンを通過するコールに LBR コーデック(たとえば、G.729a)を使用する場合、トランスコーディング リソースが使用されるのは、エンドポイントの一方(または両方)が、LBR コーデックを使用できない場合だけです。
図 7-11 では、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 サービスを通じた圧縮音声コール接続もサポートします(図 7-12 を参照)。
次の状況では、分散型呼処理配置に、トランスコーディング サービスと MTP サービスが必要になる場合があります。
図 7-12 トランスコーディングを使用したクラスタ間コール フロー
Unified CM は、MRG(メディア リソース グループ)を使用して、クラスタ内の Unified CM サーバ間で、MTP リソースとトランスコーディング リソースの共有を可能にします。さらに、クラスタ間トランクを介したコールの場合、MTP リソースとトランスコーディング リソースは、必要な場合だけ使用されます。したがって、LBR コーデックをサポートしないアプリケーションに対して MTP サービスを設定する必要がなくなります。
メディアを操作するいずれのプロセスも、メディアの品質を低下させる可能性があります。たとえば、ネットワーク(IP または TDM)上で送信するための音声ストリームのエンコーディングと、相手側でのデコーディングは情報の損失を招き、結果として音声ストリームは元の音声を正確に再生しません。同じ音声ストリームの複数のエンコーディングおよびデコーディングの手順を含む、ネットワーク経由のメディア通過パスが存在する場合、エンコーディングおよびデコーディングの操作が繰り返されるたびに音声品質は低下していきます。通常、このようなパスは回避する必要があります。このことは特に、G.729 などの低帯域幅コーデック(LBC)に当てはまります。
このようなパスが回避できない場合には、G.711 または G.722 コーデックなどの帯域幅が比較的高く、低圧縮のコーデックを使用することによって通常、音声品質を向上させることができます。このようなパスが予想される場合には、これらのコーデックの使用を推奨します。このようなシナリオで、低帯域幅で高圧縮のコーデックを使用することは推奨できません。
ここでは、堅牢な MoH ソリューションの設計に役立つ、MoH 設定上の考慮事項とベスト プラクティスについて説明します。
MoH 配置に複数のコーデックが必要な場合、クラスタ全体の Unified CM サービス パラメータ設定にある IP Voice Media Streaming Application サービス パラメータ [サポートされる MoH コーデック(Supported MoH Codecs)] で設定します。[クラスタ全体のパラメータ(Clusterwide Parameters)] の下の [サポートされる MoH コーデック(Supported MoH Codecs)] リストの中から、MoH ストリームに許可する、目的のコーデック タイプをすべて選択します。デフォルトでは、G.711 mu-law のみが選択されています。別のコーデック タイプを選択するには、リストをスクロールさせて該当するコーデックをクリックしてください。複数選択する場合は、CTRL キーを押したまま、マウスを使用して、リストをスクロールさせて複数のコーデックを選択します。MoH イベントに使用される実際のコーデックは、MoH サーバおよび保留にされるデバイス(IP 電話、ゲートウェイなど)のリージョン設定によって決まります。したがって、適切なリージョン設定を 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 アドレスでインクリメントするように、マルチキャスト オーディオ ソースを設定することも必要です。
Cisco IP Phone には、マルチキャスト ポート番号という概念はありません。したがって、特定のオーディオ ストリームに対して設定されているすべてのコーデックが、同じマルチキャスト IP アドレス(別々のポート番号であっても)に送信される場合、1 本のストリームしか必要ない場合であっても、すべてのストリームが IP Phone に送信されます。IP Phone は 1 本の MoH ストリームしか受信できないので、不必要なトラフィックでネットワークが飽和状態になる可能性があります。
ルータには、マルチキャスト ポート番号という概念はありません。したがって、同じマルチキャスト グループ アドレス(別々のポート番号であっても)に送信される複数のストリームを検出すると、ルータは、そのマルチキャスト グループのすべてのストリームを転送します。必要なストリームは 1 本だけなので、ネットワーク帯域幅が過剰に利用され、その結果、ネットワークの輻輳が発生する可能性があります。
複数のマルチキャスト MoH サーバを設定する場合は、各 MoH サーバに異なる基本のマルチキャスト IP アドレスおよび/または範囲を割り当てます。複数の MoH サーバが同じマルチキャスト IP アドレスに送信している場合、エンドポイントがマルチキャスト グループ アドレスに追加されると、そのエンドポイントは(異なる MoH サーバからの)複数の MoH ストリームを受信します。
オーディオ ソースは、Unified CM クラスタ内の すべての MoH サーバ間で共有されるため、各オーディオ ソース ファイルはクラスタ内の各 MoH サーバにアップロードしておく必要があります。クラスタごとに最大 500 の固有オーディオ ソースを設定できます。
マルチキャスト ストリームに使用するこれらのオーディオ ソースには、[マルチキャスティングを許可(Allow Multicasting)] を必ず有効にしてください。
管理者は、1 つの Unified CM クラスタでユニキャストとマルチキャスト両方の MoH ストリームを処理するように設定できます。この設定が必要なのは、マルチキャストをサポートしないデバイス、またはエンドポイントがテレフォニー ネットワークに含まれている場合、あるいはネットワークの一部でマルチキャストが使用可能になっていない場合です。
クラスタがユニキャストとマルチキャストの両方の MoH オーディオ ストリームをサポートできるようにするには、次のいずれかの方法を使用してください。
どちらの場合も、少なくとも 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 サーバを別々に配置すると、クラスタ内に必要なサーバの数が明らかに増えます。
時間に依存する重要なリアルタイム アプリケーション(音声など)に遅延または損失がないように、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 が適切に設定されている限り、他のすべてのコール シグナリングと同様、ネットワーク内で、このコール シグナリング トラフィックは、適切に分類されキューに入れられます。
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)。
図 7-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 を推奨します。
図 7-13 ロケーションベースのコール アドミッション制御と MoH
各種 Unified Communications 呼処理配置モデルにより、MoH の構成設計にはさらに考慮事項が発生します。配置モデルの選択が、MoH のトランスポート メカニズム(ユニキャストまたはマルチキャスト)、リソースのプロビジョニング、およびコーデックの決定に影響を与える場合があります。ここでは、各種配置モデルに関連した問題について説明します。
配置モデルの詳細については、コラボレーションの配置モデルの章を参照してください。
単一サイト キャンパス配置は、通常、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 サーバのリージョンと、保留にされた電話機のリージョンとの間で使用するコーデックとして設定されているためです。
PSTN アクセス用の単一のゲートウェイまたはゲートウェイ セットによる集中型 PSTN 展開では、500 を超える固有オーディオ ソースを設定する方法はありません。ゲートウェイに割り当てられたメディア リソース グループ リスト(MRGL)は、PSTN 発信者が保留されるときに MoH ストリーミングで使用される MoH サーバを判別し、コールを保留中にしている電話機はオーディオ ソースを判別します。集中型 PSTN 配置では、PSTN ゲートウェイがローカル サイトにないため、支社ロケーションに基づいて複数の MoH サーバを指すように MRGL を使用することはできません。そのためこのケースでは、最大 500 の支社サイトの固有 MoH ソースを有効にするために、最大 500 の一意のサイト固有の MoH ソースまたはマルチキャスト ストリーミングがあります。
次の例は、MOH ストリーミングが最大 500 のロケーションでどのように機能するかを示します。
1 ~ 500 の支社の場合、MOH サーバ ノード MoH_1(239.1.1.1 の基本のマルチキャスト アドレスを使用)を指している MRGL で集中型 PSTN ゲートウェイまたはゲートウェイのセットが設定されます。各支社のすべての電話機が、クラスタに設定された 500 のオーディオ ソースの 1 つを指します。そのため、支社 1 の電話機は MoH_1 サーバが 239.1.1.1 ~ 4 のオーディオ ソース 1 を指します(コーデックに応じて、そしてオーディオ ソースが順に設定されていることを想定して)。支社 2 の電話機は MoH_1 サーバが 239.1.1.5 ~ 8 のオーディオ ソース 2 を指し、支社 3 の電話機は MoH_1 サーバが 239.1.1.9 ~ 12 のオーディオ ソース 3 を指します。そして最後に、支社 500 の電話機は MoH_1 サーバが 239.1.8.197 ~ 200 のオーディオ ソース 501 を指します。
Cisco Unified Survivable Remote Site Telephony(SRST)機能を使用して配置された支社ルータは、支社の SRST ルータのフラッシュ、またはアナログ ポートに接続されているライブ フィードからの MoH ストリーミングを使用して、リモート サイトや支社サイトでマルチキャスト MoH を提供できます。これらの 2 つの方式によって支社のルータから MoH をマルチキャストすると、Unified CM 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 または E-SRST ルータは、マルチキャスト MoH をすべてのローカル Cisco Unified Communications デバイスに流すことができます。これを実現するには、支社ルータ上で設定された内容と同じマルチキャスト IP アドレスとポート番号をもつオーディオ ソースを使用して、Unified CM MoH サーバを設定する必要があります。ブランチ ルータで使用されるオーディオ ソースのマルチキャスト IP アドレスとポート番号は、集中型 Unified CM MoH サーバのオーディオ ソース ファイルまたは固定オーディオ ソースのマルチキャスト アドレスとポート番号に対応できます。このシナリオでは、マルチキャスト MoH オーディオ ストリームが、常に SRST または E-SRST ルータから発信されるので、中央サイトの MoH サーバのオーディオ ソースが WAN を通過する必要はありません。
中央サイトのオーディオ ストリームが WAN を通過しないようにするには、次のいずれかの方法を使用してください。
中央サイトの MoH オーディオ ソースが、中央サイトの LAN より先に流れないように、最大ホップ カウントまたは TTL を十分に小さく設定します。
中央サイトの WAN インターフェイス上で ACL を設定して、マルチキャスト グループ アドレス宛のパケットがインターフェイスから発信されないようにします。
WAN インターフェイス上ではマルチキャスト ルーティングを設定しないでください。設定しなければ、マルチキャスト ストリームが WAN に転送されないことが保証されます。
図 7-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 オーディオ ストリームを受信します。
図 7-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 を受信します。
フォールバック モード中(WAN がダウンしていて SRST がアクティブな場合)、支社の SRST ルータはシャーシ内のすべてのアナログ ポートとデジタル ポートに、マルチキャスト MoH を流すことができます。これによりアナログ電話機および PSTN 電話機に MoH を流すことができます。
支社のルータに対して、フォールバック モードのマルチキャスト MoH を設定する方法は、通常の設定方法と同じです。ただし、ルータに対して設定するマルチキャスト アドレスは、目的の動作によって異なります。支社のルータから、デバイスにマルチキャスト MoH をフォールバック モードでのみ流す必要がある場合(たとえば、リモート デバイスで受信する MoH が非フォールバック モード中に中央サイトの MoH サーバから発信される場合)、SRST ルータに設定したマルチキャスト アドレスとポート番号が、中央サイトの MoH サーバのいずれのオーディオ ソースと重複しないようにする必要があります。重複していると、リモート デバイスは、設定されているユーザ/ネットワーク保留オーディオ ソースに応じて、ローカル ルータのフラッシュから MoH を継続的に受信することがあります。
支社の SRST/ゲートウェイ ルータに、マルチキャスト MoH を設定すると、ルータはフォールバック モードでないときにも、MoH ストリームのマルチキャストを継続することに注意してください。
フォールバック モードを設定して、拡張 SRST(E-SRST)と呼ばれる SRST モードで Cisco Unified Communications Manager Express(Unified CME)を使用することもできます。フォールバック モードの動作は同じですが、コンフィギュレーション コマンドが多少異なります。SRST コマンドは、Cisco IOS call-manager-fallback コンストラクトで入力しますが、E-SRST モードでは、コマンドは telephony-service で入力します。
SRST を介して MoH をマルチキャストする方法は 4 つあります。
Cisco Unified SRST と E-SRST の設定方法については、次のマニュアルを参照してください。
https://www.cisco.com/en/US/products/sw/voicesw/ps2169/products_installation_and_configuration_guides_list.html
https://www.cisco.com/en/US/products/sw/voicesw/ps4625/products_installation_and_configuration_guides_list.html
https://www.cisco.com/en/US/products/sw/voicesw/ps2169/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 サイトで入手可能なマニュアルを参照してください。
https://www.cisco.com/en/US/products/ps6552/products_ios_technology_home.html
分散型クラスタ間環境では、適切なマルチキャスト アドレス管理も、設計上の重要な考慮事項です。分散型ネットワーク全体で流れるリソースの重複を防止するために、いかなる MoH オーディオ ソース マルチキャスト アドレスも、配置内のすべての Unified CM クラスタに対して一意でなければなりません。
その名前が示すように、クラスタオーバー 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 リソースを指定しておく必要があります。