idnits 2.17.1 draft-ietf-avt-rfc3047-bis-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 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 434. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 411. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 418. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 424. ** 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 (August 23, 2005) is 6821 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: '3' on line 327 -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU.G7221' ** Obsolete normative reference: RFC 2048 (Obsoleted by RFC 4288, RFC 4289) ** Obsolete normative reference: RFC 2327 (Obsoleted by RFC 4566) ** Obsolete normative reference: RFC 3047 (Obsoleted by RFC 5577) Summary: 6 errors (**), 0 flaws (~~), 2 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 AVT P. Luthi 3 Internet-Draft Tandberg 4 Expires: February 24, 2006 R. Even, Ed. 5 Polycom 6 August 23, 2005 8 RTP Payload Format for ITU-T Recommendation G.722.1 9 draft-ietf-avt-rfc3047-bis-00.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on February 24, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). 40 Abstract 42 International Telecommunication Union (ITU-T) Recommendation G.722.1 43 is a wide-band audio codec. This document describes the payload 44 format for including G.722.1 generated bit streams within an RTP 45 packet. The document also describe the syntax and semantics of the 46 SDP parameters needed to support G.722.1 audio codec. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 52 3. RTP payload format for G.722.1 . . . . . . . . . . . . . . . . 5 53 3.1. Multiple G.722.1 frames in a RTP packet . . . . . . . . . 7 54 3.2. Computing the number of G.722.1 frames . . . . . . . . . . 7 55 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 56 4.1. Registration of MIME media type audio/G7221 . . . . . . . 8 57 5. SDP Parameters . . . . . . . . . . . . . . . . . . . . . . . . 10 58 5.1. Usage with the SDP Offer Answer Model . . . . . . . . . . 10 59 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 60 7. Changes from RFC 3047 . . . . . . . . . . . . . . . . . . . . 12 61 8. Normative References . . . . . . . . . . . . . . . . . . . . . 12 62 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 63 Intellectual Property and Copyright Statements . . . . . . . . . . 14 65 1. Introduction 67 ITU-T G.722.1[ITU.G7221] is a low complexity coder, it compresses 68 50Hz - 14kHz audio signals into one of the following bit rates, 24 69 kbit/s, 32 kbit/s or 48 kbit/s. 71 The coder may be used for speech, music and other types of audio. 73 Some of the applications for which this coder is suitable are: 75 o Real-time communications such as videoconferencing and telephony. 77 o Streaming audio 79 o Archival and messaging 81 A fixed frame size of 20 ms is used, and for any given bit rate the 82 number of bits in a frame is a constant. 84 2. Terminology 86 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 87 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 88 document are to be interpreted as described in RFC2119[RFC2119] and 89 indicate requirement levels for compliant RTP implementations. 91 3. RTP payload format for G.722.1 93 ITU-T G.722.1[ITU.G7221] uses 20 ms frames and a sampling rate clock 94 of 16 kHz or 32kHz, so the RTP[RFC3550] timestamp MUST be in units of 95 1/16000 or 1/32000 of a second. The RTP payload for G.722.1 has the 96 format shown in Figure 1. No additional header specific to this 97 payload format is required. 99 0 1 2 3 100 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 101 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 102 | RTP Header [3] | 103 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 104 | | 105 + one or more frames of G.722.1 | 106 | .... | 107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 109 Figure 1: RTP payload for G.722.1 111 The encoding and decoding algorithm can change the bit rate at any 112 20ms frame boundary, but no bit rate change notification is provided 113 in-band with the bit stream. Therefore, a separate out-of-band 114 method is REQUIRED to indicate the bit rate (see section 6 for an 115 example of signaling bit rate information using SDP). For the 116 payload format specified here, the bit rate MUST remain constant for 117 a particular payload type value. An application MAY switch bit rates 118 from packet to packet by defining two payload type values and 119 switching between them. 121 The assignment of an RTP payload type for this new packet format is 122 outside the scope of this document, and will not be specified here. 123 It is expected that the RTP profile for a particular class of 124 applications will assign a payload type for this encoding, or if that 125 is not done then a payload type in the dynamic range shall be chosen. 127 The number of bits within a frame is fixed, and within this fixed 128 frame G.722.1 uses variable length coding (e.g., Huffman coding) to 129 represent most of the encoded parameters. All variable length codes 130 are transmitted in order from the left most (most significant - MSB) 131 bit to the right most (least significant - LSB) bit, see [ITU.G7221] 132 for more details. 134 The use of Huffman coding means that it is not possible to identify 135 the various encoded parameters/fields contained within the bit stream 136 without first completely decoding the entire frame. For the purposes 137 of packetizing the bit stream in RTP, it is only necessary to 138 consider the sequence of bits as output by the G.722.1 encoder, and 139 present the same sequence to the decoder. The payload format 140 described here maintains this sequence. 142 When operating at 24 kbit/s, 480 bits (60 octets) are produced per 143 frame. When operating at 32 kbit/s, 640 bits (80 octets) are 144 produced per frame. When operating at 48 kbit/s, 960 bits (120 145 octets) are produced per frame. Thus, all three bit rates allow for 146 octet alignment without the need for padding bits. 148 Figure 2 illustrates how the G.722.1 bit stream MUST be mapped into 149 an octet aligned RTP payload. 151 first bit last bit 152 transmitted transmitted 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 | | 155 + sequence of bits (480, 640 or 960) generated by the | 156 | G.722.1 encoder for transmission | 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 | | | | | 160 | | | ... | | 161 | | | | | 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+ 164 |MSB... LSB|MSB... LSB| |MSB... LSB| 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+ 166 RTP RTP RTP 167 octet 1 octet 2 octet 168 60, 80, 120 170 Figure 2: The G.722.1 encoder bit stream is split into 171 a sequence of octets (60, 80 or 120 depending on 172 the bit rate), and each octet is in turn 173 mapped into an RTP octet. 175 The ITU-T standardized bit rates for G.722.1 are 24 kbit/s or 176 32kbit/s at 16 Khz sample rate, and 24 kbit/s, 32 kbit/s or 48 kbit/s 177 at 32 Khz sample rate. However, the coding algorithm itself has the 178 capability to run at any user specified bit rate (not just 24, 32 and 179 48 kbit/s) while maintaining an audio bandwidth of 50 Hz to 14 kHz. 180 This rate change is accomplished by a linear scaling of the codec 181 operation, resulting in frames with size in bits equal to 1/50 of the 182 corresponding bit rate. 184 When operating at non-standard rates the payload format MUST follow 185 the guidelines illustrated in Figure 2. It is RECOMMENDED that 186 values in the range 16000 to 48000 be used, and that any value MUST 187 be a multiple of 400 (this maintains octet alignment and does not 188 then require (undefined) padding bits for each frame if not octet 189 aligned). For example, a bit rate of 16.4 kbit/s will result in a 190 frame of size 328 bits or 41 octets which are mapped into RTP per 191 Figure 2. 193 3.1. Multiple G.722.1 frames in a RTP packet 195 More than one G.722.1 frame may be included in a single RTP packet by 196 a sender. 198 Senders have the following additional restrictions: 200 o Sender SHOULD NOT include more G.722.1 frames in a single RTP 201 packet than will fit in the MTU of the RTP transport protocol. 203 o All frames contained in a single RTP packet MUST be of the same 204 length, that is they MUST have the same bit rate (octets per 205 frame). 207 o Frames MUST NOT be split between RTP packets. 209 It is RECOMMENDED that the number of frames contained within an RTP 210 packet be consistent with the application. For example, in a 211 telephony application where delay is important, then the fewer frames 212 per packet the lower the delay, whereas for a delay insensitive 213 streaming or messaging application, many frames per packet would be 214 acceptable. 216 3.2. Computing the number of G.722.1 frames 218 Information describing the number of frames contained in an RTP 219 packet is not transmitted as part of the RTP payload. The only way 220 to determine the number of G.722.1 frames is to count the total 221 number of octets within the RTP packet, and divide the octet count by 222 the number of expected octets per frame. 224 4. IANA Considerations 226 This section describes the media types and names associated with this 227 payload format. The section registers the media types, as per 228 RFC2048[RFC2048] 230 4.1. Registration of MIME media type audio/G7221 232 MIME media type name: audio 234 MIME subtype name: G7221 236 Required parameters: 238 bitrate: the data rate for the audio bit stream. This parameter 239 is mandatory because the bit rate is not signaled within the 240 G.722.1 bit stream. At the standard G.722.1 bit rates, the value 241 MUST be either 24000 or 32000 at 16 Khz sample rate, and 24000, 242 32000 or 48000 at 32 Khz sample rate. If using the non-standard 243 bit rates, then it is RECOMMENDED that values in the range 16000 244 to 48000 be used, and that any value MUST be a multiple of 400 245 (this maintains octet alignment and does not then require 246 (undefined) padding bits for each frame if not octet aligned). 248 Optional parameters: 250 ptime: RECOMMENDED duration of each packet in milliseconds. 252 Encoding considerations: 254 This type is only defined for transfer via RTP [RFC3550] 256 Security considerations: See Section 6 258 Interoperability considerations: 260 Terminals SHOULD offer a media type at 16 Khz sample rate in order 261 to interoperate with terminals that do not support the new 32 Khz 262 sample rate. 264 Published specification: See ITU-T Recommendation G.722.1 for 265 encoding algorithm details. 267 Applications which use this media type: 269 Audio and Video streaming and conferencing applications. 271 Additional information: none 272 Person and email address to contact for further information : 274 Roni Even: roni.even@polycom.co.il 276 Intended usage: COMMON 278 Restrictions on usage: None 280 Author: Roni Even 282 Change controller: 284 IETF Audio/Video Transport working group delegated from the IESG. 286 5. SDP Parameters 288 The media types audio/G7221 are mapped to fields in the Session 289 Description Protocol (SDP)[RFC2327] as follows: 291 o The media name in the "m=" line of SDP MUST be audio. 293 o The encoding name in the "a=rtpmap" line of SDP MUST be G7221 (the 294 MIME subtype). 296 o The clock rate in the "a=rtpmap" line MUST be 16000 or 32000. 298 o One optional parameter MUST be included in the "a=fmtp" line of 299 SDP. One bitrate SHALL be defined for each payload type. 301 5.1. Usage with the SDP Offer Answer Model 303 When offering G.722.1 over RTP using SDP in an Offer/Answer 304 model[RFC3264] the following considerations are necessary. 306 There are two clock rates defined for the updated G.722.1. 307 RFC3047[RFC3047] supported only the 16 Khz clock rate. Therefore a 308 system that wants to use G.722.1 SHOULD offer a payload type with 309 clock rate of 16000. 311 An example of an offer that includes a 16000 and 32000 clock rate is: 313 m=audio 49000 RTP/AVP 121 122 315 a=rtpmap:121 G7221/16000 317 a=fmtp:121 bitrate=24000 319 a=rtpmap:122 G7221/32000 321 a=fmtp:121 bitrate=48000 323 6. Security Considerations 325 RTP packets using the payload format defined in this specification 326 are subject to the security considerations discussed in the RTP 327 specification [3], and any appropriate RTP profile. This implies 328 that confidentiality of the media streams is achieved by encryption. 329 Because the data compression used with this payload format is applied 330 end-to-end, encryption may be performed after compression so there is 331 no conflict between the two operations. 333 A potential denial-of-service threat exists for data encodings using 334 compression techniques that have non-uniform receiver-end 335 computational load. The attacker can inject pathological datagrams 336 into the stream which are complex to decode and cause the receiver to 337 be overloaded. However, this encoding does not exhibit any 338 significant non-uniformity. 340 As with any IP-based protocol, in some circumstances a receiver may 341 be overloaded simply by the receipt of too many packets, either 342 desired or undesired. Network-layer authentication may be used to 343 discard packets from undesired sources, but the processing cost of 344 the authentication itself may be too high. 346 7. Changes from RFC 3047 348 The new draft updates RFC3047 adding the support for the Wideband 349 audio support defined in the new revision of ITU-T G.722.1. 351 Other changes 353 Update the text to be in line with the current rules for RFC. 355 8. Normative References 357 [ITU.G7221] 358 International Telecommunications Union, "Low-complexity 359 coding at 24 and 32 kbit/s for hands-free operation in 360 systems with low frame loss", ITU-T Recommendation 361 G.722.1, 2005. 363 [RFC2048] Freed, N., Klensin, J., and J. Postel, "Multipurpose 364 Internet Mail Extensions (MIME) Part Four: Registration 365 Procedures", BCP 13, RFC 2048, November 1996. 367 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 368 Requirement Levels", BCP 14, RFC 2119, March 1997. 370 [RFC2327] Handley, M. and V. Jacobson, "SDP: Session Description 371 Protocol", RFC 2327, April 1998. 373 [RFC3047] Luthi, P., "RTP Payload Format for ITU-T Recommendation 374 G.722.1", RFC 3047, January 2001. 376 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 377 with Session Description Protocol (SDP)", RFC 3264, 378 June 2002. 380 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 381 Jacobson, "RTP: A Transport Protocol for Real-Time 382 Applications", STD 64, RFC 3550, July 2003. 384 Authors' Addresses 386 Patrick Luthi 387 Tandberg 388 Philip Pedersens vei 22 389 Lysaker 1366 390 Norway 392 Email: patrick.luthi@tandberg.no 394 Roni Even (editor) 395 Polycom 396 94 Derech Em Hamoshavot 397 Petach Tikva 49130 398 Israel 400 Email: roni.even@polycom.co.il 402 Intellectual Property Statement 404 The IETF takes no position regarding the validity or scope of any 405 Intellectual Property Rights or other rights that might be claimed to 406 pertain to the implementation or use of the technology described in 407 this document or the extent to which any license under such rights 408 might or might not be available; nor does it represent that it has 409 made any independent effort to identify any such rights. Information 410 on the procedures with respect to rights in RFC documents can be 411 found in BCP 78 and BCP 79. 413 Copies of IPR disclosures made to the IETF Secretariat and any 414 assurances of licenses to be made available, or the result of an 415 attempt made to obtain a general license or permission for the use of 416 such proprietary rights by implementers or users of this 417 specification can be obtained from the IETF on-line IPR repository at 418 http://www.ietf.org/ipr. 420 The IETF invites any interested party to bring to its attention any 421 copyrights, patents or patent applications, or other proprietary 422 rights that may cover technology that may be required to implement 423 this standard. Please address the information to the IETF at 424 ietf-ipr@ietf.org. 426 Disclaimer of Validity 428 This document and the information contained herein are provided on an 429 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 430 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 431 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 432 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 433 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 434 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 436 Copyright Statement 438 Copyright (C) The Internet Society (2005). This document is subject 439 to the rights, licenses and restrictions contained in BCP 78, and 440 except as set forth therein, the authors retain all their rights. 442 Acknowledgment 444 Funding for the RFC Editor function is currently provided by the 445 Internet Society.