idnits 2.17.1 draft-ietf-mmusic-fec-grouping-00.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 260. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 269. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 276. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 282. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? == 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 (October 22, 2005) is 6760 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: 7 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: April 22, 2006 October 22, 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 cite them other than as "work in progress". 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/lid-abstracts.txt 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. FEC Grouping Semantics......................................3 51 4.3. Offer / Answer Consideration................................3 52 4.4. Example of FEC Grouping.....................................4 53 5. Security Consideration...........................................5 54 6. IANA Considerations..............................................5 55 7. Acknowledgments..................................................5 56 8. Author's Address.................................................5 57 9. References.......................................................5 58 9.1. Normative References........................................5 59 9.2. Informative References......................................6 61 1. Introduction 63 The media lines in an SDP [3] session are usually associated with 64 each other. SDP itself does not provide methods to convey the 65 relationships between the media lines. Such relationships are 66 indicated the extension to SDP as defined in Grouping of Media Lines 67 in the Session Description Protocol (RFC 3388) [2]. RFC 3388 defines 68 two types of semantics: Lip Synchronization, and Flow Identification. 70 Forward Error Correction (FEC) is a common technique to achieve 71 robust communication in error-prone environments. In this document, 72 we define the semantics that allows for grouping of FEC streams with 73 the protected payload streams in SDP by further extending RFC 3388. 75 2. Terminology 77 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 78 "SHOULD, "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 79 document are to be interpreted as described in RFC 2119 [1]. 81 3. Forward Error Correction (FEC) 83 Forward Error Correction (FEC) is a common technique to achieve 84 robust communication in error-prone environments. In FEC, 85 communication uses a bandwidth that is more than payload to send 86 redundantly coded payload information. The receivers can readily 87 recover the original payload even when some communication is lost in 88 the transmission. Compare to other error correction technique (such 89 as re-transmission), FEC can achieve much lower transmission delay, 90 and does not have the problem of implosion from retransmission 91 requests in various multicast scenarios. 93 In general, the FEC data can be send in two different ways: (1) 94 multiplexed together with the original payload stream, or (2) as a 95 separate stream. It is thus necessary to define mechanisms to 96 indicate the association relationship between the FEC data and the 97 payload data they protect. 99 When FEC data are multiplexed with the original payload stream, the 100 association relationship is indicated as specified in RTP Payload for 101 Redundant Audio Data (RFC 2198) [4]. As an example, such relationship 102 can be indicated as in the generic RFC payload format for FEC [5]. 104 When FEC data are sent as a separate stream from the payload data, 105 the association relationship can be indicated in various ways. This 106 document on the FEC media line grouping specifies a mechanism for 107 indicating such relationships. 109 4. FEC Grouping 111 4.1. FEC Group 113 Each "a=group" line are used to indicate the association relationship 114 between the FEC streams and the payload stream. The streams included 115 in one "a=group" line are called a "FEC Group". 117 Each FEC group MAY have one or more than one FEC streams, and one or 118 more than one payload streams. For example, it is possible to have 119 one payload streams protected by more than one FEC streams, or 120 multiple payload streams sharing one FEC stream. 122 Grouping streams in a FEC group only indicates the association 123 relationship between streams. The detailed FEC protection 124 scheme/parameters are conveyed through the mechanism of the 125 particular FEC algorithm used. For example, the FEC grouping is used 126 for generic RTP payload for FEC (RFC YYYY) [5] to indicate the 127 association relationship between the FEC stream and the payload 128 stream. The detailed protection level and length information for the 129 ULP algorithm is communicated in band within the FEC stream. 131 4.2. FEC Grouping Semantics 133 The FEC semantics is defined by the following BNF: 135 Semantics = "FEC" 137 4.3. Offer / Answer Consideration 139 The backward compatibility in offer / answer is generally handled as 140 specified in RFC 3388 [2]. 142 Depending on the implementation, a node that does not understand FEC 143 grouping (either does not understand line grouping at all, or just 144 does not understand the FEC semantics) might respond to an offer 145 containing FEC grouping either (1) with an answer which ignores the 146 grouping attribute, or (2) with a refusal to the request (e.g., 488 147 Not acceptable here or 606 Not Acceptable). 149 In the first case, the original sender of the offer MUST establish 150 the connection without FEC. In the second case, if the sender of the 151 offer still wishes to establish the session, it SHOULD re-try the 152 request with an offer without FEC. 154 4.4. Example of FEC Grouping 156 The following example shows a session description of a multicast 157 conference. The first media stream (mid:1) contains the audio stream. 158 The second media stream (mid:2) contains the Generic FEC [5] 159 protection for the audio stream. These two streams form an FEC Group. 160 The relationship between the two streams is indicated by the 161 "a=group:FEC 1 2" line. The FEC stream is sent to the same multicast 162 group and has the same TTL as the audio, but on a port number two 163 higher. Likewise, the video stream (mid:3) and its Generic FEC 164 protection stream (mid:4) forms another FEC group. The relationship 165 between the two streams is indicated by the "a=group:FEC 3 4" line. 166 The FEC stream is sent to a different multicast address, but has the 167 same port number (30004) as the payload video stream. 169 v=0 170 o=adam 289083124 289083124 IN IP4 host.example.com 171 s=ULP FEC Seminar 172 t=0 0 173 c=IN IP4 224.2.17.12/127 174 a=group:FEC 1 2 175 a=group:FEC 3 4 176 m=audio 30000 RTP/AVP 0 177 a=mid:1 178 m=application 30002 RTP/AVP 100 179 a=rtpmap:100 ulpfec/8000 180 a=mid:2 181 m=video 30004 RTP/AVP 31 182 a=mid:3 183 m=application 30004 RTP/AVP 101 184 c=IN IP4 224.2.17.13/127 185 a=rtpmap:101 ulpfec/8000 186 a=mid:4 188 5. Security Consideration 190 There is a weak threat for the receiver that the FEC grouping can be 191 modified to indicate FEC relationships that do not exist. Such 192 attacks may result in failure of FEC protect, and/or mishandling of 193 other media payload streams. It is recommended that the receiver 194 implementation SHOULD do integrity check to thwart such threats. 196 6. IANA Considerations 198 This document defines the semantics to be used with grouping of media 199 lines in SDP as defined in RFC 3388. The semantics defined in this 200 document are to be registered by the IANA when they are published in 201 standard track RFCs. 203 The following semantics need to be registered with IANA. 205 Semantics Token Reference 206 ------------------------ ----- --------- 207 Forward Error Correction FEC RFC XXXX 209 7. Acknowledgments 211 The author would like to thank Magnus Westerlund, Colin Perkins, and 212 Joerg Ott for their feedback on this document. 214 8. Author's Address 216 Adam Li 217 HyerVision 218 10194 Wateridge Circle #152 219 San Diego, CA 92121 220 U.S.A. 221 Tel: +1 858 622 9038 222 Email: adamli@hyervision.com 224 9. References 226 9.1. Normative References 228 [1] S. Bradner, "Key words for use in RFCs to Indicate Requirement 229 Levels", RFC 2119, March 1997. 230 [2] G. Camarillo, J. Holler, and H. Schulzrinne, "Grouping of Media 231 Lines in the Session Description Protocol (SDP)", RFC 3388, 232 December 2002. 234 9.2. Informative References 236 [3] M. Handley, and V. Jacobson, "SDP: Session Description 237 Protocol", RFC 2327, April 1998. 238 [4] C. Perkins, I. Kouvelas, O. Hodson, V. Hardman, M. Handley, J.C. 239 Bolot, A. Vega-Garcia, and S. Fosse-Parisis, "RTP Payload for 240 Redundant Audio Data", RFC 2198, September 1997. 241 [5] A. Li, "An RFC Payload Format for Generic FEC", IETF work in 242 progress. 244 Copyright Statement 246 Copyright (C) The Internet Society (2005). 248 This document is subject to the rights, licenses and restrictions 249 contained in BCP 78, and except as set forth therein, the authors 250 retain all their rights." 252 Disclaimer of Validity 254 This document and the information contained herein are provided on an 255 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 256 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 257 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 258 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 259 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 260 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 262 The IETF takes no position regarding the validity or scope of any 263 Intellectual Property Rights or other rights that might be claimed to 264 pertain to the implementation or use of the technology described in 265 this document or the extent to which any license under such rights 266 might or might not be available; nor does it represent that it has 267 made any independent effort to identify any such rights. Information 268 on the procedures with respect to rights in RFC documents can be 269 found in BCP 78 and BCP 79. 271 Copies of IPR disclosures made to the IETF Secretariat and any 272 assurances of licenses to be made available, or the result of an 273 attempt made to obtain a general license or permission for the use of 274 such proprietary rights by implementers or users of this 275 specification can be obtained from the IETF on-line IPR repository at 276 http://www.ietf.org/ipr. 278 The IETF invites any interested party to bring to its attention any 279 copyrights, patents or patent applications, or other proprietary 280 rights that may cover technology that may be required to implement 281 this standard. Please address the information to the IETF at ietf- 282 ipr@ietf.org. 284 RFC Editor Considerations 286 The RFC-editor is kindly requested to perform the following 287 modifications upon the publication of this specification: 289 - Replace all occurrences of RFC XXXX with the RFC number this 290 specification receives when being published. 292 - Replace reference [5] and all occurrences of RFC YYYY with the 293 corresponding title and RFC number of that ID when it is published. 295 - Remove this Section. 297 This Internet-Draft expires October 22, 2006.