idnits 2.17.1 draft-ietf-mmusic-rfc4756bis-10.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 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 (June 9, 2010) is 5067 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 542, but not defined ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) == Outdated reference: A later version (-15) exists of draft-ietf-fecframe-framework-08 -- 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 June 9, 2010 5 (if approved) 6 Intended status: Standards Track 7 Expires: December 11, 2010 9 Forward Error Correction Grouping Semantics in Session Description 10 Protocol 11 draft-ietf-mmusic-rfc4756bis-10 13 Abstract 15 This document defines the semantics for grouping the associated 16 source and Forward Error Correction (FEC)-based repair flows in the 17 Session Description Protocol (SDP). The semantics defined in this 18 document are to be used with the SDP Grouping Framework (RFC 19 3388bis). These semantics allow the description of grouping 20 relationships between the source and repair flows when one or more 21 source and/or repair flow are associated in the same group, and they 22 provide support for additive repair flows. Synchronization Source 23 (SSRC)-level grouping semantics are also defined in this document for 24 Real-time Transport Protocol (RTP) streams using SSRC multiplexing. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on December 11, 2010. 43 Copyright Notice 45 Copyright (c) 2010 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 5 62 3. Requirements and Changes from RFC 4756 . . . . . . . . . . . . 5 63 3.1. FEC Grouping Requirements . . . . . . . . . . . . . . . . 5 64 3.2. Source and Repair Flow Associations . . . . . . . . . . . 6 65 3.3. Support for Additivity . . . . . . . . . . . . . . . . . . 6 66 4. FEC Grouping . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 4.1. "FEC-FR" Grouping Semantics . . . . . . . . . . . . . . . 7 68 4.2. SDP Example . . . . . . . . . . . . . . . . . . . . . . . 7 69 4.3. FEC Grouping for SSRC-Multiplexed RTP Streams . . . . . . 9 70 4.4. "FEC" Grouping Semantics . . . . . . . . . . . . . . . . . 10 71 4.5. SDP Offer/Answer Model and RFC 4756 72 Backward-Compatibility Considerations . . . . . . . . . . 11 73 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 74 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 75 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 76 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 77 8.1. Normative References . . . . . . . . . . . . . . . . . . . 13 78 8.2. Informative References . . . . . . . . . . . . . . . . . . 14 79 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 81 1. Introduction 83 Any application that needs a reliable transmission over an unreliable 84 packet network has to cope with packet losses. Forward Error 85 Correction (FEC) is an effective approach that improves the 86 reliability of the transmission particularly in multicast and 87 broadcast applications where the feedback from the receiver(s) is 88 potentially limited. 90 In a nutshell, FEC groups source packets into blocks and applies 91 protection to generate a desired number of repair packets. These 92 repair packets may be sent on demand or independently of any receiver 93 feedback. The choice depends on the FEC scheme, the packet loss 94 characteristics of the underlying network, the transport scheme 95 (e.g., unicast, multicast and broadcast) and the application. At the 96 receiver side, lost packets can be recovered by erasure decoding 97 provided that a sufficient number of source and repair packets have 98 been received. 100 For example, one of the most basic FEC schemes is the parity codes, 101 where an exclusive OR (XOR) operation is applied to a group of 102 packets (i.e., source block) to generate a single repair packet. At 103 the receiver side, this scheme provides a full recovery if only one 104 packet is lost within the source block and the repair packet is 105 received. There are various other ways of generating repair packets, 106 possibly with different loss-recovery capabilities. 108 The FEC Framework [I-D.ietf-fecframe-framework] outlines a general 109 framework for using FEC codes in multimedia applications that stream 110 audio, video or other types of multimedia content. The FEC Framework 111 specification states that source and repair packets must be carried 112 in different streams, which are referred to as the source and repair 113 flows, respectively. At the receiver side, the receivers should know 114 which flows are the source flows and which ones are the repair flows. 115 The receivers should also know the exact association of the source 116 and repair flows so that they can use the correct data to repair the 117 original content in case there is a packet loss. SDP [RFC4566] uses 118 [I-D.ietf-mmusic-rfc3388bis] and this RFC for this purpose. 120 In order to provide applications more flexibility, the FEC Framework 121 [I-D.ietf-fecframe-framework] allows a source flow to be protected by 122 multiple FEC schemes, each of which requires an instance of the FEC 123 Framework. Thus, multiple instances of the FEC Framework may exist 124 at the sender and the receiver(s). Furthermore, within a single FEC 125 Framework instance, multiple source flows may be grouped and 126 protected by one or more repair flows. 128 The FEC Framework requires the source and repair packets to be 129 carried in different streams. When Real-time Transport Protocol 130 (RTP) [RFC3550] is used to carry the source and repair streams, the 131 FEC Framework recommends that each stream is carried in its own RTP 132 session. This provides flexibility in using FEC in a backward- 133 compatible manner. However, in some scenarios, a single RTP session 134 may be desired to carry multiple RTP streams via Synchronization 135 Source (SSRC) multiplexing in order to reduce the port usage. For 136 such scenarios, appropriate grouping semantics are also required. 138 A basic example scenario is shown in Figure 1. Here, the source flow 139 S1 is protected by the repair flow R1. Also, the source flows S1 and 140 S2 are grouped and protected together by the repair flow R2. 142 SOURCE FLOWS | FEC FRAMEWORK INSTANCE #1 143 | S1: Source Flow |--------| R1: Repair Flow 144 +---| 145 | | S2: Source Flow 146 | 147 +______________________________| FEC FRAMEWORK INSTANCE #2 148 | R2: Repair Flow 150 Figure 1: Example scenario with two FEC Framework instances where R1 151 protects S1, and R2 protects the group of S1 and S2 153 Grouping source flows before applying FEC protection may allow us to 154 achieve a better coding performance. As a typical scenario, suppose 155 that source flows S1 and S2 in Figure 1 correspond to the base and 156 enhancement layers in a layered video content, respectively. The 157 repair flow R2 protects the combination of the base and enhancement 158 layers for the receivers that receive both layers, whereas the repair 159 flow R1 protects the base layer only, for the receivers that want the 160 base layer only, or receive both layers but prefer FEC protection for 161 the base layer only due to a bandwidth or any other limitation. 163 The grouping semantics defined in this document offer the flexibility 164 to determine how source streams are grouped together prior to 165 applying FEC protection. However, not all FEC schemes may support 166 the full range of the possible scenarios (e.g., when the source 167 streams carry different top-level media types such as audio and 168 video). 170 Using multiple FEC Framework instances for a single source flow 171 provides flexibility to the receivers. An example scenario is 172 sketched in Figure 2. Different instances may offer repair flows 173 that are generated by different FEC schemes, and receivers choose to 174 receive the appropriate repair flow(s) that they can support and 175 decode. Alternatively, different instances (whether they use the 176 same FEC scheme or not) may use larger and smaller source block 177 sizes, which accommodate the receivers that have looser and tighter 178 latency requirements, respectively. In addition, different instances 179 may also provide FEC protection at different redundancy levels. This 180 is particularly useful in multicast scenarios where different 181 receivers may experience different packet loss rates and each 182 receiver can choose the repair flow that is tailored to its needs. 184 SOURCE FLOWS | FEC FRAMEWORK INSTANCE #1 185 S3: Source Flow |---------| R3: Repair Flow 186 | 187 |---------| FEC FRAMEWORK INSTANCE #2 188 | R4: Repair Flow 190 Figure 2: Example scenario with two FEC Framework instances, each 191 with a single repair flow protecting the same source flow S3 193 2. Requirements Notation 195 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 196 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 197 document are to be interpreted as described in [RFC2119]. 199 3. Requirements and Changes from RFC 4756 201 3.1. FEC Grouping Requirements 203 As illustrated in the introduction and based on the FEC Framework 204 [I-D.ietf-fecframe-framework], the SDP grouping semantics for FEC 205 must support the ability to indicate that: 207 1. A given source flow is protected by multiple different FEC 208 schemes. 210 2. Multiple repair flows are associated with a given FEC scheme. 212 3. Multiple source flows are grouped prior to applying FEC 213 protection. 215 4. One or more repair flow(s) protect a group of source flows. 217 3.2. Source and Repair Flow Associations 219 The FEC grouping semantics defined in this document and the SDP 220 'group' attribute defined in [I-D.ietf-mmusic-rfc3388bis] are used to 221 associate source and repair flows. This document also specifies how 222 the 'group' attribute is used to group multiple repair flows with one 223 or more source flows. 225 Note that [I-D.ietf-mmusic-rfc3388bis] obsoleted [RFC3388] to allow 226 an "m" line identified by its 'mid' attribute to appear in more than 227 one "a=group" line using the same semantics. With this change and 228 the definitions contained in this document the FEC grouping 229 semantics, a sender can indicate the specific associations between 230 the source and repair flows, and a receiver can determine which 231 repair flow(s) protect which source flow(s). 233 This document defines the FEC grouping semantics and obsoletes 234 [RFC4756]. Implementations compliant with this document MUST use the 235 semantics introduced in Section 4.1 and Section 4.3. In addition to 236 complying with the requirements defined in Section 4.1 and 237 Section 4.3, implementations are RECOMMENDED to support the "FEC" 238 semantics specified in Section 4.4 for backward compatibility reasons 239 in scenarios described in Section 4.5. 241 3.3. Support for Additivity 243 The FEC Framework [I-D.ietf-fecframe-framework] describes support for 244 additive repair flows. Additivity among the repair flows means that 245 multiple repair flows may be decoded jointly to improve the recovery 246 chances of the missing packets in a single or the same set of source 247 flows. Additive repair flows can be generated by the same FEC scheme 248 or different FEC schemes. 250 For example, in Figure 3, the repair flows R5 and R6 may be additive 251 within the FEC Framework instance #1. Alternatively, all three 252 repair flows R5, R6 and R7 could be additive, too. 254 SOURCE FLOWS | FEC FRAMEWORK INSTANCE #1 255 S4: Source Flow |---------| R5: Repair Flow 256 | | R6: Repair Flow 257 | 258 |---------| FEC FRAMEWORK INSTANCE #2 259 | R7: Repair Flow 261 Figure 3: Example scenario with two FEC Framework instances, where 262 two repair flows in the first instance and a single repair flow in 263 the second instance protect the same source flow S4 265 This document defines the mechanisms to support additive repair flows 266 that were not included in [RFC4756]. 268 4. FEC Grouping 270 4.1. "FEC-FR" Grouping Semantics 272 Each "a=group" line is used to indicate an association relationship 273 between the source and repair flows. The flows included in one 274 "a=group" line are called an FEC Group. If there is more than one 275 repair flow included in an FEC group, they MUST be considered to be 276 additive. Repair flows that are not additive MUST be indicated in 277 separate FEC groups. However, if two (or more) repair flows are 278 additive in an FEC group, it does not necessarily mean that these 279 repair flows will also be additive in any other FEC group. 280 Generally, in order to express multiple relations between the source 281 and repair flows, each source and repair flow MAY appear in more than 282 one FEC group. 284 Using the framework in [I-D.ietf-mmusic-rfc3388bis], this document 285 defines "FEC-FR" as the grouping semantics to indicate support for 286 the FEC Framework features. 288 The "a=group:FEC-FR" semantics MUST be used to associate the source 289 and repair flows except when the source and repair flows are 290 specified in the same media description, i.e., in the same "m" line 291 (See Section 4.3). Note that additivity is not necessarily a 292 transitive relationship. Thus, each set of additive repair flows 293 MUST be stated explicitly in SDP as illustrated in the example below. 295 4.2. SDP Example 297 For the scenario sketched in Figure 1, we need to write the following 298 SDP: 300 v=0 301 o=ali 1122334455 1122334466 IN IP4 fec.example.com 302 s=FEC Grouping Semantics 303 t=0 0 304 a=group:FEC-FR S1 R1 305 a=group:FEC-FR S1 S2 R2 306 m=video 30000 RTP/AVP 100 307 c=IN IP4 233.252.0.1/127 308 a=rtpmap:100 MP2T/90000 309 a=mid:S1 310 m=video 30000 RTP/AVP 101 311 c=IN IP4 233.252.0.2/127 312 a=rtpmap:101 MP2T/90000 313 a=mid:S2 314 m=application 30000 RTP/AVP 110 315 c=IN IP4 233.252.0.3/127 316 a=rtpmap:110 1d-interleaved-parityfec/90000 317 a=fmtp:110 L=5; D=10; repair-window=200000 318 a=mid:R1 319 m=application 30000 RTP/AVP 111 320 c=IN IP4 233.252.0.4/127 321 a=rtpmap:111 1d-interleaved-parityfec/90000 322 a=fmtp:111 L=10; D=10; repair-window=400000 323 a=mid:R2 325 In this example, the source and repair flows are carried in their own 326 RTP sessions and the grouping is achieved through the "a=group: 327 FEC-FR" lines. 329 For the additivity example, let us consider the scenario sketched in 330 Figure 3. Suppose that repair flows R5 and R6 are additive but 331 repair flow R7 is not additive with any of the other repair flows. 332 In this case, we must write 334 a=group:FEC-FR S4 R5 R6 335 a=group:FEC-FR S4 R7 337 If none of the repair flows is additive, we must write 339 a=group:FEC-FR S4 R5 340 a=group:FEC-FR S4 R6 341 a=group:FEC-FR S4 R7 343 4.3. FEC Grouping for SSRC-Multiplexed RTP Streams 345 [RFC5576] defines an SDP media-level attribute, called 'ssrc-group', 346 for grouping the RTP streams that are SSRC multiplexed and carried in 347 the same RTP session. The grouping is based on the Synchronization 348 Source (SSRC) identifiers. Since SSRC-multiplexed RTP streams are 349 defined in the same "m" line, the 'group' attribute cannot be used. 351 This section specifies how FEC is applied to source and repair flows 352 for SSRC-multiplexed streams using the 'ssrc-group' attribute 353 [RFC5576]. Thi section also specifies how the additivity of the 354 repair flows is expressed for the SSRC-multiplexed streams. 356 The semantics of "FEC-FR" for the 'ssrc-group' attribute are the same 357 as the one defined for the 'group' attribute except that the SSRC 358 identifiers are used to designate the FEC grouping associations: 359 a=ssrc-group:FEC-FR *(SP ssrc-id) [RFC5576]. 361 The SSRC identifiers for the RTP streams that are carried in the same 362 RTP session MUST be unique per [RFC3550]. However, the SSRC 363 identifiers are not guaranteed to be unique among different RTP 364 sessions. Thus, the 'ssrc-group' attribute MUST only be used at the 365 media level [RFC5576]. 367 Let us consider the following scenario where there are two source 368 flows (e.g., one video and one audio) and a single repair flow that 369 protects only one of the source flows (e.g., video). Suppose that 370 all these flows are separate RTP streams that are SSRC multiplexed in 371 the same RTP session. 373 SOURCE FLOWS | FEC FRAMEWORK INSTANCE #1 374 S5: Source Flow |--------| R8: Repair Flow 375 S6: Source Flow 377 Figure 4: Example scenario with one FEC Framework instance, where a 378 single repair flow protects only one of the source flows 380 The following SDP describes the scenario sketched in Figure 4. 382 v=0 383 o=ali 1122334455 1122334466 IN IP4 fec.example.com 384 s=FEC Grouping Semantics for SSRC Multiplexing 385 t=0 0 386 m=video 30000 RTP/AVP 100 101 110 387 c=IN IP4 233.252.0.1/127 388 a=rtpmap:100 JPEG/90000 389 a=rtpmap:101 L16/32000/2 390 a=rtpmap:110 1d-interleaved-parityfec/90000 391 a=fmtp:110 L=5; D=10; repair-window=200000 392 a=ssrc:1000 cname:fec@example.com 393 a=ssrc:1010 cname:fec@example.com 394 a=ssrc:2110 cname:fec@example.com 395 a=ssrc-group:FEC-FR 1000 2110 396 a=mid:Group1 398 Note that in actual use, SSRC values, which are random 32-bit 399 numbers, may be much larger than the ones shown in this example. 400 Also note that before receiving an RTP packet for each stream, the 401 receiver cannot know which SSRC identifier is associated with which 402 payload type. 404 The additivity of the repair flows is handled in the same way as 405 described in Section 4.2. In other words, the repair flows that are 406 included in an "a=ssrc-group" line MUST be additive. Repair flows 407 that are not additive MUST be indicated in separate "a=ssrc-group" 408 lines. 410 4.4. "FEC" Grouping Semantics 412 This document deprecates the usage of the "FEC" semantics. Sessions 413 negotiated between two endpoints implementing this specification MUST 414 use the "FEC-FR" semantics and not the "FEC" semantics. Section 4.5 415 details how an implementation supporting this specification detects 416 peers that do not support this specification (based on their SDP 417 answer to the initial offer). When this occurs, the offering 418 implementation SHOULD initiate a new offer using the "FEC" semantics 419 as defined in this section. 421 The "FEC" grouping semantics had been originally introduced in 422 [RFC4756]. The "FEC" semantics used the "a=group" line from 423 [RFC3388] to form an FEC Group to indicate the association 424 relationship between the source and repair flows. 426 In the "FEC" semantics, a source or repair flow can only appear in a 427 single "a=group:FEC" line. Thus, all the source and repair flows 428 that are somehow related to each other have to be listed in the same 429 "a=group:FEC" line. For example, for the scenario sketched in 430 Figure 1, we have to write "a=group:FEC S1 S2 R1 R2" regardless of 431 which repair flows protect which particular source flows. Similarly, 432 for the scenario sketched in Figure 3, we have to write "a=group:FEC 433 S4 R5 R6 R7" regardless of which repair flows are additive. However, 434 the interpretation of these lines would be ambiguous. 436 In certain simple scenarios such as where there is one source flow 437 and one repair flow, these limitations may not be a concern. In 438 Offer/Answer model scenarios, when the "FEC-FR" semantics are not 439 understood by the answerer, the "FEC" semantics can be offered 440 provided that the "FEC" semantics provide an exact association among 441 the source and repair flows and do not create any ambiguity. See 442 Section 4.5 for details. 444 4.5. SDP Offer/Answer Model and RFC 4756 Backward-Compatibility 445 Considerations 447 When offering FEC grouping using SDP in an Offer/Answer model 448 [RFC3264], the following considerations apply. 450 A node that is receiving an offer from a sender may or may not 451 understand line grouping. It is also possible that the node 452 understands line grouping but it does not understand the "FEC-FR" 453 semantics. From the viewpoint of the sender of the offer, these 454 cases are indistinguishable. 456 Implementations are RECOMMENDED to support the "FEC" semantics 457 specified in Section 4.4 for backward compatibility reasons. If the 458 sender of the offer supports the "FEC" semantics, it SHOULD fall back 459 to using the "FEC" semantics when the "FEC-FR" semantics are not 460 understood by the node. 462 When a node is offered a session with the "FEC-FR" grouping semantics 463 but it does not support line grouping or the FEC grouping semantics, 464 as per [I-D.ietf-mmusic-rfc3388bis], the node responds to the offer 465 either: 467 o With an answer that ignores the grouping attribute. 469 In this case, if the original sender of the offer 471 * does support the "FEC" semantics described in Section 4.4, it 472 MUST first check whether using the "FEC" semantics will create 473 any ambiguity or not. If using the "FEC" semantics still 474 provides an exact association among the source and repair 475 flows, the sender SHOULD send a new offer using the "FEC" 476 semantics. However, if an exact association cannot be 477 described, it MUST send a new offer without FEC. 479 * does not support the "FEC" semantics described in Section 4.4, 480 it MUST send a new offer without FEC. 482 o With a refusal to the request (e.g., 488 Not Acceptable Here or 483 606 Not Acceptable in SIP). 485 In this case, if the original sender of the offer 487 * does support the "FEC" semantics and still wish to establish 488 the session, it MUST first check whether using the "FEC" 489 semantics will create any ambiguity or not. If using the "FEC" 490 semantics still provides an exact association among the source 491 and repair flows, the sender SHOULD send a new offer using the 492 "FEC" semantics. However, if an exact association cannot be 493 described, it SHOULD send a new offer without FEC. 495 * does not support the "FEC" semantics described in Section 4.4, 496 it SHOULD send a new offer without FEC. 498 In both cases described above, when the sender of the offer sends a 499 new offer with the "FEC" semantics, and the node understands it, the 500 session will be established and the rules pertaining to the "FEC" 501 semantics will apply. 503 As specified in [I-D.ietf-mmusic-rfc3388bis], if the node does not 504 understand the "FEC" semantics, it responds to the offer, either (1) 505 with an answer that ignores the grouping attribute, or (2) with a 506 refusal to the request. In the first case, the sender must send a 507 new offer without FEC. In the second case, if the sender still 508 wishes to establish the session, it should retry the request with an 509 offer without FEC. 511 5. Security Considerations 513 There is a weak threat for the receiver that the FEC grouping can be 514 modified to indicate FEC relationships that do not exist. Such 515 attacks may result in failure of FEC to protect, and/or mishandle 516 other media payload streams. The receiver SHOULD do an integrity 517 check on SDP and follow the security considerations of SDP [RFC4566] 518 to only trust SDP from trusted sources. 520 6. IANA Considerations 522 This document registers the following semantics with IANA in 523 Semantics for the 'group' SDP Attribute under SDP Parameters: 525 Note to the RFC Editor: In the following registrations, please 526 replace "XXXX" with the number of this document prior to publication 527 as an RFC. 529 Note to IANA: Please note the change in the reference for the "FEC" 530 semantics. 532 Semantics Token Reference 533 --------------------------- ------ --------- 534 Forward Error Correction (Deprecated) FEC [RFCXXXX] 535 Forward Error Correction FR FEC-FR [RFCXXXX] 537 This document also registers the following semantics with IANA in 538 Semantics for the 'ssrc-group' SDP Attribute under SDP Parameters: 540 Semantics Token Reference 541 --------------------------- ------ --------- 542 Forward Error Correction FR FEC-FR [RFCXXXX] 544 7. Acknowledgments 546 Some parts of this document are based on [RFC4756]. Thus, the author 547 would like to thank those who contributed to [RFC4756]. Also, thanks 548 to Jonathan Lennox who has contributed to Section 4.3 and Jean- 549 Francois Mule who has reviewed this document in great detail and 550 suggested text edits. 552 8. References 554 8.1. Normative References 556 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 557 Requirement Levels", BCP 14, RFC 2119, March 1997. 559 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 560 Description Protocol", RFC 4566, July 2006. 562 [I-D.ietf-mmusic-rfc3388bis] 563 Camarillo, G. and H. Schulzrinne, "The SDP (Session 564 Description Protocol) Grouping Framework", 565 draft-ietf-mmusic-rfc3388bis-04 (work in progress), 566 November 2009. 568 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 569 with Session Description Protocol (SDP)", RFC 3264, 570 June 2002. 572 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 573 Jacobson, "RTP: A Transport Protocol for Real-Time 574 Applications", STD 64, RFC 3550, July 2003. 576 [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific 577 Media Attributes in the Session Description Protocol 578 (SDP)", RFC 5576, June 2009. 580 8.2. Informative References 582 [I-D.ietf-fecframe-framework] 583 Watson, M., "Forward Error Correction (FEC) Framework", 584 draft-ietf-fecframe-framework-08 (work in progress), 585 June 2010. 587 [RFC3388] Camarillo, G., Eriksson, G., Holler, J., and H. 588 Schulzrinne, "Grouping of Media Lines in the Session 589 Description Protocol (SDP)", RFC 3388, December 2002. 591 [RFC4756] Li, A., "Forward Error Correction Grouping Semantics in 592 Session Description Protocol", RFC 4756, November 2006. 594 Author's Address 596 Ali Begen 597 Cisco 598 181 Bay Street 599 Toronto, ON M5J 2T3 600 CANADA 602 Email: abegen@cisco.com