idnits 2.17.1 draft-hurst-quic-rtp-tunnelling-00.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (30 October 2020) is 1245 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-19) exists of draft-ietf-httpbis-semantics-12 == Outdated reference: A later version (-10) exists of draft-ietf-quic-datagram-01 == Outdated reference: A later version (-34) exists of draft-ietf-quic-recovery-32 == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-32 ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) == Outdated reference: A later version (-34) exists of draft-ietf-quic-tls-32 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Hurst 3 Internet-Draft BBC Research & Development 4 Intended status: Informational 30 October 2020 5 Expires: 3 May 2021 7 QRT: QUIC RTP Tunnelling 8 draft-hurst-quic-rtp-tunnelling-00 10 Abstract 12 QUIC is a UDP-based transport protocol for stream-orientated, 13 congestion-controlled, secure, multiplexed data transfer. RTP 14 carries real-time data between endpoints, and the accompanying 15 control protocol RTCP allows monitoring and control of the transfer 16 of such data. With RTP and RTCP being agnostic to the underlying 17 transport protocol, it is possible to multiplex both the RTP and 18 associated RTCP flows into a single QUIC connection to take advantage 19 of QUIC features such as low-latency setup and strong TLS-based 20 security. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on 3 May 2021. 39 Copyright Notice 41 Copyright (c) 2020 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 46 license-info) in effect on the date of publication of this document. 47 Please review these documents carefully, as they describe your rights 48 and restrictions with respect to this document. Code Components 49 extracted from this document must include Simplified BSD License text 50 as described in Section 4.e of the Trust Legal Provisions and are 51 provided without warranty as described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 1.1. Conventions and Definitions . . . . . . . . . . . . . . . 3 57 1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Use Cases for an RTP Mapping over QUIC . . . . . . . . . . . 4 59 2.1. Live Event Contribution Feed . . . . . . . . . . . . . . 4 60 2.2. Audio and Video Conference via a Central Server . . . . . 5 61 3. QRT Sessions . . . . . . . . . . . . . . . . . . . . . . . . 5 62 4. RTP Sessions . . . . . . . . . . . . . . . . . . . . . . . . 5 63 4.1. QRT Flow Identifier . . . . . . . . . . . . . . . . . . . 6 64 4.2. RTCP Mapping . . . . . . . . . . . . . . . . . . . . . . 7 65 4.2.1. Restricted RTCP Packet Types . . . . . . . . . . . . 7 66 5. Loss Recovery and Retransmission . . . . . . . . . . . . . . 8 67 6. Using the Session Description Protocol to Advertise QRT 68 Sessions . . . . . . . . . . . . . . . . . . . . . . . . 8 69 6.1. Using the Session Description Protocol to Advertise QRT 70 Sessions using RTP Retransmission . . . . . . . . . . . . 9 71 7. Exposing Round-Trip Time to RTP applications . . . . . . . . 10 72 8. Protocol Identifier . . . . . . . . . . . . . . . . . . . . . 10 73 8.1. Draft Version Identification . . . . . . . . . . . . . . 10 74 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 75 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 76 10.1. Registration of Protocol Identification String . . . . . 11 77 10.2. Registration of SDP Protocol Identifier . . . . . . . . 11 78 10.3. Registration of SDP Attribute Field . . . . . . . . . . 11 79 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 80 11.1. Normative References . . . . . . . . . . . . . . . . . . 12 81 11.2. Informative References . . . . . . . . . . . . . . . . . 13 82 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 14 83 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 85 1. Introduction 87 The Real-time Transport Protocol (RTP) [RFC3550] provides end-to-end 88 network transport functions suitable for applications transmitting 89 data, such as audio and video, over multicast or unicast network 90 services for the purposes of telephony, video streaming, conferencing 91 and other real-time applications. 93 The QUIC transport protocol is a UDP-based stream-orientated and 94 encrypted transport protocol aimed at offering improvements over the 95 common combination of TCP and TLS for web applications. Compared 96 with TCP+TLS, QUIC offers much reduced connection set-up times, 97 improved stream multiplexing aware congestion control, and the 98 ability to perform connection migration. QUIC offers two modes of 99 data transfer: 101 * Reliable transfer using STREAM frames, as specified in 102 [QUIC-TRANSPORT], [QUIC-RECOVERY], etc. 104 * Unreliable transfer using DATAGRAM extension frames, as specified 105 in [QUIC-DATAGRAM]. 107 RTP has traditionally been run over UDP or DTLS to achieve timely but 108 unreliable data transfer. For use cases such as real-time audio and 109 video transmission, the underlying media codecs can be considered in 110 part fault-tolerant to an unreliable transport mechanism, with 111 missing data from the stream resulting in glitches in the media 112 presentation, such as missing video frames or gaps in audio playback. 113 By purposely using an unreliable transport mechanism, applications 114 can minimise the added latency that would otherwise result from 115 managing the large packet reception buffers needed to account for 116 network reordering or transport protocol retransmission. 118 1.1. Conventions and Definitions 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 122 "OPTIONAL" in this document are to be interpreted as described in BCP 123 14 [RFC2119] [RFC8174] when, and only when, they appear in all 124 capitals, as shown here. 126 Packet and frame diagrams in this document use the format described 127 in [QUIC-TRANSPORT]. 129 1.2. Definitions 131 * Endpoint: host capable of being a participant in a QRT session. 133 * QRT session: A QUIC connection carrying one or more RTP sessions, 134 each with or without an accompanying RTCP channel. 136 * Client: The endpoint which initiates the QUIC connection. 138 * Server: The endpoint which accepts the incoming QUIC connection. 140 2. Use Cases for an RTP Mapping over QUIC 142 The following sections describe some possible use cases for an RTP 143 and RTCP mapping over QUIC, hereafter QRT. The examples were chosen 144 to illustrate some basic concepts, and are neither an exhaustive list 145 of possible use cases nor a limitation on what QRT may be used for. 147 2.1. Live Event Contribution Feed 149 A news organisation wishes to provide a two-way link to a live event 150 for distribution as part of an item in a news programme hosted in a 151 studio with a news anchor. The single camera remote production crew 152 will include a camera operator, sound technician and the reporter. 153 In order to deliver this experience, the following media flows are 154 required: 156 * A high-quality video feed from the remote camera to the news 157 organisation's gallery; 159 * One or more audio feeds for microphones at the event, including an 160 ambient microphone attached to the camera, a lapel microphone for 161 the reporter, and a handheld microphone to conduct interviews, all 162 synchronized; 164 * A video feed of the programme output from the gallery, after 165 mixing for local monitoring and for use on a comfort monitor; 167 * An audio feed from the anchor in the studio to the reporter; 169 * A two-way audio feed from the gallery to the remote production 170 crew for talkback communication; 172 * A tally light feed for the remote camera. 174 These media flows may be realised as a group of RTP sessions, some of 175 which must be synchronised together. The talkback streams do not 176 require any tight synchronisation with other streams in the group, 177 whereas the camera video feed and various microphone feeds need to be 178 tightly synchronised together. 180 At the event, a production machine running a software package that 181 includes a QRT client has two connections to the Internet; a high- 182 speed fibre link and a bonded cellular network link for backup. 184 In order to prevent a bad actor on the network path being able to 185 tamper with the contribution, all communication between the news 186 organisation's gallery and the remote production need to be 187 encrypted. Because all the data is flowing between the same two 188 endpoints, only a single QRT session is required, and the various RTP 189 sessions that are encapsulated by the QRT session are (de)multiplexed 190 at each end. 192 During the live contribution, an accident cuts the fibre connection 193 to the remote production crew. Using the QUIC connection migration 194 mechanism presented in Section 9 of [QUIC-TRANSPORT], the QRT session 195 migrates from the fibre link onto the backup cellular link. This 196 preserves the state of the RTP sessions across a network migration 197 event, and all sessions continue. 199 2.2. Audio and Video Conference via a Central Server 201 A teleconference is taking place across multiple sites using a 202 centralised server. All participants connect to this single server, 203 and the server acts as an RTP mixer to reduce the number of RTP 204 sessions being sent to all participants, as well as re-encoding the 205 streams for efficiency reasons. 207 One participant of this conference has connected via mobile phone. 208 However, when the participant enters the range of a previously- 209 associated WiFi network, the mobile phone switches its network 210 connection across to this new network. The QRT session can then 211 migrate across, and the participant is able to continue the call with 212 minimal interruption. 214 3. QRT Sessions 216 A QRT session is defined as a QUIC connection which carries one or 217 more RTP sessions (including any associated RTCP flows) using 218 "DATAGRAM" frames, as specified in Section 4. Those RTP sessions may 219 be part of one or more RTP multimedia sessions, and a multimedia 220 session may be comprised of RTP sessions carried in one or more QRT 221 sessions. 223 A QRT session inherits the standard QUIC handshake as specified in 224 [QUIC-TRANSPORT], and all communications between endpoints are 225 secured as specified in [QUIC-TLS]. 227 4. RTP Sessions 229 QRT allows multiple RTP sessions to be carried in a single QRT 230 session. Each RTP session is operated independently of all the 231 others, and individually discriminated by an QRT Flow Identifier, as 232 described below in Section 4.1. 234 RTP and RTCP packets are carried in QUIC "DATAGRAM" frames, as 235 described in [QUIC-DATAGRAM]. QUIC allows multiple QUIC frames to be 236 carried within a single QUIC packet, so multiple RTP/RTCP packets for 237 one (or more) RTP sessions may therefore be carried in a single QUIC 238 packet, subject to the network path MTU. If multiple RTP packets are 239 to be carried within a single QUIC packet, then all but the final 240 "DATAGRAM" frame must specify the length of the datagram, since the 241 RTP packet header does not provide its own length field. 242 [QUIC-DATAGRAM] specifies that if a "DATAGRAM" frame is received 243 without a Length field, then this "DATAGRAM" frame extends to the end 244 of the QUIC packet. 246 4.1. QRT Flow Identifier 248 [RFC3550] specifies that RTP sessions are distinguished by pairs of 249 transport addresses. However, since QUIC allows for connections to 250 migrate between transport address associations, and because we wish 251 to multiplex multiple RTP session flows over a single QRT session, 252 this profile of RTP amends this statement and instead introduces a 253 flow identifier to distinguish between RTP sessions. The QRT Flow 254 Identifier is a 62-bit unsigned integer between 0 and 2^62 - 1. 256 This specification does not mandate a means by which QRT Flow 257 Identifiers are allocated for use within QRT sessions. An example 258 mapping for this is discussed in Section 6 below. Implementations 259 SHOULD allocate flow identifiers that make the most efficient use of 260 the variable length integer packing mechanism, by not using flow 261 identifiers greater than can be expressed in the smallest variable 262 length integer field until all available flow identifiers have been 263 used. 265 The flow of packets belonging to an RTP session is identified using 266 an RTP Session Flow Identifier header carried in the "DATAGRAM" frame 267 payload before each RTP/RTCP packet. This flow identifier is encoded 268 as a variable-length integer, as defined in [QUIC-TRANSPORT]. 270 QRT Datagram Payload { 271 QRT Flow Identifier (i), 272 RTP/RTCP Packet (..) 273 } 275 Figure 1: QRT Datagram Payload 277 Similar to QUIC stream IDs, the least significant bit (0x1) of the 278 QRT Flow Identifier distinguishes between an RTP and an RTCP packet 279 flow. "DATAGRAM" frames which carry RTP packet flows set this bit to 280 0, and "DATAGRAM" frames which carry RTCP packet flows set this bit 281 to 1. As a consequence, RTP packet flows have even numbered QRT Flow 282 Identifiers, and RTCP packet flows have odd-numbered QRT Flow 283 Identifiers. Carriage of RTCP packets is discussed further in 284 Section 4.2. 286 +=======================+=====================================+ 287 | Least significant bit | Flow identifier category | 288 +=======================+=====================================+ 289 | 0x0 | RTP packet flow for an RTP session | 290 +-----------------------+-------------------------------------+ 291 | 0x1 | RTCP packet flow for an RTP session | 292 +-----------------------+-------------------------------------+ 294 Table 1: RTP session flow identifer categories 296 *Author's Note:* The author welcomes comments on whether a state 297 model of RTP session flows would be beneficial. Currently, once 298 an RTP session has been used by an endpoint, it is then considered 299 an extant RTP session and implementations would have to keep any 300 resources allocated to that RTP session until the QRT session is 301 complete. In addition, how should endpoints react to receiving 302 packets for unknown QRT flow identifiers? 304 4.2. RTCP Mapping 306 An RTP session may have RTCP packet flows associated with it. These 307 flows are carried with different QRT Flow Identifiers, as described 308 in Section 4.1. The QRT Flow Identifier of the RTCP packet flow is 309 always the value of the RTP packet flow QRT Flow Identifier + 1. For 310 example, for an RTP packet flow using flow identifier 18, the RTCP 311 packet flow would use flow identifier 19. 313 Since RTCP packets contain a length field in their header, 314 implementations MAY combine several RTCP packets pertaining to the 315 same RTP session into a single "DATAGRAM" frame. Alternatively, 316 implementations MAY choose to carry these RTCP packets each in their 317 own "DATAGRAM" frame. 319 4.2.1. Restricted RTCP Packet Types 321 *Author's Note:* I have specifically avoided calling this section 322 "Prohibited RTCP packet types" for the time being, so as to not 323 unnecessarily exclude the carriage of these packet types for the 324 purposes of experimentation. Similarly, most statements below use 325 SHOULD NOT instead of MUST NOT. The author welcomes comments on 326 whether the document should prohibit the sending of some or all of 327 these packet types. 329 In order to reduce duplication, the following RTCP packet types 330 SHOULD NOT be sent in a QRT session: 332 * The "Generic NACK" packet. [RFC4585] states that Generic NACK 333 feedback SHOULD NOT be used if the underlying transport protocol 334 is capable of providing similar feedback information to the 335 sender. Since all "DATAGRAM" frames are ACK-eliciting, QUIC 336 already fulfils this requirement. 338 * The "Loss RLE" Extended Report (XR) packet defined in [RFC3611] 339 contains information that should already be known to both ends of 340 the QUIC connection by means of the loss detection mechanism 341 specified in [QUIC-RECOVERY]. 343 * The "Port Mapping" packet type defined in [RFC6284] is used to 344 negotiate UDP port pairs for the carriage of RTP and RTCP packets 345 to peers. This does not apply in a QRT session, because the QUIC 346 endpoints manage the UDP port association(s) for the QUIC 347 connection as a whole. 349 5. Loss Recovery and Retransmission 351 *Author's Note:* Do we want to mandate (make a MUST) doing 352 session-multiplexing instead of SSRC-multiplexing for RTP 353 retransmission? 355 [RFC4588] specifies two schemes to support retransmission in the case 356 of RTP packet loss. Since QRT natively supports RTP session 357 multiplexing on a single QUIC connection, endpoints choosing to 358 implement retransmission SHOULD do so using the session-multiplexing 359 scheme. 361 The selection of a new QRT Flow Identifier to use for the 362 retransmission RTP session is implementation-specific. Section 6.1 363 specifies how the mapping between original and retransmission RTP 364 sessions is expressed using the Session Description Protocol (SDP). 366 6. Using the Session Description Protocol to Advertise QRT Sessions 368 [RFC4566] describes a format for advertising multimedia sessions, 369 which is used by protocols such as [RFC3261]. 371 This specification introduces a new SDP value attribute ""qrtflow"" 372 as a means of assigning QRT Flow Identifiers to RTP and RTCP packet 373 flows. Its formatting in SDP is described by the following ABNF 374 [RFC5234]: 376 qrtflow-attribute = "a=qrtflow:" qrt-flow-id 377 qrt-flow-id = 1*DIGIT ; unsigned 62-bit integer 379 Per Section 4.1 the value of the "qrt-flow-id" is required to be an 380 even number. (The odd-numbered RTCP flow associated with the RTP 381 session is not explicitly signalled in the SDP object.) 383 The example in Figure 2 below shows a hypothetical QRT server 384 advertising an endpoint to use for live contribution. It instructs a 385 prospective client to send a VC2-encoded video stream and a Vorbis- 386 encoded audio stream on two separate RTP sessions. In addition, it 387 uses the SDP grouping framework described in [RFC5888] to ensure lip 388 synchronisation between both of those RTP sessions. 390 v=0 391 o=gfreeman 1594130940 1594135167 IN IP6 qrt.example.org 392 s=Live Event Contribution 393 c=IN IP6 2001:db8::7361:6d68 394 t=1594130980 1594388466 395 a=group:LS 1 2 396 m=video 443 RTP/QRT 96 397 a=qrtflow:0 398 a=rtpmap:96 vc2 399 a=mid:1 400 a=sendonly 401 m=audio 443 RTP/QRT 97 402 a=qrtflow:2 403 a=rtpmap:97 vorbis 404 a=mid:2 405 a=sendonly 407 Figure 2: SDP object describing a QRT session 409 Since the value of a QRT Flow Identifier for an associated RTCP flow 410 is specified in Section 4.2, SDP advertisements containing the 411 "a=qrtflow:" attribute MUST NOT contain an instance of the "a=rtcp:" 412 attribute as defined in [RFC3605]. 414 6.1. Using the Session Description Protocol to Advertise QRT Sessions 415 using RTP Retransmission 417 The example in Figure 3 below shows a hypothetical QRT session 418 advertisement for a bidirectional RTP session carrying an MPEG-2 419 Transport Stream in each direction on QRT Flow Identifier 0, and a 420 corresponding pair of retransmission flows on QRT Flow Identifier 2. 422 v=0 423 o=gfreeman 1594130940 1594135167 IN IP6 qrt.example.org 424 s=Live Event Contribution 425 c=IN IP6 2001:db8::4242:4351:5254 426 t=1594130980 1594388466 427 m=video 443 RTP/QRT 33 428 a=qrtflow:0 429 m=video 443 RTP/QRT 96 430 a=rtpmap:97 rtx/90000 431 a=fmtp:96 apt=33;rtx-time=4000 432 a=qrtflow:2 434 Figure 3: SDP object describing a QRT session with RTP retransmission 436 7. Exposing Round-Trip Time to RTP applications 438 Section 5 of [QUIC-RECOVERY] specifies a mechanism for QUIC endpoints 439 to estimate the rount-trip time (RTT) of a connection. QRT 440 implementations SHOULD expose the values of "min_rtt", "smoothed_rtt" 441 and "rttvar" for each network path to the RTP layer, and they MAY use 442 these values either alone or in combination with RTCP messages to 443 discern the round-trip time of the QRT session. 445 *Author's Note:* The author welcomes comments on how appropriate 446 these QUIC RTT measurements are to the RTP layer. 448 8. Protocol Identifier 450 The QRT protocol specified in this document is identified by the 451 Application-Layer Protocol Negotiation (ALPN) [RFC7301] identifier 452 "qrt". 454 8.1. Draft Version Identification 456 *RFC Editor's Note:* Please remove this section prior to 457 publication of a final version of this document. 459 Only implementations of the final, published RFC can identify 460 themselves as "qrt". Until such an RFC exists, implementations MUST 461 NOT identify themselves using this string. Implementations of draft 462 versions of the protocol MUST add the string "-h" and the 463 corresponding draft number to the identifier. For example, draft- 464 hurst-quic-rtp-tunnelling-00 is identified using the string "qrt- 465 h00". 467 Non-compatible experiments that are based on these draft versions 468 MUST append the string "-" and an experiment name to the identifier. 469 For example, an experimental implementation based on draft-hurst- 470 quic-rtp-tunnelling-00 which uses extension features not registered 471 with the appropriate IANA registry might identify itself as "qrt-h00- 472 extension-foo". Note that any label MUST conform to the "token" 473 syntax defined in Section 5.7.2 of [HTTP-SEMANTICS]. Experimenters 474 are encouraged to coordinate their experiments. 476 9. Security Considerations 478 Implementations of the protocol defined in this specification are 479 subject to the security considerations discussed in [QUIC-TRANSPORT] 480 and [QUIC-TLS]. 482 10. IANA Considerations 484 10.1. Registration of Protocol Identification String 486 This document creates a new registration for the identification of 487 the QUIC RTP Tunnelling protocol in the "Application-Layer Protocol 488 Negotiation (ALPN) Protocol IDs" registry established by [RFC7301]. 490 The "qrt" string identifies RTP sessions multiplexed and carried over 491 a QUIC transport layer: 493 Protocol: QUIC RTP Tunnelling 495 Identification Sequence: 0x71 0x72 0x74 ("qrt") 497 Specification: This document, Section 8 499 10.2. Registration of SDP Protocol Identifier 501 This document creates a new registration for the SDP Protocol 502 Identifier ("proto") "RTP/QRT" in the SDP Protocol Identifiers 503 ("proto") registry established by [RFC4566]. 505 The "RTP/QRT" string identifies a profile of RTP where sessions are 506 multiplexed and carried over a QUIC transport layer: 508 SDP Protocol Name: RTP/QRT 510 Reference: This document, Section 6 512 10.3. Registration of SDP Attribute Field 514 This document creates a new registration for the SDP Attribute Field 515 ("att-field") "qrtflow" in the SDP Attribute Field registry 516 established by [RFC4566]. 518 SDP Attribute Field: "qrtflow" 520 Reference: This document, Section 6 522 11. References 524 11.1. Normative References 526 [HTTP-SEMANTICS] 527 Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, 528 Ed., "HTTP Semantics", Work in Progress, Internet-Draft, 529 draft-ietf-httpbis-semantics-12, 530 . 533 [QUIC-DATAGRAM] 534 Pauly, T., Ed., Kinnear, E., Ed., and D. Schinazi, Ed., 535 "An Unreliable Datagram Extension to QUIC", Work in 536 Progress, Internet-Draft, draft-ietf-quic-datagram-01, 537 . 539 [QUIC-RECOVERY] 540 Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection 541 and Congestion Control", Work in Progress, Internet-Draft, 542 draft-ietf-quic-recovery-32, 543 . 545 [QUIC-TRANSPORT] 546 Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 547 Multiplexed and Secure Transport", Work in Progress, 548 Internet-Draft, draft-ietf-quic-transport-32, 549 . 552 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 553 Requirement Levels", BCP 14, RFC 2119, 554 DOI 10.17487/RFC2119, March 1997, 555 . 557 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 558 Jacobson, "RTP: A Transport Protocol for Real-Time 559 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 560 July 2003, . 562 [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute 563 in Session Description Protocol (SDP)", RFC 3605, 564 DOI 10.17487/RFC3605, October 2003, 565 . 567 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 568 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 569 July 2006, . 571 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 572 Hakenberg, "RTP Retransmission Payload Format", RFC 4588, 573 DOI 10.17487/RFC4588, July 2006, 574 . 576 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 577 Specifications: ABNF", STD 68, RFC 5234, 578 DOI 10.17487/RFC5234, January 2008, 579 . 581 [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description 582 Protocol (SDP) Grouping Framework", RFC 5888, 583 DOI 10.17487/RFC5888, June 2010, 584 . 586 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 587 "Transport Layer Security (TLS) Application-Layer Protocol 588 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 589 July 2014, . 591 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 592 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 593 May 2017, . 595 11.2. Informative References 597 [QUIC-TLS] Thomson, M., Ed. and S. Turner, Ed., "Using Transport 598 Layer Security (TLS) to Secure QUIC", Work in Progress, 599 Internet-Draft, draft-ietf-quic-tls-32, 600 . 602 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 603 A., Peterson, J., Sparks, R., Handley, M., and E. 604 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 605 DOI 10.17487/RFC3261, June 2002, 606 . 608 [RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., 609 "RTP Control Protocol Extended Reports (RTCP XR)", 610 RFC 3611, DOI 10.17487/RFC3611, November 2003, 611 . 613 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 614 "Extended RTP Profile for Real-time Transport Control 615 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 616 DOI 10.17487/RFC4585, July 2006, 617 . 619 [RFC6284] Begen, A., Wing, D., and T. Van Caenegem, "Port Mapping 620 between Unicast and Multicast RTP Sessions", RFC 6284, 621 DOI 10.17487/RFC6284, June 2011, 622 . 624 Acknowledgments 626 The author would like to thank Richard Bradbury, David Waring, Colin 627 Perkins, Joerg Ott, and Lucas Pardue for their helpful comments on 628 both the design and review of this document. 630 Author's Address 632 Sam Hurst 633 BBC Research & Development 635 Email: sam.hurst@bbc.co.uk