idnits 2.17.1 draft-ietf-avt-rtp-hdrext-15.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 754. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 765. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 772. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 778. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 11, 2008) is 5862 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) ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 4234 (Obsoleted by RFC 5234) ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 AVT D. Singer 3 Internet-Draft Apple Computer Inc. 4 Intended status: Standards Track H. Desineni 5 Expires: September 12, 2008 Qualcomm 6 March 11, 2008 8 A general mechanism for RTP Header Extensions 9 draft-ietf-avt-rtp-hdrext-15.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on September 12, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2008). 40 Abstract 42 This document provides a general mechanism to use the header- 43 extension feature of RTP (the Real Time Transport Protocol). It 44 provides the option to use a small number of small extensions in each 45 RTP packet, where the universe of possible extensions is large and 46 registration is de-centralized. The actual extensions in use in a 47 session are signaled in the setup information for that session. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4 53 3. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . . 5 54 4. Packet Design . . . . . . . . . . . . . . . . . . . . . . . . 6 55 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 6 56 4.2. One-byte header . . . . . . . . . . . . . . . . . . . . . 7 57 4.3. Two-byte header . . . . . . . . . . . . . . . . . . . . . 9 58 5. SDP Signaling Design . . . . . . . . . . . . . . . . . . . . . 11 59 6. Offer/Answer . . . . . . . . . . . . . . . . . . . . . . . . . 13 60 7. BNF Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 16 61 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 62 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 63 9.1. Identifier space for IANA to manage . . . . . . . . . . . 18 64 9.2. Registration of the SDP extmap attribute . . . . . . . . . 19 65 10. RFC Editor Considerations . . . . . . . . . . . . . . . . . . 20 66 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 67 12. Normative References . . . . . . . . . . . . . . . . . . . . . 22 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 69 Intellectual Property and Copyright Statements . . . . . . . . . . 24 71 1. Introduction 73 The RTP Specification [RFC3550] provides a capability to extend the 74 RTP header. It defines the header extension format and rules for its 75 use in section 5.3.1. The existing header extension method permits 76 at most one extension per RTP packet, identified by a 16-bit 77 identifier and a 16-bit length field specifying the length of the 78 header extension in 32-bit words. 80 This mechanism has two conspicuous drawbacks. First, it permits only 81 one header extension in a single RTP packet. Second, the 82 specification gives no guidance as to how the 16-bit header extension 83 identifiers are allocated to avoid collisions. 85 This specification removes the first drawback by defining a backward- 86 compatible and extensible means to carry multiple header extension 87 elements in a single RTP packet. It removes the second drawback by 88 defining that these extension elements are named by URIs, defines an 89 IANA registry for extension elements defined in IETF specifications, 90 and an SDP method for mapping between the naming URIs and the 91 identifier values carried in the RTP packets. 93 This header extension applies to the RTP/AVP profile and its 94 extensions. 96 2. Requirements Notation 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 100 document are to be interpreted as described in [RFC2119]. 102 3. Design Goals 104 The goal of this design is to provide a simple mechanism whereby 105 multiple identified extensions can be used in RTP packets, without 106 the need for formal registration of those extensions but nonetheless 107 avoiding collision. 109 This mechanism provides an alternative to the practice of burying 110 associated metadata into the media format bit stream. This has often 111 been done in media data sent over fixed-bandwidth channels. Once 112 this is done, a decoder for the specific media format is required to 113 extract the metadata. Also, depending on the media format, the 114 metadata may need to be added at the time of encoding the media so 115 that the bit-rate required for the metadata is taken into account. 116 But the metadata may not be known at that time. Inserting metadata 117 at a later time can require a decode and re-encode to meet bit-rate 118 requirements. 120 In some cases a more appropriate, higher level mechanism may be 121 available, and if so, it should be used. For cases where a higher 122 level mechanism is not available, it is better to provide a mechanism 123 at the RTP level than have the meta-data be tied to a specific form 124 of media data. 126 4. Packet Design 128 4.1. General 130 The following design is fit into the "header extension" of the RTP 131 extension, as described above. 133 The presence and format of this header extension and its contents is 134 negotiated or defined out-of-band, such as through signaling (see 135 below for SDP signaling). The value defined for an RTP extension 136 (defined below for the one-byte and two-byte header forms) are only 137 architectural constants (e.g. for use by network analyzers); it is 138 the negotiation/definition (e.g. in SDP) which is the definitive 139 indication that this header extension is present. 141 This specification inherits the requirement from the RTP 142 specification that the header extension "is designed so that the 143 header extension may be ignored". To be specific, header extensions 144 using this specification MUST only be used for data that can safely 145 be ignored by the recipient without affecting interoperability, and 146 MUST NOT be used when the presence of the extension has changed the 147 form or nature of the rest of the packet in a way that is not 148 compatible with the way the stream is signaled (e.g as defined by the 149 payload type). Valid examples might include meta-data that is 150 additional to the usual RTP information. 152 The RTP header extension is formed as a sequence of extension 153 elements, with possible padding. Each extension element has a local 154 identifier and a length. The local identifiers may be mapped to a 155 larger namespace in the negotiation (e.g. session signaling). 157 As is good network practice, data should only be transmitted when 158 needed. The RTP header extension should only be present in a packet 159 if that packet also contains one or more extension elements, as 160 defined here. An extension element should only be present in a 161 packet when needed; the signaling setup of extension elements 162 indicates only that those elements may be present in some packets, 163 not that they are in fact present in all (or indeed, any) packets. 165 Each extension element in a packet has a local identifier (ID) and a 166 length. The local identifiers present in the stream MUST have been 167 negotiated or defined out-of-band. There are no static allocations 168 of local identifiers. Each distinct extension MUST have a unique ID. 169 The value 0 is reserved for padding and MUST NOT be used as a local 170 identifier. 172 There are two variants of the extension: one-byte and two-byte 173 headers. Since it is expected that (a) the number of extensions in 174 any given RTP session is small and (b) the extensions themselves are 175 small, the one-byte header form is preferred and MUST be supported by 176 all receivers. A stream MUST contain only one-byte or two-byte 177 headers: they MUST NOT be mixed within a stream. Transmitters SHOULD 178 NOT use the two byte form when all extensions are small enough for 179 the one-byte header form. 181 A sequence of extension elements, possibly with padding, forms the 182 header extension defined in the RTP specification. There are as many 183 extension elements as fit into the length as indicated in the RTP 184 header-extension length. Since this length is signaled in full 32- 185 bit words, padding bytes are used to pad to a 32-bit boundary. The 186 entire extension is parsed byte-by-byte to find each extension 187 element (no alignment is required), and parsing stops at the earlier 188 of the end of the entire header extension, or, in one-byte headers, 189 on encountering an identifier with the reserved value of 15. 191 In both forms, padding bytes have the value of 0 (zero). They may be 192 placed between extension elements, if desired for alignment, or after 193 the last extension element, if needed for padding. A padding byte 194 does not supply the ID of an element, nor the length field. When a 195 padding byte is found it is ignored and the parser moves on to 196 interpreting the next byte. 198 Note carefully that the one-byte header form allows for data lengths 199 between 1 and 16 bytes, by adding 1 to the signaled length value 200 (thus, 0 in the length field indicates 1 byte of data follows); this 201 allows for the important case of 16-byte payloads. This addition is 202 not performed for the two-byte headers, where the length field 203 signals data lengths between 0 and 255 bytes. 205 Use of RTP header extensions will reduce the efficiency of RTP header 206 compression, since the header extension will be sent uncompressed 207 unless the RTP header compression module is updated to recognise the 208 extension header. If header extensions are present in some packets, 209 but not in others, this can also reduce compression efficiency by 210 requiring an update to the fixed header to be conveyed when header 211 extensions start or stop being sent. The interactions of the RTP 212 header extension and header compression is explored further in 213 [RFC2508] and [RFC3095]. 215 4.2. One-byte header 217 In the one-byte header form of extensions, the 16-bit value required 218 by the RTP specification for a header extension, labelled in the RTP 219 specification as "defined by profile", takes the fixed bit pattern 220 0xBEDE (the first draft of this specification was written on the 221 feast day of the Venerable Bede). 223 Each extension element starts with a byte containing an ID and a 224 length: 226 0 227 0 1 2 3 4 5 6 7 228 +-+-+-+-+-+-+-+-+ 229 | ID | len | 230 +-+-+-+-+-+-+-+-+ 232 The 4-bit ID is the local identifier of this element in the range 233 1-14 inclusive. In the signaling section this is referred to as the 234 valid range. 236 The local identifier value 15 is reserved for future extension and 237 MUST NOT be used as an identifier. If the ID value 15 is 238 encountered, its length field should be ignored, processing of the 239 entire extension should terminate at that point, and only the 240 extension elements present prior to the element with ID 15 241 considered. 243 The 4-bit length is the number minus one of data bytes of this header 244 extension element following the one-byte header. Therefore the value 245 zero in this field indicates that one byte of data follows, and a 246 value of 15 (the maximum) indicates element data of 16 bytes. (This 247 permits carriage of 16-byte values, which is a common length of 248 labels and identifiers, while losing the possibility of zero-length 249 values - which would often be padded anyway.) 251 An example header extension, with three extension elements, some 252 padding, and including the required RTP fields, follows: 254 0 1 2 3 255 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 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 | 0xBE | 0xDE | length=3 | 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 | ID | L=0 | data | ID | L=1 | data... 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 ...data | 0 (pad) | 0 (pad) | ID | L=3 | 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 | data | 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 4.3. Two-byte header 268 In the two-byte header form, the 16-bit value required by the RTP 269 specification for a header extension, labelled in the RTP 270 specification as "defined by profile" is defined as shown below. 272 0 1 273 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 | 0x100 |appbits| 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 The appbits field is 4 bits that are application-dependent and may be 279 defined to be any value or meaning, and are outside the scope of this 280 specification. For the purposes of signaling, this field is treated 281 as a special extension value assigned to the local identifier 256. 282 If no extension has been specified through configuration or 283 signalling for this local identifier value 256, the appbits field 284 SHOULD be set to all 0s by the sender and MUST be ignored by the 285 receiver. 287 Each extension element starts with a byte containing an ID and a byte 288 containing a length: 290 0 1 291 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 | ID | length | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 The 8-bit ID is the local identifier of this element in the range 297 1-255 inclusive. In the signaling section the range 1-256 is 298 referred to as the valid range, with the values 1-255 referring to 299 extension elements, and the value 256 referring to the 4-bit field 300 'appbits' (above). 302 The 8-bit length field is the length of extension data in bytes not 303 including the ID and length fields. The value zero indicates there 304 is no data following. 306 An example header extension, with three extension elements, some 307 padding, and including the required RTP fields, follows: 309 0 1 2 3 310 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 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 | 0x10 | 0x00 | length=3 | 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 | ID | L=0 | ID | L=1 | 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 | data | 0 (pad) | ID | L=4 | 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 | data | 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 5. SDP Signaling Design 323 The indication of the presence of this extension, and the mapping of 324 local identifiers used in the header extension to a larger namespace 325 MUST be performed out of band, for example as part of a SIP offer/ 326 answer exchange using SDP. This section defines such signaling in 327 SDP. 329 A usable mapping MUST use IDs in the valid range, and each ID in this 330 range MUST be used only once for each media (or only once if the 331 mappings are session level). Mappings which do not conform to these 332 rules MAY be presented, for instance during offer/answer negotiation 333 as described in the next section, but remapping to conformant values 334 is necessary before they can be applied. 336 Each extension is named by a URI. That URI MUST be absolute, and 337 precisely identifies the format and meaning of the extension. In 338 general, the URI SHOULD also be de-referencable by any system that 339 sees or receives the SDP containing it. URIs that contain a domain 340 name SHOULD also contain a month-date in the form mmyyyy. The 341 definition of the element and assignment of the URI MUST have been 342 authorized by the owner of the domain name on or very close to that 343 date. (This avoids problems when domain names change ownership). If 344 the resource or document defines several extensions, then the URI 345 MUST identify the actual extension in use, e.g. using a fragment or 346 query identifier (characters after a '#' or '?' in the URI). 348 Rationale: the use of URIs provides for a large, unallocated space, 349 gives documentation on the extension. The URIs are not required to 350 be de-referencable, in order to permit confidential or experimental 351 use, and to cover the case when extensions continue to be used after 352 the organization that defined them ceases to exist. 354 An extension URI with the same attributes MUST NOT appear more than 355 once applying to the same stream, i.e. at session level or in the 356 declarations for a single stream at media level. (The same extension 357 may, of course, be used for several streams, and may appear 358 differently parameterized for the same stream.) 360 For extensions defined in RFCs, the URI used SHOULD be a URN starting 361 "urn:ietf:params:rtp-hdrext:" and followed by a registered, 362 descriptive name. 364 The registration requirements are detailed in the IANA 365 Considerations, below. 367 An example (this is only an example), where 'avt-example-metadata' is 368 the hypothetical name of a header extension, might be: 370 urn:ietf:params:rtp-hdrext:avt-example-metadata 372 An example name not from the IETF (this is only an example) might be: 374 http://example.com/082005/ext.htm#example-metadata 376 The mapping may be provided per media-stream (in the media level 377 section(s) of SDP, i.e. after an "m=" line) or globally for all 378 streams (i.e. before the first "m=" line, at session level). The 379 definitions MUST be either all session level or all media level; it 380 is not permitted to mix the two styles. In addition, as noted above, 381 the IDs used MUST be unique for each stream type for a given media, 382 or for the session for session level declarations. 384 Each local identifier potentially used in the stream is mapped to a 385 string using an attribute of the form: 387 a=extmap:["/"] 389 where is a URI, as above, is the local identifier (ID) 390 of this extension, and is an integer in the valid range inclusive (0 391 is reserved for padding in both forms, and 15 is reserved in the one- 392 byte header form, as noted above), and is one of 393 "sendonly", "recvonly", "sendrecv", "inactive" (without the quotes). 395 The formal BNF syntax is presented in a later section of this 396 specification. 398 Example: 400 a=extmap:1 http://example.com/082005/ext.htm#ttime 402 a=extmap:2/sendrecv http://example.com/082005/ext.htm#xmeta short 404 When SDP signaling is used for the RTP session, it is the presence of 405 the 'extmap' attribute(s) which is diagnostic that this style of 406 header extensions is used, not the magic number indicated above. 408 6. Offer/Answer 410 The simple signaling described above may be enhanced in an offer/ 411 answer context, to permit: 413 o asymmetric behavior (extensions sent in only one direction); 415 o the offer of mutually-exclusive alternatives; 417 o the offer of more extensions than can be sent in a single session. 419 A direction attribute MAY be included in an extmap; without it, the 420 direction implicitly inherits, of course, from the stream direction, 421 or is "sendrecv" for session level attributes or extensions of 422 "inactive" streams. The direction MUST be one of "sendonly", 423 "recvonly", "sendrecv", "inactive". A "sendonly" direction indicates 424 an ability to send; a "recvonly" direction indicates a desire to 425 receive; a "sendrecv" direction indicates both. An "inactive" 426 direction indicates neither, but later re-negotiation may make an 427 extension active. 429 Extensions, with their directions, may be signaled for an "inactive" 430 stream. It is an error to use an extension direction incompatible 431 with the stream direction (e.g. a "sendonly" attribute for a 432 "recvonly" stream). 434 If an offer or answer contains session level mappings (and hence no 435 media level mappings), and different behavior is desired for each 436 stream, then the entire set of extension map declarations may be 437 moved into the media level section(s) of the SDP. (Note that this 438 specification does not permit mixing global and local declarations, 439 to make identifier management easier). 441 If an extension map is offered as "sendrecv", explicitly or 442 implicitly, and asymmetric behavior is desired, the SDP may be 443 modified to modify or add direction qualifiers for that extension. 445 If an extension is marked as "sendonly" and the answerer desires to 446 receive it, the extension MUST be marked as "recvonly" in the SDP 447 answer. An answerer which has no desire to receive the extension or 448 does not understand the extension SHOULD remove it from the SDP 449 answer. 451 If an extension is marked as "recvonly" and the answerer desires to 452 send it, the extension MUST be marked as "sendonly" in the SDP 453 answer. An answerer which has no desire to, or is unable to, send 454 the extension SHOULD remove it from the SDP answer. 456 Local identifiers in the valid range inclusive in an offer or answer 457 must not be used more than once per media section (including the 458 session level section). A session update MAY change the direction 459 qualifiers of extensions under use. A session update MAY add or 460 remove extension(s). Identifiers values in the valid range MUST NOT 461 be altered (remapped). 463 Note that, under this rule, the same local identifier cannot be used 464 for two extensions for the same media, even when one is "sendonly" 465 and the other "recvonly", as it would then be impossible to make 466 either of them sendrecv (since re-numbering is not permitted either). 468 If a party wishes to offer mutually exclusive alternatives, then 469 multiple extensions with the same identifier in the (unusable) range 470 4096-4351 may be offered; the answerer should select at most one of 471 the offered extensions with the same identifier, and remap it to a 472 free identifier in the valid range, for that extension to be usable. 474 Similarly, if more extensions are offered than can be fit in the 475 valid range, identifiers in the range 4096-4351 may be offered; the 476 answerer should choose those that are desired, and remap them to a 477 free identifier in the valid range. 479 It is always allowed to place the offered identifier value "as is" in 480 the SDP answer (for example, due to lack of a free identifier value 481 in the valid range). Extensions with an identifier outside the valid 482 range cannot, of course, be used. If required, the offerer or 483 answerer can update the session to make space for such an extension. 485 Rationale: the range 4096-4351 for these negotiation identifiers is 486 deliberately restricted to allow expansion of the range of valid 487 identifiers in future. 489 Either party MAY include extensions in the stream other than those 490 negotiated, or those negotiated as "inactive", for example for the 491 benefit of intermediate nodes. Only extensions that appeared with an 492 identifier in the valid range in SDP originated by the sender can be 493 sent. 495 Example (port numbers, RTP profiles, payload IDs and rtpmaps etc. all 496 omitted for brevity): 498 The offer: 500 a=extmap:1 URI-toffset 501 a=extmap:14 URI-obscure 502 a=extmap:4096 URI-gps-string 503 a=extmap:4096 URI-gps-binary 504 a=extmap:4097 URI-frametype 505 m=video 506 a=sendrecv 507 m=audio 508 a=sendrecv 510 The answerer is interested in receiving GPS in string format only on 511 video, but cannot send GPS at all. They are not interested in 512 transmission offsets on audio, and do not understand the URI-obscure 513 extension. They therefore move the extensions from session level to 514 media level, and adjust the declarations: 516 m=video 517 a=sendrecv 518 a=extmap:1 URI-toffset 519 a=extmap:2/recvonly URI-gps-string 520 a=extmap:3 URI-frametype 521 m=audio 522 a=sendrecv 523 a=extmap:1/sendonly URI-toffset 525 7. BNF Syntax 527 The syntax definition below uses ABNF according to [RFC4234]. The 528 syntax element 'URI' is defined in [RFC3986] (only absolute URIs are 529 permitted here). The syntax element 'extmap' is an attribute as 530 defined in [RFC4566], i.e "a=" precedes the extmap definition. 531 Specific extensionattributes are defined by the specification that 532 defines a specific extension name; there may be several. 534 extmap = mapentry SP extensionname [SP extensionattributes] 536 extensionname = URI 538 direction = "sendonly" / "recvonly" / "sendrecv" / "inactive" 540 mapentry = "extmap:" 1*5DIGIT ["/" direction] 542 extensionattributes = byte-string 544 URI = 546 byte-string = 548 SP = 550 DIGIT = 552 8. Security Considerations 554 This defines only a place to transmit information; the security 555 implications of the extensions must be discussed with those 556 extensions. 558 Care should be taken when defining extensions. Clearly, they should 559 be solely informative, but even when the information is extracted, 560 should not cause security concerns. 562 Header extensions have the same security coverage as the RTP header 563 itself. When SRTP [RFC3711] is used to protect RTP sessions, the RTP 564 payload may be both encrypted and integrity protected, while the RTP 565 header is either unprotected or integrity protected. Therefore, it 566 is inappropriate to place information in header extensions which 567 cause security problems if disclosed, unless the entire RTP packet is 568 protected by a lower-layer security protocol providing both 569 confidentiality and integrity capability. 571 9. IANA Considerations 573 9.1. Identifier space for IANA to manage 575 The mapping from the naming URI form to a reference to a 576 specification is managed by IANA. Insertion into this registry is 577 under the requirements of "Expert Review" as defined in [RFC2434]. 579 The IANA will also maintain a server that contains all of the 580 registered elements in a publicly accessible space. 582 Here is the formal declaration required by the IETF URN Sub-namespace 583 specification [RFC3553]. 585 o Registry name: RTP Compact Header Extensions 587 o Specification: RFCxxxx and RFCs updating RFCxxxx. 589 o Information required: 591 A. The desired extension naming URI 593 B. A formal reference to the publicly available specification 595 C. A short phrase describing the function of the extension 597 D. Contact information for the organization or person making the 598 registration 600 For extensions defined in RFCs, the URI is recommended to be of 601 the form urn:ietf:params:rtp-hdrext:, and the formal reference is 602 the RFC number of the RFC documenting the extension. 604 o Review process: Expert Review is required. The expert review 605 should check the following requirements: 607 1. that the specification is publicly available; 609 2. that the extension complies with the requirements of RTP and 610 this specification, for extensions (notably, that the stream 611 is still decodable if the extension is ignored or not 612 recognized); 614 3. that the extension specification is technically consistent (in 615 itself and with RTP), complete, and comprehensible; 617 4. that the extension does not duplicate functionality in 618 existing IETF specifications (including RTP itself), or other 619 extensions already registered; 621 5. that the specification contains a security analysis regarding 622 the content of the header extension; 624 6. that the extension is general applicable, for example point to 625 multi-point safe and the specification correctly describes 626 limitations if they exist; 628 7. that the suggested naming URI form is appropriately chosen and 629 unique. 631 o Size and format of entries: a mapping from a naming URI string to 632 a formal reference to a publicly available specification, with a 633 descriptive phrase and contact information. 635 o Initial assignments: none. 637 9.2. Registration of the SDP extmap attribute 639 This section contains the information required by [RFC4566] for an 640 SDP attribute. 642 o contact name, email address and telephone number: D. Singer, 643 singer@apple.com, +1 408-974-3162 645 o attribute-name (as it will appear in SDP): extmap 647 o long-form attribute name in English: generic header extension map 648 definition 650 o type of attribute (session level, media level, or both): both 652 o whether the attribute value is subject to the charset attribute: 653 not subject to the charset attribute 655 o a one paragraph explanation of the purpose of the attribute: This 656 attribute defines the mapping from the extension numbers used in 657 packet headers into extension names as documented in 658 specifications and appropriately registered. 660 o a specification of appropriate attribute values for this 661 attribute: see RFCxxxx. 663 10. RFC Editor Considerations 665 RFCxxxx in the IANA considerations needs to be replaced with the RFC 666 number. 668 11. Acknowledgments 670 Both Brian Link and John Lazzaro provided helpful comments on an 671 initial draft. Colin Perkins was helpful in reviewing and dealing 672 with the details. The use of URNs for IETF-defined extensions was 673 suggested by Jonathan Lennox, and Pete Cordell was instrumental in 674 improving the padding wording. Dave Oran provided feedback and text 675 in the review. Mike Dolan contributed the two-byte header form. 676 Magnus Westerlund and Tom Taylor were instrumental in managing the 677 registration text. 679 12. Normative References 681 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 682 Requirement Levels", BCP 14, RFC 2119, March 1997. 684 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 685 IANA Considerations Section in RFCs", RFC 2434, BCP 26, 686 October 1998. 688 [RFC2508] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP 689 Headers for Low-Speed Serial Links", RFC 2508, 690 February 1999. 692 [RFC3095] Bormann, C., "RObust Header Compression (ROHC): Framework 693 and four profiles: RTP, UDP, ESP, and uncompressed", 694 RFC 3095, July 2001. 696 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 697 Jacobson, "RTP: A Transport Protocol for Real-Time 698 Applications", RFC 3550, STD 0064, July 2003. 700 [RFC3553] Mealling, T., Masinter, L., Hardie, T., and G. Klyne, "An 701 IETF URN Sub-namespace for Registered Protocol 702 Parameters", RFC 3553, June 2003. 704 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 705 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 706 RFC 3711, March 2004. 708 [RFC3986] Berners-Lee, MT., Fielding, R., and L. Masinter, "Uniform 709 Resource Identifier (URI): Generic Syntax", RFC 3986, 710 January 2005. 712 [RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 713 Specifications: ABNF", RFC 4234, October 2005. 715 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 716 Description Protocol", RFC 4566, July 2006. 718 Authors' Addresses 720 David Singer 721 Apple Computer Inc. 722 1 Infinite Loop 723 Cupertino, CA 95014 724 US 726 Phone: +1 408 996 1010 727 Email: singer@apple.com 728 URI: http://www.apple.com/quicktime 730 Harikishan Desineni 731 Qualcomm 732 5775 Morehouse Drive 733 San Diego, CA 92126 734 USA 736 Phone: +1 858 845 8996 737 Email: hd@qualcomm.com 738 URI: http://www.qualcomm.com 740 Full Copyright Statement 742 Copyright (C) The IETF Trust (2008). 744 This document is subject to the rights, licenses and restrictions 745 contained in BCP 78, and except as set forth therein, the authors 746 retain all their rights. 748 This document and the information contained herein are provided on an 749 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 750 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 751 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 752 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 753 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 754 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 756 Intellectual Property 758 The IETF takes no position regarding the validity or scope of any 759 Intellectual Property Rights or other rights that might be claimed to 760 pertain to the implementation or use of the technology described in 761 this document or the extent to which any license under such rights 762 might or might not be available; nor does it represent that it has 763 made any independent effort to identify any such rights. Information 764 on the procedures with respect to rights in RFC documents can be 765 found in BCP 78 and BCP 79. 767 Copies of IPR disclosures made to the IETF Secretariat and any 768 assurances of licenses to be made available, or the result of an 769 attempt made to obtain a general license or permission for the use of 770 such proprietary rights by implementers or users of this 771 specification can be obtained from the IETF on-line IPR repository at 772 http://www.ietf.org/ipr. 774 The IETF invites any interested party to bring to its attention any 775 copyrights, patents or patent applications, or other proprietary 776 rights that may cover technology that may be required to implement 777 this standard. Please address the information to the IETF at 778 ietf-ipr@ietf.org. 780 Acknowledgment 782 Funding for the RFC Editor function is provided by the IETF 783 Administrative Support Activity (IASA).