idnits 2.17.1 draft-ietf-mmusic-fec-grouping-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 253. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 262. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 269. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 275. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 2 instances of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (December 5, 2005) is 6688 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) ** Obsolete normative reference: RFC 3388 (ref. '2') (Obsoleted by RFC 5888) -- Obsolete informational reference (is this intentional?): RFC 2327 (ref. '3') (Obsoleted by RFC 4566) Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MMUSIC Working Group Adam Li 3 INTERNET-DRAFT HyerVision 4 Expires: June 5, 2006 December 5, 2005 6 FEC Grouping Semantics in SDP 7 9 Status of this memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that other 18 groups may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress". 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/1id-abstracts.html 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html 31 This document is an individual submission to the IETF. Comments 32 should be directed to the authors. 34 Abstract 36 This document defines the semantics that allows for grouping of 37 forward error correction (FEC) streams with the protected payload 38 streams in Session Description Protocol (SDP). The semantics defined 39 in this document is to be used with Grouping of Media Lines in the 40 Session Description Protocol (RFC 3388) to group together "m" lines 41 in the same session. 43 Table of Contents 45 1. Introduction.....................................................2 46 2. Terminology......................................................2 47 3. Forward Error Correction (FEC)...................................2 48 4. FEC Grouping.....................................................3 49 4.1. FEC Group...................................................3 50 4.2. Offer / Answer Consideration................................3 51 4.3. Example of FEC Grouping.....................................4 52 5. Security Consideration...........................................4 53 6. IANA Considerations..............................................5 54 7. Acknowledgments..................................................5 55 8. Author's Address.................................................5 56 9. References.......................................................5 57 9.1. Normative References........................................5 58 9.2. Informative References......................................5 60 1. Introduction 62 The media lines in an SDP [3] session are usually associated with 63 each other. SDP itself does not provide methods to convey the 64 relationships between the media lines. Such relationships are 65 indicated the extension to SDP as defined in Grouping of Media Lines 66 in the Session Description Protocol (RFC 3388) [2]. RFC 3388 defines 67 two types of semantics: Lip Synchronization, and Flow Identification. 69 Forward Error Correction (FEC) is a common technique to achieve 70 robust communication in error-prone environments. In this document, 71 we define the semantics that allows for grouping of FEC streams with 72 the protected payload streams in SDP by further extending RFC 3388. 74 2. Terminology 76 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 77 "SHOULD, "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 78 document are to be interpreted as described in RFC 2119 [1]. 80 3. Forward Error Correction (FEC) 82 Forward Error Correction (FEC) is a common technique to achieve 83 robust communication in error-prone environments. In FEC, 84 communication uses a bandwidth that is more than payload to send 85 redundantly coded payload information. The receivers can readily 86 recover the original payload even when some communication is lost in 87 the transmission. Compare to other error correction technique (such 88 as re-transmission), FEC can achieve much lower transmission delay, 89 and does not have the problem of implosion from retransmission 90 requests in various multicast scenarios. 92 In general, the FEC data can be send in two different ways: (1) 93 multiplexed together with the original payload stream, or (2) as a 94 separate stream. It is thus necessary to define mechanisms to 95 indicate the association relationship between the FEC data and the 96 payload data they protect. 98 When FEC data are multiplexed with the original payload stream, the 99 association relationship is indicated as specified in RTP Payload for 100 Redundant Audio Data (RFC 2198) [4]. As an example, such relationship 101 can be indicated as in the generic RFC payload format for FEC [5]. 103 When FEC data are sent as a separate stream from the payload data, 104 the association relationship can be indicated in various ways. This 105 document on the FEC media line grouping specifies a mechanism for 106 indicating such relationships. 108 4. FEC Grouping 110 4.1. FEC Group 112 Each "a=group" line are used to indicate the association relationship 113 between the FEC streams and the payload stream. The streams included 114 in one "a=group" line are called a "FEC Group". 116 Each FEC group MAY have one or more than one FEC streams, and one or 117 more than one payload streams. For example, it is possible to have 118 one payload streams protected by more than one FEC streams, or 119 multiple payload streams sharing one FEC stream. 121 Grouping streams in a FEC group only indicates the association 122 relationship between streams. The detailed FEC protection 123 scheme/parameters are conveyed through the mechanism of the 124 particular FEC algorithm used. For example, the FEC grouping is used 125 for generic RTP payload for FEC (RFC YYYY) [5] to indicate the 126 association relationship between the FEC stream and the payload 127 stream. The detailed protection level and length information for the 128 ULP algorithm is communicated in band within the FEC stream. 130 4.2. Offer / Answer Consideration 132 The backward compatibility in offer / answer is generally handled as 133 specified in RFC 3388 [2]. 135 Depending on the implementation, a node that does not understand FEC 136 grouping (either does not understand line grouping at all, or just 137 does not understand the FEC semantics) might respond to an offer 138 containing FEC grouping either (1) with an answer which ignores the 139 grouping attribute, or (2) with a refusal to the request (e.g., 488 140 Not acceptable here or 606 Not Acceptable). 142 In the first case, the original sender of the offer MUST establish 143 the connection without FEC. In the second case, if the sender of the 144 offer still wishes to establish the session, it SHOULD re-try the 145 request with an offer without FEC. 147 4.3. Example of FEC Grouping 149 The following example shows a session description of a multicast 150 conference. The first media stream (mid:1) contains the audio stream. 151 The second media stream (mid:2) contains the Generic FEC [5] 152 protection for the audio stream. These two streams form an FEC Group. 153 The relationship between the two streams is indicated by the 154 "a=group:FEC 1 2" line. The FEC stream is sent to the same multicast 155 group and has the same TTL as the audio, but on a port number two 156 higher. Likewise, the video stream (mid:3) and its Generic FEC 157 protection stream (mid:4) forms another FEC group. The relationship 158 between the two streams is indicated by the "a=group:FEC 3 4" line. 159 The FEC stream is sent to a different multicast address, but has the 160 same port number (30004) as the payload video stream. 162 v=0 163 o=adam 289083124 289083124 IN IP4 host.example.com 164 s=ULP FEC Seminar 165 t=0 0 166 c=IN IP4 224.2.17.12/127 167 a=group:FEC 1 2 168 a=group:FEC 3 4 169 m=audio 30000 RTP/AVP 0 170 a=mid:1 171 m=application 30002 RTP/AVP 100 172 a=rtpmap:100 ulpfec/8000 173 a=mid:2 174 m=video 30004 RTP/AVP 31 175 a=mid:3 176 m=application 30004 RTP/AVP 101 177 c=IN IP4 224.2.17.13/127 178 a=rtpmap:101 ulpfec/8000 179 a=mid:4 181 5. Security Consideration 183 There is a weak threat for the receiver that the FEC grouping can be 184 modified to indicate FEC relationships that do not exist. Such 185 attacks may result in failure of FEC protect, and/or mishandling of 186 other media payload streams. It is recommended that the receiver 187 implementation SHOULD do integrity check to thwart such threats. 189 6. IANA Considerations 191 This document defines the semantics to be used with grouping of media 192 lines in SDP as defined in RFC 3388. The semantics defined in this 193 document are to be registered by the IANA when they are published in 194 standard track RFCs. 196 The following semantics need to be registered with IANA. 198 Semantics Token Reference 199 ------------------------ ----- --------- 200 Forward Error Correction FEC RFC XXXX 202 7. Acknowledgments 204 The author would like to thank Magnus Westerlund, Colin Perkins, and 205 Joerg Ott for their feedback on this document. 207 8. Author's Address 209 Adam Li 210 HyerVision 211 10194 Wateridge Circle #152 212 San Diego, CA 92121 213 U.S.A. 214 Tel: +1 858 622 9038 215 Email: adamli@hyervision.com 217 9. References 219 9.1. Normative References 221 [1] S. Bradner, "Key words for use in RFCs to Indicate Requirement 222 Levels", RFC 2119, March 1997. 223 [2] G. Camarillo, J. Holler, and H. Schulzrinne, "Grouping of Media 224 Lines in the Session Description Protocol (SDP)", RFC 3388, 225 December 2002. 227 9.2. Informative References 229 [3] M. Handley, and V. Jacobson, "SDP: Session Description 230 Protocol", RFC 2327, April 1998. 231 [4] C. Perkins, I. Kouvelas, O. Hodson, V. Hardman, M. Handley, J.C. 232 Bolot, A. Vega-Garcia, and S. Fosse-Parisis, "RTP Payload for 233 Redundant Audio Data", RFC 2198, September 1997. 234 [5] A. Li, "An RFC Payload Format for Generic FEC", IETF work in 235 progress. 237 Copyright Statement 239 Copyright (C) The Internet Society (2005). 241 This document is subject to the rights, licenses and restrictions 242 contained in BCP 78, and except as set forth therein, the authors 243 retain all their rights. 245 Disclaimer of Validity 247 This document and the information contained herein are provided on an 248 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 249 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 250 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 251 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 252 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 253 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 255 The IETF takes no position regarding the validity or scope of any 256 Intellectual Property Rights or other rights that might be claimed to 257 pertain to the implementation or use of the technology described in 258 this document or the extent to which any license under such rights 259 might or might not be available; nor does it represent that it has 260 made any independent effort to identify any such rights. Information 261 on the procedures with respect to rights in RFC documents can be 262 found in BCP 78 and BCP 79. 264 Copies of IPR disclosures made to the IETF Secretariat and any 265 assurances of licenses to be made available, or the result of an 266 attempt made to obtain a general license or permission for the use of 267 such proprietary rights by implementers or users of this 268 specification can be obtained from the IETF on-line IPR repository at 269 http://www.ietf.org/ipr. 271 The IETF invites any interested party to bring to its attention any 272 copyrights, patents or patent applications, or other proprietary 273 rights that may cover technology that may be required to implement 274 this standard. Please address the information to the IETF at ietf- 275 ipr@ietf.org. 277 RFC Editor Considerations 279 The RFC-editor is kindly requested to perform the following 280 modifications upon the publication of this specification: 282 - Replace all occurrences of RFC XXXX with the RFC number this 283 specification receives when being published. 285 - Replace reference [5] and all occurrences of RFC YYYY with the 286 corresponding title and RFC number of that ID when it is published. 288 - Remove this Section. 290 This Internet-Draft expires June 5, 2006.