Cisco Collaboration システム 10.x ソリューション リファレンス ネットワーク デザイン(SRND)
メディア リソース
メディア リソース
発行日;2014/04/25 | 英語版ドキュメント(2013/11/23 版) | ドキュメントご利用ガイド | ダウンロード ; この章pdf , ドキュメント全体pdf (PDF - 27MB) | フィードバック

目次

メディア リソース

この章の新規情報

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

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

Cisco IP Voice Media Streaming Application

音声インターフェイス

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

フレックス モード

トランスコーディング

オーディオ変換リソース

ビデオの相互運用性

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

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

DTMF 変換

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

SIP トランク経由のコール

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

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

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

H.323 付加サービス

H.323 発信時の Fast Connect

DTMF 変換

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

CTI ルート ポイント

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

MTP リソース

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

アナンシエータ

Cisco RSVP Agent

保留音(Music on Hold)

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

MoH 選択プロセス

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

MoH ソース

オーディオ ファイル

固定ソース

MoH の選択

MoH コール フロー

SCCP コール フロー

SIP コール フロー

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

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

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

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

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

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

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

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

トランスコーダのハイ アベイラビリティ

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

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

配置モデル

単一サイト配置

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

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

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

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

コーデックの選択

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

MoH オーディオ ソース

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

Quality of Service(QoS)

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

保留音の配置モデル

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

集中型マルチサイト配置

分散型マルチサイト配置

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

メディア リソース

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

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

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

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

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

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

「アナンシエータ」

「Cisco RSVP Agent」

「保留音(Music on Hold)」

この章を使用して、Unified CM で使用可能な各メディア リソース タイプの機能を理解し、配置に必要なリソースを確認してください。会議リソースの詳細については、「Cisco Rich Media Conferencing」の章を参照してください。

Cisco Integrated Service Router(ISR)ゲートウェイの適切な DSP のサイジングを行うために、Cisco Unified Communications Sizing Tool(Unified CST)を使用できます。このツールはシスコの従業員およびシスコ パートナーが http://tools.cisco.com/cucst から入手できます。シスコ パートナーまたはシスコの従業員でない場合は、 http://www.cisco.com/go/dspcalculator から DSP Calculator を使用できます。

この章の新規情報

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

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

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

SIP トランク経由のコール

「SIP トランク経由のコール」

2013 年 11 月 19 日

保留音(MoH)オーディオ ソース

「保留音(Music on Hold)」

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

「ブランチ ルータからのマルチキャスト MoH」

2013 年 11 月 19 日

拡張 SRST(E-SRST)

「フォールバック モード」

2013 年 11 月 19 日

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

メディア リソース割り当て方針を適切に策定するには、さまざまなメディア リソースコンポーネントの 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 メッセージを示しているわけではありません。

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

 

Cisco IP Voice Media Streaming Application

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

会議ブリッジ

保留音(MoH)

アナンシエータ

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

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

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

複数のリソースが必要になる状況や、それらのリソースによって IP Voice Media Streaming Application にかかる負荷を慎重に検討してください。メディア リソースは、Unified CM と同じサーバ、または Unified CM 呼処理サービスを実行していない専用サーバを設置することができます。デフォルト数よりも多いリソースが必要な場合は、専用のサーバで実行するように設定することを推奨します。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 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.711 だけをサポートしているか、または G.711 だけを使用するように設定されている場合

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

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

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

オーディオ変換リソース

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

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

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

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


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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ビデオの相互運用性

ビデオの相互運用性とは、Cisco TelePresence System(CTS)エンドポイント、他の Cisco Unified Communications ビデオ エンドポイント、およびサードパーティ製ビデオ エンドポイント間でポイントツーポイント コールの音声とビデオをサポートすることです。Cisco Unified CM 8.5 よりも前のリリースでは、さまざまなビデオ エンドポイント間におけるビデオの相互運用性は、ビデオ トランスコーダやマルチポイント コントロール ユニット(MCU)などのビデオ コンポーネントをエンドポイントの間に挿入した場合にのみ実現できました。

Cisco Unified CM 8.5 以降のリリースでは、さまざまなタイプのエンドポイント間(ポイントツーポイント)のネイティブなビデオの相互運用性が提供されるだけでなく、SIP および H.323 プロトコルでの H.264 コーデック ネゴシエーションに関してビデオの相互運用性が全体的に向上し、利用可能な場合は高品位(HD)解像度でネゴシエートできるようになりました。ただし、ビデオの相互運用性は相互運用をサポートするエンドポイントによって異なります。詳細については、次の Web サイトで入手可能な『 Interoperability Between CTS Endpoints and Other Cisco Endpoints or Devices 』を参照してください。

http://www.cisco.com/en/US/docs/telepresence/interop/endpoint_interop.html

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

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

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

「DTMF 変換」

プロトコル固有の用途

「SIP トランク経由のコール」

「H.323 付加サービス」

「H.323 発信時の Fast Connect」

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

MTP は、G.711 a-law 音声パケットから G.711 mu-law パケット(およびその逆)にトランスコードしたり、パケット化周期が異なる(使用するサンプル サイズが異なる)2 つの接続をブリッジしたりできます。再パケット化するには、Cisco IOS MTP に DSP リソースが必要です。したがって、再パケット化は Cisco Unified CM IP Voice Media Streaming(IPVMS)アプリケーションのソフトウェア MTP でサポートされません。

DTMF 変換

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

MTP の挿入が必要であると判断された場合に使用可能な MTP リソースがないとき、Unified CM はサービス パラメータ [Fail call if MTP allocation fails] の設定に従って、そのコールを続行するかどうかを決定します。このサービス パラメータは、「False」のデフォルト値に設定されています。このデフォルト設定では、SIP アーリー オファー トランクの着信コールは、発信側でディレイド オファーになります。

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

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

Named Telephony Event(RFC 2833)

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

Key Press Markup Language(RFC 4730)

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

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

Unsolicited Notify(UN)

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

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

H.245 Signal、H.245 Alphanumeric

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

シスコ独自の RTP

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

Skinny Client Control Protocol(SCCP)

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

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

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

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

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

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

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

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

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

SIP トランク経由のコール

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

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

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

Media Termination Point Required

SIP トランク上でこのオプションをオンにすると、すべての発信コールに対して 1 つの MTP が割り当てられます。このオプションは、パススルー モードのコーデックをサポートせず、この SIP トランクでは単一のコーデック(G.711 または G.729)に制限されるので、メディアを音声コールのみに制限します。このオプションが有効な場合、トランクを介したコールは、発信デバイスに割り当てられた MTP ではなく、このトランクに割り当てられた MTP を使用するので、メディアはシグナリングと同じ経路を流れます。


) SIP トランク上で [Media Termination Point Required] オプションをオンにすると、MTP 使用率が上がります。必要に応じてではなく、すべての着信コールおよび発信コールに対して MTP が割り当てられるためです。


Early Offer support for voice and video calls (insert MTP if needed)

SIP トランクに関連付けられた SIP プロファイルでこの Unified CM 設定オプションをオンにすると、MTP が挿入されるのは、発信デバイスが発信アーリー オファーの作成に必要なメディア特性を Unified CM に提示できない場合のみです(たとえば、Unified CM への着信コールがディレイド オファー SIP トランクまたは H.323 Slow Start トランクで受信される場合、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 プロファイルに [Early Offer support for voice and video calls (insert MTP if needed)] を設定した場合、古い SCCP ベースの電話機、SIP ディレイド オファー トランク、および H.323 Slow Start トランクからのコールは、すでに別の理由で MTP またはトランスコーダが割り当てられていなければ、Unified CM によって MTP が割り当てられます。この MTP を使用して、有効なメディア ポート番号と IP アドレスを含むオファー SDP が生成されます。この MTP は、発信 SIP トランクのメディア リソースからではなく、発信デバイスに関連付けられているメディア リソースから割り当てられます。(したがって、メディア パスは、発信 SIP トランクの MTP に固定されません)。MTP を発信デバイスのメディア リソース グループ リスト(MRGL)から割り当てできない場合は、MTP の割り当てを SIP トランクの MRGL から試みます。

通常、[Early Offer support for voice and video calls (insert MTP if needed)] 設定オプションは MTP の使用を抑えるため、このオプションの使用を推奨します。


) MTP リソースを使用できない場合、コールは、ディレイド オファー コールとして処理されます。


Unified CM は、次のいずれかの手段で着信コールを受信する場合は、SIP トランク上で発信アーリー オファー コールを作成するために MTP を挿入する必要はありません。

アーリー オファーを使用する SIP トランク上

Fast Start を使用する H.323 トランク上

MGCP トランク上

Unified CM に登録されている SIP ベースの IP フォンから

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

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

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

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

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

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

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

a. DTMF Signaling Method:No Preference

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

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

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

b. DTMF Signaling Method:RFC 2833

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

c. DTMF Signaling Method:OOB and RFC 2833

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


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


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

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

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

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

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

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

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

「H.323 付加サービス」

「H.323 発信時の Fast Connect」

「DTMF 変換」

H.323 付加サービス

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

H.323 発信時の Fast Connect

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

DTMF 変換

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

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

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

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

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

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

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

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

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

CTI ルート ポイント

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

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

例 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 がメディア ストリームに割り込まされ、1 つのコールレグで SCCP を使用し、2 番目のコール レグで NTE を使用します。MTP は Unified CM によって SCCP 制御下に置かれ、NTE から SCCP への変換を実行します。KPML をサポートしている新しい電話機では、MTP は必要ありません。

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

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

MTP リソース

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

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

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

ソフトウェア MTP(Cisco IOS ベース)

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

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

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

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

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

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

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

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

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


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


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

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

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

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

アナンシエータ

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

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

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

Cisco Multilevel Precedence Preemption(MLPP)

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

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

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

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

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

SIP トランクを介した統合

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

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

DTMF トーン

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

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

システム メッセージ

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

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

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

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

会議

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

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

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

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

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

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

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

Cisco RSVP Agent

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

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

保留音(Music on Hold)

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

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

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

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

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

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

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

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

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

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

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

MoH 選択プロセス

この項では、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 を使用するように設定する必要があります。

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

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

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

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

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

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

 

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

コール転送

コール パーク

会議セットアップ

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

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

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

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

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

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

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

 

MoH ソース

Unified CM MoH サーバでは、2 つのタイプのソースから MoH ストリームを生成できます。

Unified CM MoH サーバまたは Cisco IOS ルータ フラッシュからのオーディオ ファイル

マルチキャストをサポートする Cisco IOS ルータまたはサードパーティのデバイス サポートからのライブ固定オーディオ ソース

Unified CM クラスタごとに最大で 51 個の MoH オーディオ ソースを設定できます。そのうち 1 個を Cisco IOS ルータからストリームされた固定ライブ ソースまたはオーディオ ファイル マルチキャストにできます。MoH サーバは、IPv6 アドレスを使用して Unified CM クラスタに登録できます。

オーディオ ファイル

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


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


固定ソース

録音されたオーディオまたはライブ オーディオが必要な場合、Cisco IOS ルータのアナログ インターフェイスに接続されている固定ライブ ソース、またはマルチキャストをサポートするサードパーティ デバイスからマルチキャスト MoH を生成できます。


) Unified CM ノードが仮想化される際の MoH 用の USB ポートがサポートされていないため、Cisco Unified CM は、MOH サーバへの固定ライブ オーディオ ソース接続用 USB サウンド カードをサポートしなくなりました。


このメカニズムにより、ラジオ、CD プレーヤー、または互換性があるその他のサウンド ソースを使用して、マルチキャスト MoH をストリーミングできます。固定オーディオ ソースからのストリームは、Cisco IOS ルータによってリアルタイムにトランスコードされます。


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


Cisco IOS ルータからのライブ MoH の詳細については、次の Web サイトで入手可能な最新版の『 Cisco Unified SCCP and SIP SRST System Administrator Guide 』の「 MoH from a Live Feed 」の項を参照してください。

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

MoH の選択

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

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

2. デバイス設定値

3. 共通のデバイス設定

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

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

1. デバイス設定値

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

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

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

MoH コール フロー

次の各項では、SCCP および SIP エンドポイントの両方について、ユニキャストとマルチキャスト MoH コール フローの詳細な図と説明を示します。次に示すすべてのコール フローは、Unified CM MOH サーバの MoH ストリーミングを示しています。Cisco IOS ルータからのマルチキャスト MoH のストリーミングは示されていませんが、これらのマルチキャスト シナリオのコール フローは通常、Unified CM MoH サーバのマルチキャスト コール フローと同じです。

SCCP コール フロー

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

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

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

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

 

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


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


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

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

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

 

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

SIP コール フロー

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

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

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

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

 

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

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

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


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


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

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

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

共存配置

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

スタンドアロン配置

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

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

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

サポート対象のサーバ プラットフォームの詳細については、次の Web サイトで入手可能なマニュアルを参照してください。

http://docwiki.cisco.com/wiki/UC_Virtualization_Supported_Hardware

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

Maximum Half Duplex Streams

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

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

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

次に、例を示します。

10K OVA を使用した Cisco Unified Computing System(UCS)スタンドアロン MOH サーバ
マルチキャスト MoH オーディオ ソース
有効な MoH コーデック(G.711 mu-law と G.729)
Maximum Half Duplex Streams

1,000

- (12

∗ 2)

= 976

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

Maximum Multicast Connections

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

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


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


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

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


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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

MRG 内に同じタイプのリソースを提供するデバイスが複数存在する場合、そのリソースを割り当てるアルゴリズムによって、これらすべてのデバイス間でロード バランシングが行われます。Cisco Unified CM は、MTP とトランスコーダ リソースの負荷分散するために、[MTP and Transcoder Resource Throttling Percentage] サービス パラメータを適用してスロットリング メカニズムを使用します。このサービス パラメータは、設定されている MTP とトランスコーダ リソースの割合を定義します。MTP またはトランスコード リソースのうちアクティブなリソースの数が、このサービス パラメータの設定値以上になった場合、Cisco Unified CM は当該リソースにそれ以上コール処理をさせずに、コーデック条件が一致するその他のリソースを、MRGL(デフォルト MRG を含む)から一旦探します。Cisco Unified CM がコーデック条件の一致する使用可能なリソースを見つけられない場合、MRGL の最上位からリソース検索を繰り返しますが、その場合はスロットル状態のリソースや、条件に満たない能力のリソースも対象に含まれます。そのようなリソースが利用可能な場合、Cisco Unified CM は、コールの条件に最適に一致するリソースにコールを接続します。コールは、Cisco Unified CM がコールのリソースを割り当てることができない場合に失敗します。

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

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

MRG を使用して、同様のタイプのリソースをグループ化することもできます。上記の例で説明したように、トランスコーダがより高価なリソースであるため、シスコでは、トランスコーダおよび MTP を別の MRG にグループ化し、適切な順序で MRGL に MRG を追加して、正しいリソースを呼び出すことを推奨します。

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

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

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

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

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

トランスコーダのハイ アベイラビリティ

次のトランスコーダのフェールオーバー プロセスは、デバイスが登録されている 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-10 を参照)。

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

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

 

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

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

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

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

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

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

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

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

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

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

 

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

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

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

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

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

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

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

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

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

コーデックの選択

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


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


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

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

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

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

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

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

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

MoH オーディオ ソース

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

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

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

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

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

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

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

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

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

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


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


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

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

Quality of Service(QoS)

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

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

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

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

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

図 7-12 は、集中型マルチサイト配置におけるコール アドミッション制御と 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-12 ロケーションベースのコール アドミッション制御と 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 サーバのリージョンと、保留にされた電話機のリージョンとの間で使用するコーデックとして設定されているためです。

ブランチ ルータからのマルチキャスト MoH

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 インターフェイス上で ACL を設定して、マルチキャスト グループ アドレス宛のパケットがインターフェイスから発信されないようにします。

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

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

図 7-13 は、フォールバック モードでないときに支社のルータからマルチキャスト 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-13 ブランチ ルータからのマルチキャスト MoH

 

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

マルチキャスト MoH を流すように設定された複数のブランチ ルータを含むネットワークでは、Unified CM クラスタ内に 51 を超える固有 MoH オーディオ ソースを含めることができます。支社サイトの各ルータは、固有オーディオ ソースをマルチキャストすることができます。ただし、すべてのルータが同じマルチキャスト グループ アドレス上でこのオーディオをマルチキャストする必要があります。ゲートウェイに割り当てられたメディア リソース グループ リスト(MRGL)は、PSTN 発信者が保留されるときに MoH ストリーミングで使用される MoH サーバを判別し、コールを保留中にしている電話機はオーディオ ソースを判別します。51 以上のロケーションがある場合、十分な MoH サーバと 51 以上のマルチキャスト アドレスを指定して、51 以上の固有 MoH ストリームを提供できます。

次の例は、MOH ストリーミングが 51 以上のローカル ブランチのゲートウェイでどのようにする機能するかを示します。

1 ~ 51 の支社の場合、MOH サーバ ノード MoH_1(239.1.1.1 の基本のマルチキャスト アドレスを使用)を指している MRGL がゲートウェイに割り当てられます。各支社のすべての電話機が、クラスタに設定された 51 のオーディオ ソースの 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 を指します。そして最後に、支社 51 の電話機は MoH_1 サーバに設定される 239.1.1.201 ~ 204 のオーディオ ソース 51 を指します。

52~102 の支社の場合、MOH サーバ ノード MoH_2(239.2.1.1 の基本のマルチキャスト アドレスを使用)を指している MRGL でゲートウェイが設定されます。各支社のすべての電話機が、クラスタに設定された同じ 51 のオーディオ ソースの 1 つを指します。ただしこの場合は、支社 52 の電話機は MoH_2 サーバが 239.2.1.1 ~ 4 のオーディオ ソース 1 を指します(コーデックに応じて、そしてオーディオ ソースが順に設定されていることを想定して)。支社 53 の電話機は MoH_2 サーバが 239.2.1.5 ~ 8 のオーディオ ソース 2 を指し、支社 54 の電話機は MoH_2 サーバが 239.2.1.9 ~ 12 のオーディオ ソース 3 を指します。そして最後に、支社 102 の電話機は MoH_2 サーバが 239.2.1.201 ~ 204 のオーディオ ソース 51 を指します。

ただし、PSTN アクセス用のゲートウェイをセンターサイトに集中配置する集中型 PSTN 展開では、51 を超える固有オーディオ ソースを設定する方法はありません。集中型 PSTN 配置では、PSTN ゲートウェイがローカル サイトにないため、支社ロケーションに基づいて複数の MoH サーバを指すように MRGL を使用することはできません。そのためこのケースでは、最大 51 の支社サイトの固有 MoH ソースを有効にするために、最大 51 の一意のサイト固有の 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 つあります。

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

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

ブランチ ルータのフラッシュからのマルチキャスト MoH による E-SRST モード

ライブ フィードからのマルチキャスト MoH による E-SRST モード

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

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

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

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

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

マルチキャスト MOH リソースとして Cisco Unified SRST を使用する場合の詳細については、次の Web サイトで入手可能な最新版の『 Cisco Unified SCCP and SIP SRST System Administrator Guide 』の「 Integrating Cisco Unified Communications Manager and Cisco Unified SRST to Use Cisco Unified SRST as a Multicast MoH Resource 」の項を参照してください。

http://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 サイトで入手可能なマニュアルを参照してください。

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

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

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

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

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