idnits 2.17.1 draft-ietf-avtcore-rfc5285-bis-12.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 (June 3, 2017) is 2512 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 903, but not defined == Missing Reference: 'RFC XXXX' is mentioned on line 862, 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 5226 (Obsoleted by RFC 8126) -- 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 (==), 4 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: December 5, 2017 R. Even, Ed. 7 Huawei Technologies 8 June 3, 2017 10 A General Mechanism for RTP Header Extensions 11 draft-ietf-avtcore-rfc5285-bis-12.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 December 5, 2017. 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 . . . . . . . . . . . . . . . . . . . 16 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 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 dp 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 first version of this specification was written 325 on the feast day of the Venerable Bede). 327 Each extension element MUST starts with a byte containing an ID and a 328 length: 330 0 331 0 1 2 3 4 5 6 7 332 +-+-+-+-+-+-+-+-+ 333 | ID | len | 334 +-+-+-+-+-+-+-+-+ 336 The 4-bit ID is the local identifier of this element in the range 337 1-14 inclusive. In the signaling section, this is referred to as the 338 valid range. 340 The local identifier value 15 is reserved for future extension and 341 MUST NOT be used as an identifier. If the ID value 15 is 342 encountered, its length field MUST be ignored, processing of the 343 entire extension MUST terminate at that point, and only the extension 344 elements present prior to the element with ID 15 SHOULD be 345 considered. 347 The 4-bit length is the number minus one of data bytes of this header 348 extension element following the one-byte header. Therefore, the 349 value zero in this field indicates that one byte of data follows, and 350 a value of 15 (the maximum) indicates element data of 16 bytes. 351 (This permits carriage of 16-byte values, which is a common length of 352 labels and identifiers, while losing the possibility of zero-length 353 values -- which would often be padded anyway.) 355 An example header extension, with three extension elements, and some 356 padding follows: 358 0 1 2 3 359 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 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 | 0xBE | 0xDE | length=3 | 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 | ID | L=0 | data | ID | L=1 | data... 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 365 ...data | 0 (pad) | 0 (pad) | ID | L=3 | 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 | data | 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 4.3. Two-Byte Header 372 In the two-byte header form, the 16-bit value defined by the RTP 373 specification for a header extension, labeled in the RTP 374 specification as "defined by profile", is defined as shown below. 376 0 1 377 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 | 0x100 |appbits| 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 The appbits field is 4 bits that are application-dependent and MAY be 383 defined to be any value or meaning, and are outside the scope of this 384 specification. For the purposes of signaling, this field is treated 385 as a special extension value assigned to the local identifier 256. 386 If no extension has been specified through configuration or signaling 387 for this local identifier value 256, the appbits field SHOULD be set 388 to all 0s by the sender and MUST be ignored by the receiver. 390 Each extension element starts with a byte containing an ID and a byte 391 containing a length: 393 0 1 394 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 | ID | length | 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 The 8-bit ID is the local identifier of this element in the range 400 1-255 inclusive. In the signaling section, the range 1-256 is 401 referred to as the valid range, with the values 1-255 referring to 402 extension elements, and the value 256 referring to the 4-bit field 403 'appbits' (above). Note that there is one ID space for both one-byte 404 and two-byte form. This means that the lower values (1-14) can be 405 used in the 4-bit ID field in the one-byte header format with the 406 same meanings. 408 The 8-bit length field is the length of extension data in bytes not 409 including the ID and length fields. The value zero indicates there 410 is no data following. 412 An example header extension, with three extension elements, and some 413 padding follows: 415 0 1 2 3 416 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 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 | 0x10 | 0x00 | length=3 | 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 | ID | L=0 | ID | L=1 | 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 | data | 0 (pad) | ID | L=4 | 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 | data | 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 5. SDP Signaling Design 429 The indication of the presence of this extension, and the mapping of 430 local identifiers used in the header extension to a larger namespace, 431 MUST be performed out-of-band, for example, as part of an SDP Offer/ 432 Answer [RFC3264]. This section defines such signaling in SDP. 434 A usable mapping MUST use IDs in the valid range, and each ID in this 435 range MUST be used only once for each media (or only once if the 436 mappings are session level). Mappings that do not conform to these 437 rules MAY be presented, for instance, during SDP Offer/Answer 438 [RFC3264] negotiation as described in the next section, but remapping 439 to conformant values is necessary before they can be applied. 441 Each extension is named by a URI. That URI MUST be absolute, and 442 precisely identifies the format and meaning of the extension. URIs 443 that contain a domain name SHOULD also contain a month-date in the 444 form mmyyyy. The definition of the element and assignment of the URI 445 MUST have been authorized by the owner of the domain name on or very 446 close to that date. (This avoids problems when domain names change 447 ownership.) If the resource or document defines several extensions, 448 then the URI MUST identify the actual extension in use, e.g., using a 449 fragment or query identifier (characters after a '#' or '?' in the 450 URI). 452 Rationale: the use of URIs provides for a large, unallocated space, 453 and gives documentation on the extension. The URIs do not have to be 454 de-referencable, in order to permit confidential or experimental use, 455 and to cover the case when extensions continue to be used after the 456 organization that defined them ceases to exist. 458 An extension URI with the same attributes MUST NOT appear more than 459 once applying to the same stream, i.e., at session level or in the 460 declarations for a single stream at media level. (The same extension 461 can, of course, be used for several streams, and can appear with 462 different extensionattributes for the same stream.) 464 For extensions defined in RFCs, the URI used SHOULD be a URN starting 465 "urn:ietf:params:rtp-hdrext:" and followed by a registered, 466 descriptive name. 468 The registration requirements are detailed in the IANA Considerations 469 section, below. 471 An example (this is only an example), where 'avt-example-metadata' is 472 the hypothetical name of a header extension, might be: 474 urn:ietf:params:rtp-hdrext:avt-example-metadata 476 An example name not from the IETF (this is only an example) might be: 478 http://example.com/082005/ext.htm#example-metadata 480 The mapping MAY be provided per media stream (in the media-level 481 section(s) of SDP, i.e., after an "m=" line) or globally for all 482 streams (i.e., before the first "m=" line, at session level). The 483 definitions MUST be either all session level or all media level; it 484 is not permitted to mix the two styles. In addition, as noted above, 485 the IDs used MUST be unique in each media section of the SDP, or 486 unique in the session for session-level SDP declarations. 488 Each local identifier potentially used in the stream is mapped to an 489 extension identified by a URI using an attribute of the form: 491 a=extmap:["/"] 493 where is a URI, as above, is the local identifier (ID) 494 of this extension and is an integer in the valid range (0 is reserved 495 for padding in both forms, and 15 is reserved in the one-byte header 496 form, as noted above), and is one of "sendonly", 497 "recvonly", "sendrecv", or "inactive" (without the quotes) with 498 relation to the device being configured. 500 The formal BNF syntax is presented in a later section of this 501 specification. 503 Example: 505 a=extmap:1 http://example.com/082005/ext.htm#ttime 507 a=extmap:2/sendrecv http://example.com/082005/ext.htm#xmeta short 509 When SDP signaling is used for the RTP session, it is the presence of 510 the 'extmap' attribute(s) that is diagnostic that this style of 511 header extensions is used, not the magic number indicated above. 513 6. SDP Signaling for support of mixed one byte and two bytes header 514 extensions. 516 In order to allow for backward interoperability with systems that do 517 not support mixing of one byte and two bytes header extensions this 518 document defines the "a=extmap-allow-mixed" Session Description 519 Protocol (SDP) [RFC4566] attribute to indicate if the participant is 520 capable of supporting this new mode. The attribute takes no value. 521 This attribute can be used at the session or media levels. A 522 participant that proposes the use of this mode SHALL itself support 523 the reception of mixed one byte and two bytes header extensions. 525 If SDP Offer/Answer [RFC3264] is supported and used,the negotiation 526 for mixed one byte and two bytes extension MUST be negotiated using 527 SDP Offer/Answer [RFC3264]. In the absence of negotiations using SDP 528 Offer/Answer, for example when declarative SDP is used, mixed headers 529 MUST NOT occur unless the transmitter has some (out of band) 530 knowledge that all potential recipients support this mode. 532 The formal definition of this attribute is: 534 Name: extmap-allow-mixed 536 Value: 538 Usage Level: session, media 540 Charset Dependent: no 542 Example: 544 a=extmap-allow-mixed 546 When doing SDP Offer/Answer [RFC3264] an offering client that wishes 547 to use both one and two bytes extensions MUST include the attribute 548 "a= extmap-allow-mixed " in the SDP offer. If "a= extmap-allow-mixed 549 " is present in the offer SDP, the answerer that supports this mode 550 and wishes to use it SHALL include the "a=extmap-allow-mixed " 551 attribute in the answer. In the cases where the attribute has been 552 excluded, both clients SHALL NOT use mixed one bytes and two bytes 553 extensions in the same RTP stream but MAY use one-byte or two-bytes 554 form exclusively (see section 4.1.2). 556 When used in [I-D.ietf-mmusic-sdp-bundle-negotiation] this attribute 557 is specified as normal category for the 558 [I-D.ietf-mmusic-sdp-mux-attributes]. This allows for only a subset 559 of the m-lines in the bundle group to offer extmap-allow-mixed. When 560 an answerer supporting the extmap-allow-mix attribute receives an 561 offer where only some of the m-lines in the bundle group include the 562 extmap-allow-mixed attribute, the answerer MUST receive this offer 563 and support mixed one-byte and two-bytes only for those m-lines. 564 Transmitters MUST only send RTP header extensions using mixed on 565 those RTP streams originating from those media sources (m=) blocks 566 that includes extmap-allow-mixed, and are RECOMMENDED to support 567 receiving mixed on all RTP streams being received in an RTP session 568 where at least one bundled m= block is indicating extmap-allow-mixed. 570 7. SDP Offer/Answer 572 The simple signaling described above for the extmap attribute MAY be 573 enhanced in an SDP Offer/Answer [RFC3264] context, to permit: 575 o asymmetric behavior (extensions sent in only one direction), 577 o the offer of mutually exclusive alternatives, or 579 o the offer of more extensions than can be sent in a single session. 581 A direction attribute MAY be included in an extmap; without it, the 582 direction implicitly inherits, of course, from the stream direction, 583 or is "sendrecv" for session-level attributes or extensions of 584 "inactive" streams. The direction MUST be one of "sendonly", 585 "recvonly", "sendrecv", or "inactive" as specified in [RFC3264] 587 Extensions, with their directions, MAY be signaled for an "inactive" 588 stream. It is an error to use an extension direction incompatible 589 with the stream direction (e.g., a "sendonly" attribute for a 590 "recvonly" stream). 592 If an offer or answer contains session-level mappings (and hence no 593 media-level mappings), and different behavior is desired for each 594 stream, then the entire set of extension map declarations MAY be 595 moved into the media-level section(s) of the SDP. (Note that this 596 specification does not permit mixing global and local declarations, 597 to make identifier management easier.) 599 If an extension map is offered as "sendrecv", explicitly or 600 implicitly, and asymmetric behavior is desired, the SDP answer MAY be 601 changed to modify or add direction qualifiers for that extension. 603 If an extension is marked as "sendonly" and the answerer desires to 604 receive it, the extension MUST be marked as "recvonly" in the SDP 605 answer. An answerer that has no desire to receive the extension or 606 does not understand the extension SHOULD remove it from the SDP 607 answer. 609 If an extension is marked as "recvonly" and the answerer desires to 610 send it, the extension MUST be marked as "sendonly" in the SDP 611 answer. An answerer that has no desire to, or is unable to, send the 612 extension SHOULD remove it from the SDP answer. 614 Local identifiers in the valid range inclusive in an offer or answer 615 must not be used more than once per media section (including the 616 session-level section). A session update MAY change the direction 617 qualifiers of extensions under use. A session update MAY add or 618 remove extension(s). Identifiers values in the valid range MUST NOT 619 be altered (remapped). 621 Note that, under this rule, the same local identifier cannot be used 622 for two extensions for the same media, even when one is "sendonly" 623 and the other "recvonly", as it would then be impossible to make 624 either of them sendrecv (since re-numbering is not permitted either). 626 If a party wishes to offer mutually exclusive alternatives, then 627 multiple extensions with the same identifier in the extended range 628 4096-4351 MAY be offered; the answerer SHOULD select at most one of 629 the offered extensions with the same identifier, and remap it to a 630 free identifier in the valid range, for that extension to be usable. 632 Similarly, if more extensions are offered than can be fit in the 633 valid range, identifiers in the range 4096-4351 MAY be offered; the 634 answerer SHOULD choose those that are desired, and remap them to a 635 free identifier in the valid range. 637 An answerer may copy an extmap for an identifier in the extended 638 range into the answer to indicate to the offerer that it supports 639 that extension. Of course, such an extension cannot be used, since 640 there is no way to specify them in an extension header. If needed, 641 the offerer or answerer can update the session to assign a valid 642 identifier to that extension URI. 644 Rationale: the range 4096-4351 for these negotiation identifiers is 645 deliberately restricted to allow expansion of the range of valid 646 identifiers in future. 648 Either party MAY include extensions in the stream other than those 649 negotiated, or those negotiated as "inactive", for example, for the 650 benefit of intermediate nodes. Only extensions that appeared with an 651 identifier in the valid range in SDP originated by the sender can be 652 sent. 654 Example (port numbers, RTP profiles, payload IDs and rtpmaps, etc. 655 all omitted for brevity): 657 The offer: 659 a=extmap:1 URI-toffset 660 a=extmap:14 URI-obscure 661 a=extmap:4096 URI-gps-string 662 a=extmap:4096 URI-gps-binary 663 a=extmap:4097 URI-frametype 664 m=video 665 a=sendrecv 666 m=audio 667 a=sendrecv 669 The answerer is interested in receiving GPS in string format only on 670 video, but cannot send GPS at all. It is not interested in 671 transmission offsets on audio, and does not understand the URI- 672 obscure extension. It therefore moves the extensions from session 673 level to media level, and adjusts the declarations: 675 m=video 676 a=sendrecv 677 a=extmap:1 URI-toffset 678 a=extmap:2/recvonly URI-gps-string 679 a=extmap:3 URI-frametype 680 m=audio 681 a=sendrecv 682 a=extmap:1/sendonly URI-toffset 684 When using [I-D.ietf-mmusic-sdp-bundle-negotiation] to bundle 685 multiple m-lines the extmap attribute falls under the special 686 category of [I-D.ietf-mmusic-sdp-mux-attributes]. All the m-lines in 687 a bundle group are considered to be part of the same local identifier 688 (ID) space. If an RTP header extension, i.e. a particular extension 689 URI and configuration using , is offered in 690 multiple m-lines that are part of the same bundle group it MUST use 691 the same ID in all of these m-lines. Each m-line in a bundle group 692 can include different RTP header extensions allowing for example 693 audio and video sources to use different sets of RTP header 694 extensions. It SHALL be assumed that for any RTP header extension, 695 difference in configuration using any of the is 696 important and need to be preserved to any receiver, thus requiring 697 assignment of different IDs. Any RTP header extension that do not 698 match this assumption MUST explicitly provide rules for what are 699 compatible configurations that can be sent with the same ID. The 700 directionality of the RTP header extensions in each m-line of the 701 bundle group are handled as the non-bundled case. This allows for 702 specifying different directionality for each of the repeated 703 extension URI in bundled group. 705 8. BNF Syntax 707 The syntax definition below uses ABNF according to [RFC5234]. The 708 syntax element 'URI' is defined in [RFC3986] (only absolute URIs are 709 permitted here). The syntax element 'extmap' is an attribute as 710 defined in [RFC4566], i.e., "a=" precedes the extmap definition. 711 Specific extensionattributes are defined by the specification that 712 defines a specific extension name; there can be several. 714 Name: extmap 716 Value: extmap-value 718 Syntax: 720 extmap-value = mapentry SP extensionname 721 [SP extensionattributes] 723 mapentry = "extmap:" 1*5DIGIT ["/" direction] 725 extensionname = URI 727 extensionattributes = byte-string 729 direction = "sendonly" / "recvonly" / "sendrecv" / "inactive" 731 URI = 733 byte-string = 735 SP = 737 DIGIT = 739 9. Security Considerations 741 This document defines only a place to transmit information; the 742 security implications of each of the extensions must be discussed 743 with those extensions. 745 Extensions usage is negotiated using [RFC3264] so integrity 746 protection and end-to-end authentication MUST be implemented. The 747 security considerations of [RFC3264] MUST be followed, to prevent, 748 for example, extension usage blocking. 750 Header extensions have the same security coverage as the RTP header 751 itself. When Secure Real-time Transport Protocol (SRTP) [RFC3711] is 752 used to protect RTP sessions, the RTP payload can be both encrypted 753 and integrity protected, while the RTP header is either unprotected 754 or integrity protected. In order to prevent DOS attacks, for 755 example, by changing the header extension integrity protection SHOULD 756 be used. Lower layer security protection like DTLS[RFC6347] MAY be 757 used. RTP header extensions can carry sensitive information for 758 which participants in multimedia sessions want confidentiality. 759 RFC6904 [RFC6904] provides a mechanism, extending the mechanisms of 760 SRTP, to selectively encrypt RTP header extensions in SRTP. 762 The RTP application designer needs to consider their security needs, 763 that includes cipher strength for SRTP packets in general and what 764 that means for the integrity and confidentiality of the RTP header 765 extensions. As defined by RFC6904 [RFC6904] the encryption stream 766 cipher for the header extension is dependent on the chosen SRTP 767 cipher. It can be noted that the default SRTP ciphers (AES CM 128 768 bits with HMAC-SHA1) are relative weak and more modern ciphers are 769 stronger and should be considered. 771 Other security options for securing RTP are discussed in [RFC7201]. 773 10. IANA Considerations 775 This document updates the IANA consideration to reference this 776 document and adds a new SDP attribute in section 10.3 778 Note to IANA : change RFCxxxx to this RFC number and remove the note. 780 10.1. Identifier Space for IANA to Manage 782 The mapping from the naming URI form to a reference to a 783 specification is managed by IANA. Insertion into this registry is 784 under the requirements of "Expert Review" as defined in [RFC5226]. 786 The IANA will also maintain a server that contains all of the 787 registered elements in a publicly accessible space. 789 Here is the formal declaration to comply with the IETF URN Sub- 790 namespace specification [RFC3553]. 792 o Registry name: RTP Compact Header Extensions 793 o Specification: RFC 5285 and RFCs updating RFC 5285. 795 o Information required: 797 A. The desired extension naming URI 799 B. A formal reference to the publicly available specification 801 C. A short phrase describing the function of the extension 803 D. Contact information for the organization or person making the 804 registration 806 For extensions defined in RFCs, the URI SHOULD be of the form 807 urn:ietf:params:rtp-hdrext:, and the formal reference is the RFC 808 number of the RFC documenting the extension. 810 o Review process: Expert review is REQUIRED. The expert review 811 SHOULD check the following requirements: 813 1. that the specification is publicly available; 815 2. that the extension complies with the requirements of RTP, and 816 this specification, for header extensions (specifically, that 817 the header extension can be ignored or discarded without 818 breaking the RTP layer); 820 3. that the extension specification is technically consistent (in 821 itself and with RTP), complete, and comprehensible; 823 4. that the extension does not duplicate functionality in 824 existing IETF specifications (including RTP itself), or other 825 extensions already registered; 827 5. that the specification contains a security analysis regarding 828 the content of the header extension; 830 6. that the extension is generally applicable, for example point- 831 to-multipoint safe, and the specification correctly describes 832 limitations if they exist; and 834 7. that the suggested naming URI form is appropriately chosen and 835 unique. 837 8. That for [I-D.ietf-mmusic-sdp-bundle-negotiation] multiplexed 838 m-lines, any RTP header extension with difference in 839 configurations of that do not require 840 assignment of different IDs, MUST explicitly indicate this and 841 provide rules for what are compatible configurations that can 842 be sent with the same ID. 844 o Size and format of entries: a mapping from a naming URI string to 845 a formal reference to a publicly available specification, with a 846 descriptive phrase and contact information. 848 o Initial assignments: none. 850 10.2. Registration of the SDP extmap Attribute 852 IANA is requested to update the registeration of the extmap SDP 853 [RFC4566] attribute. 855 o Contact Name and email address: IETF, contacted via 856 mmusic@ietf.org, or a successor address designated by IESG 857 Attribute Name: extmap 859 o Attribute Syntax: See section 8 of [RFCXXXX]. 861 o Attribute Semantics: The details of appropriate values are given 862 in [RFC XXXX]. 864 o Usage Level: Media or session level. 866 o Charset Dependent: No. 868 o Purpose: defines the mapping from the extension numbers used in 869 packet headers into extension names. 871 o O/A Procedures: See section 7 of [RFCXXXX]. 873 o Mux Category: Special. 875 o Reference: [RFCXXXX] 877 10.3. Registration of the SDP extmap-allow-mixed Attribute 879 The IANA is requested to register one new SDP attribute: 881 o Contact Name and email address: IETF, contacted via 882 mmusic@ietf.org, or a successor address designated by IESG. 884 o Attribute Name: extmap-allow-mixed. 886 o Attribute Syntax: See section 6 of [RFCXXXX]. 888 o Attribute Semantics: See section 6 of [RFCXXXX]. 890 o Attribute Value: None. 892 o Usage Level: Media or session level. 894 o Charset Dependent: no. 896 o Purpose: Negotiate the use of One and Two bytes in the same RTP 897 stream. 899 o O/A Procedures: See section 6 of [RFCXXXX]. 901 o Mux Category: Normal 903 o Reference: [RFCXXXX] 905 11. Changes from RFC5285 907 The major motivation for updating [RFC5285] was to allow having one 908 byte and two bytes RTP header extensions in the same RTP stream (but 909 not in the same RTP packet). The support for this case is negotiated 910 using a new SDP attribute "extmap-allow-mixed" specified in this 911 document. 913 The other major change is to update the requirement from the RTP 914 specification and[RFC5285] that the header extension "is designed so 915 that the header extension MAY be ignored". This is described in 916 section 4.1. 918 The transmission consideration section (4.1.1) adds more text to 919 clarify when and how many times to send the RTP header extension to 920 provide higher probability of delivery 922 >The security section was expanded 924 The rest of the changes are editorial. 926 12. Acknowledgments 928 Both Brian Link and John Lazzaro provided helpful comments on an 929 initial draft of this document. Colin Perkins was helpful in 930 reviewing and dealing with the details. The use of URNs for IETF- 931 defined extensions was suggested by Jonathan Lennox, and Pete Cordell 932 was instrumental in improving the padding wording. Dave Oran 933 provided feedback and text in the review. Mike Dolan contributed the 934 two-byte header form. Magnus Westerlund and Tom Taylor were 935 instrumental in managing the registration text. 937 13. References 939 13.1. Normative References 941 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 942 Requirement Levels", BCP 14, RFC 2119, 943 DOI 10.17487/RFC2119, March 1997, 944 . 946 [RFC2508] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP 947 Headers for Low-Speed Serial Links", RFC 2508, 948 DOI 10.17487/RFC2508, February 1999, 949 . 951 [RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., 952 Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, 953 K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., 954 Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header 955 Compression (ROHC): Framework and four profiles: RTP, UDP, 956 ESP, and uncompressed", RFC 3095, DOI 10.17487/RFC3095, 957 July 2001, . 959 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 960 with Session Description Protocol (SDP)", RFC 3264, 961 DOI 10.17487/RFC3264, June 2002, 962 . 964 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 965 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 966 RFC 3711, DOI 10.17487/RFC3711, March 2004, 967 . 969 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 970 Resource Identifier (URI): Generic Syntax", STD 66, 971 RFC 3986, DOI 10.17487/RFC3986, January 2005, 972 . 974 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 975 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 976 July 2006, . 978 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 979 Specifications: ABNF", STD 68, RFC 5234, 980 DOI 10.17487/RFC5234, January 2008, 981 . 983 [RFC6904] Lennox, J., "Encryption of Header Extensions in the Secure 984 Real-time Transport Protocol (SRTP)", RFC 6904, 985 DOI 10.17487/RFC6904, April 2013, 986 . 988 13.2. Informative References 990 [I-D.ietf-mmusic-sdp-bundle-negotiation] 991 Holmberg, C., Alvestrand, H., and C. Jennings, 992 "Negotiating Media Multiplexing Using the Session 993 Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- 994 negotiation-38 (work in progress), April 2017. 996 [I-D.ietf-mmusic-sdp-mux-attributes] 997 Nandakumar, S., "A Framework for SDP Attributes when 998 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-16 999 (work in progress), December 2016. 1001 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1002 Jacobson, "RTP: A Transport Protocol for Real-Time 1003 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 1004 July 2003, . 1006 [RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An 1007 IETF URN Sub-namespace for Registered Protocol 1008 Parameters", BCP 73, RFC 3553, DOI 10.17487/RFC3553, June 1009 2003, . 1011 [RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., 1012 "RTP Control Protocol Extended Reports (RTCP XR)", 1013 RFC 3611, DOI 10.17487/RFC3611, November 2003, 1014 . 1016 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 1017 "Extended RTP Profile for Real-time Transport Control 1018 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 1019 DOI 10.17487/RFC4585, July 2006, 1020 . 1022 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 1023 Hakenberg, "RTP Retransmission Payload Format", RFC 4588, 1024 DOI 10.17487/RFC4588, July 2006, 1025 . 1027 [RFC5109] Li, A., Ed., "RTP Payload Format for Generic Forward Error 1028 Correction", RFC 5109, DOI 10.17487/RFC5109, December 1029 2007, . 1031 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1032 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1033 DOI 10.17487/RFC5226, May 2008, 1034 . 1036 [RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP 1037 Header Extensions", RFC 5285, DOI 10.17487/RFC5285, July 1038 2008, . 1040 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1041 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 1042 January 2012, . 1044 [RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP 1045 Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014, 1046 . 1048 [RFC7667] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 7667, 1049 DOI 10.17487/RFC7667, November 2015, 1050 . 1052 Authors' Addresses 1054 David Singer 1055 Apple, Inc. 1056 1 Infinite Loop 1057 Cupertino, CA 95014 1058 USA 1060 Phone: +1 408 996 1010 1061 Email: singer@apple.com 1062 URI: http://www.apple.com/quicktime 1064 Harikishan Desineni 1065 Qualcomm 1066 10001 Pacific Heights Blvd 1067 San Diego, CA 92121 1068 USA 1070 Phone: +1 858 845 8996 1071 Email: hdesinen@quicinc.com 1072 Roni Even (editor) 1073 Huawei Technologies 1074 Tel Aviv 1075 Israel 1077 Email: Roni.even@huawei.com