IP 上の H.323 テレビ会議のための QoS ソリューションの実装

概要

H.323 は、IP ネットワークでのマルチメディア会議の規格として世界的に受け入れられています。このドキュメントでは、比較的低速なリンクを使用したエンタープライズ WAN 上で H.323 ビデオ会議の Quality of Service（QoS）を実装するためのツールについて説明します。

前提条件

要件

このドキュメントの読者は次のトピックについての専門知識を有している必要があります。

• H.323 に準拠したシステムのコンポーネント。コンポーネントには、端末やゲートウェイ、ゲートキーパー、Multipoint Controller（MC; マルチポイント コントローラ）、Multipoint Pprocessor（MP; マルチポイント プロセッサ）、Multipoint Control Unit（MCU; マルチポイント コントロール ユニット）などがありますが、これらに限定されるわけではありません。 詳細については、『ホワイト ペーパー：Cisco ネットワークにおける H.323 アプリケーションの導入』を参照してください。

• シスコの H.323 テレビ会議のソリューションに関する知識。MCU やゲートウェイのほか、Multimedia Conference Manager（MCM）のゲートキーパーやプロキシなどがあります。シスコのビデオ会議ソリューションの詳細については、このドキュメントの「関連情報」セクションを参照してください。

• H.323 のゾーン設計。H.323 エンドポイントのグループは、ゾーン内に形成されます。これは、Domain Name System（DNS; ドメイン ネーム システム）と同様に、優れた管理体系をもたらします。 各ゾーンにはゲートキーパーが 1 台存在し、すべてのエンドポイントを管理します。

• ダイヤル プラン。詳細については、『Cisco AVVID ソリューションの IP テレフォニー：Cisco CallManager リリース 3.0(5)』の「第 5 章：ダイヤル プランのアーキテクチャと設定」を参照してください。

• Call Admission Control（CAC; コール アドミッション制御）の技術に関する知識。Resource Reservation Protocol（RSVP; リソース予約プロトコル）を使用したリソース要求の信号の送信などがあります。

使用するコンポーネント

このドキュメントの内容は、特定のソフトウェアやハードウェアのバージョンに限定されるものではありません。

表記法

ドキュメント表記の詳細は、「シスコ テクニカル ティップスの表記法」を参照してください。

背景説明

現在、ほとんどのネットワークは次のタイプのビデオ トラフィックを 1 つ以上サポートしています。

同時に、多数の企業が既存および多くは別個のデータ、ボイス、およびビデオ ネットワークのインフラストラクチャを見直し、 IP インフラストラクチャを介してそれらのネットワークを統合する最も効率的な方法を模索しています。このような統合されたネットワークでは、ネットワーク内の潜在的な輻輳ポイントに QoS が必要です。QoS により、データの廃棄による影響を受けにくいアプリケーションと比較すれば、遅延や廃棄による影響を受けやすいトラフィック、リアルタイム ビデオ、音声などが、妨げられずに通過できるようになります。WAN エッジ ルータにおいては、QoS は特に 重要です。WAN エッジ ルータでは、キロビット単位や低いメガビット/秒の低速リンクに、数百メガビットのトラフィックが集約される可能性があるからです。

H.323

多くの IP テレビ会議アプリケーションでは、H.323 の一連のプロトコルが使用されています。International Telecommunications Union（ITU; 国際電気通信連合）の H.323 では、IP 経由のマルチメディアの国際標準が定義されています。ITU では、1996 年に最初のバージョンである H.323 標準を承認しました。現在のバージョンは4です。現在、多くのアプリケーションがLANベースのH.323ビデオシステムを導入しています。アプリケーションの例としては、Microsoft NetMeeting があります。このアプリケーションでは、テレビ会議や共有コラボレーションに H.323 を利用しています。

それ以前は、H.320 ベースのテレビ会議システムが一般的でした。H.320 ベースのシステムでは、各システムが 専用の Public Switched Telephone Network（PSTN; 公衆電話交換網）を使用して接続していました。このセクションの図の左側が示すように、現在ではビデオ ゲートウェイを使用して、統合された H.323 ネットワークと従来のビデオ ネットワークの間の通信を行うことができます。図の右側は、ビデオ ターミナル アダプタを使用して、個々の H.320 エンドポイントを H.323 ネットワークへシームレスにリンクした様子を示しています。

テレビ会議トラフィックの特性

音声とは異なり、ビデオの場合、レートが非常に高く、変動幅も極端に高くなります。また、他のトラフィックと比較して、かなり大きな Maximum Transmission Unit（MTU; 最大伝送ユニット）が使用されます。 次の図は、テレビ会議トラフィックにおける一般的なパケット サイズの内訳を示しています。

次の図が示すように、テレビ会議トラフィックのストリームは 2 種類のフレームで構成されます。

「I」フレームは、ビデオの完全サンプリングです。「P」および「B」フレームは、モーション ベクトルと予測アルゴリズムによる量子化を使用しています。

キャパシティ プランニング

ネットワークでビデオ トラフィックを扱う前に、必要なすべてのアプリケーションに適切な帯域幅があることを確認します。最初に、主要な各アプリケーション（音声、ビデオ、データなど）に最低限必要な帯域幅を計算します。その合計が、いずれか特定のリンクで最低限必要となる帯域幅を示しています。この帯域幅が、リンクで利用可能な総帯域幅の 75% を超えないようにします。この 75 % のルールでは、オーバーヘッド トラフィックのために、ある程度の帯域幅が必要になることが想定されています。オーバーヘッド トラフィックとしては、電子メールや HTTP など追加アプリケーションのトラフィックのほか、ルーティング プロトコルの更新やレイヤ 2 キープアライブが含まれます。音声やビデオによるトラフィックの占有率は、リンク容量の 33 % 以下に抑えます。次の「サンプル シナリオ」では、統合ネットワークのキャパシティ計画について説明します。

シナリオ例

リンク キャパシティが 1.544 Mbps で、2 台のビデオ端末が設置されており、各端末ではそれぞれ 256 kbps の最大データ レートをサポートします。2 つのビデオ コールのレートは 512 kbps になりますが、オーバーヘッドを考慮して、コールのデータ レートを 20 % 増加させます。20 % というのは、ほとんどの環境で適切な容量計画を実現できる安全性の高いパーセンテージです。まず、オーバーヘッドを考慮した 20 % を基準にして、次に監視結果に基づいて、この値を増加または減少しながら調整することもできます。

プライオリティ キューには十分な帯域幅をプロビジョニングしておくことにより、プライオリティ キューでオーバーランが発生することなく、両方のビデオ端末が同時に WAN でアクティブ コールを実行できるようにします。このシナリオ例では、3 つ目のビデオ ターミナルを追加する場合、なんらかの形式の CAC を導入する必要があります。

コール単位の帯域幅使用量の決定

キャパシティ プランニングで理解すべき最も重要な概念の 1 つは、各コールに帯域幅をどれだけ使用するかということです。このセクションでは、それぞれのコーダ/デコーダ（コーデック）が使用する帯域幅を説明しています。詳細については、『VoIP - コール単位の帯域幅の使用量』を参照してください。

H.323 音声

音声信号には、デジタル化された圧縮音声（通常は通話）が含まれます。H.323 は実証済みの ITU 標準音声コーデック アルゴリズムをサポートします。サポートされているアルゴリズムは次のとおりです。

• G.711：48、56、および 64 kbps（通常のテレフォニー）での 3.1 kHz（キロヘルツ）

• G.722：48、56、および 64 kbps での 7 kHz

• G.728：16 kbps での 3.1 kHz

• G.723：5.3 および 6.3 kbps のモード

適切なコーデックの選択は、通話品質、ビット レート、計算能力、および信号遅延間のトレードオフを反映します。

H.323 ビデオ

H.323 標準では、H.323 端末のビデオ機能はオプションです。ただし、H.323 端末を導入する場合には、端末で H.261 コーデックがサポートされており、オプションで H.263 標準がサポートされている必要があります。

• H.261:64 kbpsの倍数単位のオーディオビジュアルサービス用ビデオコーデック。H.261 準拠のデバイスでは、先頭フレームはすべて符号化されます。その後は、パケットの送信が最小限になるように、先頭フレームと後続フレームの差分だけが符号化されます。オプションのモーション補正は、画質を向上させます。

• H.263：ビデオ用 Plain Old Telephone Service（POTS; 一般電話サービス）のためのビデオ コーデック。 H.263 標準は、H.261 標準を更新したものであり、下位互換性があります。H.263 では、1/2 ピクセル単位での動きベクトル探索技法（必須要件）により、画質が大幅に向上しています。また、予測フレームや Huffman コード テーブルや、低ビット レート送信での最適化により、さらに機能が強化されています。H.263 標準では、『ホワイト ペーパー：Cisco ネットワークにおける H.323 アプリケーションの導入』のドキュメントの表 1 に示されているように、標準的な 5 つの画像形式を定義しています。

分類

ビデオ トラフィックで適切な QoS の保証を実現するには、ネットワーク デバイスでトラフィックを識別できる必要があります。

QoS の Differentiated Services（DiffServ; ディファレンシエーテッド サービス）モデルでは、DiffServ Code Point（DSCP; DiffServ コード ポイント）値を使用して、トラフィックを複数のクラスに分けます。DiffServ では、次の 2 つの DSCP 値が定義されています。

• Expedited Forwarding（EF; 緊急転送）：単一の DSCP 値（101110）を設定します。この値が設定されていると、マーキングされているパケットに、ネットワークから最高レベルのサービスが与えられます。シスコでは、Low Latency Queueing（LLQ; 低遅延キューイング）を使用して、EF サービスを実現しています。 通常は、EF では、高優先度キューのキャパシティきわめて小さく抑えることによって、遅延を制御し、優先順位の低いトラフィックでキャパシティ不足が起きないようにします。そのため、キューがいっぱいになると、パケットが廃棄される可能性があります。通常、EF は VoIP に最適です。

• Assured Forwarding（AF; 確認転送）：4 つのクラスを提供します。各クラスには 3 つの廃棄優先レベルがあります。

DSCP の詳細については、『DSCP による QOS ポリシーの実装』を参照してください。

通常、シスコの設計ガイドではビデオに AF41（DSCP 値 100010）を推奨しています。IP テレビ会議アプリケーションで、ビデオ ストリームの音声部分をビデオ パケットより優遇して扱っても利点はありません。そのため、ビデオ会議の音声とビデオの両方のメディアについて、DSCP の値に AF41 を使用します。

レイヤ 2 では、3 つの Class of Service（CoS; サービス クラス）ビットを使用できます。これらのフィールドは IEEE 802.1Q タグの一部です。

現在のところ、IP テレビ会議に最適な値を定義している標準はありません。ただし、シスコでは、マルチサービス ネットワークについては、通常は次のマーキング スキームを推奨しています。

^{1 RTP = Real-Time Transport Protocol}

この表では、ストリーミング ビデオとテレビ会議を別のタイプに分類し、異なるマーキングの値を割り当てています。ストリーミング ビデオは、ストリームをバッファリングし、遅延とジッタに対応するより高い能力を持っています。そのため、ストリーミング ビデオには、異なる QoS レベルが必要です。

また、テレビ会議ストリームの制御部分とデータ部分を分けることができます。ストリームのこれらの2つの部分を分割するには、AF31で制御をマークし、AF41でデータをマークします。ただし、この設計は最適な設計ではありません。すべてのエンドポイントでベアラと制御のトラフィックを区別してマークできるわけではなく、シスコのプロキシはすべてのテレビ会議トラフィックを 1 つの値でマークします。また、制御トラフィックのビット レートは、ビデオ コールのビット レートほどには重要ではありません。

ソースにできるだけ近い分類を行います。サードパーティのビデオ パートナーである VCON、PictureTel、および Polycom では IP 優先順位ビットを設定できます。使用している H.323 端末でヘッダーの値を設定しない場合には、ネットワークの次のポイントでパケットをマークできます。

• レイヤ 3 のスイッチ ポート

  詳細は、『QoS の設定』を参照してください。

• Cisco IOS?クラスベースマーキングを使用するルータ

  詳細については、『クラスベース パケット マーキングの設定』を参照してください。

• Cisco MCM 機能を使用する Cisco IOS ルータ

• リモート WAN ルータで稼動している H.323 のゲートキーパー/プロキシ

高度なキューイング メカニズムの選択

Cisco IOS ソフトウェアには、現在いくつかのキューイング メカニズムが含まれています。これらのメカニズムは、ネットワークに入るトラフィックのタイプとそのトラフィックが横断する広域メディアの要求を満たしています。キャンパスと WAN のどちらの場合でも、ネットワークのどの部分でも輻輳が発生する可能性があるため、適切なキューイング技術のアプリケーションが必要になります。キューを使用すれば、ドロップ耐性のあるデータ アプリケーションに対して、遅延とドロップの影響を受けやすい音声、リアルタイム ビデオなどのトラフィックが中断されることなく確実に受け渡されます。一般的には、中断は WAN エッジ ルータで発生します。WAN エッジ ルータでは、キロビット単位や低いメガビット/秒の低速リンクに、数百メガビットのトラフィックが集約される可能性があるからです。

新しいキュー方式の設定には、Modular QoS Command-Line Interface（MQC; モジュラ QoS コマンドライン インターフェイス）のコマンドを使用します。 MQC で最低保証帯域幅を指定するには、bandwidth コマンドを使用します。インターフェイス レベルのキューに対して絶対優先デキューを指定するには、priority コマンドを使用します。bandwidth コマンドは Class-Based Weighted Fair Queueing（CBWFQ; クラスベース WFQ）を実装し、priority コマンドは LLQ を実装します。詳細は、『QoS サービス ポリシーの bandwidth コマンドと priority コマンドの比較』を参照してください。

モデル/優先順位付けの方式

シスコでは、マルチサービス ネットワークについては、次に示すプライオリティ設定のスキームを推奨します。

^{1 LFI = Link Fragmentation and Interleaving（リンク フラグメンテーションおよびインターリービング）}

^{2 MLP = マルチリンク PPP}

^{3 CIR = Committed Information Rate（認定情報レート）}

モデル/優先順位付けのスキームの主要点をいくつか説明します。

• 音声は、Priority Queuing（PQ; プライオリティ キューイング）機能によってキューに入れられ、48 kbps の帯域幅が割り当てられます。このキューの入力基準は DSCP 値 EF、または IP 優先順位 5 です。インターフェイスに輻輳がある場合、48 kbps を超えるトラフィックはドロップされます。そのため、アドミッション制御メカニズムを使用して、トラフィックがこの値を超えないようにします。

• テレビ会議トラフィックは PQ 機能でキューに入力され、コールのデータ レートに 20% を上乗せした帯域幅を受け取ります。このキューの入力基準は DSCP 値 AF41、または IP 優先順位 4 です。インターフェイスに輻輳がある場合、コールのデータ レートを超えるトラフィックはドロップされます。したがって、音声の場合と同様、アドミッション制御メカニズムを使用して、トラフィックがこの値を超えないようにしなければなりません。特に、各スイッチ ポートに信頼関係を設定していない場合は、キュー アクセスにプロキシを使用します。ビデオ ターミナルを少数しか持たない小規模なサイトでのキュー アクセスには、ビデオ ターミナルの IP アドレスに基づいた Access Control List（ACL; アクセス コントロール リスト）を使用します。ACLを使用すると、IP precedence 4でトラフィックをマーキングするルータユーザから保護されます。このマークはゲートキーパー(CAC)をバイパスし、PQのすべてのビデオに影響を与えます。

  注：IP/TVなどの一方向ビデオトラフィックは、bandwidthコマンドを介してCBWFQを使用する必要があります。遅延耐性が高まります。

• WAN リンクで輻輳が発生すると、音声制御シグナリング プロトコルの処理が滞る可能性があります。その場合には、IP WAN 全体の IP 電話による通話を完了できません。H.323やSkinny Client Control Protocol(SCCP)などの音声制御プロトコルトラフィックでは、DSCP値AF31に等しい最小設定可能な帯域幅を持つ独自のクラスベース均等化キューが必要です。このDSCP値は3です。

• Systems Network Architecture（SNA; システム ネットワーク アーキテクチャ）のトラフィックは、指定された帯域幅 56 kbps のキューに入力されます。このクラスでのキューイング動作は FIFO であり、最小帯域幅の割り当ては 56 kbps です。このクラスで 56 kbps を超えるトラフィックは、デフォルト キューに入ります。TCP ポート番号、レイヤ 3 のアドレス、IP precedence、DSCP のいずれの条件によって、このキューに投入されるかどうかが決まります。

残りのトラフィックはすべてデフォルト キューに入ることができます。帯域幅を指定する場合、キューイング動作は FIFO です。または、キーワードの fair を指定している場合には、動作は Weighted Fair Queuing（WFQ; 重み付け均等化キューイング）になります。

また、768 kbps 未満のリンク速度では、テレビ会議を行わないでください。低速ビット レートのリンクの場合、Compressed RTP（cRTP; 圧縮 RTP）および LFI を使用すると、シリアル化およびキューイングへの遅延の影響を緩和できます。

IP テレビ会議には cRTP を使用しないでください。次に、cRTP におけるベスト プラクティスを示します。

• cRTPは、G.729などの低ビットレートの音声コーデックでのみ使用してください。音声またはビデオ会議コールの音声コーデックとしてG.711を使用すると、cRTPで達成する統計的スループットはcRTPの使用に十分ではありません。

• cRTP は、負荷全体で低ビットレートのボイスの割合が高い場合にのみ使用します。一般的には、1 回線に対する低ビットレートのボイスの割合が負荷全体の 30% を超える場合にのみ、この機能のメリットがあります。

• cRTP は転送パフォーマンスに影響する可能性があります。機能をイネーブルにした後に、CPU の使用率を監視します。

音声とビデオで LLQ を共有するかどうか

音声とテレビ会議のトラフィックをプライオリティ クラスに設定するかどうかについては、マルチサービスの QoS サービス ポリシーでは頻繁に検討の対象になります。プライオリティに複数のクラスを設定した場合であっても、LLQ で現在サポートされているのは単一の完全優先キューだけなので、この検討が必要になります。VoIP クラスとビデオ クラスにプライオリティをつけて設定しても、両方のクラスのトラフィックが単一のキューに入ります。したがって、ビデオをあえてプライオリティ キューに入れない場合もあります。

• ビデオ パケットはボイス パケットよりもずっと大規模です。通常、ビデオ パケットはリンクの最大 MTU と同じサイズです。EF がマークされていると、ビデオ パケットは音声と同じプライオリティ キューに入れることができます。小規模な VoIP パケットが、1 つまたは複数の大規模なビデオ パケットの後ろのキューに入った場合、VoIP パケットの遅延が大きくなります。遅延が重大な場合もあり、それが VoIP アプリケーションのパフォーマンスに悪影響を及ぼします。

• ほとんどのEFキューは非常に小さいため、ビデオトラフィックに使用するとパケットのドロップにつながる可能性があります。

シスコでは、プライオリティ キューにビデオを投入するテストを実施しました。テストでは、768 kbps より高いリンク速度が使用されており、また加入過多が発生しないように適切な CAC が使用されました。プライオリティ キューにビデオを投入しても、音声パケットの遅延が著しく増加しないことがわかりました。

一般に、次のモデルのうち 1 つを選択できます。シスコでは、両方のモデルについてテストを実施しました。

• プライオリティ キューに音声、ビデオ、オーディオ + 適切なプロビジョニングの使用

• 音声をプライオリティ キューに入れ、ビデオと音声を帯域幅キューに入れる

3 つめのアプローチは、テレビ会議の音声部分を切り離すことです。つまり、音声コンポーネントをプライオリティ キューに入れ、ビデオ コンポーネントを帯域幅キューに入れます。ただし、ビデオ コーダのコーディング遅延はボイス コーダよりも長い傾向にあります。そのため、テレビ会議のオーディオ ストリームに絶対的なプライオリティを与えた場合には、先に到着したオーディオ ストリームは、ビデオの同期と取るために保留されます。そのため、テレビ会議に関連づけられた音声パケットを、ビデオ パケットが受けるサービスより高いサービスを受けるキューに入れるメリットはありません。

ビデオと音声をプライオリティ キューに入れる場合は、トラフィック タイプを異なる DSCP 値でマーキングします。トラフィック タイプに異なった DSCP 値をマークすれば、QoS サービス ポリシーで異なった priority 文を使用してビデオを制御できます。特に、ビデオでは、ラージ バースト パラメータが必要になる場合があります。

CAC

トラフィックのプライオリティ設定で解決されるのは、Video over IP の QoS プロビジョニングに関する問題だけです。完全に解決するには、CAC が必要になります。

ネットワーク リソースの予約過多を防止するには、Call Admission Contro（CAC; コール アドミッション制御）による帯域幅の制御が必要です。テレビ会議で、新しい端末の追加によって、使用可能な帯域幅を超えてしまう場合は、既存のビデオ ストリームの品質を維持するために、このビデオ端末からのネットワーク リソースの要求を拒否する必要があります。つまり、CAC では他のビデオからビデオを保護します。

一般に、ビデオ コール用の CAC プロビジョニングには、次の 3 つの方式があります。

• ビデオ端末数を制限します。特に、H.323 ゲートキーパーが存在しないリモート サイトでは、WAN など、特定のリンク全体でビデオに使用する帯域幅を制御するための手段は一つしかありません。この場合、リモート サイトのビデオ端末の数を物理的に制限する必要があります。プライオリティ キューには、特定のサイトのすべてのビデオのエンドポイントの最大データ レートをサポートするのに十分な帯域幅をプロビジョニングします。

  注：ビデオ端末の最大データレートに20 %を加えたプライオリティキューをプロビジョニングします。追加された 20% によって、IP とトランスポートのオーバーヘッドをカバーできます。

• ゲートキーパーの CAC を使用して、イントラネットおよびインターネットのゾーンのコールの帯域幅に、セッション単位で制限を設定します。ゲートキーパーの CAC とプロキシを組み合せることによって、プライオリティ キューへの単一のアクセス ポイントを提供できます。この単一のアクセス ポイントによって、不正なビデオ ストリームによるプライオリティ キューの過剰予約が発生しなくなります。プロキシにアクセスできるようにするするには、ゲートキーパーにビデオ端末を登録する必要があります。ゲートキーパーの設定により、ローカル ゾーン外でビデオの最大帯域幅を確保できます。キューイング機能が正しく実行されるためには、この最大帯域幅がプライオリティ キューの帯域幅のプロビジョニングと一致している必要があります。これらのガイドラインは、ハブアンドスポークの環境だけ適用します。ゲートキーパーはダイレクト モードを使用しており、中継ゲートキーパーによってリンクの帯域幅が消費されないようにしています。

• RSVP を有効にしたエンドポイントを実装します。エンドポイントでは、RSVP メッセージを使用して、トラフィック プロファイルを記述し、必要なサービスを要求します。エンドツーエンド パス上の RSVP 対応ネットワーク デバイスでは、これらの RSVP メッセージを読み込んで、予約の要求を許可するか、または拒否するかを判断します。デバイスは、判断の結果を別の RSVP メッセージを介してエンドポイントに通知します。エンドポイントとそのアプリケーションは、会議を中断したり要件を減らしたりして利用可能なネットワーク条件に合わせるかどうかを判断します。

H.323 バージョン 4 の標準の付録 II では、RSVP を使用するためのアプローチを概説しています。主なポイントは次のとおりです。

• コールを発信すると、エンドポイントでは、リソースを予約するためにエンドポイントの処理能力をゲートキーパーに送信します。次に、ゲートキーパーは、エンドポイントのリソース予約の要求が妥当であるかどうかを示します。

• H.245 のフェーズの間、エンドポイントは、リソース予約の信号を送信できるかどうかを示します。この情報によって、エンドポイントはコールを処理するかどうかを決定します。

• RSVP の予約メッセージが送信されるのは、論理チャネルがオープンされてから、論理チャネルがデータ パケットに使用されるまでの間です。

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

WAN 接続でのフレーム リレーの使用では、さらに別の QoS の要件が必要になります。具体的には、高速の中央サイトが 1 つまたは複数の低速なリモート サイトに帯域幅を供給する場合、中央サイトがリモート サイトの物理帯域幅と CIR 帯域幅の両方をオーバーランすることがあります。リモート サイトに過剰な帯域幅が送られるのを防ぐため、中央サイトのルータにトラフィック シェーピングを実装します。フレームリレーのトラフィック シェーピングについての詳細は、次のリソースを参照してください。

• 7200 ルータおよび下位プラットフォームでのフレーム リレー トラフィック シェーピングの設定

• QoS（フラグメンテーション、トラフィック シェーピング、LLQ/IP RTP プライオリティ）が備わった VoIP over Frame Relay

H.323 端末とのインターワーキング

H.323 テレビ会議ネットワークは、通常 5 つの機能コンポーネントで構成されます。

• ビデオ端末

• ゲートキーパー

• ゲートウェイ

• MCU

• プロキシ

シスコは、ビデオ ターミナルを除くこれらすべてのコンポーネントの製品ソリューションを提供しています。シスコの H.323 製品は、サードパーティの H.323 端末との相互運用が可能であることが実証されています。

場合によっては、これらの端末には、予測不能なデータ フローに直面した場合に、ビデオ トラフィックの遅延および損失のパラメータを満たすために、QoS ツールが用意されています。たとえば、Polycom Viewstation では、コールが確立した後のすべてのビデオ パケットがトラッキングされます。Polycom Viewstation では、平均遅延時間や、ビデオ パケットまたは音声パケットを損失した数が報告されます。このツールでは、読みやすい形式で出力されるデバッグ機能もサポートされています。これらのデバッグは、ビデオの出力結果の分析では検出できない問題の原因を特定するのに役立ちます。詳細については、『Polycom ビデオ ユニットのための Video over IP の設定方法』を参照してください。

サンプル コンフィギュレーション

この設定例では、WAN リンクを通過するテレビ会議のトラフィックに LLQ を適用する方法を紹介します。

Sample Configuration 
class-map Video-Conf 
  match access-group 102 
class-map Streaming-Video 
  match access-group 103 
! 
policy-map QoS-Policy 
  class Video-Conf 
    priority 450 30000 
  class Streaming-Video 
    bandwidth 150 
class class-default 
    fair-queue 
! 
! -- Video-Conf Traffic 
access-list 102 permit ip any any dscp cs4 
access-list 102 permit ip any any dscp af41 
! 
! -- Streaming Traffic 
access-list 103 permit ip any any dscp cs1 
access-list 103 permit ip any any dscp af13

QoS ポリシー マップを作成した後で、service-policy コマンドでポリシーを適用します。ポリシーを適用するインターフェイスのタイプによって、コマンドの適用場所が決まります。次に例を示します。

line interface multilink1 
  service-policy output QoS-Policy 

interface atm 1/0.1 point 
  pvc 1/50 
    service-policy output QoS-Policy

map-class frame-relay vcofr 
  frame cir 128000 
  frame mincir 64000 
  frame bc 1000 
  frame frag 160 
  service-policy output QoS-policy 

^{1 PVC = Permanent Virtual Circuit（相手先固定回線接続）}

^{2 VC = Virtual Circuit（仮想回線）}

^{3 DTS = Distributed Traffic Shaping（分散トラフィック シェーピング）}

関連情報

• ITU H.323 Standard
• H.323 VoIP ゲートウェイ用のコールアドミッション制御
• インターネットワーキング テクノロジーの概要：Quality of Service Networking
• QoS に関するサポート ページ
• テクニカルサポート - Cisco Systems