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

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

モジュールでサポートできるコール数を確認するには、 表6-2 ～ 表6-6 でモジュールを見つけ、モジュールに搭載できる DSP の個数と、必要なコーデック タイプを確認します。たとえば、フレックス モードに設定された 3 つの C2510 DSP を持つ NM-HD-2VE モジュールは、DSP ごとに 8 つの G.729 コールをサポートできます。合計すると、フレックス モードと G.729 コーデックを使用して 24 コールをサポートできます。フレックス モードで G.711 コーデックを使用する場合は、同じハードウェアで 48 コールをサポートできます。

表6-1 に示されているように、コーデックが中複雑度モードでサポートされている場合、そのコーデックは高複雑度モードでもサポートされます。ただし、サポートされるコール数は減少します。

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

サポートされているコールの最大数を確認するには、目的のハードウェアを含む 表6-2 ～ 表6-6 で該当する行を見つけます。 表6-1 で、中複雑度と高複雑度の列を調べて、目的のコーデックを処理できる複雑度モードを確認します。次に、目的の複雑度モードの列で、DSP ごとにサポートされているコールの最大数を確認します。

フレックス モード

フレックス モードは、C5510 チップセットを使用するハードウェア プラットフォーム上のみで使用可能で、このモードでは、設定時にコーデックの複雑度を指定する必要がありません。フレックス モードの DSP は、処理能力が足りる限り、サポートされているすべてのコーデック タイプのコールを受け入れます。各コールのオーバーヘッドは、Millions of Instructions Per Second（MIPS）単位の処理能力を計算することで動的にトラッキングされます。Cisco IOS は、受信されたコールごとに MIPS の計算を実行し、新しいコールが開始されるたびにそのバジェットから MIPS クレジットを差し引きます。 表6-1 の Flex Mode 列に示されているように、1 つのコールによって消費される MIPS 数は、コールのコーデックによって異なります。着信コールに必要な MIPS 以上の MIPS クレジットが残っている限り、DSP は新しいコールを許可します。 表6-1 の Flex Mode 列は、サポートされているコーデックをコールごとの MIPS 数別に分類し（コールごとに 15、30、または 40 MIPS）、各種ハードウェアに使用可能な MIPS バジェットを示しています。

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

たとえば、各 DSP のバジェットは 240 MIPS となり、バジェットの合計は NM-HD-2VE モジュールごとに 720 MIPS となります。NM-HDV2 モジュールの場合、DSP ごとのバジェットは同じく 240 MIPS ですが、使用可能な MIPS の合計数については、選択項目や PVDM の数によって異なるため、 表6-2 で確認してください。

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

音声インターフェイスの DSP リソース

表6-2 ～ 表6-6 は、DSP チップセット別に分類されており、DSP サポートに関する情報を、プラットフォーム、DSP 密度、および DSP ごとにサポートされる音声インターフェイス（またはコール）の数別に示しています。 表6-1 は、ハードウェア モジュールでサポートされるコーデックを複雑度モードごとに示しています。

C5510 チップセットをベースとするハードウェアは、中複雑度モードと高複雑度モードのほか、フレックス モードをサポートします（ 表6-2 を参照）。

C5421 チップセットをベースとするハードウェアでは、DSP が中複雑度または高複雑度として設定されている場合があります。 表6-3 は、DSP ごとのコール密度を、 表6-1 は、複雑度モードごとにサポートされるコーデックを示しています。

C549 チップセットをベースとするハードウェアでは、DSP が中複雑度または高複雑度として設定されている場合があります。 表6-4 は、DSP ごとのコール密度を、 表6-1 は、複雑度モードごとにサポートされるコーデックを示しています。

C542 チップセットをベースとするハードウェアは、次のコーデックをサポートします。

• G.711（a-law、mu-law）

• FAX/モデム パススルー

• クリア チャネル

• G.726（32K、24K、16K）

• GSM-FR

• FAX リレー

• G.729

• G.729（a、b、ab）

• G.728

• G.723.1（32K、24K、16K）

• G.723.1a（5.3K、6.3K）

• GSM-EFR

• モデム リレー

表6-5 は、DSP ごとのコール密度を示しています。

表6-6 は、DSP リソースに対応する非 IOS ハードウェアを示しています。すべての非 IOS ハードウェア プラットフォームでは、DSP 構成が固定されています（ 表6-6 を参照）。

オーディオ会議のリソース

ハードウェア コンファレンス ブリッジは、ソフトウェア コンファレンス ブリッジのすべての機能を備えています。さらに、一部のハードウェア コンファレンス ブリッジは、G.729、GSM、G.723 などの複数の低ビット レート（LBR）ストリーム タイプをサポートできます。この機能により、一部のハードウェア コンファレンス ブリッジが混合モードの会議を処理できるようになります。混合モードの会議では、ハードウェア コンファレンス ブリッジは、G.729、GSM、および G.723 のストリームを G.711 ストリームにトランスコードし、混合します。その後、混合したストリームを、ユーザに戻すために適切なストリーム タイプにエンコードします。一部のハードウェア コンファレンス ブリッジは、G.711 会議しかサポートしません。

Cisco Unified CallManager の制御下にあるすべてのコンファレンス ブリッジは、Cisco Unified CallManager との通信に Skinny Client Control Protocol（SCCP）を使用します。

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

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

Cisco Unified CallManager システムでは、次のタイプのコンファレンス ブリッジ リソースが使用されます。

• 「ソフトウェア オーディオ コンファレンス ブリッジ（Cisco IP Voice Media Streaming Application）」

• 「ハードウェア オーディオ コンファレンス ブリッジ（Cisco NM-HDV2、NM-HD-1V/2V/2VE、2800 シリーズおよび 3800 シリーズ ルータ）」

• 「ハードウェア オーディオ コンファレンス ブリッジ（Cisco WS-SVC-CMM-ACT）」

• 「ハードウェア オーディオ コンファレンス ブリッジ（Cisco NM-HDV および 1700 シリーズ ルータ）」

• 「ハードウェア オーディオ コンファレンス ブリッジ（Cisco Catalyst WS-X6608-T1 および WS-X6608-E1）」

• 「組み込み会議」

ソフトウェア オーディオ コンファレンス ブリッジ（Cisco IP Voice Media Streaming Application）

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

ハードウェア オーディオ コンファレンス ブリッジ（Cisco NM-HDV2、NM-HD-1V/2V/2VE、2800 シリーズおよび 3800 シリーズ ルータ）

Cisco IOS で会議リソースとして設定されている DSP は、会議機能のみに特化した DSP にファームウェアをロードします。このような DSP は、他のメディア機能には使用できません。

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

• C5510 DSP チップセットに基づき、NM-HDV2 およびルータ シャーシは PVDM2 モジュールを使用して DSP を提供します。

• PVDM2 ハードウェアの DSP は、音声インターフェイス、会議、メディア ターミネーション、またはトランスコーディングとして個別に設定されます。そのため、1 つの PVDM の複数の DSP を異なるリソース タイプとして使用できます。DSP は、まず音声インターフェイスに割り当ててから、必要に応じて他の機能に割り当ててください。

• NM-HDV2 には、任意の組み合せで PVDM2 モジュールを取り付け可能な 4 つのスロットがあります。その他のネットワーク モジュールの DSP 数は固定されています。

• これらの DSP に基づく会議には、最大 8 人が参加できます。会議が始まるときに、8 つのポジションのすべてが予約されます。

• PVDM2-8 には、PVDM2-16 と比較して処理キャパシティが半分の DSP があるため、½ DSP と表示されています。たとえば、PVDM2-8 の DSP が G.711 用に設定されている場合、(0.5 ∗ 8) ブリッジ/DSP = 4 コンファレンス ブリッジを提供できます。

• 表6-1 および 表6-2 を使用して、特定のハードウェアでプロビジョニングできる DSP の数を判断してください。

• Cisco IOS の DSP ファーム設定によって、ファームで受け付けることができるコーデックを指定します。会議および G.711 用に設定されている DSP ファームは、8 つの会議を提供します。G.711 コールと G.729 コールの両方を受け付けるように設定されている場合、ストリームのトランスコーディングの実行用にリソースが予約されるため、1 つの DSP で 2 つの会議が提供されます。

• NM-HDV2 の I/O は 400 ストリームに制限されています。そのため、割り当てられている会議リソースの数がこの制限を超えないように注意してください。G.711 会議が設定されている場合、（48 ∼ 8）参加者 = 384 ストリームになるため、1 つの NM に割り当てることができる DSP は 48 までです。すべての会議を G.711 コーデックと G.729 コーデックの両方に設定した場合、各 DSP は、参加者がそれぞれ 8 人の会議を 2 つだけ提供します。この場合、NM がフル装備され、16 の DSP が設定されると、256 ストリームが可能になります。

• 会議は、GSM コーデックを利用したコールをネイティブに受け付けることはできません。これらのコールが会議に参加するには、個別にトランスコーダが必要です。

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

ハードウェア オーディオ コンファレンス ブリッジ（Cisco WS-SVC-CMM-ACT）

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

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

• この Cisco Catalyst ベースのハードウェアには、ブリッジごとに 32 人まで参加できるコンファレンス ブリッジを提供できる DSP リソースが用意されています。

• 各モジュールには、個別に設定可能な 4 つの DSP が含まれています。各 DSP は、32 のコンファレンス ブリッジをサポートします。

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

ハードウェア オーディオ コンファレンス ブリッジ（Cisco NM-HDV および 1700 シリーズ ルータ）

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

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

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

• リソースは DSP ごとにコンファレンス ブリッジとして設定されます。

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

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

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

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

ハードウェア オーディオ コンファレンス ブリッジ（Cisco Catalyst WS-X6608-T1 および WS-X6608-E1）

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

• このハードウェアには、物理的にそれぞれのポートに関連付けられた 8 つの DSP があり、カードごとに 8 つのポートがあります。DSP の設定はポート レベルで行われるため、1 つのポートに関連付けられているすべての DSP が同じ機能を実行します。

• コンファレンス ブリッジには最大 32 人が参加でき、各ポートが 32 のコンファレンス ブリッジをサポートします。

• G.711 または G.723 の会議では、ポートごとに 32 の会議が可能です。G.729 コールを使用する場合は、ポートごとに 24 の会議が可能です。

組み込み会議

一部の電話機モデルには、3 方向の会議を可能にする組み込み会議リソースが用意されています。このブリッジは、割り込み機能によってのみ呼び出され、通常の会議リソースとしては使用されません。このブリッジが用意されている電話機の詳細については、「IP テレフォニー エンドポイント」を参照してください。このブリッジは、G.711 コールのみを受け付けます。

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

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

ハードウェア トランスコーダ（Cisco NM-HDV2、NM-HD-1V/2V/2VE、2800、および 3800 シリーズ ルータ）

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

• トランスコーディングは、G.711 mu-law または a-law と G.729a または G.729ab との間で使用できます。1 つの DSP で 8 セッションをサポートできます。

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

• トランスコーディングは、G.711mu-law/G.711a-law と G.729/G729b との間でも使用できますが、通常、Cisco Unified CallManager システムでは使用されません。1 つの DSP で 6 セッションをサポートできます。

• 特定のプラットフォームまたはネットワーク モジュールで使用できる DSP の数を確認するには、「音声インターフェイスの DSP リソース」の項を参照してください。

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

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

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

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

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

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

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

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

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

• 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、または GSM コーデックへのトランスコーディングがサポートされます。

• 1 つの DSP で 2 つのトランスコーディング セッションを提供できます。

• Cisco 1751 のシャーシは 16 セッションに制限されています。Cisco 1760 のシャーシは 20 セッションに制限されています。

ハードウェア トランスコーダ（Cisco WS-X6608）

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

• DSP はポート レベルで機能に割り当てられます。1 つのポートで 24 のトランスコーディング セッションを提供できます。

• ブレードごとに 8 つのポートがあります。

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

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

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

MTP は、a-law から mu-law（およびその逆）にトランスコードしたり、パケット化にかかる時間が異なる（使用するサンプル サイズが異なる）2 つの接続をブリッジしたりすることができます。

H.323 補足サービス

MTP は、補足サービスに使用され、Empty Capabilities Set（ECS）機能を使用している H.323v2 の OpenLogicalChannel および CloseLogicalChannel 要求機能をサポートしていない H.323 エンドポイントの機能を拡張することができます。この要件はあまり発生しません。Cisco H.323 エンドポイント、およびほとんどのサードパーティのエンドポイントが ECS をサポートしています。必要に応じて、MTP が割り当てられ、H.323 エンドポイントに代わってコールに接続されます。メディア ストリームは、挿入された後、MTP と H.323 デバイス間で接続され、これらの接続は、コールの期間中、存在します。MTP のもう一方の側に接続されるメディア ストリームは、保留、転送などの機能を実行するために、必要に応じて接続されたり、接続解除されたりします。

MTP が H.323 コールで要求され、使用できるものがない場合、コールは処理されますが、補足サービスを呼び出すことはできません。

H.323 発信時の Fast Start

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

Named Telephony Event（RFC 2833）

コール中に DTMF トーンを使用して、メニュー システムのナビゲート、データの入力、またはその他の操作の目的で、遠端のデバイスに信号を送信できます。これらは、コール制御の一部としてコール セットアップ中に送信される DTMF トーンとは異なる方法で処理されます。

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

Named Telephony Event がメディア ターミネーション ポイントを必要とする条件

Cisco Unified CallManager 4.x では、SIP トランクだけがサポートされ、SIP トランクを使用するすべてのコールに MTP が割り当てられる必要があります。SIP トランクには設定パラメータ「MTP required」があります。これはデフォルトで選択されいて、変更できません。

Cisco Unified CallManager 5.0 では、回線デバイスの SIP サポートが追加され、SIP トランクを使用するすべてのコールに MTP を割り当てる必要がなくなりました。Cisco Unified CallManager 5.0 で MTP が必要になるのは、2 つのエンドポイントの間で DTMF を送信する共通の方式がない場合、またはシステム設定で MTP を割り当てるように指定した場合です。次の説明は非常に詳細に述べたものであり、Cisco Unified CallManager 5.0 だけに適用されます。

次の規則に基づいて、システムに対して計画されているエンドポイントのタイプを確認します。

1. SIP 以外のエンドポイントが 2 つの場合、MTP は必要ありません。

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

2. Cisco SIP エンドポイントが 2 つの場合、MTP は必要ありません。

すべての Cisco SIP エンドポイントは NTE をサポートするため、MTP は完全に排除できます。DTMF は NTE を使用して、エンドポイント間で直接送信されます。すべてのエンドポイントが Cisco SIP デバイスの場合、DTMF を変換する MTP は必要ありません。

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

使用するデバイスで NTE がサポートされているかどうかを確認するには、 表6-7 を参照してください。RFC 2833 は SIP に限定されていないため、その他のコール制御プロトコルを使用するデバイスでサポートされていることがあります。たとえば、SCCP または SIP スタックを実行する Cisco Unified IP Phone は、両方のモードで NTE をサポートします。一部のデバイスは、複数の方式で DTMF をサポートします（たとえば、SCCP スタックを使用する Cisco Unified IP Phone 7960 は、NTE を他のデバイスに送信することも、SCCP を Cisco Unified CallManager に送信することもできます）。Cisco Wireless IP Phone 7920 など別のデバイスは SCCP だけを送信でき、さらに別のデバイスは NTE だけを送信できます（SIP スタックを使用する Cisco Unified IP Phone 7960 など）。Cisco Unified CallManager は、エンドポイントのペアの機能に基づき、MTP をコール単位に動的に割り当てることができます。 表6-7 を使用して、MTP をプロビジョニングする必要があるかどうかを判断してください。

4. MTP の動的割り当ては、発信コールだけに適用されます。

MTP を必要としない SIP トランクは、規則 3 で説明したように動的割り当てを使用します。SIP トランクは、Invite に Session Description Protocol（SDP）を使用しているコールと使用していないコールの両方を受け付けることができるため、着信コールには MTP を割り当てません。上で説明したように、発信コールにだけ MTP が割り当てられます。特定の SIP トランクを着信コールだけに使用する場合、そのトランクのコールを受信するためにシステムの MTP リソースを割り当てる必要はありません。

5. 設定により、MTP が強制的に割り当てられることがあります。

Cisco Unified CallManager 5.0 では、SIP トランク パラメータ MTP Required がデフォルトで選択されておらず、フィールドはロック解除されています。SIP トランクが Cisco のデバイス（SIP ゲートウェイなど）用に定義されている場合、デバイスは NTE をサポートするように設定する必要があります。通常は、MTP Required のデフォルト設定を使用し、必要な場合にだけ MTP を割り当てます。

他の理由で MTP が強制的に割り当てられることもあります。コール セットアップが開始する前に MTP が割り当てられると、SIP ダイアログ確立の動作が変わります。SIP は Session Description Protocol（SDP）を使用してセッション パラメータを確立し、SDP は SIP メッセージに埋め込まれます。MTP を強制すると、コールを開始する Invite メッセージと共に SDP が送信されます。MTP が強制されない場合、Invite メッセージの後で（必要な場合）割り当てられます。SDP は Invite メッセージに含まれず、コール セットアップの後の時点で送信されます。遠端のデバイスが、SDP が埋め込まれた Invite メッセージだけをサポートする場合は、MTP Required パラメータをオン（有効）にする必要があります。

この設定パラメータによって MTP が強制割り当てされる場合は、MTP から遠端の SIP デバイスへのコール レッグで使用されるコーデックが G.711 mu-law または a-law である必要があります。MTP Required を選択するとロック解除されるトランク設定の追加パラメータがあります。このパラメータによって、使用する G.711 のバリアントを選択できます。この設定パラメータによって MTP が強制割り当てされなかった場合は、コーデックを判断する通常のメカニズムが適用されます。

（注） MTP Required の設定によって MTP をメディア ストリームに配置すると、MTP リソースの Cisco IP Voice Media Streaming Application または Cisco IOS Release 12.4(6)T 以降を使用する CMM-ACT モジュールが使用されることがあります。この制限は、複数の方式で DTMF を送信するエンドポイントによるものです（たとえば、Cisco Unified IP Phone 7960 は、SCCP イベントと NTE イベントを同時に送信します）。現在、ここで示した MTP だけが、このような状況に対処します。

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

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

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

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

SIP および H.323 ゲートウェイでの DTMF の設定

SIP ダイヤル ピアの下での方式として sip-notify または rtp-nte を設定します。SIP ダイヤル ピアの最適な設定は、システムに存在するエンドポイントの混在状況によって異なります（ 表6-7 を参照）。ゲートウェイで Unsolicited Notify を使用する場合、MTP リソースを必要とせずに、SCCP をサポートするエンドポイントでダイヤル ピアを使用できます。NTE だけをサポートするエンドポイントは、ゲートウェイを使用するために、MTP を呼び出す必要があります。

逆に、SIP ダイヤル ピアで NTE が設定されている場合は、NTE を使用できるすべてのエンドポイントが、MTP を必要とせずにゲートウェイに DTMF を直接送信できます。SCCP だけをサポートするエンドポイントは、MTP を呼び出す必要があります。

SIP ゲートウェイは、NTE、Unsolicited Notify、またはメディア ストリームのオーディオ トーンを使用して DTMF を送信できます。Unsolicited Notify はシスコ固有の方式で、DTMF トーンを含むイベントと共に SIP Notify メッセージを送信します。この方式は、Cisco Unified CallManager でもサポートされます。

次の例は、Named Telephony Event 用の SIP ゲートウェイ設定を示しています。

Cisco IOS SIP ゲートウェイは、現在、Key Press Markup Language（KPML）をサポートしていません。

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

H.323 ゲートウェイでの DTMF 方式に推奨される設定を示します。

（注） SIP デバイスは、Key Press Markup Language（KPML）という DTMF を送信する別の方式をサポートしていることがあります。多くのシスコ製電話機は KPML をサポートしていますが、まだ広くサポートされてはいません。Cisco IOS SIP ゲートウェイは、Cisco IOS Release 12.4(4)T の時点では KPML をサポートしていませんが、間もなくサポートが追加される予定です。追加された時点で、Unsolicited Notifies の代わりにゲートウェイで KPML を使用できるようになります。

CTI ルート ポイント

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

MTP リソース

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

ソフトウェア MTP（Cisco IP Voice Media Streaming Application）

ソフトウェア MTP とは、サーバに Cisco IP Voice Media Streaming Application をインストールすることによって設定されるデバイスです。インストールされたアプリケーションが、MTP アプリケーションとして設定されると、そのアプリケーションは、Cisco Unified CallManager ノードに登録され、サポートする MTP リソース数を Cisco Unified CallManager に知らせます。ソフトウェア 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、その他のルータ モデルでは Release 12.3(8)T4 から使用できるようになりました。

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

• ルータ設定では、最大 500 の個別ストリームが可能で、250 のトランスコーディングされたセッションをサポートします。この数の G.711 ストリームを使用すると、5 MB のトラフィックが生成されます。

ハードウェア MTP（Cisco NM-HDV2、NM-HD-1V/2V/2VE、2800 および 3800 シリーズ ルータ）

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

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

ハードウェア MTP（Cisco WS-SVC-CMM-ACT）

• このモジュールには、個別に設定できる 4 つの DSP があります。

• 各 DSP は、128 の G.729、G.729b、または GSM MTP セッション、または 256 の G.711 mu-law または a-law MTP セッションをサポートします。

ハードウェア MTP（Catalyst WS-X6608-T1 および WS-X6608-E1）

• サポートされるコーデックは、G.711 mu-law または a-law、G.729、G.720b、または GSM です。

• 設定はポート レベルで行います。モジュールごとに 8 つのポートを使用できます。

• MTP リソースとして設定されたポートごとに、24 のセッションが提供されます。

PVDM

表6-8 および 表6-9 に、PVDM の 2 つのモデルまたは固定構成ネットワーク モジュールに配置できる DSP の数を示します。PVDM2- xx モジュールは PVDM-256K- xx モジュールよりも新しく、この 2 つのタイプは交換できません。

表6-10 に、各ハードウェア プラットフォームおよびネットワークモジュールでメディア リソース機能をサポートするために必要な、Cisco IOS ソフトウェアの最小バージョンを示します。

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

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

ネットワーク モジュール

NM-HDV2、NM-HD- xx 、および NM-HDV モジュールは、 表6-11 に示されている Cisco IOS プラットフォームに取り付けることができます。その場合の最大モジュール数は、表のとおりです。

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

NM-HDV モジュールと NM-HDV-FARM モジュールは、同じシャーシに混在できます。すべてのシャーシがこれらのモジュールをフル装備できるわけではありません。表 6-11 では、各タイプのハードウェア プラットフォームがサポートする最大モジュール数を示しています。

（注） Cisco VG200、2620、2621、および 3620 は、NM-HDV-FARM をサポートせず、さらに MTP、会議、およびトランスコーディングもサポートしません。Cisco 2801 には NM スロットがありません。

NM-HDV の DSP 要件の計算

状況によっては、NM-HDV がフル装備されないことがあります。サンプリング レートは通常、システム デフォルトから変更されません。サンプリング レートを変更する必要がない場合は、この問題を無視してかまいません。

音声アクティビティ検出（VAD）を有効または無効にしたサンプル レート 20、30、40、60 ms の場合（または、VAD を有効にした 10 ms の場合）、PVDM を 5 台フル装備した NM-HDV または NM-HDV-FARM を構成して、使用可能な DSP リソースを 60 得ることが可能です。

VAD を無効にした 10 ms サンプリング レートの場合、フル装備の NM-HDV 上のすべての DSP を利用することは不可能です。パケット レートが、NM-HDV のキャパシティである毎秒 6600 パケット（pps）を超えないことを確認するには、さらに次の計算が必要です。

100 pps （音声インターフェイス数）+ 600 pps（会議数）+ 200 pps（トランスコーディング セッション数 ）< 6600 pps

一般的な設計ガイドライン

Cisco Unified CallManager のメディア リソース グループ（MRG）とメディア リソース グループ リスト（MRGL）のコンストラクトは、この章で説明されているリソースの編成とアクセスの方法を制御するために使用されます。この項では、これらのコンストラクトを効率的に利用する方法について説明します。また、さまざまな Cisco Unified CallManager 配置モデルに固有の考慮事項についても説明します。

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

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

• システムは、ユーザ インターフェイスに表示されず、すべてのリソースが作成時にメンバーとなるデフォルト メディア リソース グループを定義します。メディア リソースの使用側は、まず、設定で指定されている任意のメディア リソース グループ（MRG）またはメディア リソース グループ リスト（MRGL）のリソースを使用します。必要なリソースが使用できない場合、デフォルト MRG でリソースが検索されます。単純な配置では、デフォルトの MRG だけを使用することがあります。

• MRG を使用してリソースへのアクセスを制御する場合は、リソースを明示的に別のグループに設定することによって、デフォルト MRG の外に移動する必要があります。すべてのコールに対する最後の手段としてのみリソースを使用できるようにする場合は、そのリソースをデフォルト グループに残しておくことができます。また、リソースの制御が必要ない場合も、デフォルト グループに残しておくことができます。

• MRG には、複数のタイプのリソースが含まれていることがあります。必要な機能に基づいて、適切なリソースがグループから割り当てられます。MTP とトランスコーダは、特別な例です。トランスコーダは MTP としても使用できます。

• MRG の用途の 1 つは、類似したタイプのリソースのグループ化です。コンファレンス ブリッジ リソースがサポートする参加者の数は異なります。MRG を使用して、コンファレンス ブリッジのサイズ別に会議リソースをグループ化できます。

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

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

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

• MRG から類似のリソースを割り当てるアルゴリズムでは、類似したリソース間での負荷分散が試みられます。リソースが使用されると、その MRG のポインタは次のデバイスにインクリメントされます。1 つのデバイスが複数の MRG に存在することがあります。この場合、このデバイスがメンバーであるすべてのグループのポインタに影響を与えます。MTP が必要で、トランスコーダが同じグループに存在する場合、すべての MTP が使用されるまで、MTP が常に割り当てられます。すべての MTP が使用されると、トランスコーダが MTP として使用されます。同じグループにキャパシティの異なるリソースがある場合、ロード シェアリングはキャパシティに基づいてリソースを割り当てようとします。システムはリソース間で負荷を分散しますが、上記の要素により、動作がラウンドロビンになることはあまりありません。

• Cisco Unified CallManager Administration には MRG のデバイスがアルファベット順に表示されますが、割り当てられる順序は設定データベースの順序に基づきます。この順序は変更できません。メディア リソースを特定の順序で割り当てるには、リソースごとに別の MRG を作成し、MRGL を使用して割り当て順序を指定します。

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

配置モデル

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

• 「単一サイト配置」は、1 つのサイト内の 1 つ以上のコール処理エージェントから構成され、音声トラフィックは IP WAN を介して伝送されません。

• 「集中型コール処理を使用するマルチサイト WAN 配置」は、IP WAN を通じて接続された複数のサイトにサービスを提供する、単一のコール処理エージェントから構成されます。

• 「分散型コール処理を使用するマルチサイト WAN 配置」は、IP WAN を通じて接続される複数のリモート サイトのそれぞれに置かれている、コール処理エージェントから構成されます。

• 「IP 公衆網アクセス」は、MTP リソースを必要とするもう 1 つのシナリオです。このシナリオは、上記の配置モデルのすべてに適用されます。

単一サイト配置

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

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

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

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

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

図6-1 集中型コール処理を使用する WAN のトランスコーディング

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

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

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

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

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

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

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

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

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

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

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

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

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

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

IP 公衆網アクセス

MTP リソースとトランスコーディング リソースのもう 1 つのアプリケーション シナリオには、従来の公衆網ではなく、IP 公衆網へのアクセスをカスタマーに提供するサービス プロバイダーが必要です。このようなシナリオでは、ゲートキーパーがサービス プロバイダーのネットワークに置かれます。ダイヤル プランを単純化するために、各カスタマーは、エンドポイントに割り当てられている個々の IP アドレスを隠せるように、MTP を使用してコールを固定する必要があります。その後、サービス プロバイダーのセントラル オフィスは、従来の公衆網を介してリレーし、他のカスタマーとの IP 接続を提供できます。図6-3 は、この配置モデルを示しています。

図6-3 IP 公衆網アクセスの例

図6-3 のカスタマー サイトは、前述の 3 つの配置モデル（単一サイト、集中型コール処理を使用するマルチサイト WAN、分散型コール処理を使用するマルチサイト WAN）の任意の 1 つを使用できることに注意してください。

カスタマー サイトから IP 公衆網までの H.323 トランクは、エンドポイントの IP アドレスがマスクされたままであるように、MTP を使用して設定される必要があります。したがって、すべての外部コールが MTP リソースを使用します。ただし、MTP リソースは、リソースの使用効率を高めるために、Cisco Unified CallManager クラスタ内で共有できます。MTP を利用してアドレスを隠蔽するこの手法は、SIP トランクでも使用できます。