idnits 2.17.1 draft-begen-fecframe-sdp-elements-00.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 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 590. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 601. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 608. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 614. 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 use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- 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 (November 11, 2007) is 6010 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) == Outdated reference: A later version (-15) exists of draft-ietf-fecframe-framework-00 ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 4756 (Obsoleted by RFC 5956) ** Obsolete normative reference: RFC 4234 (Obsoleted by RFC 5234) == Outdated reference: A later version (-13) exists of draft-ietf-mmusic-sdp-capability-negotiation-07 Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 FEC Framework A. Begen 3 Internet-Draft Cisco Systems 4 Intended status: Standards Track November 11, 2007 5 Expires: May 14, 2008 7 SDP Elements for FEC Framework 8 draft-begen-fecframe-sdp-elements-00 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on May 14, 2008. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 This document specifies the use of Session Description Protocol (SDP) 42 to describe the parameters required to signal the Forward Error 43 Correction (FEC) Framework Configuration Information between the 44 sender(s) and receiver(s). This document also provides the semantics 45 for grouping multiple source and repair flows together for the 46 applications that simultaneously use multiple instances of the FEC 47 Framework. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 53 3. Forward Error Correction (FEC) and FEC Framework . . . . . . . 3 54 3.1. Forward Error Correction (FEC) . . . . . . . . . . . . . . 3 55 3.2. FEC Framework . . . . . . . . . . . . . . . . . . . . . . 4 56 3.3. FEC Framework Configuration Information . . . . . . . . . 4 57 4. FEC Framework Descriptors . . . . . . . . . . . . . . . . . . 6 58 4.1. Transport Protocol Identifiers . . . . . . . . . . . . . . 6 59 4.2. Media Stream Grouping . . . . . . . . . . . . . . . . . . 6 60 4.3. Source IP Addresses . . . . . . . . . . . . . . . . . . . 7 61 4.4. Source Flows . . . . . . . . . . . . . . . . . . . . . . . 8 62 4.5. Repair Flows . . . . . . . . . . . . . . . . . . . . . . . 8 63 4.6. Minimum Buffer Size . . . . . . . . . . . . . . . . . . . 9 64 4.7. Bandwidth Specification . . . . . . . . . . . . . . . . . 10 65 5. SDP Examples . . . . . . . . . . . . . . . . . . . . . . . . . 10 66 5.1. Session Announcement Considerations . . . . . . . . . . . 11 67 5.2. Offer/Answer Considerations . . . . . . . . . . . . . . . 11 68 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 69 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 70 7.1. Transport Protocols . . . . . . . . . . . . . . . . . . . 11 71 7.2. Attribute Names . . . . . . . . . . . . . . . . . . . . . 12 72 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 73 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 74 9.1. Normative References . . . . . . . . . . . . . . . . . . . 13 75 9.2. Informative References . . . . . . . . . . . . . . . . . . 13 76 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 77 Intellectual Property and Copyright Statements . . . . . . . . . . 14 79 1. Introduction 81 The Forward Error Correction (FEC) Framework, described in 82 [I-D.ietf-fecframe-framework], outlines a general framework for using 83 FEC-based error recovery in packet flows carrying media content. 84 While a continuous signaling between the sender(s) and receiver(s) is 85 not required for a Content Delivery Protocol (CDP) that uses the FEC 86 Framework, a set of parameters pertaining to the FEC Framework MUST 87 be initially communicated between the sender(s) and receiver(s). 89 One way to communicate this information is to use the Session 90 Description Protocol (SDP)[RFC4566]. SDP provides a simple text- 91 based format for announcements and invitations to describe multimedia 92 sessions. These SDP announcements and invitations include sufficient 93 information for the sender(s) and receiver(s) to participate in the 94 multimedia sessions. SDP also provides a framework for capability 95 negotiation, which MAY be used to negotiate all or a subset of the 96 parameters pertaining to the individual sessions. 98 The purpose of this document is to introduce the SDP elements that 99 MUST be used by the CDPs using the FEC Framework that choose SDP 100 [RFC4566] as their session description protocol. 102 2. Requirements Notation 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 106 document are to be interpreted as described in [RFC2119]. 108 3. Forward Error Correction (FEC) and FEC Framework 110 This section gives a brief overview of FEC and the FEC Framework. 112 3.1. Forward Error Correction (FEC) 114 Any application that needs a reliable transmission over an unreliable 115 packet network has to cope with the packet losses. FEC is an 116 effective approach that provides reliable transmission particularly 117 in multicast and broadcast applications where the feedback from the 118 receiver(s) may be potentially limited. In a nutshell, FEC groups 119 source packets into blocks and applies protection to generate a 120 desired number of repair packets. 122 Repair packets MAY be sent on demand or independently of any receiver 123 feedback. The choice depends on the FEC code used by the 124 application, the error characteristics of the underlying network, the 125 transport scheme (e.g., unicast, multicast, and broadcast), and the 126 application. At the receiver side, lost packets can be recovered by 127 erasure decoding provided that a sufficient number of source and 128 repair packets are received. See [I-D.ietf-fecframe-framework] for 129 further details. 131 3.2. FEC Framework 133 The FEC Framework [I-D.ietf-fecframe-framework] outlines a general 134 framework for using FEC codes in multimedia applications that stream 135 audio, video or other types of multimedia content. It defines the 136 common components and aspects of Content Delivery Protocols (CDP). 137 The FEC Framework also defines the requirements for the FEC schemes 138 that need to be used within a CDP. However, the details of the FEC 139 schemes are not specified within the FEC Framework. For example, the 140 FEC Framework defines what configuration information has to be known 141 at the sender and receiver(s) at minimum, but the FEC Framework 142 neither specifies how the FEC repair packets are generated and used 143 to recover missing source packets, nor dictates how the configuration 144 information is negotiated or signaled between the sender and 145 receiver(s). These are rather specified by the individual FEC 146 schemes or CDPs. 148 For a proper operation, the information required by the FEC Framework 149 and the details of an FEC scheme have to be communicated between the 150 sender and receiver(s). One way to provide this information is to 151 use the Session Description Protocol (SDP)[RFC4566]. SDP provides a 152 commonly used text-based format for announcements and invitations 153 that describe multimedia sessions. These SDP announcements and 154 invitations include sufficient information for clients to participate 155 in multimedia sessions. By using the SDP capability negotiation 156 framework, all or a subset of the parameters pertaining to the FEC 157 Framework MAY also be negotiated between the sender and receiver(s). 159 The purpose of this document is to introduce the SDP elements that 160 MUST be used by the CDPs using the FEC Framework that choose SDP as 161 their session description protocol. 163 3.3. FEC Framework Configuration Information 165 The FEC Framework defines a minimum set of information that MUST be 166 communicated between the sender and receiver(s) for a proper 167 operation of an FEC scheme. This information is called the FEC 168 Framework Configuration Information. This information specifies how 169 the sender applies protection to the source flow(s) and how the 170 repair flow(s) can be used to recover lost data. In other words, 171 this information specifies the relationship(s) between the source and 172 repair flows. 174 The FEC Framework Configuration Information includes identifiers for 175 unique identification of the source and repair flows that carry the 176 source and repair packets, respectively. For example, a packet flow 177 that is transmitted over UDP is uniquely identified by a tuple 178 {Source IP Address, Destination IP Address, Source UDP port, 179 Destination UDP port}. However, an integer identifier MAY be used 180 internally within the FEC scheme as a shorthand to identify this 181 flow. 183 Multiple instances of the FEC Framework MAY simultaneously exist at 184 the sender and the receiver(s) for different source flows, for the 185 same source flow, or for various combinations of source flows. Each 186 instance of the FEC Framework MUST provide the following FEC 187 Framework Configuration Information: 189 1. Identification of the repair flows. 191 2. For each source packet flow protected by the FEC repair flow(s): 193 a. Definition of the source flow. 195 b. An integer identifier for this flow definition (i.e., tuple). 196 This identifier MUST be unique amongst all source flows that are 197 protected by the same FEC repair flow. The identifiers SHOULD be 198 allocated starting from zero and increasing by one for each flow. 200 A source flow identifier need not be carried in source packets 201 since source packets are directly associated with a flow by virtue 202 of their packet headers. Note that an application MAY wildcard 203 some of the fields if only a subset of the fields of the tuple 204 (e.g., {Destination IP Address, Destination UDP port} ) is 205 sufficient. 207 3. The FEC Scheme ID that identifies the FEC scheme. 209 4. The length of the Source FEC Payload ID (in bytes). 211 This value MAY be zero indicating that no Explicit Source FEC 212 Payload ID is used by the FEC scheme. However, in the case that 213 the Explicit Source FEC Payload ID is used, then only one FEC 214 scheme MUST be used for this source flow, unless the generic tag 215 is used by all of the FEC schemes protecting this source flow. 217 5. An opaque container for the FEC-Scheme-Specific Information 218 (FSSI). 220 FSSI includes the information that is specific to the FEC scheme used 221 by the CDP. FSSI is used to communicate the information that cannot 222 be adequately represented otherwise and is essential for the proper 223 FEC decoding operation. FSSI is transmitted in a variable-length 224 opaque container that carries an octet string. The FEC schemes 225 define the structure of this octet string, which MAY contain multiple 226 distinct elements. If the FEC scheme does not require any specific 227 information, the FSSI MAY be null. 229 For the fully-specified FEC schemes, a full description of the 230 encoded information MUST be provided. See 231 [I-D.ietf-fecframe-framework] for details. 233 4. FEC Framework Descriptors 235 This section defines the SDP elements that MUST be used to describe 236 the FEC Framework Configuration Information in multimedia sessions by 237 the CDPs that choose SDP [RFC4566] as their session description 238 protocol. Example SDP configurations can be found in Section 5. 240 4.1. Transport Protocol Identifiers 242 This specification defines a class of new transport protocol 243 identifiers for SDP media descriptions. For all existing identifiers 244 , this specification defines the identifier 'fec/'. 245 This identifier MAY be used as the transport protocol identifier in 246 the media descriptions for the source data to indicate that the FEC 247 Source Packet format defined in Section 6.3 of 248 [I-D.ietf-fecframe-framework] is used, where the original transport 249 payload field is formatted according to . However, if the FEC 250 scheme does not use the Explicit Source FEC Payload ID described in 251 Section 6.3 of [I-D.ietf-fecframe-framework], then the original 252 transport protocol identifier MUST be used to support backward 253 compatibility with the receivers that do not support FEC at all. 255 This specification also defines another transport protocol 256 identifier, 'udp/fec', to indicate the FEC Repair Packet format 257 defined in Section 6.4 of [I-D.ietf-fecframe-framework]. 259 4.2. Media Stream Grouping 261 The FEC Framework [I-D.ietf-fecframe-framework] states that multiple 262 instances of the FEC Framework MAY exist at the sender and the 263 receiver(s), and a source flow MAY be protected by multiple FEC 264 Framework instances. Furthermore, within a single FEC Framework 265 instance, multiple source flows MAY be protected by multiple repair 266 flows. However, each repair flow MUST provide protection for a 267 single FEC Framework instance. An example relationship between the 268 source and repair flows is shown in Figure 1. Here, source flows 1 269 and 2 are grouped together and protected by the repair flows 4 and 5; 270 source flow 1 is protected by the repair flow 6; source flows 2 and 3 271 are grouped together and protected by the repair flows 7, 8 and 9. 273 _____| FEC FRAMEWORK 274 / | 4: Repair Flow 275 / | 5: Repair Flow 276 / 277 SOURCE FLOWS / __| FEC FRAMEWORK 278 1: Source Flow |___/ |---' | 6: Repair Flow 279 2: Source Flow | |____ 280 3: Source Flow | \ | FEC FRAMEWORK 281 \ | 7: Repair Flow 282 \_| 8: Repair Flow 283 | 9: Repair Flow 285 Figure 1: Relationship between the source and repair flows 287 The 'group' attribute and the FEC grouping semantics defined in 288 [RFC4756] are used to associate source and repair flows together with 289 the following additional requirement: 291 In the case that the Explicit Source FEC Payload ID is used, then 292 only one FEC Scheme MUST be used for this source flow, unless the 293 generic tag is used by all of the FEC Schemes for the Source FEC 294 Payload ID field, as defined in [I-D.ietf-fecframe-framework]. 296 The 'group' attribute MAY be used to associate multiple repair flows 297 with one or more source flows. This means that the repair flows MAY 298 be used together in an additive manner. 300 To let the receivers know the order which they MUST use the repair 301 flows MAY be communicated by using the parameter 'priority' of the 302 attribute 'fec-repair-flow'. See Section 4.5 for details. 304 4.3. Source IP Addresses 306 The 'source-filter' attribute of SDP ("a=source-filter") as defined 307 in [RFC4570] is used to express the source addresses or fully 308 qualified domain names in the FEC Framework. 310 Editor's note: Additional requirements or exceptions regarding 311 source filters are TBD. 313 4.4. Source Flows 315 The FEC Framework allows that multiple source flows MAY be grouped 316 and protected together by a single or multiple FEC Framework 317 instances. For this reason, as described in Section 3.3, individual 318 source flows MUST be identified with unique identifiers. For this 319 purpose, we introduce the attribute 'fec-source-flow'. 321 The syntax for the new attribute in ABNF [RFC4234] is as follows: 323 fec-source-flow-line = "a=fec-source-flow:" source-id 324 [";" SP tag-length] CRLF 326 source-id = "id=" src-id 327 src-id = 1*DIGIT 329 tag-length = "tag-len=" tlen 330 tlen = *DIGIT 332 The MANDATORY parameter 'id' is used to identify the source flow. 334 The OPTIONAL 'tag-len' parameter is used to specify the length of the 335 Source FEC Payload ID (in bytes) and MUST be used according to the 336 requirements listed in Section 4.2. If no value is specified for the 337 'tag-len' parameter, it indicates a value of zero. 339 4.5. Repair Flows 341 A repair flow MUST contain only repair packets formatted as described 342 in [I-D.ietf-fecframe-framework] for a single FEC Framework instance. 343 In other words, packets belonging to source flows or other repair 344 flows from a different FEC Framework instance MUST NOT be sent within 345 this flow. We introduce the attribute 'fec-repair-flow' to describe 346 the repair flows. 348 The syntax for the new attribute in ABNF is as follows: 350 fec-repair-flow-line = "a=fec-repair-flow:" fec-scheme-id 351 [";" SP flow-priority] [";" SP fec-scheme-specific] CRLF 353 fec-scheme-id = "scheme-id=" sch-id 354 sch-id = 1*DIGIT ; FEC scheme ID 356 flow-priority = "priority=" priority-of-the-flow 357 priority-of-the-flow = *DIGIT 359 fec-scheme-specific = "scheme-specific=" scheme-specific-info 360 scheme-specific-info = *CHAR 362 The MANDATORY parameter 'scheme-id' is used to identify the FEC 363 scheme used to generate this repair flow. These identifiers MUST be 364 registered with IANA by the FEC schemes that use the FEC Framework. 366 The OPTIONAL parameter 'priority' is used to indicate the priorities 367 of the repair flows when multiple repair flows are grouped together 368 to be used in an additive manner within a single FEC Framework 369 instance. The exact usage of the parameter 'priority' and the 370 pertaining rules SHOULD be defined by the FEC scheme or the CDP. If 371 no value is specified for the parameter 'priority', it means that the 372 receiver(s) MAY use the repair flows in any order. 374 The OPTIONAL parameter 'scheme-specific' is an opaque container to 375 convey the FEC-Scheme-Specific Information (FSSI) that includes the 376 information that is specific to the FEC scheme used by the CDP. FSSI 377 is transmitted in a variable-length opaque container that carries an 378 octet string. The FEC schemes define the structure of this octet 379 string, which MAY contain multiple distinct elements. If the FEC 380 scheme does not require any specific information, the FSSI MAY be 381 null. 383 4.6. Minimum Buffer Size 385 An FEC receiver usually needs to buffer source packets before it 386 receives the repair packets and can perform FEC decoding. The amount 387 of this buffer can be determined by the CDP or can be implementation 388 specific. This document specifies a new attribute to describe the 389 amount of buffer size in milliseconds. 391 The syntax for the attribute in ABNF is as follows: 393 min-buffer-size-line = "a=min-buffer-size:" buf-size-in-ms CRLF 394 buf-size-in-ms = 1*DIGIT ; in milliseconds 396 The "a=min-buffer-size" attribute is a media-level attribute since 397 each repair flow MAY have a different buffer requirement. 399 4.7. Bandwidth Specification 401 The bandwidth specification as defined in [RFC4566] denotes the 402 proposed bandwidth to be used by the session or media. The 403 specification of bandwidth is OPTIONAL. 405 In the context of the FEC Framework, the bandwidth specification can 406 be used to express the bandwidth of the repair flows or the bandwidth 407 of the session. If included in the SDP, it SHALL adhere to the 408 following rules: 410 The session-level bandwidth for an FEC Framework instance MAY be 411 specified. In this case, it is RECOMMENDED to use the Transport 412 Independent Application Specific (TIAS) bandwidth modifier [RFC3890] 413 and the 'a=maxprate' attribute for the session. 415 The media-level bandwidth for the individual repair flows MAY also be 416 specified. In this case, it is RECOMMENDED to use the TIAS bandwidth 417 modifier [RFC3890]. 419 The Application Specific (AS) bandwidth modifier [RFC4566] MAY be 420 used instead of TIAS, however, this is NOT RECOMMENDED since TIAS 421 allows the calculation of the bitrate according to the IP version and 422 transport protocol, whereas AS does not. Thus, in TIAS-based bitrate 423 calculations, the packet size SHALL include all headers and payload, 424 excluding the IP and UDP headers. In AS-based bitrate calculations, 425 the packet size SHALL include all headers and payload, plus the IP 426 and UDP headers. 428 For the ABNF syntax information of the TIAS and AS, refer to 429 [RFC3890] and [RFC4566], respectively. 431 5. SDP Examples 433 This section provides SDP examples that can be used by the FEC 434 Framework. 436 Editor's note: We need to fill in SDP examples showing single and 437 multiple FEC Framework instances each using single or multiple repair 438 flows. 440 5.1. Session Announcement Considerations 442 In multicast-based applications, the FEC Framework Configuration 443 Information pertaining to all FEC protection options available at the 444 sender MAY be advertised to the receivers as a part of a session 445 announcement. This way, the sender can let the receivers know all 446 available options for FEC protection. Based on their needs, the 447 receivers MAY choose one or more protections and subscribe to the 448 respective multicast group(s) to receive the repair flow(s). Unless 449 explicitly required by the CDP, the receivers SHOULD NOT send an 450 answer back to the sender specifying their choices. 452 5.2. Offer/Answer Considerations 454 In unicast-based applications, a sender and receiver MAY adopt the 455 Offer/Answer Model [RFC3264] to set the FEC Framework Configuration 456 Information. In this case, the sender offers all available options 457 to the receiver and the receiver answers back to the sender with its 458 choice(s). Note that some FEC protection options MAY be offered to 459 only a particular set of (i.e., premium) receivers. 461 Eligible receivers MAY also use the SDP capability negotiation 462 framework [I-D.ietf-mmusic-sdp-capability-negotiation] to negotiate 463 all or a subset of the FEC Framework parameters. 465 6. Security Considerations 467 For the general security considerations related to SDP, refer to 468 [RFC4566]. For the security considerations related to source/FEC 469 media stream grouping in SDP and use of source address filters in 470 SDP, refer to [RFC4756] and [RFC4570], respectively. 472 7. IANA Considerations 474 7.1. Transport Protocols 476 The 'proto' sub-field of the media description field ("m=") describes 477 the transport protocol used. This document registers the following 478 two values: 480 UDP/FEC 481 DCCP/FEC 483 7.2. Attribute Names 485 As recommended by [RFC4566], the following attribute names should be 486 registered with IANA. 488 The contact information for the registrations is: 490 Ali Begen 491 abegen@cisco.com 493 SDP Attribute ("att-field"): 494 Attribute name: fec-source-flow 495 Long form: Pointer to FEC Source Flow 496 Type of name: att-field 497 Type of attribute: Media level 498 Subject to charset: No 499 Purpose: See this document 500 Reference: This document 501 Values: See this document 503 SDP Attribute ("att-field"): 504 Attribute name: fec-repair-flow 505 Long form: Pointer to FEC Repair Flow 506 Type of name: att-field 507 Type of attribute: Media level 508 Subject to charset: No 509 Purpose: See this document 510 Reference: This document 511 Values: See this document 513 SDP Attribute ("att-field"): 514 Attribute name: min-buffer-size 515 Long form: Minimum Buffer Size in Milliseconds 516 Type of name: att-field 517 Type of attribute: Media level 518 Subject to charset: No 519 Purpose: See this document 520 Reference: This document 521 Values: See this document 523 8. Acknowledgments 525 The author would like to thank the FEC Framework Design Team for 526 their inputs, suggestions and contributions. 528 9. References 529 9.1. Normative References 531 [I-D.ietf-fecframe-framework] 532 Watson, M., "Forward Error Correction (FEC) Framework", 533 draft-ietf-fecframe-framework-00 (work in progress), 534 February 2007. 536 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 537 Description Protocol", RFC 4566, July 2006. 539 [RFC4570] Quinn, B. and R. Finlayson, "Session Description Protocol 540 (SDP) Source Filters", RFC 4570, July 2006. 542 [RFC4756] Li, A., "Forward Error Correction Grouping Semantics in 543 Session Description Protocol", RFC 4756, November 2006. 545 [RFC3890] Westerlund, M., "A Transport Independent Bandwidth 546 Modifier for the Session Description Protocol (SDP)", 547 RFC 3890, September 2004. 549 [RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 550 Specifications: ABNF", RFC 4234, October 2005. 552 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 553 with Session Description Protocol (SDP)", RFC 3264, 554 June 2002. 556 [I-D.ietf-mmusic-sdp-capability-negotiation] 557 Andreasen, F., "SDP Capability Negotiation", 558 draft-ietf-mmusic-sdp-capability-negotiation-07 (work in 559 progress), October 2007. 561 9.2. Informative References 563 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 564 Requirement Levels", BCP 14, RFC 2119, March 1997. 566 Author's Address 568 Ali Begen 569 Cisco Systems 570 170 West Tasman Drive 571 San Jose, CA 95134 572 USA 574 Email: abegen@cisco.com 576 Full Copyright Statement 578 Copyright (C) The IETF Trust (2007). 580 This document is subject to the rights, licenses and restrictions 581 contained in BCP 78, and except as set forth therein, the authors 582 retain all their rights. 584 This document and the information contained herein are provided on an 585 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 586 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 587 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 588 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 589 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 590 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 592 Intellectual Property 594 The IETF takes no position regarding the validity or scope of any 595 Intellectual Property Rights or other rights that might be claimed to 596 pertain to the implementation or use of the technology described in 597 this document or the extent to which any license under such rights 598 might or might not be available; nor does it represent that it has 599 made any independent effort to identify any such rights. Information 600 on the procedures with respect to rights in RFC documents can be 601 found in BCP 78 and BCP 79. 603 Copies of IPR disclosures made to the IETF Secretariat and any 604 assurances of licenses to be made available, or the result of an 605 attempt made to obtain a general license or permission for the use of 606 such proprietary rights by implementers or users of this 607 specification can be obtained from the IETF on-line IPR repository at 608 http://www.ietf.org/ipr. 610 The IETF invites any interested party to bring to its attention any 611 copyrights, patents or patent applications, or other proprietary 612 rights that may cover technology that may be required to implement 613 this standard. Please address the information to the IETF at 614 ietf-ipr@ietf.org. 616 Acknowledgment 618 Funding for the RFC Editor function is provided by the IETF 619 Administrative Support Activity (IASA).