idnits 2.17.1 draft-ietf-avtcore-rfc5285-bis-03.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 : ---------------------------------------------------------------------------- == 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 12, 2016) is 2813 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: 'RFC4588' is mentioned on line 205, but not defined == Missing Reference: 'RFC5109' is mentioned on line 206, but not defined == Missing Reference: 'RFC3611' is mentioned on line 221, but not defined == Missing Reference: 'RFC4585' is mentioned on line 223, but not defined == Missing Reference: 'RFCXXXX' is mentioned on line 794, but not defined ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). 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: February 13, 2017 H. Desineni 7 August 12, 2016 9 A General Mechanism for RTP Header Extensions 10 draft-ietf-avtcore-rfc5285-bis-03.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. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on February 13, 2017. 38 Copyright Notice 40 Copyright (c) 2016 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 57 3. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . 3 58 4. Packet Design . . . . . . . . . . . . . . . . . . . . . . . . 3 59 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 4.1.1. transmission considertions . . . . . . . . . . . . . 4 61 4.1.2. Header Extension type consideration . . . . . . . . . 5 62 4.2. One-Byte Header . . . . . . . . . . . . . . . . . . . . . 7 63 4.3. Two-Byte Header . . . . . . . . . . . . . . . . . . . . . 8 64 5. SDP Signaling Design . . . . . . . . . . . . . . . . . . . . 9 65 6. SDP Signaling for support of mixed one byte and two bytes 66 header extensions. . . . . . . . . . . . . . . . . . . . . . 11 67 7. Offer/Answer . . . . . . . . . . . . . . . . . . . . . . . . 12 68 8. BNF Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 14 69 9. Security Considerations . . . . . . . . . . . . . . . . . . . 15 70 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 71 10.1. Identifier Space for IANA to Manage . . . . . . . . . . 15 72 10.2. Registration of the SDP extmap Attribute . . . . . . . . 17 73 10.3. Registration of the SDP Attribute . . . . . . . . . . . 17 74 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 75 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 76 12.1. Normative References . . . . . . . . . . . . . . . . . . 18 77 12.2. Informative References . . . . . . . . . . . . . . . . . 19 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 80 1. Introduction 82 The RTP specification [RFC3550] provides a capability to extend the 83 RTP header. It defines the header extension format and rules for its 84 use in Section 5.3.1. The existing header extension method permits 85 at most one extension per RTP packet, identified by a 16-bit 86 identifier and a 16-bit length field specifying the length of the 87 header extension in 32-bit words. 89 This mechanism has two conspicuous drawbacks. First, it permits only 90 one header extension in a single RTP packet. Second, the 91 specification gives no guidance as to how the 16-bit header extension 92 identifiers are allocated to avoid collisions. 94 This specification removes the first drawback by defining a backward- 95 compatible and extensible means to carry multiple header extension 96 elements in a single RTP packet. It removes the second drawback by 97 defining that these extension elements are named by URIs, defining an 98 IANA registry for extension elements defined in IETF specifications, 99 and a Session Description Protocol (SDP) method for mapping between 100 the naming URIs and the identifier values carried in the RTP packets. 102 This header extension applies to RTP/AVP (the Audio/Visual Profile) 103 and its extensions. 105 This document removes a limitation from RFC5285 that did not allow 106 sending both one byte and two bytes header extensions in the same RTP 107 stream 109 2. Requirements Notation 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in [RFC2119]. 115 3. Design Goals 117 The goal of this design is to provide a simple mechanism whereby 118 multiple identified extensions can be used in RTP packets, without 119 the need for formal registration of those extensions but nonetheless 120 avoiding collision. 122 This mechanism provides an alternative to the practice of burying 123 associated metadata into the media format bit stream. This has often 124 been done in media data sent over fixed-bandwidth channels. Once 125 this is done, a decoder for the specific media format needs to 126 extract the metadata. Also, depending on the media format, the 127 metadata can be added at the time of encoding the media so that the 128 bit-rate used for the metadata is taken into account. But the 129 metadata can be unknown at that time. Inserting metadata at a later 130 time can cause a decode and re-encode to meet bit-rate requirements. 132 In some cases, a more appropriate, higher-level mechanism can be 133 available, and if so, it can be used. For cases where a higher-level 134 mechanism is not available, it is better to provide a mechanism at 135 the RTP level than have the metadata be tied to a specific form of 136 media data. 138 4. Packet Design 140 4.1. General 142 The following design is fit into the "header extension" of the RTP 143 extension, as described above. 145 The presence and format of this header extension and its contents are 146 negotiated or defined out-of-band, such as through signaling (see 147 below for SDP signaling). The value defined for an RTP extension 148 (defined below for the one-byte and two-byte header forms) is only an 149 architectural constant (e.g., for use by network analyzers); it is 150 the negotiation/definition (e.g., in SDP) that is the definitive 151 indication that this header extension is present. 153 This specification updates the requirement from the RTP specification 154 that the header extension "is designed so that the header extension 155 MAY be ignored". To be specific, header extensions using this 156 specification SHOULD be used for data that can safely be ignored by 157 the recipient without affecting interoperability, there can be 158 essential header extensions for interoperability and intermediaries 159 SHOULD NOT remove such header extensions. Note that the support of 160 header extension as specified in this recommendation is negotiated. 161 RTP Header extensions MUST NOT be used when the presence of the 162 extension has changed the form or nature of the rest of the packet in 163 a way that is not compatible with the way the stream is signaled 164 (e.g., as defined by the payload type). Valid examples might include 165 metadata that is additional to the usual RTP information, e.g. Audio 166 level from Client to mixer [RFC6464]. 168 The RTP header extension is formed as a sequence of extension 169 elements, with possible padding. Each extension element has a local 170 identifier and a length. The local identifiers MAY be mapped to a 171 larger namespace in the negotiation (e.g., session signaling). 173 4.1.1. transmission considertions 175 As is good network practice, data SHOULD only be transmitted when 176 needed. The RTP header extension SHOULD only be present in a packet 177 if that packet also contains one or more extension elements, as 178 defined here. An extension element SHOULD only be present in a 179 packet when needed; the signaling setup of extension elements 180 indicates only that those elements can be present in some packets, 181 not that they are in fact present in all (or indeed, any) packets. 183 some general considerations for getting the header extensions 184 delivered to the receiver: 186 1. The probability for packet loss and burst loss determine how many 187 repetitions of the header extensions will be required to reach a 188 targeted delivery probability, and if burst loss is likely, what 189 distribution would be needed to avoid getting all repetitions of 190 the header extensions lost in a single burst. 192 2. If a set of packets are all needed to enable decoding, there is 193 commonly no reason for including the header extension in all of 194 these packets, as they share fate. Instead, at most one instance 195 of the header extension per independently decodable set of media 196 data would be a more efficient use of the bandwidth. 198 3. How early the Header Extension item information is needed, from 199 the first received RTP data or only after some set of packets are 200 received, can guide if the header extension(s) should be in all 201 of the first N packets or be included only once per set of 202 packets, for example once per video frame. 204 4. The use of RTP level robustness mechanisms, such as RTP 205 retransmission [RFC4588], or Forward Error Correction, e.g., 206 [RFC5109] may treat packets differently from a robustness 207 perspective, and header extensions should be added to packets 208 that get a treatment corresponding to the relative importance of 209 receiving the information. 211 As a summary, the number of header extension transmissions should be 212 tailored to a desired probability of delivery taking the receiver 213 population size into account. For the very basic case, N repetitions 214 of the header extensions should be sufficient, but may not be 215 optimal. N is selected so that the header extension target delivery 216 probability reaches 1-P^N, where P is the probability of packet loss. 217 For point to point or small receiver populations, it might also be 218 possible to use feedback, such as RTCP, to determine when the 219 information in the header extensions has reached all receivers and 220 stop further repetitions. Feedback that can be used includes the 221 RTCP XR Loss RLE report block [RFC3611], which will indicate 222 successful delivery of particular packets. If the RTP/AVPF Transport 223 Layer Feedback Messages for generic NACK [RFC4585] is used, it can 224 indicate the failure to deliver an RTP packet with the header 225 extension, thus indicating the need for further repetitions. The 226 normal RTCP report blocks can also provide an indicator of successful 227 delivery, if no losses are indicated for a reporting interval 228 covering the RTP packets with the header extension. Note that loss 229 of an RTCP packet reporting on an interval where RTP header extension 230 packets were sent, does not necessarily mean that the RTP header 231 extension packets themselves were lost. 233 4.1.2. Header Extension type consideration 235 Each extension element in a packet has a local identifier (ID) and a 236 length. The local identifiers present in the stream MUST have been 237 negotiated or defined out-of-band. There are no static allocations 238 of local identifiers. Each distinct extension MUST have a unique ID. 240 The value 0 is reserved for padding and MUST NOT be used as a local 241 identifier. 243 There are two variants of the extension: one-byte and two-byte 244 headers. Since it is expected that (a) the number of extensions in 245 any given RTP session is small and (b) the extensions themselves are 246 small, the one-byte header form is preferred and MUST be supported by 247 all receivers. A stream MUST contain only one-byte or two-byte 248 headers unless it is known that all recipients support mixing, either 249 by offer/answer negotiation (see section 6) or by out-of-band 250 knowledge. One-byte and two-byte headers MUST NOT be mixed in a 251 single RTP packet. Transmitters SHOULD NOT use the two-byte form 252 when all extensions are small enough for the one-byte header form. A 253 transmitter MAY be aware that an intermediary may add RTP header 254 extensions in this case, the transmitter SHOULD use two-byte form. 256 A sequence of extension elements, possibly with padding, forms the 257 header extension defined in the RTP specification. There are as many 258 extension elements as fit into the length as indicated in the RTP 259 header extension length. Since this length is signaled in full 260 32-bit words, padding bytes are used to pad to a 32-bit boundary. 261 The entire extension is parsed byte-by-byte to find each extension 262 element (no alignment is needed), and parsing stops at the earlier of 263 the end of the entire header extension, or in one-byte headers only 264 case, on encountering an identifier with the reserved value of 15. 266 In both forms, padding bytes have the value of 0 (zero). They MAY be 267 placed between extension elements, if desired for alignment, or after 268 the last extension element, if needed for padding. A padding byte 269 does not supply the ID of an element, nor the length field. When a 270 padding byte is found, it is ignored and the parser moves on to 271 interpreting the next byte. 273 Note carefully that the one-byte header form allows for data lengths 274 between 1 and 16 bytes, by adding 1 to the signaled length value 275 (thus, 0 in the length field indicates 1 byte of data follows). This 276 allows for the important case of 16-byte payloads. This addition is 277 not performed for the two-byte headers, where the length field 278 signals data lengths between 0 and 255 bytes. 280 Use of RTP header extensions will reduce the efficiency of RTP header 281 compression, since the header extension will be sent uncompressed 282 unless the RTP header compression module is updated to recognize the 283 extension header. If header extensions are present in some packets, 284 but not in others, this can also reduce compression efficiency by 285 requiring an update to the fixed header to be conveyed when header 286 extensions start or stop being sent. The interactions of the RTP 287 header extension and header compression is explored further in 288 [RFC2508] and [RFC3095]. 290 4.2. One-Byte Header 292 In the one-byte header form of extensions, the 16-bit value REQUIRED 293 by the RTP specification for a header extension, labeled in the RTP 294 specification as "defined by profile", MUST have the fixed bit 295 pattern 0xBEDE (the first version of this specification was written 296 on the feast day of the Venerable Bede). 298 Each extension element MUST starts with a byte containing an ID and a 299 length: 301 0 302 0 1 2 3 4 5 6 7 303 +-+-+-+-+-+-+-+-+ 304 | ID | len | 305 +-+-+-+-+-+-+-+-+ 307 The 4-bit ID is the local identifier of this element in the range 308 1-14 inclusive. In the signaling section, this is referred to as the 309 valid range. 311 The local identifier value 15 is reserved for future extension and 312 MUST NOT be used as an identifier. If the ID value 15 is 313 encountered, its length field MUST be ignored, processing of the 314 entire extension MUST terminate at that point, and only the extension 315 elements present prior to the element with ID 15 SHOULD be 316 considered. 318 The 4-bit length is the number minus one of data bytes of this header 319 extension element following the one-byte header. Therefore, the 320 value zero in this field indicates that one byte of data follows, and 321 a value of 15 (the maximum) indicates element data of 16 bytes. 322 (This permits carriage of 16-byte values, which is a common length of 323 labels and identifiers, while losing the possibility of zero-length 324 values -- which would often be padded anyway.) 325 An example header extension, with three extension elements, and some 326 padding follows: 328 0 1 2 3 329 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 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 | 0xBE | 0xDE | length=3 | 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 | ID | L=0 | data | ID | L=1 | data... 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 ...data | 0 (pad) | 0 (pad) | ID | L=3 | 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 | data | 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 4.3. Two-Byte Header 342 In the two-byte header form, the 16-bit value defined by the RTP 343 specification for a header extension, labeled in the RTP 344 specification as "defined by profile", is defined as shown below. 346 0 1 347 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 | 0x100 |appbits| 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 The appbits field is 4 bits that are application-dependent and MAY be 353 defined to be any value or meaning, and are outside the scope of this 354 specification. For the purposes of signaling, this field is treated 355 as a special extension value assigned to the local identifier 256. 356 If no extension has been specified through configuration or signaling 357 for this local identifier value 256, the appbits field SHOULD be set 358 to all 0s by the sender and MUST be ignored by the receiver. 360 Each extension element starts with a byte containing an ID and a byte 361 containing a length: 363 0 1 364 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 | ID | length | 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 The 8-bit ID is the local identifier of this element in the range 370 1-255 inclusive. In the signaling section, the range 1-256 is 371 referred to as the valid range, with the values 1-255 referring to 372 extension elements, and the value 256 referring to the 4-bit field 373 'appbits' (above). 375 The 8-bit length field is the length of extension data in bytes not 376 including the ID and length fields. The value zero indicates there 377 is no data following. 379 An example header extension, with three extension elements, and some 380 padding follows: 382 0 1 2 3 383 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 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 | 0x10 | 0x00 | length=3 | 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 | ID | L=0 | ID | L=1 | 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 | data | 0 (pad) | ID | L=4 | 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 | data | 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 5. SDP Signaling Design 396 The indication of the presence of this extension, and the mapping of 397 local identifiers used in the header extension to a larger namespace, 398 MUST be performed out-of-band, for example, as part of a SIP offer/ 399 answer exchange using SDP. This section defines such signaling in 400 SDP. 402 A usable mapping MUST use IDs in the valid range, and each ID in this 403 range MUST be used only once for each media (or only once if the 404 mappings are session level). Mappings that do not conform to these 405 rules MAY be presented, for instance, during offer/answer negotiation 406 as described in the next section, but remapping to conformant values 407 is necessary before they can be applied. 409 Each extension is named by a URI. That URI MUST be absolute, and 410 precisely identifies the format and meaning of the extension. URIs 411 that contain a domain name SHOULD also contain a month-date in the 412 form mmyyyy. The definition of the element and assignment of the URI 413 MUST have been authorized by the owner of the domain name on or very 414 close to that date. (This avoids problems when domain names change 415 ownership.) If the resource or document defines several extensions, 416 then the URI MUST identify the actual extension in use, e.g., using a 417 fragment or query identifier (characters after a '#' or '?' in the 418 URI). 420 Rationale: the use of URIs provides for a large, unallocated space, 421 and gives documentation on the extension. The URIs do not have to be 422 de-referencable, in order to permit confidential or experimental use, 423 and to cover the case when extensions continue to be used after the 424 organization that defined them ceases to exist. 426 An extension URI with the same attributes MUST NOT appear more than 427 once applying to the same stream, i.e., at session level or in the 428 declarations for a single stream at media level. (The same extension 429 can, of course, be used for several streams, and can appear 430 differently parameterized for the same stream.) 432 For extensions defined in RFCs, the URI used SHOULD be a URN starting 433 "urn:ietf:params:rtp-hdrext:" and followed by a registered, 434 descriptive name. 436 The registration requirements are detailed in the IANA Considerations 437 section, below. 439 An example (this is only an example), where 'avt-example-metadata' is 440 the hypothetical name of a header extension, might be: 442 urn:ietf:params:rtp-hdrext:avt-example-metadata 444 An example name not from the IETF (this is only an example) might be: 446 http://example.com/082005/ext.htm#example-metadata 448 The mapping MAY be provided per media stream (in the media-level 449 section(s) of SDP, i.e., after an "m=" line) or globally for all 450 streams (i.e., before the first "m=" line, at session level). The 451 definitions MUST be either all session level or all media level; it 452 is not permitted to mix the two styles. In addition, as noted above, 453 the IDs used MUST be unique for each stream type for a given media, 454 or for the session for session-level declarations. 456 Each local identifier potentially used in the stream is mapped to a 457 string using an attribute of the form: 459 a=extmap:["/"] 461 where is a URI, as above, is the local identifier (ID) 462 of this extension and is an integer in the valid range inclusive (0 463 is reserved for padding in both forms, and 15 is reserved in the one- 464 byte header form, as noted above), and is one of 465 "sendonly", "recvonly", "sendrecv", or "inactive" (without the 466 quotes). 468 The formal BNF syntax is presented in a later section of this 469 specification. 471 Example: 473 a=extmap:1 http://example.com/082005/ext.htm#ttime 475 a=extmap:2/sendrecv http://example.com/082005/ext.htm#xmeta short 477 When SDP signaling is used for the RTP session, it is the presence of 478 the 'extmap' attribute(s) that is diagnostic that this style of 479 header extensions is used, not the magic number indicated above. 481 6. SDP Signaling for support of mixed one byte and two bytes header 482 extensions. 484 In order to allow for backward interoperability with systems that do 485 not support mixing of one byte and two bytes header extensions this 486 document defines the "a=extmap-allow-mixed" Session Description 487 Protocol (SDP) [RFC4566] attribute to indicate if the participant is 488 capable of supporting this new mode. The attribute takes no value. 489 This attribute can be used at the session or media levels. A 490 participant that proposes the use of this mode SHALL itself support 491 the reception of mixed one byte and two bytes header extensions. 493 The negotiation for mixed one byte and two bytes extension MUST be 494 negotiated in offer/answer [RFC3264]. In the absence of negotiation 495 using offer/answer, mixed headers MUST NOT occur unless the 496 transmitter has some (out of band) knowledge that all potential 497 recipients support this mode. 499 The formal definition of this attribute is: 501 Name: extmap-allow-mixed 503 Value: 505 Usage Level: session, media 507 Charset Dependent: no 509 Example: 511 a=extmap-allow-mixed 513 When doing SDP Offer/Answer [RFC3264] an offering client that wishes 514 to use both one and two bytes extensions MUST include the attribute 515 "a= extmap-allow-mixed " in the SDP offer. If "a= extmap-allow-mixed 516 " is present in the offer SDP, the answerer that supports this mode 517 and wishes to use it SHALL include the "a=extmap-allow-mixed " 518 attribute in the answer. In cases the answer has been excluded, 519 neither clients SHALL use mixed one bytes and two bytes extensions in 520 the same RTP stream. 522 7. Offer/Answer 524 The simple signaling described above MAY be enhanced in an offer/ 525 answer context, to permit: 527 o asymmetric behavior (extensions sent in only one direction), 529 o the offer of mutually exclusive alternatives, or 531 o the offer of more extensions than can be sent in a single session. 533 A direction attribute MAY be included in an extmap; without it, the 534 direction implicitly inherits, of course, from the stream direction, 535 or is "sendrecv" for session-level attributes or extensions of 536 "inactive" streams. The direction MUST be one of "sendonly", 537 "recvonly", "sendrecv", or "inactive". A "sendonly" direction 538 indicates an ability to send; a "recvonly" direction indicates a 539 desire to receive; a "sendrecv" direction indicates both. An 540 "inactive" direction indicates neither, but later re-negotiation MAY 541 make an extension active. 543 Extensions, with their directions, MAY be signaled for an "inactive" 544 stream. It is an error to use an extension direction incompatible 545 with the stream direction (e.g., a "sendonly" attribute for a 546 "recvonly" stream). 548 If an offer or answer contains session-level mappings (and hence no 549 media-level mappings), and different behavior is desired for each 550 stream, then the entire set of extension map declarations MAY be 551 moved into the media-level section(s) of the SDP. (Note that this 552 specification does not permit mixing global and local declarations, 553 to make identifier management easier.) 555 If an extension map is offered as "sendrecv", explicitly or 556 implicitly, and asymmetric behavior is desired, the SDP MAY be 557 modified to modify or add direction qualifiers for that extension. 559 If an extension is marked as "sendonly" and the answerer desires to 560 receive it, the extension MUST be marked as "recvonly" in the SDP 561 answer. An answerer that has no desire to receive the extension or 562 does not understand the extension SHOULD remove it from the SDP 563 answer. 565 If an extension is marked as "recvonly" and the answerer desires to 566 send it, the extension MUST be marked as "sendonly" in the SDP 567 answer. An answerer that has no desire to, or is unable to, send the 568 extension SHOULD remove it from the SDP answer. 570 Local identifiers in the valid range inclusive in an offer or answer 571 MUST NOT be used more than once per media section (including the 572 session-level section). A session update MAY change the direction 573 qualifiers of extensions under use. A session update MAY add or 574 remove extension(s). Identifiers values in the valid range MUST NOT 575 be altered (remapped). 577 Note that, under this rule, the same local identifier cannot be used 578 for two extensions for the same media, even when one is "sendonly" 579 and the other "recvonly", as it would then be impossible to make 580 either of them sendrecv (since re-numbering is not permitted either). 582 If a party wishes to offer mutually exclusive alternatives, then 583 multiple extensions with the same identifier in the (unusable) range 584 4096-4351 MAY be offered; the answerer SHOULD select at most one of 585 the offered extensions with the same identifier, and remap it to a 586 free identifier in the valid range, for that extension to be usable. 588 Similarly, if more extensions are offered than can be fit in the 589 valid range, identifiers in the range 4096-4351 MAY be offered; the 590 answerer SHOULD choose those that are desired, and remap them to a 591 free identifier in the valid range. 593 It is always allowed to place the offered identifier value "as is" in 594 the SDP answer (for example, due to lack of a free identifier value 595 in the valid range). Extensions with an identifier outside the valid 596 range MUST NOT, of course, be used. If needed, the offerer or 597 answerer can update the session to make space for such an extension. 599 Rationale: the range 4096-4351 for these negotiation identifiers is 600 deliberately restricted to allow expansion of the range of valid 601 identifiers in future. 603 Either party MAY include extensions in the stream other than those 604 negotiated, or those negotiated as "inactive", for example, for the 605 benefit of intermediate nodes. Only extensions that appeared with an 606 identifier in the valid range in SDP originated by the sender can be 607 sent. 609 Example (port numbers, RTP profiles, payload IDs and rtpmaps, etc. 610 all omitted for brevity): 612 The offer: 614 a=extmap:1 URI-toffset 615 a=extmap:14 URI-obscure 616 a=extmap:4096 URI-gps-string 617 a=extmap:4096 URI-gps-binary 618 a=extmap:4097 URI-frametype 619 m=video 620 a=sendrecv 621 m=audio 622 a=sendrecv 624 The answerer is interested in receiving GPS in string format only on 625 video, but cannot send GPS at all. It is not interested in 626 transmission offsets on audio, and does not understand the URI- 627 obscure extension. It therefore moves the extensions from session 628 level to media level, and adjusts the declarations: 630 m=video 631 a=sendrecv 632 a=extmap:1 URI-toffset 633 a=extmap:2/recvonly URI-gps-string 634 a=extmap:3 URI-frametype 635 m=audio 636 a=sendrecv 637 a=extmap:1/sendonly URI-toffset 639 8. BNF Syntax 641 The syntax definition below uses ABNF according to [RFC5234]. The 642 syntax element 'URI' is defined in [RFC3986] (only absolute URIs are 643 permitted here). The syntax element 'extmap' is an attribute as 644 defined in [RFC4566], i.e., "a=" precedes the extmap definition. 645 Specific extensionattributes are defined by the specification that 646 defines a specific extension name; there can be several. 648 extmap = mapentry SP extensionname [SP extensionattributes] 650 extensionname = URI 652 direction = "sendonly" / "recvonly" / "sendrecv" / "inactive" 654 mapentry = "extmap:" 1*5DIGIT ["/" direction] 656 extensionattributes = byte-string 658 URI = 660 byte-string = 662 SP = 664 DIGIT = 666 9. Security Considerations 668 This document defines only a place to transmit information; the 669 security implications of each of the extensions MUST be discussed 670 with those extensions. 672 Header extensions have the same security coverage as the RTP header 673 itself. When Secure Real-time Transport Protocol (SRTP) [RFC3711] is 674 used to protect RTP sessions, the RTP payload can be both encrypted 675 and integrity protected, while the RTP header is either unprotected 676 or integrity protected. RTP header extensions can carry sensitive 677 information for which participants in multimedia sessions want 678 confidentiality. RFC6904 [RFC6904] provides a mechanism, extending 679 the mechanisms of SRTP, to selectively encrypt RTP header extensions 680 in SRTP. 682 10. IANA Considerations 684 This document updates the IANA consideration to reference this 685 document and adds a new SDP attribute in section 10.3 687 Note to IANA : change RFCxxxx to this RFC number and remove the note. 689 10.1. Identifier Space for IANA to Manage 691 The mapping from the naming URI form to a reference to a 692 specification is managed by IANA. Insertion into this registry is 693 under the requirements of "Expert Review" as defined in [RFC5226]. 695 The IANA will also maintain a server that contains all of the 696 registered elements in a publicly accessible space. 698 Here is the formal declaration to comply with the IETF URN Sub- 699 namespace specification [RFC3553]. 701 o Registry name: RTP Compact Header Extensions 703 o Specification: RFC 5285 and RFCs updating RFC 5285. 705 o Information required: 707 A. The desired extension naming URI 709 B. A formal reference to the publicly available specification 711 C. A short phrase describing the function of the extension 713 D. Contact information for the organization or person making the 714 registration 716 For extensions defined in RFCs, the URI SHOULD be of the form 717 urn:ietf:params:rtp-hdrext:, and the formal reference is the RFC 718 number of the RFC documenting the extension. 720 o Review process: Expert review is REQUIRED. The expert review 721 SHOULD check the following requirements: 723 1. that the specification is publicly available; 725 2. that the extension complies with the requirements of RTP and 726 this specification, for extensions (notably, that the stream 727 is still decodable if the extension is ignored or not 728 recognized); 730 3. that the extension specification is technically consistent (in 731 itself and with RTP), complete, and comprehensible; 733 4. that the extension does not duplicate functionality in 734 existing IETF specifications (including RTP itself), or other 735 extensions already registered; 737 5. that the specification contains a security analysis regarding 738 the content of the header extension; 740 6. that the extension is generally applicable, for example point- 741 to-multipoint safe, and the specification correctly describes 742 limitations if they exist; and 744 7. that the suggested naming URI form is appropriately chosen and 745 unique. 747 o Size and format of entries: a mapping from a naming URI string to 748 a formal reference to a publicly available specification, with a 749 descriptive phrase and contact information. 751 o Initial assignments: none. 753 10.2. Registration of the SDP extmap Attribute 755 This section contains the information requested by [RFC4566] for an 756 SDP attribute. 758 o contact name, email address, and telephone number: 760 D. Singer 761 singer@apple.com 762 +1 408-974-3162 764 o attribute name (as it will appear in SDP): extmap 766 o long-form attribute name in English: generic header extension map 767 definition 769 o type of attribute (session level, media level, or both): both 771 o whether the attribute value is subject to the charset attribute: 772 not subject to the charset attribute 774 o a one-paragraph explanation of the purpose of the attribute: This 775 attribute defines the mapping from the extension numbers used in 776 packet headers into extension names as documented in 777 specifications and appropriately registered. 779 o a specification of appropriate attribute values for this 780 attribute: see RFC 5285. 782 10.3. Registration of the SDP Attribute 784 The IANA is requested to register one new SDP attribute: 786 SDP Attribute ("att-field"): 787 Attribute name: extmap-allow-mixed 788 Long form: One and Two bytes mixed mode 789 Type of name: att-field 790 Type of attribute: Media or session level 791 Subject to charset: No 792 Purpose: Negotiate the use of One and Two bytes 793 in the same RTP stream. 794 Reference: [RFCXXXX] 795 Values: None 797 11. Acknowledgments 799 Both Brian Link and John Lazzaro provided helpful comments on an 800 initial draft of this document. Colin Perkins was helpful in 801 reviewing and dealing with the details. The use of URNs for IETF- 802 defined extensions was suggested by Jonathan Lennox, and Pete Cordell 803 was instrumental in improving the padding wording. Dave Oran 804 provided feedback and text in the review. Mike Dolan contributed the 805 two-byte header form. Magnus Westerlund and Tom Taylor were 806 instrumental in managing the registration text. 808 12. References 810 12.1. Normative References 812 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 813 Requirement Levels", BCP 14, RFC 2119, 814 DOI 10.17487/RFC2119, March 1997, 815 . 817 [RFC2508] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP 818 Headers for Low-Speed Serial Links", RFC 2508, February 819 1999. 821 [RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., 822 Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, 823 K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., 824 Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header 825 Compression (ROHC): Framework and four profiles: RTP, UDP, 826 ESP, and uncompressed", RFC 3095, July 2001. 828 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 829 Jacobson, "RTP: A Transport Protocol for Real-Time 830 Applications", STD 64, RFC 3550, July 2003. 832 [RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An 833 IETF URN Sub-namespace for Registered Protocol 834 Parameters", BCP 73, RFC 3553, June 2003. 836 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 837 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 838 RFC 3711, March 2004. 840 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 841 Resource Identifier (URI): Generic Syntax", STD 66, 842 RFC 3986, January 2005. 844 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 845 Description Protocol", RFC 4566, July 2006. 847 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 848 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 849 May 2008. 851 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 852 Specifications: ABNF", STD 68, RFC 5234, January 2008. 854 [RFC6904] Lennox, J., "Encryption of Header Extensions in the Secure 855 Real-time Transport Protocol (SRTP)", RFC 6904, 856 DOI 10.17487/RFC6904, April 2013, 857 . 859 12.2. Informative References 861 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 862 with Session Description Protocol (SDP)", RFC 3264, June 863 2002. 865 [RFC6464] Lennox, J., Ed., Ivov, E., and E. Marocco, "A Real-time 866 Transport Protocol (RTP) Header Extension for Client-to- 867 Mixer Audio Level Indication", RFC 6464, 868 DOI 10.17487/RFC6464, December 2011, 869 . 871 Authors' Addresses 873 Roni Even (editor) 874 Huawei Technologies 875 Shabazi 12A 876 Tel Aviv 877 Israel 879 Email: Roni.even@mail01.huawei.com 880 David Singer 881 Apple, Inc. 882 1 Infinite Loop 883 Cupertino, CA 95014 884 USA 886 Phone: +1 408 996 1010 887 Email: singer@apple.com 888 URI: http://www.apple.com/quicktime 890 Harikishan Desineni 891 10001 Pacific Heights Blvd 892 San Diego, CA 92121 893 USA 895 Phone: +1 858 845 8996 896 Email: hdesinen@quicinc.com