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