rfc9725.original.xml   rfc9725.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.18 (Ruby 3.0. <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
2) --> -ietf-wish-whip-16" number="9725" category="std" consensus="true" updates="8840,
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft 8842" obsoletes="" tocInclude="true" submissionType="IETF" sortRefs="true" symR
-ietf-wish-whip-16" category="std" consensus="true" updates="8842, 8840" tocIncl efs="true" version="3" xml:lang="en">
ude="true" sortRefs="true" symRefs="true" version="3">
<!-- xml2rfc v2v3 conversion 3.22.0 -->
<front> <front>
<title abbrev="whip">WebRTC-HTTP ingestion protocol (WHIP)</title> <title abbrev="whip">WebRTC-HTTP Ingestion Protocol (WHIP)</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-wish-whip-16"/> <seriesInfo name="RFC" value="9725"/>
<author initials="S." surname="Murillo" fullname="Sergio Garcia Murillo"> <author initials="S." surname="Garcia Murillo" fullname="Sergio Garcia Muril
lo">
<organization>Millicast</organization> <organization>Millicast</organization>
<address> <address>
<email>sergio.garcia.murillo@cosmosoftware.io</email> <email>sergio.garcia.murillo@cosmosoftware.io</email>
</address> </address>
</author> </author>
<author initials="A." surname="Gouaillard" fullname="Alexandre Gouaillard"> <author initials="A." surname="Gouaillard" fullname="Alexandre Gouaillard">
<organization>CoSMo Software</organization> <organization>CoSMo Software</organization>
<address> <address>
<email>alex.gouaillard@cosmosoftware.io</email> <email>alex.gouaillard@cosmosoftware.io</email>
</address> </address>
</author> </author>
<date year="2024" month="August" day="21"/> <date year="2025" month="March"/>
<area>ART</area> <area>WIT</area>
<workgroup>wish</workgroup> <workgroup>wish</workgroup>
<keyword>WebRTC</keyword>
<abstract> <abstract>
<?line 35?>
<t>This document describes a simple HTTP-based protocol that will allow WebRTC-b <t>This document describes a simple HTTP-based protocol that will allow
ased ingestion of content into streaming services and/or CDNs.</t> WebRTC-based ingestion of content into streaming services and/or
<t>This document updates RFC 8842 and RFC 8840.</t> Content Delivery Networks (CDNs).</t>
<t>This document updates RFCs 8840 and 8842.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<?line 41?>
<section anchor="introduction"> <section anchor="introduction">
<name>Introduction</name> <name>Introduction</name>
<t>The IETF RTCWEB working group standardized JSEP (<xref target="RFC9429" <t>The IETF RTCWEB Working Group standardized the JavaScript Session Estab
/>), a mechanism used to control the setup, management, and teardown of a multim lishment Protocol (JSEP) <xref
edia session. It also describes how to negotiate media flows using the Offer/Ans target="RFC9429"/>, a mechanism used to control the setup, management,
wer Model with the Session Description Protocol (SDP) <xref target="RFC3264"/> i and teardown of a multimedia session. It also describes how to negotiate
ncluding the formats for data sent over the wire (e.g., media types, codec param media flows using the offer/answer model with the Session Description
eters, and encryption). WebRTC intentionally does not specify a signaling transp Protocol (SDP) <xref target="RFC3264"/>, including the formats for data
ort protocol at application level.</t> sent over the wire (e.g., media types, codec parameters, and
<t>Unfortunately, the lack of a standardized signaling mechanism in WebRTC encryption). WebRTC intentionally does not specify a signaling transport
has been an obstacle to adoption as an ingestion protocol within the broadcast/ protocol at the application level.</t>
streaming industry, where a streamlined production pipeline is taken for granted
: plug in cables carrying raw media to hardware encoders, then push the encoded <t>Unfortunately, the lack of a standardized signaling mechanism in
media to any streaming service or Content Delivery Network (CDN) ingest using an WebRTC has been an obstacle to its adoption as an ingestion protocol
ingestion protocol.</t> within the broadcast and streaming industry, where a streamlined
<t>While WebRTC can be integrated with standard signaling protocols like S production pipeline is taken for granted. For example, cables carrying raw
IP <xref target="RFC3261"/> or XMPP <xref target="RFC6120"/>, they are not desig media to hardware encoders are plugged in and then the encoded media is
ned to be used in broadcasting/streaming services, and there is also no sign of pushed to any streaming service or Content Delivery Network (CDN) using an
adoption in that industry. RTSP <xref target="RFC7826"/>, which is based on RTP, ingestion protocol.
does not support the SDP offer/answer model <xref target="RFC3264"/> for negoti </t>
ating the characteristics of the media session.</t> <t>While WebRTC can be integrated with standard signaling protocols like
<t>This document proposes a simple protocol based on HTTP for supporting W SIP <xref target="RFC3261"/> or Extensible Messaging and Presence
ebRTC as media ingestion method which:</t> Protocol (XMPP) <xref target="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) <xref t
arget="RFC7826"/>, which is based
on RTP, does not support the SDP offer/answer model <xref
target="RFC3264"/> for negotiating the characteristics of the media
session.</t>
<t>This document proposes a simple protocol based on HTTP for supporting W
ebRTC as a media ingestion method that:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>Is easy to implement,</t> <t>is easy to implement,</t>
</li> </li>
<li> <li>
<t>Is as easy to use as popular IP-based broadcast protocols</t> <t>is as easy to use as popular IP-based broadcast protocols,</t>
</li> </li>
<li> <li>
<t>Is fully compliant with WebRTC and RTCWEB specs</t> <t>is fully compliant with WebRTC and RTCWEB specs,</t>
</li> </li>
<li> <li>
<t>Enables ingestion on both classical media platforms and WebRTC end- to-end platforms, achieving the lowest possible latency.</t> <t>enables ingestion on both classical media platforms and WebRTC end- to-end platforms (achieving the lowest possible latency),</t>
</li> </li>
<li> <li>
<t>Lowers the requirements on both hardware encoders and broadcasting services to support WebRTC.</t> <t>lowers the requirements on both hardware encoders and broadcasting services to support WebRTC, and</t>
</li> </li>
<li> <li>
<t>Is usable both in web browsers and in standalone encoders.</t> <t>is usable in both web browsers and standalone encoders.</t>
</li> </li>
</ul> </ul>
</section> </section>
<section anchor="terminology"> <section anchor="terminology">
<name>Terminology</name> <name>Terminology</name>
<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14 <t>
>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECO "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>
MMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", ",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be i "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
nterpreted as "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
only when, they be
appear in all capitals, as shown here.</t> interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/> <xref
<?line -18?> target="RFC8174"/> when, and only when, they appear in all capitals, as
shown here.
</t>
</section> </section>
<section anchor="overview"> <section anchor="overview">
<name>Overview</name> <name>Overview</name>
<t>The WebRTC-HTTP Ingest Protocol (WHIP) is designed to facilitate a one- <t>The WebRTC-HTTP Ingestion Protocol (WHIP) is designed to facilitate a
time exchange of Session Description Protocol (SDP) offers and answers using HTT one-time exchange of Session Description Protocol (SDP) offers and
P POST requests. This exchange is a fundamental step in establishing an Interact answers using HTTP POST requests. This exchange is a fundamental step in
ive Connectivity Establishment (ICE) and Datagram Transport Layer Security (DTLS establishing an Interactive Connectivity Establishment (ICE) and
) session between the WHIP client, which represents the encoder or media produce Datagram Transport Layer Security (DTLS) session between the WHIP
r, and the media server, the broadcasting ingestion endpoint.</t> client, which represents the encoder or media producer, and the media
<t>Upon successful establishment of the ICE/DTLS session, unidirectional m server, which is the broadcasting ingestion endpoint.</t>
edia data transmission commences from the WHIP client to the media server. It is <t>Upon successful establishment of the ICE/DTLS session, unidirectional
important to note that SDP renegotiations are not supported in WHIP, meaning th media data transmission commences from the WHIP client to the media
at no modifications to the "m=" sections can be made after the initial SDP offer server. It is important to note that SDP renegotiations are not
/answer exchange via HTTP POST is completed and only ICE related information can supported in WHIP. This means that no modifications to the "m=" sections
be updated via HTTP PATCH requests as defined in <xref target="ice-support"/>.< can be made after the initial SDP offer/answer exchange via HTTP POST is
/t> completed and that only ICE-related information can be updated via HTTP PA
<t>The following diagram illustrates the core operation of the WHIP protoc TCH
ol for initiating and terminating an ingest session:</t> requests as defined in <xref target="ice-support"/>.</t>
<t>The following diagram illustrates the core operation of WHIP
for initiating and terminating an ingest session:</t>
<figure anchor="whip-protocol-operation"> <figure anchor="whip-protocol-operation">
<name>WHIP session setup and teardown</name> <name>WHIP Session Setup and Teardown</name>
<artwork><![CDATA[ <artwork><![CDATA[
+-------------+ +---------------+ +--------------+ +---------------+
+-------------+ +---------------+ +--------------+ +---------------+ | WHIP client | | WHIP endpoint | | Media server | | WHIP session |
| WHIP client | | WHIP endpoint | | Media Server | | WHIP session | +--+----------+ +---------+-----+ +------+-------+ +--------|------+
+--+----------+ +---------+-----+ +------+-------+ +--------|------+ | | | |
| | | | | | | |
| | | | |HTTP POST (SDP offer) | | |
|HTTP POST (SDP Offer) | | | +------------------------>+ | |
+------------------------>+ | | |201 Created (SDP answer) | | |
|201 Created (SDP answer) | | | +<------------------------+ | |
+<------------------------+ | | | ICE/STUN REQUEST | |
| ICE REQUEST | | +--------------------------------------->+ |
+--------------------------------------->+ | | ICE/STUN RESPONSE | |
| ICE RESPONSE | | |<---------------------------------------+ |
|<---------------------------------------+ | | DTLS SETUP | |
| DTLS SETUP | | |<======================================>| |
|<======================================>| | | RTP/RTCP FLOW | |
| RTP/RTCP FLOW | | +<-------------------------------------->+ |
+<-------------------------------------->+ | | HTTP DELETE |
| HTTP DELETE | +---------------------------------------------------------->+
+---------------------------------------------------------->+ | 200 OK |
| 200 OK | <-----------------------------------------------------------x
<-----------------------------------------------------------x
]]></artwork> ]]></artwork>
</figure> </figure>
<t>The elements in <xref target="whip-protocol-operation"/> are described
as follows:</t> <t>The elements in <xref target="whip-protocol-operation"/> are
<ul spacing="normal"> described as follows:</t>
<li> <dl spacing="normal">
<t>WHIP client: This represents the WebRTC media encoder or producer, <dt>WHIP client:</dt><dd>This represents the WebRTC media encoder or
which functions as a client of the WHIP protocol by encoding and delivering medi producer, which functions as a client of WHIP by
a to a remote media server.</t> encoding and delivering media to a remote media server.</dd>
</li> <dt>WHIP endpoint:</dt><dd>This denotes the ingest server that
<li> receives the initial WHIP request.</dd>
<t>WHIP endpoint: This denotes the ingest server that receives the ini <dt>WHIP endpoint URL:</dt><dd>This refers to the URL of the WHIP endp
tial WHIP request.</t> oint responsible for creating the WHIP session.</dd>
</li> <dt>Media server:</dt><dd>This is the WebRTC media server or
<li> consumer responsible for establishing the media session with the
<t>WHIP endpoint URL: Refers to the URL of the WHIP endpoint responsib WHIP client and receiving the media content it produces.</dd>
le for creating the WHIP session.</t> <dt>WHIP session:</dt><dd>This indicates the server handling the
</li> allocated HTTP resource by the WHIP endpoint for an ongoing ingest
<li> session.</dd>
<t>Media server: This is the WebRTC media server or consumer responsib
le for establishing the media session with the WHIP client and receiving the med <dt>WHIP session URL:</dt><dd>This refers to the URL of the WHIP resou
ia content it produces.</t> rce
</li> allocated by the WHIP endpoint for a specific media session. To
<li> modify the session (e.g., ICE operations or session termination), the
<t>WHIP session: This indicates the server handling the allocated HTTP WHIP client can send requests to the WHIP session using this URL.</dd>
resource by the WHIP endpoint for an ongoing ingest session.</t> </dl>
</li>
<li> <t><xref target="whip-protocol-operation"/> illustrates the
<t>WHIP session URL: Refers to the URL of the WHIP resource allocated communication flow between a WHIP client, WHIP endpoint, media server,
by the WHIP endpoint for a specific media session. The WHIP client can send requ and WHIP session. This flow outlines the process of setting up and
ests to the WHIP session using this URL to modify the session, such as ICE opera tearing down an ingest session using WHIP, which involves
tions or termination.</t> negotiation, ICE for Network Address Translation (NAT) traversal, DTLS
</li> and the Secure Real-time Transport Protocol (SRTP) for security, and
</ul> RTP/RTCP for media transport:</t>
<t>The <xref target="whip-protocol-operation"/> illustrates the communicat
ion flow between a WHIP client, WHIP endpoint, media server, and WHIP session. T
his flow outlines the process of setting up and tearing down an ingestion sessio
n using the WHIP protocol, involving negotiation, ICE for Network Address Transl
ation (NAT) traversal, DTLS and Secure Real-time Transport Protocol (SRTP) for s
ecurity, and RTP/RTCP for media transport:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>The WHIP client initiates the communication by sending an HTTP
<t>WHIP client: Initiates the communication by sending an HTTP POST wi POST with an SDP offer to the WHIP endpoint.
th an SDP Offer to the WHIP endpoint.</t> </li>
</li> <li>The WHIP endpoint responds with a "201 Created" message containing
<li> an SDP answer.
<t>WHIP endpoint: Responds with a "201 Created" message containing an </li>
SDP answer.</t> <li>The WHIP client and media server establish ICE and DTLS
</li> sessions for NAT traversal and secure communication.
<li> </li>
<t>WHIP client and media server: Establish an ICE and DTLS sessions fo <li>RTP and RTCP flows are established for media transmission from the
r NAT traversal and secure communication.</t> WHIP client to the media server, secured by the SRTP profile.
</li> </li>
<li> <li>The WHIP client sends an HTTP DELETE to terminate the WHIP session
<t>RTP/RTCP Flow: Real-time Transport Protocol and Real-time Transport .
Control Protocol flows are established for media transmission from the WHIP cli </li>
ent to the media server, secured by the SRTP profile.</t> <li>The WHIP session responds with a "200 OK" to confirm the session
</li> termination.
<li> </li>
<t>WHIP client: Sends an HTTP DELETE to terminate the WHIP session.</t
>
</li>
<li>
<t>WHIP session: Responds with a "200 OK" to confirm the session termi
nation.</t>
</li>
</ul> </ul>
</section> </section>
<section anchor="protocol-operation"> <section anchor="protocol-operation">
<name>Protocol Operation</name> <name>Protocol Operation</name>
<section anchor="http-usage"> <section anchor="http-usage">
<name>HTTP usage</name> <name>HTTP Usage</name>
<t>Following <xref target="BCP56"/> guidelines, WHIP clients <bcp14>MUST
NOT</bcp14> match error codes returned by the WHIP endpoints and resources to a <t>Following the guidelines in <xref target="BCP56"/>, WHIP clients
specific error cause indicated in this specification. WHIP clients <bcp14>MUST< <bcp14>MUST NOT</bcp14> match error codes returned by the WHIP
/bcp14> be able to handle all applicable status codes gracefully falling back to endpoints and resources to a specific error cause indicated in this
the generic n00 semantics of a given status code on unknown error codes. WHIP e specification. WHIP clients <bcp14>MUST</bcp14> be able to handle all
ndpoints and resources could convey finer-grained error information by a problem applicable status codes by gracefully falling back to the generic n00
statement json object in the response message body of the failed request as per semantics of a given status code on unknown error codes. WHIP
<xref target="RFC9457"/>.</t> endpoints and resources could convey finer-grained error information
<t>The WHIP endpoints and sessions are origin servers as defined in <xre by a problem details json object in the response message body of the
f section="3.6." sectionFormat="of" target="RFC9110"/> handling the requests and failed request as per <xref target="RFC9457"/>.</t>
providing responses for the underlying HTTP resources. Those HTTP resources do
not have any representation defined in this specification, so the WHIP endpoints <t>The WHIP endpoints and sessions are origin servers as defined in
and sessions <bcp14>MUST</bcp14> return a 2XX sucessfull response with no conte <xref section="3.6" sectionFormat="of" target="RFC9110"/>; they handle t
nt when a GET request is received.</t> he
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
<bcp14>MUST</bcp14> return a 2xx successful response with no content
when a GET request is received.</t>
</section> </section>
<section anchor="ingest-session-set-up"> <section anchor="ingest-session-set-up">
<name>Ingest session set up</name> <name>Ingest Session Setup</name>
<t>In order to set up an ingestion session, the WHIP client <bcp14>MUST<
/bcp14> generate an SDP offer according to the JSEP rules for an initial offer a <t>In order to set up an ingest session, the WHIP client
s in <xref section="5.2.1" sectionFormat="of" target="RFC9429"/> and perform an <bcp14>MUST</bcp14> generate an SDP offer according to the JSEP rules
HTTP POST request as per <xref section="9.3.3" sectionFormat="of" target="RFC911 for an initial offer as per <xref section="5.2.1" sectionFormat="of"
0"/> to the configured WHIP endpoint URL.</t> target="RFC9429"/> and send an HTTP POST request as per <xref
<t>The HTTP POST request <bcp14>MUST</bcp14> have a content type of "app section="9.3.3" sectionFormat="of" target="RFC9110"/> to the
lication/sdp" and contain the SDP offer as the body. The WHIP endpoint <bcp14>MU configured WHIP endpoint URL.</t>
ST</bcp14> generate an SDP answer according to the JSEP rules for an initial ans
wer as in <xref section="5.3.1" sectionFormat="of" target="RFC9429"/> and return <t>The HTTP POST request <bcp14>MUST</bcp14> have a content type of
a "201 Created" response with a content type of "application/sdp", the SDP answ "application/sdp" and contain the SDP offer as the body. The WHIP
er as the body, and a Location header field pointing to the newly created WHIP s endpoint <bcp14>MUST</bcp14> generate an SDP answer according to the
ession. If the HTTP POST to the WHIP endpoint has a content type different than JSEP rules for an initial answer as per <xref section="5.3.1"
"application/sdp" or the SDP is malformed, the WHIP endpoint <bcp14>MUST</bcp14> sectionFormat="of" target="RFC9429"/> and return the following: a "201 C
reject the HTTP POST request with an appropiate 4XX error response.</t> reated"
<t>As the WHIP protocol only supports the ingestion use case with unidir response with a content type of "application/sdp", the SDP answer as
ectional media, the WHIP client <bcp14>SHOULD</bcp14> use "sendonly" attribute i the body, and a Location header field pointing to the newly created
n the SDP offer but <bcp14>MAY</bcp14> use the "sendrecv" attribute instead, "in WHIP session. If the HTTP POST to the WHIP endpoint has a content type
active" and "recvonly" attributes <bcp14>MUST NOT</bcp14> be used. The WHIP endp different than "application/sdp" or the SDP is malformed, the WHIP
oint <bcp14>MUST</bcp14> use "recvonly" attribute in the SDP answer.</t> endpoint <bcp14>MUST</bcp14> reject the HTTP POST request with an
<t>Following <xref target="sdp-exchange-example"/> is an example of an H appropriate 4xx error response.</t>
TTP POST sent from a WHIP client to a WHIP endpoint and the "201 Created" respon
se from the WHIP endpoint containing the Location header pointing to the newly c <t>As WHIP only supports the ingestion use case with
reated WHIP session:</t> unidirectional media, the WHIP client <bcp14>SHOULD</bcp14> use the
"sendonly" attribute in the SDP offer but <bcp14>MAY</bcp14> use the
"sendrecv" attribute instead; the "inactive" and "recvonly" attributes
<bcp14>MUST NOT</bcp14> be used. The WHIP endpoint <bcp14>MUST</bcp14>
use the "recvonly" attribute in the SDP answer.</t>
<t><xref target="sdp-exchange-example"/> 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.</t>
<figure anchor="sdp-exchange-example"> <figure anchor="sdp-exchange-example">
<name>Example of SDP offer/answer exchange done via an HTTP POST</name <name>Example of the SDP Offer/Answer Exchange Done via an HTTP POST</
> name>
<artwork><![CDATA[ <sourcecode type="http-message"><![CDATA[
POST /whip/endpoint HTTP/1.1 POST /whip/endpoint HTTP/1.1
Host: whip.example.com Host: whip.example.com
Content-Type: application/sdp Content-Type: application/sdp
Content-Length: 1101 Content-Length: 1101
v=0 v=0
o=- 5228595038118931041 2 IN IP4 127.0.0.1 o=- 5228595038118931041 2 IN IP4 127.0.0.1
s=- s=-
t=0 0 t=0 0
a=group:BUNDLE 0 1 a=group:BUNDLE 0 1
a=extmap-allow-mixed a=extmap-allow-mixed
a=ice-options:trickle ice2 a=ice-options:trickle ice2
m=audio 9 UDP/TLS/RTP/SAVPF 111 m=audio 9 UDP/TLS/RTP/SAVPF 111
c=IN IP4 0.0.0.0 c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0 a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:EsAw a=ice-ufrag:EsAw
a=ice-pwd:bP+XJMM09aR8AiX1jdukzR6Y 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:7 a=fingerprint:sha-256 DA:7B:57:DC:28:CE:04:4F:31:79:85:C4:31:67:EB:
7:2A:0D:24:AE:ED:AD:30:BC:BD:F1:9C:02 27:58:29:ED:77:2A:0D:24:AE:ED:AD:30:BC:BD:F1:9C:02
a=setup:actpass a=setup:actpass
a=mid:0 a=mid:0
a=extmap:4 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:4 urn:ietf:params:rtp-hdrext:sdes:mid
a=sendonly a=sendonly
a=msid:d46fb922-d52a-4e9c-aa87-444eadc1521b ce326ecf-a081-453a-8f9f-0605d5ef4128 a=msid:d46fb922-d52a-4e9c-aa87-444eadc1521b ce326ecf-a081-453a-8f9f-
0605d5ef4128
a=rtcp-mux a=rtcp-mux
a=rtcp-mux-only a=rtcp-mux-only
a=rtpmap:111 opus/48000/2 a=rtpmap:111 opus/48000/2
a=fmtp:111 minptime=10;useinbandfec=1 a=fmtp:111 minptime=10;useinbandfec=1
m=video 0 UDP/TLS/RTP/SAVPF 96 97 m=video 0 UDP/TLS/RTP/SAVPF 96 97
a=mid:1 a=mid:1
a=bundle-only a=bundle-only
a=extmap:4 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:4 urn:ietf:params:rtp-hdrext:sdes:mid
a=extmap:10 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id 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=extmap:11 urn:ietf:params:rtp-hdrext:sdes:repaired-rtp-stream-id
a=sendonly a=sendonly
a=msid:d46fb922-d52a-4e9c-aa87-444eadc1521b 3956b460-40f4-4d05-acef-03abcdd8c6fd a=msid:d46fb922-d52a-4e9c-aa87-444eadc1521b 3956b460-40f4-4d05-acef-
03abcdd8c6fd
a=rtpmap:96 VP8/90000 a=rtpmap:96 VP8/90000
a=rtcp-fb:96 ccm fir a=rtcp-fb:96 ccm fir
a=rtcp-fb:96 nack a=rtcp-fb:96 nack
a=rtcp-fb:96 nack pli a=rtcp-fb:96 nack pli
a=rtpmap:97 rtx/90000 a=rtpmap:97 rtx/90000
a=fmtp:97 apt=96 a=fmtp:97 apt=96
HTTP/1.1 201 Created HTTP/1.1 201 Created
ETag: "xyzzy" ETag: "xyzzy"
Content-Type: application/sdp Content-Type: application/sdp
skipping to change at line 231 skipping to change at line 324
t=0 0 t=0 0
a=group:BUNDLE 0 1 a=group:BUNDLE 0 1
a=extmap-allow-mixed a=extmap-allow-mixed
a=ice-lite a=ice-lite
a=ice-options:trickle ice2 a=ice-options:trickle ice2
m=audio 9 UDP/TLS/RTP/SAVPF 111 m=audio 9 UDP/TLS/RTP/SAVPF 111
c=IN IP4 0.0.0.0 c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0 a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:38sdf4fdsf54 a=ice-ufrag:38sdf4fdsf54
a=ice-pwd:2e13dde17c1cb009202f627fab90cbec358d766d049c9697 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:4 a=fingerprint:sha-256 F7:EB:F3:3E:AC:D2:EA:A7:C1:EC:79:D9:B3:8A:35:
6:D9:2D:CC:D0:BC:81:9F:67:EF:34:2E:BD 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=candidate:1 1 UDP 2130706431 198.51.100.1 39132 typ host
a=setup:passive a=setup:passive
a=mid:0 a=mid:0
a=extmap:4 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:4 urn:ietf:params:rtp-hdrext:sdes:mid
a=recvonly a=recvonly
a=rtcp-mux a=rtcp-mux
a=rtcp-mux-only a=rtcp-mux-only
a=rtpmap:111 opus/48000/2 a=rtpmap:111 opus/48000/2
a=fmtp:111 minptime=10;useinbandfec=1 a=fmtp:111 minptime=10;useinbandfec=1
m=video 0 UDP/TLS/RTP/SAVPF 96 97 m=video 0 UDP/TLS/RTP/SAVPF 96 97
skipping to change at line 255 skipping to change at line 349
a=extmap:4 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:4 urn:ietf:params:rtp-hdrext:sdes:mid
a=extmap:10 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id 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=extmap:11 urn:ietf:params:rtp-hdrext:sdes:repaired-rtp-stream-id
a=recvonly a=recvonly
a=rtpmap:96 VP8/90000 a=rtpmap:96 VP8/90000
a=rtcp-fb:96 ccm fir a=rtcp-fb:96 ccm fir
a=rtcp-fb:96 nack a=rtcp-fb:96 nack
a=rtcp-fb:96 nack pli a=rtcp-fb:96 nack pli
a=rtpmap:97 rtx/90000 a=rtpmap:97 rtx/90000
a=fmtp:97 apt=96 a=fmtp:97 apt=96
]]></artwork> ]]></sourcecode>
</figure> </figure>
<t>Once a session is set up, consent freshness as per <xref target="RFC7
675"/> <bcp14>SHALL</bcp14> be used to detect non-graceful disconnection by full <t>Once a session is set up, consent freshness as per <xref
ICE implementations and DTLS teardown for session termination by either side.</ target="RFC7675"/> <bcp14>SHALL</bcp14> be used to detect non-graceful
t> disconnection by full ICE implementations and DTLS teardown for
<t>To explicitly terminate a WHIP session, the WHIP client <bcp14>MUST</ session termination by either side.</t>
bcp14> perform an HTTP DELETE request to the WHIP session URL returned in the Lo
cation header field of the initial HTTP POST. Upon receiving the HTTP DELETE req <t>To explicitly terminate a WHIP session, the WHIP client
uest, the WHIP session will be removed and the resources freed on the media serv <bcp14>MUST</bcp14> send an HTTP DELETE request to the WHIP session
er, terminating the ICE and DTLS sessions.</t> URL returned in the Location header field of the initial HTTP
<t>A media server terminating a session <bcp14>MUST</bcp14> follow the p POST. Upon receiving the HTTP DELETE request, the WHIP session will be
rocedures in <xref section="5.2" sectionFormat="of" target="RFC7675"/> for imme removed and the resources freed on the media server, terminating the
diate revocation of consent.</t> ICE and DTLS sessions.</t>
<t>The WHIP endpoints <bcp14>MUST</bcp14> support OPTIONS requests for C
ross-Origin Resource Sharing (CORS) as defined in <xref target="FETCH"/>. The "2 <t>A media server terminating a session <bcp14>MUST</bcp14> follow the
00 OK" response to any OPTIONS request <bcp14>SHOULD</bcp14> include an "Accept- procedures in <xref section="5.2" sectionFormat="of"
Post" header with a media type value of "application/sdp" as per <xref target="W target="RFC7675"/> for immediate revocation of consent.</t>
3C.REC-ldp-20150226"/>.</t>
<t>The WHIP endpoints <bcp14>MUST</bcp14> support OPTIONS requests for
Cross-Origin Resource Sharing (CORS) as defined in <xref
target="FETCH"/>. The "200 OK" response to any OPTIONS request
<bcp14>SHOULD</bcp14> include an Accept-Post header with a media
type value of "application/sdp" as per <xref
target="W3C.REC-ldp-20150226"/>.</t>
</section> </section>
<section anchor="ice-support"> <section anchor="ice-support">
<name>ICE support</name> <name>ICE Support</name>
<t>ICE <xref target="RFC8845"/> is a protocol addressing the complexitie
s of NAT traversal, commonly encountered in Internet communication. NATs hinder <t>ICE <xref target="RFC8445"/> is a protocol that addresses the
direct communication between devices on different local networks, posing challen complexities of NAT traversal commonly encountered in Internet
ges for real-time applications. ICE facilitates seamless connectivity by employi communication. NATs hinder direct communication between devices on
ng techniques to discover and negotiate efficient communication paths.</t> different local networks, posing challenges for real-time
<t>Trickle ICE <xref target="RFC8838"/> optimizes the connectivity proce applications. ICE facilitates seamless connectivity by employing
ss by incrementally sharing potential communication paths, reducing latency, and techniques to discover and negotiate efficient communication
facilitating quicker establishment.</t> paths.</t>
<t>ICE Restarts are crucial for maintaining connectivity in dynamic netw
ork conditions or disruptions, allowing devices to re-establish communication pa <t>Trickle ICE <xref target="RFC8838"/> optimizes the connectivity
ths without complete renegotiation. This ensures minimal latency and reliable re process by incrementally sharing potential communication paths,
al-time communication.</t> reducing latency, and facilitating quicker establishment.</t>
<t>Trickle ICE and ICE restart support are <bcp14>RECOMMENDED</bcp14> fo
r both WHIP sessions and clients.</t> <t>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.</t>
<t>Trickle ICE and ICE restart support are <bcp14>RECOMMENDED</bcp14>
for both WHIP sessions and clients.</t>
<section anchor="http-patch-usage"> <section anchor="http-patch-usage">
<name>HTTP PATCH request usage</name> <name>HTTP PATCH Request Usage</name>
<t>The WHIP client <bcp14>MAY</bcp14> perform trickle ICE or ICE resta
rts by sending an HTTP PATCH request as per <xref target="RFC5789"/> to the WHIP <t>The WHIP client <bcp14>MAY</bcp14> perform Trickle ICE or ICE
session URL, with a body containing an SDP fragment with media type "applicatio restarts by sending an HTTP PATCH request as per <xref
n/trickle-ice-sdpfrag" as specified in <xref target="RFC8840"/> carrying the rel target="RFC5789"/> to the WHIP session URL. This HTTP PATCH request <b
evant ICE information. If the HTTP PATCH to the WHIP session has a content type cp14>MUST</bcp14> contain a body with
different than "application/trickle-ice-sdpfrag" or the SDP fragment is malforme an SDP fragment with media type "application/trickle-ice-sdpfrag" as
d, the WHIP session <bcp14>MUST</bcp14> reject the HTTP PATCH with an appropiate specified in <xref target="RFC8840"/>, which carries the relevant ICE
4XX error response.</t> information. If the HTTP PATCH request sent to the WHIP session URL ha
<t>If the WHIP session supports either Trickle ICE or ICE restarts, bu s a content
t not both, it <bcp14>MUST</bcp14> return a "422 Unprocessable Content" error re type different than "application/trickle-ice-sdpfrag" or the SDP
sponse for the HTTP PATCH requests that are not supported as per <xref section=" fragment is malformed, the WHIP session <bcp14>MUST</bcp14> reject
15.5.21" sectionFormat="of" target="RFC9110"/>.</t> the HTTP PATCH with an appropriate 4xx error response.</t>
<t>The WHIP client <bcp14>MAY</bcp14> send overlapping HTTP PATCH requ
ests to one WHIP session. Consequently, as those HTTP PATCH requests may be rece <t>If the WHIP session supports either Trickle ICE or ICE restarts,
ived out-of-order by the WHIP session, if WHIP session supports ICE restarts, it but not both, it <bcp14>MUST</bcp14> return a "422 Unprocessable
<bcp14>MUST</bcp14> generate a unique strong entity-tag identifying the ICE ses Content" error response for the HTTP PATCH requests that are not
sion as per <xref section="8.8.3" sectionFormat="of" target="RFC9110"/>, being < supported as per <xref section="15.5.21" sectionFormat="of"
bcp14>OPTIONAL</bcp14> otherwise. The initial value of the entity-tag identifyin target="RFC9110"/>.</t>
g the initial ICE session <bcp14>MUST</bcp14> be returned in an ETag header fiel
d in the "201 Created" response to the initial POST request to the WHIP endpoint <t>The WHIP client <bcp14>MAY</bcp14> send overlapping HTTP PATCH
.</t> requests to one WHIP session.
<t>WHIP clients <bcp14>SHOULD NOT</bcp14> use entity-tag validation wh
en matching a specific ICE session is not required, such as for example when ini Consequently, those HTTP PATCH requests may be received out of order
tiating a DELETE request to terminate a session. WHIP sessions <bcp14>MUST</bcp1 by the WHIP session. Thus, if the WHIP session supports ICE
4> ignore any entity-tag value sent by the WHIP client when ICE session matching restarts, it <bcp14>MUST</bcp14> generate a unique strong entity-tag
is not required, as in the HTTP DELETE request.</t> identifying the ICE session as per <xref section="8.8.3"
<t>Missing or outdated ETags in the PATCH requests from WHIP clients w sectionFormat="of" target="RFC9110"/>.
ill be answered by WHIP sessions as per <xref section="13.1.1" sectionFormat="of The initial value of the
" target="RFC9110"/> and <xref section="3" sectionFormat="of" target="RFC6585"/> entity-tag identifying the initial ICE session <bcp14>MUST</bcp14>
, with a "428 Precondition Required" response for a missing entity tag, and a "4 be returned in an ETag header field in the "201 Created" response to
12 Precondition Failed" response for a non-matching entity tag.</t> the initial POST request to the WHIP endpoint.</t>
<t>WHIP clients <bcp14>SHOULD NOT</bcp14> use entity-tag validation
when matching a specific ICE session is not required, for example, whe
n
initiating a DELETE request to terminate a session.
WHIP sessions <bcp14>MUST</bcp14> ignore any entity-tag
value sent by the WHIP client when ICE session matching is not
required, as in the HTTP DELETE request.</t>
<t>Missing or outdated ETags in the PATCH requests from WHIP clients
will be answered by WHIP sessions as per <xref section="13.1.1"
sectionFormat="of" target="RFC9110"/> and <xref section="3"
sectionFormat="of" target="RFC6585"/>, with a "428 Precondition
Required" response for a missing entity-tag and a "412 Precondition
Failed" response for a non-matching entity-tag.</t>
</section> </section>
<section anchor="trickle-ice"> <section anchor="trickle-ice">
<name>Trickle ICE</name> <name>Trickle ICE</name>
<t>Depending on the Trickle ICE support on the WHIP client, the initia
l offer by the WHIP client <bcp14>MAY</bcp14> be sent after the full ICE gatheri <t>Depending on the Trickle ICE support on the WHIP client, the
ng is complete with the full list of ICE candidates, or it <bcp14>MAY</bcp14> on initial offer by the WHIP client <bcp14>MAY</bcp14> be sent after
ly contain local candidates (or even an empty list of candidates) as per <xref t the full ICE gathering is complete with the full list of ICE
arget="RFC8845"/>. For the purpose of reducing setup times, when using Trickle I candidates, or it <bcp14>MAY</bcp14> only contain local candidates
CE the WHIP client <bcp14>SHOULD</bcp14> send the SDP offer as soon as possible, (or even an empty list of candidates) as per <xref
containing either locally gathered ICE candidates or an empty list of candidate target="RFC8445"/>. For the purpose of reducing setup times, when
s.</t> using Trickle ICE, the WHIP client <bcp14>SHOULD</bcp14> send the SDP
<t>In order to simplify the protocol, the WHIP session cannot signal a offer (containing either locally gathered ICE
dditional ICE candidates to the WHIP client after the SDP answer has been sent. candidates or an empty list of candidates) as soon as possible.</t>
The WHIP endpoint <bcp14>SHALL</bcp14> gather all the ICE candidates for the med <t>In order to simplify the protocol, the WHIP session cannot signal
ia server before responding to the client request and the SDP answer <bcp14>SHAL additional ICE candidates to the WHIP client after the SDP answer
L</bcp14> contain the full list of ICE candidates of the media server.</t> has been sent. The WHIP endpoint <bcp14>SHALL</bcp14> gather all the
<t>As the WHIP client needs to know the WHIP session URL associated wi ICE candidates for the media server before responding to the client
th the ICE session in order to send a PATCH request containing new ICE candidate request, and the SDP answer <bcp14>SHALL</bcp14> contain the full
s, it <bcp14>MUST</bcp14> wait and buffer any gathered candidates until the "201 list of ICE candidates of the media server.</t>
Created" HTTP response to the initial POST request is received.
In order to lower the HTTP traffic and processing time required the WHIP client <t>As the WHIP client needs to know the WHIP session URL associated
<bcp14>SHOULD</bcp14> send a single aggregated HTTP PATCH request with all the b with the ICE session in order to send a PATCH request containing new
uffered ICE candidates once the response is received. ICE candidates, it <bcp14>MUST</bcp14> wait and buffer any gathered
Additionally, if ICE restarts are supported by the WHIP session, the WHIP client candidates until the "201 Created" HTTP response to the initial POST
needs to know the entity-tag associated with the ICE session in order to send a request is received. In order to reduce the HTTP traffic and
PATCH request containing new ICE candidates, so it <bcp14>MUST</bcp14> also wai processing time required, the WHIP client <bcp14>SHOULD</bcp14> send
t and buffer any gathered candidates until it receives the HTTP response with th a single aggregated HTTP PATCH request with all the buffered ICE
e new entity-tag value to the last PATCH request performing an ICE restart.</t> candidates once the response is received. Additionally, if ICE
<t>WHIP clients generating the HTTP PATCH body with the SDP fragment a restarts are supported by the WHIP session, the WHIP client needs to
nd its subsequent processing by WHIP sessions <bcp14>MUST</bcp14> follow to the know the entity-tag associated with the ICE session in order to send
guidelines defined in <xref section="4.4" sectionFormat="of" target="RFC8840"/> a PATCH request containing new ICE candidates; thus, it
with the following considerations:</t> <bcp14>MUST</bcp14> 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.</t>
<t>WHIP clients generating the HTTP PATCH body with the SDP fragment
and its subsequent processing by WHIP sessions <bcp14>MUST</bcp14>
follow the guidelines defined in <xref section="4.4"
sectionFormat="of" target="RFC8840"/> with the following
considerations:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>As per <xref target="RFC9429"/>, only m-sections not marked as <t>As per <xref target="RFC9429"/>, only "m=" sections not marked
bundle-only can gather ICE candidates, so given that the "max-bundle" policy is as bundle-only can gather ICE candidates, so given that the
being used, the SDP fragment will contain only the offerer-tagged m-line of the "max-bundle" policy is being used, the SDP fragment will contain
bundle group.</t> only the offerer-tagged "m=" line of the bundle group.</t>
</li> </li>
<li> <li>
<t>The WHIP client <bcp14>MAY</bcp14> exclude ICE candidates from <t>The WHIP client <bcp14>MAY</bcp14> exclude ICE candidates
the HTTP PATCH body if they have already been confirmed by the WHIP session with from the HTTP PATCH body if they have already been confirmed by
a successful HTTP response to a previous HTTP PATCH request.</t> the WHIP session with a successful HTTP response to a previous
HTTP PATCH request.</t>
</li> </li>
</ul> </ul>
<t>WHIP sessions and clients that support Trickle ICE <bcp14>MUST</bcp <t>WHIP sessions and clients that support Trickle ICE
14> make use of entity-tags and conditional requests as explained in <xref targe <bcp14>MUST</bcp14> make use of entity-tags and conditional requests
t="http-patch-usage"/>.</t> as explained in <xref target="http-patch-usage"/>.</t>
<t>When a WHIP session receives a PATCH request that adds new ICE cand <t>When a WHIP session receives a PATCH request that adds new ICE
idates without performing an ICE restart, it <bcp14>MUST</bcp14> return a "204 N candidates without performing an ICE restart, it <bcp14>MUST</bcp14>
o Content" response without a body and <bcp14>MUST NOT</bcp14> include an ETag h return a "204 No Content" response without a body and <bcp14>MUST
eader in the response. If the WHIP session does not support a candidate transpor NOT</bcp14> include an ETag header in the response. If the WHIP
t or is not able to resolve the connection address, it <bcp14>MUST</bcp14> silen session does not support a candidate transport or is not able to
tly discard the candidate and continue processing the rest of the request normal resolve the connection address, it <bcp14>MUST</bcp14> silently
ly.</t> discard the candidate and continue processing the rest of the
request normally.</t>
<t><xref target="trickle-ice-example"/> 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.</t>
<figure anchor="trickle-ice-example"> <figure anchor="trickle-ice-example">
<name>Example of a Trickle ICE request and response</name> <name>Example of a Trickle ICE Request and Response</name>
<artwork><![CDATA[ <sourcecode type="http-message"><![CDATA[
PATCH /session/id HTTP/1.1 PATCH /session/id HTTP/1.1
Host: whip.example.com Host: whip.example.com
If-Match: "xyzzy" If-Match: "xyzzy"
Content-Type: application/trickle-ice-sdpfrag Content-Type: application/trickle-ice-sdpfrag
Content-Length: 576 Content-Length: 576
a=group:BUNDLE 0 1 a=group:BUNDLE 0 1
m=audio 9 UDP/TLS/RTP/SAVPF 111 m=audio 9 UDP/TLS/RTP/SAVPF 111
a=mid:0 a=mid:0
a=ice-ufrag:EsAw a=ice-ufrag:EsAw
a=ice-pwd:P2uYro0UCOQ4zxjKXaWCBui1 a=ice-pwd:P2uYro0UCOQ4zxjKXaWCBui1
a=candidate:1387637174 1 udp 2122260223 192.0.2.1 61764 typ host generation 0 uf a=candidate:1387637174 1 udp 2122260223 192.0.2.1 61764 typ host
rag EsAw network-id 1 generation 0 ufrag EsAw network-id 1
a=candidate:3471623853 1 udp 2122194687 198.51.100.2 61765 typ host generation 0 a=candidate:3471623853 1 udp 2122194687 198.51.100.2 61765 typ host
ufrag EsAw network-id 2 generation 0 ufrag EsAw network-id 2
a=candidate:473322822 1 tcp 1518280447 192.0.2.1 9 typ host tcptype active gener a=candidate:473322822 1 tcp 1518280447 192.0.2.1 9 typ host tcptype
ation 0 ufrag EsAw network-id 1 active generation 0 ufrag EsAw network-id 1
a=candidate:2154773085 1 tcp 1518214911 198.51.100.2 9 typ host tcptype active g a=candidate:2154773085 1 tcp 1518214911 198.51.100.2 9 typ host
eneration 0 ufrag EsAw network-id 2 tcptype active generation 0 ufrag EsAw network-id 2
a=end-of-candidates a=end-of-candidates
HTTP/1.1 204 No Content HTTP/1.1 204 No Content
]]></artwork> ]]></sourcecode>
</figure> </figure>
<t><xref target="trickle-ice-example"/> shows an example of the Trickl e ICE procedure where the WHIP client sends a PATCH request with updated ICE can didate information and receives a successful response from the WHIP session.</t>
</section> </section>
<section anchor="ice-restarts"> <section anchor="ice-restarts">
<name>ICE Restarts</name> <name>ICE Restarts</name>
<t>As defined in <xref target="RFC8839"/>, when an ICE restart occurs, <t>As defined in <xref target="RFC8839"/>, when an ICE restart
a new SDP offer/answer exchange is triggered. However, as WHIP does not support occurs, a new SDP offer/answer exchange is triggered. However, as
renegotiation of non-ICE related SDP information, a WHIP client will not send a WHIP does not support renegotiation of non-ICE-related SDP
new offer when an ICE restart occurs. Instead, the WHIP client and WHIP session information, a WHIP client will not send a new offer when an ICE
will only exchange the relevant ICE information via an HTTP PATCH request as de restart occurs. Instead, the WHIP client and WHIP session will only
fined in <xref target="http-patch-usage"/> and <bcp14>MUST</bcp14> assume that t exchange the relevant ICE information via an HTTP PATCH request as
he previously negotiated non-ICE related SDP information still apply after the I defined in <xref target="http-patch-usage"/> and <bcp14>MUST</bcp14>
CE restart.</t> assume that the previously negotiated non-ICE-related SDP
<t>When performing an ICE restart, the WHIP client <bcp14>MUST</bcp14> information still applies after the ICE restart.</t>
include the updated "ice-pwd" and "ice-ufrag" in the SDP fragment of the HTTP P <t>When performing an ICE restart, the WHIP client
ATCH request body as well as the new set of gathered ICE candidates as defined i <bcp14>MUST</bcp14> include the updated "ice-pwd" and "ice-ufrag" in
n <xref target="RFC8840"/>. the SDP fragment of the HTTP PATCH request body as well as the new
Similar what is defined in <xref target="trickle-ice"/>, as per <xref target="RF set of gathered ICE candidates as defined in <xref
C9429"/> only m-sections not marked as bundle-only can gather ICE candidates, so target="RFC8840"/>. Similar to what is defined in <xref
given that the "max-bundle" policy is being used, the SDP fragment will contain target="trickle-ice"/>, as per <xref target="RFC9429"/>, only
only the offerer-tagged m-line of the bundle group. "m=" sections not marked as bundle-only can gather ICE candidates, so
A WHIP client sending a PATCH request for performing ICE restart <bcp14>MUST</bc given that the "max-bundle" policy is being used, the SDP fragment
p14> contain an "If-Match" header field with a field-value "*" as per <xref sect will contain only the offerer-tagged "m=" line of the bundle group. A
ion="13.1.1" sectionFormat="of" target="RFC9110"/>.</t> WHIP client sending a PATCH request for performing ICE restart
<t><xref target="RFC8840"/> states that an agent <bcp14>MUST</bcp14> d <bcp14>MUST</bcp14> contain an If-Match header field with a
iscard any received requests containing "ice-pwd" and "ice-ufrag" attributes tha field-value of "*" as per <xref section="13.1.1" sectionFormat="of"
t do not match those of the current ICE Negotiation Session, however, any WHIP s target="RFC9110"/>.</t>
ession receiving an updated "ice-pwd" and "ice-ufrag" attributes <bcp14>MUST</bc <t><xref target="RFC8840"/> states that an agent <bcp14>MUST</bcp14>
p14> consider the request as performing an ICE restart instead and, if supported discard any received requests containing "ice-pwd" and "ice-ufrag"
, <bcp14>SHALL</bcp14> return a "200 OK" with an "application/trickle-ice-sdpfra attributes that do not match those of the current ICE Negotiation
g" body containing the new ICE username fragment and password and a new set of I Session. However, any WHIP session receiving updated "ice-pwd"
CE candidates for the WHIP session. Also, the "200 OK" response for a successful and "ice-ufrag" attributes <bcp14>MUST</bcp14> consider the request
ICE restart <bcp14>MUST</bcp14> contain the new entity-tag corresponding to the as performing an ICE restart instead and, if supported,
new ICE session in an ETag response header field and <bcp14>MAY</bcp14> contain <bcp14>SHALL</bcp14> return a "200 OK" with an
a new set of ICE candidates for the media server.</t> "application/trickle-ice-sdpfrag" body containing the new ICE
<t>As defined in <xref section="4.4.1.1.1" sectionFormat="of" target=" username fragment and password and a new set of ICE candidates for
RFC8839"/> the set of candidates after an ICE restart may include some, none, or the WHIP session. Also, the "200 OK" response for a successful ICE
all of the previous candidates for that data stream and may include a totally n restart <bcp14>MUST</bcp14> contain the new entity-tag corresponding
ew set of candidates. So after performing a successful ICE restart, both the WHI to the new ICE session in an ETag response header field and
P client and the WHIP session <bcp14>MUST</bcp14> replace the previous set of re <bcp14>MAY</bcp14> contain a new set of ICE candidates for the media
mote candidates with the new set exchanged in the HTTP PATCH request and respons server.</t>
e, discarding any remote ICE candidate not present on the new set. Both the WHIP <t>As defined in <xref section="4.4.1.1.1" sectionFormat="of"
client and the WHIP session <bcp14>MUST</bcp14> ensure that the HTTP PATCH requ target="RFC8839"/>, the set of candidates after an ICE restart may
ests and response bodies include the same 'ice-options,' 'ice-pacing,' and 'ice- include some, none, or all of the previous candidates for that data
lite' attributes as those used in the SDP offer or answer.</t> stream and may include a totally new set of candidates. Therefore, aft
<t>If the ICE restart request cannot be satisfied by the WHIP session, er
the resource <bcp14>MUST</bcp14> return an appropriate HTTP error code and <bcp performing a successful ICE restart, both the WHIP client and the
14>MUST NOT</bcp14> terminate the session immediately and keep the existing ICE WHIP session <bcp14>MUST</bcp14> replace the previous set of remote
session. The WHIP client <bcp14>MAY</bcp14> retry performing a new ICE restart o candidates with the new set exchanged in the HTTP PATCH request and
r terminate the session by issuing an HTTP DELETE request instead. In any case, response, discarding any remote ICE candidate not present on the new
the session <bcp14>MUST</bcp14> be terminated if the ICE consent expires as a co set. Both the WHIP client and the WHIP session <bcp14>MUST</bcp14>
nsequence of the failed ICE restart as per <xref section="5.1" sectionFormat="of ensure that the HTTP PATCH request and response bodies include the
" target="RFC7675"/>.</t> same "ice-options," "ice-pacing," and "ice-lite" attributes as those
<t>In case of unstable network conditions, the ICE restart HTTP PATCH used in the SDP offer or answer.</t>
requests and responses might be received out of order. In order to mitigate this <t>If the ICE restart request cannot be satisfied by the WHIP
scenario, when the client performs an ICE restart, it <bcp14>MUST</bcp14> disca session, the resource <bcp14>MUST</bcp14> return an appropriate HTTP
rd any previous ICE username and passwords fragments and ignore any further HTTP error code and <bcp14>MUST NOT</bcp14> terminate the session
PATCH response received from a pending HTTP PATCH request. WHIP clients <bcp14> immediately and keep the existing ICE session. The WHIP client
MUST</bcp14> apply only the ICE information received in the response to the last <bcp14>MAY</bcp14> retry performing a new ICE restart or terminate
sent request. If there is a mismatch between the ICE information at the WHIP cl the session by issuing an HTTP DELETE request instead. In any case,
ient and at the WHIP session (because of an out-of-order request), the STUN requ the session <bcp14>MUST</bcp14> be terminated if the ICE consent
ests will contain invalid ICE information and will be dropped by the receiving s expires as a consequence of the failed ICE restart as per <xref
ide. If this situation is detected by the WHIP client, it <bcp14>MUST</bcp14> se section="5.1" sectionFormat="of" target="RFC7675"/>.</t>
nd a new ICE restart request to the server.</t> <t>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 <bcp14>MUST</bcp14> discard any previous ICE username frag
ment
and password and ignore any further HTTP PATCH response
received from a pending HTTP PATCH request. WHIP clients
<bcp14>MUST</bcp14> 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 <bcp14>MUST</bcp14>
send a new ICE restart request to the server.</t>
<t><xref target="trickle-restart-example"/> 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.</t>
<figure anchor="trickle-restart-example"> <figure anchor="trickle-restart-example">
<name>Example of an ICE restart request and response</name> <name>Example of an ICE Restart Request and Response</name>
<artwork><![CDATA[ <sourcecode type="http-message"><![CDATA[
PATCH /session/id HTTP/1.1 PATCH /session/id HTTP/1.1
Host: whip.example.com Host: whip.example.com
If-Match: "*" If-Match: "*"
Content-Type: application/trickle-ice-sdpfrag Content-Type: application/trickle-ice-sdpfrag
Content-Length: 82 Content-Length: 82
a=ice-options:trickle ice2 a=ice-options:trickle ice2
a=group:BUNDLE 0 1 a=group:BUNDLE 0 1
m=audio 9 UDP/TLS/RTP/SAVPF 111 m=audio 9 UDP/TLS/RTP/SAVPF 111
a=mid:0 a=mid:0
a=ice-ufrag:ysXw a=ice-ufrag:ysXw
a=ice-pwd:vw5LmwG4y/e6dPP/zAP9Gp5k a=ice-pwd:vw5LmwG4y/e6dPP/zAP9Gp5k
a=candidate:1387637174 1 udp 2122260223 192.0.2.1 61764 typ host generation 0 uf a=candidate:1387637174 1 udp 2122260223 192.0.2.1 61764 typ host
rag EsAw network-id 1 generation 0 ufrag EsAw network-id 1
a=candidate:3471623853 1 udp 2122194687 198.51.100.2 61765 typ host generation 0 a=candidate:3471623853 1 udp 2122194687 198.51.100.2 61765 typ host
ufrag EsAw network-id 2 generation 0 ufrag EsAw network-id 2
a=candidate:473322822 1 tcp 1518280447 192.0.2.1 9 typ host tcptype active gener a=candidate:473322822 1 tcp 1518280447 192.0.2.1 9 typ host tcptype
ation 0 ufrag EsAw network-id 1 active generation 0 ufrag EsAw network-id 1
a=candidate:2154773085 1 tcp 1518214911 198.51.100.2 9 typ host tcptype active g a=candidate:2154773085 1 tcp 1518214911 198.51.100.2 9 typ host
eneration 0 ufrag EsAw network-id 2 tcptype active generation 0 ufrag EsAw network-id 2
HTTP/1.1 200 OK HTTP/1.1 200 OK
ETag: "abccd" ETag: "abccd"
Content-Type: application/trickle-ice-sdpfrag Content-Type: application/trickle-ice-sdpfrag
Content-Length: 252 Content-Length: 252
a=ice-lite a=ice-lite
a=ice-options:trickle ice2 a=ice-options:trickle ice2
a=group:BUNDLE 0 1 a=group:BUNDLE 0 1
m=audio 9 UDP/TLS/RTP/SAVPF 111 m=audio 9 UDP/TLS/RTP/SAVPF 111
a=mid:0 a=mid:0
a=ice-ufrag:289b31b754eaa438 a=ice-ufrag:289b31b754eaa438
a=ice-pwd:0b66f472495ef0ccac7bda653ab6be49ea13114472a5d10a a=ice-pwd:0b66f472495ef0ccac7bda653ab6be49ea13114472a5d10a
a=candidate:1 1 udp 2130706431 198.51.100.1 39132 typ host a=candidate:1 1 udp 2130706431 198.51.100.1 39132 typ host
a=end-of-candidates a=end-of-candidates
]]></artwork> ]]></sourcecode>
</figure> </figure>
<t><xref target="trickle-ice-example"/> demonstrates a Trickle ICE res tart procedure example. The WHIP client sends a PATCH request containing updated ICE information, including a new ufrag and password, along with newly gathered ICE candidates. In response, the WHIP session provides ICE information for the s ession after the ICE restart, including the updated ufrag and password, as well as the previous ICE candidate.</t>
</section> </section>
</section> </section>
<section anchor="webrtc-constraints"> <section anchor="webrtc-constraints">
<name>WebRTC constraints</name> <name>WebRTC Constraints</name>
<t>To simplify the implementation of WHIP in both clients and media serv <t>To simplify the implementation of WHIP in both clients and media
ers, WHIP introduces specific restrictions on WebRTC usage. The following subsec servers, WHIP introduces specific restrictions on WebRTC usage. The
tions will explain these restrictions in detail:</t> following subsections will explain these restrictions in detail.</t>
<section anchor="sdp-bundle"> <section anchor="sdp-bundle">
<name>SDP Bundle</name> <name>SDP Bundle</name>
<t>Both the WHIP client and the WHIP endpoint <bcp14>SHALL</bcp14> sup <t>Both the WHIP client and the WHIP endpoint <bcp14>SHALL</bcp14>
port <xref target="RFC9143"/> and use "max-bundle" policy as defined in <xref ta support <xref target="RFC9143"/> and use the "max-bundle" policy as
rget="RFC9429"/>. The WHIP client and the media server <bcp14>MUST</bcp14> suppo defined in <xref target="RFC9429"/>. The WHIP client and the media
rt multiplexed media associated with the BUNDLE group as per <xref section="9" s server <bcp14>MUST</bcp14> support multiplexed media associated with
ectionFormat="of" target="RFC9143"/>. In addition, per <xref target="RFC9143"/> the BUNDLE group as per <xref section="9" sectionFormat="of"
the WHIP client and media server <bcp14>SHALL</bcp14> use RTP/RTCP multiplexing target="RFC9143"/>. In addition, per <xref target="RFC9143"/>, the
for all bundled media. In order to reduce the network resources required at the WHIP client and media server <bcp14>SHALL</bcp14> use RTP/RTCP
media server, both The WHIP client and WHIP endpoints <bcp14>MUST</bcp14> includ multiplexing for all bundled media. In order to reduce the network
e the "rtcp-mux-only" attribute in each bundled "m=" sections as per <xref secti resources required at the media server, both the WHIP client and
on="3" sectionFormat="of" target="RFC8858"/>.</t> WHIP endpoints <bcp14>MUST</bcp14> include the "rtcp-mux-only"
attribute in each bundled "m=" section as per <xref section="3"
sectionFormat="of" target="RFC8858"/>.</t>
</section> </section>
<section anchor="single-mediastream"> <section anchor="single-mediastream">
<name>Single MediaStream</name> <name>Single MediaStream</name>
<t>WHIP only supports a single MediaStream as defined in <xref target=
"RFC8830"/> and therefore all "m=" sections <bcp14>MUST</bcp14> contain a "msid" <t>WHIP only supports a single MediaStream as defined in <xref
attribute with the same value. The MediaStream <bcp14>MUST</bcp14> contain at l target="RFC8830"/>; therefore, all "m=" sections <bcp14>MUST</bcp14>
east one MediaStreamTrack of any media kind and it <bcp14>MUST NOT</bcp14> have contain a "msid" attribute with the same value. The MediaStream
two or more than MediaStreamTracks for the same media (audio or video). However, <bcp14>MUST</bcp14> contain at least one MediaStreamTrack of any
it would be possible for future revisions of this spec to allow more than a sin media kind, and it <bcp14>MUST NOT</bcp14> have two or more
gle MediaStream or MediaStreamTrack of each media kind, so in order to ensure fo MediaStreamTracks for the same media (audio or video). However, it
rward compatibility, if the number of audio and or video MediaStreamTracks or nu would be possible for future revisions of this specification to allow
mber of MediaStreams are not supported by the WHIP endpoint, it <bcp14>MUST</bcp more
14> reject the HTTP POST request with an "422 Unprocessable Content" or "400 Bad than a single MediaStream or MediaStreamTrack of each media
Request" error response. The WHIP endpoint <bcp14>MAY</bcp14> also return a pro kind. Therefore, in order to ensure forward compatibility, if the
blem statement as recommended in <xref target="http-usage"/> proving further err number of audio and/or video MediaStreamTracks or the number of
or details about the failed request.</t> MediaStreams are not supported by the WHIP endpoint, it
<bcp14>MUST</bcp14> reject the HTTP POST request with a "422
Unprocessable Content" or "400 Bad Request" error response. The WHIP
endpoint <bcp14>MAY</bcp14> also return a problem statement that provi
des further error
details about the failed request, as
recommended in <xref target="http-usage"/>.</t>
</section> </section>
<section anchor="no-partially-successful-answers"> <section anchor="no-partially-successful-answers">
<name>No partially successful answers</name> <name>No Partially Successful Answers</name>
<t>The WHIP endpoint <bcp14>SHOULD NOT</bcp14> reject individual "m=" <t>The WHIP endpoint <bcp14>SHOULD NOT</bcp14> reject individual
sections as per <xref section="5.3.1" sectionFormat="of" target="RFC9429"/> in c "m=" sections, as specified in <xref section="5.3.1" sectionFormat="of
ase there is any error processing the "m=" section, but reject the HTTP POST req "
uest with an "422 Unprocessable Content" or "400 Bad Request" error response to target="RFC9429"/>, if an error occurs when processing the "m="
prevent having partially successful ingest sessions which can be misleading to e section; instead, it <bcp14>SHOULD</bcp14> reject the HTTP POST reques
nd users. The WHIP endpoint <bcp14>MAY</bcp14> also return a problem statement a t with a "422 Unprocessable
s recommended in <xref target="http-usage"/> proving further error details about Content" or "400 Bad Request" error response to prevent having
the failed request.</t> partially successful ingest sessions, which can be misleading to end
users. The WHIP endpoint <bcp14>MAY</bcp14> also return a problem
statement as recommended in <xref target="http-usage"/> proving
further error details about the failed request.</t>
</section> </section>
<section anchor="dtls-setup-role-and-sdp-setup-attribute"> <section anchor="dtls-setup-role-and-sdp-setup-attribute">
<name>DTLS setup role and SDP "setup" attribute</name> <name>DTLS Setup Role and SDP "setup" Attribute</name>
<t>When a WHIP client sends an SDP offer, it <bcp14>SHOULD</bcp14> ins <t>When a WHIP client sends an SDP offer, it <bcp14>SHOULD</bcp14>
ert an SDP "setup" attribute with an "actpass" attribute value, as defined in <x insert an SDP "setup" attribute with an "actpass" attribute value,
ref target="RFC8842"/>. However, if the WHIP client only implements the DTLS cli as defined in <xref target="RFC8842"/>. However, if the WHIP client
ent role, it <bcp14>MAY</bcp14> use an SDP "setup" attribute with an "active" at only implements the DTLS client role, it <bcp14>MAY</bcp14> use an
tribute value. If the WHIP endpoint does not support an SDP offer with an SDP "s SDP "setup" attribute with an "active" attribute value. If the WHIP
etup" attribute with an "active" attribute value, it <bcp14>SHOULD</bcp14> rejec endpoint does not support an SDP offer with an SDP "setup" attribute
t the request with an "422 Unprocessable Content" or "400 Bad Request" error res with an "active" attribute value, it <bcp14>SHOULD</bcp14> reject
ponse.</t> the request with a "422 Unprocessable Content" or "400 Bad Request"
<t>NOTE: <xref target="RFC8842"/> defines that the offerer must insert error response.</t>
an SDP "setup" attribute with an "actpass" attribute value. However, the WHIP c <t>NOTE: <xref target="RFC8842"/> defines that the offerer
lient will always communicate with a media server that is expected to support th must insert an SDP "setup" attribute with an "actpass" attribute
e DTLS server role, in which case the client might choose to only implement supp value. However, the WHIP client will always communicate with a media
ort for the DTLS client role.</t> 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.</t>
</section> </section>
<section anchor="trickle-ice-and-ice-restarts"> <section anchor="trickle-ice-and-ice-restarts">
<name>Trickle ICE and ICE restarts</name> <name>Trickle ICE and ICE Restarts</name>
<t>The media server <bcp14>SHOULD</bcp14> support full ICE, unless it <t>The media server <bcp14>SHOULD</bcp14> support full ICE, unless
is connected to the Internet with an IP address that is accessible by each WHIP it is connected to the Internet with an IP address that is
client that is authorized to use it, in which case it <bcp14>MAY</bcp14> support accessible by each WHIP client that is authorized to use it, in
only ICE lite. The WHIP client <bcp14>MUST</bcp14> implement and use full ICE.< which case it <bcp14>MAY</bcp14> support only ICE lite. The WHIP
/t> client <bcp14>MUST</bcp14> implement and use full ICE.</t>
<t>Trickle ICE and ICE restarts support is <bcp14>OPTIONAL</bcp14> for <t>Trickle ICE and ICE restart support is <bcp14>OPTIONAL</bcp14>
both the WHIP clients and media servers as explained in <xref target="ice-suppo for both the WHIP clients and media servers as explained in <xref
rt"/>.</t> target="ice-support"/>.</t>
</section> </section>
</section> </section>
<section anchor="load-balancing-and-redirections"> <section anchor="load-balancing-and-redirections">
<name>Load balancing and redirections</name> <name>Load Balancing and Redirections</name>
<t>WHIP endpoints and media servers might not be colocated on the same s <t>WHIP endpoints and media servers might not be colocated on the same
erver, so it is possible to load balance incoming requests to different media se server, so it is possible to load balance incoming requests to
rvers.</t> different media servers.</t>
<t>WHIP clients <bcp14>SHALL</bcp14> support HTTP redirections as per <x
ref section="15.4" sectionFormat="of" target="RFC9110"/>. In order to avoid POST <t>WHIP clients <bcp14>SHALL</bcp14> support HTTP redirections as per
requests to be redirected as GET requests, status codes 301 and 302 <bcp14>MUST <xref section="15.4" sectionFormat="of" target="RFC9110"/>. In order
NOT</bcp14> be used and the preferred method for performing load balancing is v to avoid POST requests being redirected as GET requests, status codes
ia the "307 Temporary Redirect" response status code as described in <xref secti "301 Moved Permanently" and "302 Found" <bcp14>MUST NOT</bcp14> be used;
on="15.4.8" sectionFormat="of" target="RFC9110"/>. Redirections are not required the preferred method
to be supported for the PATCH and DELETE requests.</t> for performing load balancing is via the "307 Temporary Redirect"
<t>In case of high load, the WHIP endpoints <bcp14>MAY</bcp14> return a response status code as described in <xref section="15.4.8"
"503 Service Unavailable" response indicating that the server is currently unabl sectionFormat="of" target="RFC9110"/>. Redirections are not required
e to handle the request due to a temporary overload or scheduled maintenance as to be supported for the PATCH and DELETE requests.</t>
described in <xref section="15.6.4" sectionFormat="of" target="RFC9110"/>, which <t>In case of high load, the WHIP endpoints <bcp14>MAY</bcp14> return
will likely be alleviated after some delay. The WHIP endpoint might send a Retr a "503 Service Unavailable" response indicating that the server is
y-After header field indicating the minimum time that the user agent ought to wa currently unable to handle the request due to a temporary overload or
it before making a follow-up request as described in <xref section="10.2.3" sect scheduled maintenance as described in <xref section="15.6.4"
ionFormat="of" target="RFC9110"/>.</t> sectionFormat="of" target="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 <xref
section="10.2.3" sectionFormat="of" target="RFC9110"/>.</t>
</section> </section>
<section anchor="stunturn-server-configuration"> <section anchor="stunturn-server-configuration">
<name>STUN/TURN server configuration</name> <name>STUN/TURN Server Configuration</name>
<t>The WHIP endpoint <bcp14>MAY</bcp14> return STUN/TURN server configur ation URLs and credentials usable by the client in the "201 Created" response to the HTTP POST request to the WHIP endpoint URL.</t> <t>The WHIP endpoint <bcp14>MAY</bcp14> return STUN/TURN server configur ation URLs and credentials usable by the client in the "201 Created" response to the HTTP POST request to the WHIP endpoint URL.</t>
<t>A reference to each STUN/TURN server will be returned using the "Link <t>A reference to each STUN/TURN server will be returned using the Link
" header field <xref target="RFC8288"/> with a "rel" attribute value of "ice-ser header field <xref target="RFC8288"/> with a "rel" attribute value of "ice-serve
ver". The Link target URI is the server URI as defined in <xref target="RFC7064" r". The Link target URI is the server URI as defined in <xref target="RFC7064"/>
/> and <xref target="RFC7065"/>. The credentials are encoded in the Link target and <xref target="RFC7065"/>. The credentials are encoded in the Link target at
attributes as follows:</t> tributes as follows:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>username: If the Link header field represents a Traversal Using
<t>username: If the Link header field represents a TURN server, and Relays around NAT (TURN) server, then this attribute specifies the username to u
credential-type is "password", then this attribute specifies the username to use se with that TURN server.
with that TURN server.</t> </li>
</li> <li>credential: This attribute represents a long-term
<li> authentication password, as described in <xref section="9.2"
<t>credential: If the "credential-type" attribute is missing or has sectionFormat="of" target="RFC8489"/>.</li>
a "password" value, the credential attribute represents a long-term authenticati
on password, as described in <xref section="9.2" sectionFormat="of" target="RFC8
489"/>.</t>
</li>
<li>
<t>credential-type: If the Link header field represents a TURN serve
r, then this attribute specifies how the credential attribute value should be us
ed when that TURN server requests authorization. The default value if the attrib
ute is not present is "password".</t>
</li>
</ul> </ul>
<t><xref target="stun-server-example"/> illustrates the Link headers inc
luded in a "201 Created" response, providing the ICE server URLs and associated
credentials.</t>
<figure anchor="stun-server-example"> <figure anchor="stun-server-example">
<name>Example of a STUN/TURN servers configuration</name> <name>Example of a STUN/TURN Server's Configuration</name>
<artwork><![CDATA[ <sourcecode type="http-message"><![CDATA[
Link: <stun:stun.example.net>; rel="ice-server" Link: <stun:stun.example.net>; rel="ice-server"
Link: <turn:turn.example.net?transport=udp>; rel="ice-server"; Link: <turn:turn.example.net?transport=udp>; rel="ice-server";
username="user"; credential="myPassword"; credential-type="password" username="user"; credential="myPassword"
Link: <turn:turn.example.net?transport=tcp>; rel="ice-server"; Link: <turn:turn.example.net?transport=tcp>; rel="ice-server";
username="user"; credential="myPassword"; credential-type="password" username="user"; credential="myPassword"
Link: <turns:turn.example.net?transport=tcp>; rel="ice-server"; Link: <turns:turn.example.net?transport=tcp>; rel="ice-server";
username="user"; credential="myPassword"; credential-type="password" username="user"; credential="myPassword"
]]></artwork> ]]></sourcecode>
</figure> </figure>
<t><xref target="stun-server-example"/> illustrates the Link headers inc
luded in a 201 Created response, providing the ICE server URLs and associated cr <t>NOTE: The naming of both the "rel" attribute value of
edentials.</t> "ice-server" and the target attributes follows that used in the
<t>NOTE: The naming of both the "rel" attribute value of "ice-server" an RTCConfiguration dictionary in Section 4.2.1 of the W3C WebRTC
d the target attributes follows the one used on the W3C WebRTC recommendation <x recommendation (see <xref target="W3C.REC-webrtc-20250313"/>). The "rel"
ref target="W3C.REC-webrtc-20210126"/> RTCConfiguration dictionary in section 4. attribute value of "ice-server" is not prepended with the
2.1. "rel" attribute value of "ice-server" is not prepended with the "urn:ietf:p "urn:ietf:params:whip:" so it can be reused by other specifications,
arams:whip:" so it can be reused by other specifications which may use this mech which may use this mechanism to configure the usage of STUN/TURN
anism to configure the usage of STUN/TURN servers.</t> servers.</t>
<t>NOTE: Depending on the ICE Agent implementation, the WHIP client may <t>NOTE: Depending on the ICE agent implementation, the WHIP
need to call the setConfiguration method before calling the setLocalDescription client may need to call the setConfiguration method before calling the
method with the local SDP offer in order to avoid having to perform an ICE resta setLocalDescription method with the local SDP offer in order
rt for applying the updated STUN/TURN server configuration on the next ICE gathe to avoid having to perform an ICE restart for applying the updated
ring phase.</t> STUN/TURN server configuration on the next ICE gathering
<t>There are some WebRTC implementations that do not support updating th phase.</t>
e STUN/TURN server configuration after the local offer has been created as speci
fied in <xref section="4.1.18" sectionFormat="of" target="RFC9429"/>. In order t <t>There are some WebRTC implementations that do not support updating
o support these clients, the WHIP endpoint <bcp14>MAY</bcp14> also include the S the STUN/TURN server configuration after the local offer has been
TUN/TURN server configuration on the responses to OPTIONS request sent to the WH created as specified in <xref section="4.1.18" sectionFormat="of"
IP endpoint URL before the POST request is sent. However, this method is <bcp14> target="RFC9429"/>. In order to support these clients, the WHIP
NOT RECOMMENDED</bcp14> to be used by the WHIP clients and, if supported by the endpoint <bcp14>MAY</bcp14> also include the STUN/TURN server
underlying WHIP client's webrtc implementation, the WHIP client <bcp14>SHOULD</b configuration in the responses to OPTIONS requests sent to the WHIP
cp14> wait for the information to be returned by the WHIP endpoint on the respon endpoint URL before the POST request is sent. However, this method is
se of the HTTP POST request instead.</t> <bcp14>NOT RECOMMENDED</bcp14> to be used by the WHIP clients, and if it
<t>The generation of the TURN server credentials may require performing is
a request to an external provider, which can both add latency to the OPTIONS req supported by the underlying WHIP client's WebRTC implementation, the
uest processing and increase the processing required to handle that request. In WHIP client <bcp14>SHOULD</bcp14> wait for the information to be
order to prevent this, the WHIP endpoint <bcp14>SHOULD NOT</bcp14> return the ST returned by the WHIP endpoint in the response of the HTTP POST request
UN/TURN server configuration if the OPTIONS request is a preflight request for C instead.</t>
ORS as defined in <xref target="FETCH"/>, that is, if The OPTIONS request does n <t>The generation of the TURN server credentials may require
ot contain an Access-Control-Request-Method with "POST" value and the Access-Con sending a request to an external provider, which can both add
trol-Request-Headers HTTP header does not contain the "Link" value.</t> latency to the OPTIONS request processing and increase the processing
<t>The WHIP clients <bcp14>MAY</bcp14> also support configuring the STUN required to handle that request. In order to prevent this, the WHIP
/TURN server URIs with long term credentials provided by either the broadcasting endpoint <bcp14>SHOULD NOT</bcp14> return the STUN/TURN server
service or an external TURN provider, overriding the values provided by the WHI configuration if the OPTIONS request is a preflight request for CORS
P endpoint.</t> as defined in <xref target="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.</t>
<t>The WHIP clients <bcp14>MAY</bcp14> 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.</t>
<section anchor="congestion-control"> <section anchor="congestion-control">
<name>Congestion control</name> <name>Congestion Control</name>
<t><xref target="RFC8836"/> defines the congestion control requirement
s for interactive Real-Time media to be used in WebRTC. These requirements are b <t><xref target="RFC8836"/> defines the congestion control
ased on the assumption of the need to provide the data continuously, within a ve requirements for interactive real-time media to be used in
ry limited time window (no more delay than hundreds of milliseconds end-to-end). WebRTC. These requirements are based on the assumption that the data
If the latency target is higher, some of the requirements present in RFC8836 co needs to be provided continuously within a very limited time window
uld be relaxed to allow more flexible implementations.</t> (a delay of no more than hundreds of milliseconds end-to-end). If
the latency target is higher, some of the requirements present in
<xref target="RFC8836"/> could be relaxed to allow more flexible
implementations.</t>
</section> </section>
</section> </section>
<section anchor="authentication-and-authorization"> <section anchor="authentication-and-authorization">
<name>Authentication and authorization</name> <name>Authentication and Authorization</name>
<t>All WHIP endpoints, sessions and clients <bcp14>MUST</bcp14> support <t>All WHIP endpoints, sessions, and clients <bcp14>MUST</bcp14>
HTTP Authentication as per <xref section="11" sectionFormat="of" target="RFC9110 support HTTP authentication as per <xref section="11"
"/> and in order to ensure interoperability, bearer token authentication as defi sectionFormat="of" target="RFC9110"/>. Additionally, in order to
ned in the next section <bcp14>MUST</bcp14> be supported by all WHIP entities. H ensure interoperability, bearer token authentication as defined in the
owever, this does not preclude the support of additional HTTP authentication sch next section <bcp14>MUST</bcp14> be supported by all WHIP
emes as defined in <xref section="11.6" sectionFormat="of" target="RFC9110"/>.</ entities. However, this does not preclude the support of additional
t> HTTP authentication schemes as defined in <xref section="11.6"
sectionFormat="of" target="RFC9110"/>.</t>
<section anchor="bearer-token-authentication"> <section anchor="bearer-token-authentication">
<name>Bearer token authentication</name> <name>Bearer Token Authentication</name>
<t>WHIP endpoints and sessions <bcp14>MAY</bcp14> require the HTTP req
uest to be authenticated using an HTTP Authorization header field with a Bearer <t>WHIP endpoints and sessions <bcp14>MAY</bcp14> require the HTTP
token as specified in <xref section="2.1" sectionFormat="of" target="RFC6750"/>. request to be authenticated using an HTTP Authorization header field
WHIP clients <bcp14>MUST</bcp14> implement this authentication and authorizatio with a bearer token as specified in <xref section="2.1"
n mechanism and send the HTTP Authorization header field in all HTTP requests se sectionFormat="of" target="RFC6750"/>. WHIP clients
nt to either the WHIP endpoint or session except the preflight OPTIONS requests <bcp14>MUST</bcp14> implement this authentication and authorization
for CORS.</t> mechanism and send the HTTP Authorization header field in all HTTP
<t>The nature, syntax, and semantics of the bearer token, as well as h requests sent to either the WHIP endpoint or session (except the
ow to distribute it to the client, is outside the scope of this document. Some e preflight OPTIONS requests for CORS).</t>
xamples of the kind of tokens that could be used are, but are not limited to, JW
T tokens as per <xref target="RFC6750"/> and <xref target="RFC8725"/> or a share <t>The nature, syntax, and semantics of the bearer token, as well as
d secret stored on a database. The tokens are typically made available to the en how to distribute it to the client, are outside the scope of this
d user alongside the WHIP endpoint URL and configured on the WHIP clients (simil document. Examples of tokens that could be used
ar to the way RTMP URLs and Stream Keys are distributed).</t> include, but are not limited to, JSON Web Tokens (JWTs) as per
<t>WHIP endpoints and sessions could perform the authentication and au <xref target="RFC8725"/> and a shared secret
thorization by encoding an authentication token within the URLs for the WHIP end stored on a database. The tokens are typically made available to the
points or sessions instead. In case the WHIP client is not configured to use a b end user alongside the WHIP endpoint URL and configured on the WHIP
earer token, the HTTP Authorization header field <bcp14>MUST NOT</bcp14> be sent clients (similar to the way Real Time Messaging Protocol (RTMP) URLs
in any request.</t> and Stream Keys are distributed).</t>
<t>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 <bcp14>MUST NOT</bcp14> be sent in any request.</t>
</section> </section>
</section> </section>
<section anchor="simulcast-and-scalable-video-coding"> <section anchor="simulcast-and-scalable-video-coding">
<name>Simulcast and scalable video coding</name> <name>Simulcast and Scalable Video Coding</name>
<t>Simulcast as per <xref target="RFC8853"/> <bcp14>MAY</bcp14> be suppo <t>Simulcast as per <xref target="RFC8853"/> <bcp14>MAY</bcp14> be
rted by both the media servers and WHIP clients through negotiation in the SDP o supported by both the media servers and WHIP clients through
ffer/answer.</t> negotiation in the SDP offer/answer.</t>
<t>If the client supports simulcast and wants to enable it for ingesting <t>If the client supports simulcast and wants to enable it for
, it <bcp14>MUST</bcp14> negotiate the support in the SDP offer according to the ingesting, it <bcp14>MUST</bcp14> negotiate the support in the SDP
procedures in <xref section="5.3" sectionFormat="of" target="RFC8853"/>. A serv offer according to the procedures in <xref section="5.3"
er accepting a simulcast offer <bcp14>MUST</bcp14> create an answer according to sectionFormat="of" target="RFC8853"/>. A server accepting a simulcast
the procedures in <xref section="5.3.2" sectionFormat="of" target="RFC8853"/>.< offer <bcp14>MUST</bcp14> create an answer according to the procedures
/t> in <xref section="5.3.2" sectionFormat="of" target="RFC8853"/>.</t>
<t>It is possible for both media servers and WHIP clients to support Sca <t>It is possible for both media servers and WHIP clients to support
lable Video Coding (SVC). However, as there is no universal negotiation mechanis Scalable Video Coding (SVC). However, as there is no universal
m in SDP for SVC, the encoder must consider the negotiated codec(s), intended us negotiation mechanism in SDP for SVC, the encoder must consider the
age, and SVC support in available decoders when configuring SVC.</t> negotiated codec(s), intended usage, and SVC support in available
decoders when configuring SVC.</t>
</section> </section>
<section anchor="protocol-extensions"> <section anchor="protocol-extensions">
<name>Protocol extensions</name> <name>Protocol Extensions</name>
<t>In order to support future extensions to be defined for the WHIP prot <t>In order to support future extensions to be defined for WHIP, a commo
ocol, a common procedure for registering and announcing the new extensions is de n procedure for registering and announcing the new
fined.</t> extensions is defined.</t>
<t>Protocol extensions supported by the WHIP sessions <bcp14>MUST</bcp14 <t>Protocol extensions supported by the WHIP sessions
> be advertised to the WHIP client in the "201 Created" response to the initial <bcp14>MUST</bcp14> be advertised to the WHIP client in the "201
HTTP POST request sent to the WHIP endpoint. Created" response to the initial HTTP POST request sent to the WHIP
The WHIP endpoint <bcp14>MUST</bcp14> return one "Link" header field for each ex endpoint. The WHIP endpoint <bcp14>MUST</bcp14> return one Link
tension that it supports, with the extension "rel" attribute value containing th header field for each extension that it supports, with the extension
e extension URN and the URL for the HTTP resource that will be available for rec "rel" attribute value containing the extension URN and the URL for the
eiving requests related to that extension.</t> HTTP resource that will be available for receiving requests related to
<t>Protocol extensions are optional for both WHIP clients and servers. W that extension.</t>
HIP clients <bcp14>MUST</bcp14> ignore any Link attribute with an unknown "rel" <t>Protocol extensions are optional for both WHIP clients and
attribute value and WHIP sessions <bcp14>MUST NOT</bcp14> require the usage of a servers. WHIP clients <bcp14>MUST</bcp14> ignore any Link target attribu
ny extension.</t> te
<t>Each protocol extension <bcp14>MUST</bcp14> register a unique "rel" a with an unknown "rel" attribute value, and WHIP sessions <bcp14>MUST
ttribute value at IANA starting with the prefix: "urn:ietf:params:whip:ext" as d NOT</bcp14> require the usage of any extension.</t>
efined in <xref target="urn-whip-subspace"/>.</t>
<t>For example, considering a potential extension of server-to-client co <t>Each protocol extension <bcp14>MUST</bcp14> register a unique "rel"
mmunication using server-sent events as specified in https://html.spec.whatwg.or attribute value that starts with the prefix
g/multipage/server-sent-events.html#server-sent-events, the URL for connecting t "urn:ietf:params:whip:ext" in the "WebRTC-HTTP Ingestion Protocol (WHIP)
o the server-sent event resource for the ingested stream could be returned in th Extension URNs" registry (<xref
e initial HTTP "201 Created" response with a "Link" header field and a "rel" att target="urn-whip-ext-registry"/>).</t>
ribute of "urn:ietf:params:whip:ext:example:server-sent-events" (this document d <t>For example, consider a potential extension of server-to-client
oes not specify such an extension, and uses it only as an example).</t> communication using server-sent events as specified in Section 9.2 of
<t>In this theoretical case, the "201 Created" response to the HTTP POST <xref target="HTML"/>. The URL for connecting to the server-sent event
request would look like:</t> 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).</t>
<t>In this theoretical case, the "201 Created" response to the HTTP
POST request would look like:</t>
<t><xref target="protocol-extension-example"/> 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).
</t>
<figure anchor="protocol-extension-example"> <figure anchor="protocol-extension-example">
<name>Example of a WHIP protocol extension</name> <name>Example of a WHIP Extension</name>
<artwork><![CDATA[ <sourcecode type="http-message"><![CDATA[
HTTP/1.1 201 Created HTTP/1.1 201 Created
Content-Type: application/sdp Content-Type: application/sdp
Location: https://whip.example.com/session/id Location: https://whip.example.com/session/id
Link: <https://whip.example.com/session/id/sse>; Link: <https://whip.example.com/session/id/sse>;
rel="urn:ietf:params:whip:ext:example:server-sent-events" rel="urn:ietf:params:whip:ext:example:server-sent-events"
]]></artwork> ]]></sourcecode>
</figure> </figure>
<t><xref target="protocol-extension-example"/> shows an example of a WHI P protocol extension supported by the WHIP session, as indicated in the Link hea der of the 201 Created response.</t>
</section> </section>
</section> </section>
<section anchor="security-considerations"> <section anchor="security-considerations">
<name>Security Considerations</name> <name>Security Considerations</name>
<t>This document specifies a new protocol on top of HTTP and WebRTC, thus, <t>This document specifies a new protocol on top of HTTP and WebRTC;
security protocols and considerations from related specifications apply to the thus, security protocols and considerations from related specifications
WHIP specification. These include:</t> apply to the WHIP specification. These include:</t>
<ul spacing="normal">
<li> <ul>
<t>WebRTC security considerations: <xref target="RFC8826"/>. HTTPS <bc <li>WebRTC security considerations: See <xref
p14>SHALL</bcp14> be used in order to preserve the WebRTC security model.</t> target="RFC8826"/>. HTTPS <bcp14>SHALL</bcp14> be used in order to
</li> preserve the WebRTC security model.</li>
<li> <li>Transport Layer Security (TLS): See <xref target="RFC8446"/> and
<t>Transport Layer Security (TLS): <xref target="RFC8446"/> and <xref <xref target="RFC9147"/>.</li>
target="RFC9147"/>.</t> <li>HTTP security: See <xref section="11" sectionFormat="of"
</li> target="RFC9112"/> and <xref section="17" sectionFormat="of"
<li> target="RFC9110"/>.</li>
<t>HTTP security: <xref section="11" sectionFormat="of" target="RFC911 <li>URI security: See <xref section="7" sectionFormat="of" target="RFC
2"/> and <xref section="17" sectionFormat="of" target="RFC9110"/>.</t> 3986"/>.</li>
</li>
<li>
<t>URI security: <xref section="7" sectionFormat="of" target="RFC3986"
/>.</t>
</li>
</ul> </ul>
<t>On top of that, the WHIP protocol exposes a thin new attack surface spe <t>On top of that, WHIP exposes a thin new attack surface
cific of the REST API methods used within it:</t> specific to the REST API methods used within it:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>HTTP POST flooding and resource exhaustion: It would be possible
<t>HTTP POST flooding and resource exhaustion: for an attacker in possession of authentication credentials valid
It would be possible for an attacker in possession of authentication credentials for ingesting a WHIP stream to make multiple HTTP POST requests to the
valid for ingesting a WHIP stream to make multiple HTTP POST to the WHIP endpoi WHIP
nt. endpoint. This will force the WHIP endpoint to process the incoming
This will force the WHIP endpoint to process the incoming SDP and allocate resou SDP and allocate resources for being able to set up the DTLS/ICE
rces for being able to set up the DTLS/ICE connection. connection. While the malicious client does not need to initiate
While the malicious client does not need to initiate the DTLS/ICE connection at the DTLS/ICE connection at all, the WHIP session will have to wait
all, the WHIP session will have to wait for the DTLS/ICE connection timeout in o for the DTLS/ICE connection timeout in order to release the
rder to release the associated resources. associated resources. If the connection rate is high enough, this
If the connection rate is high enough, this could lead to resource exhaustion on could lead to resource exhaustion on the servers handling the
the servers handling the requests and it will not be able to process legitimate requests, and they will not be able to process legitimate incoming
incoming ingests. ingests. In order to prevent this scenario, WHIP endpoints
In order to prevent this scenario, WHIP endpoints <bcp14>SHOULD</bcp14> implemen <bcp14>SHOULD</bcp14> implement a rate limit and avalanche control
t a rate limit and avalanche control mechanism for incoming initial HTTP POST re mechanism for incoming initial HTTP POST requests.</li>
quests.</t>
</li> <li>Insecure Direct Object References (IDORs) for WHIP session URLs:
<li> If the URLs returned by the WHIP endpoint for the location of WHIP
<t>Insecure direct object references (IDOR) on the WHIP session locati sessions are easy to guess, it would be possible for an
ons: attacker to send multiple HTTP DELETE requests and terminate all
If the URLs returned by the WHIP endpoint for the WHIP sessions location are eas the WHIP sessions currently running.
y to guess, it would be possible for an attacker to send multiple HTTP DELETE re In order to prevent this scenario,
quests and terminate all the WHIP sessions currently running. WHIP endpoints <bcp14>SHOULD</bcp14> generate URLs with enough
In order to prevent this scenario, WHIP endpoints <bcp14>SHOULD</bcp14> generate randomness, using a cryptographically secure pseudorandom number
URLs with enough randomness, using a cryptographically secure pseudorandom numb generator following the best practices in "Randomness Requirements
er generator following the best practices in Randomness Requirements for Securit for Security" <xref target="RFC4086"/>, and implement a rate limit and
y <xref target="RFC4086"/>, and implement a rate limit and avalanche control mec avalanche control
hanism for HTTP DELETE requests. mechanism for HTTP DELETE requests. The security considerations for
The security considerations for Universally Unique IDentifier (UUID) <xref secti Universally Unique IDentifiers (UUIDs) in <xref section="8"
on="8" sectionFormat="comma" target="RFC9562"/> are applicable for generating th sectionFormat="of" target="RFC9562"/> are applicable for generating th
e WHIP sessions location URL.</t> e
</li> WHIP session URLs.</li>
<li>
<t>HTTP PATCH flooding: <li>HTTP PATCH flooding: Similar to the HTTP POST flooding, a
Similar to the HTTP POST flooding, a malicious client could also create a resour malicious client could also create resource exhaustion by sending
ce exhaustion by sending multiple HTTP PATCH request to the WHIP session, althou multiple HTTP PATCH requests to the WHIP session, although the WHIP
gh the WHIP sessions can limit the impact by not allocating new ICE candidates a sessions can limit the impact by not allocating new ICE candidates
nd reusing the existing ICE candidates when doing ICE restarts. and reusing the existing ICE candidates when doing ICE restarts. In
In order to prevent this scenario, WHIP endpoints <bcp14>SHOULD</bcp14> implemen order to prevent this scenario, WHIP endpoints <bcp14>SHOULD</bcp14>
t a rate limit and avalanche control mechanism for incoming HTTP PATCH requests. implement a rate limit and avalanche control mechanism for incoming
</t> HTTP PATCH requests.</li>
</li>
</ul> </ul>
</section> </section>
<section anchor="iana-considerations"> <section anchor="iana-considerations">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t>This specification adds a new link relation type and a registry for URN
sub-namespaces for WHIP protocol extensions.</t> <t>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.
</t>
<section anchor="link-relation-type-ice-server"> <section anchor="link-relation-type-ice-server">
<name>Link Relation Type: ice-server</name> <name>Link Relation Type: ice-server</name>
<t>The link relation type below has been registered by IANA per <xref se <t>The link relation type below has been registered by IANA in the
ction="4.2" sectionFormat="of" target="RFC8288"/>.</t> "Link Relation Types" registry per <xref section="4.2"
<t>Relation Name: ice-server</t> sectionFormat="of" target="RFC8288"/>:</t>
<t>Description: Conveys the STUN and TURN servers that can be used by an
ICE Agent to establish a connection with a peer.</t> <dl newline="false" spacing="normal">
<t>Reference: TBD</t> <dt>Relation Name:</dt><dd>ice-server</dd>
<dt>Description:</dt><dd>Conveys the STUN and TURN servers that can be u
sed by
an ICE agent to establish a connection with a peer.</dd>
<dt>Reference:</dt><dd>RFC 9725</dd>
</dl>
</section> </section>
<section anchor="webrtc-http-ingestion-protocol-whip-registry-group">
<name>WebRTC-HTTP Ingestion Protocol (WHIP) registry group</name> <section anchor="urn-whip-subspace">
<t>IANA is asked to create a new registry group called "WebRTC-HTTP Ing <name>URN Sub-namespace for WHIP (urn:ietf:params:whip)</name>
estion Protocol (WHIP)". This group includes the "WebRTC-HTTP ingestion protocol
(WHIP) URNs" and "WebRTC-HTTP ingestion protocol (WHIP) extension URNs" registr <t> IANA has added a new entry in the "IETF URN Sub-namespace for Registered
ies described below.</t> Protocol Parameter Identifiers" registry, following the template in <xref
target="RFC3553"/>:</t>
<dl newline="false">
<dt>Registry name:</dt><dd>whip</dd>
<dt>Specification:</dt><dd>RFC 9725</dd>
<dt>Repository:</dt><dd>&lt;https://www.iana.org/assignments/whip&gt;</dd>
<dt>Index value:</dt><dd>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.</dd>
</dl>
<t>To manage this sub-namespace, IANA has created two registries within
a new registry group called "WebRTC-HTTP Ingestion Protocol (WHIP)":</t>
<ul>
<li>"WebRTC-HTTP Ingestion Protocol (WHIP) URNs" registry (<xref target="urn-whi
p-registry"/>)</li>
<li>"WebRTC-HTTP Ingestion Protocol (WHIP) Extension URNs" registry (<xref targe
t="urn-whip-ext-registry"/>)</li>
</ul>
</section> </section>
<section anchor="registration-of-whip-urn-sub-namespace-and-whip-registrie
s">
<name>Registration of WHIP URN Sub-namespace and WHIP registries</name>
<t>IANA is asked to add an entry to the "IETF URN Sub-namespace for Regi
stered Protocol Parameter Identifiers" registry and create a sub-namespace for t
he Registered Parameter Identifier as per <xref target="RFC3553"/>: "urn:ietf:pa
rams:whip".</t>
<t>To manage this sub-namespace, IANA is asked to create the "WebRTC-HTT
P ingestion protocol (WHIP) URNs" and "WebRTC-HTTP ingestion protocol (WHIP) ext
ension URNs".</t>
<section anchor="urn-whip-registry"> <section anchor="urn-whip-registry">
<name>WebRTC-HTTP ingestion protocol (WHIP) URNs registry</name> <name>WebRTC-HTTP Ingestion Protocol (WHIP) URNs Registry</name>
<t>The "WebRTC-HTTP ingestion protocol (WHIP) URNs" registry is used t <t>The "WebRTC-HTTP Ingestion Protocol (WHIP) URNs" registry is used
o manage entries within the "urn:ietf:params:whip" namespace. The registry descr to manage entries within the "urn:ietf:params:whip" namespace. The
iptions is as follows:</t> registration procedure is "Specification Required" <xref target="RFC81
<ul spacing="normal"> 26"/>. The registry contains the following fields:
<li> URN, Name, Reference, IANA Registry Reference, and Change Controller. T
<t>Registry group: WebRTC-HTTP ingestion protocol (WHIP)</t> his document is listed as the reference.</t>
</li>
<li> <t>The registry contains a single initial entry:</t>
<t>Registry name: WebRTC-HTTP ingestion protocol (WHIP) URNs</t> <dl spacing="normal">
</li> <dt>URN:</dt><dd>urn:ietf:params:whip:ext</dd>
<li> <dt>Name:</dt><dd>WebRTC-HTTP Ingestion Protocol (WHIP) extension
<t>Specification: this document (RFC TBD)</t> URNs</dd>
</li> <dt>Reference:</dt><dd><xref target="urn-whip-ext-registry"/> of R
<li> FC 9725</dd>
<t>Registration procedure: Specification Required</t> <dt>IANA Registry Reference:</dt><dd>See "WebRTC-HTTP Ingestion Pr
</li> otocol (WHIP) Extension URNs" on &lt;https://www.iana.org/assignments/whip&gt;</
<li> dd>
<t>Field names: URI, description, change controller, reference and <dt>Change Controller:</dt><dd>IETF</dd>
IANA registry reference</t>
</li> </dl>
</ul>
<t>The registry contains a single initial value:</t>
<ul spacing="normal">
<li>
<t>URI: urn:ietf:params:whip:ext</t>
</li>
<li>
<t>Description: WebRTC-HTTP ingestion protocol (WHIP) extension UR
Ns</t>
</li>
<li>
<t>Change Controller: IETF</t>
</li>
<li>
<t>Reference: this document (RFC TBD) Section <xref target="urn-wh
ip-ext-registry"/></t>
</li>
<li>
<t>IANA registry reference: WebRTC-HTTP ingestion protocol (WHIP)
extension URNs registry.</t>
</li>
</ul>
</section> </section>
<section anchor="urn-whip-ext-registry"> <section anchor="urn-whip-ext-registry">
<name>WebRTC-HTTP ingestion protocol (WHIP) extension URNs registry</n <name>WebRTC-HTTP Ingestion Protocol (WHIP) Extension URNs Registry</n
ame> ame>
<t>The "WebRTC-HTTP ingestion protocol (WHIP) Extension URNs" is used <t>The "WebRTC-HTTP Ingestion Protocol (WHIP) Extension URNs" registry
to manage entries within the "urn:ietf:params:whip:ext" namespace. The registry is
descriptions is as follows:</t> used to manage entries within the "urn:ietf:params:whip:ext"
<ul spacing="normal"> namespace. The registration procedure is "Specification Required"
<li> <xref target="RFC8126"/>.
<t>Registry group: WebRTC-HTTP ingestion protocol (WHIP)</t> The registry contains the following fields:
</li> URN, Name, Reference, IANA Registry Reference, and Change Controller. T
<li> his document is listed as the reference.
<t>Registry name: WebRTC-HTTP ingestion protocol (WHIP) Extension </t>
URNs</t> <t>A WHIP extension URN is used as a value in the "rel" attribute of the
</li> Link header as defined in <xref target="protocol-extensions"/> for the purpose
<li> of signaling the WHIP extensions supported by the WHIP endpoint. WHIP extension
<t>Specification: this document (RFC TBD)</t> URNs have an "ext" type.</t>
</li>
<li>
<t>Registration procedure: Specification Required</t>
</li>
<li>
<t>Field names: URI, description, change controller, reference and
IANA registry reference</t>
</li>
</ul>
</section>
</section>
<section anchor="urn-whip-subspace">
<name>URN Sub-namespace for WHIP</name>
<t>WHIP endpoint utilizes URNs to identify the supported WHIP protocol e
xtensions on the "rel" attribute of the Link header as defined in <xref target="
protocol-extensions"/>.</t>
<t>This section creates and registers an IETF URN Sub-namespace for use
in the WHIP specifications and future extensions.</t>
<section anchor="specification-template">
<name>Specification Template</name>
<t>Namespace ID:</t>
<ul spacing="normal">
<li>
<t>The Namespace ID "whip" has been assigned.</t>
</li>
</ul>
<t>Registration Information:</t>
<ul spacing="normal">
<li>
<t>Version: 1</t>
</li>
<li>
<t>Date: TBD</t>
</li>
</ul>
<t>Declared registrant of the namespace:</t>
<ul spacing="normal">
<li>
<t>Registering organization: The Internet Engineering Task Force.<
/t>
</li>
<li>
<t>Designated contact: A designated expert will monitor the WHIP p
ublic mailing list, "wish@ietf.org".</t>
</li>
</ul>
<t>Declaration of Syntactic Structure:</t>
<ul spacing="normal">
<li>
<t>The Namespace Specific String (NSS) of all URNs that use the "w
hip" Namespace ID shall have the following structure: urn:ietf:params:whip:{type
}:{name}:{other}.</t>
</li>
<li>
<t>The keywords have the following meaning: </t>
<ul spacing="normal">
<li>
<t>type: The entity type. This specification only defines the
"ext" type.</t>
</li>
<li>
<t>name: A required ASCII string that conforms to the URN synt
ax requirements (see <xref target="RFC8141"/>) and defines a major namespace of
a WHIP protocol extension. The value <bcp14>MAY</bcp14> also be an industry name
or organization name.</t>
</li>
<li>
<t>other: Any ASCII string that conforms to the URN syntax req
uirements (see <xref target="RFC8141"/>) and defines the sub-namespace (which <b
cp14>MAY</bcp14> be further broken down in namespaces delimited by colons) as ne
eded to uniquely identify an WHIP protocol extension.</t>
</li>
</ul>
</li>
</ul>
<t>Relevant Ancillary Documentation:</t>
<ul spacing="normal">
<li>
<t>None</t>
</li>
</ul>
<t>Identifier Uniqueness Considerations:</t>
<ul spacing="normal">
<li>
<t>The designated contact shall be responsible for reviewing and e
nforcing uniqueness.</t>
</li>
</ul>
<t>Identifier Persistence Considerations:</t>
<ul spacing="normal">
<li>
<t>Once a name has been allocated, it <bcp14>MUST NOT</bcp14> be r
eallocated for a different purpose.</t>
</li>
<li>
<t>The rules provided for assignments of values within a sub-names
pace <bcp14>MUST</bcp14> be constructed so that the meanings of values cannot ch
ange.</t>
</li>
<li>
<t>This registration mechanism is not appropriate for naming value
s whose meanings may change over time.</t>
</li>
</ul>
<t>Process of Identifier Assignment:</t>
<ul spacing="normal">
<li>
<t>Namespace with type "ext" (e.g., "urn:ietf:params:whip:ext") is
reserved for IETF-approved WHIP specifications.</t>
</li>
</ul>
<t>Process of Identifier Resolution:</t>
<ul spacing="normal">
<li>
<t>None specified.</t>
</li>
</ul>
<t>Rules for Lexical Equivalence:</t>
<ul spacing="normal">
<li>
<t>No special considerations; the rules for lexical equivalence sp
ecified in <xref target="RFC8141"/> apply.</t>
</li>
</ul>
<t>Conformance with URN Syntax:</t>
<ul spacing="normal">
<li>
<t>No special considerations.</t>
</li>
</ul>
<t>Validation Mechanism:</t>
<ul spacing="normal">
<li>
<t>None specified.</t>
</li>
</ul>
<t>Scope:</t>
<ul spacing="normal">
<li>
<t>Global.</t>
</li>
</ul>
</section> </section>
</section>
<section anchor="registering-whip-protocol-extensions-urns"> <section anchor="registering-whip-protocol-extensions-urns">
<name>Registering WHIP Protocol Extensions URNs</name> <name>Registering WHIP URNs and WHIP Extension URNs</name>
<t>This section defines the process for registering new WHIP protocol ex <t>This section defines the process for registering new URNs in the
tensions URNs with IANA in the "WebRTC-HTTP ingestion protocol (WHIP) extension "WebRTC-HTTP Ingestion Protocol (WHIP) URNs" registry (<xref
URNs" registry (see <xref target="urn-whip-subspace"/>).</t> target="urn-whip-registry"/>) and the "WebRTC-HTTP Ingestion Protocol
<t>A WHIP Protocol Extension URNs is used as a value in the "rel" attrib (WHIP) Extension URNs" registry (<xref target="urn-whip-ext-registry"/>)
ute of the Link header as defined in <xref target="protocol-extensions"/> for th .
e purpose of signaling the WHIP protocol extensions supported by the WHIP endpoi </t>
nts.</t>
<t>WHIP Protocol Extensions URNs have an "ext" type as defined in <xref
target="urn-whip-subspace"/>.</t>
<section anchor="registration-procedure"> <section anchor="registration-procedure">
<name>Registration Procedure</name> <name>Registration Procedure</name>
<t>The IETF has created a mailing list, "wish@ietf.org", which can be <t>The IETF has created a mailing list, &lt;wish@ietf.org&gt;, which c
used an
for public discussion of WHIP protocol extensions proposals prior to registra be used for public discussion of proposals
tion. prior to registration. Use of the mailing list is strongly
Use of the mailing list is strongly encouraged. The IESG has encouraged. A designated expert (DE) <xref
appointed a designated expert as per <xref target="RFC8126"/> who will monito target="RFC8126"/>, appointed by the IESG, will monitor the &lt;wish@
r the ietf.org&gt; mailing list
wish@ietf.org mailing list and review registrations.</t> and review registrations.</t>
<t>Registration of new "ext" type URNs (in the namespace "urn:ietf:par <t>Registration of new entries in the WHIP registries defined in this
ams:whip:ext") belonging to a WHIP Protocol Extension <bcp14>MUST</bcp14> be doc document
umented in a permanent and readily available public specification, in sufficient <bcp14>MUST</bcp14> be documented in a permanent and readily
detail so that interoperability between independent implementations is possible available public specification, in sufficient detail so that
and reviewed by the designated expert as per Section 4.6 of <xref target="RFC81 interoperability between independent implementations is possible, and
26"/>. reviewed by the DE as per <xref section="4.6"
An Standards Track RFC is <bcp14>REQUIRED</bcp14> for the registration of new sectionFormat="of" target="RFC8126"/>. A Standards Track RFC is
value data types that modify existing properties. <bcp14>REQUIRED</bcp14> for the registration of new value data types
An Standards Track RFC is also <bcp14>REQUIRED</bcp14> for registration of WH that modify existing properties. A Standards Track RFC is also
IP Protocol Extensions URNs that modify WHIP Protocol Extensions previously docu <bcp14>REQUIRED</bcp14> for registration of WHIP extension
mented in an existing RFC.</t> URNs that modify WHIP extensions previously documented in
<t>The registration procedure begins when a completed registration tem an existing RFC.</t>
plate, defined in the sections below, is sent to iana@iana.org.
Decisions made by the designated expert can be appealed to an Applications an <t>The registration procedure begins when a completed registration tem
d Real Time (ART) Area Director, then to the IESG. plate, defined in <xref target="whip-protocol-extension-registration-template"/>
The normal appeals procedure described in <xref target="BCP9"/> is to be foll , is sent to &lt;iana@iana.org&gt;.
owed.</t> Decisions made by the DE can be appealed to an Applications and Real-Time (AR
<t>Once the registration procedure concludes successfully, IANA create T) Area Director, then to the IESG.
s The normal appeals procedure described in RFC 2026 <xref target="BCP9"/> is t
or modifies the corresponding record in the WHIP Protocol Extension registry. o be followed.</t>
</t> <t>Once the registration procedure concludes successfully, IANA will c
<t>An RFC specifying one or more new WHIP Protocol Extension URNs <bcp reate
14>MUST</bcp14> include the or modify the corresponding record in the "WebRTC-HTTP Ingestion Protocol (WH
completed registration templates, which <bcp14>MAY</bcp14> be expanded with IP) URNs Registry" or "WebRTC-HTTP Ingestion Protocol (WHIP) Extension URNs" reg
additional information. These completed templates are intended to go istry.</t>
<t>An RFC specifying one or more new WHIP extension URNs <bcp14>MUST</
bcp14> include the
completed registration template(s), which <bcp14>MAY</bcp14> 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. in the body of the document, not in the IANA Considerations section.
The RFC <bcp14>MUST</bcp14> include the syntax and semantics of any extension -specific attributes that may be provided in a Link header The RFC <bcp14>MUST</bcp14> include the syntax and semantics of any extension -specific attributes that may be provided in a Link header
field advertising the extension.</t> field advertising the extension.</t>
</section> </section>
<section anchor="guidance-for-designated-experts"> <section anchor="guidance-for-designated-experts">
<name>Guidance for Designated Experts</name> <name>Guidance for the Designated Expert</name>
<t>The Designated Expert (DE) is expected to ascertain the existence o <t>The DE is expected to do the following:</t>
f suitable documentation (a specification) as described in <xref target="RFC8126 <ul>
"/> and to verify that the document is permanently and publicly available.</t> <li>Ascertain the existence of suitable documentation (a
<t>The DE is also expected to check the clarity of purpose and use of specification) as described in <xref target="RFC8126"/> and verify
the requested registration.</t> that the document is permanently and publicly
<t>Additionally, the DE must verify that any request for one of these available. Specifications should be documented in an
registrations has been made available for review and comment by posting the requ Internet-Draft.</li>
est to the WebRTC Ingest Signaling over HTTPS (wish) Working Group mailing list. <li>Check the clarity of purpose and use of the requested
</t> registration.</li> <li>Verify that any request for one of these
<t>Specifications should be documented in an Internet-Draft. Lastly, t registrations has been made available for review and comments by
he DE must ensure that any other request for a code point does not conflict with posting the request to the &lt;wish@ietf.org&gt; mailing list.</li>
work that is active in or already published by the IETF.</t> <li>Ensure that any other request for a code point does not conflict w
ith work that is active or already published by the IETF.</li>
</ul>
</section> </section>
<section anchor="whip-protocol-extension-registration-template"> <section anchor="whip-protocol-extension-registration-template">
<name>WHIP Protocol Extension Registration Template</name> <name>Registration Template</name>
<t>A WHIP Protocol Extension URNs is defined by completing the followi <t>A WHIP extension URN is defined by completing the following templat
ng template:</t> e:</t>
<ul spacing="normal"> <dl spacing="normal">
<li> <dt>URN:</dt><dd>A unique URN (e.g., "urn:ietf:params:whip:ext:exa
<t>URN: A unique URN for the WHIP Protocol Extension (e.g., "urn:i mple:server-sent-events")</dd>
etf:params:whip:ext:example:server-sent-events").</t> <dt>Name:</dt><dd>A descriptive name (e.g., "Sender Side events")<
</li> /dd>
<li> <dt>Reference:</dt><dd>A formal reference to the publicly availabl
<t>Reference: A formal reference to the publicly available specifi e specification</dd>
cation</t> <dt>IANA Registry Reference:</dt><dd>The registry related to the n
</li> ew URN
<li> </dd>
<t>Name: A descriptive name of the WHIP Protocol Extension (e.g., <dt>Change Controller:</dt><dd>For Standards Track documents, this
"Sender Side events").</t> is "IETF".
</li> Otherwise, this is the name of the person or body
<li> that has change control over the specification.</dd>
<t>Description: A brief description of the function of the extensi </dl>
on, in a short paragraph or two</t>
</li>
<li>
<t>Contact information: Contact information for the organization o
r person making the registration</t>
</li>
</ul>
</section> </section>
</section> </section>
</section> </section>
<section anchor="acknowledgements">
<name>Acknowledgements</name>
<t>The authors wish to thank Lorenzo Miniero, Juliusz Chroboczek, Adam Roa
ch, Nils Ohlmeier, Christer Holmberg, Cameron Elliott, Gustavo Garcia, Jonas Bir
me, Sandro Gauci, Christer Holmberg and everyone else in the WebRTC community th
at have provided comments, feedback, text and improvement proposals on the docum
ent and contributed early implementations of the spec.</t>
</section>
</middle> </middle>
<back> <back>
<references anchor="sec-combined-references"> <references anchor="sec-combined-references">
<name>References</name> <name>References</name>
<references anchor="sec-normative-references"> <references anchor="sec-normative-references">
<name>Normative References</name> <name>Normative References</name>
<reference anchor="FETCH" target="https://fetch.spec.whatwg.org"> <reference anchor="FETCH" target="https://fetch.spec.whatwg.org">
<front> <front>
<title>Fetch - Living Standard</title> <title>Fetch</title>
<author> <author>
<organization>WHATWG</organization> <organization>WHATWG</organization>
</author> </author>
<date>n.d.</date>
</front>
</reference>
<reference anchor="RFC9429">
<front>
<title>JavaScript Session Establishment Protocol (JSEP)</title>
<author fullname="J. Uberti" initials="J." surname="Uberti"/>
<author fullname="C. Jennings" initials="C." surname="Jennings"/>
<author fullname="E. Rescorla" initials="E." role="editor" surname="
Rescorla"/>
<date month="April" year="2024"/>
<abstract>
<t>This document describes the mechanisms for allowing a JavaScrip
t application to control the signaling plane of a multimedia session via the int
erface specified in the W3C RTCPeerConnection API and discusses how this relates
to existing signaling protocols.</t>
<t>This specification obsoletes RFC 8829.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9429"/>
<seriesInfo name="DOI" value="10.17487/RFC9429"/>
</reference>
<reference anchor="RFC3264">
<front>
<title>An Offer/Answer Model with Session Description Protocol (SDP)
</title>
<author fullname="J. Rosenberg" initials="J." surname="Rosenberg"/>
<author fullname="H. Schulzrinne" initials="H." surname="Schulzrinne
"/>
<date month="June" year="2002"/>
<abstract>
<t>This document defines a mechanism by which two entities can mak
e use of the Session Description Protocol (SDP) to arrive at a common view of a
multimedia session between them. In the model, one participant offers the other
a description of the desired session from their perspective, and the other parti
cipant answers with the desired session from their perspective. This offer/answe
r model is most useful in unicast sessions where information from both participa
nts is needed for the complete view of the session. The offer/answer model is us
ed by protocols like the Session Initiation Protocol (SIP). [STANDARDS-TRACK]</t
>
</abstract>
</front>
<seriesInfo name="RFC" value="3264"/>
<seriesInfo name="DOI" value="10.17487/RFC3264"/>
</reference>
<reference anchor="RFC2119">
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</tit
le>
<author fullname="S. Bradner" initials="S." surname="Bradner"/>
<date month="March" year="1997"/>
<abstract>
<t>In many standards track documents several words are used to sig
nify the requirements in the specification. These words are often capitalized. T
his document defines these words as they should be interpreted in IETF documents
. This document specifies an Internet Best Current Practices for the Internet Co
mmunity, and requests discussion and suggestions for improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference>
<reference anchor="RFC8174">
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
tle>
<author fullname="B. Leiba" initials="B." surname="Leiba"/>
<date month="May" year="2017"/>
<abstract>
<t>RFC 2119 specifies common key words that may be used in protoco
l specifications. This document aims to reduce the ambiguity by clarifying that
only UPPERCASE usage of the key words have the defined special meanings.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="8174"/>
<seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference>
<reference anchor="RFC9110">
<front>
<title>HTTP Semantics</title>
<author fullname="R. Fielding" initials="R." role="editor" surname="
Fielding"/>
<author fullname="M. Nottingham" initials="M." role="editor" surname
="Nottingham"/>
<author fullname="J. Reschke" initials="J." role="editor" surname="R
eschke"/>
<date month="June" year="2022"/>
<abstract>
<t>The Hypertext Transfer Protocol (HTTP) is a stateless applicati
on-level protocol for distributed, collaborative, hypertext information systems.
This document describes the overall architecture of HTTP, establishes common te
rminology, and defines aspects of the protocol that are shared by all versions.
In this definition are core protocol elements, extensibility mechanisms, and the
"http" and "https" Uniform Resource Identifier (URI) schemes.</t>
<t>This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7
232, 7233, 7235, 7538, 7615, 7694, and portions of 7230.</t>
</abstract>
</front> </front>
<seriesInfo name="STD" value="97"/> <refcontent>WHATWG Living Standard</refcontent>
<seriesInfo name="RFC" value="9110"/> <annotation>Commit snapshot: <eref
<seriesInfo name="DOI" value="10.17487/RFC9110"/> target="https://fetch.spec.whatwg.org/commit-snapshots/edfa8d100cf1ecf
</reference> de385f65c172e0e8d018fcd98/"
<reference anchor="RFC7675"> brackets="angle"/>.</annotation>
<front>
<title>Session Traversal Utilities for NAT (STUN) Usage for Consent
Freshness</title>
<author fullname="M. Perumal" initials="M." surname="Perumal"/>
<author fullname="D. Wing" initials="D." surname="Wing"/>
<author fullname="R. Ravindranath" initials="R." surname="Ravindrana
th"/>
<author fullname="T. Reddy" initials="T." surname="Reddy"/>
<author fullname="M. Thomson" initials="M." surname="Thomson"/>
<date month="October" year="2015"/>
<abstract>
<t>To prevent WebRTC applications, such as browsers, from launchin
g attacks by sending traffic to unwilling victims, periodic consent to send need
s to be obtained from remote endpoints.</t>
<t>This document describes a consent mechanism using a new Session
Traversal Utilities for NAT (STUN) usage.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7675"/>
<seriesInfo name="DOI" value="10.17487/RFC7675"/>
</reference> </reference>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
429.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
264.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
119.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
174.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
110.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
675.xml"/>
<reference anchor="W3C.REC-ldp-20150226" target="https://www.w3.org/TR/2 015/REC-ldp-20150226/"> <reference anchor="W3C.REC-ldp-20150226" target="https://www.w3.org/TR/2 015/REC-ldp-20150226/">
<front> <front>
<title>Linked Data Platform 1.0</title> <title>Linked Data Platform 1.0</title>
<author fullname="Ashok Malhotra" role="editor"/>
<author fullname="John Arwe" role="editor"/> <author fullname="John Arwe" role="editor"/>
<author fullname="Steve Speicher" role="editor"/> <author fullname="Steve Speicher" role="editor"/>
<author fullname="Ashok Malhotra" role="editor"/>
<date day="26" month="February" year="2015"/> <date day="26" month="February" year="2015"/>
</front> </front>
<seriesInfo name="W3C REC" value="REC-ldp-20150226"/> <refcontent>W3C Recommendation</refcontent>
<seriesInfo name="W3C" value="REC-ldp-20150226"/> <annotation>Latest version available at: <eref target="https://www.w3.
</reference> org/TR/ldp/" brackets="angle"/>.</annotation>
<reference anchor="RFC8845">
<front>
<title>Framework for Telepresence Multi-Streams</title>
<author fullname="M. Duckworth" initials="M." role="editor" surname=
"Duckworth"/>
<author fullname="A. Pepperell" initials="A." surname="Pepperell"/>
<author fullname="S. Wenger" initials="S." surname="Wenger"/>
<date month="January" year="2021"/>
<abstract>
<t>This document defines a framework for a protocol to enable devi
ces in a telepresence conference to interoperate. The protocol enables communica
tion of information about multiple media streams so a sending system and receivi
ng system can make reasonable decisions about transmitting, selecting, and rende
ring the media streams. This protocol is used in addition to SIP signaling and S
ession Description Protocol (SDP) negotiation for setting up a telepresence sess
ion.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8845"/>
<seriesInfo name="DOI" value="10.17487/RFC8845"/>
</reference>
<reference anchor="RFC8838">
<front>
<title>Trickle ICE: Incremental Provisioning of Candidates for the I
nteractive Connectivity Establishment (ICE) Protocol</title>
<author fullname="E. Ivov" initials="E." surname="Ivov"/>
<author fullname="J. Uberti" initials="J." surname="Uberti"/>
<author fullname="P. Saint-Andre" initials="P." surname="Saint-Andre
"/>
<date month="January" year="2021"/>
<abstract>
<t>This document describes "Trickle ICE", an extension to the Inte
ractive Connectivity Establishment (ICE) protocol that enables ICE agents to beg
in connectivity checks while they are still gathering candidates, by incremental
ly exchanging candidates over time instead of all at once. This method can consi
derably accelerate the process of establishing a communication session.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8838"/>
<seriesInfo name="DOI" value="10.17487/RFC8838"/>
</reference>
<reference anchor="RFC5789">
<front>
<title>PATCH Method for HTTP</title>
<author fullname="L. Dusseault" initials="L." surname="Dusseault"/>
<author fullname="J. Snell" initials="J." surname="Snell"/>
<date month="March" year="2010"/>
<abstract>
<t>Several applications extending the Hypertext Transfer Protocol
(HTTP) require a feature to do partial resource modification. The existing HTTP
PUT method only allows a complete replacement of a document. This proposal adds
a new HTTP method, PATCH, to modify an existing HTTP resource. [STANDARDS-TRACK]
</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5789"/>
<seriesInfo name="DOI" value="10.17487/RFC5789"/>
</reference>
<reference anchor="RFC8840">
<front>
<title>A Session Initiation Protocol (SIP) Usage for Incremental Pro
visioning of Candidates for the Interactive Connectivity Establishment (Trickle
ICE)</title>
<author fullname="E. Ivov" initials="E." surname="Ivov"/>
<author fullname="T. Stach" initials="T." surname="Stach"/>
<author fullname="E. Marocco" initials="E." surname="Marocco"/>
<author fullname="C. Holmberg" initials="C." surname="Holmberg"/>
<date month="January" year="2021"/>
<abstract>
<t>The Interactive Connectivity Establishment (ICE) protocol descr
ibes a Network Address Translator (NAT) traversal mechanism for UDP-based multim
edia sessions established with the Offer/Answer model. The ICE extension for Inc
remental Provisioning of Candidates (Trickle ICE) defines a mechanism that allow
s ICE Agents to shorten session establishment delays by making the candidate gat
hering and connectivity checking phases of ICE non-blocking and by executing the
m in parallel.</t>
<t>This document defines usage semantics for Trickle ICE with the
Session Initiation Protocol (SIP). The document also defines a new SIP Info Pack
age to support this usage together with the corresponding media type. Additional
ly, a new Session Description Protocol (SDP) "end-of-candidates" attribute and a
new SIP option tag "trickle-ice" are defined.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8840"/>
<seriesInfo name="DOI" value="10.17487/RFC8840"/>
</reference>
<reference anchor="RFC6585">
<front>
<title>Additional HTTP Status Codes</title>
<author fullname="M. Nottingham" initials="M." surname="Nottingham"/
>
<author fullname="R. Fielding" initials="R." surname="Fielding"/>
<date month="April" year="2012"/>
<abstract>
<t>This document specifies additional HyperText Transfer Protocol
(HTTP) status codes for a variety of common situations. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6585"/>
<seriesInfo name="DOI" value="10.17487/RFC6585"/>
</reference>
<reference anchor="RFC8839">
<front>
<title>Session Description Protocol (SDP) Offer/Answer Procedures fo
r Interactive Connectivity Establishment (ICE)</title>
<author fullname="M. Petit-Huguenin" initials="M." surname="Petit-Hu
guenin"/>
<author fullname="S. Nandakumar" initials="S." surname="Nandakumar"/
>
<author fullname="C. Holmberg" initials="C." surname="Holmberg"/>
<author fullname="A. Keränen" initials="A." surname="Keränen"/>
<author fullname="R. Shpount" initials="R." surname="Shpount"/>
<date month="January" year="2021"/>
<abstract>
<t>This document describes Session Description Protocol (SDP) Offe
r/Answer procedures for carrying out Interactive Connectivity Establishment (ICE
) between the agents.</t>
<t>This document obsoletes RFCs 5245 and 6336.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8839"/>
<seriesInfo name="DOI" value="10.17487/RFC8839"/>
</reference>
<reference anchor="RFC9143">
<front>
<title>Negotiating Media Multiplexing Using the Session Description
Protocol (SDP)</title>
<author fullname="C. Holmberg" initials="C." surname="Holmberg"/>
<author fullname="H. Alvestrand" initials="H." surname="Alvestrand"/
>
<author fullname="C. Jennings" initials="C." surname="Jennings"/>
<date month="February" year="2022"/>
<abstract>
<t>This specification defines a new Session Description Protocol (
SDP) Grouping Framework extension called 'BUNDLE'. The extension can be used wit
h the SDP offer/answer mechanism to negotiate the usage of a single transport (5
-tuple) for sending and receiving media described by multiple SDP media descript
ions ("m=" sections). Such transport is referred to as a "BUNDLE transport", and
the media is referred to as "bundled media". The "m=" sections that use the BUN
DLE transport form a BUNDLE group.</t>
<t>This specification defines a new RTP Control Protocol (RTCP) So
urce Description (SDES) item and a new RTP header extension.</t>
<t>This specification updates RFCs 3264, 5888, and 7941.</t>
<t>This specification obsoletes RFC 8843.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9143"/>
<seriesInfo name="DOI" value="10.17487/RFC9143"/>
</reference>
<reference anchor="RFC8858">
<front>
<title>Indicating Exclusive Support of RTP and RTP Control Protocol
(RTCP) Multiplexing Using the Session Description Protocol (SDP)</title>
<author fullname="C. Holmberg" initials="C." surname="Holmberg"/>
<date month="January" year="2021"/>
<abstract>
<t>This document defines a new Session Description Protocol (SDP)
media-level attribute, 'rtcp-mux-only', that can be used by an endpoint to indic
ate exclusive support of RTP and RTP Control Protocol (RTCP) multiplexing. The d
ocument also updates RFC 5761 by clarifying that an offerer can use a mechanism
to indicate that it is not able to send and receive RTCP on separate ports.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8858"/>
<seriesInfo name="DOI" value="10.17487/RFC8858"/>
</reference>
<reference anchor="RFC8830">
<front>
<title>WebRTC MediaStream Identification in the Session Description
Protocol</title>
<author fullname="H. Alvestrand" initials="H." surname="Alvestrand"/
>
<date month="January" year="2021"/>
<abstract>
<t>This document specifies a Session Description Protocol (SDP) gr
ouping mechanism for RTP media streams that can be used to specify relations bet
ween media streams.</t>
<t>This mechanism is used to signal the association between the SD
P concept of "media description" and the Web Real-Time Communication (WebRTC) co
ncept of MediaStream/MediaStreamTrack using SDP signaling.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8830"/>
<seriesInfo name="DOI" value="10.17487/RFC8830"/>
</reference>
<reference anchor="RFC8842">
<front>
<title>Session Description Protocol (SDP) Offer/Answer Consideration
s for Datagram Transport Layer Security (DTLS) and Transport Layer Security (TLS
)</title>
<author fullname="C. Holmberg" initials="C." surname="Holmberg"/>
<author fullname="R. Shpount" initials="R." surname="Shpount"/>
<date month="January" year="2021"/>
<abstract>
<t>This document defines the Session Description Protocol (SDP) of
fer/answer procedures for negotiating and establishing a Datagram Transport Laye
r Security (DTLS) association. The document also defines the criteria for when a
new DTLS association must be established. The document updates RFCs 5763 and 73
45 by replacing common SDP offer/answer procedures with a reference to this spec
ification.</t>
<t>This document defines a new SDP media-level attribute, "tls-id"
.</t>
<t>This document also defines how the "tls-id" attribute can be us
ed for negotiating and establishing a Transport Layer Security (TLS) connection,
in conjunction with the procedures in RFCs 4145 and 8122.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8842"/>
<seriesInfo name="DOI" value="10.17487/RFC8842"/>
</reference>
<reference anchor="RFC8288">
<front>
<title>Web Linking</title>
<author fullname="M. Nottingham" initials="M." surname="Nottingham"/
>
<date month="October" year="2017"/>
<abstract>
<t>This specification defines a model for the relationships betwee
n resources on the Web ("links") and the type of those relationships ("link rela
tion types").</t>
<t>It also defines the serialisation of such links in HTTP headers
with the Link header field.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8288"/>
<seriesInfo name="DOI" value="10.17487/RFC8288"/>
</reference>
<reference anchor="RFC7064">
<front>
<title>URI Scheme for the Session Traversal Utilities for NAT (STUN)
Protocol</title>
<author fullname="S. Nandakumar" initials="S." surname="Nandakumar"/
>
<author fullname="G. Salgueiro" initials="G." surname="Salgueiro"/>
<author fullname="P. Jones" initials="P." surname="Jones"/>
<author fullname="M. Petit-Huguenin" initials="M." surname="Petit-Hu
guenin"/>
<date month="November" year="2013"/>
<abstract>
<t>This document specifies the syntax and semantics of the Uniform
Resource Identifier (URI) scheme for the Session Traversal Utilities for NAT (S
TUN) protocol.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7064"/>
<seriesInfo name="DOI" value="10.17487/RFC7064"/>
</reference>
<reference anchor="RFC7065">
<front>
<title>Traversal Using Relays around NAT (TURN) Uniform Resource Ide
ntifiers</title>
<author fullname="M. Petit-Huguenin" initials="M." surname="Petit-Hu
guenin"/>
<author fullname="S. Nandakumar" initials="S." surname="Nandakumar"/
>
<author fullname="G. Salgueiro" initials="G." surname="Salgueiro"/>
<author fullname="P. Jones" initials="P." surname="Jones"/>
<date month="November" year="2013"/>
<abstract>
<t>This document specifies the syntax of Uniform Resource Identifi
er (URI) schemes for the Traversal Using Relays around NAT (TURN) protocol. It d
efines two URI schemes to provision the TURN Resolution Mechanism (RFC 5928).</t
>
</abstract>
</front>
<seriesInfo name="RFC" value="7065"/>
<seriesInfo name="DOI" value="10.17487/RFC7065"/>
</reference>
<reference anchor="RFC8489">
<front>
<title>Session Traversal Utilities for NAT (STUN)</title>
<author fullname="M. Petit-Huguenin" initials="M." surname="Petit-Hu
guenin"/>
<author fullname="G. Salgueiro" initials="G." surname="Salgueiro"/>
<author fullname="J. Rosenberg" initials="J." surname="Rosenberg"/>
<author fullname="D. Wing" initials="D." surname="Wing"/>
<author fullname="R. Mahy" initials="R." surname="Mahy"/>
<author fullname="P. Matthews" initials="P." surname="Matthews"/>
<date month="February" year="2020"/>
<abstract>
<t>Session Traversal Utilities for NAT (STUN) is a protocol that s
erves as a tool for other protocols in dealing with NAT traversal. It can be use
d by an endpoint to determine the IP address and port allocated to it by a NAT.
It can also be used to check connectivity between two endpoints and as a keep-al
ive protocol to maintain NAT bindings. STUN works with many existing NATs and do
es not require any special behavior from them.</t>
<t>STUN is not a NAT traversal solution by itself. Rather, it is a
tool to be used in the context of a NAT traversal solution.</t>
<t>This document obsoletes RFC 5389.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8489"/>
<seriesInfo name="DOI" value="10.17487/RFC8489"/>
</reference>
<reference anchor="RFC6750">
<front>
<title>The OAuth 2.0 Authorization Framework: Bearer Token Usage</ti
tle>
<author fullname="M. Jones" initials="M." surname="Jones"/>
<author fullname="D. Hardt" initials="D." surname="Hardt"/>
<date month="October" year="2012"/>
<abstract>
<t>This specification describes how to use bearer tokens in HTTP r
equests to access OAuth 2.0 protected resources. Any party in possession of a be
arer token (a "bearer") can use it to get access to the associated resources (wi
thout demonstrating possession of a cryptographic key). To prevent misuse, beare
r tokens need to be protected from disclosure in storage and in transport. [STAN
DARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6750"/>
<seriesInfo name="DOI" value="10.17487/RFC6750"/>
</reference>
<reference anchor="RFC8725">
<front>
<title>JSON Web Token Best Current Practices</title>
<author fullname="Y. Sheffer" initials="Y." surname="Sheffer"/>
<author fullname="D. Hardt" initials="D." surname="Hardt"/>
<author fullname="M. Jones" initials="M." surname="Jones"/>
<date month="February" year="2020"/>
<abstract>
<t>JSON Web Tokens, also known as JWTs, are URL-safe JSON-based se
curity tokens that contain a set of claims that can be signed and/or encrypted.
JWTs are being widely used and deployed as a simple security token format in num
erous protocols and applications, both in the area of digital identity and in ot
her application areas. This Best Current Practices document updates RFC 7519 to
provide actionable guidance leading to secure implementation and deployment of J
WTs.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="225"/>
<seriesInfo name="RFC" value="8725"/>
<seriesInfo name="DOI" value="10.17487/RFC8725"/>
</reference>
<reference anchor="RFC8853">
<front>
<title>Using Simulcast in Session Description Protocol (SDP) and RTP
Sessions</title>
<author fullname="B. Burman" initials="B." surname="Burman"/>
<author fullname="M. Westerlund" initials="M." surname="Westerlund"/
>
<author fullname="S. Nandakumar" initials="S." surname="Nandakumar"/
>
<author fullname="M. Zanaty" initials="M." surname="Zanaty"/>
<date month="January" year="2021"/>
<abstract>
<t>In some application scenarios, it may be desirable to send mult
iple differently encoded versions of the same media source in different RTP stre
ams. This is called simulcast. This document describes how to accomplish simulca
st in RTP and how to signal it in the Session Description Protocol (SDP). The de
scribed solution uses an RTP/RTCP identification method to identify RTP streams
belonging to the same media source and makes an extension to SDP to indicate tha
t those RTP streams are different simulcast formats of that media source. The SD
P extension consists of a new media-level SDP attribute that expresses capabilit
y to send and/or receive simulcast RTP streams.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8853"/>
<seriesInfo name="DOI" value="10.17487/RFC8853"/>
</reference>
<reference anchor="RFC8826">
<front>
<title>Security Considerations for WebRTC</title>
<author fullname="E. Rescorla" initials="E." surname="Rescorla"/>
<date month="January" year="2021"/>
<abstract>
<t>WebRTC is a protocol suite for use with real-time applications
that can be deployed in browsers -- "real-time communication on the Web". This d
ocument defines the WebRTC threat model and analyzes the security threats of Web
RTC in that model.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8826"/>
<seriesInfo name="DOI" value="10.17487/RFC8826"/>
</reference>
<reference anchor="RFC8446">
<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.3</titl
e>
<author fullname="E. Rescorla" initials="E." surname="Rescorla"/>
<date month="August" year="2018"/>
<abstract>
<t>This document specifies version 1.3 of the Transport Layer Secu
rity (TLS) protocol. TLS allows client/server applications to communicate over t
he Internet in a way that is designed to prevent eavesdropping, tampering, and m
essage forgery.</t>
<t>This document updates RFCs 5705 and 6066, and obsoletes RFCs 50
77, 5246, and 6961. This document also specifies new requirements for TLS 1.2 im
plementations.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8446"/>
<seriesInfo name="DOI" value="10.17487/RFC8446"/>
</reference>
<reference anchor="RFC9147">
<front>
<title>The Datagram Transport Layer Security (DTLS) Protocol Version
1.3</title>
<author fullname="E. Rescorla" initials="E." surname="Rescorla"/>
<author fullname="H. Tschofenig" initials="H." surname="Tschofenig"/
>
<author fullname="N. Modadugu" initials="N." surname="Modadugu"/>
<date month="April" year="2022"/>
<abstract>
<t>This document specifies version 1.3 of the Datagram Transport L
ayer Security (DTLS) protocol. DTLS 1.3 allows client/server applications to com
municate over the Internet in a way that is designed to prevent eavesdropping, t
ampering, and message forgery.</t>
<t>The DTLS 1.3 protocol is based on the Transport Layer Security
(TLS) 1.3 protocol and provides equivalent security guarantees with the exceptio
n of order protection / non-replayability. Datagram semantics of the underlying
transport are preserved by the DTLS protocol.</t>
<t>This document obsoletes RFC 6347.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9147"/>
<seriesInfo name="DOI" value="10.17487/RFC9147"/>
</reference>
<reference anchor="RFC9112">
<front>
<title>HTTP/1.1</title>
<author fullname="R. Fielding" initials="R." role="editor" surname="
Fielding"/>
<author fullname="M. Nottingham" initials="M." role="editor" surname
="Nottingham"/>
<author fullname="J. Reschke" initials="J." role="editor" surname="R
eschke"/>
<date month="June" year="2022"/>
<abstract>
<t>The Hypertext Transfer Protocol (HTTP) is a stateless applicati
on-level protocol for distributed, collaborative, hypertext information systems.
This document specifies the HTTP/1.1 message syntax, message parsing, connectio
n management, and related security concerns.</t>
<t>This document obsoletes portions of RFC 7230.</t>
</abstract>
</front>
<seriesInfo name="STD" value="99"/>
<seriesInfo name="RFC" value="9112"/>
<seriesInfo name="DOI" value="10.17487/RFC9112"/>
</reference>
<reference anchor="RFC3986">
<front>
<title>Uniform Resource Identifier (URI): Generic Syntax</title>
<author fullname="T. Berners-Lee" initials="T." surname="Berners-Lee
"/>
<author fullname="R. Fielding" initials="R." surname="Fielding"/>
<author fullname="L. Masinter" initials="L." surname="Masinter"/>
<date month="January" year="2005"/>
<abstract>
<t>A Uniform Resource Identifier (URI) is a compact sequence of ch
aracters that identifies an abstract or physical resource. This specification de
fines the generic URI syntax and a process for resolving URI references that mig
ht be in relative form, along with guidelines and security considerations for th
e use of URIs on the Internet. The URI syntax defines a grammar that is a supers
et of all valid URIs, allowing an implementation to parse the common components
of a URI reference without knowing the scheme-specific requirements of every pos
sible identifier. This specification does not define a generative grammar for UR
Is; that task is performed by the individual specifications of each URI scheme.
[STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="STD" value="66"/>
<seriesInfo name="RFC" value="3986"/>
<seriesInfo name="DOI" value="10.17487/RFC3986"/>
</reference>
<reference anchor="RFC4086">
<front>
<title>Randomness Requirements for Security</title>
<author fullname="D. Eastlake 3rd" initials="D." surname="Eastlake 3
rd"/>
<author fullname="J. Schiller" initials="J." surname="Schiller"/>
<author fullname="S. Crocker" initials="S." surname="Crocker"/>
<date month="June" year="2005"/>
<abstract>
<t>Security systems are built on strong cryptographic algorithms t
hat foil pattern analysis attempts. However, the security of these systems is de
pendent on generating secret quantities for passwords, cryptographic keys, and s
imilar quantities. The use of pseudo-random processes to generate secret quantit
ies can result in pseudo-security. A sophisticated attacker may find it easier t
o reproduce the environment that produced the secret quantities and to search th
e resulting small set of possibilities than to locate the quantities in the whol
e of the potential number space.</t>
<t>Choosing random quantities to foil a resourceful and motivated
adversary is surprisingly difficult. This document points out many pitfalls in u
sing poor entropy sources or traditional pseudo-random number generation techniq
ues for generating such quantities. It recommends the use of truly random hardwa
re techniques and shows that the existing hardware on many systems can be used f
or this purpose. It provides suggestions to ameliorate the problem when a hardwa
re solution is not available, and it gives examples of how large such quantities
need to be for some applications. This document specifies an Internet Best Curr
ent Practices for the Internet Community, and requests discussion and suggestion
s for improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="106"/>
<seriesInfo name="RFC" value="4086"/>
<seriesInfo name="DOI" value="10.17487/RFC4086"/>
</reference>
<reference anchor="RFC9562">
<front>
<title>Universally Unique IDentifiers (UUIDs)</title>
<author fullname="K. Davis" initials="K." surname="Davis"/>
<author fullname="B. Peabody" initials="B." surname="Peabody"/>
<author fullname="P. Leach" initials="P." surname="Leach"/>
<date month="May" year="2024"/>
<abstract>
<t>This specification defines UUIDs (Universally Unique IDentifier
s) --
also known as GUIDs (Globally Unique IDentifiers) -- and a Uniform
Resource Name namespace for UUIDs. A UUID is 128 bits long and is
intended to guarantee uniqueness across space and time. UUIDs were
originally used in the Apollo Network Computing System (NCS), later
in the Open Software Foundation's (OSF's) Distributed Computing
Environment (DCE), and then in Microsoft Windows platforms.</t>
<t>This specification is derived from the OSF DCE specification wi
th the
kind permission of the OSF (now known as "The Open Group"). Information from ear
lier versions of the OSF DCE specification have
been incorporated into this document. This document obsoletes RFC
4122.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9562"/>
<seriesInfo name="DOI" value="10.17487/RFC9562"/>
</reference>
<reference anchor="RFC3553">
<front>
<title>An IETF URN Sub-namespace for Registered Protocol Parameters<
/title>
<author fullname="M. Mealling" initials="M." surname="Mealling"/>
<author fullname="L. Masinter" initials="L." surname="Masinter"/>
<author fullname="T. Hardie" initials="T." surname="Hardie"/>
<author fullname="G. Klyne" initials="G." surname="Klyne"/>
<date month="June" year="2003"/>
<abstract>
<t>This document describes a new sub-delegation for the 'ietf' URN
namespace for registered protocol items. The 'ietf' URN namespace is defined in
RFC 2648 as a root for persistent URIs that refer to IETF- defined resources. T
his document specifies an Internet Best Current Practices for the Internet Commu
nity, and requests discussion and suggestions for improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="73"/>
<seriesInfo name="RFC" value="3553"/>
<seriesInfo name="DOI" value="10.17487/RFC3553"/>
</reference> </reference>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
445.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
838.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
789.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
840.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
585.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
839.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
143.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
858.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
830.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
842.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
288.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
064.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
065.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
489.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
750.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
725.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
853.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
826.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
446.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
147.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
112.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
986.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
086.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
562.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
553.xml"/>
</references> </references>
<references anchor="sec-informative-references"> <references anchor="sec-informative-references">
<name>Informative References</name> <name>Informative References</name>
<reference anchor="RFC3261">
<front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
<title>SIP: Session Initiation Protocol</title> 261.xml"/>
<author fullname="J. Rosenberg" initials="J." surname="Rosenberg"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
<author fullname="H. Schulzrinne" initials="H." surname="Schulzrinne 120.xml"/>
"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
<author fullname="G. Camarillo" initials="G." surname="Camarillo"/> 826.xml"/>
<author fullname="A. Johnston" initials="A." surname="Johnston"/>
<author fullname="J. Peterson" initials="J." surname="Peterson"/>
<author fullname="R. Sparks" initials="R." surname="Sparks"/>
<author fullname="M. Handley" initials="M." surname="Handley"/>
<author fullname="E. Schooler" initials="E." surname="Schooler"/>
<date month="June" year="2002"/>
<abstract>
<t>This document describes Session Initiation Protocol (SIP), an a
pplication-layer control (signaling) protocol for creating, modifying, and termi
nating sessions with one or more participants. These sessions include Internet t
elephone calls, multimedia distribution, and multimedia conferences. [STANDARDS-
TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3261"/>
<seriesInfo name="DOI" value="10.17487/RFC3261"/>
</reference>
<reference anchor="RFC6120">
<front>
<title>Extensible Messaging and Presence Protocol (XMPP): Core</titl
e>
<author fullname="P. Saint-Andre" initials="P." surname="Saint-Andre
"/>
<date month="March" year="2011"/>
<abstract>
<t>The Extensible Messaging and Presence Protocol (XMPP) is an app
lication profile of the Extensible Markup Language (XML) that enables the near-r
eal-time exchange of structured yet extensible data between any two or more netw
ork entities. This document defines XMPP's core protocol methods: setup and tear
down of XML streams, channel encryption, authentication, error handling, and com
munication primitives for messaging, network availability ("presence"), and requ
est-response interactions. This document obsoletes RFC 3920. [STANDARDS-TRACK]</
t>
</abstract>
</front>
<seriesInfo name="RFC" value="6120"/>
<seriesInfo name="DOI" value="10.17487/RFC6120"/>
</reference>
<reference anchor="RFC7826">
<front>
<title>Real-Time Streaming Protocol Version 2.0</title>
<author fullname="H. Schulzrinne" initials="H." surname="Schulzrinne
"/>
<author fullname="A. Rao" initials="A." surname="Rao"/>
<author fullname="R. Lanphier" initials="R." surname="Lanphier"/>
<author fullname="M. Westerlund" initials="M." surname="Westerlund"/
>
<author fullname="M. Stiemerling" initials="M." role="editor" surnam
e="Stiemerling"/>
<date month="December" year="2016"/>
<abstract>
<t>This memorandum defines the Real-Time Streaming Protocol (RTSP)
version 2.0, which obsoletes RTSP version 1.0 defined in RFC 2326.</t>
<t>RTSP is an application-layer protocol for the setup and control
of the delivery of data with real-time properties. RTSP provides an extensible
framework to enable controlled, on-demand delivery of real-time data, such as au
dio and video. Sources of data can include both live data feeds and stored clips
. This protocol is intended to control multiple data delivery sessions; provide
a means for choosing delivery channels such as UDP, multicast UDP, and TCP; and
provide a means for choosing delivery mechanisms based upon RTP (RFC 3550).</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7826"/>
<seriesInfo name="DOI" value="10.17487/RFC7826"/>
</reference>
<referencegroup anchor="BCP56" target="https://www.rfc-editor.org/info/b cp56"> <referencegroup anchor="BCP56" target="https://www.rfc-editor.org/info/b cp56">
<reference anchor="RFC9205" target="https://www.rfc-editor.org/info/rf <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC
c9205"> .9205.xml"/>
<front>
<title>Building Protocols with HTTP</title>
<author fullname="M. Nottingham" initials="M." surname="Nottingham
"/>
<date month="June" year="2022"/>
<abstract>
<t>Applications often use HTTP as a substrate to create HTTP-bas
ed APIs. This document specifies best practices for writing specifications that
use HTTP to define new application protocols. It is written primarily to guide I
ETF efforts to define application protocols using HTTP for deployment on the Int
ernet but might be applicable in other situations.</t>
<t>This document obsoletes RFC 3205.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="56"/>
<seriesInfo name="RFC" value="9205"/>
<seriesInfo name="DOI" value="10.17487/RFC9205"/>
</reference>
</referencegroup> </referencegroup>
<reference anchor="RFC9457"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
457.xml"/>
<reference anchor="HTML" target="https://html.spec.whatwg.org/">
<front> <front>
<title>Problem Details for HTTP APIs</title> <title>HTML</title>
<author fullname="M. Nottingham" initials="M." surname="Nottingham"/ <author>
> <organization>WHATWG</organization>
<author fullname="E. Wilde" initials="E." surname="Wilde"/> </author>
<author fullname="S. Dalal" initials="S." surname="Dalal"/>
<date month="July" year="2023"/>
<abstract>
<t>This document defines a "problem detail" to carry machine-reada
ble details of errors in HTTP response content to avoid the need to define new e
rror response formats for HTTP APIs.</t>
<t>This document obsoletes RFC 7807.</t>
</abstract>
</front> </front>
<seriesInfo name="RFC" value="9457"/> <refcontent>WHATWG Living Standard</refcontent>
<seriesInfo name="DOI" value="10.17487/RFC9457"/> <annotation>Commit snapshot: <eref target="https://html.spec.whatwg.or
g/commit-snapshots/09db56ba9343c597340b2c7715f43ff9b10826f6/" brackets="angle"/>
.</annotation>
</reference> </reference>
<reference anchor="W3C.REC-webrtc-20210126" target="https://www.w3.org/T
R/2021/REC-webrtc-20210126/"> <reference anchor="W3C.REC-webrtc-20250313" target="https://www.w3.org/T
R/2025/REC-webrtc-20250313/">
<front> <front>
<title>WebRTC 1.0: Real-Time Communication Between Browsers</title> <title>WebRTC: Real-Time Communication in Browsers</title>
<author fullname="Cullen Jennings" role="editor"/> <author fullname="Cullen Jennings" role="editor"/>
<author fullname="Florent Castelli" role="editor"/>
<author fullname="Henrik Boström" role="editor"/> <author fullname="Henrik Boström" role="editor"/>
<author fullname="Jan-Ivar Bruaroey" role="editor"/> <author fullname="Jan-Ivar Bruaroey" role="editor"/>
<date day="26" month="January" year="2021"/> <date day="13" month="March" year="2025"/>
</front>
<seriesInfo name="W3C REC" value="REC-webrtc-20210126"/>
<seriesInfo name="W3C" value="REC-webrtc-20210126"/>
</reference>
<reference anchor="RFC8836">
<front>
<title>Congestion Control Requirements for Interactive Real-Time Med
ia</title>
<author fullname="R. Jesup" initials="R." surname="Jesup"/>
<author fullname="Z. Sarker" initials="Z." role="editor" surname="Sa
rker"/>
<date month="January" year="2021"/>
<abstract>
<t>Congestion control is needed for all data transported across th
e Internet, in order to promote fair usage and prevent congestion collapse. The
requirements for interactive, point-to-point real-time multimedia, which needs l
ow-delay, semi-reliable data delivery, are different from the requirements for b
ulk transfer like FTP or bursty transfers like web pages. Due to an increasing a
mount of RTP-based real-time media traffic on the Internet (e.g., with the intro
duction of the Web Real-Time Communication (WebRTC)), it is especially important
to ensure that this kind of traffic is congestion controlled.</t>
<t>This document describes a set of requirements that can be used
to evaluate other congestion control mechanisms in order to figure out their fit
ness for this purpose, and in particular to provide a set of possible requiremen
ts for a real-time media congestion avoidance technique.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8836"/>
<seriesInfo name="DOI" value="10.17487/RFC8836"/>
</reference>
<reference anchor="RFC8141">
<front>
<title>Uniform Resource Names (URNs)</title>
<author fullname="P. Saint-Andre" initials="P." surname="Saint-Andre
"/>
<author fullname="J. Klensin" initials="J." surname="Klensin"/>
<date month="April" year="2017"/>
<abstract>
<t>A Uniform Resource Name (URN) is a Uniform Resource Identifier
(URI) that is assigned under the "urn" URI scheme and a particular URN namespace
, with the intent that the URN will be a persistent, location-independent resour
ce identifier. With regard to URN syntax, this document defines the canonical sy
ntax for URNs (in a way that is consistent with URI syntax), specifies methods f
or determining URN-equivalence, and discusses URI conformance. With regard to UR
N namespaces, this document specifies a method for defining a URN namespace and
associating it with a namespace identifier, and it describes procedures for regi
stering namespace identifiers with the Internet Assigned Numbers Authority (IANA
). This document obsoletes both RFCs 2141 and 3406.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8141"/>
<seriesInfo name="DOI" value="10.17487/RFC8141"/>
</reference>
<reference anchor="RFC8126">
<front>
<title>Guidelines for Writing an IANA Considerations Section in RFCs
</title>
<author fullname="M. Cotton" initials="M." surname="Cotton"/>
<author fullname="B. Leiba" initials="B." surname="Leiba"/>
<author fullname="T. Narten" initials="T." surname="Narten"/>
<date month="June" year="2017"/>
<abstract>
<t>Many protocols make use of points of extensibility that use con
stants to identify various protocol parameters. To ensure that the values in the
se fields do not have conflicting uses and to promote interoperability, their al
locations are often coordinated by a central record keeper. For IETF protocols,
that role is filled by the Internet Assigned Numbers Authority (IANA).</t>
<t>To make assignments in a given registry prudently, guidance des
cribing the conditions under which new values should be assigned, as well as whe
n and how modifications to existing values can be made, is needed. This document
defines a framework for the documentation of these guidelines by specification
authors, in order to assure that the provided guidance for the IANA Consideratio
ns is clear and addresses the various issues that are likely in the operation of
a registry.</t>
<t>This is the third edition of this document; it obsoletes RFC 52
26.</t>
</abstract>
</front> </front>
<seriesInfo name="BCP" value="26"/> <refcontent>W3C Recommendation</refcontent>
<seriesInfo name="RFC" value="8126"/> <annotation>Latest version available at: <eref target="https://www.w3.
<seriesInfo name="DOI" value="10.17487/RFC8126"/> org/TR/webrtc/" brackets="angle"/>.</annotation>
</reference> </reference>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
836.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
126.xml"/>
<referencegroup anchor="BCP9" target="https://www.rfc-editor.org/info/bc p9"> <referencegroup anchor="BCP9" target="https://www.rfc-editor.org/info/bc p9">
<reference anchor="RFC2026" target="https://www.rfc-editor.org/info/rf <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC
c2026"> .2026.xml"/>
<front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC
<title>The Internet Standards Process -- Revision 3</title> .5657.xml"/>
<author fullname="S. Bradner" initials="S." surname="Bradner"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC
<date month="October" year="1996"/> .6410.xml"/>
<abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC
<t>This memo documents the process used by the Internet communit .7100.xml"/>
y for the standardization of protocols and procedures. It defines the stages in <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC
the standardization process, the requirements for moving a document between stag .7127.xml"/>
es and the types of documents used during this process. This document specifies <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC
an Internet Best Current Practices for the Internet Community, and requests disc .7475.xml"/>
ussion and suggestions for improvements.</t> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC
</abstract> .8789.xml"/>
</front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC
<seriesInfo name="BCP" value="9"/> .9282.xml"/>
<seriesInfo name="RFC" value="2026"/>
<seriesInfo name="DOI" value="10.17487/RFC2026"/>
</reference>
<reference anchor="RFC5657" target="https://www.rfc-editor.org/info/rf
c5657">
<front>
<title>Guidance on Interoperation and Implementation Reports for A
dvancement to Draft Standard</title>
<author fullname="L. Dusseault" initials="L." surname="Dusseault"/
>
<author fullname="R. Sparks" initials="R." surname="Sparks"/>
<date month="September" year="2009"/>
<abstract>
<t>Advancing a protocol to Draft Standard requires documentation
of the interoperation and implementation of the protocol. Historic reports have
varied widely in form and level of content and there is little guidance availab
le to new report preparers. This document updates the existing processes and pro
vides more detail on what is appropriate in an interoperability and implementati
on report. This document specifies an Internet Best Current Practices for the In
ternet Community, and requests discussion and suggestions for improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="9"/>
<seriesInfo name="RFC" value="5657"/>
<seriesInfo name="DOI" value="10.17487/RFC5657"/>
</reference>
<reference anchor="RFC6410" target="https://www.rfc-editor.org/info/rf
c6410">
<front>
<title>Reducing the Standards Track to Two Maturity Levels</title>
<author fullname="R. Housley" initials="R." surname="Housley"/>
<author fullname="D. Crocker" initials="D." surname="Crocker"/>
<author fullname="E. Burger" initials="E." surname="Burger"/>
<date month="October" year="2011"/>
<abstract>
<t>This document updates the Internet Engineering Task Force (IE
TF) Standards Process defined in RFC 2026. Primarily, it reduces the Standards P
rocess from three Standards Track maturity levels to two. This memo documents an
Internet Best Current Practice.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="9"/>
<seriesInfo name="RFC" value="6410"/>
<seriesInfo name="DOI" value="10.17487/RFC6410"/>
</reference>
<reference anchor="RFC7100" target="https://www.rfc-editor.org/info/rf
c7100">
<front>
<title>Retirement of the "Internet Official Protocol Standards" Su
mmary Document</title>
<author fullname="P. Resnick" initials="P." surname="Resnick"/>
<date month="December" year="2013"/>
<abstract>
<t>This document updates RFC 2026 to no longer use STD 1 as a su
mmary of "Internet Official Protocol Standards". It obsoletes RFC 5000 and reque
sts the IESG to move RFC 5000 (and therefore STD 1) to Historic status.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="9"/>
<seriesInfo name="RFC" value="7100"/>
<seriesInfo name="DOI" value="10.17487/RFC7100"/>
</reference>
<reference anchor="RFC7127" target="https://www.rfc-editor.org/info/rf
c7127">
<front>
<title>Characterization of Proposed Standards</title>
<author fullname="O. Kolkman" initials="O." surname="Kolkman"/>
<author fullname="S. Bradner" initials="S." surname="Bradner"/>
<author fullname="S. Turner" initials="S." surname="Turner"/>
<date month="January" year="2014"/>
<abstract>
<t>RFC 2026 describes the review performed by the Internet Engin
eering Steering Group (IESG) on IETF Proposed Standard RFCs and characterizes th
e maturity level of those documents. This document updates RFC 2026 by providing
a current and more accurate characterization of Proposed Standards.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="9"/>
<seriesInfo name="RFC" value="7127"/>
<seriesInfo name="DOI" value="10.17487/RFC7127"/>
</reference>
<reference anchor="RFC7475" target="https://www.rfc-editor.org/info/rf
c7475">
<front>
<title>Increasing the Number of Area Directors in an IETF Area</ti
tle>
<author fullname="S. Dawkins" initials="S." surname="Dawkins"/>
<date month="March" year="2015"/>
<abstract>
<t>This document removes a limit on the number of Area Directors
who manage an Area in the definition of "IETF Area". This document updates RFC
2026 (BCP 9) and RFC 2418 (BCP 25).</t>
</abstract>
</front>
<seriesInfo name="BCP" value="9"/>
<seriesInfo name="RFC" value="7475"/>
<seriesInfo name="DOI" value="10.17487/RFC7475"/>
</reference>
<reference anchor="RFC8789" target="https://www.rfc-editor.org/info/rf
c8789">
<front>
<title>IETF Stream Documents Require IETF Rough Consensus</title>
<author fullname="J. Halpern" initials="J." role="editor" surname=
"Halpern"/>
<author fullname="E. Rescorla" initials="E." role="editor" surname
="Rescorla"/>
<date month="June" year="2020"/>
<abstract>
<t>This document requires that the IETF never publish any IETF S
tream RFCs without IETF rough consensus. This updates RFC 2026.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="9"/>
<seriesInfo name="RFC" value="8789"/>
<seriesInfo name="DOI" value="10.17487/RFC8789"/>
</reference>
<reference anchor="RFC9282" target="https://www.rfc-editor.org/info/rf
c9282">
<front>
<title>Responsibility Change for the RFC Series</title>
<author fullname="B. Rosen" initials="B." surname="Rosen"/>
<date month="June" year="2022"/>
<abstract>
<t>In RFC 9280, responsibility for the RFC Series moved to the R
FC Series Working Group and the RFC Series Approval Board. It is no longer the r
esponsibility of the RFC Editor, and the role of the IAB in the RFC Series is al
tered. Accordingly, in Section 2.1 of RFC 2026, the sentence "RFC publication is
the direct responsibility of the RFC Editor, under the general direction of the
IAB" is deleted.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="9"/>
<seriesInfo name="RFC" value="9282"/>
<seriesInfo name="DOI" value="10.17487/RFC9282"/>
</reference>
</referencegroup> </referencegroup>
</references> </references>
</references> </references>
<section anchor="acknowledgements" numbered="false">
<name>Acknowledgements</name>
<t>The authors wish to thank <contact fullname="Lorenzo Miniero"/>,
<contact fullname="Juliusz Chroboczek"/>, <contact fullname="Adam
Roach"/>, <contact fullname="Nils Ohlmeier"/>, <contact
fullname="Christer Holmberg"/>, <contact fullname="Cameron Elliott"/>,
<contact fullname="Gustavo Garcia"/>, <contact fullname="Jonas Birme"/>,
<contact fullname="Sandro Gauci"/>, <contact fullname="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.</t>
</section>
</back> </back>
<!-- ##markdown-source:
H4sIAAAAAAAAA+1923LbSJLoO7+iDv0w0jZJkRR144ynl5bkbs36opHk6Z7Y
2DgBAiCJMQlwAVAy2+39lvMt58tO3uoGgJLc3Tuzu3E8EdM2CFRlZWXlPbO6
3W4rysI0WMVjFeXBrOwmcTnrPiTFovuwSNbdwXGrTMol/PxDPL25O+9+f3d3
rZJ0HhdlkqVqnWdlFmZLtffD91fX+61gOs3j+7HCj1thUMbzLN+OVVFGrWSd
j1WZb4py2O+f9YetII+DsZrc3LUesvzjPM82a/gQpm5t1hF8WozV6elo2MH/
77daH+MtvBdpSFqtogzS6H8HyywF8LZx0VonY/WvAE5HFVle5vGsgL9tV/iX
f2u1gk25yPJxS3VbCv4kKYx/21NvN3myXGb0jBFxG+fzJFPfBXmYBN7vWT4P
0uSnAJc+Vm/heRIGRUm/xasgWcJK6ePenD7urfjjfw6zYpUV2ax8gEX3kswD
YtJT32Ub+HoZ5JEDx2QZf4IV5nH1Zx+M8+z2baZuZXAXlgAG6M3Nt3UoWmmW
r2CY+xjQol5f3p1/P6YBDK6UzAdY/35y98N39EQo4nVchgvVVW+SeyAIdYvb
oUEsg3wel2O1KMt1MT44mOG7vWIdh72HRVA+zHswqAzf6na7KpgWZR6EZat1
t0gKBVS5WcVpqaK4CPNkGhcqUEWyWi9jhSTYnQZFHFnyK2FQoJ3lEha9zB40
tfJbllyzmQqztMSBk7TMgC6BBlcIPezbfRLiNGl0kOXq/OJd0asCI3Spbl6f
E2niy/offXgbF7JKomgZt1ov1FVa5lm0CXFmHClWV5d3rxXA9cPlK4U0jxMT
3atCkJf8BPD+6fbyWu19/vy/YOiz0fDsy5f9Dix/FYcL2PdipTa4KgAf15LT
6mNYQLlZd9QqSIN5jNB2CLoyhlGzB1o6DLFZlskqjoCui7goALCeuioBZ0Xm
YHoBCITRUzi8ZQILVvzFDBBbwNwINc74fjaL84NJWjzEuXqbRfESdqBc0G+3
PLq6oEHXhPxrwytuL673Fa/vcHg8+vIFdiNcbiI98ozIssD/KsA4AgvYz+5h
Hvz5IYEzsRf35r2OgFZu1zEc9hCACNU6yOH8lHFeMAriNMy3BMJ+TwgDdx+G
hEdALlvYYFh1mpUKCTSZbYnW5vAbAZQHabEGhmKpDWgtWK/x8NPClvF9vITt
/5ACwOUmBZQttx0CdRmEHxn13g7b0e2mJqkGbhEUahrHKUCvMjgXQQhUDxsS
RBljMkAybeLCiH8YB2ee5lkQIXc6sESepBGw3xxge1jEgMNADgBAwodJqFWt
k3WMDxVQfxl8BFBwK+aAiTIGDrxebnAwFQbTJWAuDPJ8i+PnwYPekAxWkUfI
aBD/sC+4GwAXjL0pmEb4eWS/CNJt/UQqPIxyZi8AKCCCrXoXl3h+1B4c031B
hFBmI2Jgc35YJIBFwXAIb01jogJYFKyJKVfvkbM/eoRCLZOPQNdX10C43zLh
DoBwAbof317rh8eDYf/LF1ooEBGsHYkKDhYMxycWJt0wS7IbBNMc1BmRHF/a
J9gFOqJpRpARQWlaoO0OSrO3PWAwtxqek9PhMcID4hhYNQzDDBE+u7m77jh0
v1kThdPRvbiGCfBoB3y0V3S0veOK1KDZgz60QMfIwOM8gSWFBQKJj31uU+Wo
gN51Vrjc3dCyAZVUDpxRoMQJZR/hIPD4dsvh5C+yiFc8BpasrgoVB8UWsU8z
EG/k54H9CXYF/7nO1huQlepKSxizS5YS+NvZBjlHmMGQCRwLJiANFooFZvPI
UfCLy5TPiiOLgAQy+CZcBoCbMFjKUtbLoEQGSKJIjxinUbfMuvAf+ztQSLhI
4nu9AcCe8RgAPosE5gLeA4cm3PZg9jfwU17QW3n87xvgn4iFwsBQO6s0t0uh
VkCi2BRyYeB6jJBNgSvk8YAoH+IpDvBQ6NHgGZ8vVNjMRD2UlHdxDrSfLbP5
lgUl6HooIKNCtd9+uL1rd/i/6t17+vvN5Z8/XN1cXuDfb7+fvHlj/tKSN26/
f//hzYX9m/3y/P3bt5fvLvhjeKq8R63228lf23z22u+v767ev5u8afMhc+kW
ccXHGXlIvs5jZCJB0dJSlNb76vz6//6fwUjOznAwAFEu/zgdnOBBAj6c8mxZ
CuTE/0Tu0QIBA6IbRwERBQxrnZTAAzpIpMUCBTpyBsDeP/0rYubfxuoP03A9
GP1RHuCCvYcaZ95Dwln9Se1jRmLDo4ZpDDa95xVM+/BO/ur9W+PdefiHb0kc
dQen3/6xhSTz/h7pMX5genGNkyuWBte+ZYLMz2XEsyBMloDSEqUgEGQX9SIV
f0JpPI+ReT1DhSE2ydTNvFKrRwTI9XvYBjxuAE7RU8T4zATI0oGHwHFAeoLD
X5TxGncbXoZzBFaQCLMrpC/gqyD4UA6mMf41KbfqUr9IBLl3dX65T5BcgMIE
Qm2l7ozi8ibYAh+/jUMwR+DLvYu7N7f7micDEZcPqG0gd0BcAUdKSH9kqZHH
QN0FsQsrtXMUfMKvSG2IcyOwDMvP7/Gpp4ywFqJZILCzdQYHCHWnNfy72ITA
YQpgrRYNtDqRJbDGA4Rdg95RmzSJgJuFrMrJzKQyktq2SniJwKZhHOReszxb
VVeK9FCFm/Ri2CQQGYDBgF8CURmztEUhmcdGBGZpYcS9MEfmADgLKqmg4hGX
hk9BiINETWaiPRZ69vbqZRsmD/mhaCirIAICnZWi+SZpAvMt6zLa0NU9rMBS
HyyAJBRzJ81lAI0A/DJgGFnZJizxnGzlRM5QEzAMDSUjB4riGamMsMLPn0Eq
dGXRX770+EDOMjTDcM2AUqJGsM1QPyH7idSFDPCVrYG2tWVmdsWoACj0eckl
nwa0Z1BU6H9r1U/oAeT9f+AfMSx/sz8t9U3X/fMNPvQf4cNvnnjQ/aalfvYI
72ccSB7pwwD//lm9JVK8JVKkB/SKPrHqZ4LoG3cuD6JvfAC+MW+ZV342EBEE
u/78/Og/3Ue/8UCWhpHVsq25/wsGqm6B+fPHb74SomF/oM5BS8ejQTDx0dv/
aoj+sAukr4XIPscTjQL+EvC1+6udEO0C6AmUPQ3R7fX7d7eXXw/Rzztx9DjK
HoOIBMft5d2H6/o3z4Ho5bP+/PErdg1ssANQW67V6zfvf/hqiHbT0VfvGh22
i8s3l3cNe/Xon19ER48BKRAN+331/l++Epg6RM8lo6Y/n9yBfsM/IqI+j9mP
+rLtsXZy43meu7Z6Qa54LRW7Rmh+YVkbL8WaI2m8690vpKBY8yQoREgXZCU7
UmnMqmpF7xNDlHUkRwm06h+ri6DTigqDXiot6BrF+3TLA2nZHrF7h91i2icE
cKyysqKcaYC1zBSQoxg1tEJUJdEMcnYbguYFemIMExSeKkXjiG5TG1d9uHkz
Vjcxqfmip8EjbznmXcAWKLFse6PmEqKw0Ma5u8k4zVtnOQJ90oBoAR9Hg6HB
9sxr03gGQ83jYl2yrt6B2GZs+B8Z53ip97UwONE6lgCbRqjACjIFTFBBo6Ue
ER3xIUlLYi8AdrbJwxh3vY47XAh6O9N5Zk0EF1/eIXnGrpjpLBi7Jxa/bxJW
vFXqroI31JCLmJAnyrBM74GnXeSAJgSrFIV/K6gS0wWMnQWeEZSU5pgWuNVG
x0UQ+Iw/dq7rmvVqBXaROKfRa29MvMA38DxUdCp2G3mfXKrljafxsk2J9jjP
B0Ch1YboB+5FFO+wMLIB0F/hOWarqKqwhg68ep8tiTodI6tDyMIt0w7gSRTl
ODfZukte8d67yd0+2n+wjCKAsUjyIzxkAcdAOcGS7X1rIjuWPYjlffY3isHc
EYeeSOuZMX1NaKDOQq/YbGncEiBEJCIxYaymS0cVnhiF16MuayzXmN8NsYSo
kBFU29FV2wBrUQTzmA53kKQyrdVgez7stNiVx56Mq4EcErAF5GdwDHEO1QDe
LdrpnYIR7i0fp7OaD1DT+PENIdw3vHAuwS/zIsenyIup4YVTX9kt7RF4rh+g
I2sw7APJA+l0lizjXnXXb2PcBb2polHhqHKi40ZZ4LPXhs1EXagtAb9Zkq9c
RuJxC3KNGYS810wCnr5gkDZECZ9fYFy2S/8AJeK1MdY/f/721fn10TFwlfkm
iSgGVHTcNRZKexfVKsD4b5znJJ1AswCuWG7ydAerLUTqMF8uWLgbxivDBOiH
17IlMn5X/ZrwxDo8U2D0U46SkRAivq+DdPgDUES5KQTOeR6EMTvwZ/AernyK
gTrZ/3mcghYSqhQQX8SrINXxjEDNQX9I3cHQhb5JP6bI4RxU9B5fe5htlhHu
5n0MIACS8y7ARC4VHsR1y0wxHgkUB8tY0dSk7qm/Feg2mf4tDkslMT9RDWJz
5KdZtNVicRYAxRrJRcEO4DAcJzobHZ0Y300D5OaY4+nK8mSOznw6H3V30C27
sNRh77iHc1MUezDoA015+oH1J6UUe7xPiCPqNTBLwRc3Kaiay63xqxo0okTK
irjyFKQN+eEWwIgopGgUWUanA2ydtjB1ZBfpGiQQxTGtw84Mf/wRZTn7LZd2
D+j4ppnRqdC3D69/d2mcwoq0bNJJox6d0StP70FxCqK01bqCjc4jlgf8rFGa
dmoMjSAlciZHd2odhyoIQxiTNoNXTFkH+WYpmKcJWEWWDwp/f496w97AbDCl
KfBWxjnSri/aalSnRznrHfYOK2QiABGzmxPvrSnlQqr1CWjFvPUG85gdgFO0
naD9QRGt2wSviEU/9omAkuMaDpCjBhoQGhErvtivwKz+oobaw0bUGprzBbxP
cs9Yd8cs1gKgV8vKTqDeZKKtLOIASW+WxMCyaPXO0tL4AaOg4hbz1cUr5jt2
j5q0GUp2qIAMujJsAf0TOEbDtgljwAXAEVoFSyS4OOo0DC9nlbhk2UgxWuuC
WfJsTfkuIzjSzIc1alEPnxQNNiw51MX77RqerNwCEQd6X5pCFfUTK2E1/LSN
SiKOD3RalmC1b8pY1QgVnqq3k7/SFxRGwK9gmnv/qwJ0cUBQGzQFiiUx7bfx
xcoUjoSXbIWdB4CgbBjChVJ0TOWrGbCNXR2zgL8EGKNAU4aUJ/k3SVyXiVAW
ECluQVVtCyrg6VDUjoPia3/mK0dDxh+rR+D5xG8CEQT3AdpuB2YWXNDBoDdo
fZ8VJadK9mTJPdCUW5Lt0r2DszBWFeI3v76J03m5GCtgmYNW6/5lv5W97Kqj
4fD06Oyof3g6GJyeHQ76o4Eaqqt36up6pAbDk14f/jdoFS+7rfJlX/VbwUtO
vHz14d3Fm0vVVwN4FH8qV8G6S6l03VXyKY7gIYZ5OOekGMM+hx9hh+DZsLV6
GWyiJFNn6sPF9QFYBQeo3t9O/nL9GqAbtMKXMn+fZsc58zJcj89U7TnOsZnl
wXx8WUwe5MH6IRpPr7/58U9v3/bPgpvTSfLj4G/R5uNPN8d/hVdmeODydY6W
ULEIusOjY3UxGZ+8Gh+djC/Ox8PT8fnluD8aj16PDwfjk7Px6dH4fIR/Pz4Z
X74aD0/GR6fj4dn48mJ8cjIeTsb9i/FwNJ5c4pPJxfiwP351Pn51MX49GJ+d
jzF19SX56cZwltZBUcC/V0k07hvUjUcKGPUYk2nHlI5WjHNQuBdwMD8BlKAg
juEDGoaPOI5QwBDR6Hg2PRsOu9HRMOiO4rOwGwSnJ93RaAQ0GA6OhoOpCuPD
4XEczrpB/3TQHR0dBt3T2dms2z/uH0VH8Ww0GJ4KkrurzSfnr12ZC4BBKGF3
VLbeFAej036/f4Drmq1Kfg42xRotrpeD/u/hnCfpFM7ULA5fDmDDQVeLMyCW
+oafHauzE8EHktJ0g9q4nvcrsSOvD/pPvo//5hyqrvfl4Okv43UAbDnqVof4
RVtzeHZ0PB0d97uj/mzUHUX9oy6aGt3+YTANo+g0PJ5FFv+ArL9cnx6cAfL1
qejOpvg4DFcgcXP/IbDuj/UnCviDM+SJystPZkjaTngWrMuXZ8etluY9yuGL
rcs7OHCq/Wn700/b9teyn/7RYUszSpvvW2VqB8IYDwC1hlkNjo9OTs4ORwDs
4EwNfjs2tUzK+O/OsQ5Pi2g2mkXF7GjkcK5hPDiMonhwEg7Cab9/NuwPZ8fD
k1kwPeuH0zg8PDqNTo6Po/7oLDw7prPTxNFeE6t6fTg+vBxPzscXw/HlZDw5
GZ8PxpfnyNQuzsavDsenk/Hh0RjZX398eowsb3SMPw0vxufwFTGyU+Bir4n3
AUMcjYeXwNpg1hDOd4KR//EA9gIQo4aDw/5J/3h0CA/OTntHQDd92BYg8sHh
EFU1BeZXaZghckLQLH45M9SaxD+WdzVs/n9/Zuah9h/De6phr0ur5e1OZ4kw
VxATUVxFsK1eNOqPrdb7NKSsZrGf0bonc7lD4RNWH+NikaLL2JiiaGSdHJ8c
gf7J2W86SbfEpPgSLYc0S7vaaQTmSRFKIhZ7Z8juR7eoyS/VKUHaTWqy8Nmt
XHPcUSgswWRfBaIG0/ruMkACsl5A1tbxHwaenrnD4q+a4OKI1BZPU8wCAxXG
fSfqe7MJKO4kbcKaXekpyuHyw0oN03fqk1PhxjSmUN+9ZCqJP0t8OrBtnAzc
kF/mZARJkljdPw0YnfghNS+RyEBC6OO4qI1tRJs8rjs/tH0upMPJSiuao0TQ
7zX2uOgEqa/ZwUZz6pRazn28td4xHPY8z4qi+579bjc6snW74OjK3vn7m9v9
mh+Oynm+fGHjzTiRjQkk+faV+bT9yfUY5NloT8IwXpfda+D1bU0K4mmw1Rfq
PlhudnlZzEn74fC8d3N53l3C8QUN5Kg/xPx08X3BvmksfH7hJpW1Wvib5M2e
jo7EUHTqMTgKZDLRKeXtE9BnTG5bLy7RoWgEme0YfN5geiWjjDIt07ishCvw
80ItEvRCKrbgq/Ecia5FMWdIo5PRuDAw+rgEU5HiVUUH07MRTmBdy2WMrgLa
4dwEOBzsFT2Od5lUVWRnwWqJ3Ct0U0GRe8CSM/KRAsNapAnuJjEwZFZI73gk
bEVPPJsBa6GQpreUdVAuCgo6ir7kYv7wFAseULImP5nAlgOGDgQCOEA/nGNO
9TWFUOo6o6obwEfDrB1AQrQJ8T3JXGdXlFk+/vLvGwArzv30UISX8o3wKbph
0Esd5jBWwDmEKzDqtWHvQQy7Hm3TYIXOfokowu9RYkKxgL58wypkh0vLKJ4Z
m1T4HMSPiY41rIpOSrYpTR6mnzaq04LTgngMcKRkBUALAsTpt0wohGFppBJP
8zYLP+EET0KGOVKIEycBm/BCufouJ2aRJZEVOpYvGlJA/SjSGsNAJpZUjZij
a0qLo9IBE2Z3oCwaY6LenJ64Pjo5PbOO4qog62j2ROGPetgT1XUKodBrDg/z
WJdA2yVOFK3xI2JlEi/QbFaYEvqtTR0Uy65lfI95w6QY2HBOxS9Ka2xax1f6
RRuhdfykZs07HKaeAKz5SwnK5zlKW3AWZ/VxjYtU1Jy73bTQIZ8mhnCQPjuY
jOJHXNqj4VB9SIXd0NkQs7RdgcbEkJrymCknqJ61XQtRDI56IO4HfpBCJ2ZU
aZ2yQ5DhLgFNthSgMnOGJQcVd/k5AgwvpCUWD5JH3gS3Kt+vgi2rSxw7wnSM
bjbrcozIjb0aNTGZ7dgOH/FJLbKBbmuYFevyMlgNsu9y2y2DuQI9Ff4x27p6
lx6+hsPT3mk1zAPbHOO3utpDZUgYDwk62+8cBdMoFlx9sHN+/b4Lh44Nu5ot
UDA6PHylVjTeHe5iOZ96Bi980Jyi0fJC1LZWhlzmziJgcWhzkxKM8UGKqYtK
qkPj7oISrteTIq7IZhFRJphYVDSSmzffZAA4FoUhQV8UEPKSeYqJ+qgq+mAj
TSDRu+Qm54Dmd6E2q6qBz5GvHZYCoPFtwmodrA6InOsScPfMZ5WTQY59D/fa
tmDLknMTKiKvduAPe4Ne5byTYHSC2/rX46PTI6qwlGSN0fBUXcPB1FoEKCW8
1rbPlEB3lqUxWhWgVYfe2qPB0B/kNcXua0OgWWpwa8cRwe2pcC8cAQFi+iJe
i7QVm8p9WasMWUNNkHsOJABVJwBkhFOhD1u8YszkeYAnXejB6EUmUZHeA32K
skbxfeOZAg6FRhZPQCq8Dt6ylm1fVHt4Hu65hhp0Y0CMHtG+tO8rFWxa9NRr
kRnrTY61qfiN0Uw5PReVsKLDdM4ZbC76doT0SDLUgsxFJuxSqjY7rr4ispIW
B4tlvMVRBSmKY8q7Vtmr5A+gk0InI9p8u5rAhgFILlIlNFpYiQQuK5O7/E8n
kJktd0LMpqidDOGGiCL7XniNlL2jhYozmRbnniU/jWfIovhsuHF3AcdokA7+
BSie080AeIT4qhXNnInshYVlxjSOI8IM5gU1+1qCosjCxJaeVyVo4qV8EFvw
9WGHTNL4oXZOtCR/CBJe+XTDJJc6dOSsDezgZNkgA3VuzdOC0EtmcSkO65Id
LQwscTQ+ddpPqA13NGy0YHj0DGGpeDrHFK/5PI/nNsXYRxBzZKEjXn3D0UGH
oZc65S1jYsgedbJk5tssqDtavbFR73qaMhyp+p9NE0VmyILaCXwdbSSVBHqf
MgzAOHFNUxC6WWIdvQ+y2Ia62NWit6pDiUrqORZ5KLLybOcR19ihunP4uNhM
Rbd2Sa6mCXjeP8kFNGmQzVluo95IqwJiBVo5ZvId0P0Hw0iK97jVUl01cUUP
5/h0WKatuqYKFDnwKsg/slnihB8oE114ZcM2c5oiGTh0pFfBpy5/3QZJA0bj
lppBkP6Nru5OHXWkN2nOSFPiKyS34hy3do6tO7pUli2MkWfgjjY9XGOTgRR/
Ys9ilbPrjIzqxiY09lZyupbAl6ItCxJJhm0+elohc0qKa6wMPYjxfZJtigb+
oemvyTPCmNVqkiv7iYJWwUeKICBe7FEodLaZkaRuRS06+wNLXjXPyhdqYWJT
+PUyzZGs8gK2biPgNnVWYJxSO09fk9U97I/Uu8ya2t7Zx9HE4YLLNClEjiPZ
tboqCavGKeKtrdaeJLBrcNryoErI7+kUYIwbLO9jz0OJaha7ie3aCtCq0dwm
Lyn2faEPzBQ6OzBJN7EnqhhyU9WkUU7dtEBS9Ez2D+2IE/t+MvfnatZ9i7v+
nHB8g8unFp4/OjluNQXPn4qA2xjuzpSc6+Hmr3nW/3D+/s+jnz797V9+DH44
f7VJBn4o+fD05PjwZHAyUgO1idZqOBgOh8f94fBQDc6GvT4lkR4PTo5HJqBs
WD1sWV/R3Arn1i7aLuDRn+VwdDI4Hh6eHh06swzORsenJ27kekgTHX3VRENv
otHJ4eFweDocwjxluFaDo8Hp8LQ/Gp04qzmzE8A75LmT/g1fvbDh4Gh0cnLY
Pz1yJxyMwCb1F/ar5sQ1YoOZbNa1PMLLFXEP/mOB3MBjhq7irU96W7mWqBO6
/fy56fkXanZSzQqsGqwmSid9rapaV8FlGU0Kom524DFIL/3e1spxmyIrUHak
E9peRy8krGUCExzX0grkFzIePLVCAi1n3LSJzVfXm5+F4Yb6mhFX3x03x1rC
PAEZnWP65veggXNNV8Eg1jirF5RAFKNrwe0TQbm2FiudSgomaQs0IOulCB3b
uLtXAUxfp6XWLMhK7RmPz0E7vcTHnOx+ykA1juBhvC5prQADhXyziq0epdUF
AMOE0qKnUKWKMpFalK1jGldUXeqMtlsaN4b5tWzFHzUdt4U9S36v4d5tNyfX
KHlZLRSh0cSSHDSFGGEvjGqP+RTw1S5XRBW7Vi/utW6TVYK9tR6oXVnlRdc9
9aXjO2YkA/5/knI8qfEndtT6m4DuDoco3CNEBKAhwGCQ1hzavmNb1GD6R5eN
sfY/tZ/n88QYhxfgKkqpaETVEqadG1LUChTX20hYwui3jl26mz6dBHSaQMp4
uMqMYyGCSmAeFAVDfLxz2NattroXht+l2yZ1WU7Y02emmhSvDTlP7WNcNp9c
nXmPI5MDwfgLOuJ8cvVrTtHQcban43vV+KY+pAgAUG6OfWR9Yxhz9LCxmnia
nRO9w9Pmx6gmyyLraC9RJaFEKqmteNxJrg1ugjDL6/47vRTH/6HNCDOrR+zE
uMHGNOfiGQv0mz7VJbJj6OMJsWeExTSNITO4fJD4fIUWMGyneXaRreIOio6Y
fNropxLqNjZpDVg8FNQNlRL7uE7XGRL7JXC+hbNqxw+sbjOByyXXHTvW4eSA
JsG8K2YMBqw408wSBAhp4VAxQD2ZosV65MWDKqLb0SM7muXwmdvqOXw9DhmI
FP/paIZM2FOvvm59nKJhxUZjZywHQDycCaWNWSFd4Hn8nZOW3Pkd/3MdYHQB
/oUj/E6nMP/O5T8mIKz7h/qhBIoBcDW3jr+7pGc8hOzVx+AM8JWC0hh2Oi5N
DwXPEaATAHLKACA02MJX3/j3y57NMdZJckv2FXyM4zW7Qj8l3CHOOfT1Hgx4
wAGWfOuTsWYWRsfMd0yP2Umg17mZJpXwqPBs1E+JtLCGq+ONoePKZoZI/FRM
f5JrGn9aJ3msG6Ho8H5o5JhU5LpQ1+TykWU4nGjI4RwqK4Pnm5SSj+KG9KVO
jQieIlnMP5ovympqAc5DfmdCiPFAr2CaOSMX82zDOA3yJBOzxQm/yC4VOz1M
ru5gOIcnwlzJVRiBJm1FbYB6tslJ5/PWKafRLEjqx3T4s8Hx11Bezsq7UfSq
1oYZvFqH7fq9CycWpf1d0tsXY8Gs57i9GKuzCOOpsiv3sabPvWnMpfRcQufl
hwgI+6LW3n14Z6nB02uTlLIT6nCkkYmqR8AI1paHWPWK0ph5lUgdSbnhj0nv
x5zqCuPR8WXjmrN2ZBMfE8SaINxv4G/7p1/razsdth4rOvmNvHDb4kfXC3f/
cPRm9fDdaHsQH0fX1wc/Ta7Pvlsfffz/Xrj/fl441+OGyrUuzAqmYRj9Wuoc
HhnyfKo86jei1OHp2fRwMD05GsVBMDo8dai2Pz0+no1OhqOzo3jWD8MgPJlG
wfHRYTA9nsajszgYHA4GsKHD4Cga9INaeRKT1zPLk+q+zcdcmGkjw9nhw5TX
nuHHjEA/TXWbpqqflOeybkzNomrKT7Mn0zEBXX+m56+zNywwV2UidCUrJjhj
jh83rqDa5h1uHlIErCZeEz/czSMuaqJDG10mT7DJHebC6rq2GiH2PVSe+mDg
5foC3fqfdwErL6jKxsuH8Qt4kBxoXYlp1Z4YvcO1G3WLnERu/IhtVxFaFOy1
ZJSbOx7I18j7a+PEFKaWV0nCSlQQYStifyhMXY9LvOeF/cxoCrwiH1Or9bRp
U8m6MXUX7G8bjA7FDUoV/g0OsiY/H7vp6jTb1BbaL3qha0mwZMPcBtGUCiHs
iC9MqTcSsb4rhJ6Vd0nf6LjORF5cE3Y8ABkxuH7TrMqAiXs1E6udESMf+xoy
ZY3FYnWyem4rmkyqi+hvflETkVsTIptqh1wTs+2VS1Z6MsQBqpgCsN9vuobP
Q+vnODqVGh2gMs68oe6Ft+SGkDC53wfDpOg4L+7wDR/q5EriNJTJhWj1ofO9
nfAjqJfu2gyNkIVNbk6mQ3d+f5BSLWNUyzER23nrLtc3toBBwXvyMUkjySSx
pi2lI8CeUh/0jB0DaW0g62YiwHi8PRal8AOVou478RmY4YFaQ4Fqbe5xwCFm
m3JDOW73CWcjZFqzBj5DuQyUtGIhadwBGKhpqUQWdq2cKOTQsbg+AI4HtNMw
YxP44xSrcjgriih8s5qiHwIwR8ujbuOyxAa84AUi5gvn56Y+6k3dxNwEhWc0
d3msZABAaY9A4XoVRJStGxe1OoLGDiiTv3IalfHg1nt0BZRMRs3nIy/gpENN
JCmRm4jpytMyYwdUTNH8dlwFNjcFD+O7DO86wkw8OnvGjSd3ETQUG7qZ6II3
bLYGm7QJqmeuwRVR70qUiCvC2rKYKE6LqCRMuINzhcffY+OQfFEpiKnTEKG6
EWV+w9FCetnqJvxJAbxCe6ZjFot58V+TKKTsFdOU82zJvhPUDdr0zGGafj6R
r186jcLooJmqUFh3qX+ujehELrgvivsbMeXOrgDhECW2ZYOzmnwm+WLUM9b2
aKk6yTfD3OnE9kJ6FpDcCMmH0c9FMjtbT0Zyu6m5rTu/fkoXx86p+K2ZWAtv
x7kce1iX3SisY1uimKDtsCv01+24s6vVLZXr+h6CbeFUNJouZn61tsSMQSFm
35FzC5EhBXlXSCE1h1g6Y8m07OMMF1nG7MGnLDOqFtxVImsorqiUXArjrWiT
nL+sB5dSCLzAhMp5k5JrIShXjZdHVpEuSdZ4BuxJFptBSUBMjDQFrANGWe41
x9Kv0ZWOdPucXHeVlFUsyfGx9R9yWQg6DBoc8aR7GsRpc0Gv7fG61MLMArCZ
EjBTlFqhlQaTqyFpsnoRCWzTmwzOwzRYBmmou4yDzq3bsBWivPp9Hv1pmFwk
aBJmupm0RJNIrTOdYjPZR6O6Ufa7gQB1cCB07nJpSwFtWac3MwYjK1Vkrqkm
2ax2LY2Fi6NqRN+1T4L7LIn8a4rkUis9LqdWOC0rMYPC7aR62B8Qzg77w1rb
OGP4gQCGBeZkJNHlbJW8hqW/SYBATN8hpeGwf6LuYryDJ8i3wNgYLCfq7LZi
JdniXL/lY6J3WsXFjYc9UTttCQJhwmqhmiGw64U6THhho8KPzCyAbmhlDV0J
Cx3Eksj/Uf+Q7nrB6w4/pME9yHXk7s4ypSWuuUTIOr+Jb3BCBJzWTVppg+vK
kWgjac+lwShVqiL6sS9JuACDlWzZgO7HJJJ9FKnHVQLTtwAQb8cbE5dUqYq9
Du7ZnGeXD4a/sd9/0Nhdk8+chABuMNbXndBnlZpNBycx185vVlxIYpCEmpok
qmQbHLWUugepGloFH9knxl6YLqpNbqZY88rRxVwpZ2V+g+GUg7sPN+/07ugm
ptKHuVljFEp4/GMsG5IcciBP7qNgb93buiLuWdWsdZ27sT8nN1udKDrDFL1E
HRilTA1c28ZFqm1td/f2myT9WElNEjVkeHqqqyYC7Ca5rOkQ1FWEmDvN02aS
wRHlnmEA8kpfnyCw4JMmXRMdxqaaUx4caa+Vi1h7G6Lth+PM6Efm3Zs0dNRy
rPVI+sxbuXO1RqAcDHYq29ulEAIsrK09nm25RJVsf4sm3ZOgMDRPcVMR9OId
gRPhzIWNx+1MBth2ZXbPg1SYotUslwYFFjKtypYeIp3PvVWjp7mL4XNSTPBd
0zXD8e3uOH9ntvvO6Qg7QfiLIcB/Efofx+1CSrYaVycl0QvtviEJKLFwH/NO
8F10MtMKBHniLNgsSxlODCFvC9ycFo80et7tZ7jssfpDUW7SMf6fCXuCOvnH
32Oy6kv3THkf4fEd4/+5H31rKi5ebqJ1wxC/d2/K0TT4so1/a//eQdrL9mp7
rYH+fXXfXtoFfRVMZfiPgan4rwDUoyn5VT5d+HKlrdQLJBCBzgtlNT2vXzji
nDCT78StFtw2k07AyHZ716Efw7VFxDn+f4cpGwsWT0rK9yXDEo3F8CzpYdTS
OicXNs5mcCpnWFfBH57r2I3x3jDH+vz5W93X6iGe5mXYHfaHg/4AW1vhNcDn
nhSPOICDyhc10dfZhcPeoPfMBVgmsGYXknF/t6sNAjHhYdwWy0TcWXlM6wKV
gTpu+A3wtesLEwu5pTRyfXNJub6DYr6RMgtuBYQ9/KpUZjar1msAN3xCKpkf
b6u7CBAKLJmleXUtbxGXPkrFqhCNLpQbHeRVbGK3dO9w1RdEa5xx6wDryklq
FpI4DtGVaBvruYFbigVhilA1ZPmERmdSEj+VlcYIa5CuMbeLw4BIzgmj5vb6
Sp9BN19a24cEgobnCThsGJaRwYgwFfu6w3W9+ZFNjh30Bqe+b9i3NR1nTaH1
1KKxYbv2oLpRrefh0eaxwYTVxnYkL3dpuJp2yL6rFLVzvwLHi0UHgmgI/la5
19i9472e3lTU08D1W84lF84Hv8PwNrKUJ0+KOJjItNGWqht513b9Ixe0VNHo
V4d4WJEESbZnnNwWXZvl7pSjU+NxFvvaT950LBCq9EKvF9Ch5BGYu+WIgSGz
D6LI9EiTPa3utxN+oNgdNqTTnkDnN9fcNyZz4CbqOUSsIwlIA02060VXyKR7
BvGKjleFXzocxrMlGcNuSQj2e9zV7rGjHX5EZncNAxtHtlM9MiEfYleuVOqK
A7n71mGVbe68yhJJi9Ad330vugBRjqjetWkds1A8xbWOWoXlBpp/aNzt5Gxg
+El6OSWzkInh0qDQVOS0XMVxmu66141VNDnSNJYm0XeSWzWGFuGPX6MQcR4D
vvQdESGjDpWtbzkefuw55amAufKyJlqOhPAlyfaScLor6y4x4WaHIyU6/YRs
jSL2B0IpMw0clYfK39buwdayWBZJz6gkQcqkqTaOmyGR+gcYwpY0q4R82gjT
Q5JGYEbt0S3YufiAOGS92ODFFRHFtlegYyYFdUDC7ohRt8y68J99E5wxp5+V
uKQghxt7YVeGdXnrM0ZTqgTTcg8TMcZl8InX5kTSZ5jrge6VisBlX8/EN1xJ
bXUNulZrslxWHH+d5n4CXjYMnZrq4DXfblN/qoagPVEG3Rao4/XTOMjplY8Y
/atN412PJLqJ1lJ12rsnvQK7yJJarlaFpTn5sAFOLYQOMszc5kK09gpQ6Jdc
NdQWWlT0jht8cS/Uq90rbXT82z4g5JNjOWUkoCOj0KNphzOOLl1OMHGpoLEc
z4dsp1rlXLB0fHJEPut6brqNwLDj4gmqdJR5XrOw8qcgx/O8XHqoKIxS5TDS
ikph213Hn7CNsAkIsFhrbncM8k10izTAvBc4NVs4e586ArJzJRvxbgebXkrg
gvu4RElh/CdGBzQJ5wWmxxeamxVhto5Ndk2UhRvuMHuLXEVMYDMxZQbh33Fm
UcNDzwEUIPCY7KDDC4YZZh31px/u9KdevSvvteOjPD0ZYtNjLrBbBKiuwJEE
FUMVZZYzww6IESP/ZkeSHhhJeLtOuIPYKsAwiY4vaFTojAbO/zSoqGvJ0hBD
38pV7w9XqL1Cqnxl7Afg7jd3b6+taS+5SP8Sbxk6uzvA3h8/l4xb0052ET9N
7f4dw9X3+QCKuMLxCEqv9tGCYmm58EqETIDZ1ccTo+xobIkzNqiQ63POnhtZ
0yKMa95s5oe6TVabJWowjDPYcNpjTsBiDLRazkt+67sjTIrUfftc9m6cK5Xo
q85FtC1xcgywuNe11qrUDqolajrrROcNFt4aHoKUI5IxR7XEtJELttK5zQGz
ja1d0VK/1K16M9vu9u5u+iOlk060ghlQO3SpnTTw8gScYkjmMlHbjgvhHpnW
8WzzxIArP6ZsYuRPbYhVmm81MfyFiOGcj8Pe7V/O9/3mEKVO4wL1bJMmcpOr
u6VWeiTSTBnAgYE6wkn4XnDKHfGKpZ1+CfhKuFfsd0g5IQcWeZGYu8NY7gZa
ZgUfZWRVkFPdtQPgEz4C5uZTVNlTPqmfX5hLk+3TL5WeiCYto+Tse/M1C3ut
dniMwfZODKSlvJPAzz3d58Da2J9DjClNsw2HuBkjD+5MtiECrKVpIY92mnOu
QY1g18qksEkkHlv6mj63dcN/pxOl1xTZdKpG0ZvaFAOktrUYTDQLFfvVMoWO
ddXZl5odpZVSePs6Gm7aZkVB5rWFNmWuNLPpF2sIj/dSF7YZTUW3+yB0BKWd
bcf+0dWpa9Fz/e7rbpKLyf5o0PRsqSO53OtpWPom2mb0VLuqODf9udqucelS
LqezqkvcqHVtaXqjmdpty+gdQJTqavJuoshzmuhyE60VJp/GO5zYMF27ZgLA
m126GB0rJ9ZByH3SXtteyB3DhZhh2xsILPh0bzmFOMDI1Be9e538Wb2Xl7i0
9543rKK66+uvFuVq2cNfetjs5GHey/L5AZcPAG4PnJG6PFIPv3hRf97xSFb3
MrOSpAaTpWbrBURxiSojK16Ozetf9+Id+8dvGG06ytK7uLLpGLvYtZ9j2aRx
fd1ttecp4E76JeF7K42vU7uPHZ2BRtl0lLsWuI2j9jk/h4aF5cJJQjVw6VR3
f22+BKfqL7PsI6W6mEsfGy9Ze/xata+7QU3Cj8949aAo4j/qeCPFIX/JZjwe
X/QvRDX70VYNkteLLj7yc3Pfr51zPdWGldqMe5eK+3kBYs81RStRs1C3eAc8
dtc+9zp5oo3qEqlNFeAaO+eWWKCiNU7DDg5kxOSIQ8LbFHLJvNyhQp+YbpHO
dFy7ruVOJWzHJereTRL+pens8ZOoCmWqSDTJzF1pU2psA7qjhyC/rdyQlfjO
cSIdBqAy9ApUtyVmadyZto1vgi0mxuo39u7e3O6bOUejY88CPhuMTjjNgxCo
xx3v8ogNax3bBydVH1GXkoSahjKvHp6d8v1E780Goqzv1LVAzEXNCtp5MiZx
+4ELYoVNscln2BnFlAQKtd1cAi+ZXF9JNKmQlBE2RpOStsgynRnwmcjmsAqT
jz8tgg05h8dwyK92lQ+hLULAcHwTfxOvDNXreDax6yznBgCe0WUakLI0wUYQ
2O5U18Y9cd1zD6CkM0NqFgwcNvka2MMccpazkzXLnbsjctGGfMuWuSAMFSpq
2aU9G3JROg6AOdwH0plDmoEiID8sEsmQXAV40xo13WH5b8SN9njLdQrxrvFQ
rwGwdl1uxuVimR+faxoGneRY35F4dYRLE7pyEiPM4nEt2qC2I9H9HeIXB9Si
cS4OWdYAsKRFN0ut0JLJbhbbkgJjtvOp0zokcVr/odIsuNe7twSlEFbELRVl
E5mSGOgdsTWnm0jFB6MLUWzWOa+T3GpMG/eUSMy4oGiJNVmZkA0cO6wcdO93
sTchcoZYX/mVTakuw6RBFmrv6uL9zb7nBdN7vhRxXozt1pBr6fEAbFPTrcIM
ximJQUFcfr7RnWyfPvG6Xbh/RivZy2wf2VtBJNnCB8UmGuebFO2sX7WL5pYZ
Qg2plkynsKdplK1SWqL41oEvbddlNs+D9UK8mbJB6yLeRBl/oosKZWisnDTV
1ewqptAwhspC9r7cmKn0VR02rGaEEwuhUR+lAeuZv4ICm7DPfDHeJYvpuw/a
IQNL/8Am1tUFcmrQOHK19+HD1cW+FpdHx8OOMpfvoDDMzdVymkQqHdV3EB3n
/3bdRjlaFI2V6elY05H1O+gdqXFXZkAU19XOskY25FwKVpEvfqvr+vVZ2MsA
m1LPF01UDIeDt4ukywoMR7rHhlpIs2hpbqEvstemNXsdq9z2ZuiiirJK08bC
vxfh787xGvo/kXZL9nijZuupkNxNnDXbJSrPpImS0KJOJ2T/sRsg3zLFYlh+
M+1ifiOZ50zIO5R4CauSXn6jh2ZzyWa/cVioYfppjGFbk7Ok3RHMammFfgB1
5HhaKQUdZjezvqP8bXdWJ4NsjLi6x/CFTkCgtXsZlhwK4nw7nQwkSWOc+YZe
bXNvYODKbTGx1zE5ym+0vBmru1cXTiOLLu3mlckNMC6nPUTvvt0I6pcApi+i
gLJKio+SUKePHm6o/zol0WGPgGfN1ZZbDPlTsTAYO94AiRlgXQEWUFdI983n
feC59oq2Bj+J3ZxxIgkmqhv+3W/rgRt265Kn9ZDZ8QRzLuIw+wgN0xTxJcyn
fXV597phRKT3G0uLBnPXaH3H6C+7ijQPt+vY6kIAuaCrNiTZD86wDaP5EZ7D
I4wm7HCutfnC4VWQBnPdz82dsqNqOBDY/o57LEH9509mkfn5hXEU6mdyVeVX
wW7GSwpzQbTgDGkhkb6W2sfeiGllkMphWjNmZBlMwZh2qkqUUl1Nw3JEx8/D
RPVbrkx5/qrZdcSD3LrSYOxHyNUeEBmyqH33C+/YmejI2B/JXJEmsL4mdyLh
aYwmesfFTUdJ+2+RdUuMXNnaJKoyRVo1eDW/8Yab5xIrcHqVeBcOaqTD/OPa
tevaZ+Yu1RMQv4TAZcJzXt65Wd5YIWvxsWpkwo49MKqf4yKH2Sz1f5HZduDq
l63ADPRVR3XHGO6h9UD/qoN7WZETv/zkcgDi73161a84vv7a/wcdZIYLxXqz
vCUJ7pCPCQ5VskvUpkyWdJU1UR56eeROUTeNII52Kqza9m8IelQ9zNXIVVNQ
+ktPq91yelnIarODpT33Ud2tbFBlv+uSqLiJ8UbtaphbN3fyNhPLrtHT3Gq9
MxNcXZBXEknffajaLNuM9h0UeG8ghbI9yrmyGek00F9gPUSCA/zXBXb3YzX3
Ig6XlOck2x/YywrMcmkErQRxUeIcrJ6fhKoRSNM/4TKdA+75tTtQYvCSxzAm
wxYYN95xyJkJIBPCcqwmSKn6KfacyMXPtcpASHhZABtQ4UOsmCYHGd4c2AF0
gFb/z8hBMPCHmguvx6ift1uaCD68LfNNiNvRgFi9H/gSJWy8u73dJ48tQMIk
i2bGRlyDsgnexhR4zbx4Hxdeqzkzb7N0+4xG1ZfxZ8Q2/IcqhZA+5Vavj/GW
m/E2DL2KA3QNMeNDPsDlmHcLfdkdPRCbwbcwKWrnJj+3ievS+2Y45oETm7o/
uT2/usIVmfJ4zA6hnsOinZNpRimEfkrwXhHHSjKvB6PBly/7dEA0BOi6+Bt2
qjIofSwIxSKBo9wmb51unsXg08bwb7rM1iFVemiXR6iG9aXb/7yFMXtzWcce
V1hIBpjuPDTNKUEuwpyCJFWOHY+X4nEm43RLbTFSvk4V/eWS7EYuKuytopkq
IGIX6sj25qtcJmkIJw3r4y5EJGl+Ach5l6XAkBwjhx1h5L7zPRjmPEW18y2n
YmpKXRKb5nGfxA86yhIjrilfZ2Nm6XmzXyP/KkqSWLXpAdz3JMp41y1zlOhF
1PE6yhE45je5TsH2BpHbaM29evlm6VYb0OvEdZkAgFClIMEk4/sbrvOFuB/m
hnp9FJLKwul+dIrdkaR5PMttASQxGlstP0zuZHOaxc/4LCFGNXDU0t7MhQVC
ohZk1PYnoZNxLeEEvMXBIn9ilkt7bfkeZ5SgU4jZx17cm/c6j6h1+3zrJzlv
GJUoYLsE+r2W/74g3QnVDd49t/Ep1iaJIKHTxuEkb+JPlIFwCQcX8EGKt3zD
XwTLih/49xyBMSMsZYTYjlDNJbcsgEPEAME5MxFq70G4Ik2CuMgT88PHf7E3
lr/Ve71jpbeYS82/fbfMpsHS9cWwLCbMGqfIpdWs2CLytCGXeekAUzXPDl1Z
O7U1Epm0YHZnpF/jvtjhcdpqVtuQirTfI+1ZX/ZTXyZDpG0S6qcgdf+/rV5p
XEbOldZ8sbPn/G/C2eNdGCluoVqP7qLc3Jk6svyZeVyok/qWx7W2PEhakoaH
mjCyVlOk+rgu1vFb+yHicSjqSMSqHF5HsDHB8Z2IQa6WFVxRlmQSp7WgEmI+
2CJKFyiqKgWbJ50vOTt9k4MlGvVkQbff4YLweziwiGVaVV0hNf49PuJUbg78
tKao4kgeEnxg2LhAuectoGCNpOo4xQPmbCRt8J6uFTIc+DFWi15Z1Mbn3Ito
19HQ8knbpbqjACwZOJduOIbXwSaY6WWyNWUXPW5Nfc6KDV47zdF9aqVoxF21
RsrcwgBqG5fY10rVCy8l26LQnpOd+2UDEFS15G4fEc0kBX0fRgxQveYerWiR
w3w3l3/+cHVzeWGOc96wOcxAqCgPd0hshFUWoQZm4lVrWi9Vaz0+Jymx3sTV
SR8//O7sO9907tWrbHdqQQaAeubY543+CNi4eZJK+I2ysmHPSseK5HCRGLad
aq2baX1KgYOOLv4mx0CQBv+M/4fnh1AGFp204qWimp27LowGjjIodxI/SNXE
5v+xTY5Vm4qqNvcmN3f7agKUrS4o9SAzjWmkKSBwiJ5GBN85K8MXDioqrXO+
fXV+TQ1bdU4722vIdVri5Xlv70JvRC6oAhLZsY1TsdqThKm4KnAc6ogc2XZE
/t1e2DwjjzwXRcPpdzyJTJ5IjpL6yZ0kYtN52cj8XQK22iQbh3yCNgotJ8Qg
gs0MTKsNYs22ZtEps9dZdnZ0MyBF4E3BA2ZwZDiO4IFuchNRoY9Ah/RneaEh
Rqvp1dAC4qjWEFysw1rhnJfc3TW5adVb+FAjn8bWziAe7CggJDw5/1cKD2rZ
9yLJv9uA3piKl8pxulzSOZGmmbXnau/icr/a+TMoQvhJF5ETh9D3KhWbhC9E
ilzjUe0FvkTYb+gu5YhRyoXJsHyZnYFiExkfaVJYOSS3WLHccUWRLmi/uDSM
1F1EuIiBzdIBAWsXxQ6ArxU03UzTv2G6Qq3Yl82QIZ7Ekmej6hsXdqdWjLCf
mWspC/+0F9ZKrZQKWutYElNXhAhgewCvySGpZmRwFigHjtWt0TjJtuN80j3U
TPbVD1lOffi+oxCyq58gFm99H6ZtslWTFtrh173Igxl8+yYoyipm3JvcEDPc
BcfFT8D9JCuNf9H3AlsszVipnb/twUql95S0Zy6pJ4ooFlYlQF1Vq7W7GJan
b1kX7NMmhJZl5I4h7qM3xcmAkvHYJlP4LTrSpF4DrUAvA61htqdM6ceyyPd7
PKsTvpqoGcsvr7sgWyrV4+QfYB7qnbgCTVzhPhYX2+xZy7hFbgwqGZa8VqD0
4nkTNc2TeObGL8wlbps0dP/t1COw12WByc6IJkpdo3vpHjKe41z8UY4EGTc9
NNviuQ25iWqBThduYlmV3ZjbMwmxIggUjzl7BpklcY1sQWaBFDABR38D0jT9
KVNvkzQBhbij/rRZJpviJ3W+yLNpFv4Uf+yoSRSs1E0WhIuOeof9yN8vlqs4
wegNvMYlQN9nS8zCm8Mj2AwwdNTlcplkJYi07+AEBveZ+i7IwySAKYB3FepV
kuN1mLfAWnL8bRMmDcOxUw57SiADi5dOpEPf7UJVO6WwPTI8jeQSlgWSfRbH
0RR0XGAL2N1A0vnQ1UM8zVp2Et4xbF9S8nW5soqD3O0dLexJCIHKf4B5dbtd
hbO1/h/Vl14kbs0AAA==
</rfc> </rfc>
 End of changes. 113 change blocks. 
2373 lines changed or deleted 1126 lines changed or added

This html diff was produced by rfcdiff 1.48.