idnits 2.17.1 draft-even-avt-rfc3047-bis-01.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 433. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 410. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 417. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 423. ** 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 == It seems as if not all pages are separated by form feeds - found 0 form feeds but 14 pages 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 (June 20, 2005) is 6877 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 326 -- 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 (~~), 3 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: December 22, 2005 R. Even, Ed. 5 Polycom 6 June 20, 2005 8 RTP Payload Format for ITU-T Recommendation G.722.1 9 draft-even-avt-rfc3047-bis-01.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 December 22, 2005. 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 . . . . . . . . . . . . . . . . . . . . . . 12 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 is 239 mandatory because the bit rate is not signaled within the G.722.1 bit 240 stream. At the standard G.722.1 bit rates, the value MUST be either 241 24000 or 32000 at 16 Khz sample rate, and 24000, 32000 or 48000 at 242 32 Khz sample rate. If using the non-standard bit rates, then it is 243 RECOMMENDED that values in the range 16000 to 48000 be used, and that 244 any value MUST be a multiple of 400 (this maintains octet alignment 245 and does not then require (undefined) padding bits for each frame if 246 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: Terminals SHOULD offer a media type 259 at 16 Khz sample rate in order to interoperate with terminals that do 260 not support the new 32 Khz sample rate. 262 Published specification: See ITU-T Recommendation G.722.1 for 263 encoding algorithm details. 265 Applications which use this media type: 267 Audio and Video streaming and conferencing applications. 269 Additional information: none 271 Person and email address to contact for further information : 273 Roni Even: roni.even@polycom.co.il 275 Intended usage: COMMON 277 Author: 279 Roni Even 281 Change controller: 283 IETF Audio/Video Transport working group delegated from the IESG. 285 5. SDP Parameters 287 The media types audio/G7221 are mapped to fields in the Session 288 Description Protocol (SDP)[RFC2327] as follows: 290 o The media name in the "m=" line of SDP MUST be audio. 292 o The encoding name in the "a=rtpmap" line of SDP MUST be G7221 (the 293 MIME subtype). 295 o The clock rate in the "a=rtpmap" line MUST be 16000 or 32000. 297 o One optional parameter MUST be included in the "a=fmtp" line of 298 SDP. One bitrate SHALL be defined for each payload type. 300 5.1 Usage with the SDP Offer Answer Model 302 When offering G.722.1 over RTP using SDP in an Offer/Answer 303 model[RFC3264] the following considerations are necessary. 305 There are two clock rates defined for the updated G.722.1. 306 RFC3047[RFC3047] supported only the 16 Khz clock rate. Therefore a 307 system that wants to use G.722.1 SHOULD offer a payload type with 308 clock rate of 16000. 310 An example of an offer that includes a 16000 and 32000 clock rate is: 312 m=audio 49000 RTP/AVP 121 122 314 a=rtpmap:121 G7221/16000 316 a=fmtp:121 bitrate=24000 318 a=rtpmap:122 G7221/32000 320 a=fmtp:121 bitrate=48000 322 6. Security Considerations 324 RTP packets using the payload format defined in this specification 325 are subject to the security considerations discussed in the RTP 326 specification [3], and any appropriate RTP profile. This implies 327 that confidentiality of the media streams is achieved by encryption. 328 Because the data compression used with this payload format is applied 329 end-to-end, encryption may be performed after compression so there is 330 no conflict between the two operations. 332 A potential denial-of-service threat exists for data encodings using 333 compression techniques that have non-uniform receiver-end 334 computational load. The attacker can inject pathological datagrams 335 into the stream which are complex to decode and cause the receiver to 336 be overloaded. However, this encoding does not exhibit any 337 significant non-uniformity. 339 As with any IP-based protocol, in some circumstances a receiver may 340 be overloaded simply by the receipt of too many packets, either 341 desired or undesired. Network-layer authentication may be used to 342 discard packets from undesired sources, but the processing cost of 343 the authentication itself may be too high. 345 7. Changes from RFC 3047 347 The new draft updates RFC3047 adding the support for the Wideband 348 audio support defined in the new revision of ITU-T G.722.1. 350 Other changes 352 Update the text to be in line with the current rules for RFC. 354 8. Normative References 356 [ITU.G7221] 357 International Telecommunications Union, "Low-complexity 358 coding at 24 and 32 kbit/s for hands-free operation in 359 systems with low frame loss", ITU-T Recommendation 360 G.722.1, 2005. 362 [RFC2048] Freed, N., Klensin, J., and J. Postel, "Multipurpose 363 Internet Mail Extensions (MIME) Part Four: Registration 364 Procedures", BCP 13, RFC 2048, November 1996. 366 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 367 Requirement Levels", BCP 14, RFC 2119, March 1997. 369 [RFC2327] Handley, M. and V. Jacobson, "SDP: Session Description 370 Protocol", RFC 2327, April 1998. 372 [RFC3047] Luthi, P., "RTP Payload Format for ITU-T Recommendation 373 G.722.1", RFC 3047, January 2001. 375 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 376 with Session Description Protocol (SDP)", RFC 3264, 377 June 2002. 379 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 380 Jacobson, "RTP: A Transport Protocol for Real-Time 381 Applications", STD 64, RFC 3550, July 2003. 383 Authors' Addresses 385 Patrick Luthi 386 Tandberg 387 Philip Pedersens vei 22 388 Lysaker 1366 389 Norway 391 Email: patrick.luthi@tandberg.no 393 Roni Even (editor) 394 Polycom 395 94 Derech Em Hamoshavot 396 Petach Tikva 49130 397 Israel 399 Email: roni.even@polycom.co.il 401 Intellectual Property Statement 403 The IETF takes no position regarding the validity or scope of any 404 Intellectual Property Rights or other rights that might be claimed to 405 pertain to the implementation or use of the technology described in 406 this document or the extent to which any license under such rights 407 might or might not be available; nor does it represent that it has 408 made any independent effort to identify any such rights. Information 409 on the procedures with respect to rights in RFC documents can be 410 found in BCP 78 and BCP 79. 412 Copies of IPR disclosures made to the IETF Secretariat and any 413 assurances of licenses to be made available, or the result of an 414 attempt made to obtain a general license or permission for the use of 415 such proprietary rights by implementers or users of this 416 specification can be obtained from the IETF on-line IPR repository at 417 http://www.ietf.org/ipr. 419 The IETF invites any interested party to bring to its attention any 420 copyrights, patents or patent applications, or other proprietary 421 rights that may cover technology that may be required to implement 422 this standard. Please address the information to the IETF at 423 ietf-ipr@ietf.org. 425 Disclaimer of Validity 427 This document and the information contained herein are provided on an 428 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 429 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 430 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 431 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 432 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 433 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 435 Copyright Statement 437 Copyright (C) The Internet Society (2005). This document is subject 438 to the rights, licenses and restrictions contained in BCP 78, and 439 except as set forth therein, the authors retain all their rights. 441 Acknowledgment 443 Funding for the RFC Editor function is currently provided by the 444 Internet Society.