idnits 2.17.1 draft-ietf-wish-whip-01.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 (20 October 2021) is 919 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 8829 (Obsoleted by RFC 9429) ** Obsolete normative reference: RFC 8843 (Obsoleted by RFC 9143) Summary: 3 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: 23 April 2022 20 October 2021 7 WebRTC-HTTP ingestion protocol (WHIP) 8 draft-ietf-wish-whip-01 10 Abstract 12 While WebRTC has been very sucessful 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 (wich 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 servics 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 23 April 2022. 57 Copyright Notice 59 Copyright (c) 2021 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 Simplified BSD License text 68 as described in Section 4.e of the Trust Legal Provisions and are 69 provided without warranty as described in the Simplified 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 . . . . . . . . . . . . . . . . . . . 8 79 4.3. Load balancing and redirections . . . . . . . . . . . . . 8 80 4.4. STUN/TURN server configuration . . . . . . . . . . . . . 8 81 4.5. Authentication and authorization . . . . . . . . . . . . 9 82 4.6. Simulcast and scalable video coding . . . . . . . . . . . 10 83 4.7. Protocol extensions . . . . . . . . . . . . . . . . . . . 10 84 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 85 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 86 6.1. Link Relation Type: urn:ietf:params:whip:ice-server . . . 11 87 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 88 8. Normative References . . . . . . . . . . . . . . . . . . . . 11 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 91 1. Introduction 93 RTCWEB standardized JSEP ([RFC8829]), a mechanishm used to control 94 the setup, management, and teardown of a multimedia session, how to 95 apply it using the SDP Offer/Answer model and all the formats for the 96 data sent over the wire (media, codec, encryption, ...). Also, 97 WebRTC intentionally does not specify a signaling transport protocol 98 at application level. This flexibility has allowed the 99 implementation of a wide range of services. However, those services 100 are typically standalone silos which don't require interoperability 101 with other services or leverage the existence of tools that can 102 communicate with 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 A WHIP resource receving a PATH request with new ICE candidates, but 265 which does not perform an ICE restart, MUST return a 204 No content 266 response without body. 268 PATCH /resource/id HTTP/1.1 269 Host: whip.example.com 270 Content-Type: application/trickle-ice-sdpfrag 271 Content-Length: 548 273 a=ice-ufrag:EsAw 274 a=ice-pwd:P2uYro0UCOQ4zxjKXaWCBui1 275 m=audio RTP/AVP 0 276 a=mid:0 277 a=candidate:1387637174 1 udp 2122260223 192.0.2.1 61764 typ host generation 0 ufrag EsAw network-id 1 278 a=candidate:3471623853 1 udp 2122194687 198.51.100.1 61765 typ host generation 0 ufrag EsAw network-id 2 279 a=candidate:473322822 1 tcp 1518280447 192.0.2.1 9 typ host tcptype active generation 0 ufrag EsAw network-id 1 280 a=candidate:2154773085 1 tcp 1518214911 198.51.100.2 9 typ host tcptype active generation 0 ufrag EsAw network-id 2 281 a=end-of-candidates 283 HTTP/1.1 204 No Content 285 Figure 2: Trickle ICE request 287 If the HTTP PATCH request results in an ICE restart, the WHIP 288 resource SHALL return a 200 OK with an "application/trickle-ice- 289 sdpfrag" body containing the new ICE username fragment and password 290 and, optionaly, the new set of ICE candidates for the media server. 292 PATCH /resource/id HTTP/1.1 293 Host: whip.example.com 294 Content-Type: application/trickle-ice-sdpfrag 295 Content-Length: 54 297 a=ice-ufrag:ysXw 298 a=ice-pwd:vw5LmwG4y/e6dPP/zAP9Gp5k 300 HTTP/1.1 200 OK 301 Content-Type: application/trickle-ice-sdpfrag 302 Content-Length: 102 304 a=ice-lite 305 a=ice-ufrag:289b31b754eaa438 306 a=ice-pwd:0b66f472495ef0ccac7bda653ab6be49ea13114472a5d10a 308 Figure 3: ICE restart request 310 As the HTTP PATCH request sent by a WHIP client may be received out 311 of order by the WHIP resource, the WHIP resource SHOULD keep track of 312 the previous values of the ICE username fragment and client used by 313 the WHIP client. If an HTTP PATCH request is received with a 314 previously used ICE username fragment and password by the client, the 315 WHIP endpoint SHALL NOT perform and ICE restart but reject the 316 request with a 409 Conflict response instead. 318 4.2. WebRTC constraints 320 In order to reduce the complexity of implementing WHIP in both 321 clients and media servers, some restrictions regarding WebRTC usage 322 are made. 324 SDP bundle SHALL be used by both the WHIP client and the media 325 server. The SDP offer created by the WHIP client MUST include the 326 bundle-only attribute in all m-lines as per [RFC8843]. Also, RTCP 327 muxing SHALL be supported by both the WHIP client and the media 328 server. 330 Unlike [RFC5763] a WHIP client MAY use a setup attribute value of 331 setup:active in the SDP offer, in which case the WHIP endpoint MUST 332 use a setup attribute value of setup:passive in the SDP answer. 334 4.3. Load balancing and redirections 336 WHIP endpoints and media servers MAY not be colocated on the same 337 server so it is possible to load balance incoming requests to 338 different media servers. WHIP clients SHALL support HTTP redirection 339 via the 307 Temporary Redirect response code in the initial HTTP 340 response to the WHIP endpoint URL. The WHIP resource URL MUST be a 341 final one, and redirections are not required to be supported for the 342 PATCH and DELETE request sent to it. 344 In case of high load, the WHIP endpoints MAY return a 503 (Service 345 Unavailable) status code indicating that the server is currently 346 unable to handle the request due to a temporary overload or scheduled 347 maintenance, which will likely be alleviated after some delay. 349 The WHIP endpoint MAY send a Retry-After header field indicating the 350 minimum time that the user agent is asked to wait before issuing the 351 redirected request. 353 4.4. STUN/TURN server configuration 355 The WHIP endpoint MAY return ICE server configuration urls and 356 credentials usable by the client in the 201 Created response to the 357 HTTP POST request to the WHIP endpoint url. 359 Each ICE server will be returned on a Link header with a "rel" 360 attribribute value of "ice-server" where the Link target URI is the 361 ICE server URL and the credentials are encoded in the Link target 362 attributes as follows: 364 * username: If this the Link header represents a TURN server, and 365 creadential-type is "password", then this attribute specifies the 366 username to use with that TURN server. 368 * credential: If credentialType is "password", credential represents 369 a long-term authentication password, as described in [RFC8489], 370 Section 10.2. 372 * creadential-type: If this RTCIceServer object represents a TURN 373 server, then this attribute specifies how credential should be 374 used when that TURN server requests authorization. The default 375 value if the attribute is not present is "password". 377 Link: stun:stun.example.net; 378 Link: turn:turn.example.net?transport=udp; rel="ice-server"; username="user"; credential: "myPassword"; credential-type: "password"; 379 Link: turn:turn.example.net?transport=tcp; rel="ice-server"; username="user"; credential: "myPassword"; credential-type: "password"; 380 Link: turns:turn.example.net?transport=tcp; rel="ice-server"; username="user"; credential: "myPassword"; credential-type: "password"; 382 Figure 4: Example ICE server configuration 384 There are some webrtc implementations that do not support updating 385 the ICE server configuration after the local offer has been created. 386 In order to support these clients, the WHIP endpoint MAY also include 387 the ICE server configuration on the responses to an authenticated 388 OPTIONS request sent to the WHIP endpoint URL sent before the POST 389 requests. 391 It COULD be also possible to configure the STUN/TURN server URLs with 392 long term credentials provided by either the broadcasting service or 393 an external TURN provider on the WHIP client overriding the values 394 provided by the WHIP endpoint. 396 4.5. Authentication and authorization 398 WHIP endpoints and resources MAY require the HTTP request to be 399 authenticated using an HTTP Authorization header with a Bearer token 400 as specified in [RFC6750] section 2.1. WHIP clients MUST implemenent 401 this authentication and authorization mechanism and send the HTTP 402 Authorization header in all HTTP request sent to either the WHIP 403 endpoint or resource. 405 The nature, syntax and semantics of the bearer token as well as how 406 to distribute it to the client is outside the scope of this document. 407 Some examples ot the kind of tokens that could be used are, but are 408 not limited to, JWT tokens as per [RFC6750] and [RFC8725] or a shared 409 secret stored on a database. The tokens are typically made available 410 to the end user alongside the WHIP endpoint url and configured on the 411 WHIP clients. 413 WHIP endpoints and resources COULD perform the authentication and 414 authorization by encoding an authentication token withing the urls 415 for the WHIP endpoints or resources instead. In case the WHIP client 416 is not configured to use a bearer token the HTTP Authorization header 417 must not be sent in any request. 419 4.6. Simulcast and scalable video coding 421 Both simulcast and scalable video coding (including K-SVC modes) MAY 422 be supported by both the media servers and WHIP clients through 423 negotiation in the SDP offer/answer. 425 If the client supports simulcast and wants to enable it for 426 publishing, it MUST negotiate the support in the SDP offer according 427 to the procedures in [RFC8853] section 5.3. A server accepting a 428 simulcast offer MUST create an answer accoding to the procedures 429 [RFC8853] section 5.3.2. 431 4.7. Protocol extensions 433 In order to support future extensions to be defined for the WHIP 434 protocol, a common procedure for registering and announcing the new 435 extensions is defined. 437 Protocol extensions supported by the WHIP server MUST be advertised 438 to the WHIP client on the 201 Created response to the initial HTTP 439 POST request sent to the WHIP endpoint. The WHIP endpoint MUST 440 return one Link header for each extension with the extension "rel" 441 type attribute and the URI for the HTTP resource that will be 442 available for receiving requests related to that extension. 444 Protocol extensions are optional for both WHIP clients and servers. 445 WHIP clients MUST ignore any Link attribute with an unknown "rel" 446 attribute value and WHIP servers MUST NOT require the usage of any of 447 the extensions. 449 Each protocol extension MUST register an unique "rel" attribute 450 values at IANA starting with the prefix: "urn:ietf:params:whip:". 452 For example, taking a potential extension of server to client 453 communication using server sent events as specified in 454 https://html.spec.whatwg.org/multipage/server-sent- 455 events.html#server-sent-events, the URL for connecting to the server 456 side event resource for the published stream will be returned in the 457 initial HTTP "201 Created" response with a "Link" header and a "rel" 458 attribute of "urn:ietf:params:whip:server-sent-events". 460 The HTTP 201 response to the HTTP POST request would look like: 462 HTTP/1.1 201 Created 463 Content-Type: application/sdp 464 Location: https://whip.example.org/resource/id 465 Link: ;rel="urn:ietf:params:whip:server-side-events" 467 5. Security Considerations 469 HTTPS SHALL be used in order to preserve the WebRTC security model. 471 6. IANA Considerations 473 The link relation types below have been registered by IANA per 474 Section 4.2 of [RFC8288]. 476 6.1. Link Relation Type: urn:ietf:params:whip:ice-server 478 Relation Name: ice-server Description: Describe the STUN and TURN 479 servers that can be used by the ICE Agent to establish a connection 480 with a peer. Reference: TBD 482 7. Acknowledgements 484 8. Normative References 486 [I-D.draft-alvestrand-rtcweb-gateways] 487 Alvestrand, H. and U. Rauschenbach, "WebRTC Gateways", 488 Work in Progress, Internet-Draft, draft-alvestrand-rtcweb- 489 gateways-02, 9 March 2015, 490 . 493 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 494 Requirement Levels", BCP 14, RFC 2119, 495 DOI 10.17487/RFC2119, March 1997, 496 . 498 [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework 499 for Establishing a Secure Real-time Transport Protocol 500 (SRTP) Security Context Using Datagram Transport Layer 501 Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May 502 2010, . 504 [RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization 505 Framework: Bearer Token Usage", RFC 6750, 506 DOI 10.17487/RFC6750, October 2012, 507 . 509 [RFC7675] Perumal, M., Wing, D., Ravindranath, R., Reddy, T., and M. 510 Thomson, "Session Traversal Utilities for NAT (STUN) Usage 511 for Consent Freshness", RFC 7675, DOI 10.17487/RFC7675, 512 October 2015, . 514 [RFC8288] Nottingham, M., "Web Linking", RFC 8288, 515 DOI 10.17487/RFC8288, October 2017, 516 . 518 [RFC8489] Petit-Huguenin, M., Salgueiro, G., Rosenberg, J., Wing, 519 D., Mahy, R., and P. Matthews, "Session Traversal 520 Utilities for NAT (STUN)", RFC 8489, DOI 10.17487/RFC8489, 521 February 2020, . 523 [RFC8725] Sheffer, Y., Hardt, D., and M. Jones, "JSON Web Token Best 524 Current Practices", BCP 225, RFC 8725, 525 DOI 10.17487/RFC8725, February 2020, 526 . 528 [RFC8829] Uberti, J., Jennings, C., and E. Rescorla, Ed., 529 "JavaScript Session Establishment Protocol (JSEP)", 530 RFC 8829, DOI 10.17487/RFC8829, January 2021, 531 . 533 [RFC8840] Ivov, E., Stach, T., Marocco, E., and C. Holmberg, "A 534 Session Initiation Protocol (SIP) Usage for Incremental 535 Provisioning of Candidates for the Interactive 536 Connectivity Establishment (Trickle ICE)", RFC 8840, 537 DOI 10.17487/RFC8840, January 2021, 538 . 540 [RFC8843] Holmberg, C., Alvestrand, H., and C. Jennings, 541 "Negotiating Media Multiplexing Using the Session 542 Description Protocol (SDP)", RFC 8843, 543 DOI 10.17487/RFC8843, January 2021, 544 . 546 [RFC8853] Burman, B., Westerlund, M., Nandakumar, S., and M. Zanaty, 547 "Using Simulcast in Session Description Protocol (SDP) and 548 RTP Sessions", RFC 8853, DOI 10.17487/RFC8853, January 549 2021, . 551 [RFC8863] Holmberg, C. and J. Uberti, "Interactive Connectivity 552 Establishment Patiently Awaiting Connectivity (ICE PAC)", 553 RFC 8863, DOI 10.17487/RFC8863, January 2021, 554 . 556 Authors' Addresses 558 Sergio Garcia Murillo 559 CoSMo Software 561 Email: sergio.garcia.murillo@cosmosoftware.io 563 Alexandre Gouaillard 564 CoSMo Software 566 Email: alex.gouaillard@cosmosoftware.io