idnits 2.17.1 draft-ietf-avt-rtp-hdrext-12.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 600. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 611. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 618. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 624. 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 (February 26, 2007) is 6269 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 4566 (Obsoleted by RFC 8866) Summary: 2 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: August 30, 2007 Qualcomm 6 February 26, 2007 8 A general mechanism for RTP Header Extensions 9 draft-ietf-avt-rtp-hdrext-12.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 August 30, 2007. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 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 5. SDP Signalling Design . . . . . . . . . . . . . . . . . . . . 9 56 6. Offer/Answer . . . . . . . . . . . . . . . . . . . . . . . . . 11 57 7. BNF Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 14 58 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 59 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 60 9.1. New space for IANA to manage . . . . . . . . . . . . . . . 16 61 9.2. Registration of the SDP extmap attribute . . . . . . . . . 16 62 10. RFC Editor Considerations . . . . . . . . . . . . . . . . . . 18 63 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 64 12. Normative References . . . . . . . . . . . . . . . . . . . . . 20 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 66 Intellectual Property and Copyright Statements . . . . . . . . . . 22 68 1. Introduction 70 The RTP Specification [RFC3550] provides a capability to extend the 71 RTP header. It defines the header extension format and rules for its 72 use in section 5.3.1. The existing header extension method permits 73 at most one extension per RTP packet, identified by a 16-bit 74 identifier and a 16-bit length field specifying the length of the 75 header extension in 32-bit words. 77 This mechanism has two conspicuous drawbacks. First, it permits only 78 one header extension in a single RTP packet. Second, the 79 specification gives no guidance as to how the 16-bit header extension 80 identifiers are allocated to avoid collisions. 82 This specification removes the first drawback by defining a backward- 83 compatible and extensible means to carry multiple header extension 84 elements in a single RTP packet. It removes the second drawback by 85 defining that these extension elements are labelled by URNs, defines 86 an IANA registry for extension elements defined in IETF 87 specifications, and an SDP method for mapping between the URNs and 88 the identifier values carried in the RTP packets. 90 This header extension applies to the RTP/AVP profile and its 91 extensions. 93 2. Requirements notation 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 97 document are to be interpreted as described in [RFC2119]. 99 3. Design Goals 101 The goal of this design is to provide a simple mechanism whereby 102 multiple identified extensions can be used in RTP packets, without 103 the need for formal registration of those extensions but nonetheless 104 avoiding collision. 106 This mechanism provides an alternative to the practice of burying 107 associated metadata into the media format bit stream. This has often 108 been done in media data sent over fixed-bandwidth channels. Once 109 this is done, a decoder for the specific media format is required to 110 extract the metadata. Also, depending on the media format, the 111 metadata may need to be added at the time of encoding the media so 112 that the bit-rate required for the metadata is taken into account. 113 But the metadata may not be known at that time. Inserting metadata 114 at a later time can require a decode and re-encode to meet bit-rate 115 requirements. 117 In some cases a more appropriate, higher level mechanism may be 118 available, and if so, it should be used. For cases where a higher 119 level mechanism is not available, it is better to provide a mechanism 120 at the RTP level than have the meta-data be tied to a specific form 121 of media data. 123 4. Packet Design 125 The following design is fit into the "header extension" of the RTP 126 extension, as described above. The 16-bit value required by the RTP 127 specification for a header extension, labelled in the RTP 128 specification as "defined by profile", takes the fixed bit pattern 129 0xBEDE (the first draft of this specification was written on the 130 feast day of the Venerable Bede). 132 The presence and format of this header extension and its contents is 133 negotiated or defined out-of-band, such as through signaling (see 134 below for SDP signaling). The fixed value defined above is only an 135 architectural constant (e.g. for use by by network analyzers); it is 136 the negotiation/definition (e.g. in SDP) which is the definitive 137 indication that this header extension is present. 139 This specification inherits the requirement from the RTP 140 specification that the header extension "is designed so that the 141 header extension may be ignored". To be specific, header extensions 142 using this specification MUST only be used for data that can safely 143 be ignored by the recipient without affecting interoperability. 144 Examples might include meta-data that is additional to the usual RTP 145 information. 147 The RTP header extension is formed as a sequence of extension 148 elements, with possible padding. Each extension element has a local 149 identifier and a length. Since it is expected that (a) the number of 150 extensions in any given RTP session is small and (b) the extensions 151 themselves are small, only 4 bits are allocated to each of these. 152 The local identifiers may be mapped to a larger namespace in the 153 negotiation (e.g. session signaling). 155 Each extension element starts with a byte containing an ID and a 156 length: 158 0 159 0 1 2 3 4 5 6 7 160 +-+-+-+-+-+-+-+-+ 161 | ID | len | 162 +-+-+-+-+-+-+-+-+ 164 The 4-bit ID is the local identifier of this element in the range 165 1-14 inclusive. The values present in the stream MUST have been 166 negotiated or defined out-of-band. There are no static allocations 167 of identifiers. Each distinct extension MUST have a unique ID. 169 The value 0 is reserved for padding and MUST NOT be used as an 170 identifier. 172 The value 15 is reserved for future extension and MUST NOT be used as 173 an identifier. If the ID value 15 is encountered, its length field 174 should be ignored, processing of the entire extension should 175 terminate at that point, and only the extension elements present 176 prior to the element with ID 15 considered. 178 The 4-bit length is the number minus one of data bytes of this header 179 extension element following the one-byte header. Therefore the value 180 zero in this field indicates that one byte of data follows, and a 181 value of 15 (the maximum) indicates element data of 16 bytes. (This 182 permits carriage of 16-byte values, which is a common length of 183 labels and identifiers, while losing the possibility of zero-length 184 values - which would often be padded anyway.) 186 Padding bytes have the value of 0 (zero). They may be placed between 187 extension elements, if desired for alignment, or after the last 188 extension element, if needed for padding. The first four bits of a 189 padding byte are not interpreted as the ID of an ID/length pair, nor 190 are the second four bits interpreted as a length field. When a 191 padding byte is found it is ignored and the parser moves on to 192 interpreting the next byte. 194 A sequence of extension elements, possibly with padding, forms the 195 header extension defined in the RTP specification. There are as many 196 extension elements as fit into the length as indicated in the RTP 197 header-extension length. Since this length is signaled in full 32- 198 bit words, padding bytes are used to pad to a 32-bit boundary. The 199 entire extension is parsed byte-by-byte to find each extension 200 element (no alignment is required), and parsing stops at the earlier 201 of the end of the entire header extension, or on encountering an 202 identifier with the reserved value of 15. 204 An example header extension, with three extension elements, some 205 padding, and including the required RTP fields, follows: 207 0 1 2 3 208 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 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 | 0xBE | 0xDE | length=3 | 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 | ID | L=0 | data | ID | L=1 | data... 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 ...data | 0 (pad) | 0 (pad) | ID | L=3 | 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 | data | 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 As is good network practice, data should only be transmitted when 220 needed. The RTP header extension should only be present in a packet 221 if that packet also contains one or more extension elements, as 222 defined here. An extension element should only be present in a 223 packet when needed; the signaling setup of extension elements 224 indicates only that those elements may be present in some packets, 225 not that they are in fact present in all (or indeed, any) packets. 227 5. SDP Signalling Design 229 The indication of the presence of this extension, and the mapping of 230 local identifiers used in the header extension to a larger namespace 231 MUST be performed out of band, for example as part of a SIP offer/ 232 answer exchange using SDP. This section defines such signaling in 233 SDP. 235 A usable mapping MUST use IDs in the range 1-14, and each ID in this 236 range MUST be used only once for each media (or only once if the 237 mappings are session level). Mappings which do not conform to these 238 rules MAY be presented, for instance during offer/answer negotiation 239 as described in the next section, but remapping to conformant values 240 is necessary before they can be applied. 242 Each extension is named by a URI. That URI MUST be absolute, and 243 precisely identifies the format and meaning of the extension. In 244 general, the URI SHOULD also be de-referencable by any system that 245 sees or receives the SDP containing it. URIs that contain a domain 246 name SHOULD also contain a month-date in the form mmyyyy. The 247 definition of the element and assignment of the URI MUST have been 248 authorized by the owner of the domain name on or very close to that 249 date. (This avoids problems when domain names change ownership). If 250 the resource or document defines several extensions, then the URI 251 MUST identify the actual extension in use, e.g. using a fragment or 252 query identifier (characters after a '#' or '?' in the URI). 254 Rationale: the use of URIs provides for a large, unallocated space, 255 gives documentation on the extension. The URIs are not required to 256 be de-referencable, in order to permit confidential or experimental 257 use, and to cover the case when extensions continue to be used after 258 the organization that defined them ceases to exist. 260 An extension URI MUST NOT appear more than once applying to the same 261 stream, i.e. at session level or in the declarations for a single 262 stream at media level. (The same extension may, of course, be used 263 for several streams.) 265 For extensions defined in RFCs, the URI used SHOULD be a URN starting 266 "urn:ietf:params:rtp-hdrext:" and followed by a registered, 267 descriptive name. These URNs are managed by IANA. An example (this 268 is only an example), where 'avt-example-metadata' is the hypothetical 269 name of a header extension, might be: 271 urn:ietf:params:rtp-hdrext:avt-example-metadata 273 An example name not from the IETF (this is only an example) might be 274 http://example.com/082005/ext.htm#example-metadata 276 The mapping may be provided per media-stream (in the media level 277 section(s) of SDP, i.e. after an "m=" line) or globally for all 278 streams (i.e. before the first "m=" line, at session level). The 279 definitions MUST be either all session level or all media level; it 280 is not permitted to mix the two styles. In addition, as noted above, 281 the IDs used MUST be unique for each stream type for a given media, 282 or for the session for session level declarations. 284 Each local identifier potentially used in the stream is mapped to a 285 string using an attribute of the form: 287 a=extmap:["/"] 289 where is a URI, as above, is the local identifier (ID) 290 of this extension, and is an integer in the range 1-14 inclusive (0 291 and 15 are reserved, as noted above), and is one of 292 "sendonly", "recvonly", "sendrecv", "inactive" (without the quotes). 294 The formal BNF syntax is presented in a later section of this 295 specification. 297 Example: 299 a=extmap:1 http://example.com/082005/ext.htm#ttime 301 a=extmap:2/sendrecv http://example.com/082005/ext.htm#xmeta short 303 When SDP signaling is used for the RTP session, it is the presence of 304 the 'extmap' attribute(s) which is diagnostic that this style of 305 header extensions is used, not the magic number indicated above. 307 6. Offer/Answer 309 The simple signaling described above may be enhanced in an offer/ 310 answer context, to permit: 312 o asymmetric behavior (extensions sent in only one direction); 314 o the offer of mutually-exclusive alternatives; 316 o the offer of more extensions than can be sent in a single session. 318 A direction attribute MAY be included in an extmap; without it, the 319 direction implicitly inherits, of course, from the stream direction, 320 or is "sendrecv" for session level attributes or extensions of 321 "inactive" streams. The direction MUST be one of "sendonly", 322 "recvonly", "sendrecv", "inactive". A "sendonly" direction indicates 323 an ability to send; a "recvonly" direction indicates a desire to 324 receive; a "sendrecv" direction indicates both. An "inactive" 325 direction indicates neither, but later re-negotiation may make an 326 extension active. 328 Extensions, with their directions, may be signaled for an "inactive" 329 stream. It is an error to use an extension direction incompatible 330 with the stream direction (e.g. a "sendonly" attribute for a 331 "recvonly" stream). 333 If an offer or answer contains session level mappings (and hence no 334 media level mappings), and different behavior is desired for each 335 stream, then the entire set of extension map declarations may be 336 moved into the media level section(s) of the SDP. (Note that this 337 specification does not permit mixing global and local declarations, 338 to make identifier management easier). 340 If an extension map is offered as "sendrecv", explicitly or 341 implicitly, and asymmetric behavior is desired, the SDP may be 342 modified to modify or add direction qualifiers for that extension. 344 If an extension is marked as "sendonly" and the answerer desires to 345 receive it, the extension MUST be marked as "recvonly" in the SDP 346 answer. An answerer which has no desire to receive the extension or 347 does not understand the extension SHOULD remove it from the SDP 348 answer. 350 If an extension is marked as "recvonly" and the answerer desires to 351 send it, the extension MUST be marked as "sendonly" in the SDP 352 answer. An answerer which has no desire to, or is unable to, send 353 the extension SHOULD remove it from the SDP answer. 355 Identifiers in the range 1-14 inclusive in an offer or answer must 356 not be used more than once per media section (including the session 357 level section). A session update MAY change the direction qualifiers 358 of extensions under use. A session update MAY add or remove 359 extension(s). Identifiers values in the range 1-14 MUST NOT be 360 altered (remapped). 362 Note that, under this rule, the same identifier cannot be used for 363 two extensions for the same media, even when one is "sendonly" and 364 the other "recvonly", as it would then be impossible to make either 365 of them sendrecv (since re-numbering is not permitted either). 367 If a party wishes to offer mutually exclusive alternatives, then 368 multiple extensions with the same identifier in the (unusable) range 369 4096-4351 may be offered; the answerer should select at most one of 370 the offered extensions with the same identifier, and remap it to a 371 free identifier in the range 1-14, for that extension to be usable. 373 Similarly, if more than 14 extensions are offered, identifiers in the 374 range 4096-4351 may be offered; the answerer should choose those that 375 are desired, and remap them to a free identifier in the range 1-14. 377 It is always allowed to place the offered identifier value "as is" in 378 the SDP answer (for example, due to lack of a free identifier value 379 in the range 1-14). Extensions with an identifier outside the range 380 1-14 cannot, of course, be used. If required, the offerer or 381 answerer can update the session to make space for such an extension. 383 Rationale: the range 4096-4351 for these negotiation identifiers is 384 deliberately restricted to allow expansion of the range of valid 385 identifiers in future (e.g. by using a full byte for an ID). 387 Either party MAY include extensions in the stream other than those 388 negotiated, or those negotiated as "inactive", for example for the 389 benefit of intermediate nodes. Only extensions that appeared with an 390 identifier in the range 1-14 in SDP originated by the sender can be 391 sent. 393 Example (port numbers, RTP profiles, payload IDs and rtpmaps etc. all 394 omitted for brevity): 396 The offer: 398 a=extmap:1 URI-toffset 399 a=extmap:14 URI-obscure 400 a=extmap:4096 URI-gps-string 401 a=extmap:4096 URI-gps-binary 402 a=extmap:4097 URI-frametype 403 m=video 404 a=sendrecv 405 m=audio 406 a=sendrecv 408 The answerer is interested in receiving GPS in string format only on 409 video, but cannot send GPS at all. They are not interested in 410 transmission offsets on audio, and do not understand the URI-obscure 411 extension. They therefore move the extensions from session level to 412 media level, and adjust the declarations: 414 m=video 415 a=sendrecv 416 a=extmap:1 URI-toffset 417 a=extmap:2/recvonly URI-gps-string 418 a=extmap:3 URI-frametype 419 m=audio 420 a=sendrecv 421 a=extmap:1/sendonly URI-toffset 423 7. BNF Syntax 425 The syntax element 'URI-reference' is as defined in [RFC3986], except 426 that only absolute URIs are permitted here. The syntax element 427 'extmap' is an attribute as defined in [RFC4566]. 428 Extensionattributes are not defined here, but by the specification 429 that defines a specific extension name; there may be several. 431 digit = "0"/"1"/"2"/"3"/"4"/"5"/"6"/"7"/"8"/"9" 433 integer = 1*digit 435 space = " " 437 extensionname = URI-reference 439 direction = "sendonly" / "recvonly" / "sendrecv" / "inactive" 441 mapentry = "extmap:" integer ["/" direction] 443 mapattrs = [space extensionattributes] 445 extmap = mapentry space extensionname mapattrs 447 8. Security Considerations 449 This defines only a place to transmit information; the security 450 implications of the extensions must be discussed with those 451 extensions. 453 Care should be taken when defining extensions. Clearly, they should 454 be solely informative, but even when the information is extracted, 455 should not cause security concerns. 457 Header extensions have the same security coverage as the RTP header 458 itself. When SRTP [RFC3711] is used to protect RTP sessions, the RTP 459 payload may be both encrypted and integrity protected, while the RTP 460 header is either unprotected or integrity protected. Therefore, it 461 is inappropriate to place information in header extensions which 462 cause security problems if disclosed, unless the entire RTP packet is 463 protected by a lower-layer security protocol providing both 464 confidentiality and integrity capability. 466 9. IANA Considerations 468 9.1. New space for IANA to manage 470 The rtp-hdrext namespace under urn:ietf:params: needs to be created 471 for management, referenced to RFCxxxx. Additions in this namespace 472 shall be made on the basis of "Specification Required". 474 Note: Names drawn from other spaces than the IETF are managed outside 475 both the IETF and IANA, and the handling of registration and 476 documentation is the responsibility of the owner of the internet 477 domain name as of the date specified in the registration; no IANA 478 action is required for these names. 480 The IANA will also maintain a server available via at least HTTP and 481 FTP that contains all of the registered elements in some publicly 482 accessible space in the same way that all of the IANA's registered 483 elements are available via http://www.iana.org/assignments/. The 484 suggested path is 485 http://www.iana.org/assignments/RTP-header-extensions/. 487 Here is the formal declaration required by the IETF URN Sub-namespace 488 specification [RFC3553]. 490 o Registry name: urn:ietf:params:rtp-hdrext: (RTP header extensions 491 defined by the IETF) 493 o Specification: RFCxxxx and RFCs updating RFCxxxx. 495 o Repository: see above. 497 o Index value: -- The index value is an absolute URI, chosen for 498 uniqueness within the parameter space. 500 9.2. Registration of the SDP extmap attribute 502 This section contains the information required by [RFC4566] for an 503 SDP attribute. 505 o contact name, email address and telephone number: D. Singer, 506 singer@apple.com, +1 408-974-3162 508 o attribute-name (as it will appear in SDP): extmap 510 o long-form attribute name in English: generic header extension map 511 definition 513 o type of attribute (session level, media level, or both): both 515 o whether the attribute value is subject to the charset attribute: 516 not subject to the charset attribute 518 o a one paragraph explanation of the purpose of the attribute: This 519 attribute defines the mapping from the extension numbers used in 520 packet headers into extension names as documented in 521 specifications and appropriately registered. 523 o a specification of appropriate attribute values for this 524 attribute: see RFCxxxx. 526 10. RFC Editor Considerations 528 RFCxxxx in the IANA considerations needs to be replaced with the RFC 529 number (two places). 531 11. Acknowledgments 533 Both Brian Link and John Lazzaro provided helpful comments on an 534 initial draft. Colin Perkins was helpful in reviewing and dealing 535 with the details. The use of URNs for IETF-defined extensions was 536 suggested by Jonathan Lennox, and Pete Cordell was instrumental in 537 improving the padding wording. Dave Oran provided feedback and text 538 in the final review. 540 12. Normative References 542 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 543 Requirement Levels", BCP 14, RFC 2119, March 1997. 545 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 546 Jacobson, "RTP: A Transport Protocol for Real-Time 547 Applications", RFC 3550, STD 0064, July 2003. 549 [RFC3553] Mealling, T., Masinter, L., Hardie, T., and G. Klyne, "An 550 IETF URN Sub-namespace for Registered Protocol 551 Parameters", RFC 3553, June 2003. 553 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 554 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 555 RFC 3711, March 2004. 557 [RFC3986] Berners-Lee, MT., Fielding, R., and L. Masinter, "Uniform 558 Resource Identifier (URI): Generic Syntax", RFC 3986, 559 January 2005. 561 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 562 Description Protocol", RFC 4566, July 2006. 564 Authors' Addresses 566 David Singer 567 Apple Computer Inc. 568 1 Infinite Loop 569 Cupertino, CA 95014 570 US 572 Phone: +1 408 996 1010 573 Email: singer@apple.com 574 URI: http://www.apple.com/quicktime 576 Harikishan Desineni 577 Qualcomm 578 5775 Morehouse Drive 579 San Diego, CA 92126 580 USA 582 Phone: +1 858 845 8996 583 Email: hd@qualcomm.com 584 URI: http://www.qualcomm.com 586 Full Copyright Statement 588 Copyright (C) The IETF Trust (2007). 590 This document is subject to the rights, licenses and restrictions 591 contained in BCP 78, and except as set forth therein, the authors 592 retain all their rights. 594 This document and the information contained herein are provided on an 595 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 596 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 597 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 598 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 599 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 600 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 602 Intellectual Property 604 The IETF takes no position regarding the validity or scope of any 605 Intellectual Property Rights or other rights that might be claimed to 606 pertain to the implementation or use of the technology described in 607 this document or the extent to which any license under such rights 608 might or might not be available; nor does it represent that it has 609 made any independent effort to identify any such rights. Information 610 on the procedures with respect to rights in RFC documents can be 611 found in BCP 78 and BCP 79. 613 Copies of IPR disclosures made to the IETF Secretariat and any 614 assurances of licenses to be made available, or the result of an 615 attempt made to obtain a general license or permission for the use of 616 such proprietary rights by implementers or users of this 617 specification can be obtained from the IETF on-line IPR repository at 618 http://www.ietf.org/ipr. 620 The IETF invites any interested party to bring to its attention any 621 copyrights, patents or patent applications, or other proprietary 622 rights that may cover technology that may be required to implement 623 this standard. Please address the information to the IETF at 624 ietf-ipr@ietf.org. 626 Acknowledgment 628 Funding for the RFC Editor function is provided by the IETF 629 Administrative Support Activity (IASA).