idnits 2.17.1 draft-ietf-avt-rtp-vmr-wb-extension-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 319. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 297. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 297. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 303. ** 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 19, 2005) is 6764 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) -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Audio Video Transport WG Sassan Ahmadi 2 INTERNET-DRAFT 3 Expires: April 19, 2006 October 19, 2005 5 Real-Time Transport Protocol (RTP) Payload Format for the 6 Variable-Rate Multimode Wideband (VMR-WB) Extension Audio Codec 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 18 other groups may also distribute working documents as 19 Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other 23 documents at any time. It is inappropriate to use Internet-Drafts 24 as reference material or to cite them other than as "work in 25 progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html 33 This document is a submission of the IETF AVT WG. Comments should 34 be directed to the AVT WG mailing list, avt@ietf.org. 36 Abstract 38 This document is an addendum to RFC xxxx, which specifies the 39 RTP payload format for the Variable-Rate Multimode Wideband (VMR-WB) 40 speech codec. This document specifies some updates in RFC xxxx to 41 enable support for the new operating mode of VMR-WB standard (i.e., 42 VMR-WB mode 4). These updates do not affect the existing modes of 43 VMR-WB already specified in RFC xxxx. 45 The payload formats and their associated parameters, as well as all 46 provisions, restrictions, use cases, features, etc. that are 47 specified in RFC xxxx are applicable to the new operating mode with 48 no exception. 50 Table of Contents 52 1.Introduction.................................................2 53 2.Conventions and Acronyms.....................................2 54 3.The Variable-Rate Multimode Wideband (VMR-WB) Extension......3 55 4.The Necessary Updates in RFC xxxx............................3 56 5.Security Considerations......................................5 57 6.Public Specification.........................................5 58 7.IANA Considerations..........................................5 59 References.....................................................5 60 Normative References........................................5 61 Informative References......................................6 62 Author's Address...............................................6 63 IPR Notice.....................................................6 64 Copyright Notice...............................................7 66 1. Introduction 68 This document is an addendum to RFC xxxx [2] and contains the 69 necessary updates for the support of the new operating mode of 3GPP2 70 VMR-WB standard [1]. The new mode of VMR-WB standard; i.e., VMR-WB 71 mode 4, while operating at a lower data rate, has similar 72 characteristics and functionalities compared to the existing modes 73 of VMR-WB already included in RFC xxxx (e.g., variable bit rate, 74 narrowband/wideband input/output speech/audio processing capability, 75 continuous and discontinuous transmission, etc.). Therefore, all 76 provisions and restrictions specified in RFC xxxx are applicable to 77 all modes of the VMR-WB standard including the new mode, which is 78 specified in this document. As a result, no new media type 79 registration is required. 81 The VMR-WB file format; i.e., for transport of VMR-WB speech data in 82 storage mode applications, is specified in [1,4] and includes 83 support for the new mode of operation. 85 The following sections provide the necessary updates to 86 RFC xxxx to enable support of VMR-WB mode 4. 88 2. Conventions and Acronyms 90 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 91 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 92 document are to be interpreted as described in RFC2119 [3]. 94 The following acronyms are used in this document: 96 3GPP2 - The Third Generation Partnership Project 2 97 CDMA - Code Division Multiple Access 98 VMR-WB - Variable-Rate Multimode Wideband Codec 99 CMR - Codec Mode Request 100 DTX - Discontinuous Transmission 101 RTP - Real-Time Transport Protocol 102 MIME - Multipurpose Internet Mail Extension 104 3. The Variable-Rate Multimode Wideband (VMR-WB) Extension 106 VMR-WB is the wideband speech-coding standard developed by 107 Third Generation Partnership Project 2 (3GPP2) for 108 encoding/decoding wideband/narrowband speech content in 109 multimedia services in 3G CDMA cellular systems [1]. VMR-WB is a 110 source-controlled variable-rate multimode wideband speech 111 codec. It has a number of operating modes, where each mode is 112 a tradeoff between voice quality and average data rate. The 113 operating mode in VMR-WB (as shown in Table 2) is chosen based on 114 the traffic condition of the network and the desired quality of 115 service. The desired average data rate (ADR) in each mode 116 is obtained by encoding speech frames at permissible rates (as shown 117 in Tables 1 and 3) compliant with cdma2000 system depending on the 118 instantaneous characteristics of input speech and the maximum and 119 minimum rate constraints imposed by the network operator. 121 The capabilities of the VMR-WB codec were extended through the 122 addition of a new mode operating at lower average data rates, 123 resulting in improved system capacity in IP and non-IP networks [1]. 125 As a result of this extension, certain reserved table entries in 126 RFC xxxx are used to include support for the new operating mode. 127 VMR-WB mode 4 is compliant with all applicable provisions and 128 restrictions specified in RFC xxxx [2]. Note that the existing table 129 entries of RFC xxxx remain unchanged (e.g., frame types, etc.) and 130 the original modes of VMR-WB are not affected by these updates. 132 The existing flexibility in RFC xxxx for future extensions allows 133 the addition of the new mode without any impact on the 134 interoperability with earlier implementations of RFC xxxx. 136 The following sections provide the necessary updates that are 137 required to be made in RFC xxxx. 139 The provisions and considerations for implementation, congestion 140 control, and security remain identical to those specified in 141 RFC xxxx. 143 4. The Necessary Updates in RFC xxxx 145 Table 1 of RFC xxxx is updated as follows: 147 +---------------------------+-----------------+---------------+ 148 | Frame Type | Bits per Packet | Encoding Rate | 149 | | (Frame Size) | (kbps) | 150 +---------------------------+-----------------+---------------+ 151 | Full-Rate | 266 | 13.3 | 152 | Full-Rate | 171 | 8.55 | 153 | Half-Rate | 124 | 7.2 | 154 | Half-Rate | 80 | 4.0 | 155 | Quarter-Rate | 54 | 2.7 | 156 | Quarter-Rate | 40 | 2.0 | 157 | Eighth-Rate | 20 | 1.0 | 158 | Eighth-Rate | 16 | 0.8 | 159 | Blank | 0 | - | 160 | Erasure | 0 | - | 161 | Full-Rate with Bit Errors | 171 | 8.55 | 162 +---------------------------+-----------------+---------------+ 163 Table 1: cdma2000 system permissible frame types and their 164 associated encoding rates 166 Note that the new permissible rates correspond to cdma2000 rate-set 167 I have been added to the table. 169 Table 2 of RFC xxxx is updated as follows to include VMR-WB mode 4 170 and VMR-WB mode 4 with maximum half-rate similar to that described 171 in Section 2.4 of the revised VMR-WB specification [1]. 173 +-------+----------------------------------------------------------+ 174 | CMR | VMR-WB Operating Modes | 175 +-------+----------------------------------------------------------+ 176 | 0 | VMR-WB mode 3 (AMR-WB interoperable mode at 6.60 kbps) | 177 | 1 | VMR-WB mode 3 (AMR-WB interoperable mode at 8.85 kbps) | 178 | 2 | VMR-WB mode 3 (AMR-WB interoperable mode at 12.65 kbps) | 179 | 3 | VMR-WB mode 2 | 180 | 4 | VMR-WB mode 1 | 181 | 5 | VMR-WB mode 0 | 182 | 6 | VMR-WB mode 2 with maximum half-rate encoding | 183 | 7 | VMR-WB mode 4 | 184 | 8 | VMR-WB mode 4 with maximum half-rate encoding | 185 | 9-14 | (reserved) | 186 | 15 | No Preference (no mode request is present) | 187 +-------+----------------------------------------------------------+ 188 Table 2: List of valid CMR values and their associated VMR-WB 189 operating modes. 191 Note that CMR values 7 and 8 replace the reserved values in Table 2 192 of RFC xxxx. 194 Table 3 of RFC xxxx is updated as follows to include new frame types 195 (FT) associated with VMR-WB mode 4. 197 Note that the size of the frames are unique and different, allowing 198 for the use of header-free payload format for all modes of 199 operations [2]. 201 +----+--------------------------------------------+-------------------+ 202 | FT | Encoding Rate | Frame Size (Bits) | 203 +----+--------------------------------------------+-------------------+ 204 | 0 | Interoperable Full-Rate (AMR-WB 6.60 kbps) | 132 | 205 | 1 | Interoperable Full-Rate (AMR-WB 8.85 kbps) | 177 | 206 | 2 | Interoperable Full-Rate (AMR-WB 12.65 kbps)| 253 | 207 | 3 | Full-Rate 13.3 kbps | 266 | 208 | 4 | Half-Rate 6.2 kbps | 124 | 209 | 5 | Quarter-Rate 2.7 kbps | 54 | 210 | 6 | Eighth-Rate 1.0 kbps | 20 | 211 | 7 | Full-Rate 8.55 kbps | 171 | 212 | 8 | Half-Rate 4.0 kbps | 80 | 213 | 9 | CNG (AMR-WB SID) | 35 | 214 | 10 | Eighth-Rate 0.8 kbps | 16 | 215 | 11 | (reserved) | - | 216 | 12 | (reserved) | - | 217 | 13 | (reserved) | - | 218 | 14 | Erasure (AMR-WB SPEECH_LOST) | 0 | 219 | 15 | Blank (AMR-WB NO_DATA) | 0 | 220 +----+--------------------------------------------+-------------------+ 221 Table 3:VMR-WB payload frame types for real-time transport 223 Note that the new FT types associated with VMR-WB mode 4 replace the 224 reserved entries 7, 8, and 10 in Table 3 of RFC xxxx and there are 225 no changes in the existing entries of Table 3 of RFC xxxx. 227 The 'mode-set' MIME parameter value 4 is defined to indicate that 228 VMR-WB mode 4 is supported and used. Note that the active modes of 229 operation are negotiated and agreed by the IP terminals through the 230 offer-answer model provided in Section 9.3 of RFC xxxx [2]. 232 5. Security Considerations 234 Same as RFC xxxx 236 6. Public specification 238 The VMR-WB speech codec including the new mode is specified in 239 following 3GPP2 specification C.S0052-A version 1.0. Transfer 240 methods are specified in RFC xxxx. 242 7. IANA Considerations 244 None 246 References 248 Normative References 250 [1] 3GPP2 C.S0052-A v1.0 "Source-Controlled Variable-Rate 251 Multimode Wideband Speech Codec (VMR-WB) Service Options 252 62 and 63 for Spread Spectrum Systems", 3GPP2 Technical 253 Specification, April 2005. 255 [2] S. Ahmadi, "Real-Time Transport Protocol (RTP) Payload Formats 256 for the Variable-Rate Multimode Wideband (VMR-WB) Audio Codec", 257 RFC xxxx, Internet Engineering Task Force, October 2005. 259 [3] S. Bradner, "Key words for use in RFCs to Indicate 260 Requirement Levels", BCP 14, RFC 2119, Internet Engineering 261 Task Force, March 1997. 263 Informative References 265 [4] 3GPP2 C.S0050-A v1.0 "3GPP2 File Formats for Multimedia 266 Services", 3GPP2 Technical Specification, October 2005. 268 Any 3GPP2 document can be downloaded from the 3GPP2 web 269 server, "http://www.3gpp2.org/", see specifications. 271 Author's Address 273 Dr. Sassan Ahmadi Email: sassan.ahmadi@ieee.org 275 This Internet-Draft expires in six months from October 19, 2005. 277 RFC Editor Considerations 279 The RFC editor is requested to replace all occurrences of xxxx with 280 the RFC number that reference [2] will receive. 282 IPR Notice 284 The IETF takes no position regarding the validity or scope of any 285 Intellectual Property Rights or other rights that might be claimed 286 to pertain to the implementation or use of the technology described 287 in this document or the extent to which any license under such 288 rights might or might not be available; nor does it represent that 289 it has made any independent effort to identify any such rights. 290 Information on the procedures with respect to rights in RFC 291 documents can be found in BCP 78 and BCP 79. 292 Copies of IPR disclosures made to the IETF Secretariat and any 293 assurances of licenses to be made available, or the result of an 294 attempt made to obtain a general license or permission for the use 295 of such proprietary rights by implementers or users of this 296 specification can be obtained from the IETF on-line IPR repository 297 at http://www.ietf.org/ipr. 299 The IETF invites any interested party to bring to its attention any 300 copyrights, patents or patent applications, or other proprietary 301 rights that may cover technology that may be required to implement 302 this standard. Please address the information to the IETF at 303 ietf-ipr@ietf.org. 305 Copyright Notice 307 Copyright (C) The Internet Society (2005). This document is 308 subject to the rights, licenses and restrictions contained in BCP 309 78, and except as set forth therein, the authors retain all their 310 rights. 312 This document and the information contained herein are provided on 313 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 314 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 315 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 316 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 317 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 318 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 319 PARTICULAR PURPOSE.