idnits 2.17.1 draft-ietf-avtcore-rfc5285-bis-01.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 (December 23, 2015) is 3046 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 739, 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 (~~), 3 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: June 25, 2016 H. Desineni 7 December 23, 2015 9 A General Mechanism for RTP Header Extensions 10 draft-ietf-avtcore-rfc5285-bis-01.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 June 25, 2016. 38 Copyright Notice 40 Copyright (c) 2015 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.2. One-Byte Header . . . . . . . . . . . . . . . . . . . . . 5 61 4.3. Two-Byte Header . . . . . . . . . . . . . . . . . . . . . 7 62 5. SDP Signaling Design . . . . . . . . . . . . . . . . . . . . 8 63 6. SDP Signaling for support of mixed one byte and two bytes 64 header extensions. . . . . . . . . . . . . . . . . . . . . . 10 65 7. Offer/Answer . . . . . . . . . . . . . . . . . . . . . . . . 11 66 8. BNF Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 13 67 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 68 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 69 10.1. Identifier Space for IANA to Manage . . . . . . . . . . 14 70 10.2. Registration of the SDP extmap Attribute . . . . . . . . 16 71 10.3. Registration of the SDP Attribute . . . . . . . . . . . 16 72 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 73 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 74 12.1. Normative References . . . . . . . . . . . . . . . . . . 17 75 12.2. Informative References . . . . . . . . . . . . . . . . . 18 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 78 1. Introduction 80 The RTP specification [RFC3550] provides a capability to extend the 81 RTP header. It defines the header extension format and rules for its 82 use in Section 5.3.1. The existing header extension method permits 83 at most one extension per RTP packet, identified by a 16-bit 84 identifier and a 16-bit length field specifying the length of the 85 header extension in 32-bit words. 87 This mechanism has two conspicuous drawbacks. First, it permits only 88 one header extension in a single RTP packet. Second, the 89 specification gives no guidance as to how the 16-bit header extension 90 identifiers are allocated to avoid collisions. 92 This specification removes the first drawback by defining a backward- 93 compatible and extensible means to carry multiple header extension 94 elements in a single RTP packet. It removes the second drawback by 95 defining that these extension elements are named by URIs, defining an 96 IANA registry for extension elements defined in IETF specifications, 97 and a Session Description Protocol (SDP) method for mapping between 98 the naming URIs and the identifier values carried in the RTP packets. 100 This header extension applies to RTP/AVP (the Audio/Visual Profile) 101 and its extensions. 103 This document removes a limitation from RFC5285 that did not allow 104 sending both one byte and two bytes header extensions in the same RTP 105 stream 107 2. Requirements Notation 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in [RFC2119]. 113 3. Design Goals 115 The goal of this design is to provide a simple mechanism whereby 116 multiple identified extensions can be used in RTP packets, without 117 the need for formal registration of those extensions but nonetheless 118 avoiding collision. 120 This mechanism provides an alternative to the practice of burying 121 associated metadata into the media format bit stream. This has often 122 been done in media data sent over fixed-bandwidth channels. Once 123 this is done, a decoder for the specific media format is required to 124 extract the metadata. Also, depending on the media format, the 125 metadata may need to be added at the time of encoding the media so 126 that the bit-rate required for the metadata is taken into account. 127 But the metadata may not be known at that time. Inserting metadata 128 at a later time can require a decode and re-encode to meet bit-rate 129 requirements. 131 In some cases, a more appropriate, higher-level mechanism may be 132 available, and if so, it should be used. For cases where a higher- 133 level mechanism is not available, it is better to provide a mechanism 134 at the RTP level than have the metadata be tied to a specific form of 135 media data. 137 4. Packet Design 139 4.1. General 141 The following design is fit into the "header extension" of the RTP 142 extension, as described above. 144 The presence and format of this header extension and its contents are 145 negotiated or defined out-of-band, such as through signaling (see 146 below for SDP signaling). The value defined for an RTP extension 147 (defined below for the one-byte and two-byte header forms) is only an 148 architectural constant (e.g., for use by network analyzers); it is 149 the negotiation/definition (e.g., in SDP) that is the definitive 150 indication that this header extension is present. 152 This specification updates the requirement from the RTP specification 153 that the header extension "is designed so that the header extension 154 may be ignored". To be specific, header extensions using this 155 specification SHOULD be used for data that can safely be ignored by 156 the recipient without affecting interoperability, there may be 157 essential header extensions for interoperability and intermediaries 158 should not remove such header extensions. Note that the support of 159 header extension as specified in this recommendation is negotiated. 160 RTP Header extensions MUST NOT be used when the presence of the 161 extension has changed the form or nature of the rest of the packet in 162 a way that is not compatible with the way the stream is signaled 163 (e.g., as defined by the payload type). Valid examples might include 164 metadata that is additional to the usual RTP information, e.g. Audio 165 level from Client to mixer [RFC6464]. 167 The RTP header extension is formed as a sequence of extension 168 elements, with possible padding. Each extension element has a local 169 identifier and a length. The local identifiers may be mapped to a 170 larger namespace in the negotiation (e.g., session signaling). 172 As is good network practice, data should only be transmitted when 173 needed. The RTP header extension should only be present in a packet 174 if that packet also contains one or more extension elements, as 175 defined here. An extension element should only be present in a 176 packet when needed; the signaling setup of extension elements 177 indicates only that those elements may be present in some packets, 178 not that they are in fact present in all (or indeed, any) packets. 180 Each extension element in a packet has a local identifier (ID) and a 181 length. The local identifiers present in the stream MUST have been 182 negotiated or defined out-of-band. There are no static allocations 183 of local identifiers. Each distinct extension MUST have a unique ID. 184 The value 0 is reserved for padding and MUST NOT be used as a local 185 identifier. 187 There are two variants of the extension: one-byte and two-byte 188 headers. Since it is expected that (a) the number of extensions in 189 any given RTP session is small and (b) the extensions themselves are 190 small, the one-byte header form is preferred and MUST be supported by 191 all receivers. A stream MUST contain only one-byte or two-byte 192 headers unless it is known that all recipients support mixing, either 193 by offer/answer negotiation (see section 6) or by out-of-band 194 knowledge. One-byte and two-byte headers MUST NOT be mixed in a 195 single RTP packet. Transmitters SHOULD NOT use the two-byte form 196 when all extensions are small enough for the one-byte header form. A 197 transmitter may be aware that an intermediary may add RTP header 198 extensions in this case, the transmitter SHOULD use two-byte form. 200 A sequence of extension elements, possibly with padding, forms the 201 header extension defined in the RTP specification. There are as many 202 extension elements as fit into the length as indicated in the RTP 203 header extension length. Since this length is signaled in full 204 32-bit words, padding bytes are used to pad to a 32-bit boundary. 205 The entire extension is parsed byte-by-byte to find each extension 206 element (no alignment is required), and parsing stops at the earlier 207 of the end of the entire header extension, or in one-byte headers 208 only case, on encountering an identifier with the reserved value of 209 15. 211 In both forms, padding bytes have the value of 0 (zero). They may be 212 placed between extension elements, if desired for alignment, or after 213 the last extension element, if needed for padding. A padding byte 214 does not supply the ID of an element, nor the length field. When a 215 padding byte is found, it is ignored and the parser moves on to 216 interpreting the next byte. 218 Note carefully that the one-byte header form allows for data lengths 219 between 1 and 16 bytes, by adding 1 to the signaled length value 220 (thus, 0 in the length field indicates 1 byte of data follows). This 221 allows for the important case of 16-byte payloads. This addition is 222 not performed for the two-byte headers, where the length field 223 signals data lengths between 0 and 255 bytes. 225 Use of RTP header extensions will reduce the efficiency of RTP header 226 compression, since the header extension will be sent uncompressed 227 unless the RTP header compression module is updated to recognize the 228 extension header. If header extensions are present in some packets, 229 but not in others, this can also reduce compression efficiency by 230 requiring an update to the fixed header to be conveyed when header 231 extensions start or stop being sent. The interactions of the RTP 232 header extension and header compression is explored further in 233 [RFC2508] and [RFC3095]. 235 4.2. One-Byte Header 237 In the one-byte header form of extensions, the 16-bit value required 238 by the RTP specification for a header extension, labeled in the RTP 239 specification as "defined by profile", takes the fixed bit pattern 240 0xBEDE (the first version of this specification was written on the 241 feast day of the Venerable Bede). 243 Each extension element starts with a byte containing an ID and a 244 length: 246 0 247 0 1 2 3 4 5 6 7 248 +-+-+-+-+-+-+-+-+ 249 | ID | len | 250 +-+-+-+-+-+-+-+-+ 252 The 4-bit ID is the local identifier of this element in the range 253 1-14 inclusive. In the signaling section, this is referred to as the 254 valid range. 256 The local identifier value 15 is reserved for future extension and 257 MUST NOT be used as an identifier. If the ID value 15 is 258 encountered, its length field should be ignored, processing of the 259 entire extension should terminate at that point, and only the 260 extension elements present prior to the element with ID 15 261 considered. 263 The 4-bit length is the number minus one of data bytes of this header 264 extension element following the one-byte header. Therefore, the 265 value zero in this field indicates that one byte of data follows, and 266 a value of 15 (the maximum) indicates element data of 16 bytes. 267 (This permits carriage of 16-byte values, which is a common length of 268 labels and identifiers, while losing the possibility of zero-length 269 values -- which would often be padded anyway.) 271 An example header extension, with three extension elements, some 272 padding, and including the required RTP fields, follows: 274 0 1 2 3 275 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 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 | 0xBE | 0xDE | length=3 | 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 | ID | L=0 | data | ID | L=1 | data... 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 ...data | 0 (pad) | 0 (pad) | ID | L=3 | 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 | data | 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 4.3. Two-Byte Header 288 In the two-byte header form, the 16-bit value required by the RTP 289 specification for a header extension, labeled in the RTP 290 specification as "defined by profile", is defined as shown below. 292 0 1 293 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | 0x100 |appbits| 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 The appbits field is 4 bits that are application-dependent and may be 299 defined to be any value or meaning, and are outside the scope of this 300 specification. For the purposes of signaling, this field is treated 301 as a special extension value assigned to the local identifier 256. 302 If no extension has been specified through configuration or signaling 303 for this local identifier value 256, the appbits field SHOULD be set 304 to all 0s by the sender and MUST be ignored by the receiver. 306 Each extension element starts with a byte containing an ID and a byte 307 containing a length: 309 0 1 310 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 | ID | length | 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 The 8-bit ID is the local identifier of this element in the range 316 1-255 inclusive. In the signaling section, the range 1-256 is 317 referred to as the valid range, with the values 1-255 referring to 318 extension elements, and the value 256 referring to the 4-bit field 319 'appbits' (above). 321 The 8-bit length field is the length of extension data in bytes not 322 including the ID and length fields. The value zero indicates there 323 is no data following. 325 An example header extension, with three extension elements, some 326 padding, and including the required RTP fields, 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 | 0x10 | 0x00 | length=3 | 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 | ID | L=0 | ID | L=1 | 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 | data | 0 (pad) | ID | L=4 | 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 | data | 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 5. SDP Signaling Design 342 The indication of the presence of this extension, and the mapping of 343 local identifiers used in the header extension to a larger namespace, 344 MUST be performed out-of-band, for example, as part of a SIP offer/ 345 answer exchange using SDP. This section defines such signaling in 346 SDP. 348 A usable mapping MUST use IDs in the valid range, and each ID in this 349 range MUST be used only once for each media (or only once if the 350 mappings are session level). Mappings that do not conform to these 351 rules MAY be presented, for instance, during offer/answer negotiation 352 as described in the next section, but remapping to conformant values 353 is necessary before they can be applied. 355 Each extension is named by a URI. That URI MUST be absolute, and 356 precisely identifies the format and meaning of the extension. URIs 357 that contain a domain name SHOULD also contain a month-date in the 358 form mmyyyy. The definition of the element and assignment of the URI 359 MUST have been authorized by the owner of the domain name on or very 360 close to that date. (This avoids problems when domain names change 361 ownership.) If the resource or document defines several extensions, 362 then the URI MUST identify the actual extension in use, e.g., using a 363 fragment or query identifier (characters after a '#' or '?' in the 364 URI). 366 Rationale: the use of URIs provides for a large, unallocated space, 367 and gives documentation on the extension. The URIs are not required 368 to be de-referencable, in order to permit confidential or 369 experimental use, and to cover the case when extensions continue to 370 be used after the organization that defined them ceases to exist. 372 An extension URI with the same attributes MUST NOT appear more than 373 once applying to the same stream, i.e., at session level or in the 374 declarations for a single stream at media level. (The same extension 375 may, of course, be used for several streams, and may appear 376 differently parameterized for the same stream.) 378 For extensions defined in RFCs, the URI used SHOULD be a URN starting 379 "urn:ietf:params:rtp-hdrext:" and followed by a registered, 380 descriptive name. 382 The registration requirements are detailed in the IANA Considerations 383 section, below. 385 An example (this is only an example), where 'avt-example-metadata' is 386 the hypothetical name of a header extension, might be: 388 urn:ietf:params:rtp-hdrext:avt-example-metadata 390 An example name not from the IETF (this is only an example) might be: 392 http://example.com/082005/ext.htm#example-metadata 394 The mapping may be provided per media stream (in the media-level 395 section(s) of SDP, i.e., after an "m=" line) or globally for all 396 streams (i.e., before the first "m=" line, at session level). The 397 definitions MUST be either all session level or all media level; it 398 is not permitted to mix the two styles. In addition, as noted above, 399 the IDs used MUST be unique for each stream type for a given media, 400 or for the session for session-level declarations. 402 Each local identifier potentially used in the stream is mapped to a 403 string using an attribute of the form: 405 a=extmap:["/"] 407 where is a URI, as above, is the local identifier (ID) 408 of this extension and is an integer in the valid range inclusive (0 409 is reserved for padding in both forms, and 15 is reserved in the one- 410 byte header form, as noted above), and is one of 411 "sendonly", "recvonly", "sendrecv", or "inactive" (without the 412 quotes). 414 The formal BNF syntax is presented in a later section of this 415 specification. 417 Example: 419 a=extmap:1 http://example.com/082005/ext.htm#ttime 420 a=extmap:2/sendrecv http://example.com/082005/ext.htm#xmeta short 422 When SDP signaling is used for the RTP session, it is the presence of 423 the 'extmap' attribute(s) that is diagnostic that this style of 424 header extensions is used, not the magic number indicated above. 426 6. SDP Signaling for support of mixed one byte and two bytes header 427 extensions. 429 In order to allow for backward interoperability with systems that do 430 not support mixing of one byte and two bytes header extensions this 431 document defines the "a=extmap-allow-mixed" Session Description 432 Protocol (SDP) [RFC4566] attribute to indicate if the participant is 433 capable of supporting this new mode. The attribute takes no value. 434 This attribute can be used at the session or media levels. A 435 participant that proposes the use of this mode SHALL itself support 436 the reception of mixed one byte and two bytes header extensions. 438 The negotiation for mixed one byte and two bytes extension MUST be 439 negotiated in offer/answer [RFC3264]. In the absence of negotiation 440 using offer/answer, mixed headers MUST NOT occur unless the 441 transmitter has some (out of band) knowledge that all potential 442 recipients support this mode. 444 The formal definition of this attribute is: 446 Name: extmap-allow-mixed 448 Value: 450 Usage Level: session, media 452 Charset Dependent: no 454 Example: 456 a=extmap-allow-mixed 458 When doing SDP Offer/Answer [RFC3264] an offering client that wishes 459 to use both one and two bytes extensions MUST include the attribute 460 "a= extmap-allow-mixed " in the SDP offer. If "a= extmap-allow-mixed 461 " is present in the offer SDP, the answerer that supports this mode 462 and wishes to use it SHALL include the "a=extmap-allow-mixed " 463 attribute in the answer. In cases the answer has been excluded, 464 neither clients SHALL use mixed one bytes and two bytes extensions in 465 the same RTP stream. 467 7. Offer/Answer 469 The simple signaling described above may be enhanced in an offer/ 470 answer context, to permit: 472 o asymmetric behavior (extensions sent in only one direction), 474 o the offer of mutually exclusive alternatives, or 476 o the offer of more extensions than can be sent in a single session. 478 A direction attribute MAY be included in an extmap; without it, the 479 direction implicitly inherits, of course, from the stream direction, 480 or is "sendrecv" for session-level attributes or extensions of 481 "inactive" streams. The direction MUST be one of "sendonly", 482 "recvonly", "sendrecv", or "inactive". A "sendonly" direction 483 indicates an ability to send; a "recvonly" direction indicates a 484 desire to receive; a "sendrecv" direction indicates both. An 485 "inactive" direction indicates neither, but later re-negotiation may 486 make an extension active. 488 Extensions, with their directions, may be signaled for an "inactive" 489 stream. It is an error to use an extension direction incompatible 490 with the stream direction (e.g., a "sendonly" attribute for a 491 "recvonly" stream). 493 If an offer or answer contains session-level mappings (and hence no 494 media-level mappings), and different behavior is desired for each 495 stream, then the entire set of extension map declarations may be 496 moved into the media-level section(s) of the SDP. (Note that this 497 specification does not permit mixing global and local declarations, 498 to make identifier management easier.) 500 If an extension map is offered as "sendrecv", explicitly or 501 implicitly, and asymmetric behavior is desired, the SDP may be 502 modified to modify or add direction qualifiers for that extension. 504 If an extension is marked as "sendonly" and the answerer desires to 505 receive it, the extension MUST be marked as "recvonly" in the SDP 506 answer. An answerer that has no desire to receive the extension or 507 does not understand the extension SHOULD remove it from the SDP 508 answer. 510 If an extension is marked as "recvonly" and the answerer desires to 511 send it, the extension MUST be marked as "sendonly" in the SDP 512 answer. An answerer that has no desire to, or is unable to, send the 513 extension SHOULD remove it from the SDP answer. 515 Local identifiers in the valid range inclusive in an offer or answer 516 must not be used more than once per media section (including the 517 session-level section). A session update MAY change the direction 518 qualifiers of extensions under use. A session update MAY add or 519 remove extension(s). Identifiers values in the valid range MUST NOT 520 be altered (remapped). 522 Note that, under this rule, the same local identifier cannot be used 523 for two extensions for the same media, even when one is "sendonly" 524 and the other "recvonly", as it would then be impossible to make 525 either of them sendrecv (since re-numbering is not permitted either). 527 If a party wishes to offer mutually exclusive alternatives, then 528 multiple extensions with the same identifier in the (unusable) range 529 4096-4351 may be offered; the answerer should select at most one of 530 the offered extensions with the same identifier, and remap it to a 531 free identifier in the valid range, for that extension to be usable. 533 Similarly, if more extensions are offered than can be fit in the 534 valid range, identifiers in the range 4096-4351 may be offered; the 535 answerer should choose those that are desired, and remap them to a 536 free identifier in the valid range. 538 It is always allowed to place the offered identifier value "as is" in 539 the SDP answer (for example, due to lack of a free identifier value 540 in the valid range). Extensions with an identifier outside the valid 541 range cannot, of course, be used. If required, the offerer or 542 answerer can update the session to make space for such an extension. 544 Rationale: the range 4096-4351 for these negotiation identifiers is 545 deliberately restricted to allow expansion of the range of valid 546 identifiers in future. 548 Either party MAY include extensions in the stream other than those 549 negotiated, or those negotiated as "inactive", for example, for the 550 benefit of intermediate nodes. Only extensions that appeared with an 551 identifier in the valid range in SDP originated by the sender can be 552 sent. 554 Example (port numbers, RTP profiles, payload IDs and rtpmaps, etc. 555 all omitted for brevity): 557 The offer: 559 a=extmap:1 URI-toffset 560 a=extmap:14 URI-obscure 561 a=extmap:4096 URI-gps-string 562 a=extmap:4096 URI-gps-binary 563 a=extmap:4097 URI-frametype 564 m=video 565 a=sendrecv 566 m=audio 567 a=sendrecv 569 The answerer is interested in receiving GPS in string format only on 570 video, but cannot send GPS at all. It is not interested in 571 transmission offsets on audio, and does not understand the URI- 572 obscure extension. It therefore moves the extensions from session 573 level to media level, and adjusts the declarations: 575 m=video 576 a=sendrecv 577 a=extmap:1 URI-toffset 578 a=extmap:2/recvonly URI-gps-string 579 a=extmap:3 URI-frametype 580 m=audio 581 a=sendrecv 582 a=extmap:1/sendonly URI-toffset 584 8. BNF Syntax 586 The syntax definition below uses ABNF according to [RFC5234]. The 587 syntax element 'URI' is defined in [RFC3986] (only absolute URIs are 588 permitted here). The syntax element 'extmap' is an attribute as 589 defined in [RFC4566], i.e., "a=" precedes the extmap definition. 590 Specific extensionattributes are defined by the specification that 591 defines a specific extension name; there may be several. 593 extmap = mapentry SP extensionname [SP extensionattributes] 595 extensionname = URI 597 direction = "sendonly" / "recvonly" / "sendrecv" / "inactive" 599 mapentry = "extmap:" 1*5DIGIT ["/" direction] 601 extensionattributes = byte-string 603 URI = 605 byte-string = 607 SP = 609 DIGIT = 611 9. Security Considerations 613 This document defines only a place to transmit information; the 614 security implications of each of the extensions must be discussed 615 with those extensions. 617 Header extensions have the same security coverage as the RTP header 618 itself. When Secure Real-time Transport Protocol (SRTP) [RFC3711] is 619 used to protect RTP sessions, the RTP payload may be both encrypted 620 and integrity protected, while the RTP header is either unprotected 621 or integrity protected. RTP header extensions may carry sensitive 622 information for which participants in multimedia sessions want 623 confidentiality. RFC6904 [RFC6904] provides a mechanism, extending 624 the mechanisms of SRTP, to selectively encrypt RTP header extensions 625 in SRTP. 627 10. IANA Considerations 629 This document updates the IANA consideration to reference this 630 document and adds a new SDP attribute in section 10.3 632 Note to IANA : change RFCxxxx to this RFC number and remove the note. 634 10.1. Identifier Space for IANA to Manage 636 The mapping from the naming URI form to a reference to a 637 specification is managed by IANA. Insertion into this registry is 638 under the requirements of "Expert Review" as defined in [RFC5226]. 640 The IANA will also maintain a server that contains all of the 641 registered elements in a publicly accessible space. 643 Here is the formal declaration required by the IETF URN Sub-namespace 644 specification [RFC3553]. 646 o Registry name: RTP Compact Header Extensions 648 o Specification: RFC 5285 and RFCs updating RFC 5285. 650 o Information required: 652 A. The desired extension naming URI 654 B. A formal reference to the publicly available specification 656 C. A short phrase describing the function of the extension 658 D. Contact information for the organization or person making the 659 registration 661 For extensions defined in RFCs, the URI is recommended to be of 662 the form urn:ietf:params:rtp-hdrext:, and the formal reference is 663 the RFC number of the RFC documenting the extension. 665 o Review process: Expert review is required. The expert review 666 should check the following requirements: 668 1. that the specification is publicly available; 670 2. that the extension complies with the requirements of RTP and 671 this specification, for extensions (notably, that the stream 672 is still decodable if the extension is ignored or not 673 recognized); 675 3. that the extension specification is technically consistent (in 676 itself and with RTP), complete, and comprehensible; 678 4. that the extension does not duplicate functionality in 679 existing IETF specifications (including RTP itself), or other 680 extensions already registered; 682 5. that the specification contains a security analysis regarding 683 the content of the header extension; 685 6. that the extension is generally applicable, for example point- 686 to-multipoint safe, and the specification correctly describes 687 limitations if they exist; and 689 7. that the suggested naming URI form is appropriately chosen and 690 unique. 692 o Size and format of entries: a mapping from a naming URI string to 693 a formal reference to a publicly available specification, with a 694 descriptive phrase and contact information. 696 o Initial assignments: none. 698 10.2. Registration of the SDP extmap Attribute 700 This section contains the information required by [RFC4566] for an 701 SDP attribute. 703 o contact name, email address, and telephone number: 705 D. Singer 706 singer@apple.com 707 +1 408-974-3162 709 o attribute name (as it will appear in SDP): extmap 711 o long-form attribute name in English: generic header extension map 712 definition 714 o type of attribute (session level, media level, or both): both 716 o whether the attribute value is subject to the charset attribute: 717 not subject to the charset attribute 719 o a one-paragraph explanation of the purpose of the attribute: This 720 attribute defines the mapping from the extension numbers used in 721 packet headers into extension names as documented in 722 specifications and appropriately registered. 724 o a specification of appropriate attribute values for this 725 attribute: see RFC 5285. 727 10.3. Registration of the SDP Attribute 729 The IANA is requested to register one new SDP attribute: 731 SDP Attribute ("att-field"): 732 Attribute name: extmap-allow-mixed 733 Long form: One and Two bytes mixed mode 734 Type of name: att-field 735 Type of attribute: Media or session level 736 Subject to charset: No 737 Purpose: Negotiate the use of One and Two bytes 738 in the same RTP stream. 739 Reference: [RFCXXXX] 740 Values: None 742 11. Acknowledgments 744 Both Brian Link and John Lazzaro provided helpful comments on an 745 initial draft of this document. Colin Perkins was helpful in 746 reviewing and dealing with the details. The use of URNs for IETF- 747 defined extensions was suggested by Jonathan Lennox, and Pete Cordell 748 was instrumental in improving the padding wording. Dave Oran 749 provided feedback and text in the review. Mike Dolan contributed the 750 two-byte header form. Magnus Westerlund and Tom Taylor were 751 instrumental in managing the registration text. 753 12. References 755 12.1. Normative References 757 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 758 Requirement Levels", BCP 14, RFC 2119, 759 DOI 10.17487/RFC2119, March 1997, 760 . 762 [RFC2508] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP 763 Headers for Low-Speed Serial Links", RFC 2508, February 764 1999. 766 [RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., 767 Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, 768 K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., 769 Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header 770 Compression (ROHC): Framework and four profiles: RTP, UDP, 771 ESP, and uncompressed", RFC 3095, July 2001. 773 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 774 Jacobson, "RTP: A Transport Protocol for Real-Time 775 Applications", STD 64, RFC 3550, July 2003. 777 [RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An 778 IETF URN Sub-namespace for Registered Protocol 779 Parameters", BCP 73, RFC 3553, June 2003. 781 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 782 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 783 RFC 3711, March 2004. 785 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 786 Resource Identifier (URI): Generic Syntax", STD 66, 787 RFC 3986, January 2005. 789 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 790 Description Protocol", RFC 4566, July 2006. 792 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 793 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 794 May 2008. 796 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 797 Specifications: ABNF", STD 68, RFC 5234, January 2008. 799 [RFC6904] Lennox, J., "Encryption of Header Extensions in the Secure 800 Real-time Transport Protocol (SRTP)", RFC 6904, 801 DOI 10.17487/RFC6904, April 2013, 802 . 804 12.2. Informative References 806 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 807 with Session Description Protocol (SDP)", RFC 3264, June 808 2002. 810 [RFC6464] Lennox, J., Ed., Ivov, E., and E. Marocco, "A Real-time 811 Transport Protocol (RTP) Header Extension for Client-to- 812 Mixer Audio Level Indication", RFC 6464, 813 DOI 10.17487/RFC6464, December 2011, 814 . 816 Authors' Addresses 818 Roni Even (editor) 819 Huawei Technologies 820 Shabazi 12A 821 Tel Aviv 822 Israel 824 Email: Roni.even@mail01.huawei.com 825 David Singer 826 Apple, Inc. 827 1 Infinite Loop 828 Cupertino, CA 95014 829 USA 831 Phone: +1 408 996 1010 832 Email: singer@apple.com 833 URI: http://www.apple.com/quicktime 835 Harikishan Desineni 836 10001 Pacific Heights Blvd 837 San Diego, CA 92121 838 USA 840 Phone: +1 858 845 8996 841 Email: hdesinen@quicinc.com