Internet Engineering Task Force (IETF) S. Garcia Murillo
Request for Comments: 9725 Millicast
Updates: 8840, 8842 A. Gouaillard
Category: Standards Track CoSMo Software
ISSN: 2070-1721 March 2025
This document describes a simple HTTP-based protocol that will allow WebRTC-based ingestion of content into streaming services and/or Content Delivery Networks (CDNs).
このドキュメントでは、WEBRTCベースのコンテンツをストリーミングサービスおよび/またはコンテンツ配信ネットワーク（CDN）に摂取できるようにする簡単なHTTPベースのプロトコルについて説明します。
This document updates RFCs 8840 and 8842.
このドキュメントは、RFCS 8840および8842を更新します。
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 7841のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9725.
このドキュメントの現在のステータス、任意のERRATA、およびそれに関するフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9725で取得できます。
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2025 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
1. Introduction
2. Terminology
3. Overview
4. Protocol Operation
4.1. HTTP Usage
4.2. Ingest Session Setup
4.3. ICE Support
4.3.1. HTTP PATCH Request Usage
4.3.2. Trickle ICE
4.3.3. ICE Restarts
4.4. WebRTC Constraints
4.4.1. SDP Bundle
4.4.2. Single MediaStream
4.4.3. No Partially Successful Answers
4.4.4. DTLS Setup Role and SDP "setup" Attribute
4.4.5. Trickle ICE and ICE Restarts
4.5. Load Balancing and Redirections
4.6. STUN/TURN Server Configuration
4.6.1. Congestion Control
4.7. Authentication and Authorization
4.7.1. Bearer Token Authentication
4.8. Simulcast and Scalable Video Coding
4.9. Protocol Extensions
5. Security Considerations
6. IANA Considerations
6.1. Link Relation Type: ice-server
6.2. URN Sub-namespace for WHIP (urn:ietf:params:whip)
6.3. WebRTC-HTTP Ingestion Protocol (WHIP) URNs Registry
6.4. WebRTC-HTTP Ingestion Protocol (WHIP) Extension URNs
Registry
6.5. Registering WHIP URNs and WHIP Extension URNs
6.5.1. Registration Procedure
6.5.2. Guidance for the Designated Expert
6.5.3. Registration Template
7. References
7.1. Normative References
7.2. Informative References
Acknowledgements
Authors' Addresses
The IETF RTCWEB Working Group standardized the JavaScript Session Establishment Protocol (JSEP) [RFC9429], a mechanism used to control the setup, management, and teardown of a multimedia session. It also describes how to negotiate media flows using the offer/answer model with the Session Description Protocol (SDP) [RFC3264], including the formats for data sent over the wire (e.g., media types, codec parameters, and encryption). WebRTC intentionally does not specify a signaling transport protocol at the application level.
IETF RTCWEBワーキンググループは、マルチメディアセッションのセットアップ、管理、および断落を制御するために使用されるメカニズムであるJavaScriptセッション確立プロトコル（JSEP）[RFC9429]を標準化しました。また、ワイヤーで送信されたデータの形式（メディアタイプ、コーデックパラメーター、暗号化など）の形式を含む、セッション説明プロトコル（SDP）[RFC3264]を使用して、オファー/回答モデルを使用してメディアフローをネゴシエートする方法についても説明します。WeBRTCは意図的に、アプリケーションレベルで信号輸送プロトコルを指定しません。
Unfortunately, the lack of a standardized signaling mechanism in WebRTC has been an obstacle to its adoption as an ingestion protocol within the broadcast and streaming industry, where a streamlined production pipeline is taken for granted. For example, cables carrying raw media to hardware encoders are plugged in and then the encoded media is pushed to any streaming service or Content Delivery Network (CDN) using an ingestion protocol.
残念ながら、WeBRTCの標準化されたシグナル伝達メカニズムの欠如は、放送およびストリーミング業界内の摂取プロトコルとしての採用の障害となっています。たとえば、生のメディアをハードウェアエンコーダーに運ぶケーブルがプラグインされ、エンコードされたメディアが摂取プロトコルを使用してストリーミングサービスまたはコンテンツ配信ネットワーク（CDN）にプッシュされます。
While WebRTC can be integrated with standard signaling protocols like SIP [RFC3261] or Extensible Messaging and Presence Protocol (XMPP) [RFC6120], they are not designed to be used in broadcasting and streaming services, and there is also no sign of adoption in that industry. The Real-Time Streaming Protocol (RTSP) [RFC7826], which is based on RTP, does not support the SDP offer/answer model [RFC3264] for negotiating the characteristics of the media session.
WeBRTCは、SIP [RFC3261]や拡張可能なメッセージと存在プロトコル（XMPP）[RFC6120]などの標準的なシグナル伝達プロトコルと統合できますが、放送およびストリーミングサービスに使用されるようには設計されておらず、その業界での採用の兆候もありません。RTPに基づくリアルタイムストリーミングプロトコル（RTSP）[RFC7826]は、メディアセッションの特性を交渉するためのSDPオファー/回答モデル[RFC3264]をサポートしていません。
This document proposes a simple protocol based on HTTP for supporting WebRTC as a media ingestion method that:
このドキュメントは、WeBRTCをメディア摂取方法としてサポートするためのHTTPに基づく簡単なプロトコルを提案しています。
* is easy to implement,
* 実装が簡単です、
* is as easy to use as popular IP-based broadcast protocols,
* 人気のあるIPベースのブロードキャストプロトコルと同じくらい使いやすいです。
* is fully compliant with WebRTC and RTCWEB specs,
* webrtcおよびrtcwebスペックに完全に準拠している、
* enables ingestion on both classical media platforms and WebRTC end-to-end platforms (achieving the lowest possible latency),
* クラシックメディアプラットフォームとWeBRTCのエンドツーエンドプラットフォームの両方で摂取を可能にします（可能な限り低いレイテンシを実現）
* lowers the requirements on both hardware encoders and broadcasting services to support WebRTC, and
* WeBRTCをサポートするために、ハードウェアエンコーダーと放送サービスの両方の要件を低下させ、
* is usable in both web browsers and standalone encoders.
* Webブラウザーとスタンドアロンエンコーダーの両方で使用可能です。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
このドキュメント内のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、ここに示すようにすべて大文字で表示されている場合にのみ、BCP 14 [RFC2119] [RFC8174] で説明されているように解釈されます。
The WebRTC-HTTP Ingestion Protocol (WHIP) is designed to facilitate a one-time exchange of Session Description Protocol (SDP) offers and answers using HTTP POST requests. This exchange is a fundamental step in establishing an Interactive Connectivity Establishment (ICE) and Datagram Transport Layer Security (DTLS) session between the WHIP client, which represents the encoder or media producer, and the media server, which is the broadcasting ingestion endpoint.
WeBRTC-HTTP Ingestion Protocol（WHIP）は、HTTP Postリクエストを使用して、セッション説明プロトコル（SDP）の1回の交換と回答を促進するように設計されています。この交換は、エンコーダまたはメディアプロデューサーを表すWHIPクライアントと、放送摂取エンドポイントであるメディアサーバーを表す、ホイップクライアント間のインタラクティブ接続確立（ICE）およびデータグラムトランスポートレイヤーセキュリティ（DTLS）セッションを確立するための基本的なステップです。
Upon successful establishment of the ICE/DTLS session, unidirectional media data transmission commences from the WHIP client to the media server. It is important to note that SDP renegotiations are not supported in WHIP. This means that no modifications to the "m=" sections can be made after the initial SDP offer/answer exchange via HTTP POST is completed and that only ICE-related information can be updated via HTTP PATCH requests as defined in Section 4.3.
ICE/DTLSセッションの確立が成功すると、一方向のメディアデータ送信が鞭クライアントからメディアサーバーに開始されます。SDPの再交渉は鞭ではサポートされていないことに注意することが重要です。これは、HTTP投稿を介した最初のSDPオファー/回答交換が完了した後、「m =」セクションの変更を行うことができず、セクション4.3で定義されているHTTPパッチ要求を介して氷関連情報のみを更新できることを意味します。
The following diagram illustrates the core operation of WHIP for initiating and terminating an ingest session:
次の図は、摂取セッションを開始および終了するための鞭のコア操作を示しています。
+-------------+ +---------------+ +--------------+ +---------------+
| WHIP client | | WHIP endpoint | | Media server | | WHIP session |
+--+----------+ +---------+-----+ +------+-------+ +--------|------+
| | | |
| | | |
|HTTP POST (SDP offer) | | |
+------------------------>+ | |
|201 Created (SDP answer) | | |
+<------------------------+ | |
| ICE/STUN REQUEST | |
+--------------------------------------->+ |
| ICE/STUN RESPONSE | |
|<---------------------------------------+ |
| DTLS SETUP | |
|<======================================>| |
| RTP/RTCP FLOW | |
+<-------------------------------------->+ |
| HTTP DELETE |
+---------------------------------------------------------->+
| 200 OK |
<-----------------------------------------------------------x
Figure 1: WHIP Session Setup and Teardown
図1：ホイップセッションのセットアップと分解
The elements in Figure 1 are described as follows:
図1の要素は次のように説明されています。
WHIP client:
ホイップクライアント：
This represents the WebRTC media encoder or producer, which functions as a client of WHIP by encoding and delivering media to a remote media server.
これは、Mediaをリモートメディアサーバーにエンコードして配信することにより、WHIPのクライアントとして機能するWeBRTCメディアエンコーダーまたはプロデューサーを表します。
WHIP endpoint:
ホイップエンドポイント：
This denotes the ingest server that receives the initial WHIP request.
これは、初期ホイップリクエストを受信するINGESTサーバーを示します。
WHIP endpoint URL:
ホイップエンドポイントURL：
This refers to the URL of the WHIP endpoint responsible for creating the WHIP session.
これは、ホイップセッションの作成を担当するホイップエンドポイントのURLを指します。
Media server:
メディアサーバー：
This is the WebRTC media server or consumer responsible for establishing the media session with the WHIP client and receiving the media content it produces.
これは、WHIPクライアントとのメディアセッションを確立し、生成するメディアコンテンツを受信するWeBRTCメディアサーバーまたは消費者です。
WHIP session:
ホイップセッション：
This indicates the server handling the allocated HTTP resource by the WHIP endpoint for an ongoing ingest session.
これは、継続的なインゲストセッションのために、ホイップエンドポイントによって割り当てられたHTTPリソースを処理するサーバーを示しています。
WHIP session URL:
ホイップセッションURL：
This refers to the URL of the WHIP resource allocated by the WHIP endpoint for a specific media session. To modify the session (e.g., ICE operations or session termination), the WHIP client can send requests to the WHIP session using this URL.
これは、特定のメディアセッションのためにWHIPエンドポイントによって割り当てられたWHIPリソースのURLを指します。セッションを変更するため（アイス操作やセッション終了など）、WHIPクライアントはこのURLを使用してホイップセッションにリクエストを送信できます。
Figure 1 illustrates the communication flow between a WHIP client, WHIP endpoint, media server, and WHIP session. This flow outlines the process of setting up and tearing down an ingest session using WHIP, which involves negotiation, ICE for Network Address Translation (NAT) traversal, DTLS and the Secure Real-time Transport Protocol (SRTP) for security, and RTP/RTCP for media transport:
図1は、ホイップクライアント、ホイップエンドポイント、メディアサーバー、およびホイップセッション間の通信フローを示しています。このフローは、ネゴシエーション、ネットワークアドレス翻訳（NAT）トラバーサルのICE、DTLS、セキュリティ用の安全なリアルタイムトランスポートプロトコル（SRTP）、およびメディア輸送用のRTP/RTCPを含む、ホイップを使用してインゲストセッションをセットアップして引き裂くプロセスの概要を示しています。
* The WHIP client initiates the communication by sending an HTTP POST with an SDP offer to the WHIP endpoint.
* WHIPクライアントは、SDPオファーでHTTP投稿をWHIPエンドポイントに送信することにより、通信を開始します。
* The WHIP endpoint responds with a "201 Created" message containing an SDP answer.
* WHIPエンドポイントは、SDP回答を含む「201」の「作成」メッセージで応答します。
* The WHIP client and media server establish ICE and DTLS sessions for NAT traversal and secure communication.
* WHIPクライアントとメディアサーバーは、NATトラバーサルおよび安全な通信のためのICEおよびDTLSセッションを確立します。
* RTP and RTCP flows are established for media transmission from the WHIP client to the media server, secured by the SRTP profile.
* RTPおよびRTCPフローは、SRTPプロファイルによって保護された、WHIPクライアントからメディアサーバーへのメディア送信のために確立されています。
* The WHIP client sends an HTTP DELETE to terminate the WHIP session.
* WHIPクライアントは、HTTP削除を送信して、ホイップセッションを終了します。
* The WHIP session responds with a "200 OK" to confirm the session termination.
* ホイップセッションは、セッションの終了を確認するために「200 OK」で応答します。
Following the guidelines in [BCP56], WHIP clients MUST NOT match error codes returned by the WHIP endpoints and resources to a specific error cause indicated in this specification. WHIP clients MUST be able to handle all applicable status codes by gracefully falling back to the generic n00 semantics of a given status code on unknown error codes. WHIP endpoints and resources could convey finer-grained error information by a problem details json object in the response message body of the failed request as per [RFC9457].
[BCP56]のガイドラインに従って、WHIPクライアントは、WHIPエンドポイントとリソースによって返されたエラーコードと、この仕様に示されている特定のエラー原因に一致してはなりません。WHIPクライアントは、不明なエラーコードの特定のステータスコードの一般的なN00セマンティクスに優雅に戻ることにより、適用されるすべてのステータスコードを処理できる必要があります。WHIPエンドポイントとリソースは、[RFC9457]に従って、故障した要求の応答メッセージ本文でJSONオブジェクトを詳細に説明することにより、より細かい粒度のエラー情報を伝えることができます。
The WHIP endpoints and sessions are origin servers as defined in Section 3.6 of [RFC9110]; they handle the requests and provide responses for the underlying HTTP resources. Those HTTP resources do not have any representation defined in this specification, so the WHIP endpoints and sessions MUST return a 2xx successful response with no content when a GET request is received.
ホイップエンドポイントとセッションは、[RFC9110]のセクション3.6で定義されているオリジンサーバーです。彼らはリクエストを処理し、基礎となるHTTPリソースの応答を提供します。これらのHTTPリソースには、この仕様では表現が定義されていないため、WHIPのエンドポイントとセッションは、GETリクエストを受信したときにコンテンツなしで2xxの成功した応答を返す必要があります。
In order to set up an ingest session, the WHIP client MUST generate an SDP offer according to the JSEP rules for an initial offer as per Section 5.2.1 of [RFC9429] and send an HTTP POST request as per Section 9.3.3 of [RFC9110] to the configured WHIP endpoint URL.
INGESTセッションを設定するために、WHIPクライアントは、[RFC9429]のセクション5.2.1に従って、最初のオファーのJSEPルールに従ってSDPオファーを生成し、[RFC9110]のセクション9.3.3に従って、構成されたWHIPエンドポイントURLにHTTP POSTリクエストを送信する必要があります。
The HTTP POST request MUST have a content type of "application/sdp" and contain the SDP offer as the body. The WHIP endpoint MUST generate an SDP answer according to the JSEP rules for an initial answer as per Section 5.3.1 of [RFC9429] and return the following: a "201 Created" response with a content type of "application/sdp", the SDP answer as the body, and a Location header field pointing to the newly created WHIP session. If the HTTP POST to the WHIP endpoint has a content type different than "application/sdp" or the SDP is malformed, the WHIP endpoint MUST reject the HTTP POST request with an appropriate 4xx error response.
HTTP POSTリクエストには、コンテンツタイプの「アプリケーション/SDP」が必要であり、SDPオファーがボディとして含まれている必要があります。WHIPエンドポイントは、[RFC9429]のセクション5.3.1に従って、初期回答のJSEPルールに従ってSDP回答を生成し、以下を返します。ホイップエンドポイントへのHTTP投稿に「アプリケーション/SDP」とは異なるコンテンツタイプがある場合、またはSDPが奇形である場合、ホイップエンドポイントは、適切な4XXエラー応答でHTTP POSTリクエストを拒否する必要があります。
As WHIP only supports the ingestion use case with unidirectional media, the WHIP client SHOULD use the "sendonly" attribute in the SDP offer but MAY use the "sendrecv" attribute instead; the "inactive" and "recvonly" attributes MUST NOT be used. The WHIP endpoint MUST use the "recvonly" attribute in the SDP answer.
WHIPは単方向メディアで摂取ユースケースのみをサポートするため、WHIPクライアントはSDPオファーで「sendonly」属性を使用する必要がありますが、代わりに「sendrecv」属性を使用する場合があります。「非アクティブ」および「recvonly」属性を使用しないでください。WHIPエンドポイントは、SDP回答で「Recvonly」属性を使用する必要があります。
Figure 2 is an example of an HTTP POST sent from a WHIP client to a WHIP endpoint and the "201 Created" response from the WHIP endpoint containing the Location header pointing to the newly created WHIP session.
図2は、ホイップクライアントからホイップエンドポイントに送信されたHTTP投稿の例であり、新しく作成されたホイップセッションを指すロケーションヘッダーを含むホイップエンドポイントからの「作成された」応答の例です。
POST /whip/endpoint HTTP/1.1
Host: whip.example.com
Content-Type: application/sdp
Content-Length: 1101
v=0
o=- 5228595038118931041 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE 0 1
a=extmap-allow-mixed
a=ice-options:trickle ice2
m=audio 9 UDP/TLS/RTP/SAVPF 111
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:EsAw
a=ice-pwd:bP+XJMM09aR8AiX1jdukzR6Y
a=fingerprint:sha-256 DA:7B:57:DC:28:CE:04:4F:31:79:85:C4:31:67:EB:
27:58:29:ED:77:2A:0D:24:AE:ED:AD:30:BC:BD:F1:9C:02
a=setup:actpass
a=mid:0
a=extmap:4 urn:ietf:params:rtp-hdrext:sdes:mid
a=sendonly
a=msid:d46fb922-d52a-4e9c-aa87-444eadc1521b ce326ecf-a081-453a-8f9f-
0605d5ef4128
a=rtcp-mux
a=rtcp-mux-only
a=rtpmap:111 opus/48000/2
a=fmtp:111 minptime=10;useinbandfec=1
m=video 0 UDP/TLS/RTP/SAVPF 96 97
a=mid:1
a=bundle-only
a=extmap:4 urn:ietf:params:rtp-hdrext:sdes:mid
a=extmap:10 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
a=extmap:11 urn:ietf:params:rtp-hdrext:sdes:repaired-rtp-stream-id
a=sendonly
a=msid:d46fb922-d52a-4e9c-aa87-444eadc1521b 3956b460-40f4-4d05-acef-
03abcdd8c6fd
a=rtpmap:96 VP8/90000
a=rtcp-fb:96 ccm fir
a=rtcp-fb:96 nack
a=rtcp-fb:96 nack pli
a=rtpmap:97 rtx/90000
a=fmtp:97 apt=96
HTTP/1.1 201 Created
ETag: "xyzzy"
Content-Type: application/sdp
Content-Length: 1053
Location: https://whip.example.com/session/id
v=0
o=- 1657793490019 1 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE 0 1
a=extmap-allow-mixed
a=ice-lite
a=ice-options:trickle ice2
m=audio 9 UDP/TLS/RTP/SAVPF 111
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:38sdf4fdsf54
a=ice-pwd:2e13dde17c1cb009202f627fab90cbec358d766d049c9697
a=fingerprint:sha-256 F7:EB:F3:3E:AC:D2:EA:A7:C1:EC:79:D9:B3:8A:35:
DA:70:86:4F:46:D9:2D:CC:D0:BC:81:9F:67:EF:34:2E:BD
a=candidate:1 1 UDP 2130706431 198.51.100.1 39132 typ host
a=setup:passive
a=mid:0
a=extmap:4 urn:ietf:params:rtp-hdrext:sdes:mid
a=recvonly
a=rtcp-mux
a=rtcp-mux-only
a=rtpmap:111 opus/48000/2
a=fmtp:111 minptime=10;useinbandfec=1
m=video 0 UDP/TLS/RTP/SAVPF 96 97
c=IN IP4 0.0.0.0
a=mid:1
a=bundle-only
a=extmap:4 urn:ietf:params:rtp-hdrext:sdes:mid
a=extmap:10 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
a=extmap:11 urn:ietf:params:rtp-hdrext:sdes:repaired-rtp-stream-id
a=recvonly
a=rtpmap:96 VP8/90000
a=rtcp-fb:96 ccm fir
a=rtcp-fb:96 nack
a=rtcp-fb:96 nack pli
a=rtpmap:97 rtx/90000
a=fmtp:97 apt=96
Figure 2: Example of the SDP Offer/Answer Exchange Done via an HTTP POST
図2：HTTP投稿を介して行われたSDPオファー/回答交換の例
Once a session is set up, consent freshness as per [RFC7675] SHALL be used to detect non-graceful disconnection by full ICE implementations and DTLS teardown for session termination by either side.
セッションがセットアップされると、[RFC7675]によると同意した新鮮さを使用して、完全な氷の実装による不利な切断と、いずれかの側でのセッション終了のためのDTLS分解を検出するものとします。
To explicitly terminate a WHIP session, the WHIP client MUST send an HTTP DELETE request to the WHIP session URL returned in the Location header field of the initial HTTP POST. Upon receiving the HTTP DELETE request, the WHIP session will be removed and the resources freed on the media server, terminating the ICE and DTLS sessions.
ホイップセッションを明示的に終了するには、ホイップクライアントは、最初のHTTPポストの位置ヘッダーフィールドに返されたWHIPセッションURLにHTTP削除要求を送信する必要があります。HTTP削除要求を受信すると、ホイップセッションが削除され、リソースがメディアサーバーで解放され、ICEおよびDTLSセッションが終了します。
A media server terminating a session MUST follow the procedures in Section 5.2 of [RFC7675] for immediate revocation of consent.
セッションを終了するメディアサーバーは、同意を即座に取り消すために、[RFC7675]のセクション5.2の手順に従う必要があります。
The WHIP endpoints MUST support OPTIONS requests for Cross-Origin Resource Sharing (CORS) as defined in [FETCH]. The "200 OK" response to any OPTIONS request SHOULD include an Accept-Post header with a media type value of "application/sdp" as per [W3C.REC-ldp-20150226].
ホイップエンドポイントは、[フェッチ]で定義されているように、クロスオリジンリソース共有（CORS）のオプションリクエストをサポートする必要があります。オプションリクエストに対する「200 OK」応答には、[W3C.REC-LDP-20150226]に従って、「Application/SDP」のメディアタイプ値を持つAccept-Postヘッダーを含める必要があります。
ICE [RFC8445] is a protocol that addresses the complexities of NAT traversal commonly encountered in Internet communication. NATs hinder direct communication between devices on different local networks, posing challenges for real-time applications. ICE facilitates seamless connectivity by employing techniques to discover and negotiate efficient communication paths.
ICE [RFC8445]は、インターネット通信で一般的に遭遇するNATトラバーサルの複雑さに対処するプロトコルです。NATSは、さまざまなローカルネットワーク上のデバイス間の直接通信を妨げ、リアルタイムアプリケーションの課題を提起します。ICEは、効率的な通信パスを発見および交渉するための手法を使用することにより、シームレスな接続性を促進します。
Trickle ICE [RFC8838] optimizes the connectivity process by incrementally sharing potential communication paths, reducing latency, and facilitating quicker establishment.
Trickle Ice [RFC8838]は、潜在的な通信パスを徐々に共有し、レイテンシを減らし、より迅速な設立を促進することにより、接続プロセスを最適化します。
ICE restarts are crucial for maintaining connectivity in dynamic network conditions or disruptions, allowing devices to re-establish communication paths without complete renegotiation. This ensures minimal latency and reliable real-time communication.
ICEの再起動は、動的なネットワーク条件または破壊の接続性を維持するために重要であり、完全な再交渉なしにデバイスが通信パスを再確立できるようにします。これにより、最小限のレイテンシと信頼性の高いリアルタイム通信が保証されます。
Trickle ICE and ICE restart support are RECOMMENDED for both WHIP sessions and clients.
トリクルアイスとアイスの再起動サポートは、ホイップセッションとクライアントの両方に推奨されます。
The WHIP client MAY perform Trickle ICE or ICE restarts by sending an HTTP PATCH request as per [RFC5789] to the WHIP session URL. This HTTP PATCH request MUST contain a body with an SDP fragment with media type "application/trickle-ice-sdpfrag" as specified in [RFC8840], which carries the relevant ICE information. If the HTTP PATCH request sent to the WHIP session URL has a content type different than "application/trickle-ice-sdpfrag" or the SDP fragment is malformed, the WHIP session MUST reject the HTTP PATCH with an appropriate 4xx error response.
ホイップクライアントは、[RFC5789]に従ってHTTPパッチリクエストをホイップセッションURLに送信することにより、トリクルアイスまたはアイスの再起動を実行できます。このHTTPパッチ要求には、関連する氷情報を運ぶ[RFC8840]で指定されているように、メディアタイプの「アプリケーション/トリクルアイス-SDPFrag」を備えたSDPフラグメントを備えたボディを含める必要があります。ホイップセッションURLに送信されたHTTPパッチ要求が「アプリケーション/トリクルアイス-SDPFrag」とは異なるコンテンツタイプを持っている場合、またはSDPフラグメントが奇形である場合、WHIPセッションは適切な4XXエラー応答でHTTPパッチを拒否する必要があります。
If the WHIP session supports either Trickle ICE or ICE restarts, but not both, it MUST return a "422 Unprocessable Content" error response for the HTTP PATCH requests that are not supported as per Section 15.5.21 of [RFC9110].
ホイップセッションがトリクルアイスまたはアイスの再起動のいずれかをサポートしているが、両方ではない場合、[RFC9110]のセクション15.5.21に従ってサポートされていないHTTPパッチリクエストの「422未処理のコンテンツ」エラー応答を返す必要があります。
The WHIP client MAY send overlapping HTTP PATCH requests to one WHIP session. Consequently, those HTTP PATCH requests may be received out of order by the WHIP session. Thus, if the WHIP session supports ICE restarts, it MUST generate a unique strong entity-tag identifying the ICE session as per Section 8.8.3 of [RFC9110]. The initial value of the entity-tag identifying the initial ICE session MUST be returned in an ETag header field in the "201 Created" response to the initial POST request to the WHIP endpoint.
WHIPクライアントは、重複するHTTPパッチリクエストを1つのホイップセッションに送信する場合があります。したがって、これらのHTTPパッチ要求は、WHIPセッションによって故障していない場合があります。したがって、ホイップセッションがアイスの再起動をサポートする場合、[RFC9110]のセクション8.8.3に従って、アイスセッションを識別する一意の強力なエンティティタグを生成する必要があります。初期アイスセッションを識別するエンティティタグの初期値は、ホイップエンドポイントへの最初のPOSTリクエストに対する「作成された」応答のETAGヘッダーフィールドで返される必要があります。
WHIP clients SHOULD NOT use entity-tag validation when matching a specific ICE session is not required, for example, when initiating a DELETE request to terminate a session. WHIP sessions MUST ignore any entity-tag value sent by the WHIP client when ICE session matching is not required, as in the HTTP DELETE request.
特定のアイスセッションと一致するときは、Entity-TAG検証を使用しないでください。たとえば、セッションを終了するために削除要求を開始する場合。HTTP削除リクエストのように、ICEセッションのマッチングが不要な場合、WHIPセッションでは、ホイップクライアントが送信したエンティティタグ値を無視する必要があります。
Missing or outdated ETags in the PATCH requests from WHIP clients will be answered by WHIP sessions as per Section 13.1.1 of [RFC9110] and Section 3 of [RFC6585], with a "428 Precondition Required" response for a missing entity-tag and a "412 Precondition Failed" response for a non-matching entity-tag.
WHIPクライアントからのパッチリクエストの欠落または時代遅れのETAGは、[RFC9110]のセクション13.1.1および[RFC6585]のセクション3に従って、「428の前提条件が必要な」回答が必要であり、「412の事前条件が必要」と「412の事前条件が失敗した」と回答されます。
Depending on the Trickle ICE support on the WHIP client, the initial offer by the WHIP client MAY be sent after the full ICE gathering is complete with the full list of ICE candidates, or it MAY only contain local candidates (or even an empty list of candidates) as per [RFC8445]. For the purpose of reducing setup times, when using Trickle ICE, the WHIP client SHOULD send the SDP offer (containing either locally gathered ICE candidates or an empty list of candidates) as soon as possible.
WHIPクライアントのトリクルアイスサポートに応じて、ホイップクライアントによる最初のオファーは、完全な氷の収集が氷の候補者の完全なリストを完全に備えた後に送信されるか、[RFC845]に従ってローカル候補（または候補者の空のリスト）のみを含めることができます。セットアップ時間を短縮する目的で、Trickle Iceを使用する場合、WHIPクライアントは、できるだけ早くSDPのオファー（地元で集められた氷の候補者または空の候補者のいずれかを含む）を送信する必要があります。
In order to simplify the protocol, the WHIP session cannot signal additional ICE candidates to the WHIP client after the SDP answer has been sent. The WHIP endpoint SHALL gather all the ICE candidates for the media server before responding to the client request, and the SDP answer SHALL contain the full list of ICE candidates of the media server.
プロトコルを簡素化するために、SDPの回答が送信された後、WHIPセッションでは、追加のICE候補者にWHIPクライアントに信号を送ることができません。WHIPエンドポイントは、クライアントリクエストに応答する前にメディアサーバーのすべてのICE候補を収集するものとし、SDPの回答にはメディアサーバーのICE候補の完全なリストが含まれます。
As the WHIP client needs to know the WHIP session URL associated with the ICE session in order to send a PATCH request containing new ICE candidates, it MUST wait and buffer any gathered candidates until the "201 Created" HTTP response to the initial POST request is received. In order to reduce the HTTP traffic and processing time required, the WHIP client SHOULD send a single aggregated HTTP PATCH request with all the buffered ICE candidates once the response is received. Additionally, if ICE restarts are supported by the WHIP session, the WHIP client needs to know the entity-tag associated with the ICE session in order to send a PATCH request containing new ICE candidates; thus, it MUST also wait and buffer any gathered candidates until it receives the HTTP response with the new entity-tag value to the last PATCH request performing an ICE restart.
WHIPクライアントは、新しいICE候補を含むパッチリクエストを送信するために、ICEセッションに関連付けられているWHIPセッションURLを知る必要があるため、最初のPOSTリクエストに対する「作成された」HTTP応答が受信されるまで、収集した候補を待ってバッファする必要があります。必要なHTTPトラフィックと処理時間を短縮するために、WHIPクライアントは、応答が受信されたら、すべての緩衝ICE候補と単一の集約されたHTTPパッチ要求を送信する必要があります。さらに、ICEの再起動がホイップセッションによってサポートされている場合、WHIPクライアントは、新しいICE候補を含むパッチリクエストを送信するために、ICEセッションに関連付けられたエンティティタグを知る必要があります。したがって、ICEの再起動を実行する最後のパッチ要求に対して、新しいエンティティタグ値を使用してHTTP応答を受信するまで、収集した候補を待機し、バッファする必要があります。
WHIP clients generating the HTTP PATCH body with the SDP fragment and its subsequent processing by WHIP sessions MUST follow the guidelines defined in Section 4.4 of [RFC8840] with the following considerations:
SDPフラグメントを使用してHTTPパッチ本体を生成するWHIPクライアントと、WHIPセッションによる後続の処理は、[RFC8840]のセクション4.4で定義されているガイドラインに従う必要があります。
* As per [RFC9429], only "m=" sections not marked as bundle-only can gather ICE candidates, so given that the "max-bundle" policy is being used, the SDP fragment will contain only the offerer-tagged "m=" line of the bundle group.
* [rfc9429]によると、「m =」セクションのみがバンドルのみとしてマークされていないセクションのみがICE候補を収集できるため、「max-bundle」ポリシーが使用されていることを考えると、SDPフラグメントにはバンドルグループのオファータグ付き「m =」ラインのみが含まれます。
* The WHIP client MAY exclude ICE candidates from the HTTP PATCH body if they have already been confirmed by the WHIP session with a successful HTTP response to a previous HTTP PATCH request.
* WHIPクライアントは、以前のHTTPパッチリクエストに対するHTTP応答を成功させて、ホイップセッションによってすでに確認されている場合、HTTPパッチ本体からICE候補を除外することができます。
WHIP sessions and clients that support Trickle ICE MUST make use of entity-tags and conditional requests as explained in Section 4.3.1.
Trickle Iceをサポートするホイップセッションとクライアントは、セクション4.3.1で説明されているように、エンティティタグと条件付きリクエストを利用する必要があります。
When a WHIP session receives a PATCH request that adds new ICE candidates without performing an ICE restart, it MUST return a "204 No Content" response without a body and MUST NOT include an ETag header in the response. If the WHIP session does not support a candidate transport or is not able to resolve the connection address, it MUST silently discard the candidate and continue processing the rest of the request normally.
ホイップセッションで、アイスリスタートを実行せずに新しいアイス候補を追加するパッチリクエストを受信した場合、ボディなしで「204コンテンツなし」応答を返す必要があり、応答にETAGヘッダーを含めてはなりません。WHIPセッションが候補の輸送をサポートしていない場合、または接続アドレスを解決できない場合、候補者を静かに破棄し、リクエストの残りの部分を正常に処理し続ける必要があります。
Figure 3 shows an example of the Trickle ICE procedure where the WHIP client sends a PATCH request with updated ICE candidate information and receives a successful response from the WHIP session.
図3は、WHIPクライアントが更新されたICE候補の情報を使用してパッチ要求を送信し、ホイップセッションから成功した応答を受け取るトリクルアイス手順の例を示しています。
PATCH /session/id HTTP/1.1
Host: whip.example.com
If-Match: "xyzzy"
Content-Type: application/trickle-ice-sdpfrag
Content-Length: 576
a=group:BUNDLE 0 1
m=audio 9 UDP/TLS/RTP/SAVPF 111
a=mid:0
a=ice-ufrag:EsAw
a=ice-pwd:P2uYro0UCOQ4zxjKXaWCBui1
a=candidate:1387637174 1 udp 2122260223 192.0.2.1 61764 typ host
generation 0 ufrag EsAw network-id 1
a=candidate:3471623853 1 udp 2122194687 198.51.100.2 61765 typ host
generation 0 ufrag EsAw network-id 2
a=candidate:473322822 1 tcp 1518280447 192.0.2.1 9 typ host tcptype
active generation 0 ufrag EsAw network-id 1
a=candidate:2154773085 1 tcp 1518214911 198.51.100.2 9 typ host
tcptype active generation 0 ufrag EsAw network-id 2
a=end-of-candidates
HTTP/1.1 204 No Content
Figure 3: Example of a Trickle ICE Request and Response
図3：トリクルアイスリクエストと応答の例
As defined in [RFC8839], when an ICE restart occurs, a new SDP offer/ answer exchange is triggered. However, as WHIP does not support renegotiation of non-ICE-related SDP information, a WHIP client will not send a new offer when an ICE restart occurs. Instead, the WHIP client and WHIP session will only exchange the relevant ICE information via an HTTP PATCH request as defined in Section 4.3.1 and MUST assume that the previously negotiated non-ICE-related SDP information still applies after the ICE restart.
[RFC8839]で定義されているように、ICEの再起動が発生すると、新しいSDPオファー/回答交換がトリガーされます。ただし、WHIPは非氷関連のSDP情報の再交渉をサポートしていないため、ICEの再起動が発生したときにWHIPクライアントは新しいオファーを送信しません。代わりに、WHIPクライアントとホイップセッションは、セクション4.3.1で定義されているHTTPパッチ要求を介して関連する氷情報のみを交換し、以前に交渉された非氷に関連したSDP情報がICEの再起動後もまだ適用されると仮定する必要があります。
When performing an ICE restart, the WHIP client MUST include the updated "ice-pwd" and "ice-ufrag" in the SDP fragment of the HTTP PATCH request body as well as the new set of gathered ICE candidates as defined in [RFC8840]. Similar to what is defined in Section 4.3.2, as per [RFC9429], only "m=" sections not marked as bundle-only can gather ICE candidates, so given that the "max-bundle" policy is being used, the SDP fragment will contain only the offerer-tagged "m=" line of the bundle group. A WHIP client sending a PATCH request for performing ICE restart MUST contain an If-Match header field with a field-value of "*" as per Section 13.1.1 of [RFC9110].
ICEの再起動を実行するとき、WHIPクライアントは、HTTPパッチ要求本体のSDPフラグメントに更新された「ICE-PWD」と「ICE-UFRAG」を、[RFC8840]で定義されている新しい集められたICE候補のセットを含める必要があります。[RFC9429]に従ってセクション4.3.2で定義されているものと同様に、バンドルのみとしてマークされていない「M =」セクションのみがICE候補を収集できるため、「Max-Bundle」ポリシーが使用されていることを考えると、SDPフラグメントにはバンドルグループのオファータグ付き「M =」ラインのみが含まれます。[RFC9110]のセクション13.1.1に従って、「*」のフィールド値を備えた、ICE再起動を実行するためのパッチリクエストを送信するホイップクライアントには、IFマッチヘッダーフィールドが含まれている必要があります。
[RFC8840] states that an agent MUST discard any received requests containing "ice-pwd" and "ice-ufrag" attributes that do not match those of the current ICE Negotiation Session. However, any WHIP session receiving updated "ice-pwd" and "ice-ufrag" attributes MUST consider the request as performing an ICE restart instead and, if supported, SHALL return a "200 OK" with an "application/trickle-ice-sdpfrag" body containing the new ICE username fragment and password and a new set of ICE candidates for the WHIP session. Also, the "200 OK" response for a successful ICE restart MUST contain the new entity-tag corresponding to the new ICE session in an ETag response header field and MAY contain a new set of ICE candidates for the media server.
[RFC8840]は、エージェントが現在のICE交渉セッションのものと一致しない「ICE-PWD」および「ICE-UFRAG」属性を含む受信リクエストを破棄する必要があると述べています。ただし、更新された「ICE-PWD」および「ICE-USFRAG」属性を受信するホイップセッションは、リクエストを代わりにICEの再起動を実行するものとしてリクエストを検討する必要があり、サポートされている場合は、「アプリケーション/トリクルアイス-SDPFrag」を返す必要があります。また、成功したアイス再起動のための「200 OK」応答には、ETAG応答ヘッダーフィールドの新しいアイスセッションに対応する新しいエンティティタグを含める必要があり、メディアサーバーの新しいアイス候補のセットが含まれる場合があります。
As defined in Section 4.4.1.1.1 of [RFC8839], the set of candidates after an ICE restart may include some, none, or all of the previous candidates for that data stream and may include a totally new set of candidates. Therefore, after performing a successful ICE restart, both the WHIP client and the WHIP session MUST replace the previous set of remote candidates with the new set exchanged in the HTTP PATCH request and response, discarding any remote ICE candidate not present on the new set. Both the WHIP client and the WHIP session MUST ensure that the HTTP PATCH request and response bodies include the same "ice-options," "ice-pacing," and "ice-lite" attributes as those used in the SDP offer or answer.
[RFC8839]のセクション4.4.1.1.1で定義されているように、ICEの再起動後の候補者のセットには、そのデータストリームの以前の候補の一部が含まれ、まったく新しい候補のセットが含まれる場合があります。したがって、ICEの再起動を成功させた後、ホイップクライアントとホイップセッションの両方が、以前のリモート候補のセットをHTTPパッチ要求と応答で交換した新しいセットに置き換え、新しいセットに存在しないリモートアイス候補を破棄する必要があります。WHIPクライアントとホイップセッションの両方は、HTTPパッチ要求と応答本体に、SDPのオファーまたは回答で使用されているものと同じ「アイスオプション」、「アイスペース」、「アイスライト」属性が含まれるようにする必要があります。
If the ICE restart request cannot be satisfied by the WHIP session, the resource MUST return an appropriate HTTP error code and MUST NOT terminate the session immediately and keep the existing ICE session. The WHIP client MAY retry performing a new ICE restart or terminate the session by issuing an HTTP DELETE request instead. In any case, the session MUST be terminated if the ICE consent expires as a consequence of the failed ICE restart as per Section 5.1 of [RFC7675].
WHIPセッションでICE再起動要求が満たされない場合、リソースは適切なHTTPエラーコードを返す必要があり、すぐにセッションを終了して既存のICEセッションを維持してはなりません。ホイップクライアントは、代わりにHTTP削除要求を発行して、新しいアイス再起動を再試行したり、セッションを終了したりすることができます。いずれにせよ、[RFC7675]のセクション5.1に従って、氷の再起動の結果として氷の同意が期限切れになった場合、セッションは終了する必要があります。
In case of unstable network conditions, the ICE restart HTTP PATCH requests and responses might be received out of order. In order to mitigate this scenario, when the client performs an ICE restart, it MUST discard any previous ICE username fragment and password and ignore any further HTTP PATCH response received from a pending HTTP PATCH request. WHIP clients MUST apply only the ICE information received in the response to the last sent request. If there is a mismatch between the ICE information at the WHIP client and at the WHIP session (because of an out-of-order request), the Session Traversal Utilities for NAT (STUN) requests will contain invalid ICE information and will be dropped by the receiving side. If this situation is detected by the WHIP client, it MUST send a new ICE restart request to the server.
不安定なネットワーク条件の場合、ICEの再起動HTTPパッチのリクエストと応答が順調に受け取られる可能性があります。このシナリオを緩和するために、クライアントがICEの再起動を実行するとき、以前のICEユーザー名フラグメントとパスワードを破棄し、保留中のHTTPパッチリクエストから受信したさらにHTTPパッチ応答を無視する必要があります。WHIPクライアントは、最後に送信されたリクエストへの応答で受け取ったICE情報のみを適用する必要があります。ホイップクライアントとホイップセッション（オーダーオブオーダーリクエストのため）の氷情報間に不一致がある場合、NAT（STUN）リクエストのセッショントラバーサルユーティリティには無効なICE情報が含まれ、受信側によって削除されます。この状況がWHIPクライアントによって検出された場合、サーバーに新しいICE RETARTリクエストを送信する必要があります。
Figure 4 demonstrates a Trickle ICE restart procedure example. The WHIP client sends a PATCH request containing updated ICE information, including a new username fragment and password, along with newly gathered ICE candidates. In response, the WHIP session provides ICE information for the session after the ICE restart, including the updated username fragment and password, as well as the previous ICE candidate.
図4は、トリクルアイス再起動手順の例を示しています。WHIPクライアントは、新しく収集されたICE候補とともに、新しいユーザー名フラグメントとパスワードを含む更新されたICE情報を含むパッチリクエストを送信します。これに応じて、WHIPセッションは、更新されたユーザー名フラグメントとパスワード、および以前のICE候補を含むICE再起動後のセッションのICE情報を提供します。
PATCH /session/id HTTP/1.1
Host: whip.example.com
If-Match: "*"
Content-Type: application/trickle-ice-sdpfrag
Content-Length: 82
a=ice-options:trickle ice2
a=group:BUNDLE 0 1
m=audio 9 UDP/TLS/RTP/SAVPF 111
a=mid:0
a=ice-ufrag:ysXw
a=ice-pwd:vw5LmwG4y/e6dPP/zAP9Gp5k
a=candidate:1387637174 1 udp 2122260223 192.0.2.1 61764 typ host
generation 0 ufrag EsAw network-id 1
a=candidate:3471623853 1 udp 2122194687 198.51.100.2 61765 typ host
generation 0 ufrag EsAw network-id 2
a=candidate:473322822 1 tcp 1518280447 192.0.2.1 9 typ host tcptype
active generation 0 ufrag EsAw network-id 1
a=candidate:2154773085 1 tcp 1518214911 198.51.100.2 9 typ host
tcptype active generation 0 ufrag EsAw network-id 2
HTTP/1.1 200 OK
ETag: "abccd"
Content-Type: application/trickle-ice-sdpfrag
Content-Length: 252
a=ice-lite
a=ice-options:trickle ice2
a=group:BUNDLE 0 1
m=audio 9 UDP/TLS/RTP/SAVPF 111
a=mid:0
a=ice-ufrag:289b31b754eaa438
a=ice-pwd:0b66f472495ef0ccac7bda653ab6be49ea13114472a5d10a
a=candidate:1 1 udp 2130706431 198.51.100.1 39132 typ host
a=end-of-candidates
Figure 4: Example of an ICE Restart Request and Response
図4：アイス再起動リクエストと応答の例
To simplify the implementation of WHIP in both clients and media servers, WHIP introduces specific restrictions on WebRTC usage. The following subsections will explain these restrictions in detail.
クライアントとメディアサーバーの両方でのWHIPの実装を簡素化するために、WHIPはWeBRTCの使用に関する特定の制限を導入します。次のサブセクションでは、これらの制限を詳細に説明します。
Both the WHIP client and the WHIP endpoint SHALL support [RFC9143] and use the "max-bundle" policy as defined in [RFC9429]. The WHIP client and the media server MUST support multiplexed media associated with the BUNDLE group as per Section 9 of [RFC9143]. In addition, per [RFC9143], the WHIP client and media server SHALL use RTP/RTCP multiplexing for all bundled media. In order to reduce the network resources required at the media server, both the WHIP client and WHIP endpoints MUST include the "rtcp-mux-only" attribute in each bundled "m=" section as per Section 3 of [RFC8858].
WHIPクライアントとホイップエンドポイントの両方が[RFC9143]をサポートし、[RFC9429]で定義されている「最大バンドル」ポリシーを使用するものとします。WHIPクライアントとメディアサーバーは、[RFC9143]のセクション9に従って、バンドルグループに関連付けられた多重化されたメディアをサポートする必要があります。さらに、[RFC9143]に従って、WHIPクライアントとメディアサーバーは、バンドルされたすべてのメディアに対してRTP/RTCP多重化を使用するものとします。メディアサーバーで必要なネットワークリソースを削減するには、WHIPクライアントとホイップエンドポイントの両方に、[RFC8858]のセクション3に従って、各バンドルされた「M =」セクションに「RTCP-Muxのみ」属性を含める必要があります。
WHIP only supports a single MediaStream as defined in [RFC8830]; therefore, all "m=" sections MUST contain a "msid" attribute with the same value. The MediaStream MUST contain at least one MediaStreamTrack of any media kind, and it MUST NOT have two or more MediaStreamTracks for the same media (audio or video). However, it would be possible for future revisions of this specification to allow more than a single MediaStream or MediaStreamTrack of each media kind. Therefore, in order to ensure forward compatibility, if the number of audio and/or video MediaStreamTracks or the number of MediaStreams are not supported by the WHIP endpoint, it MUST reject the HTTP POST request with a "422 Unprocessable Content" or "400 Bad Request" error response. The WHIP endpoint MAY also return a problem statement that provides further error details about the failed request, as recommended in Section 4.1.
WHIPは、[RFC8830]で定義されているように、単一のMediaStreamのみをサポートします。したがって、すべての「m =」セクションには、同じ値の「MSID」属性を含める必要があります。MediaStreamには、あらゆるメディアの少なくとも1つのMediaStreamTrackが含まれている必要があり、同じメディア（オーディオまたはビデオ）に2つ以上のMediaStreamTrackを搭載してはなりません。ただし、この仕様の将来の改訂が、各メディアの種類の単一のMediaStreamまたはMediaStreamTrackを許可することが可能です。したがって、順方向の互換性を確保するために、オーディオおよび/またはビデオのMediaStreamTracksまたはMediaStreamの数がホイップエンドポイントによってサポートされていない場合、「422の未加工のコンテンツ」または「400の悪いリクエスト」エラー応答でHTTP Postリクエストを拒否する必要があります。ホイップエンドポイントは、セクション4.1で推奨されるように、失敗した要求に関するさらなるエラーの詳細を提供する問題ステートメントを返す場合があります。
The WHIP endpoint SHOULD NOT reject individual "m=" sections, as specified in Section 5.3.1 of [RFC9429], if an error occurs when processing the "m=" section; instead, it SHOULD reject the HTTP POST request with a "422 Unprocessable Content" or "400 Bad Request" error response to prevent having partially successful ingest sessions, which can be misleading to end users. The WHIP endpoint MAY also return a problem statement as recommended in Section 4.1 proving further error details about the failed request.
"m ="セクションの処理時にエラーが発生した場合、[rfc9429]のセクション5.3.1で指定されているように、ホイップエンドポイントは、個々の「m =」セクションを拒否してはなりません。代わりに、「422の処理不可能なコンテンツ」または「400の悪いリクエスト」エラー応答を使用して、HTTP POSTリクエストを拒否する必要があります。WHIPエンドポイントは、セクション4.1で推奨されるように、失敗した要求に関するさらなるエラーの詳細を証明する問題ステートメントを返すこともできます。
When a WHIP client sends an SDP offer, it SHOULD insert an SDP "setup" attribute with an "actpass" attribute value, as defined in [RFC8842]. However, if the WHIP client only implements the DTLS client role, it MAY use an SDP "setup" attribute with an "active" attribute value. If the WHIP endpoint does not support an SDP offer with an SDP "setup" attribute with an "active" attribute value, it SHOULD reject the request with a "422 Unprocessable Content" or "400 Bad Request" error response.
WHIPクライアントがSDPオファーを送信する場合、[RFC8842]で定義されているように、「ActPass」属性値を持つSDP「セットアップ」属性を挿入する必要があります。ただし、WHIPクライアントがDTLSクライアントの役割のみを実装する場合、「アクティブ」属性値を持つSDP「セットアップ」属性を使用する場合があります。WHIPエンドポイントが、「アクティブ」属性値を持つSDP「セットアップ」属性を持つSDPオファーをサポートしていない場合、「422未処理のコンテンツ」または「400不良リクエスト」エラー応答でリクエストを拒否する必要があります。
NOTE: [RFC8842] defines that the offerer must insert an SDP "setup" attribute with an "actpass" attribute value. However, the WHIP client will always communicate with a media server that is expected to support the DTLS server role, in which case the client might choose to only implement support for the DTLS client role.
注：[RFC8842]は、オファーが「ActPass」属性値を持つSDP「セットアップ」属性を挿入する必要があることを定義しています。ただし、WHIPクライアントは、DTLSサーバーの役割をサポートすることが期待されるメディアサーバーと常に通信します。この場合、クライアントはDTLSクライアントロールのサポートのみを実装することを選択できます。
The media server SHOULD support full ICE, unless it is connected to the Internet with an IP address that is accessible by each WHIP client that is authorized to use it, in which case it MAY support only ICE lite. The WHIP client MUST implement and use full ICE.
メディアサーバーは、それを使用することを許可されている各鞭クライアントがアクセスできるIPアドレスでインターネットに接続されていない限り、完全なICEをサポートする必要があります。その場合、Ice Liteのみをサポートできます。WHIPクライアントは、完全な氷を実装および使用する必要があります。
Trickle ICE and ICE restart support is OPTIONAL for both the WHIP clients and media servers as explained in Section 4.3.
セクション4.3で説明されているように、Trickle Ice and Ice Restartサポートは、ホイップクライアントとメディアサーバーの両方でオプションです。
WHIP endpoints and media servers might not be colocated on the same server, so it is possible to load balance incoming requests to different media servers.
ホイップのエンドポイントとメディアサーバーは同じサーバーにコロンケートされていない可能性があるため、入ってくるリクエストを異なるメディアサーバーにロードすることができます。
WHIP clients SHALL support HTTP redirections as per Section 15.4 of [RFC9110]. In order to avoid POST requests being redirected as GET requests, status codes "301 Moved Permanently" and "302 Found" MUST NOT be used; the preferred method for performing load balancing is via the "307 Temporary Redirect" response status code as described in Section 15.4.8 of [RFC9110]. Redirections are not required to be supported for the PATCH and DELETE requests.
WHIPクライアントは、[RFC9110]のセクション15.4に従って、HTTPリダイレクトをサポートするものとします。Get Requestsとしてリクエストがリダイレクトされることを避けるために、ステータスコード「301が永続的に移動」、「302が見つかった」は使用してはなりません。[RFC9110]のセクション15.4.8で説明されているように、負荷分散を実行するための好ましい方法は、「307一時リダイレクト」応答ステータスコードを介して行われます。リダイレクトは、リクエストを削除するためにサポートされる必要はありません。
In case of high load, the WHIP endpoints MAY return a "503 Service Unavailable" response indicating that the server is currently unable to handle the request due to a temporary overload or scheduled maintenance as described in Section 15.6.4 of [RFC9110], which will likely be alleviated after some delay. The WHIP endpoint might send a Retry-After header field indicating the minimum time that the user agent ought to wait before making a follow-up request as described in Section 10.2.3 of [RFC9110].
高負荷の場合、ホイップエンドポイントは、[RFC9110]のセクション15.6.4で説明されているように、一時的な過負荷またはスケジュールされたメンテナンスのためにサーバーが現在リクエストを処理できないことを示す「503サービスの利用できない」応答を返す場合があります。ホイップエンドポイントは、[RFC9110]のセクション10.2.3で説明されているように、フォローアップリクエストを行う前に、ユーザーエージェントが待つべき最小時間を示す、再試行後のヘッダーフィールドを送信する場合があります。
The WHIP endpoint MAY return STUN/TURN server configuration URLs and credentials usable by the client in the "201 Created" response to the HTTP POST request to the WHIP endpoint URL.
ホイップエンドポイントは、クライアントが使用できるStun/Turn Server構成URLと資格情報を返す場合があります。
A reference to each STUN/TURN server will be returned using the Link header field [RFC8288] with a "rel" attribute value of "ice-server". The Link target URI is the server URI as defined in [RFC7064] and [RFC7065]. The credentials are encoded in the Link target attributes as follows:
各スタン/ターンサーバーへの参照は、「Ice-Server」の「REL」属性値を持つリンクヘッダーフィールド[RFC8288]を使用して返されます。リンクターゲットURIは、[RFC7064]および[RFC7065]で定義されているサーバーURIです。資格情報は、次のようにリンクターゲット属性にエンコードされます。
* username: If the Link header field represents a Traversal Using Relays around NAT (TURN) server, then this attribute specifies the username to use with that TURN server.
* ユーザー名：リンクヘッダーフィールドがNAT（ターン）サーバーの周りのリレーを使用したトラバーサルを表す場合、この属性は、そのターンサーバーで使用するユーザー名を指定します。
* credential: This attribute represents a long-term authentication password, as described in Section 9.2 of [RFC8489].
* 資格情報：この属性は、[RFC8489]のセクション9.2で説明されているように、長期的な認証パスワードを表します。
Figure 5 illustrates the Link headers included in a "201 Created" response, providing the ICE server URLs and associated credentials.
図5は、アイスサーバーのURLと関連する資格情報を提供する「201」の「作成された」応答に含まれるリンクヘッダーを示しています。
Link: <stun:stun.example.net>; rel="ice-server"
Link: <turn:turn.example.net?transport=udp>; rel="ice-server";
username="user"; credential="myPassword"
Link: <turn:turn.example.net?transport=tcp>; rel="ice-server";
username="user"; credential="myPassword"
Link: <turns:turn.example.net?transport=tcp>; rel="ice-server";
username="user"; credential="myPassword"
Figure 5: Example of a STUN/TURN Server's Configuration
図5：スタン/ターンサーバーの構成の例
NOTE: The naming of both the "rel" attribute value of "ice-server" and the target attributes follows that used in the RTCConfiguration dictionary in Section 4.2.1 of the W3C WebRTC recommendation (see [W3C.REC-webrtc-20250313]). The "rel" attribute value of "ice-server" is not prepended with the "urn:ietf:params:whip:" so it can be reused by other specifications, which may use this mechanism to configure the usage of STUN/TURN servers.
注：「アイスサーバー」の「REL」属性値とターゲット属性の両方の命名は、W3C WeBRTC推奨のセクション4.2.1のRTCCONFiguration辞書で使用されているものです（[W3C.REC-WERBRTC-20250313]を参照）。「Ice-Server」の「Rel」属性値は、「urn：ietf：params：whip： "で準備されていません。したがって、他の仕様で再利用できます。
NOTE: Depending on the ICE agent implementation, the WHIP client may need to call the setConfiguration method before calling the setLocalDescription method with the local SDP offer in order to avoid having to perform an ICE restart for applying the updated STUN/TURN server configuration on the next ICE gathering phase.
注：ICEエージェントの実装に応じて、WHIPクライアントは、次のアイス収集フェーズで更新されたStun/Turnサーバー構成を適用するためにICE再起動を実行する必要がないように、ローカルSDPオファーでSetLocalDescriptionメソッドを呼び出す前にSetConfigurationメソッドを呼び出す必要がある場合があります。
There are some WebRTC implementations that do not support updating the STUN/TURN server configuration after the local offer has been created as specified in Section 4.1.18 of [RFC9429]. In order to support these clients, the WHIP endpoint MAY also include the STUN/ TURN server configuration in the responses to OPTIONS requests sent to the WHIP endpoint URL before the POST request is sent. However, this method is NOT RECOMMENDED to be used by the WHIP clients, and if it is supported by the underlying WHIP client's WebRTC implementation, the WHIP client SHOULD wait for the information to be returned by the WHIP endpoint in the response of the HTTP POST request instead.
[RFC9429]のセクション4.1.18で指定されているように、ローカルオファーが作成された後、Stun/Turn Server構成の更新をサポートしないWEBRTC実装があります。これらのクライアントをサポートするために、ホイップエンドポイントには、POSTリクエストが送信される前に、ホイップエンドポイントURLに送信されたオプションリクエストへの応答にStun/ Turnサーバー構成を含めることもできます。ただし、この方法は、WHIPクライアントが使用することをお勧めしません。基礎となるWHIPクライアントのWEBRTC実装によってサポートされている場合、HTTP POSTリクエストの応答でWHIPエンドポイントによって情報が返されるのをホイップクライアントが待機する必要があります。
The generation of the TURN server credentials may require sending a request to an external provider, which can both add latency to the OPTIONS request processing and increase the processing required to handle that request. In order to prevent this, the WHIP endpoint SHOULD NOT return the STUN/TURN server configuration if the OPTIONS request is a preflight request for CORS as defined in [FETCH], that is, if the OPTIONS request does not contain an Access-Control-Request-Method with a POST value and the Access-Control-Request-Headers HTTP header does not contain the Link value.
ターンサーバーの資格情報の生成には、リクエストを外部プロバイダーに送信する必要がある場合があります。これは、オプションリクエスト処理に遅延を追加し、そのリクエストを処理するために必要な処理を増やすことができます。これを防ぐために、オプション要求が[Fetch]で定義されているCORのプリフライトリクエストである場合、ホイップエンドポイントはスタン/ターンサーバー構成を返してはなりません。つまり、オプションリクエストにPOST値とアクセスコントロール-Request-Headers HTTP Headerがリンク値を含む場合は、アクセスコントロールレクエストメソッドが含まれていません。
The WHIP clients MAY also support configuring the STUN/TURN server URIs with long-term credentials provided by either the broadcasting service or an external TURN provider, overriding the values provided by the WHIP endpoint.
WHIPクライアントは、Broadcastingサービスまたは外部ターンプロバイダーによって提供される長期的な資格情報を使用して、Stun/Turn Server URISの構成をサポートし、WHIPエンドポイントによって提供される値をオーバーライドすることもできます。
[RFC8836] defines the congestion control requirements for interactive real-time media to be used in WebRTC. These requirements are based on the assumption that the data needs to be provided continuously within a very limited time window (a delay of no more than hundreds of milliseconds end-to-end). If the latency target is higher, some of the requirements present in [RFC8836] could be relaxed to allow more flexible implementations.
[RFC8836]は、WeBRTCで使用するインタラクティブなリアルタイムメディアの輻輳制御要件を定義しています。これらの要件は、データを非常に限られた時間ウィンドウ（数百ミリ秒以下のエンドツーエンド以下の遅延）内で継続的に提供する必要があるという仮定に基づいています。遅延ターゲットが高い場合、[RFC8836]に存在する要件の一部をリラックスさせて、より柔軟な実装を可能にする可能性があります。
All WHIP endpoints, sessions, and clients MUST support HTTP authentication as per Section 11 of [RFC9110]. Additionally, in order to ensure interoperability, bearer token authentication as defined in the next section MUST be supported by all WHIP entities. However, this does not preclude the support of additional HTTP authentication schemes as defined in Section 11.6 of [RFC9110].
すべてのWHIPエンドポイント、セッション、およびクライアントは、[RFC9110]のセクション11に従ってHTTP認証をサポートする必要があります。さらに、相互運用性を確保するために、次のセクションで定義されているベアラートークン認証は、すべてのWHIPエンティティでサポートする必要があります。ただし、これは、[RFC9110]のセクション11.6で定義されている追加のHTTP認証スキームのサポートを排除するものではありません。
WHIP endpoints and sessions MAY require the HTTP request to be authenticated using an HTTP Authorization header field with a bearer token as specified in Section 2.1 of [RFC6750]. WHIP clients MUST implement this authentication and authorization mechanism and send the HTTP Authorization header field in all HTTP requests sent to either the WHIP endpoint or session (except the preflight OPTIONS requests for CORS).
ホイップのエンドポイントとセッションでは、[RFC6750]のセクション2.1で指定されているように、BEARERトークンを備えたHTTP認証ヘッダーフィールドを使用してHTTPリクエストを認証する必要があります。WHIPクライアントは、この認証と承認のメカニズムを実装し、ホイップエンドポイントまたはセッション（CORSのプリフライトオプションリクエストを除く）に送信されるすべてのHTTPリクエストでHTTP認証ヘッダーフィールドを送信する必要があります。
The nature, syntax, and semantics of the bearer token, as well as how to distribute it to the client, are outside the scope of this document. Examples of tokens that could be used include, but are not limited to, JSON Web Tokens (JWTs) as per [RFC8725] and a shared secret stored on a database. The tokens are typically made available to the end user alongside the WHIP endpoint URL and configured on the WHIP clients (similar to the way Real Time Messaging Protocol (RTMP) URLs and Stream Keys are distributed).
ベアラートークンの性質、構文、およびセマンティクス、およびそれをクライアントに配布する方法は、このドキュメントの範囲外です。使用できるトークンの例には、[RFC8725]に従ってJSON Webトークン（JWTS）とデータベースに保存されている共有秘密が含まれます。トークンは通常、ホイップエンドポイントURLと一緒にエンドユーザーが利用できるようになり、ホイップクライアントで構成されています（リアルタイムメッセージングプロトコル（RTMP）URLとストリームキーが分散される方法と同様）。
WHIP endpoints and sessions could perform the authentication and authorization by encoding an authentication token within the URLs for the WHIP endpoints or sessions instead. In case the WHIP client is not configured to use a bearer token, the HTTP Authorization header field MUST NOT be sent in any request.
ホイップのエンドポイントとセッションは、ホイップエンドポイントまたはセッションのURL内の認証トークンをエンコードすることにより、認証と承認を実行できます。WHIPクライアントがBearerトークンを使用するように構成されていない場合、HTTP認証ヘッダーフィールドをリクエストで送信してはなりません。
Simulcast as per [RFC8853] MAY be supported by both the media servers and WHIP clients through negotiation in the SDP offer/answer.
[RFC8853]に従って同時放送されると、SDPオファー/回答の交渉を通じて、メディアサーバーとWHIPクライアントの両方がサポートできます。
If the client supports simulcast and wants to enable it for ingesting, it MUST negotiate the support in the SDP offer according to the procedures in Section 5.3 of [RFC8853]. A server accepting a simulcast offer MUST create an answer according to the procedures in Section 5.3.2 of [RFC8853].
クライアントがSimulcastをサポートし、摂取のためにそれを有効にしたい場合、[RFC8853]のセクション5.3の手順に従ってSDPオファーのサポートを交渉する必要があります。シンプルなオファーを受け入れるサーバーは、[RFC8853]のセクション5.3.2の手順に従って回答を作成する必要があります。
It is possible for both media servers and WHIP clients to support Scalable Video Coding (SVC). However, as there is no universal negotiation mechanism in SDP for SVC, the encoder must consider the negotiated codec(s), intended usage, and SVC support in available decoders when configuring SVC.
メディアサーバーとWHIPクライアントの両方が、スケーラブルなビデオコーディング（SVC）をサポートすることが可能です。ただし、SVCのSDPには普遍的な交渉メカニズムがないため、エンコーダーは、SVCを構成する際に利用可能なデコーダーで交渉されたコーデック、意図された使用、およびSVCサポートを考慮する必要があります。
In order to support future extensions to be defined for WHIP, a common procedure for registering and announcing the new extensions is defined.
WHIPに対して定義される将来の拡張機能をサポートするために、新しい拡張機能を登録および発表するための一般的な手順が定義されています。
Protocol extensions supported by the WHIP sessions MUST be advertised to the WHIP client in the "201 Created" response to the initial HTTP POST request sent to the WHIP endpoint. The WHIP endpoint MUST return one Link header field for each extension that it supports, with the extension "rel" attribute value containing the extension URN and the URL for the HTTP resource that will be available for receiving requests related to that extension.
ホイップセッションでサポートされているプロトコル拡張は、ホイップエンドポイントに送信された最初のHTTP POSTリクエストに対する「201が作成した」応答で、WHIPクライアントに宣伝する必要があります。WHIPエンドポイントは、サポートする各拡張機能の1つのリンクヘッダーフィールドを返す必要があります。拡張機能の「rel」属性値は、その拡張機能に関連するリクエストを受信するために使用できるhttpリソースの拡張機能とURLを含む。
Protocol extensions are optional for both WHIP clients and servers. WHIP clients MUST ignore any Link target attribute with an unknown "rel" attribute value, and WHIP sessions MUST NOT require the usage of any extension.
プロトコル拡張は、WHIPクライアントとサーバーの両方でオプションです。WHIPクライアントは、不明な「REL」属性値を持つLink Target属性を無視する必要があり、WHIPセッションは拡張機能の使用を必要としてはなりません。
Each protocol extension MUST register a unique "rel" attribute value that starts with the prefix "urn:ietf:params:whip:ext" in the "WebRTC-HTTP Ingestion Protocol (WHIP) Extension URNs" registry (Section 6.4).
各プロトコル拡張は、「webrtc-http ingestionプロトコル（whip）拡張urns」レジストリ（セクション6.4）で、プレフィックス「urn：ietf：params：whip：ext」で始まる一意の「rel」属性値を登録する必要があります。
For example, consider a potential extension of server-to-client communication using server-sent events as specified in Section 9.2 of [HTML]. The URL for connecting to the server-sent event resource for the ingested stream could be returned in the initial HTTP "201 Created" response with a Link header field and a "rel" attribute of "urn:ietf:params:whip:ext:example:server-sent-events" (this document does not specify such an extension and uses it only as an example).
たとえば、[HTML]のセクション9.2で指定されているサーバーセントイベントを使用したサーバーからクライアントへの通信の潜在的な拡張を検討してください。摂取されたストリームのサーバーセントイベントリソースに接続するためのURLは、リンクヘッダーフィールドと「urn：ietf：params：ext：expemers：example：empers-events」の「rel」属性を使用して、初期のhttp "201" Response "Responseで返される可能性があります（このドキュメントはそのような拡張機能を指定しません。
In this theoretical case, the "201 Created" response to the HTTP POST request would look like:
この理論的場合、HTTP POSTリクエストに対する「201が作成した」応答は次のようになります。
Figure 6 shows the "201 Created" response to the HTTP POST request in this theoretical case (i.e., the WHIP extension supported by the WHIP session, as indicated in the Link header of the "201 Created" response).
図6は、この理論的ケースのHTTP POST要求に対する「201」の「作成」応答（つまり、「201の作成」応答のリンクヘッダーに示されているように、WHIPセッションでサポートされる鞭拡張）を示しています。
HTTP/1.1 201 Created
Content-Type: application/sdp
Location: https://whip.example.com/session/id
Link: <https://whip.example.com/session/id/sse>;
rel="urn:ietf:params:whip:ext:example:server-sent-events"
Figure 6: Example of a WHIP Extension
図6：鞭拡張の例
This document specifies a new protocol on top of HTTP and WebRTC; thus, security protocols and considerations from related specifications apply to the WHIP specification. These include:
このドキュメントは、HTTPとWeBRTCの上に新しいプロトコルを指定します。したがって、関連する仕様からのセキュリティプロトコルと考慮事項は、WHIP仕様に適用されます。これらには以下が含まれます：
* WebRTC security considerations: See [RFC8826]. HTTPS SHALL be used in order to preserve the WebRTC security model.
* WEBRTCセキュリティ上の考慮事項：[RFC8826]を参照してください。WeBRTCセキュリティモデルを保存するために、HTTPSを使用するものとします。
* Transport Layer Security (TLS): See [RFC8446] and [RFC9147].
* 輸送層のセキュリティ（TLS）：[RFC8446]および[RFC9147]を参照してください。
* HTTP security: See Section 11 of [RFC9112] and Section 17 of [RFC9110].
* HTTPセキュリティ：[RFC9112]のセクション11および[RFC9110]のセクション17を参照してください。
* URI security: See Section 7 of [RFC3986].
* URIセキュリティ：[RFC3986]のセクション7を参照してください。
On top of that, WHIP exposes a thin new attack surface specific to the REST API methods used within it:
それに加えて、WHIPは、その中で使用されるREST APIメソッドに固有の薄い新しい攻撃面を露出します。
* HTTP POST flooding and resource exhaustion: It would be possible for an attacker in possession of authentication credentials valid for ingesting a WHIP stream to make multiple HTTP POST requests to the WHIP endpoint. This will force the WHIP endpoint to process the incoming SDP and allocate resources for being able to set up the DTLS/ICE connection. While the malicious client does not need to initiate the DTLS/ICE connection at all, the WHIP session will have to wait for the DTLS/ICE connection timeout in order to release the associated resources. If the connection rate is high enough, this could lead to resource exhaustion on the servers handling the requests, and they will not be able to process legitimate incoming ingests. In order to prevent this scenario, WHIP endpoints SHOULD implement a rate limit and avalanche control mechanism for incoming initial HTTP POST requests.
* http洪水とリソースの疲労：攻撃者が、ホイップストリームを摂取するために有効な認証資格情報を所持して、ホイップエンドポイントに複数のHTTP投稿要求を行うことが可能です。これにより、ホイップエンドポイントは、着信SDPを処理し、DTLS/ICE接続をセットアップできるようにリソースを割り当てます。悪意のあるクライアントはDTL/ICE接続をまったく開始する必要はありませんが、WHIPセッションは、関連するリソースをリリースするためにDTLS/ICE接続タイムアウトを待つ必要があります。接続レートが十分に高い場合、これによりリクエストを処理するサーバーのリソースの消耗につながる可能性があり、合法的な摂取を処理することはできません。このシナリオを防ぐために、ホイップエンドポイントは、初期のHTTP POSTリクエストを受信するためのレート制限と雪崩制御メカニズムを実装する必要があります。
* Insecure Direct Object References (IDORs) for WHIP session URLs: If the URLs returned by the WHIP endpoint for the location of WHIP sessions are easy to guess, it would be possible for an attacker to send multiple HTTP DELETE requests and terminate all the WHIP sessions currently running. In order to prevent this scenario, WHIP endpoints SHOULD generate URLs with enough randomness, using a cryptographically secure pseudorandom number generator following the best practices in "Randomness Requirements for Security" [RFC4086], and implement a rate limit and avalanche control mechanism for HTTP DELETE requests. The security considerations for Universally Unique IDentifiers (UUIDs) in Section 8 of [RFC9562] are applicable for generating the WHIP session URLs.
* WHIPセッションURLの不安定な直接オブジェクト参照（IDORS）：ホイップセッションの場所のホイップエンドポイントによって返されるURLが推測しやすい場合、攻撃者は複数のHTTP削除リクエストを送信し、現在実行されているすべてのホイップセッションを終了することができます。このシナリオを防ぐために、ホイップエンドポイントは、「セキュリティのランダム性要件」[RFC4086]のベストプラクティスに従って暗号化されたセキュアーな擬似ランダム数ジェネレーターを使用して、十分なランダム性のあるURLを生成し、HTTPデレクトリクエストのレート制限と雪崩制御メカニズムを実装する必要があります。[RFC9562]のセクション8の普遍的に一意の識別子（UUID）のセキュリティ上の考慮事項は、WHIPセッションURLの生成に適用できます。
* HTTP PATCH flooding: Similar to the HTTP POST flooding, a malicious client could also create resource exhaustion by sending multiple HTTP PATCH requests to the WHIP session, although the WHIP sessions can limit the impact by not allocating new ICE candidates and reusing the existing ICE candidates when doing ICE restarts. In order to prevent this scenario, WHIP endpoints SHOULD implement a rate limit and avalanche control mechanism for incoming HTTP PATCH requests.
* HTTPパッチ洪水：HTTP後の洪水と同様に、悪意のあるクライアントは、ホイップセッションに複数のHTTPパッチ要求を送信することでリソースの疲労を作成することもできますが、ホイップセッションは新しいICE候補者を割り当てず、ICEの再起動時に既存のICE候補者を再利用することで影響を制限する可能性があります。このシナリオを防ぐために、ホイップエンドポイントは、HTTPパッチ要求を着信するためのレート制限と雪崩制御メカニズムを実装する必要があります。
Per this specification, IANA has added a new link relation type and a new URN sub-namespace for WHIP. IANA has also created registries to manage entries within the "urn:ietf:params:whip" and "urn:ietf:params:whip:ext" namespaces.
この仕様に従って、IANAは新しいリンク関係タイプとWHIP用の新しいurnサブネームスペースを追加しました。IANAは、「urn：ietf：params：whip」および「urn：ietf：params：whip：ext」namespaces内のエントリを管理するためのレジストリを作成しました。
The link relation type below has been registered by IANA in the "Link Relation Types" registry per Section 4.2 of [RFC8288]:
以下のリンク関係タイプは、[RFC8288]のセクション4.2ごとに「リンク関係タイプ」レジストリにIANAによって登録されています。
Relation Name:
関係名：
ice-server
アイスサーバー
Description:
説明：
Conveys the STUN and TURN servers that can be used by an ICE agent to establish a connection with a peer.
アイスエージェントがピアとの接続を確立するために使用できるスタンおよびターンサーバーを伝えます。
Reference:
参照：
RFC 9725
RFC 9725
IANA has added a new entry in the "IETF URN Sub-namespace for Registered Protocol Parameter Identifiers" registry, following the template in [RFC3553]:
IANAは、[RFC3553]のテンプレートに従って、「登録プロトコルパラメーター識別子のIETF URNサブネームスペース」レジストリに新しいエントリを追加しました。
Registry name:
レジストリ名：
whip
ホイップ
Specification:
仕様：
RFC 9725
RFC 9725
Repository:
リポジトリ：
<https://www.iana.org/assignments/whip>
<https://www.iana.org/assignments/whip>
Index value:
インデックス値：
An IANA-assigned positive integer that identifies the registration. The first entry added to this registry uses the value 1, and this value is incremented for each subsequent entry added to the registry.
登録を識別するIANAが割り当てた正の整数。このレジストリに追加された最初のエントリは値1を使用し、この値はレジストリに追加された後続のエントリごとに増加します。
To manage this sub-namespace, IANA has created two registries within a new registry group called "WebRTC-HTTP Ingestion Protocol (WHIP)":
このサブネームスペースを管理するために、IANAは「Webrtc-HTTP Ingestion Protocol（WHIP）」と呼ばれる新しいレジストリグループ内に2つのレジストリを作成しました。
* "WebRTC-HTTP Ingestion Protocol (WHIP) URNs" registry (Section 6.3)
* 「webrtc-http摂取プロトコル（whip）urns」レジストリ（セクション6.3）
* "WebRTC-HTTP Ingestion Protocol (WHIP) Extension URNs" registry (Section 6.4)
* 「webrtc-http摂取プロトコル（whip）拡張urns」レジストリ（セクション6.4）
The "WebRTC-HTTP Ingestion Protocol (WHIP) URNs" registry is used to manage entries within the "urn:ietf:params:whip" namespace. The registration procedure is "Specification Required" [RFC8126]. The registry contains the following fields: URN, Name, Reference, IANA Registry Reference, and Change Controller. This document is listed as the reference.
「webrtc-http ingestionプロトコル（whip）urns」レジストリは、「urn：ietf：params：whip "namespace内のエントリを管理するために使用されます。登録手順は「必要な仕様」です[RFC8126]。レジストリには、次のフィールドが含まれています。URN、名前、参照、IANAレジストリリファレンス、および変更コントローラー。このドキュメントはリファレンスとしてリストされています。
The registry contains a single initial entry:
レジストリには、単一の初期エントリが含まれています。
URN:
URN:
urn:ietf:params:whip:ext
urn：ietf：params：whip：ext
Name:
名前：
WebRTC-HTTP Ingestion Protocol (WHIP) extension URNs
webrtc-http摂取プロトコル（whip）拡張ウルン
Reference:
参照：
Section 6.4 of RFC 9725
RFC 9725のセクション6.4
IANA Registry Reference:
IANAレジストリリファレンス：
See "WebRTC-HTTP Ingestion Protocol (WHIP) Extension URNs" on <https://www.iana.org/assignments/whip>
<https://www.iana.org/assignments/whip>の「webrtc-http ingestion protocol（whip）拡張ウルン」を参照してください
Change Controller:
Change Controller：
IETF
IETF
The "WebRTC-HTTP Ingestion Protocol (WHIP) Extension URNs" registry is used to manage entries within the "urn:ietf:params:whip:ext" namespace. The registration procedure is "Specification Required" [RFC8126]. The registry contains the following fields: URN, Name, Reference, IANA Registry Reference, and Change Controller. This document is listed as the reference.
「webrtc-http ingestionプロトコル（whip）拡張ウルン」レジストリは、「urn：ietf：params：whip：ext "namespace内のエントリを管理するために使用されます。登録手順は「必要な仕様」です[RFC8126]。レジストリには、次のフィールドが含まれています。URN、名前、参照、IANAレジストリリファレンス、および変更コントローラー。このドキュメントはリファレンスとしてリストされています。
A WHIP extension URN is used as a value in the "rel" attribute of the Link header as defined in Section 4.9 for the purpose of signaling the WHIP extensions supported by the WHIP endpoint. WHIP extension URNs have an "ext" type.
鞭拡張URNは、ホイップエンドポイントでサポートされている鞭拡張を信号する目的で、セクション4.9で定義されているリンクヘッダーの「rel」属性の値として使用されます。WHIP拡張ウルンには「ext」タイプがあります。
This section defines the process for registering new URNs in the "WebRTC-HTTP Ingestion Protocol (WHIP) URNs" registry (Section 6.3) and the "WebRTC-HTTP Ingestion Protocol (WHIP) Extension URNs" registry (Section 6.4).
このセクションでは、「webrtc-http摂取プロトコル（whip）urns」レジストリ（セクション6.3）および「webrtc-http摂取プロトコル（whip）拡張ウルン」レジストリ（セクション6.4）に新しいurnsを登録するプロセスを定義します。
The IETF has created a mailing list, <wish@ietf.org>, which can be used for public discussion of proposals prior to registration. Use of the mailing list is strongly encouraged. A designated expert (DE) [RFC8126], appointed by the IESG, will monitor the <wish@ietf.org> mailing list and review registrations.
IETFは、登録前に提案の公開討論に使用できるメーリングリスト<sish@ietf.org>を作成しました。メーリングリストの使用を強くお勧めします。IESGによって任命された指定された専門家（DE）[RFC8126]は、<sish@ietf.org>メーリングリストを監視し、登録を確認します。
Registration of new entries in the WHIP registries defined in this document MUST be documented in a permanent and readily available public specification, in sufficient detail so that interoperability between independent implementations is possible, and reviewed by the DE as per Section 4.6 of [RFC8126]. A Standards Track RFC is REQUIRED for the registration of new value data types that modify existing properties. A Standards Track RFC is also REQUIRED for registration of WHIP extension URNs that modify WHIP extensions previously documented in an existing RFC.
このドキュメントで定義されているWHIPレジストリへの新しいエントリの登録は、独立した実装間の相互運用性が可能であるように、[RFC8126]のセクション4.6に従ってDEによってレビューされるように、恒久的で容易に利用可能な公開仕様で十分に詳細に文書化する必要があります。既存のプロパティを変更する新しい値データ型の登録には、RFCを追跡する標準トラックが必要です。RFCを追跡する標準トラックは、既存のRFCで以前に文書化されたWHIP拡張機能を変更するWHIP拡張URNの登録にも必要です。
The registration procedure begins when a completed registration template, defined in Section 6.5.3, is sent to <iana@iana.org>. Decisions made by the DE can be appealed to an Applications and Real-Time (ART) Area Director, then to the IESG. The normal appeals procedure described in RFC 2026 [BCP9] is to be followed.
登録手順は、セクション6.5.3で定義されている完了した登録テンプレートが<iana@iana.org>に送信されると開始されます。DEによって行われた決定は、アプリケーションとリアルタイム（ART）エリアディレクター、次にIESGに上訴することができます。RFC 2026 [BCP9]に記載されている通常の控訴手順に従うことになります。
Once the registration procedure concludes successfully, IANA will create or modify the corresponding record in the "WebRTC-HTTP Ingestion Protocol (WHIP) URNs Registry" or "WebRTC-HTTP Ingestion Protocol (WHIP) Extension URNs" registry.
登録手順が順調に終了すると、IANAは「webrtc-http摂取プロトコル（whip）urnsレジストリ」または「webrtc-http ingestionプロトコル（whip）拡張ウルン」レジストリで対応するレコードを作成または変更します。
An RFC specifying one or more new WHIP extension URNs MUST include the completed registration template(s), which MAY be expanded with additional information. These completed template(s) are intended to go in the body of the document, not in the IANA Considerations section. The RFC MUST include the syntax and semantics of any extension-specific attributes that may be provided in a Link header field advertising the extension.
1つまたは複数の新しい鞭拡張URNを指定するRFCには、追加情報が付いて拡張される可能性のある登録テンプレートを完了する必要があります。これらの完成したテンプレートは、IANAの考慮事項セクションではなく、ドキュメントの本体に移動することを目的としています。RFCには、拡張機能を宣伝するリンクヘッダーフィールドで提供される可能性のある拡張固有の属性の構文とセマンティクスを含める必要があります。
The DE is expected to do the following:
DEは次のことを行うことが期待されています。
* Ascertain the existence of suitable documentation (a specification) as described in [RFC8126] and verify that the document is permanently and publicly available. Specifications should be documented in an Internet-Draft.
* [RFC8126]で説明されている適切なドキュメント（仕様）の存在を確認し、ドキュメントが永続的かつ公開されていることを確認します。仕様は、インターネットドラフトに文書化する必要があります。
* Check the clarity of purpose and use of the requested registration.
* 要求された登録の目的と使用の明確さを確認してください。
* Verify that any request for one of these registrations has been made available for review and comments by posting the request to the <wish@ietf.org> mailing list.
* これらの登録のいずれかのリクエストが、<wish@ietf.org>メーリングリストにリクエストを投稿することにより、レビューとコメントのために利用可能になったことを確認します。
* Ensure that any other request for a code point does not conflict with work that is active or already published by the IETF.
* コードポイントの他の要求が、IETFによってアクティブまたはすでに公開されている作業と競合しないことを確認してください。
A WHIP extension URN is defined by completing the following template:
WHIP拡張URNは、次のテンプレートを完成させることによって定義されます。
URN:
URN:
A unique URN (e.g., "urn:ietf:params:whip:ext:example:server-sent-events")
一意のur（例： "urn：ietf：params：whip：ext：example：server-sent-events"））
Name:
名前：
A descriptive name (e.g., "Sender Side events")
説明的な名前（例：「送信者サイドイベント」）
Reference:
参照：
A formal reference to the publicly available specification
公開されている仕様への正式な参照
IANA Registry Reference:
IANAレジストリリファレンス：
The registry related to the new URN
新しいurnに関連するレジストリ
Change Controller:
Change Controller：
For Standards Track documents, this is "IETF". Otherwise, this is the name of the person or body that has change control over the specification.
標準の場合、ドキュメントを追跡すると、これは「IETF」です。それ以外の場合、これは仕様を制御する人または身体の名前です。
[FETCH] WHATWG, "Fetch", WHATWG Living Standard,
<https://fetch.spec.whatwg.org>. Commit snapshot:
<https://fetch.spec.whatwg.org/commit-snapshots/
edfa8d100cf1ecfde385f65c172e0e8d018fcd98/>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264,
DOI 10.17487/RFC3264, June 2002,
<https://www.rfc-editor.org/info/rfc3264>.
[RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An
IETF URN Sub-namespace for Registered Protocol
Parameters", BCP 73, RFC 3553, DOI 10.17487/RFC3553, June
2003, <https://www.rfc-editor.org/info/rfc3553>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005,
<https://www.rfc-editor.org/info/rfc4086>.
[RFC5789] Dusseault, L. and J. Snell, "PATCH Method for HTTP",
RFC 5789, DOI 10.17487/RFC5789, March 2010,
<https://www.rfc-editor.org/info/rfc5789>.
[RFC6585] Nottingham, M. and R. Fielding, "Additional HTTP Status
Codes", RFC 6585, DOI 10.17487/RFC6585, April 2012,
<https://www.rfc-editor.org/info/rfc6585>.
[RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization
Framework: Bearer Token Usage", RFC 6750,
DOI 10.17487/RFC6750, October 2012,
<https://www.rfc-editor.org/info/rfc6750>.
[RFC7064] Nandakumar, S., Salgueiro, G., Jones, P., and M. Petit-
Huguenin, "URI Scheme for the Session Traversal Utilities
for NAT (STUN) Protocol", RFC 7064, DOI 10.17487/RFC7064,
November 2013, <https://www.rfc-editor.org/info/rfc7064>.
[RFC7065] Petit-Huguenin, M., Nandakumar, S., Salgueiro, G., and P.
Jones, "Traversal Using Relays around NAT (TURN) Uniform
Resource Identifiers", RFC 7065, DOI 10.17487/RFC7065,
November 2013, <https://www.rfc-editor.org/info/rfc7065>.
[RFC7675] Perumal, M., Wing, D., Ravindranath, R., Reddy, T., and M.
Thomson, "Session Traversal Utilities for NAT (STUN) Usage
for Consent Freshness", RFC 7675, DOI 10.17487/RFC7675,
October 2015, <https://www.rfc-editor.org/info/rfc7675>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8288] Nottingham, M., "Web Linking", RFC 8288,
DOI 10.17487/RFC8288, October 2017,
<https://www.rfc-editor.org/info/rfc8288>.
[RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive
Connectivity Establishment (ICE): A Protocol for Network
Address Translator (NAT) Traversal", RFC 8445,
DOI 10.17487/RFC8445, July 2018,
<https://www.rfc-editor.org/info/rfc8445>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
[RFC8489] Petit-Huguenin, M., Salgueiro, G., Rosenberg, J., Wing,
D., Mahy, R., and P. Matthews, "Session Traversal
Utilities for NAT (STUN)", RFC 8489, DOI 10.17487/RFC8489,
February 2020, <https://www.rfc-editor.org/info/rfc8489>.
[RFC8725] Sheffer, Y., Hardt, D., and M. Jones, "JSON Web Token Best
Current Practices", BCP 225, RFC 8725,
DOI 10.17487/RFC8725, February 2020,
<https://www.rfc-editor.org/info/rfc8725>.
[RFC8826] Rescorla, E., "Security Considerations for WebRTC",
RFC 8826, DOI 10.17487/RFC8826, January 2021,
<https://www.rfc-editor.org/info/rfc8826>.
[RFC8830] Alvestrand, H., "WebRTC MediaStream Identification in the
Session Description Protocol", RFC 8830,
DOI 10.17487/RFC8830, January 2021,
<https://www.rfc-editor.org/info/rfc8830>.
[RFC8838] Ivov, E., Uberti, J., and P. Saint-Andre, "Trickle ICE:
Incremental Provisioning of Candidates for the Interactive
Connectivity Establishment (ICE) Protocol", RFC 8838,
DOI 10.17487/RFC8838, January 2021,
<https://www.rfc-editor.org/info/rfc8838>.
[RFC8839] Petit-Huguenin, M., Nandakumar, S., Holmberg, C., Keränen,
A., and R. Shpount, "Session Description Protocol (SDP)
Offer/Answer Procedures for Interactive Connectivity
Establishment (ICE)", RFC 8839, DOI 10.17487/RFC8839,
January 2021, <https://www.rfc-editor.org/info/rfc8839>.
[RFC8840] Ivov, E., Stach, T., Marocco, E., and C. Holmberg, "A
Session Initiation Protocol (SIP) Usage for Incremental
Provisioning of Candidates for the Interactive
Connectivity Establishment (Trickle ICE)", RFC 8840,
DOI 10.17487/RFC8840, January 2021,
<https://www.rfc-editor.org/info/rfc8840>.
[RFC8842] Holmberg, C. and R. Shpount, "Session Description Protocol
(SDP) Offer/Answer Considerations for Datagram Transport
Layer Security (DTLS) and Transport Layer Security (TLS)",
RFC 8842, DOI 10.17487/RFC8842, January 2021,
<https://www.rfc-editor.org/info/rfc8842>.
[RFC8853] Burman, B., Westerlund, M., Nandakumar, S., and M. Zanaty,
"Using Simulcast in Session Description Protocol (SDP) and
RTP Sessions", RFC 8853, DOI 10.17487/RFC8853, January
2021, <https://www.rfc-editor.org/info/rfc8853>.
[RFC8858] Holmberg, C., "Indicating Exclusive Support of RTP and RTP
Control Protocol (RTCP) Multiplexing Using the Session
Description Protocol (SDP)", RFC 8858,
DOI 10.17487/RFC8858, January 2021,
<https://www.rfc-editor.org/info/rfc8858>.
[RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Semantics", STD 97, RFC 9110,
DOI 10.17487/RFC9110, June 2022,
<https://www.rfc-editor.org/info/rfc9110>.
[RFC9112] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP/1.1", STD 99, RFC 9112, DOI 10.17487/RFC9112,
June 2022, <https://www.rfc-editor.org/info/rfc9112>.
[RFC9143] Holmberg, C., Alvestrand, H., and C. Jennings,
"Negotiating Media Multiplexing Using the Session
Description Protocol (SDP)", RFC 9143,
DOI 10.17487/RFC9143, February 2022,
<https://www.rfc-editor.org/info/rfc9143>.
[RFC9147] Rescorla, E., Tschofenig, H., and N. Modadugu, "The
Datagram Transport Layer Security (DTLS) Protocol Version
1.3", RFC 9147, DOI 10.17487/RFC9147, April 2022,
<https://www.rfc-editor.org/info/rfc9147>.
[RFC9429] Uberti, J., Jennings, C., and E. Rescorla, Ed.,
"JavaScript Session Establishment Protocol (JSEP)",
RFC 9429, DOI 10.17487/RFC9429, April 2024,
<https://www.rfc-editor.org/info/rfc9429>.
[RFC9562] Davis, K., Peabody, B., and P. Leach, "Universally Unique
IDentifiers (UUIDs)", RFC 9562, DOI 10.17487/RFC9562, May
2024, <https://www.rfc-editor.org/info/rfc9562>.
[W3C.REC-ldp-20150226]
Arwe, J., Ed., Speicher, S., Ed., and A. Malhotra, Ed.,
"Linked Data Platform 1.0", W3C Recommendation, 26
February 2015,
<https://www.w3.org/TR/2015/REC-ldp-20150226/>. Latest
version available at: <https://www.w3.org/TR/ldp/>.
[BCP56] Best Current Practice 56,
<https://www.rfc-editor.org/info/bcp56>.
At the time of writing, this BCP comprises the following:
Nottingham, M., "Building Protocols with HTTP", BCP 56,
RFC 9205, DOI 10.17487/RFC9205, June 2022,
<https://www.rfc-editor.org/info/rfc9205>.
[BCP9] Best Current Practice 9,
<https://www.rfc-editor.org/info/bcp9>.
At the time of writing, this BCP comprises the following:
Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996,
<https://www.rfc-editor.org/info/rfc2026>.
Dusseault, L. and R. Sparks, "Guidance on Interoperation
and Implementation Reports for Advancement to Draft
Standard", BCP 9, RFC 5657, DOI 10.17487/RFC5657,
September 2009, <https://www.rfc-editor.org/info/rfc5657>.
Housley, R., Crocker, D., and E. Burger, "Reducing the
Standards Track to Two Maturity Levels", BCP 9, RFC 6410,
DOI 10.17487/RFC6410, October 2011,
<https://www.rfc-editor.org/info/rfc6410>.
Resnick, P., "Retirement of the "Internet Official
Protocol Standards" Summary Document", BCP 9, RFC 7100,
DOI 10.17487/RFC7100, December 2013,
<https://www.rfc-editor.org/info/rfc7100>.
Kolkman, O., Bradner, S., and S. Turner, "Characterization
of Proposed Standards", BCP 9, RFC 7127,
DOI 10.17487/RFC7127, January 2014,
<https://www.rfc-editor.org/info/rfc7127>.
Dawkins, S., "Increasing the Number of Area Directors in
an IETF Area", BCP 9, RFC 7475, DOI 10.17487/RFC7475,
March 2015, <https://www.rfc-editor.org/info/rfc7475>.
Halpern, J., Ed. and E. Rescorla, Ed., "IETF Stream
Documents Require IETF Rough Consensus", BCP 9, RFC 8789,
DOI 10.17487/RFC8789, June 2020,
<https://www.rfc-editor.org/info/rfc8789>.
Rosen, B., "Responsibility Change for the RFC Series",
BCP 9, RFC 9282, DOI 10.17487/RFC9282, June 2022,
<https://www.rfc-editor.org/info/rfc9282>.
[HTML] WHATWG, "HTML", WHATWG Living Standard,
<https://html.spec.whatwg.org/>. Commit snapshot:
<https://html.spec.whatwg.org/commit-
snapshots/09db56ba9343c597340b2c7715f43ff9b10826f6/>.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
DOI 10.17487/RFC3261, June 2002,
<https://www.rfc-editor.org/info/rfc3261>.
[RFC6120] Saint-Andre, P., "Extensible Messaging and Presence
Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120,
March 2011, <https://www.rfc-editor.org/info/rfc6120>.
[RFC7826] Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M.,
and M. Stiemerling, Ed., "Real-Time Streaming Protocol
Version 2.0", RFC 7826, DOI 10.17487/RFC7826, December
2016, <https://www.rfc-editor.org/info/rfc7826>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC8836] Jesup, R. and Z. Sarker, Ed., "Congestion Control
Requirements for Interactive Real-Time Media", RFC 8836,
DOI 10.17487/RFC8836, January 2021,
<https://www.rfc-editor.org/info/rfc8836>.
[RFC9457] Nottingham, M., Wilde, E., and S. Dalal, "Problem Details
for HTTP APIs", RFC 9457, DOI 10.17487/RFC9457, July 2023,
<https://www.rfc-editor.org/info/rfc9457>.
[W3C.REC-webrtc-20250313]
Jennings, C., Ed., Castelli, F., Ed., Boström, H., Ed.,
and J. Bruaroey, Ed., "WebRTC: Real-Time Communication in
Browsers", W3C Recommendation, 13 March 2025,
<https://www.w3.org/TR/2025/REC-webrtc-20250313/>. Latest
version available at: <https://www.w3.org/TR/webrtc/>.
The authors wish to thank Lorenzo Miniero, Juliusz Chroboczek, Adam Roach, Nils Ohlmeier, Christer Holmberg, Cameron Elliott, Gustavo Garcia, Jonas Birme, Sandro Gauci, Christer Holmberg, and everyone else in the WebRTC community that have provided comments, feedback, text, and improvement proposals on the document and contributed early implementations of the spec.
著者は、Lorenzo Miniero、Juliusz Chroboczek、Adam Roach、Nils Ohlmeier、Christer Holmberg、Cameron Elliott、Gustavo Garcia、Jonas Birme、Sandro Gauci、Christer Holmberg、およびContrivation feed feed feed feed fired fired fired fired feed feed feed feed feed feed feed feed feed feed feed feart bearth in the webrtcコミュニティに感謝します。仕様。
Sergio Garcia Murillo
Millicast
Email: sergio.garcia.murillo@cosmosoftware.io
Alexandre Gouaillard
CoSMo Software
Email: alex.gouaillard@cosmosoftware.io