メインコンテンツまでスキップ

4. Media Prioritization (メディア優先順位付け)

WebRTC優先順位付けモデルでは、アプリケーションはAPIから制御されるメディアとデータの優先度についてWebRTCエンドポイントに通知します.

このコンテキストでは、「フロー (Flow)」は、WebRTC APIを通じて特定の優先度が与えられる単位に使用されます.

メディアの場合、「メディアフロー (Media Flow)」(「オーディオフロー (Audio Flow)」または「ビデオフロー (Video Flow)」のいずれか)は、[RFC7656] が「メディアソース (Media Source)」と呼ぶものであり、「ソースRTPストリーム (Source RTP Stream)」と1つ以上の「冗長RTPストリーム (Redundancy RTP Streams)」を生成します. この仕様は、単一のメディアソースから来るRTPストリーム間の優先順位付けについては説明していません.

WebRTCのすべてのメディアフローは、[RFC4594] で定義されているように、インタラクティブであると想定されています; メディアがインタラクティブか非インタラクティブかを示すためのブラウザAPIサポートはありません.

「データフロー (Data Flow)」は、単一のWebRTCデータチャネル上の送信データです.

メディアフローまたはデータフローに関連付けられた優先度は、「very-low (非常に低い)」、「low (低い)」、「medium (中程度)」、または「high (高い)」として分類されます. APIには4つの優先度レベルのみがあります.

優先度設定は、2つの動作に影響します: パケット送信シーケンスの決定とパケットマーキング. それぞれは以下の独自のセクションで説明されています.

4.1. Local Prioritization (ローカル優先順位付け)​

ローカル優先順位付けは、パケットが送信される前にローカルノードで適用されます. これは、優先順位付けが個々のパケットに関するデータへの完全なアクセスを持ち、パケットが属するストリームに基づいて異なる処理を選択できることを意味します.

WebRTCエンドポイントが同じ輻輳制御体制下で輻輳制御される複数のストリーム上で送信するパケットを持っている場合、WebRTCエンドポイントは、各優先度レベルの各ストリームが下位レベルの約2倍の伝送容量(ペイロードバイト単位で測定)を与えられるようにデータを出力すべきです (SHOULD).

したがって、輻輳が発生した場合、両方が送信するデータを持っている場合、高優先度フローは非常に低優先度フローの8倍のデータを送信できます. この優先順位付けはメディアタイプから独立しています. どのパケットを最初に送信するかの詳細は実装定義です.

たとえば、100バイトのパケットを送信する高優先度オーディオフローと1000バイトのパケットを送信する低優先度ビデオフローがあり、> 5000ペイロードバイトを送信する送信容量が存在する場合、単一の送信決定のパスの結果として4000バイト(40パケット)のオーディオと1000バイト(1パケット)のビデオを送信することが適切です.

逆に、オーディオフローが低優先度とマークされ、ビデオフローが高優先度とマークされている場合、> 2500ペイロードバイトを送信する送信容量が存在するときに、スケジューラは2つのビデオパケット(2000バイト)と5つのオーディオパケット(500バイト)を送信することを決定する可能性があります.

2つの高優先度オーディオフローがある場合、低優先度ビデオフローが1000バイトを送信できる同じ期間に、それぞれが4000バイトを送信できます.

2つの実装戦略の例は次のとおりです:

  • 輻輳制御アルゴリズムから利用可能な帯域幅がわかっている場合、各コーデックと各データチャネルを、利用可能な帯域幅のシェアに適したターゲット送信レートで設定します.

  • 輻輳制御が指定された数のパケットを送信できることを示した場合、接続全体で重み付けラウンドロビン方式を使用して、送信可能なパケットを送信します.

伝送容量の分配がおおよそ正しい限り、これらの任意の組み合わせ、または同じ効果を持つ他のスキームは有効です.

メディアの場合、送信に深いキューを使用することは通常不適切です; より有用なのは、たとえば、より低いビットレートを達成するために、それらに依存関係のない中間フレームをスキップすることです. 信頼できるデータの場合、キューは有用です.

この仕様は、異なるストリームがいつ「同じ輻輳制御体制下で輻輳制御される」かを規定していないことに注意してください. 輻輳コントローラの結合の問題は、[RFC8699] でさらに検討されています.

4.2. Usage of Quality of Service -- DSCP and Multiplexing (サービス品質の使用 -- DSCPと多重化)​

パケットが送信されると、ネットワークは通信の品質に影響を与える可能性のあるパケットのキューイングおよび/または破棄について決定を行います. 送信者は、これらの決定に影響を与えるためにパケットのDSCPフィールドを設定しようと試みることができます.

実装は、[RFC8837] のガイドラインに従って、送信されるパケットにQoSを設定しようと試みるべきです (SHOULD). QoSマーキングが実装されていないプラットフォームで実行する場合、この推奨事項から逸脱することは適切です.

実装は、優先度の反転や特定のDSCPマーキングを持つパケットのブロックなど、予期しない動作の症状を検出した場合、DSCPマーキングの使用をオフにしてもよい (MAY) です. そのような動作のいくつかの例は [ANRW16] で説明されています. これらの条件の検出は実装依存です.

特に困難な問題は、1つのメディアトランスポートが複数のDSCPを使用し、1つがブロックされ、別のものが許可される可能性がある場合です. これは、[RFC8837] のビデオの単一メディアフロー内でも許可されています. 実装はこのシナリオを診断する必要があります; 可能な実装の1つは、DSCP 0で初期ICEプローブを送信し、候補ペアが選択されたら、使用する予定のすべてのDSCPでICEプローブを送信することです. 1つ以上のDSCPマークされたプローブが失敗した場合、送信者はメディアタイプをDSCP 0の使用に切り替えます. これは初期メディアトラフィックと同時に実行できます; 失敗時には、初期データを再送信する必要がある場合があります. もちろん、この切り替えは、その時点までに収集された輻輳情報を無効にします.

障害は通話の寿命中に発生し始めることもあります; このケースはまれであると予想され、トランスポート障害の通常のメカニズムによって処理できます。これにはICE再起動が含まれる場合があります.

DSCPが配信不能を引き起こす場合、単一のメディアフローのすべてのトラフィックが輻輳制御のために同じキューにある必要があるため、メディアフロー全体をDSCP 0に切り替える必要があることに注意してください. 異なるDSCPを使用する同じトランスポート上の他のフローは変更する必要はありません.

データチャネルをサポートするSCTPアソシエーションからのデータを運ぶすべてのパケットは、単一のDSCPを使用しなければなりません (MUST). 使用されるコードポイントは、運ばれる最高優先度のデータチャネルに対して [RFC8837] で推奨されるものであるべきです (SHOULD). これは、すべてのデータパケットが、相対的な優先度に関係なく、ネットワークによって同じように扱われることを意味することに注意してください.

1つのTCP接続上のすべてのパケットは、それが何を運ぶかに関係なく、単一のDSCPを使用しなければなりません (MUST).

DSCPとRTPの使用、およびDSCPと輻輳制御の関係に関する詳細なアドバイスは、[RFC7657] に記載されています.

DSCPのみに依存しないサービス品質を実現するための多くのスキームが存在します. これらのスキームの一部は、5タプル(送信元アドレス、送信元ポート、プロトコル、宛先アドレス、宛先ポート)または6タプル(5タプル + DSCP)に基づいてトラフィックをフローに分類することに依存しています. したがって、異なる条件下では、送信アプリケーションが次のいずれかの構成を選択することが理にかなっている場合があります:

  • 各メディアストリームが独自の5タプルで運ばれる
  • メディアストリームがメディアタイプごとに5タプルにグループ化される(すべてのオーディオを1つの5タプルで運ぶなど)
  • すべてのメディアが単一の5タプルで送信され、DSCPに基づいて6タプルに区別されるか、区別されない

言及された各構成では、データチャネルは独自の5タプルで運ばれるか、メディアフローの1つと一緒に多重化される可能性があります.

1つの5タプルで高優先度ビデオストリームを送信し、他のすべてのビデオストリームを別の5タプルで一緒に多重化して送信するなど、より複雑な構成も考えられます. メディアフローを5タプルにマッピングする詳細については、[RFC8834] を参照してください.

送信実装は、次の構成をサポートできなければなりません (MUST):

  • 単一の5タプルですべてのメディアとデータを多重化する(完全にバンドル)
  • 各メディアストリームを独自の5タプルで送信し、データを独自の5タプルで送信する(完全にアンバンドル)

送信実装は、各メディアタイプ(オーディオ、ビデオ、またはデータ)を独自の5タプルにバンドルする(メディアタイプ別のバンドル)などの他の構成をサポートすることを選択してもよい (MAY) です.

複数の5タプルでデータチャネルデータを送信することはサポートされていません.

受信実装は、これらすべての構成でメディアとデータを受信できなければなりません (MUST).

に最終更新