idnits 2.17.1 draft-ietf-avtcore-rfc5285-bis-14.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 (August 2, 2017) is 2457 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) == Missing Reference: 'RFCXXXX' is mentioned on line 912, but not defined == Missing Reference: 'RFC XXXX' is mentioned on line 871, but not defined ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) == Outdated reference: A later version (-54) exists of draft-ietf-mmusic-sdp-bundle-negotiation-38 == Outdated reference: A later version (-19) exists of draft-ietf-mmusic-sdp-mux-attributes-16 -- Obsolete informational reference (is this intentional?): RFC 5285 (Obsoleted by RFC 8285) -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 AVTCore D. Singer 3 Internet-Draft Apple, Inc. 4 Obsoletes: 5285 (if approved) H. Desineni 5 Intended status: Standards Track Qualcomm 6 Expires: February 3, 2018 R. Even, Ed. 7 Huawei Technologies 8 August 2, 2017 10 A General Mechanism for RTP Header Extensions 11 draft-ietf-avtcore-rfc5285-bis-14.txt 13 Abstract 15 This document provides a general mechanism to use the header 16 extension feature of RTP (the Real-Time Transport Protocol). It 17 provides the option to use a small number of small extensions in each 18 RTP packet, where the universe of possible extensions is large and 19 registration is de-centralized. The actual extensions in use in a 20 session are signaled in the setup information for that session. This 21 document obsoletes RFC5285. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on February 3, 2018. 40 Copyright Notice 42 Copyright (c) 2017 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 59 3. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . 3 60 4. Packet Design . . . . . . . . . . . . . . . . . . . . . . . . 4 61 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 4.1.1. Transmission Considerations . . . . . . . . . . . . . 5 63 4.1.2. Header Extension Type Considerations . . . . . . . . 6 64 4.2. One-Byte Header . . . . . . . . . . . . . . . . . . . . . 7 65 4.3. Two-Byte Header . . . . . . . . . . . . . . . . . . . . . 9 66 5. SDP Signaling Design . . . . . . . . . . . . . . . . . . . . 10 67 6. SDP Signaling for support of mixed one byte and two bytes 68 header extensions. . . . . . . . . . . . . . . . . . . . . . 12 69 7. SDP Offer/Answer . . . . . . . . . . . . . . . . . . . . . . 13 70 8. BNF Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 16 71 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 72 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 73 10.1. Identifier Space for IANA to Manage . . . . . . . . . . 17 74 10.2. Registration of the SDP extmap Attribute . . . . . . . . 19 75 10.3. Registration of the SDP extmap-allow-mixed Attribute . . 19 76 11. Changes from RFC5285 . . . . . . . . . . . . . . . . . . . . 20 77 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 78 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 79 13.1. Normative References . . . . . . . . . . . . . . . . . . 21 80 13.2. Informative References . . . . . . . . . . . . . . . . . 22 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 83 1. Introduction 85 The RTP specification [RFC3550] provides a capability to extend the 86 RTP header. It defines the header extension format and rules for its 87 use in Section 5.3.1. The existing header extension method permits 88 at most one extension per RTP packet, identified by a 16-bit 89 identifier and a 16-bit length field specifying the length of the 90 header extension in 32-bit words. 92 This mechanism has two conspicuous drawbacks. First, it permits only 93 one header extension in a single RTP packet. Second, the 94 specification gives no guidance as to how the 16-bit header extension 95 identifiers are allocated to avoid collisions. 97 This specification removes the first drawback by defining a backward- 98 compatible and extensible means to carry multiple header extension 99 elements in a single RTP packet. It removes the second drawback by 100 defining that these extension elements are named by URIs, defining an 101 IANA registry for extension elements defined in IETF specifications, 102 and a Session Description Protocol (SDP) method for mapping between 103 the naming URIs and the identifier values carried in the RTP packets. 105 This header extension applies to RTP/AVP (the Audio/Visual Profile) 106 and its extensions. 108 This document obsoletes [RFC5285] and removes a limitation from 109 RFC5285 that did not allow sending both one-byte and two-byte header 110 extensions in the same RTP stream. 112 2. Requirements Notation 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 116 document are to be interpreted as described in [RFC2119]. 118 3. Design Goals 120 The goal of this design is to provide a simple mechanism whereby 121 multiple identified extensions can be used in RTP packets, without 122 the need for formal registration of those extensions but nonetheless 123 avoiding collision. 125 This mechanism provides an alternative to the practice of burying 126 associated metadata into the media format bit stream. This has often 127 been done in media data sent over fixed-bandwidth channels. Once 128 this is done, a decoder for the specific media format needs to 129 extract the metadata. Also, depending on the media format, the 130 metadata can be added at the time of encoding the media so that the 131 bit-rate used for the metadata is taken into account. But the 132 metadata can be unknown at that time. Inserting metadata at a later 133 time can cause a decode and re-encode to meet bit-rate requirements. 135 In some cases, a more appropriate, higher-level mechanism may be 136 available, and if so, it can be used. For cases where a higher-level 137 mechanism is not available, it is better to provide a mechanism at 138 the RTP level than have the metadata be tied to a specific form of 139 media data. 141 4. Packet Design 143 4.1. General 145 The following design is fit into the "header extension" of the RTP 146 extension, as described above. 148 The presence and format of this header extension and its contents are 149 negotiated or defined out-of-band, such as through signaling (see 150 below for SDP signaling). The 16-bit identifier for the two forms of 151 RTP extension defined here is only an architectural constant (e.g., 152 for use by network analyzers); it is the negotiation/definition 153 (e.g., in SDP) that is the definitive indication that this header 154 extension is present. 156 The RTP specification [RFC3550] states that RTP "is designed so that 157 the header extension may be ignored by other interoperating 158 implementations that have not been extended". The intent of this 159 restriction is that RTP header extensions MUST NOT be used to extend 160 RTP itself in a manner that is backwards incompatible with non- 161 extended implementations. For example, a header extension is not 162 allowed to change the meaning or interpretation of the standard RTP 163 header fields, or of the RTCP Control Protocol (RTCP). Header 164 extensions MAY carry metadata in addition to the usual RTP header 165 information, provided the RTP layer can function if that metadata is 166 missing. For example, RTP header extensions can be used to carry 167 data that's also sent in RTCP, as an optimisation to lower latency, 168 since they'll fall back to the original, non-optimised, behaviour if 169 the header extension is not present. The use of header extensions to 170 convey information that will, if missing, disrupt the behaviour of a 171 higher layer application that builds on top of RTP is only acceptable 172 if this doesn't affect interoperability at the RTP layer. For 173 example, applications that use the SDP BUNDLE extension with the MID 174 RTP header extension [I-D.ietf-mmusic-sdp-bundle-negotiation] to 175 correlate RTP streams with SDP m= lines likely won't work with full 176 functionality if the MID is missing, but the operation of the RTP 177 layer of those applications will be unaffected. Support for RTP 178 header extensions based on this memo is negotiated using, for 179 example, SDP Offer/Answer [RFC3264]; intermediaries aware of the RTP 180 header extensions are advised to be cautious when removing or 181 generating RTP header extensions see section 4.7 of [RFC7667]. 183 The RTP header extension is formed as a sequence of extension 184 elements, with possible padding. Each extension element has a local 185 identifier and a length. The local identifiers MAY be mapped to a 186 larger namespace in the negotiation (e.g., session signaling). 188 4.1.1. Transmission Considerations 190 As is good network practice, data should only be transmitted when 191 needed. The RTP header extension SHOULD only be present in a packet 192 if that packet also contains one or more extension elements, as 193 defined here. An extension element SHOULD only be present in a 194 packet when needed; the signaling setup of extension elements 195 indicates only that those elements can be present in some packets, 196 not that they are in fact present in all (or indeed, any) packets. 198 Some general considerations for getting the header extensions 199 delivered to the receiver: 201 1. The probability for packet loss and burst loss determine how many 202 repetitions of the header extensions will be required to reach a 203 targeted delivery probability, and if burst loss is likely, what 204 distribution would be needed to avoid getting all repetitions of 205 the header extensions lost in a single burst. 207 2. If a set of packets are all needed to enable decoding, there is 208 commonly no reason for including the header extension in all of 209 these packets, as they share fate. Instead, at most one instance 210 of the header extension per independently decodable set of media 211 data would be a more efficient use of the bandwidth. 213 3. How early the Header Extension item information is needed, from 214 the first received RTP data or only after some set of packets are 215 received, can guide if the header extension(s) should be in all 216 of the first N packets or be included only once per set of 217 packets, for example once per video frame. 219 4. The use of RTP level robustness mechanisms, such as RTP 220 retransmission [RFC4588], or Forward Error Correction, e.g., 221 [RFC5109] may treat packets differently from a robustness 222 perspective, and header extensions should be added to packets 223 that get a treatment corresponding to the relative importance of 224 receiving the information. 226 As a summary, the number of header extension transmissions should be 227 tailored to a desired probability of delivery taking the receiver 228 population size into account. For the very basic case, N repetitions 229 of the header extensions should be sufficient, but may not be 230 optimal. N is selected so that the header extension target delivery 231 probability reaches 1-P^N, where P is the probability of packet loss. 232 For point to point or small receiver populations, it might also be 233 possible to use feedback, such as RTCP, to determine when the 234 information in the header extensions has reached all receivers and 235 stop further repetitions. Feedback that can be used includes the 236 RTCP XR Loss RLE report block [RFC3611], which will indicate 237 successful delivery of particular packets. If the RTP/AVPF Transport 238 Layer Feedback Messages for generic NACK [RFC4585] is used, it can 239 indicate the failure to deliver an RTP packet with the header 240 extension, thus indicating the need for further repetitions. The 241 normal RTCP report blocks can also provide an indicator of successful 242 delivery, if no losses are indicated for a reporting interval 243 covering the RTP packets with the header extension. Note that loss 244 of an RTCP packet reporting on an interval where RTP header extension 245 packets were sent, does not necessarily mean that the RTP header 246 extension packets themselves were lost. 248 4.1.2. Header Extension Type Considerations 250 Each extension element in a packet has a local identifier (ID) and a 251 length. The local identifiers present in the stream MUST have been 252 negotiated or defined out-of-band. There are no static allocations 253 of local identifiers. Each distinct extension MUST have a unique ID. 254 The ID value 0 is reserved for padding and MUST NOT be used as a 255 local identifier. 257 An extension element with an ID value equal 0 MUST NOT have len field 258 greater than 0. If such an extension element is encountered, its 259 length field MUST be ignored, processing of the entire extension MUST 260 terminate at that point, and only the extension elements present 261 prior to the element with ID 0 and len field greater than 0 SHOULD be 262 considered. 264 There are two variants of the extension: one-byte and two-byte 265 headers. Since it is expected that (a) the number of extensions in 266 any given RTP session is small and (b) the extensions themselves are 267 small, the one-byte header form is preferred and MUST be supported by 268 all receivers. A stream MUST contain only one-byte or only two-byte 269 headers unless it is known that all recipients support mixing, either 270 by SDP Offer/Answer [RFC3264] negotiation (see section 6) or by out- 271 of-band knowledge. Each RTP packet with an RTP header extension 272 following this specification will indicate if it contains one or two 273 byte header extensions through the use of the "defined by profile" 274 field. Extension element types that do not match the header 275 extension format, i.e. one- or two-byte, MUST NOT be used in that RTP 276 packet. Transmitters SHOULD NOT use the two-byte form when all 277 extensions are small enough for the one-byte header form. 278 Transmitters that intend to send the two-byte form SHOULD negotiate 279 the use of IDs above 14 if they want to let the Receivers know that 280 they intend to use two-byte form, for example if the RTP header 281 extension is longer than 16 bytes. A transmitter may be aware that 282 an intermediary may add RTP header extensions; in this case the 283 transmitter SHOULD use two-byte form. 285 A sequence of extension elements, possibly with padding, forms the 286 header extension defined in the RTP specification. There are as many 287 extension elements as fit into the length as indicated in the RTP 288 header extension length. Since this length is signaled in full 289 32-bit words, padding bytes are used to pad to a 32-bit boundary. 290 The entire extension is parsed byte-by-byte to find each extension 291 element (no alignment is needed), and parsing stops at the earlier of 292 the end of the entire header extension, or in "one-byte headers only" 293 case, on encountering an identifier with the reserved value of 15. 295 In both forms, padding bytes have the value of 0 (zero). They MAY be 296 placed between extension elements, if desired for alignment, or after 297 the last extension element, if needed for padding. A padding byte 298 does not supply the ID of an element, nor the length field. When a 299 padding byte is found, it is ignored and the parser moves on to 300 interpreting the next byte. 302 Note carefully that the one-byte header form allows for data lengths 303 between 1 and 16 bytes, by adding 1 to the signaled length value 304 (thus, 0 in the length field indicates 1 byte of data follows). This 305 allows for the important case of 16-byte payloads. This addition is 306 not performed for the two-byte headers, where the length field 307 signals data lengths between 0 and 255 bytes. 309 Use of RTP header extensions will reduce the efficiency of RTP header 310 compression, since the header extension will be sent uncompressed 311 unless the RTP header compression module is updated to recognize the 312 extension header. If header extensions are present in some packets, 313 but not in others, this can also reduce compression efficiency by 314 requiring an update to the fixed header to be conveyed when header 315 extensions start or stop being sent. The interactions of the RTP 316 header extension and header compression is explored further in 317 [RFC2508] and [RFC3095]. 319 4.2. One-Byte Header 321 In the one-byte header form of extensions, the 16-bit value required 322 by the RTP specification for a header extension, labeled in the RTP 323 specification as "defined by profile", MUST have the fixed bit 324 pattern 0xBEDE (the pattern was picked for the trivial reason that 325 the first version of this specification was written on May 25th the 326 feast day of the Venerable Bede). 328 Each extension element MUST start with a byte containing an ID and a 329 length: 331 0 332 0 1 2 3 4 5 6 7 333 +-+-+-+-+-+-+-+-+ 334 | ID | len | 335 +-+-+-+-+-+-+-+-+ 337 The 4-bit ID is the local identifier of this element in the range 338 1-14 inclusive. In the signaling section, this is referred to as the 339 valid range. 341 The local identifier value 15 is reserved for future extension and 342 MUST NOT be used as an identifier. If the ID value 15 is 343 encountered, its length field MUST be ignored, processing of the 344 entire extension MUST terminate at that point, and only the extension 345 elements present prior to the element with ID 15 SHOULD be 346 considered. 348 The 4-bit length is the number minus one of data bytes of this header 349 extension element following the one-byte header. Therefore, the 350 value zero in this field indicates that one byte of data follows, and 351 a value of 15 (the maximum) indicates element data of 16 bytes. 352 (This permits carriage of 16-byte values, which is a common length of 353 labels and identifiers, while losing the possibility of zero-length 354 values -- which would often be padded anyway.) 356 An example header extension, with three extension elements, and some 357 padding follows: 359 0 1 2 3 360 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 | 0xBE | 0xDE | length=3 | 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 | ID | L=0 | data | ID | L=1 | data... 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 ...data | 0 (pad) | 0 (pad) | ID | L=3 | 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 | data | 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 4.3. Two-Byte Header 373 In the two-byte header form, the 16-bit value defined by the RTP 374 specification for a header extension, labeled in the RTP 375 specification as "defined by profile", is defined as shown below. 377 0 1 378 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 | 0x100 |appbits| 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 The appbits field is 4 bits that are application-dependent and MAY be 384 defined to be any value or meaning, and are outside the scope of this 385 specification. For the purposes of signaling, this field is treated 386 as a special extension value assigned to the local identifier 256. 387 If no extension has been specified through configuration or signaling 388 for this local identifier value 256, the appbits field SHOULD be set 389 to all 0s by the sender and MUST be ignored by the receiver. 391 Each extension element starts with a byte containing an ID and a byte 392 containing a length: 394 0 1 395 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 | ID | length | 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 The 8-bit ID is the local identifier of this element in the range 401 1-255 inclusive. In the signaling section, the range 1-256 is 402 referred to as the valid range, with the values 1-255 referring to 403 extension elements, and the value 256 referring to the 4-bit field 404 'appbits' (above). Note that there is one ID space for both one-byte 405 and two-byte form. This means that the lower values (1-14) can be 406 used in the 4-bit ID field in the one-byte header format with the 407 same meanings. 409 The 8-bit length field is the length of extension data in bytes not 410 including the ID and length fields. The value zero indicates there 411 is no data following. 413 An example header extension, with three extension elements, and some 414 padding follows: 416 0 1 2 3 417 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 | 0x10 | 0x00 | length=3 | 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 | ID | L=0 | ID | L=1 | 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 | data | 0 (pad) | ID | L=4 | 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 | data | 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 5. SDP Signaling Design 430 The indication of the presence of this extension, and the mapping of 431 local identifiers used in the header extension to a larger namespace, 432 MUST be performed out-of-band, for example, as part of an SDP Offer/ 433 Answer [RFC3264]. This section defines such signaling in SDP. 435 A usable mapping MUST use IDs in the valid range, and each ID in this 436 range MUST be used only once for each media (or only once if the 437 mappings are session level). Mappings that do not conform to these 438 rules MAY be presented, for instance, during SDP Offer/Answer 439 [RFC3264] negotiation as described in the next section, but remapping 440 to conformant values is necessary before they can be applied. 442 Each extension is named by a URI. That URI MUST be absolute, and 443 precisely identifies the format and meaning of the extension. URIs 444 that contain a domain name SHOULD also contain a month-date in the 445 form mmyyyy. The definition of the element and assignment of the URI 446 MUST have been authorized by the owner of the domain name on or very 447 close to that date. (This avoids problems when domain names change 448 ownership.) If the resource or document defines several extensions, 449 then the URI MUST identify the actual extension in use, e.g., using a 450 fragment or query identifier (characters after a '#' or '?' in the 451 URI). 453 Rationale: the use of URIs provides for a large, unallocated space, 454 and gives documentation on the extension. The URIs do not have to be 455 de-referencable, in order to permit confidential or experimental use, 456 and to cover the case when extensions continue to be used after the 457 organization that defined them ceases to exist. 459 An extension URI with the same attributes MUST NOT appear more than 460 once applying to the same stream, i.e., at session level or in the 461 declarations for a single stream at media level. (The same extension 462 can, of course, be used for several streams, and can appear with 463 different extensionattributes for the same stream.) 465 For extensions defined in RFCs, the URI used SHOULD be a URN starting 466 "urn:ietf:params:rtp-hdrext:" and followed by a registered, 467 descriptive name. 469 The registration requirements are detailed in the IANA Considerations 470 section, below. 472 An example (this is only an example), where 'avt-example-metadata' is 473 the hypothetical name of a header extension, might be: 475 urn:ietf:params:rtp-hdrext:avt-example-metadata 477 An example name not from the IETF (this is only an example) might be: 479 http://example.com/082005/ext.htm#example-metadata 481 The mapping MAY be provided per media stream (in the media-level 482 section(s) of SDP, i.e., after an "m=" line) or globally for all 483 streams (i.e., before the first "m=" line, at session level). The 484 definitions MUST be either all session level or all media level; it 485 is not permitted to mix the two styles. In addition, as noted above, 486 the IDs used MUST be unique in each media section of the SDP, or 487 unique in the session for session-level SDP declarations. 489 Each local identifier potentially used in the stream is mapped to an 490 extension identified by a URI using an attribute of the form: 492 a=extmap:["/"] 494 where is a URI, as above, is the local identifier (ID) 495 of this extension and is an integer in the valid range (0 is reserved 496 for padding in both forms, and 15 is reserved in the one-byte header 497 form, as noted above), and is one of "sendonly", 498 "recvonly", "sendrecv", or "inactive" (without the quotes) with 499 relation to the device being configured. 501 The formal BNF syntax is presented in a later section of this 502 specification. 504 Example: 506 a=extmap:1 http://example.com/082005/ext.htm#ttime 508 a=extmap:2/sendrecv http://example.com/082005/ext.htm#xmeta short 510 When SDP signaling is used for the RTP session, it is the presence of 511 the 'extmap' attribute(s) that is diagnostic that this style of 512 header extensions is used, not the magic number ("BEDE" or "100") 513 indicated above. 515 6. SDP Signaling for support of mixed one byte and two bytes header 516 extensions. 518 In order to allow for backward interoperability with systems that do 519 not support mixing of one byte and two bytes header extensions this 520 document defines the "a=extmap-allow-mixed" Session Description 521 Protocol (SDP) [RFC4566] attribute to indicate if the participant is 522 capable of supporting this new mode. The attribute takes no value. 523 This attribute can be used at the session or media levels. A 524 participant that proposes the use of this mode SHALL itself support 525 the reception of mixed one byte and two bytes header extensions. 527 If SDP Offer/Answer [RFC3264] is supported and used,the negotiation 528 for mixed one byte and two bytes extension MUST be negotiated using 529 SDP Offer/Answer [RFC3264]. In the absence of negotiations using SDP 530 Offer/Answer, for example when declarative SDP is used, mixed headers 531 MUST NOT occur unless the transmitter has some (out of band) 532 knowledge that all potential recipients support this mode. 534 The formal definition of this attribute is: 536 Name: extmap-allow-mixed 538 Value: none 540 Usage Level: session, media 542 Charset Dependent: no 544 Example: 546 a=extmap-allow-mixed 548 When doing SDP Offer/Answer [RFC3264] an offering client that wishes 549 to use both one and two bytes extensions MUST include the attribute 550 "a= extmap-allow-mixed " in the SDP offer. If "a= extmap-allow-mixed 551 " is present in the offer SDP, the answerer that supports this mode 552 and wishes to use it SHALL include the "a=extmap-allow-mixed " 553 attribute in the answer. In the cases where the attribute has been 554 excluded, both clients SHALL NOT use mixed one bytes and two bytes 555 extensions in the same RTP stream but MAY use one-byte or two-bytes 556 form exclusively (see section 4.1.2). 558 When used in [I-D.ietf-mmusic-sdp-bundle-negotiation] this attribute 559 is specified as identical category for the 560 [I-D.ietf-mmusic-sdp-mux-attributes]. This allows for only a subset 561 of the m-lines in the bundle group to offer extmap-allow-mixed. When 562 an answerer supporting the extmap-allow-mix attribute receives an 563 offer where only some of the m-lines in the bundle group include the 564 extmap-allow-mixed attribute, the answerer MUST receive this offer 565 and support mixed one-byte and two-bytes only for those m-lines. 566 Transmitters MUST only send RTP header extensions using mixed on 567 those RTP streams originating from those media sources (m=) blocks 568 that includes extmap-allow-mixed, and are RECOMMENDED to support 569 receiving mixed on all RTP streams being received in an RTP session 570 where at least one bundled m= block is indicating extmap-allow-mixed. 572 7. SDP Offer/Answer 574 The simple signaling described above for the extmap attribute MAY be 575 enhanced in an SDP Offer/Answer [RFC3264] context, to permit: 577 o asymmetric behavior (extensions sent in only one direction), 579 o the offer of mutually exclusive alternatives, or 581 o the offer of more extensions than can be sent in a single session. 583 A direction attribute MAY be included in an extmap; without it, the 584 direction implicitly inherits, of course, from the stream direction, 585 or is "sendrecv" for session-level attributes or extensions of 586 "inactive" streams. The direction MUST be one of "sendonly", 587 "recvonly", "sendrecv", or "inactive" as specified in [RFC3264] 589 Extensions, with their directions, MAY be signaled for an "inactive" 590 stream. It is an error to use an extension direction incompatible 591 with the stream direction (e.g., a "sendonly" attribute for a 592 "recvonly" stream). 594 If an offer or answer contains session-level mappings (and hence no 595 media-level mappings), and different behavior is desired for each 596 stream, then the entire set of extension map declarations MAY be 597 moved into the media-level section(s) of the SDP. (Note that this 598 specification does not permit mixing global and local declarations, 599 to make identifier management easier.) 601 If an extension map is offered as "sendrecv", explicitly or 602 implicitly, and asymmetric behavior is desired, the SDP answer MAY be 603 changed to modify or add direction qualifiers for that extension. 605 If an extension is marked as "sendonly" and the answerer desires to 606 receive it, the extension MUST be marked as "recvonly" in the SDP 607 answer. An answerer that has no desire to receive the extension or 608 does not understand the extension SHOULD remove it from the SDP 609 answer. An answerer MAY want to respond that he supports the 610 extension and does not want to receive it at the moment but may offer 611 to receive it in a future offer, will mark the extension as 612 "inactive" 614 If an extension is marked as "recvonly" and the answerer desires to 615 send it, the extension MUST be marked as "sendonly" in the SDP 616 answer. An answerer that has no desire to, or is unable to, send the 617 extension SHOULD remove it from the SDP answer. An answerer MAY want 618 to respond that he support this extension yet has no intention of 619 sending it now but may offer to send it in a future offer by marking 620 the extension as "inactive" 622 Local identifiers in the valid range inclusive in an offer or answer 623 must not be used more than once per media section (including the 624 session-level section). The local identifiers MUST be unique in an 625 RTP session and the same identifier MUST be used for the same offered 626 extension in the answer. A session update MAY change the direction 627 qualifiers of extensions under use. A session update MAY add or 628 remove extension(s). Identifiers values in the valid range MUST NOT 629 be altered (remapped). 631 Note that, under this rule, the same local identifier cannot be used 632 for two extensions for the same media, even when one is "sendonly" 633 and the other "recvonly", as it would then be impossible to make 634 either of them sendrecv (since re-numbering is not permitted either). 636 If a party wishes to offer mutually exclusive alternatives, then 637 multiple extensions with the same identifier in the extended range 638 4096-4351 MAY be offered; the answerer SHOULD select at most one of 639 the offered extensions with the same identifier, and remap it to a 640 free identifier in the valid range, for that extension to be usable. 642 Similarly, if more extensions are offered than can be fit in the 643 valid range, identifiers in the range 4096-4351 MAY be offered; the 644 answerer SHOULD choose those that are desired, and remap them to a 645 free identifier in the valid range. 647 An answerer may copy an extmap for an identifier in the extended 648 range into the answer to indicate to the offerer that it supports 649 that extension. Of course, such an extension cannot be used, since 650 there is no way to specify them in an extension header. If needed, 651 the offerer or answerer can update the session to assign a valid 652 identifier to that extension URI. 654 Rationale: the range 4096-4351 for these negotiation identifiers is 655 deliberately restricted to allow expansion of the range of valid 656 identifiers in future. 658 Either party MAY include extensions in the stream other than those 659 negotiated, or those negotiated as "inactive", for example, for the 660 benefit of intermediate nodes. Only extensions that appeared with an 661 identifier in the valid range in SDP originated by the sender can be 662 sent. 664 Example (port numbers, RTP profiles, payload IDs and rtpmaps, etc. 665 all omitted for brevity): 667 The offer: 669 a=extmap:1 URI-toffset 670 a=extmap:14 URI-obscure 671 a=extmap:4096 URI-gps-string 672 a=extmap:4096 URI-gps-binary 673 a=extmap:4097 URI-frametype 674 m=video 675 a=sendrecv 676 m=audio 677 a=sendrecv 679 The answerer is interested in receiving GPS in string format only on 680 video, but cannot send GPS at all. It is not interested in 681 transmission offsets on audio, and does not understand the URI- 682 obscure extension. It therefore moves the extensions from session 683 level to media level, and adjusts the declarations: 685 m=video 686 a=sendrecv 687 a=extmap:1 URI-toffset 688 a=extmap:2/recvonly URI-gps-string 689 a=extmap:3 URI-frametype 690 m=audio 691 a=sendrecv 692 a=extmap:1/sendonly URI-toffset 694 When using [I-D.ietf-mmusic-sdp-bundle-negotiation] to bundle 695 multiple m-lines the extmap attribute falls under the special 696 category of [I-D.ietf-mmusic-sdp-mux-attributes]. All the m-lines in 697 a bundle group are considered to be part of the same local identifier 698 (ID) space. If an RTP header extension, i.e. a particular extension 699 URI and configuration using , is offered in 700 multiple m-lines that are part of the same bundle group it MUST use 701 the same ID in all of these m-lines. Each m-line in a bundle group 702 can include different RTP header extensions allowing for example 703 audio and video sources to use different sets of RTP header 704 extensions. It SHALL be assumed that for any RTP header extension, 705 difference in configuration using any of the is 706 important and need to be preserved to any receiver, thus requiring 707 assignment of different IDs. Any RTP header extension that does not 708 match this assumption MUST explicitly provide rules for what are 709 compatible configurations that can be sent with the same ID. The 710 directionality of the RTP header extensions in each m-line of the 711 bundle group are handled as the non-bundled case. This allows for 712 specifying different directionality for each of the repeated 713 extension URI in bundled group. 715 8. BNF Syntax 717 The syntax definition below uses ABNF according to [RFC5234]. The 718 syntax element 'URI' is defined in [RFC3986] (only absolute URIs are 719 permitted here). The syntax element 'extmap' is an attribute as 720 defined in [RFC4566], i.e., "a=" precedes the extmap definition. 721 Specific extensionattributes are defined by the specification that 722 defines a specific extension name; there can be several. 724 Name: extmap 726 Value: extmap-value 728 Syntax: 730 extmap-value = mapentry SP extensionname 731 [SP extensionattributes] 733 mapentry = "extmap:" 1*5DIGIT ["/" direction] 735 extensionname = URI 737 extensionattributes = byte-string 739 direction = "sendonly" / "recvonly" / "sendrecv" / "inactive" 741 URI = 743 byte-string = 745 SP = 747 DIGIT = 749 9. Security Considerations 751 This document defines only a place to transmit information; the 752 security implications of each of the extensions must be discussed 753 with those extensions. 755 Extensions usage is negotiated using [RFC3264] so integrity 756 protection and end-to-end authentication MUST be implemented. The 757 security considerations of [RFC3264] MUST be followed, to prevent, 758 for example, extension usage blocking. 760 Header extensions have the same security coverage as the RTP header 761 itself. When Secure Real-time Transport Protocol (SRTP) [RFC3711] is 762 used to protect RTP sessions, the RTP payload can be both encrypted 763 and integrity protected, while the RTP header is either unprotected 764 or integrity protected. In order to prevent DOS attacks, for 765 example, by changing the header extension, integrity protection 766 SHOULD be used. Lower layer security protection like DTLS[RFC6347] 767 MAY be used. RTP header extensions can carry sensitive information 768 for which participants in multimedia sessions want confidentiality. 769 RFC6904 [RFC6904] provides a mechanism, extending the mechanisms of 770 SRTP, to selectively encrypt RTP header extensions in SRTP. 772 The RTP application designer needs to consider their security needs, 773 that includes cipher strength for SRTP packets in general and what 774 that means for the integrity and confidentiality of the RTP header 775 extensions. As defined by RFC6904 [RFC6904] the encryption stream 776 cipher for the header extension is dependent on the chosen SRTP 777 cipher. 779 Other security options for securing RTP are discussed in [RFC7201]. 781 10. IANA Considerations 783 This document updates the IANA consideration to reference this 784 document and adds a new SDP attribute in section 10.3 786 Note to IANA : change RFCxxxx to this RFC number and remove the note. 788 10.1. Identifier Space for IANA to Manage 790 The mapping from the naming URI form to a reference to a 791 specification is managed by IANA. Insertion into this registry is 792 under the requirements of "Expert Review" as defined in [RFC8126]. 794 The IANA will also maintain a server that contains all of the 795 registered elements in a publicly accessible space. 797 Here is the formal declaration to comply with the IETF URN Sub- 798 namespace specification [RFC3553]. 800 o Registry name: RTP Compact Header Extensions 802 o Specification: RFC 5285 and RFCs updating RFC 5285. 804 o Information required: 806 A. The desired extension naming URI 808 B. A formal reference to the publicly available specification 810 C. A short phrase describing the function of the extension 812 D. Contact information for the organization or person making the 813 registration 815 For extensions defined in RFCs, the URI SHOULD be of the form 816 urn:ietf:params:rtp-hdrext:, and the formal reference is the RFC 817 number of the RFC documenting the extension. 819 o Review process: Expert review is REQUIRED. The expert review 820 SHOULD check the following requirements: 822 1. that the specification is publicly available; 824 2. that the extension complies with the requirements of RTP, and 825 this specification, for header extensions (specifically, that 826 the header extension can be ignored or discarded without 827 breaking the RTP layer); 829 3. that the extension specification is technically consistent (in 830 itself and with RTP), complete, and comprehensible; 832 4. that the extension does not duplicate functionality in 833 existing IETF specifications (including RTP itself), or other 834 extensions already registered; 836 5. that the specification contains a security analysis regarding 837 the content of the header extension; 839 6. that the extension is generally applicable, for example point- 840 to-multipoint safe, and the specification correctly describes 841 limitations if they exist; and 843 7. that the suggested naming URI form is appropriately chosen and 844 unique. 846 8. That for [I-D.ietf-mmusic-sdp-bundle-negotiation] multiplexed 847 m-lines, any RTP header extension with difference in 848 configurations of that do not require 849 assignment of different IDs, MUST explicitly indicate this and 850 provide rules for what are compatible configurations that can 851 be sent with the same ID. 853 o Size and format of entries: a mapping from a naming URI string to 854 a formal reference to a publicly available specification, with a 855 descriptive phrase and contact information. 857 o Initial assignments: none. 859 10.2. Registration of the SDP extmap Attribute 861 IANA is requested to update the registration of the extmap SDP 862 [RFC4566] attribute. 864 o Contact Name and email address: IETF, contacted via 865 mmusic@ietf.org, or a successor address designated by IESG 866 Attribute Name: extmap 868 o Attribute Syntax: See section 8 of [RFCXXXX]. 870 o Attribute Semantics: The details of appropriate values are given 871 in [RFC XXXX]. 873 o Usage Level: Media or session level. 875 o Charset Dependent: No. 877 o Purpose: defines the mapping from the extension numbers used in 878 packet headers into extension names. 880 o O/A Procedures: See section 7 of [RFCXXXX]. 882 o Mux Category: Special. 884 o Reference: [RFCXXXX] 886 10.3. Registration of the SDP extmap-allow-mixed Attribute 888 The IANA is requested to register one new SDP attribute: 890 o Contact Name and email address: IETF, contacted via 891 mmusic@ietf.org, or a successor address designated by IESG. 893 o Attribute Name: extmap-allow-mixed. 895 o Attribute Syntax: See section 6 of [RFCXXXX]. 897 o Attribute Semantics: See section 6 of [RFCXXXX]. 899 o Attribute Value: None. 901 o Usage Level: Media or session level. 903 o Charset Dependent: no. 905 o Purpose: Negotiate the use of One and Two bytes in the same RTP 906 stream. 908 o O/A Procedures: See section 6 of [RFCXXXX]. 910 o Mux Category: Identical 912 o Reference: [RFCXXXX] 914 11. Changes from RFC5285 916 The major motivation for updating [RFC5285] was to allow having one 917 byte and two bytes RTP header extensions in the same RTP stream (but 918 not in the same RTP packet). The support for this case is negotiated 919 using a new SDP attribute "extmap-allow-mixed" specified in this 920 document. 922 The other major change is to update the requirement from the RTP 923 specification [RFC3550] and [RFC5285] that the header extension "is 924 designed so that the header extension MAY be ignored". This is 925 described in section 4.1. 927 The transmission consideration section (4.1.1) adds more text to 928 clarify when and how many times to send the RTP header extension to 929 provide higher probability of delivery 931 >The security section was expanded 933 The rest of the changes are editorial. 935 12. Acknowledgments 937 Both Brian Link and John Lazzaro provided helpful comments on an 938 initial draft of this document. Colin Perkins was helpful in 939 reviewing and dealing with the details. The use of URNs for IETF- 940 defined extensions was suggested by Jonathan Lennox, and Pete Cordell 941 was instrumental in improving the padding wording. Dave Oran 942 provided feedback and text in the review. Mike Dolan contributed the 943 two-byte header form. Magnus Westerlund and Tom Taylor were 944 instrumental in managing the registration text. 946 13. References 948 13.1. Normative References 950 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 951 Requirement Levels", BCP 14, RFC 2119, 952 DOI 10.17487/RFC2119, March 1997, 953 . 955 [RFC2508] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP 956 Headers for Low-Speed Serial Links", RFC 2508, 957 DOI 10.17487/RFC2508, February 1999, 958 . 960 [RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., 961 Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, 962 K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., 963 Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header 964 Compression (ROHC): Framework and four profiles: RTP, UDP, 965 ESP, and uncompressed", RFC 3095, DOI 10.17487/RFC3095, 966 July 2001, . 968 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 969 with Session Description Protocol (SDP)", RFC 3264, 970 DOI 10.17487/RFC3264, June 2002, 971 . 973 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 974 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 975 RFC 3711, DOI 10.17487/RFC3711, March 2004, 976 . 978 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 979 Resource Identifier (URI): Generic Syntax", STD 66, 980 RFC 3986, DOI 10.17487/RFC3986, January 2005, 981 . 983 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 984 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 985 July 2006, . 987 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 988 Specifications: ABNF", STD 68, RFC 5234, 989 DOI 10.17487/RFC5234, January 2008, 990 . 992 [RFC6904] Lennox, J., "Encryption of Header Extensions in the Secure 993 Real-time Transport Protocol (SRTP)", RFC 6904, 994 DOI 10.17487/RFC6904, April 2013, 995 . 997 13.2. Informative References 999 [I-D.ietf-mmusic-sdp-bundle-negotiation] 1000 Holmberg, C., Alvestrand, H., and C. Jennings, 1001 "Negotiating Media Multiplexing Using the Session 1002 Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- 1003 negotiation-38 (work in progress), April 2017. 1005 [I-D.ietf-mmusic-sdp-mux-attributes] 1006 Nandakumar, S., "A Framework for SDP Attributes when 1007 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-16 1008 (work in progress), December 2016. 1010 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1011 Jacobson, "RTP: A Transport Protocol for Real-Time 1012 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 1013 July 2003, . 1015 [RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An 1016 IETF URN Sub-namespace for Registered Protocol 1017 Parameters", BCP 73, RFC 3553, DOI 10.17487/RFC3553, June 1018 2003, . 1020 [RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., 1021 "RTP Control Protocol Extended Reports (RTCP XR)", 1022 RFC 3611, DOI 10.17487/RFC3611, November 2003, 1023 . 1025 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 1026 "Extended RTP Profile for Real-time Transport Control 1027 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 1028 DOI 10.17487/RFC4585, July 2006, 1029 . 1031 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 1032 Hakenberg, "RTP Retransmission Payload Format", RFC 4588, 1033 DOI 10.17487/RFC4588, July 2006, 1034 . 1036 [RFC5109] Li, A., Ed., "RTP Payload Format for Generic Forward Error 1037 Correction", RFC 5109, DOI 10.17487/RFC5109, December 1038 2007, . 1040 [RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP 1041 Header Extensions", RFC 5285, DOI 10.17487/RFC5285, July 1042 2008, . 1044 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1045 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 1046 January 2012, . 1048 [RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP 1049 Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014, 1050 . 1052 [RFC7667] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 7667, 1053 DOI 10.17487/RFC7667, November 2015, 1054 . 1056 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1057 Writing an IANA Considerations Section in RFCs", BCP 26, 1058 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1059 . 1061 Authors' Addresses 1063 David Singer 1064 Apple, Inc. 1065 1 Infinite Loop 1066 Cupertino, CA 95014 1067 USA 1069 Phone: +1 408 996 1010 1070 Email: singer@apple.com 1071 URI: http://www.apple.com/quicktime 1073 Harikishan Desineni 1074 Qualcomm 1075 10001 Pacific Heights Blvd 1076 San Diego, CA 92121 1077 USA 1079 Phone: +1 858 845 8996 1080 Email: hdesinen@quicinc.com 1081 Roni Even (editor) 1082 Huawei Technologies 1083 Tel Aviv 1084 Israel 1086 Email: Roni.even@huawei.com