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

帯域幅のプロビジョニング

主要なすべてのアプリケーション（音声、ビデオ、およびデータ）を合計した帯域幅必要量が、使用可能なリンク帯域幅の 75% 以下になるように、WAN リンク帯域幅のプロビジョニングを行う必要があります。

表 2-4 では、デフォルトのパケット レートである毎秒 50 パケット（pps）で、音声ペイロードのみが消費する帯域幅をリストしています。

表 2-5 では、レイヤ 2 ヘッダーが計算に含まれる場合に、音声トラフィックが消費する帯域幅量をリストしています。

この項の計算では、電話機 1 台当たりの平均毎時コール数を 10 と想定します。

公式 1 ：制御トラフィックに必要な推奨帯域幅、TAPI アプリケーションなし

帯域幅（bps）= 150 ∗（事業所内の IP フォンとゲートウェイの数）

公式 2 ：制御トラフィックに必要な推奨帯域幅、TAPI アプリケーションあり

TAPI を使用する場合の帯域幅（bps）= 225 ∗（事業所内の IP フォンとゲートウェイの数）

表 2-6 では、さまざまな事業所の規模に対する推奨帯域幅を示しています。

（注） 表 2-6 の値は、レイヤ 3 帯域幅を示します。WAN リンクをプロビジョニングする場合、使用するレイヤ 2 テクノロジーに応じて、これらの数値にレイヤ 2 オーバーヘッドを加算する必要があります。

拡張公式

この項で示されている上記の公式は、電話機 1 台当たりの平均コール レートを毎時 10 コールと想定しています。しかし、コール パターンが大きく異なる場合（たとえば、事業所にコール センター エージェントが配置されている場合）、この想定が、実際の配置に該当しない場合があります。こうした場合のコール制御帯域幅必要量を計算するには、次の公式を使用してください。これらの公式には、電話機 1 台当たりの毎時平均コール数を表す追加変数（CH）が含まれています。

公式 3 ：事業所の推奨帯域幅、TAPI アプリケーションなし

帯域幅（bps）=（39 + 10.8 ∗ CH）∗（事業所内の IP フォンとゲートウェイの数）

公式 4 ：遠隔地にある事業所の推奨帯域幅、TAPI アプリケーションあり

TAPI を使用する場合の帯域幅（bps）=（39 +18.3 ∗ CH）∗（事業所内の IP フォンとゲートウェイの数）

分散型コール処理を使用したコール制御トラフィック用の帯域幅プロビジョニング

分散された Cisco CallManager クラスタを接続する WAN リンクの場合、必要な帯域幅のシグナリング コンポーネントは次のように計算できます。

平均コール所要時間を 2 分、各仮想タイ ラインの利用率を 100 % と想定すると、各タイ ラインの伝送量は毎時 30 コールであると推論することができます。この前提により、コール制御トラフィック用の推奨帯域幅を仮想タイ ライン数の関数として表す、次の公式が得られます。

公式 5 ：仮想タイ ライン数に基づく推奨帯域幅

推奨帯域幅（bps）= 116 ∗（仮想タイ ライン数）

Cisco IOS ルータ上のキューに割り当て可能な最小帯域幅は、8 kbps です。つまり 8 kbps の最小キュー サイズは、最高 70 の仮想タイ ラインによって生成されるコール制御トラフィックを受け入れることができると推定できます。これは、大部分の大企業での配置に十分な量です。

トラフィックの優先順位

IP WAN を介したマルチサービス トラフィックには、低遅延キューイング（LLQ）をお勧めします。次の優先順位の基準もお勧めします。

• 音声が優先キューに入る基準は、DSCP（Differentiated Services Code Point）値 EF、または IP 優先順位値 5 です。

• ビデオ会議トラフィックが優先キューに入る基準は、DSCP 値 AF41、または IP 優先順位値 4 です。片方向ビデオ トラフィック（IP/TV など）は、遅延許容度がかなり高いので、クラス ベースの均等化キューイング方式を使用する必要があることに注意してください。

• 音声制御プロトコル（たとえば、H.323 や Skinny Client Control Protocol（SCCP））には、独自のクラス ベースの均等化キューが必要です。このキューに入る基準は、DSCP 値 AF31 です。これは、IP 優先順位値 3 に相当します。

リンク効率化手法

cRTP（Compressed Real-Time Transport Protocol）

cRTP を使用すると、さらにリンク効率を高めることができます。このプロトコルは、40 バイトの IP ヘッダー、UDP（User Datagram Protocol）ヘッダー、および RTP ヘッダーを約 2 ～ 4 バイトに圧縮します。個々のリンクで cRTP を使用するのは、そのリンクが次の条件を全部満たす場合だけにしてください。

• 音声トラフィックによる負荷が、特定リンク上で 30% を超えている場合。

• リンクが低ビット レート コーデック（たとえば G.729）を使用する場合。

• 他のリアルタイム アプリケーション（たとえば、ビデオ会議）が同じリンクを使用しない場合。

音声およびビデオに対応した IPSec VPN（V3PN）で cRTP を使用する場合の追加の推奨事項については、次の Web サイトで入手可能な V3PN 資料を参照してください。

http://cisco.com/go/srnd

ATM とフレームリレーのサービス インターワーキング（SIW）リンクでは、cRTP を使用しないでください。

cRTP を使用する前に検討する必要がある重要なパラメータは、ルータの CPU 利用率です。これは、圧縮処理と圧縮解除処理の際に高まるので、注意が必要です。

LFI（Link Fragmentation and Interleaving）

低速リンク（768 kbps 未満）の場合、LFI を使用してください。

トラフィック シェーピング

トラフィック シェーピングは、ATM やフレームリレーなどの複数アクセスの非ブロードキャスト メディアに必要です。この場合、物理的なアクセス速度は 2 つのエンドポイント間で異なります。通常、複数の事業所サイトは、中央サイトのルータの単一インターフェイスへ集約されます。

次のシナリオでは、同一 IP WAN 上での音声とデータの転送時にトラフィック シェーピングが必要な理由を示しています。

• ライン スピード ミスマッチ

中央サイトのインターフェイスは、一般に高速インターフェイス（たとえば、T1 以上）ですが、小規模なリモート サイトの事業所のインターフェイス回線速度はかなり遅くなります（たとえば、64 kbps）。データが中央サイトから低速リモート サイトにフル レートで送信されると、リモート サイトのインターフェイスは輻輳し、音声パフォーマンスが低下する場合があります。

• リモート サイトから中央サイトへの集約時の過剰サブスクリプション

複数のリモート サイトを 1 つの中央サイトに集約する場合、帯域幅を余分にサブスクライブするのは、フレームリレーまたは ATM ネットワークでは一般的な方法です。たとえば、T1 インターフェイスで WAN に接続するリモート サイトが複数あるにもかかわらず、中央サイトには 1 つの T1 インターフェイスしかない場合があります。この設定により、配置されたネットワークは統計多重化による恩恵を受けますが、中央サイトのルータ インターフェイスが、トラフィックのバースト時に輻輳し、音声品質が低下することがあります。

• CIR（認定情報レート）を超えたバースト

もう 1 つの一般的な設定は、CIR を超えたトラフィック バーストを許可することです。CIR は、サービス プロバイダーが、損失なく、遅延の少ないネットワークを介して転送することを保証したレートです。たとえば、T1 インターフェイスを備えたリモート サイトでは、CIR が 64 kbps に過ぎない場合があります。64 kbps 以上に相当するトラフィックが WAN を介して送信される場合、プロバイダーは、追加トラフィックに「discard eligible（廃棄適性）」のマークを付けます。プロバイダーのネットワークで輻輳が発生した場合、このトラフィックは廃棄され、音声品質に悪影響を与える場合があります。

トラフィック シェーピングは、インターフェイスから送出されるトラフィックを、回線レート未満に制限することによって問題を解決し、WAN の両端で輻輳が発生しないようにします。