メディア・コミュニケーション

メディア・コミュニケーション #

WebRTCのメディア通信では何ができるのですか？ #

WebRTCでは、オーディオやビデオのストリームを無制限に送受信できます。これらのストリームは、通話中にいつでも追加・削除できます。これらのストリームはすべて独立していることもあれば、まとめて送信することもできます。例えば、自分のデスクトップのビデオフィードを送信し、ウェブカムからのオーディオ／ビデオを含めることができます。

WebRTCプロトコルは、コーデックに依存しません。基礎となるトランスポートは、まだ存在しないものも含めて、すべてをサポートしています。ただし、通信相手であるWebRTCエージェントが、それを受け入れるために必要なツールを持っていない場合もあります。

また、WebRTCは、動的なネットワーク状況に対応できるように設計されています。通話中に帯域が増えたり減ったりすることがあります。また、突然パケットロスが多発することもあります。WebRTCはこのような状況にも対応できるように設計されています。WebRTCはネットワークの状態に対応し、利用可能なリソースで最高の体験を提供しようとします。

どのような仕組みになっているのですか？ #

WebRTCは、RFC 3550で定義されている2つの既存のプロトコルRTPとRTCPを使用しています。

RTP（Real-time Transport Protocol）は、メディアを伝送するプロトコルです。動画をリアルタイムに配信することを目的に設計されています。遅延や信頼性に関するルールは規定されていませんが、それらを実装するためのツールが提供されています。RTPはストリームを提供し、1つの接続で複数のメディアフィードを実行できます。また、メディアパイプラインに供給するために必要な、タイミングや順序の情報も提供します。

RTCP（RTP Control Protocol）は、コールに関するメタデータを通信するためのプロトコルです。このフォーマットは非常に柔軟で、必要なメタデータを追加できます。通話に関する統計情報を通信するために使用されます。また、パケットロスの処理や輻輳制御の実装にも使用されます。これにより、変化するネットワークの状況に対応するために必要な双方向の通信が可能になります。

レイテンシー vs クオリティ #

リアルタイムメディアは、遅延と品質のトレードオフの関係にあります。遅延を許容すればするほど、高品質な映像が期待できます。

現実の制約 #

これらの制約は、すべて現実世界の制約に起因するもので、お客様が克服しなければならないネットワークの特性です。

ビデオは複雑 #

動画の転送は簡単ではありません。30分の非圧縮720 8bitビデオを保存するには、約110Gb必要です。この数字では、4人での電話会議は不可能です。もっと小さくする方法が必要ですが、その答えは映像の圧縮です。しかし、これにはデメリットもあります。

ビデオ101 #

ここでは、動画圧縮について詳しく説明しませんが、RTPがなぜこのように設計されているのかを理解するには十分です。動画圧縮とは、動画を新しいフォーマットにエンコードすることで、同じ動画をより少ないビット数で表現することです。

非可逆圧縮と可逆圧縮 #

動画のエンコードは、ロスレス（情報が失われない）とロッシー（情報が失われる可能性がある）の2種類があります。ロスレス圧縮の場合、相手に送るデータ量が多くなり、ストリームの遅延が大きくなったり、パケットの損失が多くなるため、RTPでは映像の品質が悪くなってもロッシー圧縮を行うのが一般的です。

イントラフレームとインターフレームの圧縮 #

動画の圧縮には2種類あります。1つ目はイントラフレームです。フレーム内圧縮では、1つのビデオフレームを記述するためのビットを削減します。静止画の圧縮にも同じ手法が使われており、JPEG圧縮法などがあります。

2つ目は、フレーム間圧縮です。動画は多くの画像で構成されているので、同じ情報を2度送らない方法を考えます。

フレーム間の種類 #

フレームには3つの種類があります。

  • I-Frame - 完全な画像で、何もなくてもデコードできます。
  • P-Frame - 部分的な画像で、前の画像を修正したもの。
  • B-Frame - 部分的な画像で、以前の画像と未来の画像を組み合わせたもの。

3つのフレームタイプを視覚化すると以下のようになります。

Frame types

動画はデリケート #

動画の圧縮は非常にステートフルであり、インターネットでの転送は困難です。I-Frameの一部が失われるとどうなるのか？P-Frameはどうやって修正すべき箇所を知るのでしょうか？映像圧縮がより複雑になるにつれ、この問題はさらに深刻になっています。幸いなことに、RTPとRTCPには解決策があります。

RTP #

パケットフォーマット #

すべてのRTPパケットは、以下のような構造になっています。

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X|  CC   |M|     PT      |       Sequence Number         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           Timestamp                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Synchronization Source (SSRC) identifier            |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
|            Contributing Source (CSRC) identifiers             |
|                             ....                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            Payload                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

バージョン (V) #

バージョン は常に 2 です。

パディング (P) #

パディング はペイロードにパディングがあるかどうかを制御する bool です。

ペイロードの最後のバイトには、何バイトのパディングが追加されたかのカウントが入っています。

拡張 (X) #

セットされている場合、RTPヘッダーは拡張機能を持つことになります。これについては、以下で詳しく説明します。

CSRC 数 (CC) #

SSRCの後、ペイロードの前に続くCSRCの識別子の数です。

マーカー (M) #

マーカービットには事前に設定された意味はなく、ユーザーが好きなように使うことができます。

場合によっては、ユーザーが話しているときに設定されることもあります。また、キーフレームのマークとしてもよく使われます。

ペイロードタイプ (PT) #

ペイロードタイプ は、このパケットで伝送されるコーデックを示す一意の識別子です。

WebRTCでは、ペイロードタイプは動的なものです。ある通話での VP8 は、別の通話では異なる可能性があります。通話中の提供者は、Session Description の中でペイロードタイプとコーデックのマッピングを決定します。

シーケンス番号 #

シーケンス番号は、ストリームのパケットの順序付けに使用されます。パケットが送信されるたびに、シーケンス番号は1ずつ増加します。

RTPは、損失の多いネットワーク上で役立つように設計されています。これにより、受信者はパケットが失われたことを検出できます。

タイムスタンプ #

このパケットのサンプリング秒数です。これはグローバルクロックではなく、メディアストリームの中でどれだけ時間が経過したかを示します。複数のRTPパケットが同じタイムスタンプを持つこともあります(例: すべてのパケットが同じビデオフレームに含まれる場合)。

同期ソース (SSRC) #

SSRCは、このストリームの一意の識別子です。これにより、複数のメディアストリームを1つのストリーム上で実行できます。

コントリビューションソース(CSRC) #

どの SSRC がこのパケットに貢献したかを伝えるリストです。

これは一般的にトーキングインジケーターに使用されます。例えば、サーバー側で複数のオーディオフィードを1つのRTPストリームにまとめたとします。このフィールドを使用して、「入力ストリームAとCがこの瞬間に話していた」と言うことができます。

ペイロード #

実際のペイロードデータです。パディングフラグが設定されている場合は、何バイトのパディングが追加されたかが最後に表示されます。

拡張機能 #

RTCP #

Packet Format #

RTCPのパケットは、以下のような構造になっています。

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|    RC   |       PT      |             length            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            Payload                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

バージョン (V) #

バージョン は常に 2 です。

パディング (P) #

パディング は bool で、ペイロードにパディングがあるかどうかを制御します。

ペイロードの最後のバイトには、何バイトのパディングが追加されたかのカウントが含まれています。

受信レポート数 (RC) #

このパケットに含まれるレポートの数です。1つのRTCPパケットに複数のイベントを含めることができます。

パケットタイプ (PT) #

この RTCP パケットがどのタイプであるかを示す一意の識別子です。WebRTCエージェントは、これらのタイプをすべてサポートする必要はなく、エージェントによってサポートが異なる場合があります。しかし、一般的に目にするのはこれらのタイプです。

  • Full INTRA-frame Request (FIR) - 192
  • Negative ACKnowledgements (NACK) - 193
  • Sender Report - 200
  • Receiver Report - 201
  • Generic RTP Feedback - 205
  • Payload Specific Feedback - 206

これらのパケットタイプの意義については、以下で詳しく説明します。

Full INTRA-frame Request (FIR)とPicture Loss Indication (PLI) #

FIRとPLIの目的は似ています。これらのメッセージは、送信者にフルキーフレームを要求します。 PLIは、デコーダにパーシャルフレームが到着し、デコードできない場合に使用します。 これは、パケットロスが多い場合や、デコーダがクラッシュした場合などに起こります。

RFC5104によると、パケットやフレームが失われたときには FIR を使用してはならないとされており、それは PLI の仕事です。FIR はパケットロス以外の理由でキーフレームを要求します。例えば、ビデオ会議に新しいメンバーが入ってきたときなどです。FIRはビデオストリームのデコードを開始するために完全なキーフレームを必要とし、デコーダはキーフレームが到着するまでフレームを破棄します。

これにより、接続してからユーザーの画面に画像が表示されるまでの遅延を最小限に抑えることができます。

PLI パケットは、Payload Specific Feedback メッセージの一部です。

実際には、PLI パケットと FIR パケットの両方を扱うことができるソフトウェアは、どちらの場合も同じように動作します。 エンコーダーに信号を送り、新しいフルキーフレームを生成します。

Negative ACKnowledgements #

NACKは、送信者に1つのRTPパケットの再送を要求するものです。これは通常、RTP パケットが失われたときに発生しますが、遅延した場合にも発生します。

NACKは、フレーム全体の再送信を要求するよりも、はるかに帯域幅を効率的に利用できます。RTPはパケットを非常に小さなチャンクに分割するので、実際には1つの小さな欠落部分を要求しているに過ぎません。

送信者/受信者レポート #

これらのレポートは、エージェント間で統計情報を送信するために使用します。このレポートでは、実際に受信したパケット量やジッターを伝えます。

このレポートは、診断や輻輳制御に利用できます。

RTP/RTCPが共に問題を解決する方法 #

このように、RTPとRTCPが連携することで、ネットワークに起因するあらゆる問題を解決できます。これらの技術は今でも常に変化しています。

Negative Acknowledgment #

NACKとも呼ばれます。これは、RTPのパケットロスに対処する方法のひとつです。

NACKは、再送信を要求するために送信者に送り返されるRTCPメッセージです。受信者は、SSRCとシーケンス番号を含むRTCPメッセージを作ります。送信者は、再送信可能なこのRTPパケットを持っていない場合、そのメッセージを無視します。

前方誤り訂正 (Forward Error Correction) #

FECとも呼ばれます。パケットロスに対処するもう一つの方法です。FEC は、同じデータを要求されてもいないのに複数回送信することです。これは、RTP レベルで行われ、さらに下位のコーデックでも行われます。

通話中のパケットロスが安定している場合、FECはNACKよりもはるかに低遅延のソリューションです。NACKの場合は、パケットを要求してから再送信するまでの往復時間が大きくなります。

適応型ビットレートと帯域幅の推定 (Adaptive Bitrate and Bandwidth Estimation) #

リアルタイムネットワーキングで説明したように、ネットワークは予測不可能で信頼性がありません。帯域幅の利用可能性は、セッション中に何度も変化する可能性があります。 利用可能な帯域幅が1秒以内に劇的に（桁違いに）変化することも珍しくありません。

主なアイデアは、予測される、現在および将来の利用可能なネットワーク帯域幅に基づいて、エンコーディングのビットレートを調整することです。 これにより、可能な限り最高の品質の映像・音声信号を伝送し、ネットワークの輻輳によって接続が切断されることがないようにします。 ネットワークの挙動をモデル化し、それを予測するヒューリスティックな手法を「帯域推定」といいます。

これには様々なニュアンスがありますので、詳しくご紹介しましょう。

ネットワーク状況の把握と伝達 #

RTP/RTCPはあらゆる種類の異なるネットワーク上で動作するため、送信者から受信者への通信が途中で途切れることはよくあることです。UDPの上に構築されているため、輻輳制御の処理はもちろん、パケット再送のためのビルトインメカニズムは存在しません。

ユーザーに最高の体験を提供するために、WebRTC はネットワーク経路の品質を推定し、その品質が時間と共にどのように変化するかに適応する必要があります。監視すべき重要な特性には、利用可能な帯域幅（対称でない場合があるため各方向）、往復時間、ジッター（往復時間の変動）などがあります。また、パケットロスを考慮し、ネットワーク状況の変化に応じてこれらの特性の変化を伝える必要があります。

これらのプロトコルの主な目的は2つあります。

  1. ネットワークがサポートする利用可能な帯域幅（各方向）を推定する。
  2. 送り手と受け手の間でネットワークの特性を伝達する

RTP/RTCPは、この問題に対処するために3つの異なるアプローチを持っています。どれも長所と短所があり、一般に、各世代は前の世代よりも改善されています。どの実装を使用するかは、主にクライアントが使用できるソフトウェアスタックと、アプリケーションを構築するために使用できるライブラリに依存します。

Receiver Reports / Sender Reports #

最初の実装は、Receiver Reportsとその補集合である Sender Reportsのペアです。これらのRTCPメッセージはRFC 3550で定義されており、エンドポイント間のネットワークステータスを通信する役割を担っています。受信者レポートは、ネットワークの品質(パケットロス、往復時間、ジッターなど)の通信に重点を置いており、これらのレポートに基づいて利用可能な帯域幅を推定する責任を負う他のアルゴリズムと対になっています。

送信者レポートと受信者レポート（SRとRR）を合わせて、ネットワーク品質の全体像を描きます。これらは各SSRCのスケジュールに従って送信され、利用可能な帯域幅を推定する際に使用される入力となります。これらの推定は、以下のフィールドを含むRRデータを受信した後に送信者によって行われます。

  • Fraction Lost – 前回のReceiver Report以降、何パーセントのパケットが失われたか。
  • Cumulative Number of Packets Lost – 通話全体で失われたパケット数。
  • Extended Highest Sequence Number Received – 最後に受信したシーケンス番号と、それが何回ロールオーバーしたかを示しています。
  • Interarrival Jitter – 通話全体のローリングジッターです。
  • Last Sender Report Timestamp – ラウンドトリップタイムの計算に使用される、送信者の最後の既知の時間。

SRとRRは連動して往復時間を計算します。

送信者は、SRに自分のローカルタイム sendertime1 を含めます。受信者はSRパケットを受信すると、RRを送り返します。このとき、RRには送信者から受け取ったばかりの sendertime1 が含まれます。 SRを受信してからRRを送信するまでの間に遅延が発生します。そのため、RRは「最後の送信者レポートからの遅延」時間 - DLSR も含まれています。 DLSR は後の処理でラウンドトリップタイムの見積もりを調整するために使用されます。送信者はRRを受け取ると、現在の時刻 sendertime2 から sendertime1 と DLSR を差し引きます。この時間差をラウンドトリッププロパゲーションディレイまたはラウンドトリップタイムと呼びます。

rtt = sendertime2 - sendertime1 - DLSR

往復の時間をわかりやすく解説:

  • 私があなたにメッセージを送るとき、私の時計の現在の表示は「午後4時20分、42秒と420ミリ秒」です。
  • あなたはこの同じタイムスタンプを私に送り返します。
  • あなたはまた、私のメッセージを読んでからメッセージを送り返すまでの経過時間、例えば5ミリ秒を入れます。
  • このタイムスタンプを受け取った私は、再び時計を見ます。
  • 今、私の時計は午後4時20分、42秒690ミリ秒と表示されています。
  • つまり、あなたに届いてから私に戻ってくるまでに265ミリ秒（690 - 420 - 5）かかったことになります。
  • したがって、往復の時間は265ミリ秒です。

RTT

TMMBR、TMMBN、REMB、TWCC、GCCと対になる #

Google輻輳制御（GCC) #

Google Congestion Control (GCC) アルゴリズム (概要は draft-ietf-rmcat-gcc-02) は、帯域幅の推定という難題に対処しています。GCCは、他のさまざまなプロトコルと組み合わせて、関連する通信要件を容易にします。その結果、受信側(TMMBR/TMMBNまたはREMBで実行する場合)または送信側 (TWCCで実行する場合)のどちらかで実行するのに適しています。

利用可能な帯域幅の推定値を得るために、GCC は、パケット損失とフレーム到着時間の変動という 2 つの主要なメトリックスに着目しています。これらのメトリックは、ロスベース・コントローラと遅延ベース・コントローラという 2 つのリンクされたコントローラを介して実行されます。

GCCの最初のコンポーネントであるロス・ベース・コントローラはシンプルなものです．

  • パケットロスが 10%を超えると，推定帯域幅が縮小されます。
  • パケットロスが2～10％の場合、推定帯域は変わりません。
  • パケットロスが2%以下の場合、推定帯域を増加させます。

パケットロスの測定は頻繁に行われています。ペアとなる通信プロトコルによって、パケットロスは明示的に伝達される場合（TWCCなど）と推定される場合（TMMBR/TMBNやREMBなど）があります。これらの割合は、約1秒の間隔で評価されます。

2 番目の機能は、損失ベースのコントローラと協力し、パケット到着時間の変動を見ます。この遅延ベースのコントローラーは、ネットワークリンクの混雑が深刻化するタイミングを特定することを目的としており、パケットロスが発生する前であっても帯域幅の見積もりを減らすことがあります。理論的には、パスに沿って最も忙しいネットワークインターフェイスは、そのバッファ内の容量を使い果たすまでパケットをキューに入れ続けることになります。そのインターフェイスが送信可能なトラフィックよりも多くのトラフィックを受信し続ける場合、そのバッファスペースに収まりきらないすべてのパケットをドロップすることを余儀なくされるでしょう。このようなパケットロスは、特に低遅延／リアルタイム通信において破壊的ですが、そのリンク上のすべての通信のスループットを低下させることもあり、理想的には避けるべきものです。したがって、GCC は、パケットロスが実際に発生する 前 に、ネットワークリンクがより大きく、より大きなキューの深さを増しているかどうかを把握しようとします。もし、時間の経過とともにキューの遅延が増加するのを観測したら、それは帯域幅の使用を減らすでしょう。

これを達成するために、GCC はラウンドトリップタイムの微妙な増加を測定することによって、 キューの深さの増加を推測しようとします。これは、フレームの「到着間時間」，t(i) - t(i-1) を記録するもので、パケットの 2 つのグループ（一般に，連続したビデオフレーム）の到着時間の差です．これらのパケット群は一定の時間間隔（例えば24fpsの映像の場合1/24秒間隔）で頻繁に創出します。その結果、到着間時間の測定は、最初のパケットグループ（すなわちフレーム）の開始と次のフレームの最初のフレームとの間の時間差を記録するのと同じくらい簡単です。

下図では、パケット間遅延の増加の中央値は+20ミリ秒であり、ネットワーク輻輳の明確な指標となっています。

TWCC with delay

到着間時間が時間とともに長くなる場合は、接続するネットワーク・インターフェイスのキューの深さが増している証拠と推定され、ネットワークの輻輳とみなされる。(注：GCCはフレームバイトサイズの変動に対して、これらの測定値を制御するのに十分な賢さを持っています)。GCCは輻輳にフラグを立てる前に、カルマンフィルターを使ってそのレイテンシー測定を改良し、ネットワークのラウンドトリップタイム（とその変動）の多くの測定を行います。GCCのカルマンフィルタを線形回帰の代わりと考えることができます：ジッターがタイミング測定にノイズを加えても正確な予測をするのに役立ちます。輻輳のフラグが立てられると、GCC は利用可能なビットレートを下げます。また、ネットワークが安定している場合は、帯域幅の推定値を徐々に増やして、より高い負荷の値をテストすることもできます。

TMMBR、TMMBN、および REMB #

TMMBR/TMMBNおよびREMBの場合、受信側はまず利用可能な受信帯域幅を推定し (GCCなどのプロトコルを使用)、次にその推定帯域幅をリモート送信側に伝達します。受信側で動作することにより、到着間時間やパケットロスを直接測定できるため、パケットロスやネットワークの混雑に関する他の品質に関する詳細を交換する必要はありません。その代わり、TMMBR、TMMBN、およびREMBは、帯域幅の推定値のみを交換します。

  • 一時的な最大メディアストリームビットレート要求(Temporary Maximum Media Stream Bit Rate Request) - 1つのSSRCに対する要求ビットレートの仮数/指数。
  • 一時的な最大メディアストリームビットレート通知(Temporary Maximum Media Stream Bit Rate Notification) - TMMBRを受信したことを通知するためのメッセージ。
  • 受信機推定最大ビットレート(Receiver Estimated Maximum Bitrate) - セッション全体の要求ビットレートの仮数/指数。

TMMBRとTMMBNが最初に登場し、RFC 5104で定義されています。REMBは後に登場し、draft-alvestrand-rmcat-rembでドラフトが提出されましたが、標準化されるには至りませんでした。

REMBを使用するセッションの例は、以下のように動作します。

REMB

この方法は、理論的にはとてもうまくいきます。送信側は受信側から推定値を受け取り、エンコーダのビットレートを受け取った値に設定します。なんということでしょう！これでネットワークの状況に合わせた調整ができました。

しかし実際には、REMB 方式には複数の欠点があります。

エンコーダの非効率性が第一です。エンコーダーにビットレートを設定しても、必ずしも要求された通りのビットレートで出力されるとは限りません。エンコーダーの設定やエンコードされるフレームによって、出力されるビットが多くなったり少なくなったりすることがあります。

たとえば、tune=zerolatency で x264 エンコーダーを使用すると、指定したターゲットビットレートから大きく外れることがあります。以下に考えられるシナリオを示します。

  • まず、ビットレートを 1000kbps に設定したとします。
  • エンコーダーは 700kbps しか出力しない。（別名 - 壁を見つめる）。
  • また、受信機がパケットロスゼロで 700kbps の映像を受信した場合、REMB ルール 1 を適用して受信ビットレートを8％増加させたとします。
  • 受信機は 756kbps の提案(700kbps * 1.08)をした REMB パケットを送信機に送ります。
  • 送信者は、エンコーダのビットレートを 756kbps に設定します。
  • エンコーダーはさらに低いビットレートを出力します。
  • これを繰り返して、ビットレートを極限まで下げていきます。

これでは、エンコーダのパラメータ調整が大変になってしまい、素晴らしい接続環境であっても、ユーザーが見られない映像になってしまうことがわかります。

トランスポートワイド輻輳制御 (Transport Wide Congestion Control) #

トランスポートワイド輻輳制御は、RTCPのネットワーク状態通信における最新の開発です。draft-holmer-rmcat-transport-wide-cc-extensions-01で定義されていますが、標準化されたことはありません。

TWCCは非常にシンプルな原理を使用しています。

TWCC

REMBでは、受信側が送信側にダウンロード可能なビットレートを指示します。また、パケットロスやパケット間到着時間などのデータを事前に測定しておく必要があります。

TWCCは、SR/RRとREMB世代のプロトコルの間のハイブリッドアプローチに近いものです。帯域幅の推定を送信側に戻しますが (SR/RRと同様)、その帯域幅推定技法はREMB世代により近いものであるためです。

TWCCでは、受信機から送信機に対して、各パケットの到着時刻が通知されます。これは送信側にとって、パケット間の到着遅延の変動を測定し、どのパケットがドロップされたか、あるいは到着が遅すぎてオーディオ／ビデオフィードに貢献しなかったかを特定するのに十分な情報です。このデータが頻繁に交換されることで、送信者はネットワークの状況の変化に迅速に対応し、GCCなどのアルゴリズムを使用して出力帯域幅を変化させることができます。

送信者は、送信されたパケット、そのシーケンス番号、サイズ、およびタイムスタンプを追跡します。 送信側は受信側からRTCPメッセージを受信すると、送信パケット間遅延と受信遅延を比較します。 受信遅延が大きくなると、ネットワークの輻輳を意味し、送信者は是正措置を講じなければなりません。

TWCCは、送信者に生データを提供することで、リアルタイムのネットワーク状況を把握することができます。

  • パケットロスの挙動をほぼ瞬時に把握し、個々のパケットロスまで把握可能
  • 正確な送信ビットレート
  • 正確な受信ビットレート
  • ジッター測定
  • 送信パケット遅延と受信パケット遅延の違い
  • ネットワークがバースト的または安定的な帯域幅の配信をどのように許容しているかの説明

TWCCの最も大きな貢献の一つは、WebRTCの開発者に柔軟性を与えることです。輻輳制御アルゴリズムを送信側に集約することで、広く使用できるシンプルなクライアントコードを実現し、時間の経過とともに必要な拡張を最小限に抑えることができます。複雑な輻輳制御アルゴリズムは、その後、それらが直接制御するハードウェア（セクション 8 で説明する選択的転送ユニットなど）上でより迅速に反復することができます。ブラウザとモバイルデバイスの場合、これは、これらのクライアントが標準化またはブラウザの更新（広く利用できるようになるまでかなり長い時間がかかる）を待つことなく、アルゴリズムの強化の恩恵を受けられることを意味します。

帯域幅の推定の代替案 #

最も多く導入されているのは、draft-alvestrand-rmcat-congestionで定義されている「A Google Congestion Control Algorithm for Real-Time Communication」です。

GCC に代わるものとして、NADA: A Unified Congestion Control Scheme for Real-Time Media や SCReAM - Self-Clocked Rate Adaptation for Multimedia などの実装があります。