idnits 2.17.1 draft-ietf-avtcore-rfc5285-bis-11.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 (May 2, 2017) is 2549 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 862, but not defined == Missing Reference: 'RFC XXXX' is mentioned on line 821, 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 -- 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 (~~), 4 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: November 3, 2017 R. Even, Ed. 7 Huawei Technologies 8 May 2, 2017 10 A General Mechanism for RTP Header Extensions 11 draft-ietf-avtcore-rfc5285-bis-11.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 November 3, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 15 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 . . . . . . . . 18 75 10.3. Registration of the SDP extmap-allow-mixed Attribute . . 19 76 11. Changes from RFC5285 . . . . . . . . . . . . . . . . . . . . 19 77 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 78 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 79 13.1. Normative References . . . . . . . . . . . . . . . . . . 20 80 13.2. Informative References . . . . . . . . . . . . . . . . . 21 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 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 7. SDP Offer/Answer 558 The simple signaling described above for the extmap attribute MAY be 559 enhanced in an SDP Offer/Answer [RFC3264] context, to permit: 561 o asymmetric behavior (extensions sent in only one direction), 563 o the offer of mutually exclusive alternatives, or 565 o the offer of more extensions than can be sent in a single session. 567 A direction attribute MAY be included in an extmap; without it, the 568 direction implicitly inherits, of course, from the stream direction, 569 or is "sendrecv" for session-level attributes or extensions of 570 "inactive" streams. The direction MUST be one of "sendonly", 571 "recvonly", "sendrecv", or "inactive" as specified in [RFC3264] 573 Extensions, with their directions, MAY be signaled for an "inactive" 574 stream. It is an error to use an extension direction incompatible 575 with the stream direction (e.g., a "sendonly" attribute for a 576 "recvonly" stream). 578 If an offer or answer contains session-level mappings (and hence no 579 media-level mappings), and different behavior is desired for each 580 stream, then the entire set of extension map declarations MAY be 581 moved into the media-level section(s) of the SDP. (Note that this 582 specification does not permit mixing global and local declarations, 583 to make identifier management easier.) 585 If an extension map is offered as "sendrecv", explicitly or 586 implicitly, and asymmetric behavior is desired, the SDP answer MAY be 587 changed to modify or add direction qualifiers for that extension. 589 If an extension is marked as "sendonly" and the answerer desires to 590 receive it, the extension MUST be marked as "recvonly" in the SDP 591 answer. An answerer that has no desire to receive the extension or 592 does not understand the extension SHOULD remove it from the SDP 593 answer. 595 If an extension is marked as "recvonly" and the answerer desires to 596 send it, the extension MUST be marked as "sendonly" in the SDP 597 answer. An answerer that has no desire to, or is unable to, send the 598 extension SHOULD remove it from the SDP answer. 600 Local identifiers in the valid range inclusive in an offer or answer 601 must not be used more than once per media section (including the 602 session-level section). A session update MAY change the direction 603 qualifiers of extensions under use. A session update MAY add or 604 remove extension(s). Identifiers values in the valid range MUST NOT 605 be altered (remapped). 607 Note that, under this rule, the same local identifier cannot be used 608 for two extensions for the same media, even when one is "sendonly" 609 and the other "recvonly", as it would then be impossible to make 610 either of them sendrecv (since re-numbering is not permitted either). 612 If a party wishes to offer mutually exclusive alternatives, then 613 multiple extensions with the same identifier in the extended range 614 4096-4351 MAY be offered; the answerer SHOULD select at most one of 615 the offered extensions with the same identifier, and remap it to a 616 free identifier in the valid range, for that extension to be usable. 618 Similarly, if more extensions are offered than can be fit in the 619 valid range, identifiers in the range 4096-4351 MAY be offered; the 620 answerer SHOULD choose those that are desired, and remap them to a 621 free identifier in the valid range. 623 An answerer may copy an extmap for an identifier in the extended 624 range into the answer to indicate to the offerer that it supports 625 that extension. Of course, such an extension cannot be used, since 626 there is no way to specify them in an extension header. If needed, 627 the offerer or answerer can update the session to assign a valid 628 identifier to that extension URI. 630 Rationale: the range 4096-4351 for these negotiation identifiers is 631 deliberately restricted to allow expansion of the range of valid 632 identifiers in future. 634 Either party MAY include extensions in the stream other than those 635 negotiated, or those negotiated as "inactive", for example, for the 636 benefit of intermediate nodes. Only extensions that appeared with an 637 identifier in the valid range in SDP originated by the sender can be 638 sent. 640 Example (port numbers, RTP profiles, payload IDs and rtpmaps, etc. 641 all omitted for brevity): 643 The offer: 645 a=extmap:1 URI-toffset 646 a=extmap:14 URI-obscure 647 a=extmap:4096 URI-gps-string 648 a=extmap:4096 URI-gps-binary 649 a=extmap:4097 URI-frametype 650 m=video 651 a=sendrecv 652 m=audio 653 a=sendrecv 655 The answerer is interested in receiving GPS in string format only on 656 video, but cannot send GPS at all. It is not interested in 657 transmission offsets on audio, and does not understand the URI- 658 obscure extension. It therefore moves the extensions from session 659 level to media level, and adjusts the declarations: 661 m=video 662 a=sendrecv 663 a=extmap:1 URI-toffset 664 a=extmap:2/recvonly URI-gps-string 665 a=extmap:3 URI-frametype 666 m=audio 667 a=sendrecv 668 a=extmap:1/sendonly URI-toffset 670 8. BNF Syntax 672 The syntax definition below uses ABNF according to [RFC5234]. The 673 syntax element 'URI' is defined in [RFC3986] (only absolute URIs are 674 permitted here). The syntax element 'extmap' is an attribute as 675 defined in [RFC4566], i.e., "a=" precedes the extmap definition. 676 Specific extensionattributes are defined by the specification that 677 defines a specific extension name; there can be several. 679 Name: extmap 681 Value: extmap-value 683 Syntax: 685 extmap-value = mapentry SP extensionname 686 [SP extensionattributes] 688 mapentry = "extmap:" 1*5DIGIT ["/" direction] 690 extensionname = URI 692 extensionattributes = byte-string 694 direction = "sendonly" / "recvonly" / "sendrecv" / "inactive" 696 URI = 698 byte-string = 700 SP = 702 DIGIT = 704 9. Security Considerations 706 This document defines only a place to transmit information; the 707 security implications of each of the extensions must be discussed 708 with those extensions. 710 Extensions usage is negotiated using [RFC3264] so integrity 711 protection and end-to-end authentication MUST be implemented. The 712 security considerations of [RFC3264] MUST be followed, to prevent, 713 for example, extension usage blocking. 715 Header extensions have the same security coverage as the RTP header 716 itself. When Secure Real-time Transport Protocol (SRTP) [RFC3711] is 717 used to protect RTP sessions, the RTP payload can be both encrypted 718 and integrity protected, while the RTP header is either unprotected 719 or integrity protected. In order to prevent DOS attacks, for 720 example, by changing the header extension integrity protection SHOULD 721 be used. Lower layer security protection like DTLS[RFC6347] MAY be 722 used. RTP header extensions can carry sensitive information for 723 which participants in multimedia sessions want confidentiality. 724 RFC6904 [RFC6904] provides a mechanism, extending the mechanisms of 725 SRTP, to selectively encrypt RTP header extensions in SRTP. 727 The RTP application designer needs to consider their security needs, 728 that includes cipher strength for SRTP packets in general and what 729 that means for the integrity and confidentiality of the RTP header 730 extensions. As defined by RFC6904 [RFC6904] the encryption stream 731 cipher for the header extension is dependent on the chosen SRTP 732 cipher. It can be noted that the default SRTP ciphers (AES CM 128 733 bits with HMAC-SHA1) are relative weak and more modern ciphers are 734 stronger and should be considered. 736 Other security options for securing RTP are discussed in [RFC7201]. 738 10. IANA Considerations 740 This document updates the IANA consideration to reference this 741 document and adds a new SDP attribute in section 10.3 743 Note to IANA : change RFCxxxx to this RFC number and remove the note. 745 10.1. Identifier Space for IANA to Manage 747 The mapping from the naming URI form to a reference to a 748 specification is managed by IANA. Insertion into this registry is 749 under the requirements of "Expert Review" as defined in [RFC5226]. 751 The IANA will also maintain a server that contains all of the 752 registered elements in a publicly accessible space. 754 Here is the formal declaration to comply with the IETF URN Sub- 755 namespace specification [RFC3553]. 757 o Registry name: RTP Compact Header Extensions 759 o Specification: RFC 5285 and RFCs updating RFC 5285. 761 o Information required: 763 A. The desired extension naming URI 765 B. A formal reference to the publicly available specification 767 C. A short phrase describing the function of the extension 769 D. Contact information for the organization or person making the 770 registration 772 For extensions defined in RFCs, the URI SHOULD be of the form 773 urn:ietf:params:rtp-hdrext:, and the formal reference is the RFC 774 number of the RFC documenting the extension. 776 o Review process: Expert review is REQUIRED. The expert review 777 SHOULD check the following requirements: 779 1. that the specification is publicly available; 781 2. that the extension complies with the requirements of RTP, and 782 this specification, for header extensions (specifically, that 783 the header extension can be ignored or discarded without 784 breaking the RTP layer); 786 3. that the extension specification is technically consistent (in 787 itself and with RTP), complete, and comprehensible; 789 4. that the extension does not duplicate functionality in 790 existing IETF specifications (including RTP itself), or other 791 extensions already registered; 793 5. that the specification contains a security analysis regarding 794 the content of the header extension; 796 6. that the extension is generally applicable, for example point- 797 to-multipoint safe, and the specification correctly describes 798 limitations if they exist; and 800 7. that the suggested naming URI form is appropriately chosen and 801 unique. 803 o Size and format of entries: a mapping from a naming URI string to 804 a formal reference to a publicly available specification, with a 805 descriptive phrase and contact information. 807 o Initial assignments: none. 809 10.2. Registration of the SDP extmap Attribute 811 IANA is requested to update the registeration of the extmap SDP 812 [RFC4566] attribute. 814 o Contact Name and email address: IETF, contacted via 815 mmusic@ietf.org, or a successor address designated by IESG 816 Attribute Name: extmap 818 o Attribute Syntax: See section 8 of [RFCXXXX]. 820 o Attribute Semantics: The details of appropriate values are given 821 in [RFC XXXX]. 823 o Usage Level: Media or session level. 825 o Charset Dependent: No. 827 o Purpose: defines the mapping from the extension numbers used in 828 packet headers into extension names. 830 o O/A Procedures: See section 7 of [RFCXXXX]. 832 o Mux Category: Special. 834 o Reference: [RFCXXXX] 836 10.3. Registration of the SDP extmap-allow-mixed Attribute 838 The IANA is requested to register one new SDP attribute: 840 o Contact Name and email address: IETF, contacted via 841 mmusic@ietf.org, or a successor address designated by IESG. 843 o Attribute Name: extmap-allow-mixed. 845 o Attribute Syntax: See section 6 of [RFCXXXX]. 847 o Attribute Semantics: See section 6 of [RFCXXXX]. 849 o Attribute Value: None. 851 o Usage Level: Media or session level. 853 o Charset Dependent: no. 855 o Purpose: Negotiate the use of One and Two bytes in the same RTP 856 stream. 858 o O/A Procedures: See section 6 of [RFCXXXX]. 860 o Mux Category: Normal 862 o Reference: [RFCXXXX] 864 11. Changes from RFC5285 866 The major motivation for updating [RFC5285] was to allow having one 867 byte and two bytes RTP header extensions in the same RTP stream (but 868 not in the same RTP packet). The support for this case is negotiated 869 using a new SDP attribute "extmap-allow-mixed" specified in this 870 document. 872 The other major change is to update the requirement from the RTP 873 specification and[RFC5285] that the header extension "is designed so 874 that the header extension MAY be ignored". This is described in 875 section 4.1. 877 The transmission consideration section (4.1.1) adds more text to 878 clarify when and how many times to send the RTP header extension to 879 provide higher probability of delivery 881 >The security section was expanded 883 The rest of the changes are editorial. 885 12. Acknowledgments 887 Both Brian Link and John Lazzaro provided helpful comments on an 888 initial draft of this document. Colin Perkins was helpful in 889 reviewing and dealing with the details. The use of URNs for IETF- 890 defined extensions was suggested by Jonathan Lennox, and Pete Cordell 891 was instrumental in improving the padding wording. Dave Oran 892 provided feedback and text in the review. Mike Dolan contributed the 893 two-byte header form. Magnus Westerlund and Tom Taylor were 894 instrumental in managing the registration text. 896 13. References 898 13.1. Normative References 900 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 901 Requirement Levels", BCP 14, RFC 2119, 902 DOI 10.17487/RFC2119, March 1997, 903 . 905 [RFC2508] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP 906 Headers for Low-Speed Serial Links", RFC 2508, 907 DOI 10.17487/RFC2508, February 1999, 908 . 910 [RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., 911 Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, 912 K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., 913 Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header 914 Compression (ROHC): Framework and four profiles: RTP, UDP, 915 ESP, and uncompressed", RFC 3095, DOI 10.17487/RFC3095, 916 July 2001, . 918 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 919 with Session Description Protocol (SDP)", RFC 3264, 920 DOI 10.17487/RFC3264, June 2002, 921 . 923 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 924 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 925 RFC 3711, DOI 10.17487/RFC3711, March 2004, 926 . 928 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 929 Resource Identifier (URI): Generic Syntax", STD 66, 930 RFC 3986, DOI 10.17487/RFC3986, January 2005, 931 . 933 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 934 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 935 July 2006, . 937 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 938 Specifications: ABNF", STD 68, RFC 5234, 939 DOI 10.17487/RFC5234, January 2008, 940 . 942 [RFC6904] Lennox, J., "Encryption of Header Extensions in the Secure 943 Real-time Transport Protocol (SRTP)", RFC 6904, 944 DOI 10.17487/RFC6904, April 2013, 945 . 947 13.2. Informative References 949 [I-D.ietf-mmusic-sdp-bundle-negotiation] 950 Holmberg, C., Alvestrand, H., and C. Jennings, 951 "Negotiating Media Multiplexing Using the Session 952 Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- 953 negotiation-38 (work in progress), April 2017. 955 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 956 Jacobson, "RTP: A Transport Protocol for Real-Time 957 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 958 July 2003, . 960 [RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An 961 IETF URN Sub-namespace for Registered Protocol 962 Parameters", BCP 73, RFC 3553, DOI 10.17487/RFC3553, June 963 2003, . 965 [RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., 966 "RTP Control Protocol Extended Reports (RTCP XR)", 967 RFC 3611, DOI 10.17487/RFC3611, November 2003, 968 . 970 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 971 "Extended RTP Profile for Real-time Transport Control 972 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 973 DOI 10.17487/RFC4585, July 2006, 974 . 976 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 977 Hakenberg, "RTP Retransmission Payload Format", RFC 4588, 978 DOI 10.17487/RFC4588, July 2006, 979 . 981 [RFC5109] Li, A., Ed., "RTP Payload Format for Generic Forward Error 982 Correction", RFC 5109, DOI 10.17487/RFC5109, December 983 2007, . 985 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 986 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 987 DOI 10.17487/RFC5226, May 2008, 988 . 990 [RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP 991 Header Extensions", RFC 5285, DOI 10.17487/RFC5285, July 992 2008, . 994 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 995 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 996 January 2012, . 998 [RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP 999 Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014, 1000 . 1002 [RFC7667] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 7667, 1003 DOI 10.17487/RFC7667, November 2015, 1004 . 1006 Authors' Addresses 1007 David Singer 1008 Apple, Inc. 1009 1 Infinite Loop 1010 Cupertino, CA 95014 1011 USA 1013 Phone: +1 408 996 1010 1014 Email: singer@apple.com 1015 URI: http://www.apple.com/quicktime 1017 Harikishan Desineni 1018 Qualcomm 1019 10001 Pacific Heights Blvd 1020 San Diego, CA 92121 1021 USA 1023 Phone: +1 858 845 8996 1024 Email: hdesinen@quicinc.com 1026 Roni Even (editor) 1027 Huawei Technologies 1028 Tel Aviv 1029 Israel 1031 Email: Roni.even@huawei.com