idnits 2.17.1 draft-ahmadi-avt-rtp-vmr-wb-extension-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 403. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 381. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 381. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 387. ** 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 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 (May 26, 2005) is 6903 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 (~~), 2 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 Nokia Inc. 3 Expires: November 26, 2005 May 26, 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 real-time transport protocol for the Variable-Rate Multimode 40 Wideband (VMR-WB) speech codec. This document contains the 41 information related to the new operating mode of VMR-WB. All 42 provisions, restrictions, use cases, features, etc. that are 43 specified in RFC xxxx are applicable to the new operating mode 44 without any exception. 46 No new media type registration is included in this document as the 47 new VMR-WB mode, defined in this document, will use the same media 48 type specified in RFC xxxx (i.e., audio/VMR-WB). Note that the 49 RFC xxxx was developed with sufficient flexibility for future 50 extensions and thereby it allows the addition of new operating 51 modes without any impacts on the interoperability of terminals 52 supporting different versions of the VMR-WB standard. 54 Table of Contents 56 1.Introduction.................................................2 57 2.Conventions and Acronyms.....................................2 58 3.The Variable-Rate Multimode Wideband (VMR-WB) Extension......3 59 4.The Necessary Updates in RFC xxxx............................3 60 4.1. Implementation Considerations..........................5 61 5. Congestion Control..........................................5 62 6. Security Considerations.....................................5 63 6.1. Confidentiality........................................5 64 6.2. Authentication.........................................5 65 6.3. Decoding Validation and Provision for Lost or Late 66 Packets................................................5 67 7. Payload Format Parameters...................................6 68 7.1. VMR-WB RTP Payload MIME Registration...................6 69 7.2. Mapping MIME Parameters into SDP.......................7 70 7.3. Offer-Answer Model Considerations......................7 71 8. IANA Considerations.........................................7 72 References.....................................................7 73 Normative References........................................7 74 Informative References......................................7 75 Author's Address...............................................7 76 IPR Notice.....................................................8 77 Copyright Notice...............................................8 79 1. Introduction 81 This document is an addendum to RFC xxxx [2] and contains the 82 necessary updates for the support of the new operating mode of 3GPP2 83 VMR-WB standard [1]. The new mode of VMR-WB standard (i.e., VMR-WB 84 mode 4) has similar characteristics (e.g., narrowband/wideband 85 input/output media processing capability, continuous and 86 discontinuous transmission, etc.) as the other modes of VMR-WB 87 already included in RFC xxxx. Therefore, all provisions and 88 restrictions specified in RFC xxxx are applicable to all modes of 89 the VMR-WB standard including the new mode, which is described in 90 this document. 92 As a result, no media type registration is required. The VMR-WB file 93 format; i.e., for transport of VMR-WB speech data in storage mode 94 applications, is specified in [1,4] and supports the new mode. 96 The following sections provide the necessary updates to RFC xxxx to 97 enable support of VMR-WB mode 4. 99 2. Conventions and Acronyms 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 102 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 103 "OPTIONAL" in this document are to be interpreted as 104 described in RFC2119 [3]. 106 The following acronyms are used in this document: 108 3GPP2 - The Third Generation Partnership Project 2 109 CDMA - Code Division Multiple Access 110 VMR-WB - Variable-Rate Multimode Wideband Codec 111 CMR - Codec Mode Request 112 DTX - Discontinuous Transmission 113 RTP - Real-Time Transport Protocol 114 MIME - Multipurpose Internet Mail Extension 115 SDP - Session Description Protocol 117 The term "frame-block" is used in this document to describe 118 the time-synchronized set of speech frames in a multi-channel 120 3. The Variable-Rate Multimode Wideband (VMR-WB) Extension 122 VMR-WB is the wideband speech-coding standard developed by 123 Third Generation Partnership Project 2 (3GPP2) for 124 encoding/decoding wideband/narrowband speech content in 125 multimedia services in 3G CDMA cellular systems [1]. VMR-WB is a 126 source-controlled variable-rate multimode wideband speech 127 codec. It has a number of operating modes, where each mode is 128 a tradeoff between voice quality and average data rate. The 129 operating mode in VMR-WB (as shown in Table 2) is chosen based on 130 the traffic condition of the network and the desired quality of 131 service. The desired average data rate (ADR) in each mode 132 is obtained by encoding speech frames at permissible rates (as shown 133 in Tables 1 and 3) compliant with CDMA2000 system depending on the 134 instantaneous characteristics of input speech and the maximum and 135 minimum rate constraints imposed by the network operator. 137 The capabilities of the VMR-WB codec were extended through the 138 addition of a new mode operating at lower average data rates, 139 resulting in improved system capacity in IP and non-IP networks [1]. 141 As a result of this extension, certain tables and parameters in RFC 142 xxxx must be updated to support of the new operating mode. VMR-WB 143 mode 4 is compliant with all applicable provisions and restrictions 144 specified in RFC xxxx [2]. 146 The existing flexibility in RFC xxxx for future extensions allows 147 the addition of the new mode without any impact on the 148 interoperability with earlier implementations of RFC xxxx. 150 The following sections provide the necessary updates that are 151 required to be made in RFC xxxx. 153 4. The Necessary Updates in RFC xxxx 154 Table 1 of RFC xxxx is updated as follows: 156 +---------------------------+-----------------+---------------+ 157 | Frame Type | Bits per Packet | Encoding Rate | 158 | | (Frame Size) | (kbps) | 159 +---------------------------+-----------------+---------------+ 160 | Full-Rate | 266 | 13.3 | 161 | Full-Rate | 171 | 8.55 | 162 | Half-Rate | 124 | 7.2 | 163 | Half-Rate | 80 | 4.0 | 164 | Quarter-Rate | 54 | 2.7 | 165 | Quarter-Rate | 40 | 2.0 | 166 | Eighth-Rate | 20 | 1.0 | 167 | Eighth-Rate | 16 | 0.8 | 168 | Blank | 0 | - | 169 | Erasure | 0 | - | 170 | Full-Rate with Bit Errors | 171 | 8.55 | 171 +---------------------------+-----------------+---------------+ 172 Table 1: CDMA2000 system permissible frame types and their associated 173 encoding rates 175 Note that the new permissible rates correspond to CDMA2000 rate-set 176 I. 178 Table 2 of RFC xxxx is updated as follows to include VMR-WB mode 4 179 and VMR-WB mode 4 with maximum half-rate similar to that described in 180 Section 2.4 of the revised VMR-WB specification [1]. 182 +-------+----------------------------------------------------------+ 183 | CMR | VMR-WB Operating Modes | 184 +-------+----------------------------------------------------------+ 185 | 0 | VMR-WB mode 3 (AMR-WB interoperable mode at 6.60 kbps) | 186 | 1 | VMR-WB mode 3 (AMR-WB interoperable mode at 8.85 kbps) | 187 | 2 | VMR-WB mode 3 (AMR-WB interoperable mode at 12.65 kbps) | 188 | 3 | VMR-WB mode 2 | 189 | 4 | VMR-WB mode 1 | 190 | 5 | VMR-WB mode 0 | 191 | 6 | VMR-WB mode 2 with maximum half-rate encoding | 192 | 7 | VMR-WB mode 4 | 193 | 8 | VMR-WB mode 4 with maximum half-rate encoding | 194 | 9-14 | (reserved) | 195 | 15 | No Preference (no mode request is present) | 196 +-------+----------------------------------------------------------+ 197 Table 2: List of valid CMR values and their associated VMR-WB 198 operating modes. 200 Table 3 of RFC xxxx is updated as follows to include new frame types 201 (FT) associated with VMR-WB mode 4. 203 Note that the size of the frames are unique and different, allowing 204 for the use of header-free payload format for all modes of operations 205 [2]. 207 +----+--------------------------------------------+-------------------+ 208 | FT | Encoding Rate | Frame Size (Bits) | 209 +----+--------------------------------------------+-------------------+ 210 | 0 | Interoperable Full-Rate (AMR-WB 6.60 kbps) | 132 | 211 | 1 | Interoperable Full-Rate (AMR-WB 8.85 kbps) | 177 | 212 | 2 | Interoperable Full-Rate (AMR-WB 12.65 kbps)| 253 | 213 | 3 | Full-Rate 13.3 kbps | 266 | 214 | 4 | Half-Rate 6.2 kbps | 124 | 215 | 5 | Quarter-Rate 2.7 kbps | 54 | 216 | 6 | Eighth-Rate 1.0 kbps | 20 | 217 | 7 | Full-Rate 8.55 kbps | 171 | 218 | 8 | Half-Rate 4.0 kbps | 80 | 219 | 9 | CNG (AMR-WB SID) | 35 | 220 | 10 | Eighth-Rate 0.8 kbps | 16 | 221 | 11 | (reserved) | - | 222 | 12 | (reserved) | - | 223 | 13 | (reserved) | - | 224 | 14 | Erasure (AMR-WB SPEECH_LOST) | 0 | 225 | 15 | Blank (AMR-WB NO_DATA) | 0 | 226 +----+--------------------------------------------+-------------------+ 227 Table 3:VMR-WB payload frame types for real-time transport 229 Note that the new entires replace the "reserved" entries in RFC xxxx 230 Tables 1 to 3 and there are no changes in the existing table entries 231 of RFC xxxx. 233 4.1 Implementation Considerations 235 Same as RFC xxxx 237 5. Congestion Control 239 Same as RFC xxxx 241 6. Security Considerations 243 Same as RFC xxxx 245 6.1. Confidentiality 247 Same as RFC xxxx 249 6.2. Authentication 251 Same as RFC xxxx 253 6.3. Decoding Validation and Provision for Lost or Late Packets 254 Same as RFC xxxx 256 7. Payload Format Parameters 258 Same as RFC xxxx. 260 7.1. VMR-WB RTP Payload MIME Registration 262 No MIME registration is required for the new mode of VMR-WB. The 263 only necessary update is in the definition of the optional MIME 264 parameter "mode-set" by adding the new operating mode. Note that 265 the addition of the new mode does not create any interoperability 266 issues since the modes of operation are negotiated and agreed 267 by the IP terminals through the offer-answer model provided in 268 Section 9.3 of RFC xxxx [2]. 270 mode-set: Requested VMR-WB operating mode set. Restricts 271 the active operating modes to a subset of all 272 modes. Possible values are a comma separated 273 list of integer values. Currently, this list 274 includes modes 0,1,2, 3, and 4 [1,2] but MAY be 275 extended in the future. If such mode-set is 276 specified during session initiation, the encoder 277 MUST NOT use modes outside of the subset. If not 278 present, all operating modes in the set 0 to 4 are 279 allowed for the session. 281 Encoding considerations: 283 Same as RFC xxxx 285 Security considerations: 287 Same as RFC xxxx 289 Public specification: 291 The VMR-WB speech codec is specified in following 292 3GPP2 specifications C.S0052-A version 1.0. 293 Transfer methods are specified in RFC xxxx. 295 Additional information: 297 Person & email address to contact for further information: 299 Sassan Ahmadi, Ph.D. Nokia Inc. USA 300 sassan.ahmadi@nokia.com 302 Intended usage: COMMON. 304 Same as RFC xxxx 306 Author/Change controller: 308 IETF Audio/Video Transport working group delegated from the IESG 310 7.2. Mapping MIME Parameters into SDP 312 Same as RFC xxxx 314 7.3. Offer-Answer Model Considerations 316 Same as RFC xxxx 318 8. IANA Considerations 320 None 322 References 324 Normative References 326 [1] 3GPP2 C.S0052-A v1.0 "Source-Controlled Variable-Rate 327 Multimode Wideband Speech Codec (VMR-WB) Service Options 328 62 and 63 for Spread Spectrum Systems", 3GPP2 Technical 329 Specification, April 2005. 331 [2] S. Ahmadi, "Real-Time Transport Protocol (RTP) Payload Formats 332 for the Variable-Rate Multimode Wideband (VMR-WB) Audio Codec", 333 RFC xxxx, Internet Engineering Task Force, May 2005. 335 [3] S. Bradner, "Key words for use in RFCs to Indicate 336 Requirement Levels", BCP 14, RFC 2119, Internet Engineering 337 Task Force, March 1997. 339 Informative References 341 [4] 3GPP2 C.S0050-A v1.0 "3GPP2 File Formats for Multimedia 342 Services", 3GPP2 Technical Specification, May 2005. 344 Any 3GPP2 document can be downloaded from the 3GPP2 web 345 server, "http://www.3gpp2.org/", see specifications. 347 Author's Address 349 The editor will serve as the point of contact for all 350 technical matters related to this document. 352 Dr. Sassan Ahmadi Phone: 1 (858) 831-5916 353 Fax: 1 (858) 831-5111 355 Nokia Inc. Email: sassan.ahmadi@nokia.com 356 12278 Scripps Summit Dr. 357 San Diego, CA 92131 USA 359 This Internet-Draft expires in six months from May 27, 2005. 361 RFC Editor Considerations 363 The RFC editor is requested to replace all occurrences of xxxx with 364 the RFC number that reference [2] will receive. 366 IPR Notice 368 The IETF takes no position regarding the validity or scope of any 369 Intellectual Property Rights or other rights that might be claimed 370 to pertain to the implementation or use of the technology described 371 in this document or the extent to which any license under such 372 rights might or might not be available; nor does it represent that 373 it has made any independent effort to identify any such rights. 374 Information on the procedures with respect to rights in RFC 375 documents can be found in BCP 78 and BCP 79. 376 Copies of IPR disclosures made to the IETF Secretariat and any 377 assurances of licenses to be made available, or the result of an 378 attempt made to obtain a general license or permission for the use 379 of such proprietary rights by implementers or users of this 380 specification can be obtained from the IETF on-line IPR repository 381 at http://www.ietf.org/ipr. 383 The IETF invites any interested party to bring to its attention any 384 copyrights, patents or patent applications, or other proprietary 385 rights that may cover technology that may be required to implement 386 this standard. Please address the information to the IETF at 387 ietf-ipr@ietf.org. 389 Copyright Notice 391 Copyright (C) The Internet Society (2005). This document is 392 subject to the rights, licenses and restrictions contained in BCP 393 78, and except as set forth therein, the authors retain all their 394 rights. 396 This document and the information contained herein are provided on 397 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 398 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 399 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 400 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 401 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 402 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 403 PARTICULAR PURPOSE.