このページはコミュニティーの尽力で英語から翻訳されました。MDN Web Docs コミュニティーについてもっと知り、仲間になるにはこちらから。

View in English Always switch to English

WebRTC プロトコル入門

この記事では、 WebRTC API の基礎となっているプロトコルについて説明します。

ICE

Interactive Connectivity Establishment (ICE) は、ウェブブラウザーをピアーと接続することを可能にするフレームワークです。さまざまな理由から、ピアー A からピアー B に直接接続することはできません。ファイアウォールをバイパスする必要があるからです。ファイアウォールは直接接続を開くことを妨害したり、端末がパブリック IP アドレスを持たない多くの場合にはユニークなアドレスを与えたり、ルーターがピアーとの直接接続を許さない場合にはサーバー経由でデータをリレーしたりします。以下で説明するように、 ICE は STUN や TURN サーバーを使用してこれを解決しています。

STUN

Session Traversal Utilities for NAT (STUN) は、パブリックアドレスを発見し、ピアーとの直接接続を妨害するルーターの制限を特定するためのプロトコルです。

クライアントがインターネット上の STUN サーバーにリクエストを送信すると、サーバーは、クライアントのパブリックアドレスと、ルーターの NAT 内部にアクセス可能かどうかを答えます。

An interaction between two users of a WebRTC application involving a STUN server.

NAT

ネットワークアドレス変換 (Network Address Translation; NAT) は、端末にパブリック IP アドレスを割り当てるために使われます。ルーターはパブリック IP アドレスを持ち、ルーターに接続されたすべての端末はプライベート IP アドレスを持ちます。リクエストが送られると、端末のプライベート IP から、特定のポートを持つルーターのパブリック IP へ変換されます。こうすることで、各端末にユニークな IP アドレスを割り当てずともインターネット上で発見することができるようになります。

ルーターによっては、ネットワーク上の端末に接続できる相手に制限をかけている場合があります。つまり、 STUN サーバーが発見できるパブリック IP アドレスを持っていたとしても、すべての相手が接続を張れるわけではないということです。このような状況では、 TURN を使う必要があります。

TURN

NAT を使用するルーターによっては、 'Symmetric NAT' と呼ばれる制限をかけています。その場合、ルーターは過去に接続したことのあるピアーから来る接続しか受け入れることができません。

Traversal Using Relays around NAT (TURN) は、 TURN サーバーとの接続を開き、そのサーバーを介してすべての情報を中継することで、 Symmetric NAT の制限を回避することを意図しています。 TURN サーバーとの接続を作成し、すべてのピアにサーバーにパケットを送信するように指示し、そのパケットはあなたに転送されます。これは明らかにオーバーヘッドを伴うので、他に方法がない場合にのみ使用します。

An interaction between two users of a WebRTC application involving STUN and TURN servers.

SDP

Session Description Protocol (SDP) とは、解像度、フォーマット、コーデック、暗号化などのマルチメディアコンテンツを指定するための標準です。これにより、データが転送された際に双方が理解できるようになります。本来、これらはメディアコンテンツそのものではなくそのコンテンツを指定するメタデータです。

技術的には、 SDP は真のプロトコルではなく、端末間でメディアを共有する接続を記述するために使用されるデータ形式です。

SDP の文書化は、このドキュメントの範囲外です。ただし、ここで注目すべき点がいくつかあります。

構造

SDP は、 1 行以上の UTF-8 テキストで構成され、それぞれ 1 文字の型で始まり、等号 ("=") が続き、型に依存する形式で値または説明からなる構造化テキストが続きます。ある文字で始まるテキストの行は、一般に "letter-lines" と呼ばれています。例えば、メディアの説明を提供する行は "m" という型なので、それらの行は「m 行」と呼ばれます。

詳細情報

SDP についてより詳しく知りたい方は、以下の有用な資料をご覧ください。

多者間ビデオ会議

WebRTC のピアツーピアネットワークでは、ピア同士が端末の機能やネットワーク帯域幅に基づいて、適切な映像コーデックやストリームをネゴシエーションします。 その後、各送信者は、映像情報を含む単一のストリームを相手側のピアに送信(「シングルキャスト」)します。

複数の参加者間でのビデオ会議は、ピアごとに機能やネットワーク環境が異なる可能性があるため、より複雑になります。特定の映像ストリーム解像度、フレームレート、画質がすべての受信者に適しているとは限らず、一方で送信者が複数のストリームを生成して多数の受信者に送信することは、効率的でもスケーラブルでもありません。

これらの問題に対処するための最も一般的なアプローチは、Selective Forwarding Unit (SFU) または Selective Forwarding Middlebox (SFM) と呼ばれる仲介サーバーを使用することです。 送信者は、SFM が各受信者に適切な映像ストリームを選択的に転送できるようにエンコードされた映像を配信します。 この場合、WebRTC が映像エンコードに使用する主な技術には、Simulcast とスケーラブル映像コーディングの 2 つがあります。

Simulcast

Simulcast は、同じソースの異なる解像度やビットレートを持つ複数のバージョンを、別々のストリームとして同時に送信します。 SFM は、各受信者のネットワーク状況や端末の性能に基づいて、最適なストリームを各受信者に転送します。

SFM は、最後のキーフレームまで遡る一連のインターフレームの連鎖など、フレーム間の依存関係を特定する機能を活用し、受信者に気付かれることなくパケットを転送したり、シムキャスト層を切り替えたりします。

VP8 および VP9 コーデックでは、それぞれ VP8 ペイロード記述子および VP9 ペイロード記述子にフレーム依存情報を含めることができます。 AV1 コーデックの場合、この情報は依存性記述子 (DD) RTP ヘッダー拡張を通じて送信されます。

最近のブラウザの実装では、DD ヘッダーがコーデック非依存であるため、すべてのコーデックで一般的に使用されており、これにより SFM の実装を簡素化できます。 さらに、これはペイロードではなく RTP ヘッダーの一部であるため、エンドツーエンド暗号化のシナリオでも使用可能です。

スケーラブル映像コーディング

スケーラブル映像コーディング (SVC) は、動画ソースを単一のストリームにエンコードし、特定の解像度、ビットレート、または画質の動画を取得するために、複数のレイヤーから選択的にデコードできるようにする技術です。 SFM は、各受信者のネットワークや映像に適したストリームを送信するために、レイヤーの一部を転送することができます。

なお、依存関係は、サイマルキャストを使用する際に転送するストリームを選択するために必要なものよりもはるかに複雑であることに留意されたい(その複雑さの「一例」については、SVC 仕様の依存関係図を参照のこと)。 SVC ストリームは、最低限の品質を提供するベースレイヤーで構成されており、可変フレームレート(「時間的スケーラビリティ」)、解像度の向上(「空間的スケーラビリティ」)、および異なるビットレートでの同一解像度を可能にする、複数の拡張レイヤーを含む場合があります。 VP8 コーデックは時間的レイヤーのみに対応していますが、VP9 は時間的レイヤーと空間的レイヤーの両方に対応しています。

VP8 および VP9 コーデックでは、それぞれ VP8 ペイロード記述子および VP9 ペイロード記述子にフレーム依存性情報を含めることができます。 AV1 コーデックの場合、この情報は依存性記述子 (DD) RTP ヘッダー拡張で送信されます。

同時配信に関しては、最近のブラウザーの実装では、SFM の実装を簡素化するため、またエンドツーエンド暗号化のシナリオに対応していることから、SVC に対応しているすべてのコーデックで DD ヘッダーが一般的に使用されています。

Chrome 111 以降では SVC に対応しています。 Firefox は、この記事の執筆時点(FF136 頃)では SVC に対応していません。

依存性記述子 RTP ヘッダー拡張

[依存性記述子 (DD) RTP ヘッダー拡張](https://aomediacodec.github.io/av1-rtp-spec/# 43-dependency-descriptor-rtp-header-extension)は、仕様書 RTP Payload Format For AV1 (v1.0) で定義されており、多層映像ストリーム内のフレーム間の関係を記述するための、コーデックに依存せず、柔軟で、効率的かつ拡張性のある方法を提供します。

SFM はこれらを利用して、受信者を宛先とするレイヤーに関連するパケットを選択し、転送することができます。 このヘッダーは真の拡張であるため、ペイロードの一部ではなく、したがってエンドツーエンド暗号化 (E2EE) のシナリオにおいても、SFM が引き続き利用可能です。

Chrome および Firefox(バージョン 136 以降)は DD ヘッダーに対応しています。

WebRTC が対応しているコーデック

この情報は、WebRTC で使用されるコーデックに記載されています。