idnits 2.17.1 draft-ietf-mmusic-fec-grouping-05.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 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 256. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 265. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 272. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 278. ** 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 (June 25, 2006) is 6512 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) -- Looks like a reference, but probably isn't: 'RFC XXXX' on line 203 ** Obsolete normative reference: RFC 3388 (ref. '2') (Obsoleted by RFC 5888) 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: December 25, 2006 June 25, 2006 6 Forward Error Correction Grouping Semantics 7 in Session Description Protocol 8 10 Status of this memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that other 19 groups may also distribute working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/1id-abstracts.html 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html 32 This document is an individual submission to the IETF. Comments 33 should be directed to the authors. 35 Abstract 37 This document defines the semantics that allows for grouping of 38 forward error correction (FEC) streams with the protected payload 39 streams in Session Description Protocol (SDP). The semantics defined 40 in this document is to be used with Grouping of Media Lines in the 41 Session Description Protocol (RFC 3388) to group together "m" lines 42 in the same session. 44 Table of Contents 46 1. Introduction.....................................................2 47 2. Terminology......................................................2 48 3. Forward Error Correction (FEC)...................................2 49 4. FEC Grouping.....................................................3 50 4.1. FEC Group...................................................3 51 4.2. Offer / Answer Consideration................................3 52 4.3. Example of FEC Grouping.....................................4 53 5. Security Consideration...........................................4 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......................................5 61 1. Introduction 63 The media lines in an SDP [3] session may be associated with each 64 other in various ways. SDP itself does not provide methods to convey 65 the 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 sent 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 is used to indicate an 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. Offer / Answer Consideration 133 The backward compatibility in offer / answer is generally handled as 134 specified in RFC 3388 [2]. 136 Depending on the implementation, a node that does not understand FEC 137 grouping (either does not understand line grouping at all, or just 138 does not understand the FEC semantics) SHOULD respond to an offer 139 containing FEC grouping either (1) with an answer which ignores the 140 grouping attribute, or (2) with a refusal to the request (e.g., 488 141 Not acceptable here or 606 Not Acceptable in SIP). 143 In the first case, the original sender of the offer MUST establish 144 the connection without FEC. In the second case, if the sender of the 145 offer still wishes to establish the session, it SHOULD re-try the 146 request with an offer without FEC. 148 4.3. Example of FEC Grouping 150 The following example shows a session description of a multicast 151 conference. The first media stream (mid:1) contains the audio stream. 152 The second media stream (mid:2) contains the Generic FEC [5] 153 protection for the audio stream. These two streams form an FEC Group. 154 The relationship between the two streams is indicated by the 155 "a=group:FEC 1 2" line. The FEC stream is sent to the same multicast 156 group and has the same TTL as the audio, but on a port number two 157 higher. Likewise, the video stream (mid:3) and its Generic FEC 158 protection stream (mid:4) forms another FEC group. The relationship 159 between the two streams is indicated by the "a=group:FEC 3 4" line. 160 The FEC stream is sent to a different multicast address, but has the 161 same port number (30004) as the payload video stream. 163 v=0 164 o=adam 289083124 289083124 IN IP4 host.example.com 165 s=ULP FEC Seminar 166 t=0 0 167 c=IN IP4 224.2.17.12/127 168 a=group:FEC 1 2 169 a=group:FEC 3 4 170 m=audio 30000 RTP/AVP 0 171 a=mid:1 172 m=audio 30002 RTP/AVP 100 173 a=rtpmap:100 ulpfec/8000 174 a=mid:2 175 m=video 30004 RTP/AVP 31 176 a=mid:3 177 m=video 30004 RTP/AVP 101 178 c=IN IP4 224.2.17.13/127 179 a=rtpmap:101 ulpfec/8000 180 a=mid:4 182 5. Security Consideration 184 There is a weak threat for the receiver that the FEC grouping can be 185 modified to indicate FEC relationships that do not exist. Such 186 attacks may result in failure of FEC protect, and/or mishandling of 187 other media payload streams. It is recommended that the receiver 188 SHOULD do integrity check on SDP and follow the security 189 considerations of SDP to only trust SDP from trusted sources. 191 6. IANA Considerations 193 This document defines the semantics to be used with grouping of media 194 lines in SDP as defined in RFC 3388. The semantics defined in this 195 document are to be registered by the IANA when they are published in 196 standard track RFCs. 198 The following semantics need to be registered with IANA in Semantic 199 for the "group" SDP Attribute under SDP Parameters. 201 Semantics Token Reference 202 ------------------------ ----- ---------- 203 Forward Error Correction FEC [RFC XXXX] 205 7. Acknowledgments 207 The author would like to thank Magnus Westerlund, Colin Perkins, 208 Joerg Ott, and Cullen Jennings for their feedback on this document. 210 8. Author's Address 212 Adam Li 213 HyerVision 214 10194 Wateridge Circle #152 215 San Diego, CA 92121 216 U.S.A. 217 Tel: +1 858 622 9038 218 Email: adamli@hyervision.com 220 9. References 222 9.1. Normative References 224 [1] S. Bradner, "Key words for use in RFCs to Indicate Requirement 225 Levels", RFC 2119, March 1997. 226 [2] G. Camarillo, J. Holler, and H. Schulzrinne, "Grouping of Media 227 Lines in the Session Description Protocol (SDP)", RFC 3388, 228 December 2002. 230 9.2. Informative References 232 [3] M. Handley, V. Jacobson, and C. Perkins, "SDP: Session 233 Description Protocol", IETF work in progress, January 2006. 234 [4] C. Perkins, I. Kouvelas, O. Hodson, V. Hardman, M. Handley, J.C. 235 Bolot, A. Vega-Garcia, and S. Fosse-Parisis, "RTP Payload for 236 Redundant Audio Data", RFC 2198, September 1997. 237 [5] A. Li, "An RFC Payload Format for Generic FEC", IETF work in 238 progress, March 2006. 240 Copyright Statement 242 Copyright (C) The Internet Society (2006). 244 This document is subject to the rights, licenses and restrictions 245 contained in BCP 78, and except as set forth therein, the authors 246 retain all their rights. 248 Disclaimer of Validity 250 This document and the information contained herein are provided on an 251 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 252 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 253 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 254 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 255 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 256 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 258 The IETF takes no position regarding the validity or scope of any 259 Intellectual Property Rights or other rights that might be claimed to 260 pertain to the implementation or use of the technology described in 261 this document or the extent to which any license under such rights 262 might or might not be available; nor does it represent that it has 263 made any independent effort to identify any such rights. Information 264 on the procedures with respect to rights in RFC documents can be 265 found in BCP 78 and BCP 79. 267 Copies of IPR disclosures made to the IETF Secretariat and any 268 assurances of licenses to be made available, or the result of an 269 attempt made to obtain a general license or permission for the use of 270 such proprietary rights by implementers or users of this 271 specification can be obtained from the IETF on-line IPR repository at 272 http://www.ietf.org/ipr. 274 The IETF invites any interested party to bring to its attention any 275 copyrights, patents or patent applications, or other proprietary 276 rights that may cover technology that may be required to implement 277 this standard. Please address the information to the IETF at ietf- 278 ipr@ietf.org. 280 RFC Editor Considerations 282 The RFC-editor is kindly requested to perform the following 283 modifications upon the publication of this specification: 285 - Replace all occurrences of RFC XXXX with the RFC number this 286 specification receives when being published. 288 - Replace reference [5] and all occurrences of RFC YYYY with the 289 corresponding title and RFC number of that ID when it is published. 291 - Remove this Section. 293 This Internet-Draft expires December 25, 2006.