idnits 2.17.1 draft-ietf-avtcore-rfc5285-bis-07.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 (February 25, 2017) is 2616 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 826, 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-36 -- 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 (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 AVTCore R. Even, Ed. 3 Internet-Draft Huawei Technologies 4 Obsoletes: 5285 (if approved) D. Singer 5 Intended status: Standards Track Apple, Inc. 6 Expires: August 29, 2017 H. Desineni 7 February 25, 2017 9 A General Mechanism for RTP Header Extensions 10 draft-ietf-avtcore-rfc5285-bis-07.txt 12 Abstract 14 This document provides a general mechanism to use the header 15 extension feature of RTP (the Real-Time Transport Protocol). It 16 provides the option to use a small number of small extensions in each 17 RTP packet, where the universe of possible extensions is large and 18 registration is de-centralized. The actual extensions in use in a 19 session are signaled in the setup information for that session. This 20 document obsoletes RFC5285. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on August 29, 2017. 39 Copyright Notice 41 Copyright (c) 2017 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 58 3. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . 3 59 4. Packet Design . . . . . . . . . . . . . . . . . . . . . . . . 4 60 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 4.1.1. Transmission Considerations . . . . . . . . . . . . . 5 62 4.1.2. Header Extension Type Considerations . . . . . . . . 6 63 4.2. One-Byte Header . . . . . . . . . . . . . . . . . . . . . 7 64 4.3. Two-Byte Header . . . . . . . . . . . . . . . . . . . . . 9 65 5. SDP Signaling Design . . . . . . . . . . . . . . . . . . . . 10 66 6. SDP Signaling for support of mixed one byte and two bytes 67 header extensions. . . . . . . . . . . . . . . . . . . . . . 12 68 7. Offer/Answer . . . . . . . . . . . . . . . . . . . . . . . . 13 69 8. BNF Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 15 70 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 71 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 72 10.1. Identifier Space for IANA to Manage . . . . . . . . . . 17 73 10.2. Registration of the SDP extmap Attribute . . . . . . . . 18 74 10.3. Registration of the SDP extmap-allow-mixed Attribute . . 18 75 11. Changes from RFC5285 . . . . . . . . . . . . . . . . . . . . 19 76 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 77 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 78 13.1. Normative References . . . . . . . . . . . . . . . . . . 20 79 13.2. Informative References . . . . . . . . . . . . . . . . . 21 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 82 1. Introduction 84 The RTP specification [RFC3550] provides a capability to extend the 85 RTP header. It defines the header extension format and rules for its 86 use in Section 5.3.1. The existing header extension method permits 87 at most one extension per RTP packet, identified by a 16-bit 88 identifier and a 16-bit length field specifying the length of the 89 header extension in 32-bit words. 91 This mechanism has two conspicuous drawbacks. First, it permits only 92 one header extension in a single RTP packet. Second, the 93 specification gives no guidance as to how the 16-bit header extension 94 identifiers are allocated to avoid collisions. 96 This specification removes the first drawback by defining a backward- 97 compatible and extensible means to carry multiple header extension 98 elements in a single RTP packet. It removes the second drawback by 99 defining that these extension elements are named by URIs, defining an 100 IANA registry for extension elements defined in IETF specifications, 101 and a Session Description Protocol (SDP) method for mapping between 102 the naming URIs and the identifier values carried in the RTP packets. 104 This header extension applies to RTP/AVP (the Audio/Visual Profile) 105 and its extensions. 107 This document obsoletes [RFC5285] and removes a limitation from 108 RFC5285 that did not allow sending both one-byte and two-byte header 109 extensions in the same RTP stream 111 2. Requirements Notation 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 115 document are to be interpreted as described in [RFC2119]. 117 3. Design Goals 119 The goal of this design is to provide a simple mechanism whereby 120 multiple identified extensions can be used in RTP packets, without 121 the need for formal registration of those extensions but nonetheless 122 avoiding collision. 124 This mechanism provides an alternative to the practice of burying 125 associated metadata into the media format bit stream. This has often 126 been done in media data sent over fixed-bandwidth channels. Once 127 this is done, a decoder for the specific media format needs to 128 extract the metadata. Also, depending on the media format, the 129 metadata can be added at the time of encoding the media so that the 130 bit-rate used for the metadata is taken into account. But the 131 metadata can be unknown at that time. Inserting metadata at a later 132 time can cause a decode and re-encode to meet bit-rate requirements. 134 In some cases, a more appropriate, higher-level mechanism can be 135 available, and if so, it can be used. For cases where a higher-level 136 mechanism is not available, it is better to provide a mechanism at 137 the RTP level than have the metadata be tied to a specific form of 138 media data. 140 4. Packet Design 142 4.1. General 144 The following design is fit into the "header extension" of the RTP 145 extension, as described above. 147 The presence and format of this header extension and its contents are 148 negotiated or defined out-of-band, such as through signaling (see 149 below for SDP signaling). The 16-bit identifier for the two forms of 150 RTP extension defined here is only an architectural constant (e.g., 151 for use by network analyzers); it is the negotiation/definition 152 (e.g., in SDP) that is the definitive indication that this header 153 extension is present. 155 The RTP specification [RFC3550] states that RTP "is designed so that 156 the header extension may be ignored by other interoperating 157 implementations that have not been extended". The intent of this 158 restriction is that RTP header extensions MUST NOT be used to extend 159 RTP itself in a manner that is backwards incompatible with non- 160 extended implementations. For example, a header extension is not 161 allowed to change the meaning or interpretation of the standard RTP 162 header fields, or of the RTCP Control Protocol (RTCP). Header 163 extensions MAY carry metadata in addition to the usual RTP header 164 information, provided the RTP layer can function if that metadata is 165 missing. For example, RTP header extensions can be used to carry 166 data that's also sent in RTCP, as an optimisation to lower latency, 167 since they'll fall back to the original, non-optimised, behaviour if 168 the header extension is not present. The use of header extensions to 169 convey information that will, if missing, disrupt the behaviour of a 170 higher layer application that builds on top of RTP is only acceptable 171 if this doesn't affect interoperability at the RTP layer. For 172 example, applications that use the SDP BUNDLE extension with the MID 173 RTP header extension [I-D.ietf-mmusic-sdp-bundle-negotiation] to 174 correlate RTP streams with SDP m= lines likely won't work with full 175 functionality if the MID is missing, but the operation of the RTP 176 layer of those applications will be unaffected. Support for RTP 177 header extensions based on this memo is negotiated using, for 178 example, SDP offer answer [RFC3264]; intermediaries aware of the RTP 179 header extensions are advised to be cautious when removing or 180 generating RTP header extensions see section 4.7 of [RFC7667]. 182 The RTP header extension is formed as a sequence of extension 183 elements, with possible padding. Each extension element has a local 184 identifier and a length. The local identifiers MAY be mapped to a 185 larger namespace in the negotiation (e.g., session signaling). 187 4.1.1. Transmission Considerations 189 As is good network practice, data SHOULD only be transmitted when 190 needed. The RTP header extension SHOULD only be present in a packet 191 if that packet also contains one or more extension elements, as 192 defined here. An extension element SHOULD only be present in a 193 packet when needed; the signaling setup of extension elements 194 indicates only that those elements can be present in some packets, 195 not that they are in fact present in all (or indeed, any) packets. 197 Some general considerations for getting the header extensions 198 delivered to the receiver: 200 1. The probability for packet loss and burst loss determine how many 201 repetitions of the header extensions will be required to reach a 202 targeted delivery probability, and if burst loss is likely, what 203 distribution would be needed to avoid getting all repetitions of 204 the header extensions lost in a single burst. 206 2. If a set of packets are all needed to enable decoding, there is 207 commonly no reason for including the header extension in all of 208 these packets, as they share fate. Instead, at most one instance 209 of the header extension per independently decodable set of media 210 data would be a more efficient use of the bandwidth. 212 3. How early the Header Extension item information is needed, from 213 the first received RTP data or only after some set of packets are 214 received, can guide if the header extension(s) should be in all 215 of the first N packets or be included only once per set of 216 packets, for example once per video frame. 218 4. The use of RTP level robustness mechanisms, such as RTP 219 retransmission [RFC4588], or Forward Error Correction, e.g., 220 [RFC5109] may treat packets differently from a robustness 221 perspective, and header extensions should be added to packets 222 that get a treatment corresponding to the relative importance of 223 receiving the information. 225 As a summary, the number of header extension transmissions should be 226 tailored to a desired probability of delivery taking the receiver 227 population size into account. For the very basic case, N repetitions 228 of the header extensions should be sufficient, but may not be 229 optimal. N is selected so that the header extension target delivery 230 probability reaches 1-P^N, where P is the probability of packet loss. 231 For point to point or small receiver populations, it might also be 232 possible to use feedback, such as RTCP, to determine when the 233 information in the header extensions has reached all receivers and 234 stop further repetitions. Feedback that can be used includes the 235 RTCP XR Loss RLE report block [RFC3611], which will indicate 236 successful delivery of particular packets. If the RTP/AVPF Transport 237 Layer Feedback Messages for generic NACK [RFC4585] is used, it can 238 indicate the failure to deliver an RTP packet with the header 239 extension, thus indicating the need for further repetitions. The 240 normal RTCP report blocks can also provide an indicator of successful 241 delivery, if no losses are indicated for a reporting interval 242 covering the RTP packets with the header extension. Note that loss 243 of an RTCP packet reporting on an interval where RTP header extension 244 packets were sent, does not necessarily mean that the RTP header 245 extension packets themselves were lost. 247 4.1.2. Header Extension Type Considerations 249 Each extension element in a packet has a local identifier (ID) and a 250 length. The local identifiers present in the stream MUST have been 251 negotiated or defined out-of-band. There are no static allocations 252 of local identifiers. Each distinct extension MUST have a unique ID. 253 The value 0 is reserved for padding and MUST NOT be used as a local 254 identifier. 256 an extension element with a value equal 0 MUST NOT have len greater 257 than 0. If such an extension element is encountered, its length 258 field MUST be ignored, processing of the entire extension MUST 259 terminate at that point, and only the extension elements present 260 prior to the element with ID 0 and len greater than 0 SHOULD be 261 considered. 263 There are two variants of the extension: one-byte and two-byte 264 headers. Since it is expected that (a) the number of extensions in 265 any given RTP session is small and (b) the extensions themselves are 266 small, the one-byte header form is preferred and MUST be supported by 267 all receivers. A stream MUST contain only one-byte or two-byte 268 headers unless it is known that all recipients support mixing, either 269 by offer/answer negotiation (see section 6) or by out-of-band 270 knowledge. Each RTP packet with an RTP header extension following 271 this specification will indicate if it contains one or two byte 272 header extensions through the use of the "defined by profile" field. 273 Only the extension element types that match the header extension 274 format, i.e. one- or two-byte, MUST be used in that RTP packet. 275 Transmitters SHOULD NOT use the two-byte form when all extensions are 276 small enough for the one-byte header form. Transmitters that intend 277 to send the two-byte form SHOULD negotiate the use of IDs above 14 if 278 they want to let the Receivers know that they intend to use two-byte 279 form, for example if the RTP header extension is longer than 16 280 bytes. A transmitter MAY be aware that an intermediary may add RTP 281 header extensions in this case, the transmitter SHOULD use two-byte 282 form. 284 A sequence of extension elements, possibly with padding, forms the 285 header extension defined in the RTP specification. There are as many 286 extension elements as fit into the length as indicated in the RTP 287 header extension length. Since this length is signaled in full 288 32-bit words, padding bytes are used to pad to a 32-bit boundary. 289 The entire extension is parsed byte-by-byte to find each extension 290 element (no alignment is needed), and parsing stops at the earlier of 291 the end of the entire header extension, or in one-byte headers only 292 case, on encountering an identifier with the reserved value of 15. 294 In both forms, padding bytes have the value of 0 (zero). They MAY be 295 placed between extension elements, if desired for alignment, or after 296 the last extension element, if needed for padding. A padding byte 297 does not supply the ID of an element, nor the length field. When a 298 padding byte is found, it is ignored and the parser moves on to 299 interpreting the next byte. 301 Note carefully that the one-byte header form allows for data lengths 302 between 1 and 16 bytes, by adding 1 to the signaled length value 303 (thus, 0 in the length field indicates 1 byte of data follows). This 304 allows for the important case of 16-byte payloads. This addition is 305 not performed for the two-byte headers, where the length field 306 signals data lengths between 0 and 255 bytes. 308 Use of RTP header extensions will reduce the efficiency of RTP header 309 compression, since the header extension will be sent uncompressed 310 unless the RTP header compression module is updated to recognize the 311 extension header. If header extensions are present in some packets, 312 but not in others, this can also reduce compression efficiency by 313 requiring an update to the fixed header to be conveyed when header 314 extensions start or stop being sent. The interactions of the RTP 315 header extension and header compression is explored further in 316 [RFC2508] and [RFC3095]. 318 4.2. One-Byte Header 320 In the one-byte header form of extensions, the 16-bit value REQUIRED 321 by the RTP specification for a header extension, labeled in the RTP 322 specification as "defined by profile", MUST have the fixed bit 323 pattern 0xBEDE (the first version of this specification was written 324 on the feast day of the Venerable Bede). 326 Each extension element MUST starts with a byte containing an ID and a 327 length: 329 0 330 0 1 2 3 4 5 6 7 331 +-+-+-+-+-+-+-+-+ 332 | ID | len | 333 +-+-+-+-+-+-+-+-+ 335 The 4-bit ID is the local identifier of this element in the range 336 1-14 inclusive. In the signaling section, this is referred to as the 337 valid range. 339 The local identifier value 15 is reserved for future extension and 340 MUST NOT be used as an identifier. If the ID value 15 is 341 encountered, its length field MUST be ignored, processing of the 342 entire extension MUST terminate at that point, and only the extension 343 elements present prior to the element with ID 15 SHOULD be 344 considered. 346 The 4-bit length is the number minus one of data bytes of this header 347 extension element following the one-byte header. Therefore, the 348 value zero in this field indicates that one byte of data follows, and 349 a value of 15 (the maximum) indicates element data of 16 bytes. 350 (This permits carriage of 16-byte values, which is a common length of 351 labels and identifiers, while losing the possibility of zero-length 352 values -- which would often be padded anyway.) 354 An example header extension, with three extension elements, and some 355 padding follows: 357 0 1 2 3 358 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 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 | 0xBE | 0xDE | length=3 | 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 | ID | L=0 | data | ID | L=1 | data... 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 ...data | 0 (pad) | 0 (pad) | ID | L=3 | 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 | data | 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 4.3. Two-Byte Header 371 In the two-byte header form, the 16-bit value defined by the RTP 372 specification for a header extension, labeled in the RTP 373 specification as "defined by profile", is defined as shown below. 375 0 1 376 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 | 0x100 |appbits| 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 The appbits field is 4 bits that are application-dependent and MAY be 382 defined to be any value or meaning, and are outside the scope of this 383 specification. For the purposes of signaling, this field is treated 384 as a special extension value assigned to the local identifier 256. 385 If no extension has been specified through configuration or signaling 386 for this local identifier value 256, the appbits field SHOULD be set 387 to all 0s by the sender and MUST be ignored by the receiver. 389 Each extension element starts with a byte containing an ID and a byte 390 containing a length: 392 0 1 393 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 | ID | length | 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 The 8-bit ID is the local identifier of this element in the range 399 1-255 inclusive. In the signaling section, the range 1-256 is 400 referred to as the valid range, with the values 1-255 referring to 401 extension elements, and the value 256 referring to the 4-bit field 402 'appbits' (above). Note that there is one ID space for both one-byte 403 and two-byte form. This means that the lower values (1-14) can be 404 used in the 4-bit ID field in the one-byte header format with the 405 same meanings. 407 The 8-bit length field is the length of extension data in bytes not 408 including the ID and length fields. The value zero indicates there 409 is no data following. 411 An example header extension, with three extension elements, and some 412 padding follows: 414 0 1 2 3 415 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 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 | 0x10 | 0x00 | length=3 | 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 | ID | L=0 | ID | L=1 | 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 | data | 0 (pad) | ID | L=4 | 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 | data | 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 5. SDP Signaling Design 428 The indication of the presence of this extension, and the mapping of 429 local identifiers used in the header extension to a larger namespace, 430 MUST be performed out-of-band, for example, as part of a SIP offer/ 431 answer exchange using SDP. This section defines such signaling in 432 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 offer/answer negotiation 438 as described in the next section, but remapping to conformant values 439 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 506 a=extmap:2/sendrecv http://example.com/082005/ext.htm#xmeta short 508 When SDP signaling is used for the RTP session, it is the presence of 509 the 'extmap' attribute(s) that is diagnostic that this style of 510 header extensions is used, not the magic number indicated above. 512 6. SDP Signaling for support of mixed one byte and two bytes header 513 extensions. 515 In order to allow for backward interoperability with systems that do 516 not support mixing of one byte and two bytes header extensions this 517 document defines the "a=extmap-allow-mixed" Session Description 518 Protocol (SDP) [RFC4566] attribute to indicate if the participant is 519 capable of supporting this new mode. The attribute takes no value. 520 This attribute can be used at the session or media levels. A 521 participant that proposes the use of this mode SHALL itself support 522 the reception of mixed one byte and two bytes header extensions. 524 The negotiation for mixed one byte and two bytes extension MUST be 525 negotiated in offer/answer [RFC3264]. In the absence of negotiation 526 using offer/answer, mixed headers MUST NOT occur unless the 527 transmitter has some (out of band) knowledge that all potential 528 recipients support this mode. 530 The formal definition of this attribute is: 532 Name: extmap-allow-mixed 534 Value: 536 Usage Level: session, media 538 Charset Dependent: no 540 Example: 542 a=extmap-allow-mixed 544 When doing SDP Offer/Answer [RFC3264] an offering client that wishes 545 to use both one and two bytes extensions MUST include the attribute 546 "a= extmap-allow-mixed " in the SDP offer. If "a= extmap-allow-mixed 547 " is present in the offer SDP, the answerer that supports this mode 548 and wishes to use it SHALL include the "a=extmap-allow-mixed " 549 attribute in the answer. In cases the where the attribute has been 550 excluded, both clients SHALL NOT use mixed one bytes and two bytes 551 extensions in the same RTP stream but MAY use one-byte or two-bytes 552 form exclusively (see section 4.1.2). 554 7. Offer/Answer 556 The simple signaling described above for the extmap attribute MAY be 557 enhanced in an offer/answer context, to permit: 559 o asymmetric behavior (extensions sent in only one direction), 561 o the offer of mutually exclusive alternatives, or 563 o the offer of more extensions than can be sent in a single session. 565 A direction attribute MAY be included in an extmap; without it, the 566 direction implicitly inherits, of course, from the stream direction, 567 or is "sendrecv" for session-level attributes or extensions of 568 "inactive" streams. The direction MUST be one of "sendonly", 569 "recvonly", "sendrecv", or "inactive" as specified in [RFC3264] 571 Extensions, with their directions, MAY be signaled for an "inactive" 572 stream. It is an error to use an extension direction incompatible 573 with the stream direction (e.g., a "sendonly" attribute for a 574 "recvonly" stream). 576 If an offer or answer contains session-level mappings (and hence no 577 media-level mappings), and different behavior is desired for each 578 stream, then the entire set of extension map declarations MAY be 579 moved into the media-level section(s) of the SDP. (Note that this 580 specification does not permit mixing global and local declarations, 581 to make identifier management easier.) 583 If an extension map is offered as "sendrecv", explicitly or 584 implicitly, and asymmetric behavior is desired, the SDP answer MAY be 585 changed to modify or add direction qualifiers for that extension. 587 If an extension is marked as "sendonly" and the answerer desires to 588 receive it, the extension MUST be marked as "recvonly" in the SDP 589 answer. An answerer that has no desire to receive the extension or 590 does not understand the extension SHOULD remove it from the SDP 591 answer. 593 If an extension is marked as "recvonly" and the answerer desires to 594 send it, the extension MUST be marked as "sendonly" in the SDP 595 answer. An answerer that has no desire to, or is unable to, send the 596 extension SHOULD remove it from the SDP answer. 598 Local identifiers in the valid range inclusive in an offer or answer 599 MUST NOT be used more than once per media section (including the 600 session-level section). A session update MAY change the direction 601 qualifiers of extensions under use. A session update MAY add or 602 remove extension(s). Identifiers values in the valid range MUST NOT 603 be altered (remapped). 605 Note that, under this rule, the same local identifier cannot be used 606 for two extensions for the same media, even when one is "sendonly" 607 and the other "recvonly", as it would then be impossible to make 608 either of them sendrecv (since re-numbering is not permitted either). 610 If a party wishes to offer mutually exclusive alternatives, then 611 multiple extensions with the same identifier in the extended range 612 4096-4351 MAY be offered; the answerer SHOULD select at most one of 613 the offered extensions with the same identifier, and remap it to a 614 free identifier in the valid range, for that extension to be usable. 616 Similarly, if more extensions are offered than can be fit in the 617 valid range, identifiers in the range 4096-4351 MAY be offered; the 618 answerer SHOULD choose those that are desired, and remap them to a 619 free identifier in the valid range. 621 An answerer may copy an extmap for an identifier in the extended 622 range into the answer to indicate to the offerer that it supports 623 that extension. Of course, such an extension cannot be used, since 624 there is no way to specify them in an extension header. If needed, 625 the offerer or answerer can update the session to assign a valid 626 identifier to that extension URI. 628 Rationale: the range 4096-4351 for these negotiation identifiers is 629 deliberately restricted to allow expansion of the range of valid 630 identifiers in future. 632 Either party MAY include extensions in the stream other than those 633 negotiated, or those negotiated as "inactive", for example, for the 634 benefit of intermediate nodes. Only extensions that appeared with an 635 identifier in the valid range in SDP originated by the sender can be 636 sent. 638 Example (port numbers, RTP profiles, payload IDs and rtpmaps, etc. 639 all omitted for brevity): 641 The offer: 643 a=extmap:1 URI-toffset 644 a=extmap:14 URI-obscure 645 a=extmap:4096 URI-gps-string 646 a=extmap:4096 URI-gps-binary 647 a=extmap:4097 URI-frametype 648 m=video 649 a=sendrecv 650 m=audio 651 a=sendrecv 653 The answerer is interested in receiving GPS in string format only on 654 video, but cannot send GPS at all. It is not interested in 655 transmission offsets on audio, and does not understand the URI- 656 obscure extension. It therefore moves the extensions from session 657 level to media level, and adjusts the declarations: 659 m=video 660 a=sendrecv 661 a=extmap:1 URI-toffset 662 a=extmap:2/recvonly URI-gps-string 663 a=extmap:3 URI-frametype 664 m=audio 665 a=sendrecv 666 a=extmap:1/sendonly URI-toffset 668 8. BNF Syntax 670 The syntax definition below uses ABNF according to [RFC5234]. The 671 syntax element 'URI' is defined in [RFC3986] (only absolute URIs are 672 permitted here). The syntax element 'extmap' is an attribute as 673 defined in [RFC4566], i.e., "a=" precedes the extmap definition. 674 Specific extensionattributes are defined by the specification that 675 defines a specific extension name; there can be several. 677 Name: extmap 679 Value: extmap-value 681 Syntax: 683 extmap-value = mapentry SP extensionname 684 [SP extensionattributes] 686 mapentry = "extmap:" 1*5DIGIT ["/" direction] 688 extensionname = URI 690 extensionattributes = byte-string 692 direction = "sendonly" / "recvonly" / "sendrecv" / "inactive" 694 URI = 696 byte-string = 698 SP = 700 DIGIT = 702 9. Security Considerations 704 This document defines only a place to transmit information; the 705 security implications of each of the extensions MUST be discussed 706 with those extensions. 708 Extensions usage is negotiated using [RFC3264] so integrity 709 protection and end-to-end authentication MUST be used. The security 710 considerations of [RFC3264] MUST be followed, to prevent, for 711 example, extension usage blocking. 713 Header extensions have the same security coverage as the RTP header 714 itself. When Secure Real-time Transport Protocol (SRTP) [RFC3711] is 715 used to protect RTP sessions, the RTP payload can be both encrypted 716 and integrity protected, while the RTP header is either unprotected 717 or integrity protected. In order to prevent DOS attacks, for 718 example, by changing the header extension integrity protection SHOULD 719 be used. Lower layer security protection like DTLS[RFC6347] MAY be 720 used. RTP header extensions can carry sensitive information for 721 which participants in multimedia sessions want confidentiality. 722 RFC6904 [RFC6904] provides a mechanism, extending the mechanisms of 723 SRTP, to selectively encrypt RTP header extensions in SRTP. 725 Other security options for securing RTP are discussed in [RFC7201]. 727 10. IANA Considerations 729 This document updates the IANA consideration to reference this 730 document and adds a new SDP attribute in section 10.3 732 Note to IANA : change RFCxxxx to this RFC number and remove the note. 734 10.1. Identifier Space for IANA to Manage 736 The mapping from the naming URI form to a reference to a 737 specification is managed by IANA. Insertion into this registry is 738 under the requirements of "Expert Review" as defined in [RFC5226]. 740 The IANA will also maintain a server that contains all of the 741 registered elements in a publicly accessible space. 743 Here is the formal declaration to comply with the IETF URN Sub- 744 namespace specification [RFC3553]. 746 o Registry name: RTP Compact Header Extensions 748 o Specification: RFC 5285 and RFCs updating RFC 5285. 750 o Information required: 752 A. The desired extension naming URI 754 B. A formal reference to the publicly available specification 756 C. A short phrase describing the function of the extension 758 D. Contact information for the organization or person making the 759 registration 761 For extensions defined in RFCs, the URI SHOULD be of the form 762 urn:ietf:params:rtp-hdrext:, and the formal reference is the RFC 763 number of the RFC documenting the extension. 765 o Review process: Expert review is REQUIRED. The expert review 766 SHOULD check the following requirements: 768 1. that the specification is publicly available; 770 2. that the extension complies with the requirements of RTP, and 771 this specification, for header extensions (specifically, that 772 the header extension can be ignored or discarded without 773 breaking the RTP layer); 775 3. that the extension specification is technically consistent (in 776 itself and with RTP), complete, and comprehensible; 778 4. that the extension does not duplicate functionality in 779 existing IETF specifications (including RTP itself), or other 780 extensions already registered; 782 5. that the specification contains a security analysis regarding 783 the content of the header extension; 785 6. that the extension is generally applicable, for example point- 786 to-multipoint safe, and the specification correctly describes 787 limitations if they exist; and 789 7. that the suggested naming URI form is appropriately chosen and 790 unique. 792 o Size and format of entries: a mapping from a naming URI string to 793 a formal reference to a publicly available specification, with a 794 descriptive phrase and contact information. 796 o Initial assignments: none. 798 10.2. Registration of the SDP extmap Attribute 800 IANA is requested to register the extmap SDP [RFC4566] attribute. 802 SDP Attribute ("att-field"): 803 Attribute name: extmap 804 Long form: generic header extension map definition 805 Type of name: att-field 806 Type of attribute: Media or session level 807 Subject to charset: No 808 Purpose: defines the mapping from the extension 809 numbers used in packet headers 810 into extension names. 811 Reference: [RFCXXXX] 812 Values: See [RFCXXXX] 814 10.3. Registration of the SDP extmap-allow-mixed Attribute 816 The IANA is requested to register one new SDP attribute: 818 SDP Attribute ("att-field"): 819 Attribute name: extmap-allow-mixed 820 Long form: One and Two bytes mixed mode 821 Type of name: att-field 822 Type of attribute: Media or session level 823 Subject to charset: No 824 Purpose: Negotiate the use of One and Two bytes 825 in the same RTP stream. 826 Reference: [RFCXXXX] 827 Values: None 829 11. Changes from RFC5285 831 The major motivation for updating [RFC5285] was to allow having one 832 byte and two bytes RTP header extensions in the same RTP stream (but 833 not in the same RTP packet). The support for this case is negotiated 834 using a new SDP attribute "extmap-allow-mixed" specified in this 835 document. 837 The other major change is to update the requirement from the RTP 838 specification and[RFC5285] that the header extension "is designed so 839 that the header extension MAY be ignored". This is described in 840 section 4.1. 842 The transmission consideration section (4.1.1) adds more text to 843 clarify when and how many times to send the RTP header extension to 844 provide higher probability of delivery 846 >The security section was expanded 848 The rest of the changes are editorial. 850 12. Acknowledgments 852 Both Brian Link and John Lazzaro provided helpful comments on an 853 initial draft of this document. Colin Perkins was helpful in 854 reviewing and dealing with the details. The use of URNs for IETF- 855 defined extensions was suggested by Jonathan Lennox, and Pete Cordell 856 was instrumental in improving the padding wording. Dave Oran 857 provided feedback and text in the review. Mike Dolan contributed the 858 two-byte header form. Magnus Westerlund and Tom Taylor were 859 instrumental in managing the registration text. 861 13. References 863 13.1. Normative References 865 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 866 Requirement Levels", BCP 14, RFC 2119, 867 DOI 10.17487/RFC2119, March 1997, 868 . 870 [RFC2508] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP 871 Headers for Low-Speed Serial Links", RFC 2508, 872 DOI 10.17487/RFC2508, February 1999, 873 . 875 [RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., 876 Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, 877 K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., 878 Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header 879 Compression (ROHC): Framework and four profiles: RTP, UDP, 880 ESP, and uncompressed", RFC 3095, DOI 10.17487/RFC3095, 881 July 2001, . 883 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 884 with Session Description Protocol (SDP)", RFC 3264, 885 DOI 10.17487/RFC3264, June 2002, 886 . 888 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 889 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 890 RFC 3711, DOI 10.17487/RFC3711, March 2004, 891 . 893 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 894 Resource Identifier (URI): Generic Syntax", STD 66, 895 RFC 3986, DOI 10.17487/RFC3986, January 2005, 896 . 898 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 899 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 900 July 2006, . 902 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 903 Specifications: ABNF", STD 68, RFC 5234, 904 DOI 10.17487/RFC5234, January 2008, 905 . 907 [RFC6904] Lennox, J., "Encryption of Header Extensions in the Secure 908 Real-time Transport Protocol (SRTP)", RFC 6904, 909 DOI 10.17487/RFC6904, April 2013, 910 . 912 13.2. Informative References 914 [I-D.ietf-mmusic-sdp-bundle-negotiation] 915 Holmberg, C., Alvestrand, H., and C. Jennings, 916 "Negotiating Media Multiplexing Using the Session 917 Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- 918 negotiation-36 (work in progress), October 2016. 920 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 921 Jacobson, "RTP: A Transport Protocol for Real-Time 922 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 923 July 2003, . 925 [RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An 926 IETF URN Sub-namespace for Registered Protocol 927 Parameters", BCP 73, RFC 3553, DOI 10.17487/RFC3553, June 928 2003, . 930 [RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., 931 "RTP Control Protocol Extended Reports (RTCP XR)", 932 RFC 3611, DOI 10.17487/RFC3611, November 2003, 933 . 935 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 936 "Extended RTP Profile for Real-time Transport Control 937 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 938 DOI 10.17487/RFC4585, July 2006, 939 . 941 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 942 Hakenberg, "RTP Retransmission Payload Format", RFC 4588, 943 DOI 10.17487/RFC4588, July 2006, 944 . 946 [RFC5109] Li, A., Ed., "RTP Payload Format for Generic Forward Error 947 Correction", RFC 5109, DOI 10.17487/RFC5109, December 948 2007, . 950 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 951 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 952 DOI 10.17487/RFC5226, May 2008, 953 . 955 [RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP 956 Header Extensions", RFC 5285, DOI 10.17487/RFC5285, July 957 2008, . 959 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 960 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 961 January 2012, . 963 [RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP 964 Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014, 965 . 967 [RFC7667] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 7667, 968 DOI 10.17487/RFC7667, November 2015, 969 . 971 Authors' Addresses 973 Roni Even (editor) 974 Huawei Technologies 975 Tel Aviv 976 Israel 978 Email: Roni.even@huawei.com 980 David Singer 981 Apple, Inc. 982 1 Infinite Loop 983 Cupertino, CA 95014 984 USA 986 Phone: +1 408 996 1010 987 Email: singer@apple.com 988 URI: http://www.apple.com/quicktime 990 Harikishan Desineni 991 10001 Pacific Heights Blvd 992 San Diego, CA 92121 993 USA 995 Phone: +1 858 845 8996 996 Email: hdesinen@quicinc.com