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

3. Transport and Middlebox Specification (トランスポートとミドルボックス仕様)

本セクションでは、WebRTCエンドポイントがサポートしなければならないトランスポートプロトコルとミドルボックス処理機能を定義します.

3.1. System-Provided Interfaces (システム提供インターフェース)​

ここで使用されるプロトコル仕様は、WebRTCプロトコルの実装に以下のプロトコルが利用可能であることを前提としています:

UDP [RFC0768]: これは、記述されているほとんどのプロトコル要素で想定されているプロトコルです.

TCP [RFC0793]: これは、HTTP/WebSocketsや、TURN/TLS、ICE-TCPに使用されます.

両方のプロトコルについて、IPv4とIPv6のサポートが想定されています.

UDPの場合、本仕様は、複数のメディアタイプが多重化される際に [RFC8837] で説明されている優先順位付け(本文書の第4.2節を参照)を実現するために、パケット単位で開かれたソケットの差分化サービスコードポイント (Differentiated Services Code Point, DSCP) を設定する機能を想定しています. DSCPが遵守されることは想定しておらず、これはローカル設定の問題であるため、DSCPがゼロにされるか変更される可能性があることを想定しています.

これらのインターフェースへのアクセスを提供しないプラットフォームは、適合WebRTCエンドポイント (Conforming WebRTC Endpoint) をサポートできません.

本仕様は、実装がICMPまたは生のIPへのアクセスを持つことを想定していません.

以下のプロトコルは使用される可能性がありますが、WebRTCエンドポイントによって実装できるため、「システム提供インターフェース」として定義されていません:

  • TURN: Traversal Using Relays Around NAT [RFC8656]
  • STUN: Session Traversal Utilities for NAT [RFC5389]
  • ICE: Interactive Connectivity Establishment [RFC8445]
  • TLS: Transport Layer Security [RFC8446]
  • DTLS: Datagram Transport Layer Security [RFC6347]

3.2. Ability to Use IPv4 and IPv6 (IPv4とIPv6を使用する能力)​

WebRTCブラウザで実行されるWebアプリケーションは、利用可能な場合、IPv4とIPv6の両方を利用できなければなりません (MUST) -- つまり、2つのピアが互いにIPv4接続のみを持っている場合、または互いにIPv6接続のみを持っている場合、WebRTCブラウザで実行されるアプリケーションは通信できなければなりません (MUST).

TURNが使用され、TURNサーバーがピアまたはピアのTURNサーバーへのIPv4またはIPv6接続を持っている場合、適切なタイプの候補をサポートしなければなりません (MUST). ICEの「Happy Eyeballs」仕様 [RFC8421] をサポートすべきです (SHOULD).

3.3. Usage of Temporary IPv6 Addresses (一時的なIPv6アドレスの使用)​

IPv6デフォルトアドレス選択仕様 [RFC6724] は、一時アドレス [RFC4941] が永続アドレスよりも優先されることを規定しています. これは、[RFC3484] で規定されたルールからの変更です. 単一のアドレスを選択するアプリケーションの場合、これは通常、[RFC5014] で指定されたIPV6_PREFER_SRC_TMP優先フラグによって行われます. ただし、プライバシー強化アドレスが静的アドレスよりも優先的に使用されることを保証することを目的としたこのルールは、すべてのアドレスが収集されるため、アプリケーションに公開されるICEでは正しい効果がありません. したがって、代わりに以下のルールが適用されます:

WebRTCエンドポイントがホスト上のすべてのIPv6アドレスを収集し、同じスコープの非非推奨一時アドレスと永続アドレスの両方が存在する場合、WebRTCエンドポイントは、アドレスをアプリケーションに公開する前、またはICEで使用する前に、永続アドレスを破棄すべきです (SHOULD). これは、[RFC6724] で説明されているデフォルトポリシーと一致しています.

一時的なIPv6アドレスの一部(すべてではない)が非推奨としてマークされている場合、WebRTCエンドポイントは、進行中の接続で使用されていない限り、非推奨のアドレスを破棄すべきです (SHOULD). ICE再起動では、現在使用中の非推奨アドレスを保持してもよい (MAY) です.

ミドルボックスを処理するための主要なメカニズムはICEであり、これは、NATボックスや、内部からのトラフィックを受け入れるが、内部トラフィックへの応答である場合にのみ外部からのトラフィックを受け入れるファイアウォール(単純なステートフルファイアウォール)を処理する適切な方法です.

ICE [RFC8445] をサポートしなければなりません (MUST). 実装は、ICE-LiteではなくフルICE実装でなければなりません (MUST). フルICE実装により、適切に展開された場合、ICEとICE-Lite実装の両方との相互運用が可能になります.

エンドポイント依存マッピング ([RFC5128] のセクション2.4で定義) を実行するタイプのNATの背後に両当事者がいる状況に対処するために、TURN [RFC8656] をサポートしなければなりません (MUST).

WebRTCブラウザは、ブラウザ設定とアプリケーションの両方からSTUNおよびTURNサーバーの設定をサポートしなければなりません (MUST).

サーバー発見用の [RFC8155] や [RETURN] など、STUNおよびTURNサーバーの発見と管理に関する他の作業が存在することに注意してください.

すべてのUDPトラフィックをブロックするファイアウォールに対処するために、WebRTCエンドポイントとTURNサーバー間でTCPを使用するTURNモードをサポートしなければならず (MUST)、WebRTCエンドポイントとTURNサーバー間でTCP上でTLSを使用するTURNモードをサポートしなければなりません (MUST). 詳細については、[RFC8656] のセクション3.1を参照してください.

一方がIPv4ネットワーク上にあり、他方がIPv6ネットワーク上にある状況に対処するために、IPv6のTURN拡張をサポートしなければなりません (MUST).

WebRTCエンドポイントのTURNサーバーからピアへの接続がTCP接続であるTURN TCP候補 [RFC6062] をサポートしてもよい (MAY) です.

ただし、そのような候補は、以下の理由により、重要な利点を提供するとは見なされていません.

第一に、TURN TCP候補の使用は、両方のピアが接続を確立するためにTCPを使用する必要がある場合にのみ関連します.

第二に、そのユースケースは、両側がTCP上のTURNを使用してUDPリレー候補を確立し、それぞれのリレーサーバーに接続することによって、異なる方法でサポートされています.

第三に、WebRTCエンドポイントのTURNサーバーとピア間でTCPを使用すると、たとえばヘッドオブラインブロッキング (Head of Line Blocking) により、UDPを使用するよりも多くのパフォーマンス問題が発生する可能性があります.

ICE-TCP候補 [RFC6544] をサポートしなければなりません (MUST); これにより、アプリケーションは、TURNサーバーを使用せずに、UDPをブロックするファイアウォールを越えてパブリックIPアドレスを持つピアと通信できる可能性があります.

TCP接続が使用される場合、すべてのパケットに対して [RFC4571] に従ったRTPフレーミングを使用しなければなりません (MUST). これには、RTPパケット、データチャネルを運ぶために使用されるDTLSパケット、およびSTUN接続性チェックパケットが含まれます.

[RFC5389] のセクション11 (300 Try Alternate) で指定されたALTERNATE-SERVERメカニズムをサポートしなければなりません (MUST).

WebRTCエンドポイントは、HTTPプロキシを介してインターネットにアクセスすることをサポートしてもよい (MAY) です. その場合、[RFC7639] で指定された「ALPN」ヘッダーを含めなければならず (MUST)、[RFC7231] のセクション4.3.6および [RFC7235] で説明されているプロキシ認証もサポートしなければなりません (MUST).

3.5. Transport Protocols Implemented (実装されたトランスポートプロトコル)​

メディアのトランスポートには、セキュアRTPが使用されます. 使用されるRTPプロファイルの詳細は、「Media Transport and Use of RTP in WebRTC」[RFC8834] で説明されており、サーキットブレーカー (Circuit Breaker) [RFC8083] と輻輳制御の使用を義務付けています(詳細なガイダンスについては [RFC8836] を参照してください).

鍵交換は、[RFC8827] で説明されているように、DTLS-SRTPを使用して行わなければなりません (MUST).

WebRTCデータチャネル [RFC8831] を介したデータトランスポートの場合、WebRTCエンドポイントは、SCTP over DTLS over ICEをサポートしなければなりません (MUST). このカプセル化は [RFC8261] で指定されています. セッション記述プロトコル (Session Description Protocol, SDP) でのこのトランスポートのネゴシエーションは [RFC8841] で定義されています. I-DATAのSCTP拡張 [RFC8260] をサポートしなければなりません (MUST).

[RFC8832] で説明されているWebRTCデータチャネルのセットアッププロトコルをサポートしなければなりません (MUST).

注意: [RFC5764] で定義されたDTLS-SRTPと [RFC8445] で定義されたICEとの間の相互作用は、[RFC8842] のセクション6で説明されています. この仕様の効果は、単一のコンポーネントに関連付けられたすべてのICE候補ペアが同じDTLSアソシエーションの一部であることです. したがって、複数の有効な候補ペアが存在する場合でも、DTLSハンドシェイクは1回だけ行われます.

WebRTCエンドポイントは、DTLS-SRTP仕様 [RFC5764] のセクション5.1.2で説明されているように、[RFC7983] で明確化された、同じポートペア上でのDTLSとRTPの多重化をサポートしなければなりません (MUST). このDTLS接続上のすべてのアプリケーション層プロトコルペイロードはSCTPパケットです.

[RFC8833] で指定されているように、プロトコル識別はDTLSハンドシェイクの一部として提供されなければなりません (MUST).

に最終更新