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