idnits 2.17.1 draft-ietf-wish-whip-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 29 instances of too long lines in the document, the longest one being 66 characters in excess of 72. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (7 March 2022) is 778 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 7232 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 8829 (Obsoleted by RFC 9429) ** Obsolete normative reference: RFC 8843 (Obsoleted by RFC 9143) Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 wish S. Murillo 3 Internet-Draft A. Gouaillard 4 Intended status: Standards Track CoSMo Software 5 Expires: 8 September 2022 7 March 2022 7 WebRTC-HTTP ingestion protocol (WHIP) 8 draft-ietf-wish-whip-02 10 Abstract 12 While WebRTC has been very successful in a wide range of scenarios, 13 its adoption in the broadcasting/streaming industry is lagging 14 behind. Currently there is no standard protocol (like SIP or RTSP) 15 designed for ingesting media into a streaming service using WebRTC 16 and so content providers still rely heavily on protocols like RTMP 17 for it. 19 These protocols are much older than WebRTC and by default lack some 20 important security and resilience features provided by WebRTC with 21 minimal overhead and additional latency. 23 The media codecs used for ingestion in older protocols tend to be 24 limited and not negotiated. WebRTC includes support for negotiation 25 of codecs, potentially alleviating transcoding on the ingest node 26 (which can introduce delay and degrade media quality). Server side 27 transcoding that has traditionally been done to present multiple 28 renditions in Adaptive Bit Rate Streaming (ABR) implementations can 29 be replaced with simulcasting and SVC codecs that are well supported 30 by WebRTC clients. In addition, WebRTC clients can adjust client- 31 side encoding parameters based on RTCP feedback to maximize encoding 32 quality. 34 Encryption is mandatory in WebRTC, therefore secure transport of 35 media is implicit. 37 This document proposes a simple HTTP based protocol that will allow 38 WebRTC based ingest of content into streaming services and/or CDNs. 40 Status of This Memo 42 This Internet-Draft is submitted in full conformance with the 43 provisions of BCP 78 and BCP 79. 45 Internet-Drafts are working documents of the Internet Engineering 46 Task Force (IETF). Note that other groups may also distribute 47 working documents as Internet-Drafts. The list of current Internet- 48 Drafts is at https://datatracker.ietf.org/drafts/current/. 50 Internet-Drafts are draft documents valid for a maximum of six months 51 and may be updated, replaced, or obsoleted by other documents at any 52 time. It is inappropriate to use Internet-Drafts as reference 53 material or to cite them other than as "work in progress." 55 This Internet-Draft will expire on 8 September 2022. 57 Copyright Notice 59 Copyright (c) 2022 IETF Trust and the persons identified as the 60 document authors. All rights reserved. 62 This document is subject to BCP 78 and the IETF Trust's Legal 63 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 64 license-info) in effect on the date of publication of this document. 65 Please review these documents carefully, as they describe your rights 66 and restrictions with respect to this document. Code Components 67 extracted from this document must include Revised BSD License text as 68 described in Section 4.e of the Trust Legal Provisions and are 69 provided without warranty as described in the Revised BSD License. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 74 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 75 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 76 4. Protocol Operation . . . . . . . . . . . . . . . . . . . . . 5 77 4.1. ICE and NAT support . . . . . . . . . . . . . . . . . . . 6 78 4.2. WebRTC constraints . . . . . . . . . . . . . . . . . . . 9 79 4.3. Load balancing and redirections . . . . . . . . . . . . . 9 80 4.4. STUN/TURN server configuration . . . . . . . . . . . . . 9 81 4.5. Authentication and authorization . . . . . . . . . . . . 10 82 4.6. Simulcast and scalable video coding . . . . . . . . . . . 11 83 4.7. Protocol extensions . . . . . . . . . . . . . . . . . . . 11 84 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 85 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 86 6.1. Link Relation Type: ice-server . . . . . . . . . . . . . 12 87 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 88 8. Normative References . . . . . . . . . . . . . . . . . . . . 12 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 91 1. Introduction 93 RTCWEB standardized JSEP ([RFC8829]), a mechanism used to control the 94 setup, management, and teardown of a multimedia session, how to apply 95 it using the SDP Offer/Answer model and all the formats for the data 96 sent over the wire (media, codec, encryption, ...). Also, WebRTC 97 intentionally does not specify a signaling transport protocol at 98 application level. This flexibility has allowed the implementation 99 of a wide range of services. However, those services are typically 100 standalone silos which don't require interoperability with other 101 services or leverage the existence of tools that can communicate with 102 them. 104 In the broadcasting/streaming world, the usage of hardware encoders 105 that make it very simple to plug in (SDI) cables carrying raw media, 106 encode it in place, and push it to any streaming service or CDN 107 ingest is already ubiquitous. It is the adoption of a custom 108 signaling transport protocol for each WebRTC service has hindered 109 broader adoption as an ingestion protocol. 111 While some standard signaling protocols are available that can be 112 integrated with WebRTC, like SIP or XMPP, they are not designed to be 113 used in broadcasting/streaming services, and there also is no sign of 114 adoption in that industry. RTSP, which is based on RTP and may be 115 the closest in terms of features to WebRTC, is not compatible with 116 the WebRTC SDP offer/answer model. 118 In the specific case of media ingestion into a streaming service, 119 some assumptions can be made about the server-side which simplifies 120 the WebRTC compliance burden, as detailed in webrtc-gateway document 121 [I-D.draft-alvestrand-rtcweb-gateways]. 123 This document proposes a simple protocol for supporting WebRTC as 124 media ingestion method which is: 126 * Easy to implement, 128 * As easy to use as current RTMP URIs. 130 * Fully compliant with WebRTC and RTCWEB specs. 132 * Allows for both ingest in traditional media platforms and ingest 133 in WebRTC end-to-end platforms with the lowest possible latency. 135 * Lowers the requirements on both hardware encoders and broadcasting 136 services to support WebRTC. 138 * Usable both in web browsers and in native encoders. 140 2. Terminology 142 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 143 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 144 document are to be interpreted as described in [RFC2119]. 146 * WHIP client: WebRTC media encoder or producer that acts as a 147 client of the WHIP protocol by encoding and delivering the media 148 to a remote media server. 150 * WHIP endpoint: Ingest server receiving the initial WHIP request. 152 * WHIP endpoint URL: URL of the WHIP endpoint that will create the 153 WHIP resource. 155 * Media Server: WebRTC media server or consumer that establishes the 156 media session with the WHIP client and receives the media produced 157 by it. 159 * WHIP resource: Allocated resource by the WHIP endpoint for an 160 ongoing ingest session that the WHIP client can send requests for 161 altering the session (ICE operations or termination, for example). 163 * WHIP resource URL: URL allocated to a specific media session by 164 the WHIP endpoint which can be used to perform operations such as 165 terminating the session or ICE restarts. 167 3. Overview 169 The WebRTC-HTTP ingest protocol (WHIP) uses an HTTP POST request to 170 perform a single shot SDP offer/answer so an ICE/DTLS session can be 171 established between the encoder/media producer (WHIP client) and the 172 broadcasting ingestion endpoint (media server). 174 Once the ICE/DTLS session is set up, the media will flow 175 unidirectionally from the encoder/media producer (WHIP client) to the 176 broadcasting ingestion endpoint (media server). In order to reduce 177 complexity, no SDP renegotiation is supported, so no tracks or 178 streams can be added or removed once the initial SDP offer/answer 179 over HTTP is completed. 181 +-----------------+ +---------------+ +--------------+ +----------------+ 182 | WebRTC Producer | | WHIP endpoint | | Media Server | | WHIP Resource | 183 +---------+-------+ +-------+- -----+ +------+-------+ +--------|-------+ 184 | | | | 185 | | | | 186 |HTTP POST (SDP Offer) | | | 187 +------------------------>+ | | 188 |201 Created (SDP answer) | | | 189 +<------------------------+ | | 190 | ICE REQUEST | | 191 +----------------------------------------->+ | 192 | ICE RESPONSE | | 193 <------------------------------------------+ | 194 | DTLS SETUP | | 195 <==========================================> | 196 | RTP/RTCP FLOW | | 197 +------------------------------------------> | 198 | HTTP DELETE | 199 +------------------------------------------------------------>+ 200 | 200 OK | 201 <-------------------------------------------------------------x 203 Figure 1: WHIP session setup and teardown 205 4. Protocol Operation 207 In order to setup an ingestion session, the WHIP client will generate 208 an SDP offer according to the JSEP rules and do an HTTP POST request 209 to the WHIP endpoint configured URL. 211 The HTTP POST request will have a content type of application/sdp and 212 contain the SDP offer as the body. The WHIP endpoint will generate 213 an SDP answer and return a 201 Created response with a content type 214 of application/sdp and the SDP answer as the body and a Location 215 header pointing to the newly created resource. 217 The SDP offer SHOULD use the sendonly attribute and the SDP answer 218 MUST use the recvonly attribute. 220 Once a session is setup, ICE consent freshness [RFC7675] will be used 221 to detect abrupt disconnection and DTLS teardown for session 222 termination by either side. 224 To explicitly terminate the session, the WHIP client MUST perform an 225 HTTP DELETE request to the resource URL returned in the Location 226 header of the initial HTTP POST. Upon receiving the HTTP DELETE 227 request, the WHIP resource will be removed and the resources freed on 228 the media server, terminating the ICE and DTLS sessions. 230 A media server terminating a session MUST follow the procedures in 231 [RFC7675] section 5.2 for immediate revocation of consent. 233 The WHIP endpoints MUST return an HTTP 405 response for any HTTP GET, 234 HEAD or PUT requests on the resource URL in order to reserve its 235 usage for future versions of this protocol specification. 237 The WHIP resources MUST return an HTTP 405 response for any HTTP GET, 238 HEAD, POST or PUT requests on the resource URL in order to reserve 239 its usage for future versions of this protocol specification. 241 4.1. ICE and NAT support 243 The initial offer by the WHIP client MAY be sent after the full ICE 244 gathering is complete with the full list of ICE candidates, or only 245 contain local candidates or even an empty list of candidates. 247 In order to simplify the protocol, there is no support for exchanging 248 gathered trickle candidates from media server ICE candidates once the 249 SDP answer is sent. The WHIP Endpoint SHALL gather all the ICE 250 candidates for the media server before responding to the client 251 request and the SDP answer SHALL contain the full list of ICE 252 candidates of the media server. The media server MAY use ICE lite, 253 while the WHIP client MUST implement full ICE. 255 The WHIP client MAY perform trickle ICE or an ICE restarts [RFC8863] 256 by sending a HTTP PATCH request to the WHIP resource URL with a body 257 containing a SDP fragment with MIME type "application/trickle-ice- 258 sdpfrag" as specified in [RFC8840] with the new ICE candidate or ICE 259 ufrag/pwd for ICE restarts. A WHIP resource MAY not support trickle 260 ICE (i.e. ICE lite media servers) or ICE restart, in that case, it 261 MUST return a 405 Method Not Allowed response for any HTTP PATCH 262 request. 264 As the HTTP PATCH request sent by a WHIP client may be received out 265 of order by the WHIP resource, the WHIP resource MUST generate a 266 unique strong entity-tag identifying the ICE session as per [RFC7232] 267 section 2.3. The initial value of the entity-tag identifying the 268 initial ICE session MUST be returned in an ETag header in the 201 269 response to the initial POST request to the WHIP endpoint and in the 270 200 OK of a PATCH request that triggers an ICE restart. 272 POST /whip/endpoint HTTP/1.1 273 Host: whip.example.com 274 Content-Type: application/sdp 276 278 HTTP/1.1 201 Created 279 ETag: "38sdf4fdsf54:EsAw" 280 Content-Type: application/sdp 281 Location: https://whip.example.org/resource/id 283 285 A WHIP client sending a PATCH request for performing trickle ICE MUST 286 contain an If-Match header with the latest known entity-tag as per 287 [RFC7232] section 3.1. When the PATCH request is received by the 288 WHIP resource, it MUST compare the entity-tag value requested with 289 the current entinty-tag of the resource as per [RFC7232] section 3.1 290 and return a 412 Precondition Failed response if they do not match. 291 Entity-tag validation MUST only be used for HTTP requests requiring 292 to match a known ICE session and SHOULD NOT be used otherwise, for 293 example in the HTTP DELETE request to terminate the session. 295 A WHIP resource receiving a PATCH request with new ICE candidates, 296 but which does not perform an ICE restart, MUST return a 204 No 297 content response without body. If the media server does not support 298 a candidate transport or is not able to resolve the connection 299 address it MUST accept the HTTP request with the 204 response and 300 silently discard the candidate. 302 PATCH /resource/id HTTP/1.1 303 Host: whip.example.com 304 If-Match: "38sdf4fdsf54:EsAw" 305 Content-Type: application/trickle-ice-sdpfrag 306 Content-Length: 548 308 a=ice-ufrag:EsAw 309 a=ice-pwd:P2uYro0UCOQ4zxjKXaWCBui1 310 m=audio RTP/AVP 0 311 a=mid:0 312 a=candidate:1387637174 1 udp 2122260223 192.0.2.1 61764 typ host generation 0 ufrag EsAw network-id 1 313 a=candidate:3471623853 1 udp 2122194687 198.51.100.1 61765 typ host generation 0 ufrag EsAw network-id 2 314 a=candidate:473322822 1 tcp 1518280447 192.0.2.1 9 typ host tcptype active generation 0 ufrag EsAw network-id 1 315 a=candidate:2154773085 1 tcp 1518214911 198.51.100.2 9 typ host tcptype active generation 0 ufrag EsAw network-id 2 316 a=end-of-candidates 318 HTTP/1.1 204 No Content 319 Figure 2: Trickle ICE request 321 A WHIP client sending a PATCH request for performing ICE restart MUST 322 contain an If-Match header with a field-value "*" as per [RFC7232] 323 section 3.1. 325 If the HTTP PATCH request results in an ICE restart, the WHIP 326 resource SHALL return a 200 OK with an "application/trickle-ice- 327 sdpfrag" body containing the new ICE username fragment and password 328 and, optionally, the new set of ICE candidates for the media server 329 and the new entity-tag correspond to the new ICE session in an ETag 330 response header. 332 If the ICE request can not be performed by the WHIP resource it MUST 333 return an appropriate HTTP error code but MUST NOT terminate the 334 session immediately. The WHIP client COULD try again to perform a 335 new ICE restart or terminate the session issuing a HTTP DELETE 336 request instead. In any case the session MUST be terminated if the 337 ICE consent expires as a consequence of the failed ICE restart. 339 PATCH /resource/id HTTP/1.1 340 Host: whip.example.com 341 If-Match: "*" 342 Content-Type: application/trickle-ice-sdpfrag 343 Content-Length: 54 345 a=ice-ufrag:ysXw 346 a=ice-pwd:vw5LmwG4y/e6dPP/zAP9Gp5k 348 HTTP/1.1 200 OK 349 ETag: "289b31b754eaa438:ysXw" 350 Content-Type: application/trickle-ice-sdpfrag 351 Content-Length: 102 353 a=ice-lite 354 a=ice-ufrag:289b31b754eaa438 355 a=ice-pwd:0b66f472495ef0ccac7bda653ab6be49ea13114472a5d10a 357 Figure 3: ICE restart request 359 Given that in order to send new ICE candidates to the WHIP resource, 360 the WHIP client needs to know the entity-tag associated to the ICE 361 session, it MUST buffer any gathered candidates before the HTTP 362 response to the initial PUT request or the PATCH request with the new 363 entity-tag value is received. Once the entity-tag value is known the 364 WHIP client SHOULD send a single aggregated HTTP PATCH request with 365 all the ICE candidates it has buffered so far. 367 4.2. WebRTC constraints 369 In order to reduce the complexity of implementing WHIP in both 370 clients and media servers, some restrictions regarding WebRTC usage 371 are made. 373 SDP bundle SHALL be used by both the WHIP client and the media 374 server. The SDP offer created by the WHIP client MUST include the 375 bundle-only attribute in all m-lines as per [RFC8843]. Also, RTCP 376 muxing SHALL be supported by both the WHIP client and the media 377 server. 379 Unlike [RFC5763] a WHIP client MAY use a setup attribute value of 380 setup:active in the SDP offer, in which case the WHIP endpoint MUST 381 use a setup attribute value of setup:passive in the SDP answer. 383 4.3. Load balancing and redirections 385 WHIP endpoints and media servers MAY not be colocated on the same 386 server so it is possible to load balance incoming requests to 387 different media servers. WHIP clients SHALL support HTTP redirection 388 via the 307 Temporary Redirect response code in the initial HTTP 389 response to the WHIP endpoint URL. The WHIP resource URL MUST be a 390 final one, and redirections are not required to be supported for the 391 PATCH and DELETE request sent to it. 393 In case of high load, the WHIP endpoints MAY return a 503 (Service 394 Unavailable) status code indicating that the server is currently 395 unable to handle the request due to a temporary overload or scheduled 396 maintenance, which will likely be alleviated after some delay. 398 The WHIP endpoint MAY send a Retry-After header field indicating the 399 minimum time that the user agent is asked to wait before issuing the 400 redirected request. 402 4.4. STUN/TURN server configuration 404 The WHIP endpoint MAY return ICE server configuration urls and 405 credentials usable by the client in the 201 Created response to the 406 HTTP POST request to the WHIP endpoint url. 408 Each ICE server will be returned on a Link header with a "rel" 409 attribute value of "ice-server" where the Link target URI is the ICE 410 server URL and the credentials are encoded in the Link target 411 attributes as follows: 413 * username: If the Link header represents a TURN server, and 414 credential-type is "password", then this attribute specifies the 415 username to use with that TURN server. 417 * credential: If credential-type attribute is missing or has a 418 "password" value, the credential attribute represents a long-term 419 authentication password, as described in [RFC8489], Section 10.2. 421 * credential-type: If the Link header represents a TURN server, then 422 this attribute specifies how the credential attribute value should 423 be used when that TURN server requests authorization. The default 424 value if the attribute is not present is "password". 426 Link: stun:stun.example.net; rel="ice-server"; 427 Link: turn:turn.example.net?transport=udp; rel="ice-server"; username="user"; credential: "myPassword"; credential-type: "password"; 428 Link: turn:turn.example.net?transport=tcp; rel="ice-server"; username="user"; credential: "myPassword"; credential-type: "password"; 429 Link: turns:turn.example.net?transport=tcp; rel="ice-server"; username="user"; credential: "myPassword"; credential-type: "password"; 431 Figure 4: Example ICE server configuration 433 There are some webrtc implementations that do not support updating 434 the ICE server configuration after the local offer has been created. 435 In order to support these clients, the WHIP endpoint MAY also include 436 the ICE server configuration on the responses to an authenticated 437 OPTIONS request sent to the WHIP endpoint URL sent before the POST 438 requests. 440 It COULD be also possible to configure the STUN/TURN server URLs with 441 long term credentials provided by either the broadcasting service or 442 an external TURN provider on the WHIP client overriding the values 443 provided by the WHIP endpoint. 445 4.5. Authentication and authorization 447 WHIP endpoints and resources MAY require the HTTP request to be 448 authenticated using an HTTP Authorization header with a Bearer token 449 as specified in [RFC6750] section 2.1. WHIP clients MUST implement 450 this authentication and authorization mechanism and send the HTTP 451 Authorization header in all HTTP requests sent to either the WHIP 452 endpoint or resource. 454 The nature, syntax and semantics of the bearer token as well as how 455 to distribute it to the client is outside the scope of this document. 456 Some examples of the kind of tokens that could be used are, but are 457 not limited to, JWT tokens as per [RFC6750] and [RFC8725] or a shared 458 secret stored on a database. The tokens are typically made available 459 to the end user alongside the WHIP endpoint url and configured on the 460 WHIP clients. 462 WHIP endpoints and resources COULD perform the authentication and 463 authorization by encoding an authentication token within the urls for 464 the WHIP endpoints or resources instead. In case the WHIP client is 465 not configured to use a bearer token the HTTP Authorization header 466 must not be sent in any request. 468 4.6. Simulcast and scalable video coding 470 Both simulcast and scalable video coding (including K-SVC modes) MAY 471 be supported by both the media servers and WHIP clients through 472 negotiation in the SDP offer/answer. 474 If the client supports simulcast and wants to enable it for 475 publishing, it MUST negotiate the support in the SDP offer according 476 to the procedures in [RFC8853] section 5.3. A server accepting a 477 simulcast offer MUST create an answer according to the procedures 478 [RFC8853] section 5.3.2. 480 4.7. Protocol extensions 482 In order to support future extensions to be defined for the WHIP 483 protocol, a common procedure for registering and announcing the new 484 extensions is defined. 486 Protocol extensions supported by the WHIP server MUST be advertised 487 to the WHIP client on the 201 Created response to the initial HTTP 488 POST request sent to the WHIP endpoint. The WHIP endpoint MUST 489 return one Link header for each extension with the extension "rel" 490 type attribute and the URI for the HTTP resource that will be 491 available for receiving requests related to that extension. 493 Protocol extensions are optional for both WHIP clients and servers. 494 WHIP clients MUST ignore any Link attribute with an unknown "rel" 495 attribute value and WHIP servers MUST NOT require the usage of any of 496 the extensions. 498 Each protocol extension MUST register a unique "rel" attribute values 499 at IANA starting with the prefix: "urn:ietf:params:whip:". 501 For example, taking a potential extension of server to client 502 communication using server sent events as specified in 503 https://html.spec.whatwg.org/multipage/server-sent- 504 events.html#server-sent-events, the URL for connecting to the server 505 side event resource for the published stream will be returned in the 506 initial HTTP "201 Created" response with a "Link" header and a "rel" 507 attribute of "urn:ietf:params:whip:server-sent-events". 509 The HTTP 201 response to the HTTP POST request would look like: 511 HTTP/1.1 201 Created 512 Content-Type: application/sdp 513 Location: https://whip.example.org/resource/id 514 Link: ;rel="urn:ietf:params:whip:server-side-events" 516 5. Security Considerations 518 HTTPS SHALL be used in order to preserve the WebRTC security model. 520 6. IANA Considerations 522 The link relation types below have been registered by IANA per 523 Section 4.2 of [RFC8288]. 525 6.1. Link Relation Type: ice-server 527 Relation Name: ice-server 529 Description: Describe the STUN and TURN servers that can be used by 530 the ICE Agent to establish a connection with a peer. 532 Reference: TBD 534 7. Acknowledgements 536 8. Normative References 538 [I-D.draft-alvestrand-rtcweb-gateways] 539 Alvestrand, H. and U. Rauschenbach, "WebRTC Gateways", 540 Work in Progress, Internet-Draft, draft-alvestrand-rtcweb- 541 gateways-02, 9 March 2015, 542 . 545 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 546 Requirement Levels", BCP 14, RFC 2119, 547 DOI 10.17487/RFC2119, March 1997, 548 . 550 [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework 551 for Establishing a Secure Real-time Transport Protocol 552 (SRTP) Security Context Using Datagram Transport Layer 553 Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May 554 2010, . 556 [RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization 557 Framework: Bearer Token Usage", RFC 6750, 558 DOI 10.17487/RFC6750, October 2012, 559 . 561 [RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 562 Protocol (HTTP/1.1): Conditional Requests", RFC 7232, 563 DOI 10.17487/RFC7232, June 2014, 564 . 566 [RFC7675] Perumal, M., Wing, D., Ravindranath, R., Reddy, T., and M. 567 Thomson, "Session Traversal Utilities for NAT (STUN) Usage 568 for Consent Freshness", RFC 7675, DOI 10.17487/RFC7675, 569 October 2015, . 571 [RFC8288] Nottingham, M., "Web Linking", RFC 8288, 572 DOI 10.17487/RFC8288, October 2017, 573 . 575 [RFC8489] Petit-Huguenin, M., Salgueiro, G., Rosenberg, J., Wing, 576 D., Mahy, R., and P. Matthews, "Session Traversal 577 Utilities for NAT (STUN)", RFC 8489, DOI 10.17487/RFC8489, 578 February 2020, . 580 [RFC8725] Sheffer, Y., Hardt, D., and M. Jones, "JSON Web Token Best 581 Current Practices", BCP 225, RFC 8725, 582 DOI 10.17487/RFC8725, February 2020, 583 . 585 [RFC8829] Uberti, J., Jennings, C., and E. Rescorla, Ed., 586 "JavaScript Session Establishment Protocol (JSEP)", 587 RFC 8829, DOI 10.17487/RFC8829, January 2021, 588 . 590 [RFC8840] Ivov, E., Stach, T., Marocco, E., and C. Holmberg, "A 591 Session Initiation Protocol (SIP) Usage for Incremental 592 Provisioning of Candidates for the Interactive 593 Connectivity Establishment (Trickle ICE)", RFC 8840, 594 DOI 10.17487/RFC8840, January 2021, 595 . 597 [RFC8843] Holmberg, C., Alvestrand, H., and C. Jennings, 598 "Negotiating Media Multiplexing Using the Session 599 Description Protocol (SDP)", RFC 8843, 600 DOI 10.17487/RFC8843, January 2021, 601 . 603 [RFC8853] Burman, B., Westerlund, M., Nandakumar, S., and M. Zanaty, 604 "Using Simulcast in Session Description Protocol (SDP) and 605 RTP Sessions", RFC 8853, DOI 10.17487/RFC8853, January 606 2021, . 608 [RFC8863] Holmberg, C. and J. Uberti, "Interactive Connectivity 609 Establishment Patiently Awaiting Connectivity (ICE PAC)", 610 RFC 8863, DOI 10.17487/RFC8863, January 2021, 611 . 613 Authors' Addresses 615 Sergio Garcia Murillo 616 CoSMo Software 617 Email: sergio.garcia.murillo@cosmosoftware.io 619 Alexandre Gouaillard 620 CoSMo Software 621 Email: alex.gouaillard@cosmosoftware.io