Cisco IP テレフォニー ソリューション リファレンス ネットワーク デザイン Cisco CallManager Release 4.0 および 4.1

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

モジュールでサポートできるコール数を確認するには、 表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 を指定しています。たとえば、C5510 は C2510 とも呼ばれます。また、C プレフィックスは、TI5510 や TI549 のように、TI で置き換えられる場合があります。

音声インターフェイスの 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 を参照）。

会議

コンファレンス ブリッジとは、複数の参加者を 1 つのコールに参加させるリソースです。そのデバイス上で 1 つの会議に許可される最大ストリーム数まで、所定の会議用に任意の数の接続を受け入れることができます。会議に接続されているメディア ストリームと、その会議に接続されている参加者との間には、1 対 1 の対応があります。コンファレンス ブリッジは、ストリームを混合し、接続されている通話者ごとに固有の出力ストリームを作成します。所定の通話者の出力ストリームは、接続されている全通話者からのストリームの合成から、当事者の入力ストリームをマイナスしたものです。一部のコンファレンス ブリッジは、会議で通話量が最も多い 3 名の通話者だけを混合し、その合成ストリーム（通話量が最も多い通話者の 1 人である場合は、当事者の入力ストリームをマイナスしたもの）を各参加者に配信します。

コンファレンス ブリッジ リソースには、次の 2 つの主要なタイプがあります。

• ソフトウェア コンファレンス ブリッジ

ソフトウェア ユニキャスト コンファレンス ブリッジは、G.711 音声ストリームと Cisco Wideband オーディオ ストリームを混合できる標準の会議ミキサーです。Wideband または G.711 A-law および mu-law ストリームの任意の組み合せが、同じ会議に接続される場合があります。所定の会議でサポートできる通話者数は、コンファレンス ブリッジ ソフトウェアが実行されるサーバと、そのデバイスの設定によって決まります。

• ハードウェア コンファレンス ブリッジ

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

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

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

トランスコーディング

トランスコーダは、あるコーデックの出力ストリームを取り、別のコーデック タイプ用の入力ストリームにリアルタイムで変換する（トランスコードする）デバイスです。つまり、トランスコーダは、ある圧縮タイプのストリームを、別の圧縮タイプのストリームに変換します。

トランスコーダは、G.711 音声ストリームを、G.729a などの低ビット レート（LBR）圧縮音声ストリームに変換できます。この変換は、低速 IP WAN を介した Cisco IP Interactive Voice Response（IVR）、音声メッセージング、電話会議などのアプリケーションを使用可能にする場合に非常に重要です。さらに、トランスコーダはメディア ターミネーション ポイント（MTP）の機能を備えているので、必要に応じて H.323 エンドポイント用の補足サービスを使用可能にするのにも使用できます。

表6-8 は、各プラットフォームでサポートされているコーデック タイプごとの MTP とトランスコーディング セッションの最大数をリストしています。

IP テレフォニー システムを大企業の環境へスケーリングするには、ハードウェア会議が必要です。 表6-7 に示されているハードウェア プラットフォームの音声モジュールの DSP リソースは、大規模システムに必要なハードウェア会議機能を提供し、次の特性をサポートします。

• MRG（メディア リソース グループ）と MRGL（メディア リソース グループ リスト）を使用して、Cisco CallManager は、クラスタ内の Cisco CallManager サーバ間でハードウェア会議ポートの共有を可能にします。

• Cisco CallManager は、Skinny Client Control Protocol（SCCP）を使用して、ハードウェア コンファレンス ブリッジと情報を交換しますが、これらのプラットフォーム上のゲートウェイ サービスはメディア ゲートウェイ コントロール プロトコル（MGCP）を使用する場合があります。

ハードウェア MTP リソースには、次のガイドラインが適用されます。

• 一部のリソース（たとえば、Cisco 会議リソース）には、G.711 音声ストリームのみを使用する機能があります。

• 音声ストリームを圧縮する場合は、G.711 以外のコーデックを使用してください。

• 圧縮された音声ストリームを、G.711 のみをサポートするデバイスに接続する場合、ハードウェア ベースの MTP とトランスコーディング サービスを使用して、圧縮された音声ストリームを G.711 に変換してください。

メディア ターミネーション ポイント（MTP）

メディア ターミネーション ポイント（MTP）は、2 つの全二重 G.711 ストリームを受け入れるエンティティです。MTP は、この 2 つのメディア ストリームをブリッジします。また、これらのメディア ストリームは、個々にセットアップと終了ができるようになります。ある接続の入力ストリームから受信されるストリーミング データは、他の接続の出力ストリームに渡され、逆も同様です。また、MTP は、A-law から mu-law への、およびその逆のトランスコーディングを行うことや、パケット化にかかる時間が異なる（使用するパケット サイズが異なる）2 つの接続をブリッジすることもできます。さらに、MTP は、RFC 2833 サポートなどのコール処理を行うこともできます。

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

（注） Release 3.2 より前の Cisco CallManager を実装する場合は MTP を使用して H.323 エンドポイントに補足サービスを提供する必要がありますが、Cisco CallManager Release 3.2 以降を実装する場合は、MTP リソースを使用してこの機能を提供する必要はありません。

MTP には、次の 2 つの主要なタイプがあります。

• ソフトウェア MTP

ソフトウェア MTP とは、サーバに Cisco IP Voice Media Streaming Application をインストールすることによって設定されるデバイスです。インストールされたアプリケーションが、MTP アプリケーションとして設定されると、そのアプリケーションは、Cisco CallManager ノードに登録され、サポートする MTP リソース数を Cisco CallManager に知らせます。ソフトウェア MTP デバイスは、G.711 ストリームだけをサポートします。

Cisco IOS Enhanced ソフトウェア デバイスを Cisco IOS ルータに実装する場合、DSP ファームでソフトウェア専用の MTP を設定できます。この DSP ファームは、単純な MTP としてのみ使用でき、ルータ上のハードウェア DSP を必要としません。

• ハードウェア MTP

ハードウェア MTP とは、Cisco CallManager の外部のハードウェア上にある DSP ベースのリソースです。トランスコーダには MTP 機能があります。実際、ハードウェア MTP は、MTP として使用されるトランスコーダです。ハードウェア デバイスは、トランスコーダとして Cisco CallManager ノードに登録され、サポートするリソース数を Cisco CallManager に知らせます。トランスコーダ機能を持つハードウェア MTP は、G.711 以外のストリームを受け入れることができます。

SIP RFC 2833 サポートに対する MTP

SIP の仕様で規定されているとおり、SIP エンドポイントには、DTMF ディジットとコール進捗音をメディア ストリームでインバンドで送信する機能があります。DTMF トーンは、修正された RTP パケットとして RTP ストリームで送信されます。Cisco CallManager Release 4.1 の時点で、Skinny Client Control Protocol（SCCP）エンドポイントにはこの機能がありません。したがって、Cisco CallManager システムと SIP システムを統合するには、メディア ストリームに MTP を挿入し、SIP インバンド シグナリングを SCCP アウトバンド シグナリングに、またはその逆に変換する必要があります。

Cisco CallManager Release 4.1 の時点で、ソフトウェアとハードウェアはどちらも RFC 2833 をサポートできます。Ad-hoc Conferencing and Transcoding（ACT）Port Adapter の最小コード バージョン 12.3(8)XY2 と Cisco IP Voice Media Streaming Application はどちらも RFC 2833 をサポートします。

SIP トランクを通過するコール用に MTP をプロビジョニングする必要があります。2 つの Cisco CallManager クラスタが SIP トランクを介して接続されている場合、各クラスタにはこの用途のための独自の MTP リソースが必要です。ソフトウェア MTP は、この用途専用のデュアル CPU サーバに実装されると、512 のストリームをサポートできます。

MTP、会議、およびトランスコーディングに対するハードウェア リソース

これらの機能を実装するためのリソースは、ハードウェアベースにすることも、ソフトウェアベースにすることもできます。ソフトウェア リソースは、Cisco CallManager サーバまたは Cisco IOS プラットフォーム上に常駐できます。また、ハードウェア プラットフォームは、Cisco IOS または Cisco Catalyst プラットフォームのどちらかになります。この項では、使用可能なすべてのリソースでサポートされるストリームのコーデック タイプと数について要約します。これらのリソースは、ゲートウェイ上で DSP ファームとして設定され、Cisco CallManager によって SCCP プロトコルを介して使用されます。ゲートウェイは、リソースの制御と割り当てを担当します。

これらの機能のサポートは、ハードウェア プラットフォーム、Cisco CallManager のバージョン、および Cisco IOS のバージョンによって異なります。 表6-7 は、モジュールおよびプラットフォームで MTP、会議、およびトランスコーディングをサポートするのに必要な最小のソフトウェア リリースを示しています。さまざまな Cisco IOS プラットフォームでサポートされるメディア リソース モジュールの数とタイプを確認する場合は、 表6-11 を使用してください。各表は、メディア リソースをサポートするモジュールのみを示しています。

（注） Cisco VG200、2620、2621、および 3620 は、NM-HDV-FARM をサポートせず、さらに MTP、会議、およびトランスコーディングもサポートしません。Cisco 2801 には NM スロットがありません。DSP ファームのサービスは、Cisco Survivable Remote Site Telephony（SRST）または Cisco CallManager Express ではサポートされません。

次の項で説明するように、C549 プラットフォームでのリソースの割り当て処理は、C5510 プラットフォームの場合と異なります。

音声インターフェイスまたは DSP ファームへのリソースの割り当て

モジュール上の DSP リソースは、音声トランク グループの音声インターフェイスとして、または DSP ファームとして設定できます。DSP ファームでは、DSP を会議またはトランスコーディング/MTP のどちらかに割り当てることができます。 表6-8 は、各コンファレンス ブリッジでサポートできる参加者の数と、モジュールごとにサポートされる会議セッションの数を示しています。同様に、 表6-9 は、DSP およびモジュールごとにサポートされるトランスコーディング セッションの数を示しています。また、 表6-10 は、DSP およびモジュールごとにサポートされる MTP セッションの数を示しています。モジュール上で使用可能な DSP の個数を確認する場合は 表6-2 ～ 表6-6 を使用し、シャーシでサポートできる NM モジュールの最大数を確認する場合は 表6-11 を使用してください。これら各種の表を使用すると、配置に必要なハードウェア構成を確認できます。

（注） モジュールでサポートできるコールまたはセッションの数は、そのモジュール上の特定の DSP 構成によって異なります。表6-8 ～表6-10 は、モジュール タイプごとに使用可能な多数の DSP 構成のごく一部を示しています。他の DSP 構成について調べる場合や、DSP 構成でサポートできるコールまたはセッションの数を計算する場合は、
http://www.cisco.com/cgi-bin/Support/DSP/cisco_dsp_calc.pl にアクセスして、Cisco DSP Calculator を使用します（Cisco.com へのログインが必要です）。

NM-HDV（C549 ベースのハードウェア）におけるリソースの割り当て

各 DSP は個別に設定でき、各 DSP 機能は相互に独立して設定できます。会議、トランスコーディング、および MTP リソースは、別々の DSP に割り当てる必要があります。また、単一の DSP で一度にサポートできる DSP 機能は 1 つのみです。設定によって、各 DSP が実行する機能が指定されます。

1 つの NM-HDV モジュールに関連付けることのできる Cisco CallManager は 1 つのみです。

NM-HDV2、NM-HD- xx 、および PVDM2（C5510 ベースのハードウェア）におけるリソースの割り当て

C5510 チップセットをベースとするハードウェア リソースは、リソース タイプを定義する DSP プロファイルを使用して割り当てられます。プロファイルには DSP ファームが関連付けられているため、DSP は特定のリソース タイプとして定義されません。

DSP ファームの DSP は、複数の Cisco CallManager によって使用される場合があります。

NM-HDV の DSP 要件の計算

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

所定のアプリケーションに必要な DSP の個数を計算するには、必要な会議の数、音声インターフェイス用の DSP の個数、およびトランスコーディング セッション用の DSP の個数を加算します。トランスコーディングに必要な DSP の個数は、必要なトランスコーディング セッション数を 4 で除算して、その結果を切り上げた整数と等しくなります。

PVDM の固定構成では DSP を 3 個備えているので、必要な PVDM 数は、DSP の個数を 3 で除算して、その結果を切り上げた整数と等しくなります。

最後に、必要な NM-HDV または NM-HDV-FARM モジュールの数は、PVDM 数を 5 で除算して、その結果を切り上げた整数と等しくなります。

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

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

DSP リソースのプラットフォーム サポート

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-11 内の 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 IP Voice Media Streaming Application です。また、これは、Cisco CallManager 用に認定された任意のプラットフォームで実行されます（認定プラットフォームのリストについては、「コール処理」を参照してください）。このアプリケーションは、次のデバイス タイプのいずれかとして動作し、Cisco CallManager に登録されるように設定できます。デバイス タイプは、ソフトウェア コンファレンス ブリッジ、メディア ターミネーション ポイント（MTP）、Annunciator、および Music On Hold（MOH）サーバです。

Cisco IP Voice Media Streaming Application は、IP Voice Media Streaming Driver を使用して、リアルタイムの音声メディア ストリーミングを実行します。また、このアプリケーションは、アプリケーション自体と IP Voice Media Streaming Driver の両方の設定情報も取得します。ソフトウェア コンファレンス ブリッジは、G.711 コーデックだけをサポートするので、電話会議にトランスコーディングが不要の単一サイトに最も適しています。スケジューリング機能を必要としないソフトウェア会議サービスには、比較的拡張が容易なソリューションです。

ソフトウェア コンファレンス ブリッジには、次の特性があります。

• G.711（A-law または mu-law）および Cisco Wideband をサポート

• Ad Hoc 会議の参加者は最大 64 名、Meet-Me 会議の参加者は最大 128 名

• 低ビット レート（LBR） コールはすべて、電話会議に参加する前にトランスコーディングされなければならない

（注） G.711 以外のコーデックを使用するコールがソフトウェア コンファレンス ブリッジに参加する場合は、別のトランスコーダ リソースが使用可能になっている必要があります。

Annunciator

Annunciator は Cisco IP Voice Media Streaming Application のソフトウェア機能で、これを使用すると、音声メッセージや各種のコール進捗音をシステムからユーザに流すことができます。この機能は、複数の片方向 RTP ストリームを Cisco IP Phone やゲートウェイなどのデバイスに送信できます。さらに、SCCP メッセージを使用して、RTP ストリームを確立します。この機能を使用するには、デバイスが SCCP に対応している必要があります。トーンとアナウンスは、システムで事前に定義されています。アナウンスでは、ローカリゼーションがサポートされています。また、適切な .wav ファイルを置き換えて、アナウンスをカスタマイズすることもできます。Annunciator は、トランスコーディング リソースを使用しないで、G.711 A-law および mu-law、G.729、および Wideband コーデックをサポートすることができます。

次の機能には、Annunciator リソースが必要です。

• Cisco Multilevel Precedence Preemption（MLPP）

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

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

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

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

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

• SIP トランクを介した統合

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

–コール進捗音（ビジー、アラート、およびリングバック）

–DTMF トーン

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

これらのデバイスには、コール進捗音（リングバック トーン）のサポートが必要です。

• システム メッセージ

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

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

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

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

• 会議

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

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

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

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

Annunciator のパフォーマンス

デフォルトでは、Annunciator は 48 のストリームを同時にサポートするように設定されています。この設定値は、Cisco CallManager サービスを含む同一のサーバ（共存）上で動作する Annunciator に推奨される最大値です。サーバの接続性が 10 Mbps しかない場合は、設定を下げて同時ストリームを 24 にします。

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

Cisco IP Voice Media Streaming Application

Cisco IP Voice Media Streaming Application は、ソフトウェアに次のリソースを組み込みます。

• Music On Hold（MOH）

• Annunciator

• ソフトウェア コンファレンス ブリッジ

• メディア ターミネーション ポイント（MTP）

Media Streaming Application をアクティブにすると、上記の各リソースが 1 つずつ自動的に設定されます。Annunciator、ソフトウェア コンファレンス ブリッジ、または MTP が必要ない場合は、Cisco IP Voice Media Streaming Application の Run Flag サービス パラメータを無効にして、これらのリソースを無効にすることをお勧めします。

複数のリソースが必要になる状況や、それらのリソースによって Media Streaming Application にかかる負荷を慎重に検討してください。各リソースには、処理可能な接続の最大数を制御するサービス パラメータと、関連付けられたデフォルト設定があります。デフォルト設定を変更しない限り、4 つのリソースすべてを同じサーバ上で実行できます。ただし、配置においてデフォルトを超える数のリソースが 1 つでも必要になった場合は、そのリソースを独自の専用サーバ上で実行するように設定します（そのサーバ上では、その他すべてのリソースおよび Cisco CallManager サービスを実行しないでください）。

すべての配置モデル用の会議ガイドライン

• ユーザ用に少なくとも次の会議リソースを用意することをお勧めします。

–ユーザ ベースの 5% 以上に相当する Ad Hoc 会議リソース

–ユーザ ベースの 5% 以上に相当する Meet-Me 会議リソース

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

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

• 会議リソースのタイプによって、単一のブリッジにおける参加者の最大数の制限が異なります（ 表6-8 を参照）。MRGL に複数のリソースが定義されている場合は、使用可能な最初のリソースが使用されます。参加者の最大数は、次の 2 つの Cisco Callmanager サービス パラメータによって制御されます。Maximum Ad Hoc Conferences の値の範囲は 3 ～ 64 で、Maximum Meet Me Conference Unicast の値の範囲は 1 ～ 128 です。デフォルト設定はどちらも 4 です。会議リソースの参加者の最大数によって、サービス パラメータの設定値が上書きされます。

コンファレンス ブリッジのサイズを最大にするには、サービス パラメータを、MRGL 内のリソースの最小ブリッジ サイズと一致するように設定します。別の方法としては、同じ特性のリソースだけを使用してブリッジ サイズを最大にし、そのサイズと一致するようにサービス パラメータを設定します。

• CTI アプリケーションと Drop Any Party 機能では、16 を超える参加者はサポートされません。Ad Hoc 会議リソースの中には 16 を超える参加者をサポートできるものもありますが、このアプリケーションに表示される参加者は、最新の 16 名のみです。

単一サイト配置用の会議ガイドライン

単一サイト配置では、音声トラフィックは IP WAN を通過しません。1 つのタイプのコーデック（通常、G.711）だけが使用されます。したがって、このタイプの配置には、電話会議用のトランスコーディング リソースが必要ないので、ソフトウェア会議を使用できます。より多くの会議キャパシティが必要な場合は、ハードウェア会議リソースを追加できます。

単一サイト配置には、次のガイドラインが適用されます。

• このモデルでは、音声トラフィックは IP WAN を通過しません。したがって、1 つのタイプのコーデック（通常、G.711） を使用してください。トランスコーディング リソースは必要ありません。

• ソフトウェアとハードウェアのどちらの会議でも使用できます。ただしソフトウェア会議は、小規模な配置のみに使用してください。

集中型コール処理を使用するマルチサイト WAN 配置用の会議ガイドライン

このモデルでは、コール処理は中央サイトでローカライズされます。MTP、トランスコーディング、および会議の各サービスは、中央で処理するか、分散させるか、または両方を組み合せることもできます。

• メディア リソースが中央に集中する場合

–これらのリソースの 1 つを使用するすべてのコールで、WAN が使用されます。

–リソースを中央に配置すると、ローカル コールも WAN を通過するので、帯域幅の使用量に対する影響を検討する必要があります（「コール アドミッション制御」を参照）。

• メディア リソースが分散される場合

–あるリモート サイトが別のリモート サイトにあるリソースを使用できないように、そのロケーションに基づいてリソースを MRGL にグループ化してください。この方法は、サイト間のコール アドミッション制御を管理するのに役立ちます。

–複数のタイプのコーデックと、G.729 をサポートしない任意のデバイスがクラスタに含まれている場合は、ハードウェア会議リソースを使用してください。現時点で、Cisco デバイスはすべて、両方のコーデック タイプをサポートできます。Cisco Customer Response Solution（CRS）Release 3.0 以降は、G.729 または G.711 をサポートできますが、同一のインストールで両方をサポートすることはできません。

すべての集中型コール処理配置では、Cisco CallManager のロケーション メカニズムを使用して、コール アドミッション制御を提供します。Cisco CallManager は、リージョンと連携させてロケーションを使用して、ネットワーク リンクの特性を指定します。リージョンは、リンクで使用される圧縮のタイプを定義します。ロケーションは、リンクに使用可能な帯域幅の量を定義します。図6-1 は、音声コールに割り当てられる帯域幅の量によって制限されるロケーションを使用した、一般的な集中型コール処理モデルを示しています。帯域幅の制限があるので、この設定のリージョンは、G.729 などの低ビット レート（LBR）コーデックを使用します。各 LBR コールは、G.711 に必要な 80 kbps ではなく、約 24 kbps を使用します。

図6-1 集中型コール処理配置用のロケーションベースのコール アドミッション制御

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

Cisco CallManager のメディア リソース グループとメディア リソース グループ リストを使用すると、リモート サイトの会議リソースを提供して、WAN 上の帯域幅使用量を最小限に抑えることができます（図6-2 を参照）。WAN 帯域幅がオーバーサブスクリプションにならないように、ロケーションに基づくコール アドミッション制御が引き続き必要です。

図6-2 集中型コール処理配置における会議リソースのローカライズ

図6-2 では、支店のリモート サイトにある電話機には、メディア リソース グループ MRG1 が登録されているメディア リソース グループ リスト（MRGL）が割り当てられています。このグループには、そのサイトのコンファレンス ブリッジ リソースが登録されています。この設定では、WAN 帯域幅を使用しないでそのサイト内で電話会議が可能になります。たとえば、Phone X が Phone A にコールし、Phone A が Phone B と電話会議を行うと想定します。この時点で、Cisco CallManager は、電話会議をホストするために、会議リソースを要求します。MRG と MRGL が設定されているので、Cisco CallManager は、この電話会議用に支店サイトのコンファレンス ブリッジを選択します。

Cisco CallManager におけるメディア リソースの割り当て

Cisco CallManager がメディア リソース グループ（MRG） 内のリソースをどのように割り当てるかを理解することが、非常に重要です。上記で説明したように、MRG は、メディア リソース グループ リスト（MRGL） に含まれ、MRGL は、デバイス プールに関連付けられます。リソースを割り当てる場合、Cisco CallManager はまず、MRGL で指定されている順序に従って、適切な MRG を選択します。MRG 内のリソースは、MRG にリソースが追加された順番に関係なく、名前のアルファベット順にリストされます。Cisco CallManager は、リストされている順（つまり、アルファベット順）にリソースを MRG から割り当てます。したがって、リソースの優先順位順の割り当てが必要な場合（たとえば、ソフトウェア コンファレンス ブリッジより前に、ハードウェア コンファレンス ブリッジ）、MRG でこれらのリソースに適切な名前を付け、適切な MRGL を設定して、必要な順序を指定する必要があります。

分散型コール処理を使用するマルチサイト WAN 配置用の会議ガイドライン

分散型コール処理配置では、IP WAN を介して複数のサイトが接続されます。各サイトには、Cisco CallManager クラスタなどの独自のコール処理エンティティが含まれ、単一サイト モデルか、集中型コール処理モデルになります。サイト間のコール アドミッション制御には、ゲートキーパーを使用できます。また、この場合、一般に WAN 帯域幅が制限されるので、サイト間コールは、WAN を通過するときに低ビット レート コーデック（たとえば、G.729）を使用するように設定されます。

分散型コール処理配置には、次のガイドラインが適用されます。

• このモデルでは、各サイトの Cisco CallManager クラスタに、独自の会議リソースがある場合があります。

• 各クラスタは、複数のタイプのコーデックを使用する可能性があります。一般に、クラスタ間の WAN 上では G.729、クラスタ内では G.711 です。

• 複数の Cisco CallManager クラスタ間での会議では、会議主催者の ID により、どの会議リソースが電話会議に割り当てられるかが決まります（図6-3 を参照）。

• WAN を通過するストリームの本数は、会議の主催者、およびその他の参加者のロケーションによって異なります。主催者と別のクラスタ内にいる各参加者は、WAN 上のストリームを追加し、そのストリームは、主催者のクラスタ内のリソースで終端します。コール アドミッション制御を設定する際には、これらの要素を考慮してください（「コール アドミッション制御」を参照）。

• 1 つのクラスタ内では、会議の参加者の最大数は、リソースのタイプと、サービス パラメータの設定値で決まります。ただし、参加者が複数のクラスタから参加する場合、電話会議では最大数を超える可能性があります。1 つのクラスタ内では、会議の主催者だけが参加者を追加できます。しかし、会議の主催者とは所属クラスタが異なる会議参加者は、自身のクラスタ内に使用可能な会議リソースがあれば、参加者を追加できます。こうした電話会議が拡張できるのは、着信コールが別のクラスタ内の既存会議の一部であることをクラスタが認識せず、各クラスタはその最大数の参加者を追加できるからです。

図6-3 は、複数の Cisco CallManager クラスタにまたがって会議リソースが割り当てられる仕組みの例を示しています。

図6-3 分散型コール処理配置用のリソースのローカライズ

図6-3 では、サイト 1 とサイト 2 の 2 つの Cisco CallManager クラスタが、IP WAN とクラスタ間トランクを通じて接続されます。各サイトには、MRG と MRGL を使用して個々の IP Phone に割り当てられる独自の会議リソースがあります。

サイト 1 の Phone A がサイト 2 の Phone C にコールした後、サイト 2 の Phone D に会議コールをすると想定します。会議の開始者はサイト 1 の Cisco CallManager クラスタによって制御されるので、このコールに割り当てられるコンファレンス ブリッジは、サイト 1 に置かれているコンファレンス ブリッジです。つまり、WAN を通過する 2 つのストリーム、つまり、Phone A と Phone C 間のストリームと、Phone A と Phone D 間のストリームがあります。一方、サイト 2 の Cisco CallManager クラスタによって制御される Phone C によって会議が開始された場合、そのコールには、サイト 2 に置かれているコンファレンス ブリッジが割り当てられ、（Phone C と Phone A 間の）1 つのストリームだけが、WAN を通過します。

電話会議が複数の Cisco CallManager クラスタにまたがる場合は、各クラスタで定義された参加者の最大数を超える可能性があります。図6-3 に基づいて、次の例を検証します。

サイト 1 の Phone A が、サイト 1 にあるコンファレンス ブリッジを使用して、サイト 2 の Phone C を含む 6 名の通話者による電話会議をセットアップするとします。両方のクラスタのサービス パラメータは、会議サイズが 6 名の参加者に制限されるように設定されています。ここで、Phone C は、サイト 2 のコンファレンス ブリッジを使用して、別の 5 名の通話者用に別の電話会議をセットアップし、この 2 つの会議を「結合」することができます（すべての音声ストリームを受け入れるのに十分な帯域幅があることを前提とします）。

（注） MRGL 内のすべてのリソースが使用された場合、Cisco CallManager は、デフォルトの MRG、つまり <None> MRG 内でメディア リソースを探します。

単一サイト配置

単一サイト配置では、低ビット レート（LBR） コーデックを使用する根拠となっている低速リンクが不要のため、トランスコーディングの必要はありません。H.323v2 に準拠していない相当数のデバイス（旧バージョンの Microsoft NetMeeting や特定のビデオ デバイスなど）が存在する場合、なんらかの MTP リソースが必要なことがあります。MTP リソースが必要なもう一つの状況は、単一サイトが IP 公衆網プロバイダーを介して公衆網にアクセスする場合です（「IP 公衆網アクセス」を参照）。

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

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

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

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

現行バージョンの Cisco アプリケーションを使用する場合は、トランスコーディング リソースの使用を回避できるため、回避することをお勧めします。Cisco CRS（Release 3.0 以降）アプリケーションは、G.711 または G.729 をサポートできますが、両方を同時にサポートすることはできません。両方のコーデックが必要な場合は、2 つの別々のサーバを使用します。単一のサーバで G.711 を使用する場合は、トランスコーディング リソースが必須となります。

Release 3.0 より前の Cisco CRS は、G.711 のみをサポートしていました。この場合、集中型コール処理配置で 2 つのコーデック タイプが使用されるときは、トランスコーディングを使用する必要があります。

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

Cisco CallManager は、MRG（メディア リソース グループ）を使用して、クラスタ内の Cisco CallManager サーバ間で、MTP リソースとトランスコーディング リソースの共有を可能にします。さらに、異なるリージョンを通過するコールに LBR コーデック（たとえば、G.729）を使用する場合、トランスコーディング リソースが使用されるのは、エンドポイントの一方（または両方）が、LBR コーデックを使用できない場合だけです。つまり、中央サイトの G.711 専用アプリケーションや、リモート サイトの H.323 ゲートウェイがあっても、ゲートウェイは、必ずしも、トランスコーダを実行する必要があるとは限りません。

（注） Release 3.3(2) より前の Cisco CallManager リリースの場合、MTP リソースとトランスコーディング リソースは、Cisco CallManager クラスタを備えた中央サイトに置く必要があります。この理由は、これらのリソースが、コール アドミッション制御用にロケーションで設定できないからです。

要約すると、Cisco CallManager は次の機能を提供します。

• Cisco CallManager クラスタ全体でのリソース共有による、トランスコーディング リソースの最適な使用

• エンドポイントの一方または両方が必要とする場合のみ、トランスコーディング リソースを動的に割り当てることによる、リソースの効率的な使用

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

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

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

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

• 現行バージョンの Cisco アプリケーションを使用する場合は、トランスコーディング リソースの使用を回避できるため、回避することをお勧めします。Cisco CRS（Release 3.0 以降）アプリケーションは、G.711 または G.729 をサポートできますが、両方を同時にサポートすることはできません。両方のコーデックが必要な場合は、2 つの別々のサーバを使用します。単一のサーバで G.711 を使用する場合は、トランスコーディング リソースが必須となります。

Release 3.0 より前の Cisco CRS は、G.711 のみをサポートしていました。この場合、分散型コール処理配置で 2 つのコーデック タイプが使用されるときは、トランスコーディングを使用する必要があります。

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

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

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

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

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

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

IP 公衆網アクセス

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

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

図6-6 のカスタマー サイトは、上記の 3 つの配置モデル、つまり、単一サイト、集中型コール処理を使用するマルチサイト WAN、または分散型コール処理を使用するマルチサイト WAN のいずれのモデルでも使用できることに注意してください。

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