Video Quality of Service(QOS)チュートリアル

ダウンロード オプション

  • PDF     (458.1 KB)
    Adobe Reader を使ってさまざまなデバイスで表示
  • ePub     (209.9 KB)
    iPhone、iPad、Android、ソニーの Reader、または Windows Phone 上で、さまざまなアプリを使って表示
  • Mobi (Kindle)     (223.0 KB)
    Kindle デバイスで、または Kindle アプリを使って複数のデバイスで表示
Updated: 2017 年 9 月 18 日
Document ID:212134

偏向のない言語

この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。

翻訳について

シスコは世界中のユーザにそれぞれの言語でサポート コンテンツを提供するために、機械と人による翻訳を組み合わせて、本ドキュメントを翻訳しています。ただし、最高度の機械翻訳であっても、専門家による翻訳のような正確性は確保されません。シスコは、これら翻訳の正確性について法的責任を負いません。原典である英語版（リンクからアクセス可能）もあわせて参照することを推奨します。

    概要

    このドキュメントでは、ビデオコール品質について説明し、Quality of Service(QoS)がCisco Unified Border Element(CUBE)または時分割多重(TDM)ゲートウェイで設定されている場合に留意すべき事項のチュートリアルを提供します。

    著者：Anoop Kumar、編集：Cisco TACエンジニア、Baktha Muralidharan

    前提条件

    要件

    このドキュメントは、Voice over IP(VoIP)に精通しているエンジニアにとって最も有益ですが、他のエンジニアにとっては有用なドキュメントです。

    使用するコンポーネント

    このドキュメントの作成に使用される特定のハードウェアまたはソフトウェアはありません。

    背景説明

    最も簡単な形式でデジタル化された音声は、一連の音声サンプルであり、各サンプルはその期間の音圧を記述します。  会話音声をキャプチャし、高い精度で再生できます。1秒あたり8000サンプルです[1]。  これにより、ネットワークが過度の遅延、ジッタ、およびパケット損失なしでサンプルを転送できる限り、音声を相手側で忠実に再生できます。

    対照的に、ビデオの処理と転送は、はるかに複雑です。明るさ、コントラスト、色の彩度、応答性（動き）、リップシンクは、ビデオの品質を決定する属性の一部にすぎません。一般的に、ビデオサンプルにはより大きなスペースが必要です。当然ながら、ビデオはトランスポートネットワークのネットワーク帯域幅に対する要求を大きく高めます。オーディオ品質は、ヘッドセットコーデックの：Microphone Speakerによって決まります。圧縮トランスポートネットワークのビデオコール品質は、次の影響を受けます。カメラディスプレイデバイスのビデオコーデックトランスポートネットワークの互換性/相互運用性

    注：  オーディオとは異なり、ビデオエンドポイントでは品質の調整に関して非常に多くのビットが使用されることを理解することが重要です。

    目的

    一般的なQoSは、トラフィック全体の要件（単に品質を向上させたいトラフィックではなく）を考慮する必要があり、メディアフローのパスに沿って各ネットワークコンポーネントをチェックする必要があります。ビデオ会議でのビデオ品質の実現は、ネットワークコンポーネントに加え、エンドポイントでの設定と調整のレビューと調査に、さらに複雑になります。ビデオの品質には、次のような特徴があります。

    • エンドポイントの調整：エンドポイントの設定の最適化（解像度、フレーム/秒など）
    • トランスポートの最適化：ネットワークSLAごとにビデオトラフィックを転送するようにネットワークを最適化します。
    • 相互運用性に関する考慮事項：多くの場合、ビデオコールには多様な機能を持つエンドポイントが含まれます。相互運用性を最大限に高めるためにシステムを設計および構成すると、ビデオ品質に影響を及ぼします。

    このドキュメントでは、ビデオコールを処理する際のIOSゲートウェイまたはCUBEのQoSに関する考慮事項に焦点を当てます。

    エンドポイントでの調整には、ビデオエンドポイントの一連のパラメータの調整が含まれます。これは製品によって異なりますが、一般的な「ノブ」をいくつか紹介します。

    • 解像度（画像サイズ）
    • フレームレート（モーション感度/リアリティ）
    • タギング（ToSマーキング）

    ビデオ用のネットワークの調整は、一般に次の作業を行います。

    • CUBEを通過するトラフィックの構成（ピーク[call]ボリュームなど）の理解
    • ネットワークリンク/パイプ容量の確認
    • 各トラフィッククラスのSLAを確実に満たすように、適切なQoSポリシーを設計する

    異種(ビデオテレフォニーおよびテレプレゼンス(TP))システムが会議コールに参加すると、相互運用性が実現します。TPとビデオ電話システムによって提供されるエクスペリエンスは根本的に異なります。これらの間の相互運用性は、一般に、カスケードと呼ばれるプロセスを使用してブリッジングすることで実現されます。

    これでは説明できない内容

    これは設計文書ではなく、包括的なビデオQoS文書でもありません。具体的には、次のトピックは扱いません。

    • ビデオコールのシグナリング[プロトコル]は、qos関連の説明に必要な機能を超えています。
    • ビデオエンドポイントの設定/設定
    • ポリシング、キューイング、シェーピング、およびバーストを含むQoSメカニズムの包括的なレビュー
    • レイヤ2スイッチのQoS設定または信頼境界に関する考慮事項のレビュー

    ビデオのネットワークトラフィック特性

    音声のようなビデオはリアルタイムです。 オーディオ伝送は固定ビットレート(CBR)です。 これに対し、ビデオトラフィックはバースト性が高く、可変ビットレート(VBR)と呼ばれます。そのため、一定の品質を維持する必要がある場合は、ビデオ伝送のビットレートは必ずしも一定ではありません[2]。

    画像 1

    ビデオに必要な帯域幅とバーストの決定も、より複雑です。これについては、このドキュメントで後述します。

    • ビデオトラフィックはバースト性があります。
    • ビデオパケットが非常に大きくなる可能性があります。
    • オーディオは常にCBRです。ビデオは通常VBRです。 

    なぜビデオはバースト性があるのですか。

    答えは、ビデオの圧縮方法にあります。ビデオは、視覚的なモーション効果を提供するために再生される一連の画像（フレーム）であることに注意してください。ビデオコーデックで使用される圧縮技術では、デルタ符号化[3]と呼ばれるアプローチが使用されます。これは、バイトの値を値自体ではなく、連続した（サンプル）値の差分（差分）として保存します。これにより、ビデオは、フレーム全体ではなく「動き部分」のみを運ぶ連続フレームとして符号化（伝送）される。

    オーディオも徐々に変わっていくのではないでしょうか？確かに、「動き」（またはダイナミクス）は、ビデオとほぼ同じ程度の影響をオーディオに与えません。8ビットのオーディオサンプルは、デルタでエンコードされた場合は圧縮が適していません。ビデオサンプル（フレーム）は圧縮されます。サンプル(フレーム間)からサンプルへの相対的な変化は、ビデオがオーディオの変化よりもはるかに小さいことです。動きの性質や程度に応じて、ビデオのサンプルのサイズは大きく異なります。

    画像 2

    Iフレームは、通常の静的イメージファイルのように、実際には完全に指定されたピクチャです。

    Pフレーム(予測画像)は、前のフレームからの画像の変化のみを保持する。エンコーダは、不変の背景ピクセルをPフレームに格納する必要がないため、省スペース化を図ることができる。Pフレームはデルタフレームとも呼ばれます。

    Bフレーム(Bi-predictive picture)は、現在のフレームと前後のフレームの差分を使用して内容を指定することで、さらに多くのスペースを節約します。

    ビデオ品質測定

    シスコのビデオ機器は、このようなビデオ品質の測定やレポートを行わないため、ビデオ品質は測定ではなく認識されます。MOS（平均オピニオン評点）を用いて品質を測定する標準化されたアルゴリズムがあります。 ただし、音声品質に関して報告された問題が何らかの指標である場合、ユーザがツールで報告するのではなく品質の問題を認識しているため、ビデオ品質(TAC)ケースを開く可能性が高くなります。

    エンドポイントでの制御

    ビデオ品質に影響を与える要因は次のとおりです。

    • ビデオコーデック(MPEG4、H261、H263、H264、H265)
    • サイズ（1/8画面、1/4画面、全画面表示）
    • フレームレート（1 ～ 30フレーム/秒、デフォルトは6つ）
    • 圧縮品質設定（低、中、高）

    一般に、上記の各エンドポイントは選択可能/制御可能です。

    可視アーティファクト

    キルティング、コーミング&バンドは、ビデオ障害の分類の一部として、これらの用語に使用されます。一般的なビデオ障害の詳細については、次のドキュメントを参照してください。

    参照： 

    http://www.estadistica.cl/public_disk/Programas/DeTodo/Manejo y pegado de subtitlos/VirtualDub-1.6.14/help/p-artifacts.html

      

    ビデオ品質のトランスポートネットワークSLA

    ビデオ[4]に対して推奨されるネットワークSLAは次のとおりです。

    • 遅延≤ 150 ～ 300 ms
    • ジッター≤ 10ミリ秒～50ミリ秒
    • 損失≤ 0.5%

    ちなみに、音声を転送するための推奨ネットワークSLAは次のとおりです。

    • 遅延≤ 150 ～ 300 ms
    • ジッター≤ 20ミリ秒～50ミリ秒
    • 損失≤ 1 %

    注：  明らかに、ビデオは音声よりもパケット損失に敏感です。  インターフレームには前のフレームからの情報が必要であることを理解したら、これは予期されるべきです。つまり、インターフレームの損失はビデオ画像の再構築プロセスに壊滅的な影響を与える可能性があります。

    トランスポートネットワークの制御

    一般に、ビデオ転送のSLAは、音声転送に使用されるSLAに非常によく似たQoSポリシーを使用して配信できます。ただし、ビデオトラフィックの特性により、いくつかの違いがあります。

      

    注：  このドキュメントの範囲はCUBEコンポーネントに限定されていますが、QoSはエンドツーエンドであることに注意してください。

    ビデオの種類

    ビデオはすべて同じですか。まぁそうじゃなくて。メディアとしてのビデオのバリエーションは次のとおりです。

    • ビデオテレフォニー/ビデオ会議
      • リアルタイムインタラクティブ
      • 帯域幅が比較的低い。最大1 Mbps
    • Telepresence
      • リアルタイムインタラクティブ
      • 臨場感のある体験
      • 非常に高い帯域幅が必要
    • ストリーミング
      • リアルタイム、単方向
      • ユニキャストまたはマルチキャスト
      • 高帯域幅
      • 遅延の影響を受けない（ビデオのキューに数秒かかる場合がある）
      • ジッターに大きく影響されない（アプリケーションバッファリングによる）
      • 損失は5%以下でなければなりません。
      • 遅延は4 ～ 5秒を超えないようにする必要があります（ビデオアプリケーションのバッファリング機能によって異なります）
      • 一部のビデオ（エンターテイメントなど）はスカベンジャサービスに考慮される可能性があります。

    注：  簡潔にするために、上記のビデオの種類ごとに図が広く提供されているわけではありません。

    ビデオトラフィックコーデック

      • H.261-Codecは元々ISDN回線での伝送用に設計されていました。ビデオボンディングを使用すると、ビデオビットレートは64 Kbit/sの倍数になります。
      • H.263：コーデックは、IPベースのビデオ会議およびISDNネットワークで使用されます。H.263は、H.261と同じビデオ品質を実現するために半分の帯域幅を必要とします。その結果、H.263はH.261に代わって大きく置き換えられました。
      • H.264/MPEG-4 - Csは現在、最も一般的に使用されている形式の1つであり、MPEG-2、H.263、MPEG-4 Part 2のビットレートの半分または少ない。
      • H265 – 広く使用されているH.264の潜在的な後継者の1つ。同じ概念の拡張に基づいています。8192×4320までの解像度（8K UHDを含む）をサポートします。

    注：  音声と同様に、ビデオはリアルタイムプロトコル(RTP)で伝送されます

    ビデオのQoSメカニズム

    原則として、ビデオ伝送ネットワークのSLAを提供するために使用されるQoSメカニズムは、主にオーディオのものと同じです。ただし、ビデオおよびVBR伝送のバースト性が主な原因で、いくつかの違いがあります。

    QoSには、Interated Services(intserv)とDifferentiated Services(diffserv)の2つのアプローチがあります。

    Intservはシグナリングレベルで動作し、Diffservはメディアレベルで動作します。つまり、intservモデルはコントロールプレーンで動作することで品質を保証します。diffservは、データプレーンのレベルで動作することで品質を確保することを目的としています。

    IntServアーキテクチャネットワークデバイスは、スタティック帯域幅予約を要求し、すべての予約フローの状態を維持しながら、これらのフローの分類、マーキング、およびキューイングを実行します。IntServアーキテクチャは、コントロールプレーンとデータプレーンの両方を動作および統合します。そのため、固有のスケーリングの制限により、大部分が放棄されています。帯域幅予約に使用されるプロトコルは、RSVP(Resource reSerVation Protocol)です。

    IntServ/DiffServモデルもあります。これは組み合わせと呼ばれます。このモデルは、コントロールプレーン操作とデータプレーン操作を分離します。RSVPの動作は、アドミッション制御のみに限定されます。分類、マーキング、ポリシング、およびスケジューリング操作を処理するDiffServメカニズム。そのため、IntServ/DiffServモデルは非常にスケーラブルで柔軟です。

    注：  このドキュメントでは、diffserv（viz-a-viz優先順位付け方式、LLQ）アプローチのみに焦点を当てています。

    帯域幅保証

    帯域幅は明らかに、最も基本的なqosパラメータです。 これは、次のようなパラメータに依存します。

    • 使用コーデック
    • フレーム レート

    • Image size
    • コール量（ピークおよび平均）

    問題に対して帯域幅を投入する古い方法が、必ずしも解決策であるとは限りません。これは、特にビデオ品質に当てはまります。たとえば、CUVA(Cisco Unified Video Advantage)では、2台のデバイス（電話機とPC）間の同期メカニズムは使用されません。したがって、QoSを設定して、ジッタ、遅延、フラグメント化されたパケット、および不正なパケットを最小限に抑える必要があります。

    注：  Interactive Videoは、音声コールがビデオストリームに組み込まれるため、VoIPと同じサービスレベル要件を持ちます。ストリーミングビデオは、アプリケーションに組み込まれた大量のバッファリングにより、はるかに緩和の要件を持っています。

    最後に、VoIPとは異なり、必要な増分帯域幅を計算するための明確な式がないことを理解することが重要です。これは、ビデオパケットサイズとパケットレートが大きく異なり、送信されるビデオ画像内の動きの程度の関数が大きいためです。詳細については後で説明します。

    キューイング

    低遅延キューイング(LLQ)は、VoIP音声に適したキューイングポリシーです。TPの厳しい遅延/ジッタの影響を受けやすい要件と、CUVAの音声とビデオを同期する必要があるため、すべてのビデオトラフィックに対してもプライオリティ(LLQ)キューイングが推奨されます。ビデオの場合、プライオリティ帯域幅は一般に20 %増加します。



    ヘッダ圧縮

    ビデオには推奨されません。

    Link Fragmentation and Interleaving

    LFIは、シリアライゼーション遅延が大きくなる可能性がある低速リンクでジッタが制御できなくなることを保証する一般的なメカニズムです。

    ただし、低速リンクではインタラクティブビデオは推奨されません。これは、ビデオトラフィックが割り当てられているLLQがフラグメンテーションの対象ではないためです。これは、大きなインタラクティブビデオパケット（1500バイトのフルモーションIフレームなど）が、小さなインタラクティブビデオパケットのシリアル化遅延を引き起こす可能性があることを意味します。

    輻輳回避

    RTCPに基づく選択的廃棄

    バースト

    このQoSメカニズムは、前述したようにバースト性のあるビデオトラフィックにとって重要です。

    オプションのバーストパラメータは、priorityコマンド[6]の一部として設定できます。

    H.264では、最悪のケースのバーストは（空間的に圧縮された）ビデオの全画面です。TPシステムの広範なテストに基づくと、64 KBであることがわかりました。したがって、LLQバーストパラメータは、1画面あたりフレームあたり最大64 KBのバーストを許可するように設定する必要があります。したがって、1080p-Bestで動作するCTS-1000システム(補助ビデオストリーム[7]をオプションでサポート)は、最適なバーストパラメータが128(2x64) KBのLLQで設定されます。

    帯域幅

    ビデオコールを忠実に転送するには、どの程度の帯域幅が必要ですか。計算に入る前に、ビデオに固有の次の概念を理解することが重要です。

    解決方法

    これは基本的にイメージのサイズを指します。  この他の一般的な用語には、ビデオ形式や画面サイズが含まれます。  一般的に使用されるビデオ形式を次に示します。

    書式

    ビデオ解像度（ピクセル）

    SQCIF

    128x96

    QCIF

    176x144

    SCIF

    256x192

    SIF

    352x240

    CIF

    352x288

    DCIF

    528x384

    4CIF

    		  

    704x576

    16CIF

    1408x1152

    ほとんどのビデオ会議機器は、CIFまたは4CIF形式で動作します。

    参照：http://en.wikipedia.org/wiki/Common_Intermediate_Format

    注：  オーディオの世界では（ビデオ）の解決には等価ではありません

    フレーム レート


    これは、撮像素子がフレームと呼ばれる一意の連続した画像を生成する割合を指します。フレームレートは、フレーム/秒(fps)で表されます。

    注：  オーディオの世界で同等のメトリックは、サンプリング時間です。例：g.711ulawの8000

    帯域幅計算

    ビデオテレフォニーシステムやその他の従来のビデオ会議システムの帯域幅計算は、より簡単になる傾向があります。

    例として、解像度が1080 x1920のTPコールを考えます。  必要な帯域幅は次のように計算されます。

         2,073,600ピクセル/フレーム

            x3カラー/ピクセル

            x1バイト（8ビット）/カラー

            x 30フレーム/秒

            = 1画面あたり1.5 Gbps非圧縮！

    圧縮を使用すると、上記のフレームを転送するのに十分な帯域幅が画面あたり4 Mbps（圧縮99 %以上）になります。

    次の表に、いくつかの組み合わせを示します。

    画像
    書式

    輝度
    ピクセル

    輝度
    回線

    非圧縮
    ビットレート(Mbit/s)

    10フレーム/秒

    30フレーム/秒

    グレー

    色

    グレー

    色

    SQCIF

    128

    96

    1.0

    1.5

    3.0

    4.4

    QCIF

    176

    144

    2.0

    3.0

    6.1

    9.1

    CIF

    352

    288

    8.1

    12.2

    24.3

    36.5

    4CIF

    704

    576


    32.4

    48.7

    97.3

    146.0

    16CIF

    1408

    1152

    129.8

    194.6

    389.3

    583.9

    上記の計算は1画面で行われることに注意してください。TPコールには複数の画面が含まれる可能性があるため、コールの合計帯域幅は画面ごとの帯域幅の倍数になります。

    Cisco TPシステムに適した帯域幅カルキュレータについては、https://supportforums.cisco.com/thread/311604を参照してください。

    ビデオトラフィックの分類/マーキング

    ビデオトラフィックはどのように特定または区別されますか。CUBEでパケットを分類する1つの方法は、DSCPマーキングを使用することです。

    次の表に、RFC 4594に加え、Cisco QoSベースラインごとのDSCPマーキングを示します。

    トラフィック

    レイヤ3 PHB

    レイヤ 3 DSCP

    コールシグナリング

    CS3

    24

    音声

    EF

    46

    ビデオ会議

    AF41

    34

    TelePresence

    CS4

    32

    マルチメディアストリーミング

    AF31

    26

    ブロードキャストビデオ

    CS5

    40

    PHB：ホップ単位の動作。ルータがパケットの分類やトラフィックの調整機能（計測、マーキング、シェーピング、ポリシングなど）に対して行う処理を指します。

    デフォルトでは、バージョン9.0より前のCUCM(Cisco Unified Call Manager)では、すべてのビデオトラフィック（TelePresenceを含む）がAF41にマーキングされています。バージョン9.0以降では、CUCMは次のDSCP値を事前設定します。

    • CS4およびCS4でのTelePresence（イマーシブビデオ）コール
    • AF41でのビデオ（IPビデオテレフォニー）コール

    コンフィギュレーション

    音声品質を調整するようにを設定するには、優先帯域幅の計算とWANリンクでのLLQポリシーの実装が必要です。これは通常、予想されるコール量と使用されるオーディオコーデックに基づいています。

    原則は同じですが、CUBEを介したビデオ帯域幅はそれほど簡単に計算できません。これは、次のようなさまざまな要因が原因です。

    • 異なるTPコール（CUBEを通過する）に必要な合計帯域幅を計算する方法は、画面の数や解像度が異なる場合があります。
    • バースト性とVBR
    • 複雑さの別の側面（帯域幅計算）は、「相互運用性コール」と関係がありますか。  相互運用性コールはTIPを使用します。TIPは、Telepresence Interoperability Protocolの略です。TIPは、複数の画面、複数のオーディオストリーム、および補助データ画面を2つのRTPフローに多重化するために使用され、それぞれビデオとオーディオ用に1つずつ使用されます。ポイントツーポイントおよびマルチポイントセッションに加え、マルチスクリーンとシングルスクリーンのエンドポイントを混在させることができます。TIPはシスコ独自のプロトコルです。TIPはRTCPに基づいています。

    したがって、ビデオシステムの帯域幅プロビジョニングは逆の順序で行われる場合があります。つまり、トランスポートネットワークがLLQポリシーで提供できる帯域幅の量が最初に決定され、それに基づいてエンドポイントが設定されます。エンドポイントビデオシステムは、パイプサイズのさまざまなビデオパラメータを調整するのに十分なスマートです。したがって、エンドポイントはコールに信号を送信します。

    CUBE帯域幅処理

    では、ビデオコールのシグナリング時に、CUBEは(SIP)のオファー/応答でどのように帯域幅を処理するのでしょうか。CUBEは、次のようにSDPのビデオ帯域幅フィールドに入力します。

      1.着信SDPの帯域幅属性から。SDPには、値が参照するビットレートのタイプを指定する修飾子を持つ帯域幅属性があります。  この属性の形式は次のとおりです。b=<修飾子>:<値>

      2. CUBEで設定されたビデオ帯域幅から。たとえば、推定最大帯域幅はCTSユーザが使用する機能に基づいて計算され、推定帯域幅はCLIを使用してCUBEで事前設定されます。

    • <bandwidth video tias-modifier>または
    • <bandwidth video as-modifier>

      3.デフォルトのビデオ帯域幅(384 Kbps)

    次に示すコールフローは、CUBEがコールシグナリングメッセージの帯域幅を入力する方法を示しています。

    具体的には、CUBEは次のロジックを使用します。

    • オファー（DOコール）では、CUBEは設定された帯域幅を使用します。
    • オン（EOに対する回答）では、CUBEはオファーとローカル設定の最小値を値とする帯域幅を送信します。

    SDPセッションレベルでは、TIAS値は、宣言されたすべてのメディアストリームが使用される場合に必要な最大帯域幅[8]です。

    ビデオコーデックペイロードタイプ

    これは、ビデオと音声が異なる別の領域です。 オーディオコーデックは静的ペイロードタイプを使用します。一方、ビデオコーデックは、96 ～ 127の範囲を使用するダイナミックRTPペイロードタイプを使用します。

    動的ペイロードタイプを使用する理由は、ビデオコーデックの広い適用性に関係しています。ビデオコーデックには、送信されるストリームのプロパティをレシーバに提供するパラメータがあります。ビデオペイロードタイプは、a=rtpmapパラメータを使用してSDPで定義されます。また、"a=fmtp:"属性を使用してフォーマットパラメータを指定することもできます。fmtp文字列は不透明で、反対側に渡されます。

    インターフェイスが -

    m=video 2338 RTP/AVP 97 98 99 100
c=IN IP4 192.168.90.237
b=TIAS:768000
a=rtpmap:97 H264/90000
a=fmtp:97 profile-level-id=42800d;max-mbps=40500;max-fs=1344;max-smbps=40500
a=rtpmap:98 H264/90000
a=fmtp:98 profile-level-id=42800d;max-mbps=40500;max-fs=1344;max-smbps=40500;packetiza tion-mode=1
a=rtpmap:99 H263-1998/90000
a=fmtp:99 custom=1024,768,4;custom=1024,576,4;custom=800,600,4;cif4=2;custom=720,480,2 ;custom=640,480,2;custom=512,288,1;cif=1;custom=352,240,1;qcif=1;maxbr=7680
a=rtpmap:100 H263/90000
a=fmtp:100 cif=1;qcif=1;maxbr=7680

    コールに関係する2つのエンドポイントが、同じコーデックに異なるペイロードタイプを使用する場合があることに注意してください。CUBEは、反対側のレッグで受信したa=rtpmap回線で各側に応答します。これは、ビデオコールが機能するためには、設定「非対称ペイロードがいっぱいです」が必要であることを意味します。

    L2帯域幅

    音声とは異なり、リアルタイムのIPビデオトラフィックは一般に、バースト性のある可変ビットレートストリームです。したがって、音声とは異なり、ビデオにはネットワークオーバーヘッドを計算するための明確な公式はありません。ビデオパケットのサイズとレートは、ビデオ画像自体の動きの度合いに比例して変化するためです。ネットワーク管理者の観点からは、帯域幅は常にレイヤ2でプロビジョニングされますが、パケットがエンドツーエンドで通過する可能性のあるパケットサイズやレイヤ2メディアの多様性により、レイヤ2でプロビジョニングする実際の帯域幅を計算することは困難です。これにより、レイヤ2からレイヤ4への10 %バーストとネットワークオーバーヘッドに対応できます。

    モニタリング/測定

    前述のように、ビデオエンドポイントはMOSを報告しません。ただし、次のツールを使用して、転送ネットワークのパフォーマンスを測定/監視したり、ビデオ品質を監視したりできます。

    IP SLAのビデオ

    IOSに組み込まれた機能であるIP SLA（サービスレベル契約）は、ネットワークパフォーマンスのアクティブモニタリングを実行します。IP SLAのビデオ操作は、すべてのトラフィックが一方向のみであるという点で他のIP SLA操作とは異なり、応答側はシーケンス番号とタイムスタンプをローカルに処理し、送信元からの要求を待ってから計算データを返送する必要があります。

    現在のビデオ操作が完了すると、送信元から応答側に要求が送信されます。この要求は、応答側に対して、パケットがこれ以上到着せず、ビデオ操作のビデオシンク機能をオフにできることを通知します。応答側からの応答が送信元に到達すると、メッセージから統計情報が読み取られ、操作の関連フィールドが更新されます。

    CiscoWorks IPM(IOS Performance Monitor)は、IP SLAプローブとMediaTrace[9]を使用して、ユーザトラフィックのパフォーマンスとレポートを測定します。

    CUBE VQM

    CUBEで利用可能なVQM（ビデオ品質モニタ）機能は、2つの関心点間のビデオ品質をモニタする優れたツールです。結果はMOSとして表示されます。

    これは、IOS 15.2(1)T以降で利用可能です。VQMはDSPリソースを使用することに注意してください。

    参考


    [1]約4000Hzのオーディオの最高可聴周波数に基づく。参照：ナイキストの定理。

    [2]CBR(Constant Bit Rate)伝送方式はビデオで可能です。ただし、品質を犠牲にしてCBRを維持します。

    (3)フレーム間圧縮の場合

    [4]TPに関しては、SLAの方が厳しいことに注意してください。

    (5)ライフサイズ画像と高品質オーディオ

    [6]このパラメータのデフォルト値は、プライオリティ帯域幅でのトラフィックの200ミリ秒です。Cisco LLQアルゴリズムは、トラフィックの200 ms相当のデフォルトバーストパラメータを含むように実装されています。テストでは、このバーストパラメータでは、単一のIP Videoconferencing(IP/VC)ストリームに対する追加の調整が不要であることが示されています。複数のストリームの場合、このバーストパラメータは必要に応じて増やすことができます。

    [7]補助ビデオストリームは、データプロジェクタでプレゼンテーションやその他の販促品を共有するための5 fpsビデオチャネルです。

    [8]一部のシステムでは、「AS」（アプリケーション固有）修飾子を使用して最大帯域幅を伝達することに注意してください。  この属性の解釈は、アプリケーションの最大帯域幅の概念によって異なります。

    CUBEは、特定の帯域幅修飾子（TIASまたはAS）に依存しません。

    [9]Mediatraceは、IPフローのパスに沿ってルータとスイッチを検出するIOSソフトウェア機能です。

     StartSelection:0000000199 EndSelection:0000000538

    TAC Authored

    シスコ エンジニア提供

    • Baktha Muralidharan
      Cisco TAC Engineer
    • Edited by Anoop Kumar
      Cisco TAC Engineer

    このドキュメントは役に立ちましたか?

    Feedbackフィードバック

    シスコに問い合わせ