idnits 2.17.1 draft-ietf-avt-variable-rate-audio-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 3667, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 219. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 230. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 237. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 243. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 2) being 112 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 6 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 121: '... 1) This draft MUST specify a unifie...' RFC 2119 keyword, line 123: '... 2) This draft MUST specify a roundi...' RFC 2119 keyword, line 126: '...unding algorithm MUST fulfill the requ...' RFC 2119 keyword, line 128: '... 3) This draft SHOULD state that its...' RFC 2119 keyword, line 131: '... 4) This draft SHOULD state that its...' (11 more instances...) 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 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 2004) is 7131 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) No issues found here. Summary: 7 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group S. Wenger 2 Internet Draft C. Perkins 3 Document: draft-ietf-avt-variable-rate-audio-00.txt 4 Expires: April 2005 5 October 2004 7 RTP Timestamp Frequency for Variable Rate Audio Codecs 9 Status of this Memo 11 By submitting this Internet-Draft, I certify that any applicable 12 patent or other IPR claims of which I am aware have been disclosed, 13 or will be disclosed, and any of which I become aware will be 14 disclosed, in accordance with RFC 3668. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 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 cite them other than as "work in progress". 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html 32 This document is a submission of the IETF AVT WG. Comments should 33 be directed to the AVT WG mailing list, avt@ietf.org. 35 Abstract 37 This memo discusses the problems of audio codecs with variable 38 external sampling rates. Historically, for audio codecs, the RTP 39 timestamp frequency was chosen to match the sampling rate of the 40 audio codec. However, this choice is nowadays more difficult to 41 justify, because of the advent of audio codecs (and, even more 42 important, practical use cases) that support multiple sample rates 43 and the switch between the sample rates during the lifetime of an 44 RTP session. This Internet draft addresses the problem by 45 suggesting that RTP Payload RFCs for such codecs to utilize a 46 single, high, unified RTP timestamp frequency. 48 1. Introduction 49 One key property of audio codecs is the external input sample rate. 50 For many of codecs, this sample rate is fixed. ITU-T G.711 [2], 51 also known as a-law and mu-law, uses, for example, a sample rate of 52 8 kHz. Other audio codecs give the user a choice between different 53 sample rates. However, until recently, applications never changed 54 the sample rate during the lifetime of an RTP session, even if this 55 is technically feasible and probably advantageous from both the user 56 perception, and the network point-of-view. One example for such a 57 codec is MPEG-1 audio, layers 1, 2, or 3 [3]. At the time RTP [1] 58 and the AV-profile [4] was developed, it was a reasonable design 59 choice to use an RTP timestamp frequency that is identical to the 60 codec's input sample rate, as this facilitates sample exact 61 synchronization and processing of media data in endpoints, mixers 62 and translators, among other advantages. Although neither RTP [1] 63 nor the audio-visual profile [4] require the codec sample rate being 64 the same as the RTP timestamp frequency, this paradigm was observed 65 in practice. 67 Recently, codecs have been developed which do not only support 68 variable sample rates, but use unannounced (in-band only signaled) 69 changes of the sample rate as one of their key mechanisms. 70 Similarly, applications have emerged, that not only support variable 71 sample rates, but, to some extend, rely on this feature. For most 72 (if not all) of these codecs, it is true that the required bit rate 73 and the user experience scales with the sample rate selected. This 74 allows, in the future, a network-dictated scaling of the 75 transmission bit rate of an audio codec -- a feature that was not 76 available before -- which could turn out to be very useful in 77 Internet environments, for example to support congestion control. 79 With the modern codecs mentioned, the current paradigm of RTP time 80 stamp frequency equal to codec sample rate does not make much sense 81 any more. The purpose of this draft is to provide guidance for the 82 developers of RTP payload specs for codecs with variable sample rate 83 to use a single, relatively high, RTP timestamp frequency, which is 84 specified in this draft. 86 2. Audio codecs with variable sample rates: Examples 88 Examples for audio codecs with variable sample rates, that (at least 89 in theory) could switch the sample rate on the fly without 90 out-of-band signaling support, include: 92 * AMR-WB+ [5] with a choice of 56 different sample rates 93 * VMR-WB [6] with the choice of 8 kHz and 16 kHz sample rates 94 * MPEG-4 AAC+ [7] with the choice of (need details here) 95 * Any others? 97 All these codecs use in-band signaling of the sample rate. 99 3. Rounding 100 It is possible (even likely) that no unified RTP timestamp frequency 101 can be found that, on one hand, fulfills one key requirement spelled 102 out later (namely: is low enough to make timestamp wrap-around 103 during erasure periods unlikely for all practical application 104 scenarios) and, one the other hand, is an integer multitude of all 105 sampling frequencies the codecs support. It is well possible that, 106 in the future, codecs be developed that can make sample rate choices 107 in a granularity of 1 Hz or even finer. Considering this, it is 108 required to specify a rounding algorithm for such cases where no 109 sample-exact position of an audio frame can be found in the RTP 110 timestamp numbering space. Specifying this rounding algorithm 111 ensures that all equipment conforming to this draft use the same 112 rounding algorithm. If that selected rounding algorithm guaranties 113 that inaccuracies do not add up (as spelled out in the requirements 114 later), then even frequent transcoding steps will not lead to an 115 increase to inaccuracy of the timing beyond the unavoidable minimum. 117 4. Requirements discussion 119 4.1. Requirements for this draft (general) 121 1) This draft MUST specify a unified RTP timestamp frequency that 122 fulfills the requirements of section 4.2. 123 2) This draft MUST specify a rounding algorithm that can be used for 124 non-sample exact alignment of samples stemming from more than one 125 audio codec, at least one of which having a variable sample 126 rate). The rounding algorithm MUST fulfill the requirements of 127 section 4.3. 128 3) This draft SHOULD state that its provisions MUST be used for the 129 design of future RTP payload formats for audio codecs with 130 variable sample rates 131 4) This draft SHOULD state that its provisions SHOULD be considered 132 in the design of future RTP payload formats for non-audio codecs 133 that have similar problems as variable sample rate audio codecs. 134 5) This draft SHOULD provide an application example for a 135 well-understood variable sample rate codec. 137 4.2. Requirements for the unified RTP timestamp rate 139 6) The unified RTP timestamp rate (uRTR) MUST be sufficiently high 140 to fulfill the requirements for timestamps in RFC3550[1] 141 7) The uRTR MUST be low enough to make wrap-arounds of the RTP 142 timestamp during erasure periods (packet loss bursts) unlikely in 143 all reasonable application scenarios. 144 Informative note: Such scenarios include, for example, cell 145 handovers in wireless cellular networks, where erasure periods 146 of a few seconds can occur. 147 8) The uRTR SHOULD share the prime factors of the sample rates of 148 the most commonly used fixed sample rate audio codecs, so to 149 allow for sample exact mixing of streams coded by those fixed 150 sample rate audio codecs. 151 9) The uRTR SHOULD be chosen to include a sufficiently high number 152 of prime factors so to support as many future variable sample 153 rate codec code points as possible for sample-exact mixing 155 4.3. Requirements for a rounding algorithm 157 10) The rounding algorithm MUST be applicable for all sample 158 rates lower than the 0.5 * uRTR specified in this draft. 159 11) The rounding algorithm MAY specify a minimum and maximum 160 sample rate, in units of x * uRTR. Only within this band it 161 is a reasonable expectation that the application of the 162 rounding algorithm does not lead to audible distortions for 163 the common user. 164 12) The rounding algorithm MUST be simple enough to be 165 implemented, without a serious cycle burden, in networking 166 equipment. 167 13) The rounding algorithm SHOULD be imlementable in fixed-point 168 arithmetic 169 14) The rounding algorithm MAY, advantageously, be specified such 170 that it does not require division operations 171 15) The rounding algorithm SHOULD be designed such that that 172 multiple applications of the algorithm does not lead to the 173 introduction of errors larger than one tick of the uRTR. 174 Informative Note: this is a much more difficult 175 requirement as it seems at the first glance. Think of a 176 transcoding scenario where variable goes to 44.1 kHz goes 177 to variable, and the unified timestamp frequency does not 178 share all prime factors of 44.1 kHz. One way out of this 179 would be to rewrite all fixed rate payload specs that use 180 timestamp frequencies that do not fit into the prime 181 factors of the uRTR to be rewritten so to use the uRTR. 182 Is it possible to do this for 44.1 -- or is this nailed 183 down in RFC3551? 185 5. Open issues 187 * Very general: is this a good idea? 188 * What would be a good choice for the uRTR? 192 kHz? 189 * Is it a good idea to require ALL future I-Ds on audio (not only 190 the variable clock frequency ones) to use the uRTR? 191 * Or only those that do not fit the uRTR (fit == subset of prime 192 factors)? 193 * Revisit CD 44.1. No variable sample rate needed? Are there 194 proposals for an 88.2 CD audio codec? 196 6. Security Considerations 197 None 199 7. Congestion Control 200 None 202 8. IANA Consideration 203 None 205 9. Acknowledgements 206 None 208 10. Full Copyright Statement 209 Copyright (C) The Internet Society (2004). This document is subject 210 to the rights, licenses and restrictions contained in BCP 78, and 211 except as set forth therein, the authors retain all their rights. 213 This document and the information contained herein are provided on 214 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 215 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 216 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 217 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 218 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 219 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 221 11. Intellectual Property Notice 223 The IETF takes no position regarding the validity or scope of any 224 Intellectual Property Rights or other rights that might be claimed 225 to pertain to the implementation or use of the technology described 226 in this document or the extent to which any license under such 227 rights might or might not be available; nor does it represent that 228 it has made any independent effort to identify any such rights. 229 Information on the procedures with respect to rights in RFC 230 documents can be found in BCP 78 and BCP 79. 232 Copies of IPR disclosures made to the IETF Secretariat and any 233 assurances of licenses to be made available, or the result of an 234 attempt made to obtain a general license or permission for the use 235 of such proprietary rights by implementers or users of this 236 specification can be obtained from the IETF on-line IPR repository 237 at http://www.ietf.org/ipr. 239 The IETF invites any interested party to bring to its attention any 240 copyrights, patents or patent applications, or other proprietary 241 rights that may cover technology that may be required to implement 242 this standard. Please address the information to the IETF at ietf- 243 ipr@ietf.org. 245 12. References 247 12.1. Normative References 248 [1] RTP, RFC 3550, STD 64 250 12.2. Informative References 252 [2] G.711 253 [3] ISO/IEC 11172 part 3 254 [4] RTP AV profile, RFC 3551, STD 65 255 [5] AMR-WB+ 256 [6] VMR-WB 257 [7] ISO/IEC 14496 part xxx, AAC+ 259 13. Author's Addresses 261 Stephan Wenger Phone: +358-50-486-0637 262 Nokia Research Center Email: stewe@stewe.org 263 P.O. Box 100 264 FIN-33721 Tampere 265 Finland 267 Colin Perkins 268 University of Glasgow 269 Department of Computing Science 270 17 Lilybank Gardens 271 Glasgow G12 8QQ 272 United Kingdom 274 14. RFC Editor Considerations 276 none