idnits 2.17.1 draft-ietf-avtcore-rfc5285-bis-04.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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 11 characters in excess of 72. == The 'Obsoletes: ' line in the draft header should list only the _numbers_ of the RFCs which will be obsoleted by this document (if approved); it should not include the word 'RFC' in the list. -- The abstract seems to indicate that this document obsoletes RFC5285, but the header doesn't have an 'Obsoletes:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 28, 2016) is 2737 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 795, but not defined ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) ** Obsolete normative reference: 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: 3 errors (**), 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: RFC5285 (if approved) D. Singer 5 Intended status: Standards Track Apple, Inc. 6 Expires: May 1, 2017 H. Desineni 7 October 28, 2016 9 A General Mechanism for RTP Header Extensions 10 draft-ietf-avtcore-rfc5285-bis-04.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. The 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 May 1, 2017. 39 Copyright Notice 41 Copyright (c) 2016 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 considertions . . . . . . . . . . . . . 4 62 4.1.2. Header Extension type consideration . . . . . . . . . 6 63 4.2. One-Byte Header . . . . . . . . . . . . . . . . . . . . . 7 64 4.3. Two-Byte Header . . . . . . . . . . . . . . . . . . . . . 8 65 5. SDP Signaling Design . . . . . . . . . . . . . . . . . . . . 9 66 6. SDP Signaling for support of mixed one byte and two bytes 67 header extensions. . . . . . . . . . . . . . . . . . . . . . 11 68 7. Offer/Answer . . . . . . . . . . . . . . . . . . . . . . . . 12 69 8. BNF Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 14 70 9. Security Considerations . . . . . . . . . . . . . . . . . . . 15 71 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 72 10.1. Identifier Space for IANA to Manage . . . . . . . . . . 16 73 10.2. Registration of the SDP extmap Attribute . . . . . . . . 17 74 10.3. Registration of the SDP extmap-allow-mixed Attribute . . 17 75 11. Changes from RFC5285 . . . . . . . . . . . . . . . . . . . . 18 76 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 77 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 78 13.1. Normative References . . . . . . . . . . . . . . . . . . 18 79 13.2. Informative References . . . . . . . . . . . . . . . . . 19 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 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 bytes 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 value defined for an RTP extension 150 (defined below for the one-byte and two-byte header forms) is only an 151 architectural constant (e.g., for use by network analyzers); it is 152 the negotiation/definition (e.g., in SDP) that is the definitive 153 indication that this header extension is present. 155 This specification updates the requirement from the RTP specification 156 that the header extension "is designed so that the header extension 157 MAY be ignored". To be specific, header extensions using this 158 specification SHOULD be used for data that can safely be ignored by 159 the recipient without affecting interoperability, there can be 160 essential header extensions for interoperability and intermediaries 161 SHOULD NOT remove such header extensions. Note that the support of 162 header extension as specified in this recommendation is negotiated. 163 RTP Header extensions MUST NOT be used when the presence of the 164 extension has changed the form or nature of the rest of the packet in 165 a way that is not compatible with the way the stream is signaled 166 (e.g., as defined by the payload type). Valid examples might include 167 metadata that is additional to the usual RTP information, e.g. Audio 168 level from Client to mixer [RFC6464]. 170 The RTP header extension is formed as a sequence of extension 171 elements, with possible padding. Each extension element has a local 172 identifier and a length. The local identifiers MAY be mapped to a 173 larger namespace in the negotiation (e.g., session signaling). 175 4.1.1. transmission considertions 177 As is good network practice, data SHOULD only be transmitted when 178 needed. The RTP header extension SHOULD only be present in a packet 179 if that packet also contains one or more extension elements, as 180 defined here. An extension element SHOULD only be present in a 181 packet when needed; the signaling setup of extension elements 182 indicates only that those elements can be present in some packets, 183 not that they are in fact present in all (or indeed, any) packets. 185 Some general considerations for getting the header extensions 186 delivered to the receiver: 188 1. The probability for packet loss and burst loss determine how many 189 repetitions of the header extensions will be required to reach a 190 targeted delivery probability, and if burst loss is likely, what 191 distribution would be needed to avoid getting all repetitions of 192 the header extensions lost in a single burst. 194 2. If a set of packets are all needed to enable decoding, there is 195 commonly no reason for including the header extension in all of 196 these packets, as they share fate. Instead, at most one instance 197 of the header extension per independently decodable set of media 198 data would be a more efficient use of the bandwidth. 200 3. How early the Header Extension item information is needed, from 201 the first received RTP data or only after some set of packets are 202 received, can guide if the header extension(s) should be in all 203 of the first N packets or be included only once per set of 204 packets, for example once per video frame. 206 4. The use of RTP level robustness mechanisms, such as RTP 207 retransmission [RFC4588], or Forward Error Correction, e.g., 208 [RFC5109] may treat packets differently from a robustness 209 perspective, and header extensions should be added to packets 210 that get a treatment corresponding to the relative importance of 211 receiving the information. 213 As a summary, the number of header extension transmissions should be 214 tailored to a desired probability of delivery taking the receiver 215 population size into account. For the very basic case, N repetitions 216 of the header extensions should be sufficient, but may not be 217 optimal. N is selected so that the header extension target delivery 218 probability reaches 1-P^N, where P is the probability of packet loss. 219 For point to point or small receiver populations, it might also be 220 possible to use feedback, such as RTCP, to determine when the 221 information in the header extensions has reached all receivers and 222 stop further repetitions. Feedback that can be used includes the 223 RTCP XR Loss RLE report block [RFC3611], which will indicate 224 successful delivery of particular packets. If the RTP/AVPF Transport 225 Layer Feedback Messages for generic NACK [RFC4585] is used, it can 226 indicate the failure to deliver an RTP packet with the header 227 extension, thus indicating the need for further repetitions. The 228 normal RTCP report blocks can also provide an indicator of successful 229 delivery, if no losses are indicated for a reporting interval 230 covering the RTP packets with the header extension. Note that loss 231 of an RTCP packet reporting on an interval where RTP header extension 232 packets were sent, does not necessarily mean that the RTP header 233 extension packets themselves were lost. 235 4.1.2. Header Extension type consideration 237 Each extension element in a packet has a local identifier (ID) and a 238 length. The local identifiers present in the stream MUST have been 239 negotiated or defined out-of-band. There are no static allocations 240 of local identifiers. Each distinct extension MUST have a unique ID. 241 The value 0 is reserved for padding and MUST NOT be used as a local 242 identifier. 244 There are two variants of the extension: one-byte and two-byte 245 headers. Since it is expected that (a) the number of extensions in 246 any given RTP session is small and (b) the extensions themselves are 247 small, the one-byte header form is preferred and MUST be supported by 248 all receivers. A stream MUST contain only one-byte or two-byte 249 headers unless it is known that all recipients support mixing, either 250 by offer/answer negotiation (see section 6) or by out-of-band 251 knowledge. Each RTP packet with an RTP header extension following 252 this specification will indicate if it contains one or two byte 253 header extensions through the use of the "defined by profile" field. 254 Only the extension element types that match the header extension 255 format, i.e. one- or two-byte, MUST be used in that RTP packet. 256 Transmitters SHOULD NOT use the two-byte form when all extensions are 257 small enough for the one-byte header form. Transmitters that intend 258 to send the two-byte form SHOULD use IDs above 14 if they want to let 259 the Receivers know that they intend to use two-byte form, for example 260 if the RTP header extension is longer than 16 bytes. A transmitter 261 MAY be aware that an intermediary may add RTP header extensions in 262 this case, the transmitter SHOULD use two-byte form. 264 A sequence of extension elements, possibly with padding, forms the 265 header extension defined in the RTP specification. There are as many 266 extension elements as fit into the length as indicated in the RTP 267 header extension length. Since this length is signaled in full 268 32-bit words, padding bytes are used to pad to a 32-bit boundary. 269 The entire extension is parsed byte-by-byte to find each extension 270 element (no alignment is needed), and parsing stops at the earlier of 271 the end of the entire header extension, or in one-byte headers only 272 case, on encountering an identifier with the reserved value of 15. 274 In both forms, padding bytes have the value of 0 (zero). They MAY be 275 placed between extension elements, if desired for alignment, or after 276 the last extension element, if needed for padding. A padding byte 277 does not supply the ID of an element, nor the length field. When a 278 padding byte is found, it is ignored and the parser moves on to 279 interpreting the next byte. 281 Note carefully that the one-byte header form allows for data lengths 282 between 1 and 16 bytes, by adding 1 to the signaled length value 283 (thus, 0 in the length field indicates 1 byte of data follows). This 284 allows for the important case of 16-byte payloads. This addition is 285 not performed for the two-byte headers, where the length field 286 signals data lengths between 0 and 255 bytes. 288 Use of RTP header extensions will reduce the efficiency of RTP header 289 compression, since the header extension will be sent uncompressed 290 unless the RTP header compression module is updated to recognize the 291 extension header. If header extensions are present in some packets, 292 but not in others, this can also reduce compression efficiency by 293 requiring an update to the fixed header to be conveyed when header 294 extensions start or stop being sent. The interactions of the RTP 295 header extension and header compression is explored further in 296 [RFC2508] and [RFC3095]. 298 4.2. One-Byte Header 300 In the one-byte header form of extensions, the 16-bit value REQUIRED 301 by the RTP specification for a header extension, labeled in the RTP 302 specification as "defined by profile", MUST have the fixed bit 303 pattern 0xBEDE (the first version of this specification was written 304 on the feast day of the Venerable Bede). 306 Each extension element MUST starts with a byte containing an ID and a 307 length: 309 0 310 0 1 2 3 4 5 6 7 311 +-+-+-+-+-+-+-+-+ 312 | ID | len | 313 +-+-+-+-+-+-+-+-+ 315 The 4-bit ID is the local identifier of this element in the range 316 1-14 inclusive. In the signaling section, this is referred to as the 317 valid range. 319 The local identifier value 15 is reserved for future extension and 320 MUST NOT be used as an identifier. If the ID value 15 is 321 encountered, its length field MUST be ignored, processing of the 322 entire extension MUST terminate at that point, and only the extension 323 elements present prior to the element with ID 15 SHOULD be 324 considered. 326 The 4-bit length is the number minus one of data bytes of this header 327 extension element following the one-byte header. Therefore, the 328 value zero in this field indicates that one byte of data follows, and 329 a value of 15 (the maximum) indicates element data of 16 bytes. 331 (This permits carriage of 16-byte values, which is a common length of 332 labels and identifiers, while losing the possibility of zero-length 333 values -- which would often be padded anyway.) 335 An example header extension, with three extension elements, and some 336 padding follows: 338 0 1 2 3 339 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 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 | 0xBE | 0xDE | length=3 | 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 | ID | L=0 | data | ID | L=1 | data... 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 ...data | 0 (pad) | 0 (pad) | ID | L=3 | 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 | data | 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 4.3. Two-Byte Header 352 In the two-byte header form, the 16-bit value defined by the RTP 353 specification for a header extension, labeled in the RTP 354 specification as "defined by profile", is defined as shown below. 356 0 1 357 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 | 0x100 |appbits| 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 The appbits field is 4 bits that are application-dependent and MAY be 363 defined to be any value or meaning, and are outside the scope of this 364 specification. For the purposes of signaling, this field is treated 365 as a special extension value assigned to the local identifier 256. 366 If no extension has been specified through configuration or signaling 367 for this local identifier value 256, the appbits field SHOULD be set 368 to all 0s by the sender and MUST be ignored by the receiver. 370 Each extension element starts with a byte containing an ID and a byte 371 containing a length: 373 0 1 374 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 | ID | length | 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 The 8-bit ID is the local identifier of this element in the range 380 1-255 inclusive. In the signaling section, the range 1-256 is 381 referred to as the valid range, with the values 1-255 referring to 382 extension elements, and the value 256 referring to the 4-bit field 383 'appbits' (above). Note that there is one ID space for both one-byte 384 and two-byte form this means that the lower values (1-14) can be used 385 in the 4-bit ID field in the one-byte header format as well. 387 The 8-bit length field is the length of extension data in bytes not 388 including the ID and length fields. The value zero indicates there 389 is no data following. 391 An example header extension, with three extension elements, and some 392 padding follows: 394 0 1 2 3 395 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 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 | 0x10 | 0x00 | length=3 | 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 | ID | L=0 | ID | L=1 | 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 | data | 0 (pad) | ID | L=4 | 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 | data | 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 5. SDP Signaling Design 408 The indication of the presence of this extension, and the mapping of 409 local identifiers used in the header extension to a larger namespace, 410 MUST be performed out-of-band, for example, as part of a SIP offer/ 411 answer exchange using SDP. This section defines such signaling in 412 SDP. 414 A usable mapping MUST use IDs in the valid range, and each ID in this 415 range MUST be used only once for each media (or only once if the 416 mappings are session level). Mappings that do not conform to these 417 rules MAY be presented, for instance, during offer/answer negotiation 418 as described in the next section, but remapping to conformant values 419 is necessary before they can be applied. 421 Each extension is named by a URI. That URI MUST be absolute, and 422 precisely identifies the format and meaning of the extension. URIs 423 that contain a domain name SHOULD also contain a month-date in the 424 form mmyyyy. The definition of the element and assignment of the URI 425 MUST have been authorized by the owner of the domain name on or very 426 close to that date. (This avoids problems when domain names change 427 ownership.) If the resource or document defines several extensions, 428 then the URI MUST identify the actual extension in use, e.g., using a 429 fragment or query identifier (characters after a '#' or '?' in the 430 URI). 432 Rationale: the use of URIs provides for a large, unallocated space, 433 and gives documentation on the extension. The URIs do not have to be 434 de-referencable, in order to permit confidential or experimental use, 435 and to cover the case when extensions continue to be used after the 436 organization that defined them ceases to exist. 438 An extension URI with the same attributes MUST NOT appear more than 439 once applying to the same stream, i.e., at session level or in the 440 declarations for a single stream at media level. (The same extension 441 can, of course, be used for several streams, and can appear 442 differently parameterized for the same stream.) 444 For extensions defined in RFCs, the URI used SHOULD be a URN starting 445 "urn:ietf:params:rtp-hdrext:" and followed by a registered, 446 descriptive name. 448 The registration requirements are detailed in the IANA Considerations 449 section, below. 451 An example (this is only an example), where 'avt-example-metadata' is 452 the hypothetical name of a header extension, might be: 454 urn:ietf:params:rtp-hdrext:avt-example-metadata 456 An example name not from the IETF (this is only an example) might be: 458 http://example.com/082005/ext.htm#example-metadata 460 The mapping MAY be provided per media stream (in the media-level 461 section(s) of SDP, i.e., after an "m=" line) or globally for all 462 streams (i.e., before the first "m=" line, at session level). The 463 definitions MUST be either all session level or all media level; it 464 is not permitted to mix the two styles. In addition, as noted above, 465 the IDs used MUST be unique for each stream type for a given media, 466 or for the session for session-level declarations. 468 Each local identifier potentially used in the stream is mapped to a 469 string using an attribute of the form: 471 a=extmap:["/"] 473 where is a URI, as above, is the local identifier (ID) 474 of this extension and is an integer in the valid range inclusive (0 475 is reserved for padding in both forms, and 15 is reserved in the one- 476 byte header form, as noted above), and is one of 477 "sendonly", "recvonly", "sendrecv", or "inactive" (without the 478 quotes) with relation to the device being configured. 480 The formal BNF syntax is presented in a later section of this 481 specification. 483 Example: 485 a=extmap:1 http://example.com/082005/ext.htm#ttime 487 a=extmap:2/sendrecv http://example.com/082005/ext.htm#xmeta short 489 When SDP signaling is used for the RTP session, it is the presence of 490 the 'extmap' attribute(s) that is diagnostic that this style of 491 header extensions is used, not the magic number indicated above. 493 6. SDP Signaling for support of mixed one byte and two bytes header 494 extensions. 496 In order to allow for backward interoperability with systems that do 497 not support mixing of one byte and two bytes header extensions this 498 document defines the "a=extmap-allow-mixed" Session Description 499 Protocol (SDP) [RFC4566] attribute to indicate if the participant is 500 capable of supporting this new mode. The attribute takes no value. 501 This attribute can be used at the session or media levels. A 502 participant that proposes the use of this mode SHALL itself support 503 the reception of mixed one byte and two bytes header extensions. 505 The negotiation for mixed one byte and two bytes extension MUST be 506 negotiated in offer/answer [RFC3264]. In the absence of negotiation 507 using offer/answer, mixed headers MUST NOT occur unless the 508 transmitter has some (out of band) knowledge that all potential 509 recipients support this mode. 511 The formal definition of this attribute is: 513 Name: extmap-allow-mixed 515 Value: 517 Usage Level: session, media 519 Charset Dependent: no 521 Example: 523 a=extmap-allow-mixed 525 When doing SDP Offer/Answer [RFC3264] an offering client that wishes 526 to use both one and two bytes extensions MUST include the attribute 527 "a= extmap-allow-mixed " in the SDP offer. If "a= extmap-allow-mixed 528 " is present in the offer SDP, the answerer that supports this mode 529 and wishes to use it SHALL include the "a=extmap-allow-mixed " 530 attribute in the answer. In cases the answer has been excluded, 531 neither clients SHALL use mixed one bytes and two bytes extensions in 532 the same RTP stream but MAY use one-byte or two-bytes form (see 533 section 4.1.2). 535 7. Offer/Answer 537 The simple signaling described above for the extmap attribute MAY be 538 enhanced in an offer/answer context, to permit: 540 o asymmetric behavior (extensions sent in only one direction), 542 o the offer of mutually exclusive alternatives, or 544 o the offer of more extensions than can be sent in a single session. 546 A direction attribute MAY be included in an extmap; without it, the 547 direction implicitly inherits, of course, from the stream direction, 548 or is "sendrecv" for session-level attributes or extensions of 549 "inactive" streams. The direction MUST be one of "sendonly", 550 "recvonly", "sendrecv", or "inactive" as specified in [RFC3264] 552 Extensions, with their directions, MAY be signaled for an "inactive" 553 stream. It is an error to use an extension direction incompatible 554 with the stream direction (e.g., a "sendonly" attribute for a 555 "recvonly" stream). 557 If an offer or answer contains session-level mappings (and hence no 558 media-level mappings), and different behavior is desired for each 559 stream, then the entire set of extension map declarations MAY be 560 moved into the media-level section(s) of the SDP. (Note that this 561 specification does not permit mixing global and local declarations, 562 to make identifier management easier.) 564 If an extension map is offered as "sendrecv", explicitly or 565 implicitly, and asymmetric behavior is desired, the SDP MAY be 566 modified to modify or add direction qualifiers for that extension. 568 If an extension is marked as "sendonly" and the answerer desires to 569 receive it, the extension MUST be marked as "recvonly" in the SDP 570 answer. An answerer that has no desire to receive the extension or 571 does not understand the extension SHOULD remove it from the SDP 572 answer. 574 If an extension is marked as "recvonly" and the answerer desires to 575 send it, the extension MUST be marked as "sendonly" in the SDP 576 answer. An answerer that has no desire to, or is unable to, send the 577 extension SHOULD remove it from the SDP answer. 579 Local identifiers in the valid range inclusive in an offer or answer 580 MUST NOT be used more than once per media section (including the 581 session-level section). A session update MAY change the direction 582 qualifiers of extensions under use. A session update MAY add or 583 remove extension(s). Identifiers values in the valid range MUST NOT 584 be altered (remapped). 586 Note that, under this rule, the same local identifier cannot be used 587 for two extensions for the same media, even when one is "sendonly" 588 and the other "recvonly", as it would then be impossible to make 589 either of them sendrecv (since re-numbering is not permitted either). 591 If a party wishes to offer mutually exclusive alternatives, then 592 multiple extensions with the same identifier in the (unusable) range 593 4096-4351 MAY be offered; the answerer SHOULD select at most one of 594 the offered extensions with the same identifier, and remap it to a 595 free identifier in the valid range, for that extension to be usable. 597 Similarly, if more extensions are offered than can be fit in the 598 valid range, identifiers in the range 4096-4351 MAY be offered; the 599 answerer SHOULD choose those that are desired, and remap them to a 600 free identifier in the valid range. 602 It is always allowed to place the offered identifier value "as is" in 603 the SDP answer (for example, due to lack of a free identifier value 604 in the valid range). Extensions with an identifier outside the valid 605 range MUST NOT, of course, be used. If needed, the offerer or 606 answerer can update the session to make space for such an extension. 608 Rationale: the range 4096-4351 for these negotiation identifiers is 609 deliberately restricted to allow expansion of the range of valid 610 identifiers in future. 612 Either party MAY include extensions in the stream other than those 613 negotiated, or those negotiated as "inactive", for example, for the 614 benefit of intermediate nodes. Only extensions that appeared with an 615 identifier in the valid range in SDP originated by the sender can be 616 sent. 618 Example (port numbers, RTP profiles, payload IDs and rtpmaps, etc. 619 all omitted for brevity): 621 The offer: 623 a=extmap:1 URI-toffset 624 a=extmap:14 URI-obscure 625 a=extmap:4096 URI-gps-string 626 a=extmap:4096 URI-gps-binary 627 a=extmap:4097 URI-frametype 628 m=video 629 a=sendrecv 630 m=audio 631 a=sendrecv 633 The answerer is interested in receiving GPS in string format only on 634 video, but cannot send GPS at all. It is not interested in 635 transmission offsets on audio, and does not understand the URI- 636 obscure extension. It therefore moves the extensions from session 637 level to media level, and adjusts the declarations: 639 m=video 640 a=sendrecv 641 a=extmap:1 URI-toffset 642 a=extmap:2/recvonly URI-gps-string 643 a=extmap:3 URI-frametype 644 m=audio 645 a=sendrecv 646 a=extmap:1/sendonly URI-toffset 648 8. BNF Syntax 650 The syntax definition below uses ABNF according to [RFC5234]. The 651 syntax element 'URI' is defined in [RFC3986] (only absolute URIs are 652 permitted here). The syntax element 'extmap' is an attribute as 653 defined in [RFC4566], i.e., "a=" precedes the extmap definition. 654 Specific extensionattributes are defined by the specification that 655 defines a specific extension name; there can be several. 657 extmap = mapentry SP extensionname [SP extensionattributes] 659 extensionname = URI 661 direction = "sendonly" / "recvonly" / "sendrecv" / "inactive" 663 mapentry = "extmap:" 1*5DIGIT ["/" direction] 665 extensionattributes = byte-string 667 URI = 669 byte-string = 671 SP = 673 DIGIT = 675 9. Security Considerations 677 This document defines only a place to transmit information; the 678 security implications of each of the extensions MUST be discussed 679 with those extensions. 681 Extensions usage is negotiated using [RFC3264] so integrity 682 protection and end-to-end authentication MUST be used. The security 683 considerations of [RFC3264] MUST be followed, to prevent, for 684 example, extension usage blocking. 686 Header extensions have the same security coverage as the RTP header 687 itself. When Secure Real-time Transport Protocol (SRTP) [RFC3711] is 688 used to protect RTP sessions, the RTP payload can be both encrypted 689 and integrity protected, while the RTP header is either unprotected 690 or integrity protected. In order to prevent DOS attacks, for 691 example, by changing the header extension integrity protection SHOULD 692 be used. Lower layer security protection like DTLS[RFC6347] MAY be 693 used. RTP header extensions can carry sensitive information for 694 which participants in multimedia sessions want confidentiality. 695 RFC6904 [RFC6904] provides a mechanism, extending the mechanisms of 696 SRTP, to selectively encrypt RTP header extensions in SRTP. 698 Other security options for securing RTP are discussed in [RFC7201]. 700 10. IANA Considerations 702 This document updates the IANA consideration to reference this 703 document and adds a new SDP attribute in section 10.3 704 Note to IANA : change RFCxxxx to this RFC number and remove the note. 706 10.1. Identifier Space for IANA to Manage 708 The mapping from the naming URI form to a reference to a 709 specification is managed by IANA. Insertion into this registry is 710 under the requirements of "Expert Review" as defined in [RFC5226]. 712 The IANA will also maintain a server that contains all of the 713 registered elements in a publicly accessible space. 715 Here is the formal declaration to comply with the IETF URN Sub- 716 namespace specification [RFC3553]. 718 o Registry name: RTP Compact Header Extensions 720 o Specification: RFC 5285 and RFCs updating RFC 5285. 722 o Information required: 724 A. The desired extension naming URI 726 B. A formal reference to the publicly available specification 728 C. A short phrase describing the function of the extension 730 D. Contact information for the organization or person making the 731 registration 733 For extensions defined in RFCs, the URI SHOULD be of the form 734 urn:ietf:params:rtp-hdrext:, and the formal reference is the RFC 735 number of the RFC documenting the extension. 737 o Review process: Expert review is REQUIRED. The expert review 738 SHOULD check the following requirements: 740 1. that the specification is publicly available; 742 2. that the extension complies with the requirements of RTP and 743 this specification, for extensions; 745 3. that the extension specification is technically consistent (in 746 itself and with RTP), complete, and comprehensible; 748 4. that the extension does not duplicate functionality in 749 existing IETF specifications (including RTP itself), or other 750 extensions already registered; 752 5. that the specification contains a security analysis regarding 753 the content of the header extension; 755 6. that the extension is generally applicable, for example point- 756 to-multipoint safe, and the specification correctly describes 757 limitations if they exist; and 759 7. that the suggested naming URI form is appropriately chosen and 760 unique. 762 o Size and format of entries: a mapping from a naming URI string to 763 a formal reference to a publicly available specification, with a 764 descriptive phrase and contact information. 766 o Initial assignments: none. 768 10.2. Registration of the SDP extmap Attribute 770 IANA is requested to register the extmap SDP [RFC4566] attribute. 772 SDP Attribute ("att-field"): 773 Attribute name: extmap 774 Long form: generic header extension map definition 775 Type of name: att-field 776 Type of attribute: Media or session level 777 Subject to charset: No 778 Purpose: defines the mapping from the extension numbers used in 779 packet headers into extension names. 780 Reference: [RFCXXXX] 781 Values: See [RFCXXXX] 783 10.3. Registration of the SDP extmap-allow-mixed Attribute 785 The IANA is requested to register one new SDP attribute: 787 SDP Attribute ("att-field"): 788 Attribute name: extmap-allow-mixed 789 Long form: One and Two bytes mixed mode 790 Type of name: att-field 791 Type of attribute: Media or session level 792 Subject to charset: No 793 Purpose: Negotiate the use of One and Two bytes 794 in the same RTP stream. 795 Reference: [RFCXXXX] 796 Values: None 798 11. Changes from RFC5285 800 The major motivation for updating [RFC5285] was to allow having one 801 byte and two bytes RTP header extensions in the same RTP stream (but 802 not in the same RTP packet). The support for this case is negotiated 803 using a new SDP attribute "extmap-allowed-mixed" specified in this 804 document. 806 The other major change is to update the requirement from the RTP 807 specification and[RFC5285] that the header extension "is designed so 808 that the header extension MAY be ignored". This is described in 809 section 4.1. 811 The transmission consideration section (4.1.1) adds more text to 812 clarify when and how many times to send the RTP header extension to 813 provide higher probability of delivery 815 >The security section was expanded 817 The rest of the changes are editorial. 819 12. Acknowledgments 821 Both Brian Link and John Lazzaro provided helpful comments on an 822 initial draft of this document. Colin Perkins was helpful in 823 reviewing and dealing with the details. The use of URNs for IETF- 824 defined extensions was suggested by Jonathan Lennox, and Pete Cordell 825 was instrumental in improving the padding wording. Dave Oran 826 provided feedback and text in the review. Mike Dolan contributed the 827 two-byte header form. Magnus Westerlund and Tom Taylor were 828 instrumental in managing the registration text. 830 13. References 832 13.1. Normative References 834 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 835 Requirement Levels", BCP 14, RFC 2119, 836 DOI 10.17487/RFC2119, March 1997, 837 . 839 [RFC2508] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP 840 Headers for Low-Speed Serial Links", RFC 2508, February 841 1999. 843 [RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., 844 Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, 845 K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., 846 Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header 847 Compression (ROHC): Framework and four profiles: RTP, UDP, 848 ESP, and uncompressed", RFC 3095, July 2001. 850 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 851 with Session Description Protocol (SDP)", RFC 3264, 852 DOI 10.17487/RFC3264, June 2002, 853 . 855 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 856 Jacobson, "RTP: A Transport Protocol for Real-Time 857 Applications", STD 64, RFC 3550, July 2003. 859 [RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An 860 IETF URN Sub-namespace for Registered Protocol 861 Parameters", BCP 73, RFC 3553, June 2003. 863 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 864 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 865 RFC 3711, March 2004. 867 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 868 Resource Identifier (URI): Generic Syntax", STD 66, 869 RFC 3986, January 2005. 871 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 872 Description Protocol", RFC 4566, July 2006. 874 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 875 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 876 May 2008. 878 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 879 Specifications: ABNF", STD 68, RFC 5234, January 2008. 881 [RFC6904] Lennox, J., "Encryption of Header Extensions in the Secure 882 Real-time Transport Protocol (SRTP)", RFC 6904, 883 DOI 10.17487/RFC6904, April 2013, 884 . 886 13.2. Informative References 888 [RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., 889 "RTP Control Protocol Extended Reports (RTCP XR)", 890 RFC 3611, DOI 10.17487/RFC3611, November 2003, 891 . 893 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 894 "Extended RTP Profile for Real-time Transport Control 895 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 896 DOI 10.17487/RFC4585, July 2006, 897 . 899 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 900 Hakenberg, "RTP Retransmission Payload Format", RFC 4588, 901 DOI 10.17487/RFC4588, July 2006, 902 . 904 [RFC5109] Li, A., Ed., "RTP Payload Format for Generic Forward Error 905 Correction", RFC 5109, DOI 10.17487/RFC5109, December 906 2007, . 908 [RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP 909 Header Extensions", RFC 5285, DOI 10.17487/RFC5285, July 910 2008, . 912 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 913 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 914 January 2012, . 916 [RFC6464] Lennox, J., Ed., Ivov, E., and E. Marocco, "A Real-time 917 Transport Protocol (RTP) Header Extension for Client-to- 918 Mixer Audio Level Indication", RFC 6464, 919 DOI 10.17487/RFC6464, December 2011, 920 . 922 [RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP 923 Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014, 924 . 926 Authors' Addresses 928 Roni Even (editor) 929 Huawei Technologies 930 Shabazi 12A 931 Tel Aviv 932 Israel 934 Email: Roni.even@mail01.huawei.com 935 David Singer 936 Apple, Inc. 937 1 Infinite Loop 938 Cupertino, CA 95014 939 USA 941 Phone: +1 408 996 1010 942 Email: singer@apple.com 943 URI: http://www.apple.com/quicktime 945 Harikishan Desineni 946 10001 Pacific Heights Blvd 947 San Diego, CA 92121 948 USA 950 Phone: +1 858 845 8996 951 Email: hdesinen@quicinc.com