idnits 2.17.1 draft-ietf-mmusic-rfc4756bis-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 (April 2, 2010) is 5138 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 (-15) exists of draft-ietf-fecframe-framework-07 -- 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: 1 error (**), 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 April 2, 2010 5 (if approved) 6 Intended status: Standards Track 7 Expires: October 4, 2010 9 Forward Error Correction Grouping Semantics in Session Description 10 Protocol 11 draft-ietf-mmusic-rfc4756bis-07 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 Note to the RFC Editor: In the "Updates" line above, please replace 28 that with the RFC number for draft-ietf-mmusic-rfc3388bis-04 when 29 that draft is published as an RFC . 31 Status of this Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on October 4, 2010. 48 Copyright Notice 49 Copyright (c) 2010 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 5 66 3. Requirements and Changes from RFC 4756 . . . . . . . . . . . . 5 67 3.1. Source and Repair Flow Association . . . . . . . . . . . . 5 68 3.2. Support for Additivity . . . . . . . . . . . . . . . . . . 6 69 4. FEC Grouping . . . . . . . . . . . . . . . . . . . . . . . . . 6 70 4.1. New Grouping Semantics . . . . . . . . . . . . . . . . . . 6 71 4.2. SDP Example . . . . . . . . . . . . . . . . . . . . . . . 7 72 4.3. Grouping for SSRC-Multiplexed RTP Streams . . . . . . . . 8 73 4.4. SDP Offer-Answer Model and Backward Compatibility 74 Considerations . . . . . . . . . . . . . . . . . . . . . . 10 75 4.5. ABNF Syntax . . . . . . . . . . . . . . . . . . . . . . . 11 76 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 77 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 78 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 79 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 80 8.1. Normative References . . . . . . . . . . . . . . . . . . . 13 81 8.2. Informative References . . . . . . . . . . . . . . . . . . 13 82 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 84 1. Introduction 86 Any application that needs a reliable transmission over an unreliable 87 packet network has to cope with packet losses. Forward Error 88 Correction (FEC) is an effective approach that provides reliable 89 transmission particularly in multicast and broadcast applications 90 where the feedback from the receiver(s) is potentially limited. 92 In a nutshell, FEC groups source packets into blocks and applies 93 protection to generate a desired number of repair packets. These 94 repair packets may be sent on demand or independently of any receiver 95 feedback. The choice depends on the FEC scheme, the packet loss 96 characteristics of the underlying network, the transport scheme 97 (e.g., unicast, multicast and broadcast) and the application. At the 98 receiver side, lost packets can be recovered by erasure decoding 99 provided that a sufficient number of source and repair packets have 100 been received. 102 For example, one of the most basic FEC schemes is the parity codes, 103 where an exclusive OR (XOR) operation is applied to a group of 104 packets (i.e., source block) to generate a single repair packet. At 105 the receiver side, this scheme provides a full recovery if only one 106 packet is lost within the source block and the repair packet is 107 received. There are various other ways of generating repair packets, 108 possibly with different loss-recovery capabilities. 110 The FEC Framework [I-D.ietf-fecframe-framework] outlines a general 111 framework for using FEC codes in multimedia applications that stream 112 audio, video or other types of multimedia content. The FEC Framework 113 specification states that source and repair packets must be carried 114 in different streams, which are referred to as the source and repair 115 flows, respectively. At the receiver side, the receivers should know 116 which flows are the source flows and which flows are the repair 117 flows. The receivers should also know the exact association of the 118 source and repair flows so that they can use the correct data to 119 repair the original content in case there is a packet loss. 120 Currently, SDP [RFC4566] uses [RFC3388] and [RFC4756] for this 121 purpose. 123 In order to provide applications more flexibility, the FEC Framework 124 [I-D.ietf-fecframe-framework] allows a source flow to be protected by 125 multiple FEC schemes, each of which requires an instance of the FEC 126 Framework. Thus, multiple instances of the FEC Framework may exist 127 at the sender and the receiver(s). Furthermore, within a single FEC 128 Framework instance, multiple source flows may be grouped and 129 protected by one or more repair flows. 131 It should be noted that the FEC Framework requires the source and 132 repair packets to be carried in different streams. When Real-time 133 Transport Protocol (RTP) [RFC3550] is used to carry the source and 134 repair streams, the FEC Framework recommends that each stream is 135 carried in its own RTP session. This provides flexibility in using 136 FEC in a backward-compatible manner. However, in some scenarios, a 137 single RTP session may be desired to carry multiple RTP streams via 138 SSRC multiplexing in order to reduce the port usage. For such 139 scenarios, an appropriate grouping semantics is also required. 141 A basic example scenario is shown in Figure 1. Here, source flow S1 142 is protected by repair flow R1. Also, source flows S1 and S2 are 143 grouped and protected together by repair flow R2. 145 SOURCE FLOWS | FEC FRAMEWORK INSTANCE #1 146 | S1: Source Flow |--------| R1: Repair Flow 147 +---| 148 | | S2: Source Flow 149 | 150 +______________________________| FEC FRAMEWORK INSTANCE #2 151 | R2: Repair Flow 153 Figure 1: Example scenario with two FEC Framework instances where R1 154 protects S1, and R2 protects the group of S1 and S2 156 Grouping source flows before applying FEC protection may allow us to 157 achieve a better coding performance. As a typical scenario, suppose 158 that source flows S1 and S2 in Figure 1 correspond to the base and 159 enhancement layers in a layered video content, respectively. Repair 160 flow R2 protects the combination of the base and enhancement layers 161 for the receivers who receive both layers, and repair flow R1 162 protects the base layer only, for the receivers who want the base 163 layer only, or who receive both layers but prefer FEC protection for 164 the base layer only due to a bandwidth and/or any other limitation. 166 It should be noted that the grouping semantics defined in this 167 document offers the flexibility to determine how source streams are 168 grouped together prior to applying FEC protection. However, not all 169 FEC schemes support the full range of the possible scenarios (e.g., 170 when the source streams carry different top-level media types such as 171 audio and video). 173 Using multiple FEC Framework instances for a single source flow 174 provides flexibility to the receivers. An example scenario is 175 sketched in Figure 2. Different instances may offer repair flows 176 that are generated by different FEC schemes, and receivers choose 177 receiving the appropriate repair flow(s) that they can support and 178 decode. Alternatively, different instances (whether they use the 179 same FEC scheme or not) may use larger and smaller source block 180 sizes, which accommodate the receivers that have looser and tighter 181 latency requirements, respectively. In addition, different instances 182 may also provide FEC protection at different redundancy levels. This 183 is particularly useful in multicast scenarios where different 184 receivers may experience different packet loss rates and each 185 receiver can choose the repair flow that is tailored to its needs. 187 SOURCE FLOWS | FEC FRAMEWORK INSTANCE #1 188 S3: Source Flow |---------| R3: Repair Flow 189 | 190 |---------| FEC FRAMEWORK INSTANCE #2 191 | R4: Repair Flow 193 Figure 2: Example scenario with two FEC Framework instances, each 194 with a single repair flow protecting the same source flow S3 196 In summary, based on the FEC Framework [I-D.ietf-fecframe-framework], 197 the SDP grouping semantics for FEC must support the ability to 198 indicate that: 200 1. A given source flow is protected by multiple different FEC 201 schemes. 203 2. Multiple repair flows are associated with a given FEC scheme. 205 3. Multiple source flows are grouped prior to applying FEC 206 protection. 208 4. One or more repair flows protect a group of source flows. 210 2. Requirements Notation 212 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 213 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 214 document are to be interpreted as described in [RFC2119]. 216 3. Requirements and Changes from RFC 4756 218 3.1. Source and Repair Flow Association 220 The FEC grouping semantics and 'group' attribute defined in this 221 document and [I-D.ietf-mmusic-rfc3388bis], respectively, are used to 222 associate source and repair flows together. This document also 223 specifies how the 'group' attribute in SDP is used to group multiple 224 repair flows with one or more source flows. 226 [I-D.ietf-mmusic-rfc3388bis] updates [RFC3388] to allow an "m" line 227 identified by its 'mid' attribute to appear in more than one 228 "a=group" line using the same semantics. With this change and other 229 required changes in the grouping semantics for FEC, a sender is 230 allowed to indicate the specific associations between the source and 231 repair flows, and a receiver can determine which repair flow(s) 232 protect which source flow(s). 234 This document introduces the changes required in the FEC grouping 235 semantics and updates [RFC4756]. New implementations SHOULD use the 236 new semantics introduced in this document whenever possible, but they 237 may need to use [RFC4756] semantics when backward compatibility is 238 desired, as described in Section 4.4. 240 3.2. Support for Additivity 242 The FEC Framework also supports additive repair flows. Additivity 243 among the repair flows means that multiple repair flows may be 244 decoded jointly to improve the recovery chances of the missing 245 packets in a single or the same set of source flows. Additive repair 246 flows can be generated by the same FEC scheme or different FEC 247 schemes. 249 For example, in Figure 3, repair flows R5 and R6 may be additive 250 within the FEC Framework instance #1. Alternatively, all three 251 repair flows R5, R6 and R7 could be additive, too. 253 SOURCE FLOWS | FEC FRAMEWORK INSTANCE #1 254 S4: Source Flow |---------| R5: Repair Flow 255 | | R6: Repair Flow 256 | 257 |---------| FEC FRAMEWORK INSTANCE #2 258 | R7: Repair Flow 260 Figure 3: Example scenario with two FEC Framework instances, where 261 two repair flows in the first instance and a single repair flow in 262 the second instance protect the same source flow S4 264 4. FEC Grouping 266 4.1. New Grouping Semantics 268 Each "a=group" line is used to indicate an association relationship 269 between the source and repair flows. The flows included in one 270 "a=group" line are called an FEC Group. If there are more than one 271 repair flows included in an FEC group, they MUST be considered to be 272 additive. Repair flows that are not additive MUST be indicated in 273 separate FEC groups. However, if two (or more) repair flows are 274 additive in an FEC group, it does not necessarily mean that these 275 repair flows will also be additive in any other FEC group. 276 Generally, in order to express multiple relations between the source 277 and repair flows, each source and repair flow MAY appear in more than 278 one FEC group. 280 By extending [I-D.ietf-mmusic-rfc3388bis] we define "FEC-FR" as the 281 new grouping semantics that can support the features of the FEC 282 Framework. 284 The "a=group:FEC-FR" semantics MUST always be used to associate the 285 source and repair flows except when the source and repair flows are 286 specified in the same media description, i.e., in the same "m" line. 287 Note that additivity is not necessarily a transitive relation. Thus, 288 each set of additive repair flows MUST be stated explicitly. 290 4.2. SDP Example 292 For the scenario sketched in Figure 1, we need to write the following 293 SDP: 295 v=0 296 o=ali 1122334455 1122334466 IN IP4 fec.example.com 297 s=New FEC Grouping Semantics 298 t=0 0 299 a=group:FEC-FR S1 R1 300 a=group:FEC-FR S1 S2 R2 301 m=video 30000 RTP/AVP 100 302 c=IN IP4 233.252.0.1/127 303 a=rtpmap:100 MP2T/90000 304 a=mid:S1 305 m=video 30000 RTP/AVP 101 306 c=IN IP4 233.252.0.2/127 307 a=rtpmap:101 MP2T/90000 308 a=mid:S2 309 m=application 30000 RTP/AVP 110 310 c=IN IP4 233.252.0.3/127 311 a=rtpmap:110 1d-interleaved-parityfec/90000 312 a=fmtp:110 L=5; D=10; repair-window=200000 313 a=mid:R1 314 m=application 30000 RTP/AVP 111 315 c=IN IP4 233.252.0.4/127 316 a=rtpmap:111 1d-interleaved-parityfec/90000 317 a=fmtp:111 L=10; D=10; repair-window=400000 318 a=mid:R2 320 In this example, the source and repair flows are carried in their own 321 RTP sessions and the grouping is achieved through the "a=group: 322 FEC-FR" lines. 324 For the additivity issues, let us consider the scenario sketched in 325 Figure 3. Suppose that repair flows R5 and R6 are additive but 326 repair flow R7 is not additive with any of the other repair flows. 327 In this case, we must write 329 a=group:FEC-FR S4 R5 R6 330 a=group:FEC-FR S4 R7 332 If none of the repair flows are additive, we must write 334 a=group:FEC-FR S4 R5 335 a=group:FEC-FR S4 R6 336 a=group:FEC-FR S4 R7 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-FR" 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-FR 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-FR" 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-FR" 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-FR" 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-FR" 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 apply. 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-FR") 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-FR" ; 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 FR FEC-FR [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 FR FEC-FR [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. and H. Schulzrinne, "The SDP (Session 522 Description Protocol) Grouping Framework", 523 draft-ietf-mmusic-rfc3388bis-04 (work in progress), 524 November 2009. 526 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 527 with Session Description Protocol (SDP)", RFC 3264, 528 June 2002. 530 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 531 Jacobson, "RTP: A Transport Protocol for Real-Time 532 Applications", STD 64, RFC 3550, July 2003. 534 [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific 535 Media Attributes in the Session Description Protocol 536 (SDP)", RFC 5576, June 2009. 538 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 539 Specifications: ABNF", STD 68, RFC 5234, January 2008. 541 8.2. Informative References 543 [I-D.ietf-fecframe-framework] 544 Watson, M., "Forward Error Correction (FEC) Framework", 545 draft-ietf-fecframe-framework-07 (work in progress), 546 March 2010. 548 [RFC4756] Li, A., "Forward Error Correction Grouping Semantics in 549 Session Description Protocol", RFC 4756, November 2006. 551 [RFC3388] Camarillo, G., Eriksson, G., Holler, J., and H. 552 Schulzrinne, "Grouping of Media Lines in the Session 553 Description Protocol (SDP)", RFC 3388, December 2002. 555 Author's Address 557 Ali Begen 558 Cisco 559 170 West Tasman Drive 560 San Jose, CA 95134 561 USA 563 Email: abegen@cisco.com