idnits 2.17.1 draft-ietf-mmusic-rfc4756bis-08.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 obsoletes RFC4756, but the abstract doesn't seem to directly say this. It does mention RFC4756 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 28, 2010) is 5106 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-07 -- Obsolete informational reference (is this intentional?): RFC 3388 (Obsoleted by RFC 5888) -- Obsolete informational reference (is this intentional?): RFC 4756 (Obsoleted by RFC 5956) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MMUSIC A. Begen 3 Internet-Draft Cisco 4 Obsoletes: 4756 April 28, 2010 5 (if approved) 6 Intended status: Standards Track 7 Expires: October 30, 2010 9 Forward Error Correction Grouping Semantics in Session Description 10 Protocol 11 draft-ietf-mmusic-rfc4756bis-08 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 were defined in RFC 4756 generally fail to provide the 19 specific grouping relationships between the source and repair flows 20 when there is more than one source and/or repair flow in the same 21 group. Furthermore, the existing semantics do not support describing 22 additive repair flows. This document addresses these issues by 23 introducing new FEC grouping semantics. Synchronization Source 24 (SSRC)-level grouping semantics are also introduced in this document 25 for Real-time Transport Protocol (RTP) streams using SSRC 26 multiplexing. 28 Status of this Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on October 30, 2010. 45 Copyright Notice 47 Copyright (c) 2010 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 5 64 3. Requirements and Changes from RFC 4756 . . . . . . . . . . . . 5 65 3.1. Source and Repair Flow Associations . . . . . . . . . . . 5 66 3.2. Support for Additivity . . . . . . . . . . . . . . . . . . 6 67 4. FEC Grouping . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 4.1. Old "FEC" Grouping Semantics . . . . . . . . . . . . . . . 6 69 4.2. New "FEC-FR" Grouping Semantics . . . . . . . . . . . . . 7 70 4.3. SDP Example . . . . . . . . . . . . . . . . . . . . . . . 7 71 4.4. Grouping for SSRC-Multiplexed RTP Streams . . . . . . . . 8 72 4.5. SDP Offer/Answer Model and Backward-Compatibility 73 Considerations . . . . . . . . . . . . . . . . . . . . . . 10 74 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 75 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 76 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 77 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 78 8.1. Normative References . . . . . . . . . . . . . . . . . . . 12 79 8.2. Informative References . . . . . . . . . . . . . . . . . . 13 80 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 82 1. Introduction 84 Any application that needs a reliable transmission over an unreliable 85 packet network has to cope with packet losses. Forward Error 86 Correction (FEC) is an effective approach that improves the 87 reliabilty of the transmission particularly in multicast and 88 broadcast applications where the feedback from the receiver(s) is 89 potentially limited. 91 In a nutshell, FEC groups source packets into blocks and applies 92 protection to generate a desired number of repair packets. These 93 repair packets may be sent on demand or independently of any receiver 94 feedback. The choice depends on the FEC scheme, the packet loss 95 characteristics of the underlying network, the transport scheme 96 (e.g., unicast, multicast and broadcast) and the application. At the 97 receiver side, lost packets can be recovered by erasure decoding 98 provided that a sufficient number of source and repair packets have 99 been received. 101 For example, one of the most basic FEC schemes is the parity codes, 102 where an exclusive OR (XOR) operation is applied to a group of 103 packets (i.e., source block) to generate a single repair packet. At 104 the receiver side, this scheme provides a full recovery if only one 105 packet is lost within the source block and the repair packet is 106 received. There are various other ways of generating repair packets, 107 possibly with different loss-recovery capabilities. 109 The FEC Framework [I-D.ietf-fecframe-framework] outlines a general 110 framework for using FEC codes in multimedia applications that stream 111 audio, video or other types of multimedia content. The FEC Framework 112 specification states that source and repair packets must be carried 113 in different streams, which are referred to as the source and repair 114 flows, respectively. At the receiver side, the receivers should know 115 which flows are the source flows and which flows are the repair 116 flows. The receivers should also know the exact association of the 117 source and repair flows so that they can use the correct data to 118 repair the original content in case there is a packet loss. 119 Currently, SDP [RFC4566] uses [RFC3388] and [RFC4756] for this 120 purpose. 122 In order to provide applications more flexibility, the FEC Framework 123 [I-D.ietf-fecframe-framework] allows a source flow to be protected by 124 multiple FEC schemes, each of which requires an instance of the FEC 125 Framework. Thus, multiple instances of the FEC Framework may exist 126 at the sender and the receiver(s). Furthermore, within a single FEC 127 Framework instance, multiple source flows may be grouped and 128 protected by one or more repair flows. 130 The FEC Framework requires the source and repair packets to be 131 carried in different streams. When Real-time Transport Protocol 132 (RTP) [RFC3550] is used to carry the source and repair streams, the 133 FEC Framework recommends that each stream is carried in its own RTP 134 session. This provides flexibility in using FEC in a backward- 135 compatible manner. However, in some scenarios, a single RTP session 136 may be desired to carry multiple RTP streams via Synchronization 137 Source (SSRC) multiplexing in order to reduce the port usage. For 138 such scenarios, appropriate grouping semantics are also required. 140 A basic example scenario is shown in Figure 1. Here, source flow S1 141 is protected by repair flow R1. Also, source flows S1 and S2 are 142 grouped and protected together by repair flow R2. 144 SOURCE FLOWS | FEC FRAMEWORK INSTANCE #1 145 | S1: Source Flow |--------| R1: Repair Flow 146 +---| 147 | | S2: Source Flow 148 | 149 +______________________________| FEC FRAMEWORK INSTANCE #2 150 | R2: Repair Flow 152 Figure 1: Example scenario with two FEC Framework instances where R1 153 protects S1, and R2 protects the group of S1 and S2 155 Grouping source flows before applying FEC protection may allow us to 156 achieve a better coding performance. As a typical scenario, suppose 157 that source flows S1 and S2 in Figure 1 correspond to the base and 158 enhancement layers in a layered video content, respectively. Repair 159 flow R2 protects the combination of the base and enhancement layers 160 for the receivers who receive both layers, and repair flow R1 161 protects the base layer only, for the receivers who want the base 162 layer only, or who receive both layers but prefer FEC protection for 163 the base layer only due to a bandwidth and/or any other limitation. 165 The grouping semantics defined in this document offer the flexibility 166 to determine how source streams are grouped together prior to 167 applying FEC protection. However, not all FEC schemes may support 168 the full range of the possible scenarios (e.g., when the source 169 streams carry different top-level media types such as audio and 170 video). 172 Using multiple FEC Framework instances for a single source flow 173 provides flexibility to the receivers. An example scenario is 174 sketched in Figure 2. Different instances may offer repair flows 175 that are generated by different FEC schemes, and receivers choose to 176 receive the appropriate repair flow(s) that they can support and 177 decode. Alternatively, different instances (whether they use the 178 same FEC scheme or not) may use larger and smaller source block 179 sizes, which accommodate the receivers that have looser and tighter 180 latency requirements, respectively. In addition, different instances 181 may also provide FEC protection at different redundancy levels. This 182 is particularly useful in multicast scenarios where different 183 receivers may experience different packet loss rates and each 184 receiver can choose the repair flow that is tailored to its needs. 186 SOURCE FLOWS | FEC FRAMEWORK INSTANCE #1 187 S3: Source Flow |---------| R3: Repair Flow 188 | 189 |---------| FEC FRAMEWORK INSTANCE #2 190 | R4: Repair Flow 192 Figure 2: Example scenario with two FEC Framework instances, each 193 with a single repair flow protecting the same source flow S3 195 In summary, based on the FEC Framework [I-D.ietf-fecframe-framework], 196 the SDP grouping semantics for FEC must support the ability to 197 indicate that: 199 1. A given source flow is protected by multiple different FEC 200 schemes. 202 2. Multiple repair flows are associated with a given FEC scheme. 204 3. Multiple source flows are grouped prior to applying FEC 205 protection. 207 4. One or more repair flows protect a group of source flows. 209 2. Requirements Notation 211 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 212 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 213 document are to be interpreted as described in [RFC2119]. 215 3. Requirements and Changes from RFC 4756 217 3.1. Source and Repair Flow Associations 219 The FEC grouping semantics and 'group' attribute defined in this 220 document and [I-D.ietf-mmusic-rfc3388bis], respectively, are used to 221 associate source and repair flows. This document also specifies how 222 the 'group' attribute [I-D.ietf-mmusic-rfc3388bis] in SDP is used to 223 group multiple repair flows with one or more source flows. 225 [I-D.ietf-mmusic-rfc3388bis] obsoletes [RFC3388] to allow an "m" line 226 identified by its 'mid' attribute to appear in more than one 227 "a=group" line using the same semantics. With this change and other 228 required changes in the grouping semantics for FEC, a sender is 229 allowed to indicate the specific associations between the source and 230 repair flows, and a receiver can determine which repair flow(s) 231 protect which source flow(s). 233 This document introduces the changes required in the FEC grouping 234 semantics and obsoletes [RFC4756]. New implementations SHOULD use 235 the new semantics introduced in Section 4.2 and Section 4.4 of this 236 document whenever possible, but they may need to use the obsoleted 237 semantics given in Section 4.1 when backward compatibility is 238 desired, as described in Section 4.5. 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. Old "FEC" Grouping Semantics 268 The old "FEC" grouping semantics had been introduced in [RFC4756], 269 and were based on [RFC3388]. The "FEC" semantics used the "a=group" 270 line to form an FEC Group to indicate the association relationship 271 between the source and repair flows. 273 In the "FEC" semantics, a source or repair flow could only appear in 274 a single "a=group:FEC" line. Thus, all the source and repair flows 275 that are somehow related to each other have to be listed in the same 276 "a=group:FEC" line. For example, for the scenario sketched in 277 Figure 1, we must write "a=group:FEC S1 S2 R1 R2" regardless of which 278 repair flows protect which particular source flows. Similarly, for 279 the scenario sketched in Figure 3, we must write "a=group:FEC S4 R5 280 R6 R7" regardless of which repair flows are additive. 282 In certain simple scenarios such as where there is one source flow or 283 one repair flow, these limitations will not be a concern. In 284 scenarios where using the "FEC" grouping semantics will provide an 285 exact association among the source and repair flows and will not 286 create any ambiguity, the "FEC" semantics can be safely used when 287 backward compatibility is essential. 289 4.2. New "FEC-FR" Grouping Semantics 291 Each "a=group" line is used to indicate an association relationship 292 between the source and repair flows. The flows included in one 293 "a=group" line are called an FEC Group. If there is more than one 294 repair flow included in an FEC group, they MUST be considered to be 295 additive. Repair flows that are not additive MUST be indicated in 296 separate FEC groups. However, if two (or more) repair flows are 297 additive in an FEC group, it does not necessarily mean that these 298 repair flows will also be additive in any other FEC group. 299 Generally, in order to express multiple relations between the source 300 and repair flows, each source and repair flow MAY appear in more than 301 one FEC group. 303 By extending [I-D.ietf-mmusic-rfc3388bis] we define "FEC-FR" as the 304 new grouping semantics that can support the features of the FEC 305 Framework. 307 The "a=group:FEC-FR" semantics MUST always be used to associate the 308 source and repair flows except when the source and repair flows are 309 specified in the same media description, i.e., in the same "m" line. 310 Note that additivity is not necessarily a transitive relationship. 311 Thus, each set of additive repair flows MUST be stated explicitly. 313 4.3. SDP Example 315 For the scenario sketched in Figure 1, we need to write the following 316 SDP: 318 v=0 319 o=ali 1122334455 1122334466 IN IP4 fec.example.com 320 s=New FEC Grouping Semantics 321 t=0 0 322 a=group:FEC-FR S1 R1 323 a=group:FEC-FR S1 S2 R2 324 m=video 30000 RTP/AVP 100 325 c=IN IP4 233.252.0.1/127 326 a=rtpmap:100 MP2T/90000 327 a=mid:S1 328 m=video 30000 RTP/AVP 101 329 c=IN IP4 233.252.0.2/127 330 a=rtpmap:101 MP2T/90000 331 a=mid:S2 332 m=application 30000 RTP/AVP 110 333 c=IN IP4 233.252.0.3/127 334 a=rtpmap:110 1d-interleaved-parityfec/90000 335 a=fmtp:110 L=5; D=10; repair-window=200000 336 a=mid:R1 337 m=application 30000 RTP/AVP 111 338 c=IN IP4 233.252.0.4/127 339 a=rtpmap:111 1d-interleaved-parityfec/90000 340 a=fmtp:111 L=10; D=10; repair-window=400000 341 a=mid:R2 343 In this example, the source and repair flows are carried in their own 344 RTP sessions and the grouping is achieved through the "a=group: 345 FEC-FR" lines. 347 For the additivity issues, let us consider the scenario sketched in 348 Figure 3. Suppose that repair flows R5 and R6 are additive but 349 repair flow R7 is not additive with any of the other repair flows. 350 In this case, we must write 352 a=group:FEC-FR S4 R5 R6 353 a=group:FEC-FR S4 R7 355 If none of the repair flows is additive, we must write 357 a=group:FEC-FR S4 R5 358 a=group:FEC-FR S4 R6 359 a=group:FEC-FR S4 R7 361 4.4. Grouping for SSRC-Multiplexed RTP Streams 363 [RFC5576] defines a grouping attribute, called 'ssrc-group', for the 364 RTP streams that are SSRC multiplexed and carried in the same RTP 365 session. The grouping is based on the Synchronization Source (SSRC) 366 identifiers. Since SSRC-multiplexed RTP streams are defined in the 367 same "m" line, the 'group' attribute cannot be used. 369 This document extends [RFC5576] in two ways. First, we define how 370 FEC is applied to source and repair flows for SSRC-multiplexed 371 streams using the 'ssrc-group' attribute. We then specify how the 372 additivity of the repair flows is expressed for the SSRC-multiplexed 373 streams. 375 Per [RFC3550], the SSRC identifiers for the RTP streams that are 376 carried in the same RTP session MUST be unique. However, the SSRC 377 identifiers are not guaranteed to be unique among different RTP 378 sessions. Thus, the 'ssrc-group' attribute MUST only be used at the 379 media level [RFC5576]. The semantics of "FEC-FR" for the 'ssrc- 380 group' attribute are exactly the same as the one defined for the 381 'group' attribute. 383 Let us consider the following scenario where there are two source 384 flows (e.g., one video and one audio) and a single repair flow that 385 protects only one of the source flows (e.g., video). Suppose that 386 all these flows are separate RTP streams that are SSRC multiplexed in 387 the same RTP session. 389 SOURCE FLOWS | FEC FRAMEWORK INSTANCE #1 390 S5: Source Flow |--------| R8: Repair Flow 391 S6: Source Flow 393 Figure 4: Example scenario with one FEC Framework instance, where a 394 single repair flow protects only one of the source flows 396 The following SDP describes the scenario sketched in Figure 4. 398 v=0 399 o=ali 1122334455 1122334466 IN IP4 fec.example.com 400 s=New FEC Grouping Semantics for SSRC Multiplexing 401 t=0 0 402 m=video 30000 RTP/AVP 100 101 110 403 c=IN IP4 233.252.0.1/127 404 a=rtpmap:100 JPEG/90000 405 a=rtpmap:101 L16/32000/2 406 a=rtpmap:110 1d-interleaved-parityfec/90000 407 a=fmtp:110 L=5; D=10; repair-window=200000 408 a=ssrc:1000 cname:fec@example.com 409 a=ssrc:1010 cname:fec@example.com 410 a=ssrc:2110 cname:fec@example.com 411 a=ssrc-group:FEC-FR 1000 2110 412 a=mid:Group1 414 Note that in actual use, SSRC values, which are random 32-bit 415 numbers, may be much larger than the ones shown in this example. 416 Also note that before receiving an RTP packet for each stream, the 417 receiver cannot know which SSRC identifier is associated with which 418 payload type. 420 The additivity of the repair flows is handled in the same way as 421 described in Section 4.3. In other words, the repair flows that are 422 included in an "a=ssrc-group" line MUST be additive. Repair flows 423 that are not additive MUST be indicated in separate "a=ssrc-group" 424 lines. 426 4.5. SDP Offer/Answer Model and Backward-Compatibility Considerations 428 When offering FEC grouping using SDP in an Offer/Answer model 429 [RFC3264], the following considerations apply. 431 A node that is receiving an offer from a sender may or may not 432 understand line grouping. It is also possible that the node 433 understands line grouping but it does not understand the "FEC-FR" 434 semantics. From the viewpoint of the sender of the offer, these 435 cases are indistinguishable. 437 When a node is offered a session with the "FEC-FR" grouping semantics 438 but it does not support line grouping or the FEC grouping semantics, 439 the node responds to the offer either: 441 o With an answer that ignores the grouping attribute. 443 In this case, the original sender of the offer MUST first check 444 whether using the "FEC" grouping semantics from Section 4.1 will 445 create any ambiguity or not, while keeping its limitations in 446 mind. If using the "FEC" semantics rather than the "FEC-FR" 447 semantics still provides an exact association among the source and 448 repair flows, the sender of the offer MUST send a new offer using 449 the "FEC" semantics. However, if an exact association cannot be 450 described, the sender MUST send a new offer without FEC. 452 o With a refusal to the request (e.g., 488 Not Acceptable Here or 453 606 Not Acceptable in SIP). 455 In this case, if the sender of the offer still wishes to establish 456 the session, it MUST first check whether using the "FEC" grouping 457 semantics from Section 4.1 will create any ambiguity or not, while 458 keeping its limitations in mind. If using the "FEC" semantics 459 rather than the "FEC-FR" semantics still provides an exact 460 association among the source and repair flows, the sender of the 461 offer SHOULD send a new offer using the "FEC" semantics. However, 462 if an exact association cannot be described, the sender SHOULD 463 send a new offer without FEC. 465 This behaviour is as specified in [I-D.ietf-mmusic-rfc3388bis]. Note 466 that in both cases described above, when the sender of the offer 467 sends a new offer with the "FEC" semantics, and the node understands 468 it, the session will be established and the rules pertaining to the 469 "FEC" semantics will apply. 471 If the node does not understand the "FEC" semantics, it responds to 472 the offer, as specified in [I-D.ietf-mmusic-rfc3388bis], either (1) 473 with an answer that ignores the grouping attribute, or (2) with a 474 refusal to the request. In the first case, the sender MUST send a 475 new offer without FEC. In the second case, if the sender of the 476 offer still wishes to establish the session, it SHOULD retry the 477 request with an offer without FEC. 479 5. Security Considerations 481 There is a weak threat for the receiver that the FEC grouping can be 482 modified to indicate FEC relationships that do not exist. Such 483 attacks may result in failure of FEC to protect, and/or mishandle 484 other media payload streams. The receiver SHOULD do an integrity 485 check on SDP and follow the security considerations of SDP [RFC4566] 486 to only trust SDP from trusted 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.4. 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 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 [RFC3388] Camarillo, G., Eriksson, G., Holler, J., and H. 549 Schulzrinne, "Grouping of Media Lines in the Session 550 Description Protocol (SDP)", RFC 3388, December 2002. 552 [RFC4756] Li, A., "Forward Error Correction Grouping Semantics in 553 Session Description Protocol", RFC 4756, November 2006. 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