idnits 2.17.1 draft-ietf-mmusic-rfc4756bis-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC4756, but the abstract doesn't seem to directly say this. It does mention RFC4756 though, so this could be OK. -- The draft header indicates that this document updates RFC3388bis, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC4756, updated by this document, for RFC5378 checks: 2005-10-25) -- 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 11, 2010) is 5188 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFCXXXX' is mentioned on line 505, but not defined ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) == Outdated reference: A later version (-15) exists of draft-ietf-fecframe-framework-05 -- Obsolete informational reference (is this intentional?): RFC 4756 (Obsoleted by RFC 5956) -- Obsolete informational reference (is this intentional?): RFC 3388 (Obsoleted by RFC 5888) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MMUSIC A. Begen 3 Internet-Draft Cisco 4 Updates: 4756, 3388bis, 5576 February 11, 2010 5 (if approved) 6 Intended status: Standards Track 7 Expires: August 15, 2010 9 Forward Error Correction Grouping Semantics in Session Description 10 Protocol 11 draft-ietf-mmusic-rfc4756bis-06 13 Abstract 15 The Session Description Protocol (SDP) supports grouping media lines. 16 SDP also has semantics defined for grouping the associated source and 17 Forward Error Correction (FEC)-based repair flows. However, the 18 semantics that was defined in RFC 4756 generally fail to provide the 19 specific grouping relationships between the source and repair flows 20 when there are more than one source and/or repair flows in the same 21 group. Furthermore, the existing semantics does not support 22 describing additive repair flows. This document addresses these 23 issues by introducing new FEC grouping semantics. SSRC-level 24 grouping semantics is also introduced in this document for Real-time 25 Transport Protocol (RTP) streams using SSRC multiplexing. 27 Status of this Memo 29 This Internet-Draft is submitted to IETF in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF), its areas, and its working groups. Note that 34 other groups may also distribute working documents as Internet- 35 Drafts. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 The list of current Internet-Drafts can be accessed at 43 http://www.ietf.org/ietf/1id-abstracts.txt. 45 The list of Internet-Draft Shadow Directories can be accessed at 46 http://www.ietf.org/shadow.html. 48 This Internet-Draft will expire on August 15, 2010. 50 Copyright Notice 52 Copyright (c) 2010 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 5 69 3. Requirements and Changes from RFC 4756 . . . . . . . . . . . . 5 70 3.1. Source and Repair Flow Association . . . . . . . . . . . . 5 71 3.2. Support for Additivity . . . . . . . . . . . . . . . . . . 6 72 4. FEC Grouping . . . . . . . . . . . . . . . . . . . . . . . . . 6 73 4.1. New Grouping Semantics . . . . . . . . . . . . . . . . . . 6 74 4.2. SDP Example . . . . . . . . . . . . . . . . . . . . . . . 7 75 4.3. Grouping for SSRC-Multiplexed RTP Streams . . . . . . . . 8 76 4.4. SDP Offer-Answer Model and Backward Compatibility 77 Considerations . . . . . . . . . . . . . . . . . . . . . . 10 78 4.5. ABNF Syntax . . . . . . . . . . . . . . . . . . . . . . . 11 79 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 80 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 81 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 82 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 83 8.1. Normative References . . . . . . . . . . . . . . . . . . . 13 84 8.2. Informative References . . . . . . . . . . . . . . . . . . 13 85 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 87 1. Introduction 89 Any application that needs a reliable transmission over an unreliable 90 packet network has to cope with packet losses. Forward Error 91 Correction (FEC) is an effective approach that provides reliable 92 transmission particularly in multicast and broadcast applications 93 where the feedback from the receiver(s) is potentially limited. 95 In a nutshell, FEC groups source packets into blocks and applies 96 protection to generate a desired number of repair packets. These 97 repair packets may be sent on demand or independently of any receiver 98 feedback. The choice depends on the FEC scheme, the packet loss 99 characteristics of the underlying network, the transport scheme 100 (e.g., unicast, multicast and broadcast) and the application. At the 101 receiver side, lost packets can be recovered by erasure decoding 102 provided that a sufficient number of source and repair packets have 103 been received. 105 For example, one of the most basic FEC schemes is the parity codes, 106 where an exclusive OR (XOR) operation is applied to a group of 107 packets (i.e., source block) to generate a single repair packet. At 108 the receiver side, this scheme provides a full recovery if only one 109 packet is lost within the source block and the repair packet is 110 received. There are various other ways of generating repair packets, 111 possibly with different loss-recovery capabilities. 113 The FEC Framework [I-D.ietf-fecframe-framework] outlines a general 114 framework for using FEC codes in multimedia applications that stream 115 audio, video or other types of multimedia content. The FEC Framework 116 specification states that source and repair packets must be carried 117 in different streams, which are referred to as the source and repair 118 flows, respectively. At the receiver side, the receivers should know 119 which flows are the source flows and which flows are the repair 120 flows. The receivers should also know the exact association of the 121 source and repair flows so that they can use the correct data to 122 repair the original content in case there is a packet loss. 123 Currently, SDP [RFC4566] uses [RFC3388] and [RFC4756] for this 124 purpose. 126 In order to provide applications more flexibility, the FEC Framework 127 [I-D.ietf-fecframe-framework] allows a source flow to be protected by 128 multiple FEC schemes, each of which requires an instance of the FEC 129 Framework. Thus, multiple instances of the FEC Framework may exist 130 at the sender and the receiver(s). Furthermore, within a single FEC 131 Framework instance, multiple source flows may be grouped and 132 protected by one or more repair flows. 134 It should be noted that the FEC Framework requires the source and 135 repair packets to be carried in different streams. When Real-time 136 Transport Protocol (RTP) [RFC3550] is used to carry the source and 137 repair streams, the FEC Framework recommends that each stream is 138 carried in its own RTP session. This provides flexibility in using 139 FEC in a backward-compatible manner. However, in some scenarios, a 140 single RTP session may be desired to carry multiple RTP streams via 141 SSRC multiplexing in order to reduce the port usage. For such 142 scenarios, an appropriate grouping semantics is also required. 144 A basic example scenario is shown in Figure 1. Here, source flow S1 145 is protected by repair flow R1. Also, source flows S1 and S2 are 146 grouped and protected together by repair flow R2. 148 SOURCE FLOWS | FEC FRAMEWORK INSTANCE #1 149 | S1: Source Flow |--------| R1: Repair Flow 150 +---| 151 | | S2: Source Flow 152 | 153 +______________________________| FEC FRAMEWORK INSTANCE #2 154 | R2: Repair Flow 156 Figure 1: Example scenario with two FEC Framework instances where R1 157 protects S1, and R2 protects the group of S1 and S2 159 Grouping source flows before applying FEC protection may allow us to 160 achieve a better coding performance. As a typical scenario, suppose 161 that source flows S1 and S2 in Figure 1 correspond to the base and 162 enhancement layers in a layered video content, respectively. Repair 163 flow R2 protects the combination of the base and enhancement layers 164 for the receivers who receive both layers, and repair flow R1 165 protects the base layer only, for the receivers who want the base 166 layer only, or who receive both layers but prefer FEC protection for 167 the base layer only due to a bandwidth and/or any other limitation. 169 It should be noted that the grouping semantics defined in this 170 document offers the flexibility to determine how source streams are 171 grouped together prior to applying FEC protection. However, not all 172 FEC schemes support the full range of the possible scenarios (e.g., 173 when the source streams carry different top-level media types such as 174 audio and video). 176 Using multiple FEC Framework instances for a single source flow 177 provides flexibility to the receivers. An example scenario is 178 sketched in Figure 2. Different instances may offer repair flows 179 that are generated by different FEC schemes, and receivers choose 180 receiving the appropriate repair flow(s) that they can support and 181 decode. Alternatively, different instances (whether they use the 182 same FEC scheme or not) may use larger and smaller source block 183 sizes, which accommodate the receivers that have looser and tighter 184 latency requirements, respectively. In addition, different instances 185 may also provide FEC protection at different redundancy levels. This 186 is particularly useful in multicast scenarios where different 187 receivers may experience different packet loss rates and each 188 receiver can choose the repair flow that is tailored to its needs. 190 SOURCE FLOWS | FEC FRAMEWORK INSTANCE #1 191 S3: Source Flow |---------| R3: Repair Flow 192 | 193 |---------| FEC FRAMEWORK INSTANCE #2 194 | R4: Repair Flow 196 Figure 2: Example scenario with two FEC Framework instances, each 197 with a single repair flow protecting the same source flow S3 199 In summary, based on the FEC Framework [I-D.ietf-fecframe-framework], 200 the SDP grouping semantics for FEC must support the ability to 201 indicate that: 203 1. A given source flow is protected by multiple different FEC 204 schemes. 206 2. Multiple repair flows are associated with a given FEC scheme. 208 3. Multiple source flows are grouped prior to applying FEC 209 protection. 211 4. One or more repair flows protect a group of source flows. 213 2. Requirements Notation 215 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 216 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 217 document are to be interpreted as described in [RFC2119]. 219 3. Requirements and Changes from RFC 4756 221 3.1. Source and Repair Flow Association 223 The FEC grouping semantics and 'group' attribute defined in this 224 document and [I-D.ietf-mmusic-rfc3388bis], respectively, are used to 225 associate source and repair flows together. This document also 226 specifies how the 'group' attribute in SDP is used to group multiple 227 repair flows with one or more source flows. 229 [I-D.ietf-mmusic-rfc3388bis] updates [RFC3388] to allow an "m" line 230 identified by its 'mid' attribute to appear in more than one 231 "a=group" line using the same semantics. With this change and other 232 required changes in the grouping semantics for FEC, a sender is 233 allowed to indicate the specific associations between the source and 234 repair flows, and a receiver can determine which repair flow(s) 235 protect which source flow(s). 237 This document introduces the changes required in the FEC grouping 238 semantics and updates [RFC4756]. New implementations SHOULD use the 239 new semantics introduced in this document whenever possible, but they 240 may need to use [RFC4756] semantics when backward compatibility is 241 desired, as described in Section 4.4. 243 3.2. Support for Additivity 245 The FEC Framework also supports additive repair flows. Additivity 246 among the repair flows means that multiple repair flows may be 247 decoded jointly to improve the recovery chances of the missing 248 packets in a single or the same set of source flows. Additive repair 249 flows can be generated by the same FEC scheme or different FEC 250 schemes. 252 For example, in Figure 3, repair flows R5 and R6 may be additive 253 within the FEC Framework instance #1. Alternatively, all three 254 repair flows R5, R6 and R7 could be additive, too. 256 SOURCE FLOWS | FEC FRAMEWORK INSTANCE #1 257 S4: Source Flow |---------| R5: Repair Flow 258 | | R6: Repair Flow 259 | 260 |---------| FEC FRAMEWORK INSTANCE #2 261 | R7: Repair Flow 263 Figure 3: Example scenario with two FEC Framework instances, where 264 two repair flows in the first instance and a single repair flow in 265 the second instance protect the same source flow S4 267 4. FEC Grouping 269 4.1. New Grouping Semantics 271 Each "a=group" line is used to indicate an association relationship 272 between the source and repair flows. The flows included in one 273 "a=group" line are called an FEC Group. If there are more than one 274 repair flows included in an FEC group, they MUST be considered to be 275 additive. Repair flows that are not additive MUST be indicated in 276 separate FEC groups. However, if two (or more) repair flows are 277 additive in an FEC group, it does not necessarily mean that these 278 repair flows will also be additive in any other FEC group. 279 Generally, in order to express multiple relations between the source 280 and repair flows, each source and repair flow MAY appear in more than 281 one FEC group. 283 By extending [I-D.ietf-mmusic-rfc3388bis] we define "FEC-FR" as the 284 new grouping semantics that can support the features of the FEC 285 Framework. 287 The "a=group:FEC-FR" semantics MUST always be used to associate the 288 source and repair flows except when the source and repair flows are 289 specified in the same media description, i.e., in the same "m" line. 290 Note that additivity is not necessarily a transitive relation. Thus, 291 each set of additive repair flows MUST be stated explicitly. 293 4.2. SDP Example 295 For the scenario sketched in Figure 1, we need to write the following 296 SDP: 298 v=0 299 o=ali 1122334455 1122334466 IN IP4 fec.example.com 300 s=New FEC Grouping Semantics 301 t=0 0 302 a=group:FEC-FR S1 R1 303 a=group:FEC-FR S1 S2 R2 304 m=video 30000 RTP/AVP 100 305 c=IN IP4 233.252.0.1/127 306 a=rtpmap:100 MP2T/90000 307 a=mid:S1 308 m=video 30000 RTP/AVP 101 309 c=IN IP4 233.252.0.2/127 310 a=rtpmap:101 MP2T/90000 311 a=mid:S2 312 m=application 30000 RTP/AVP 110 313 c=IN IP4 233.252.0.3/127 314 a=rtpmap:110 1d-interleaved-parityfec/90000 315 a=fmtp:110 L=5; D=10; repair-window=200000 316 a=mid:R1 317 m=application 30000 RTP/AVP 111 318 c=IN IP4 233.252.0.4/127 319 a=rtpmap:111 1d-interleaved-parityfec/90000 320 a=fmtp:111 L=10; D=10; repair-window=400000 321 a=mid:R2 323 In this example, the source and repair flows are carried in their own 324 RTP sessions and the grouping is achieved through the "a=group: 325 FEC-FR" lines. 327 For the additivity issues, let us consider the scenario sketched in 328 Figure 3. Suppose that repair flows R5 and R6 are additive but 329 repair flow R7 is not additive with any of the other repair flows. 330 In this case, we must write 332 a=group:FEC-FR S4 R5 R6 333 a=group:FEC-FR S4 R7 335 If none of the repair flows are additive, we must write 337 a=group:FEC-FR S4 R5 338 a=group:FEC-FR S4 R6 339 a=group:FEC-FR S4 R7 341 4.3. Grouping for SSRC-Multiplexed RTP Streams 343 [RFC5576] defines a grouping attribute, called 'ssrc-group', for the 344 RTP streams that are SSRC multiplexed and carried in the same RTP 345 session. The grouping is based on the Synchronization Source (SSRC) 346 identifiers. Since SSRC-multiplexed RTP streams are defined in the 347 same "m" line, the 'group' attribute cannot be used. 349 This document extends [RFC5576] in two ways. First, we define how 350 FEC is applied to source and repair flows for SSRC-multiplexed 351 streams using the 'ssrc-group' attribute. We then specify how the 352 additivity of the repair flows is expressed for the SSRC-multiplexed 353 streams. 355 Per [RFC3550], the SSRC identifiers for the RTP streams that are 356 carried in the same RTP session MUST be unique. However, the SSRC 357 identifiers are not guaranteed to be unique among different RTP 358 sessions. Thus, the 'ssrc-group' attribute MUST only be used at the 359 media level [RFC5576]. The semantics of "FEC-FR" for the 'ssrc- 360 group' attribute is exactly the same as the one defined for the 361 'group' attribute. 363 Let us consider the following scenario where there are two source 364 flows (e.g., one video and one audio) and a single repair flow that 365 protects only one of the source flows (e.g., video). Suppose that 366 all these flows are separate RTP streams that are SSRC multiplexed in 367 the same RTP session. 369 SOURCE FLOWS | FEC FRAMEWORK INSTANCE #1 370 S5: Source Flow |--------| R8: Repair Flow 371 S6: Source Flow 373 Figure 4: Example scenario with one FEC Framework instance, where a 374 single repair flow protects only one of the source flows 376 The following SDP describes the scenario sketched in Figure 4. 378 v=0 379 o=ali 1122334455 1122334466 IN IP4 fec.example.com 380 s=New FEC Grouping Semantics for SSRC Multiplexing 381 t=0 0 382 m=video 30000 RTP/AVP 100 101 110 383 c=IN IP4 233.252.0.1/127 384 a=rtpmap:100 JPEG/90000 385 a=rtpmap:101 L16/32000/2 386 a=rtpmap:110 1d-interleaved-parityfec/90000 387 a=fmtp:110 L=5; D=10; repair-window=200000 388 a=ssrc:1000 cname:fec@example.com 389 a=ssrc:1010 cname:fec@example.com 390 a=ssrc:2110 cname:fec@example.com 391 a=ssrc-group:FEC-FR 1000 2110 392 a=mid:Group1 394 Note that in actual use, SSRC values, which are random 32-bit 395 numbers, may be much larger than the ones shown in this example. 396 Also note that before receiving an RTP packet for each stream, the 397 receiver cannot know which SSRC identifier is associated with which 398 payload type. 400 The additivity of the repair flows is handled in the same way as 401 described in Section 4.2. In other words, the repair flows that are 402 included in an "a=ssrc-group" line MUST be additive. Repair flows 403 that are not additive MUST be indicated in separate "a=ssrc-group" 404 lines. 406 4.4. SDP Offer-Answer Model and Backward Compatibility Considerations 408 When offering FEC grouping using SDP in an Offer/Answer model 409 [RFC3264], the following considerations apply. 411 A node that is receiving an offer from a sender may or may not 412 understand line grouping. It is also possible that the node 413 understands line grouping but it does not understand the "FEC-FR" 414 semantics. From the viewpoint of the sender of the offer, these 415 cases are indistinguishable. 417 When a node is offered a session with the "FEC-FR" grouping semantics 418 but it does not support line grouping or the FEC grouping semantics, 419 the node SHOULD respond to the offer either: 421 o With an answer that ignores the grouping attribute. 423 In this case, the original sender of the offer MUST first check 424 whether using the "FEC" grouping semantics will create any 425 ambiguity or not, while keeping its limitations in mind. If using 426 the "FEC" semantics rather than the "FEC-FR" semantics still 427 provides an exact association among the source and repair flows, 428 the sender of the offer MUST send a new offer using the "FEC" 429 semantics. However, if an exact association cannot be described, 430 the sender MUST send a new offer without FEC. 432 o With a refusal to the request (e.g., 488 Not Acceptable Here or 433 606 Not Acceptable in SIP). 435 In this case, if the sender of the offer still wishes to establish 436 the session, it MUST first check whether using the "FEC" grouping 437 semantics will create any ambiguity or not, while keeping its 438 limitations in mind. If using the "FEC" semantics rather than the 439 "FEC-FR" semantics still provides an exact association among the 440 source and repair flows, the sender of the offer SHOULD send a new 441 offer using the "FEC" semantics. However, if an exact association 442 cannot be described, the sender SHOULD send a new offer without 443 FEC. 445 Note that in both cases described above, when the sender of the offer 446 sends a new offer with the "FEC" semantics, and the node understands 447 it, the session will be established and the rules pertaining to 448 [RFC4756] will apply. 450 However, if the node does not understand the "FEC" semantics, it 451 SHOULD respond to the offer either (1) with an answer that ignores 452 the grouping attribute, or (2) with a refusal to the request. In the 453 first case, the sender MUST send a new offer without FEC. In the 454 second case, if the sender of the offer still wishes to establish the 455 session, it SHOULD retry the request with an offer without FEC. 457 4.5. ABNF Syntax 459 Note to the RFC Editor: In the following, please replace "XXXX" with 460 the number of this document prior to publication as an RFC. 462 A new semantics ("FEC-FR") is defined for the 'group' attribute 463 [I-D.ietf-mmusic-rfc3388bis]. Its formatting in SDP is described by 464 the following ABNF [RFC5234]: 466 group-attribute = "a=group:" semantics 467 *(space identification-tag) 468 semantics = "LS" / "FID" / 469 "FEC" / ; from [RFC4756] for backward 470 ; compatibility 471 "FEC-FR" ; from [RFCXXXX] 473 identification-tag = token 475 The identification tags MUST be unique within an SDP session 476 description. 478 5. Security Considerations 480 There is a weak threat for the receiver that the FEC grouping can be 481 modified to indicate FEC relationships that do not exist. Such 482 attacks may result in failure of FEC to protect, and/or mishandling 483 of other media payload streams. It is RECOMMENDED that the receiver 484 SHOULD do integrity check on SDP and follow the security 485 considerations of SDP [RFC4566] to only trust SDP from trusted 486 sources. 488 6. IANA Considerations 490 This document registers the following semantics with IANA in 491 Semantics for the 'group' SDP Attribute under SDP Parameters: 493 Note to the RFC Editor: In the following, please replace "XXXX" with 494 the number of this document prior to publication as an RFC. 496 Semantics Token Reference 497 --------------------------- ------ --------- 498 Forward Error Correction FR FEC-FR [RFCXXXX] 500 This document also registers the following semantics with IANA in 501 Semantics for the 'ssrc-group' SDP Attribute under SDP Parameters: 503 Semantics Token Reference 504 --------------------------- ------ --------- 505 Forward Error Correction FR FEC-FR [RFCXXXX] 507 7. Acknowledgments 509 Some parts of this document are based on [RFC4756]. Thus, the author 510 would like to thank those who contributed to [RFC4756]. Also, thanks 511 to Jonathan Lennox who has contributed to Section 4.3. 513 8. References 515 8.1. Normative References 517 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 518 Requirement Levels", BCP 14, RFC 2119, March 1997. 520 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 521 Description Protocol", RFC 4566, July 2006. 523 [I-D.ietf-mmusic-rfc3388bis] 524 Camarillo, G. and H. Schulzrinne, "The SDP (Session 525 Description Protocol) Grouping Framework", 526 draft-ietf-mmusic-rfc3388bis-04 (work in progress), 527 November 2009. 529 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 530 with Session Description Protocol (SDP)", RFC 3264, 531 June 2002. 533 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 534 Jacobson, "RTP: A Transport Protocol for Real-Time 535 Applications", STD 64, RFC 3550, July 2003. 537 [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific 538 Media Attributes in the Session Description Protocol 539 (SDP)", RFC 5576, June 2009. 541 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 542 Specifications: ABNF", STD 68, RFC 5234, January 2008. 544 8.2. Informative References 546 [I-D.ietf-fecframe-framework] 547 Watson, M., "Forward Error Correction (FEC) Framework", 548 draft-ietf-fecframe-framework-05 (work in progress), 549 July 2009. 551 [RFC4756] Li, A., "Forward Error Correction Grouping Semantics in 552 Session Description Protocol", RFC 4756, November 2006. 554 [RFC3388] Camarillo, G., Eriksson, G., Holler, J., and H. 555 Schulzrinne, "Grouping of Media Lines in the Session 556 Description Protocol (SDP)", RFC 3388, December 2002. 558 Author's Address 560 Ali Begen 561 Cisco 562 170 West Tasman Drive 563 San Jose, CA 95134 564 USA 566 Email: abegen@cisco.com