idnits 2.17.1 draft-ietf-avt-rfc3047-bis-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 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 447. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 458. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 465. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 471. ** 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 issues found here. 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 22, 2006) is 6456 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) -- Obsolete informational reference (is this intentional?): RFC 3047 (Obsoleted by RFC 5577) -- Obsolete informational reference (is this intentional?): RFC 4288 (Obsoleted by RFC 6838) Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 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 Intended status: Informational R. Even, Ed. 5 Expires: February 23, 2007 Polycom 6 August 22, 2006 8 RTP Payload Format for ITU-T Recommendation G.722.1 9 draft-ietf-avt-rfc3047-bis-02.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 23, 2007. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 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 usage for G.722.1 . . . . . . . . . . . . . . . . . . . . 5 53 3.1. RTP G.722.1 Header Fields . . . . . . . . . . . . . . . . 5 54 3.2. RTP payload format for G.722.1 . . . . . . . . . . . . . . 5 55 3.3. Multiple G.722.1 frames in a RTP packet . . . . . . . . . 7 56 3.4. Computing the number of G.722.1 frames . . . . . . . . . . 8 57 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 58 4.1. Media Type Registration . . . . . . . . . . . . . . . . . 9 59 4.1.1. Registration of MIME media type audio/G7221 . . . . . 9 60 5. SDP Parameters . . . . . . . . . . . . . . . . . . . . . . . . 11 61 5.1. Usage with the SDP Offer Answer Model . . . . . . . . . . 11 62 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 63 7. Changes from RFC 3047 . . . . . . . . . . . . . . . . . . . . 13 64 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 65 8.1. Normative References . . . . . . . . . . . . . . . . . . . 14 66 8.2. Informative References . . . . . . . . . . . . . . . . . . 14 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 68 Intellectual Property and Copyright Statements . . . . . . . . . . 16 70 1. Introduction 72 ITU-T G.722.1 [ITU.G7221] is a low complexity coder, it compresses 50 73 Hz - 14 kHz audio signals into one of the following bit rates, 24 74 kbit/s, 32 kbit/s or 48 kbit/s. 76 The coder may be used for speech, music and other types of audio. 78 Some of the applications for which this coder is suitable are: 80 o Real-time communications such as videoconferencing and telephony. 82 o Streaming audio 84 o Archival and messaging 86 A fixed frame size of 20 ms is used, and for any given bit rate the 87 number of bits in a frame is a constant. 89 2. Terminology 91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 93 document are to be interpreted as described in RFC2119 [RFC2119] and 94 indicate requirement levels for compliant RTP implementations. 96 3. RTP usage for G.722.1 98 ITU-T G.722.1 [ITU.G7221] uses 20 ms frames and a sampling rate clock 99 of 16 kHz or 32kHz. 101 3.1. RTP G.722.1 Header Fields 103 The RTP header is defined in the RTP specification [RFC3550]. This 104 section defines how fields in the RTP header are used. 106 Payload Type (PT): The assignment of an RTP payload type for this 107 packet format is outside the scope of this document; it is 108 specified by the RTP profile under which this payload format is 109 used, or signaled dynamically out-of-band (e.g., using SDP). 111 Marker (M) bit: The M bit is set to one to indicate that the RTP 112 packet payload contains at least one complete frame 114 Extension (X) bit: Defined by the RTP profile used. 116 Timestamp: A 32-bit word that corresponds to the sampling instant 117 for the first frame in the RTP packet. 119 3.2. RTP payload format for G.722.1 121 The RTP payload for G.722.1 has the format shown in Figure 1. No 122 additional header fields specific to this payload format are 123 required. 125 0 1 2 3 126 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 127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 128 | RTP Header | 129 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 130 | | 131 + one or more frames of G.722.1 | 132 | .... | 133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 135 Figure 1: RTP payload for G.722.1 137 The encoding and decoding algorithm can change the bit rate at any 138 20ms frame boundary, but no bit rate change notification is provided 139 in-band with the bit stream. Therefore, a separate out-of-band 140 method is REQUIRED to indicate the bit rate (see section 5 for an 141 example of signaling bit rate information using SDP). For the 142 payload format specified here, the bit rate MUST remain constant for 143 a particular payload type value. An application MAY switch bit rates 144 from packet to packet by defining two payload type values and 145 switching between them. 147 The assignment of an RTP payload type for this new packet format is 148 outside the scope of this document, and will not be specified here. 149 It is expected that the RTP profile for a particular class of 150 applications will assign a payload type for this encoding, or if that 151 is not done then a payload type in the dynamic range shall be chosen. 153 The number of bits within a frame is fixed, and within this fixed 154 frame, G.722.1 uses variable length coding (e.g. Huffman coding) to 155 represent most of the encoded parameters. All variable length codes 156 are transmitted in order from the left most (most significant - MSB) 157 bit to the right most (least significant - LSB) bit, see [ITU.G7221] 158 for more details. 160 The use of Huffman coding means that it is not possible to identify 161 the various encoded parameters/fields contained within the bit stream 162 without first completely decoding the entire frame. For the purposes 163 of packetizing the bit stream in RTP, it is only necessary to 164 consider the sequence of bits as output by the G.722.1 encoder, and 165 present the same sequence to the decoder. The payload format 166 described here maintains this sequence. 168 When operating at 24 kbit/s, 480 bits (60 octets) are produced per 169 frame. When operating at 32 kbit/s, 640 bits (80 octets) are 170 produced per frame. When operating at 48 kbit/s, 960 bits (120 171 octets) are produced per frame. Thus, all three bit rates allow for 172 octet alignment without the need for padding bits. 174 Figure 2 illustrates how the G.722.1 bit stream MUST be mapped into 175 an octet aligned RTP payload. 177 first bit last bit 178 transmitted transmitted 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 | | 181 + sequence of bits (480, 640 or 960) generated by the | 182 | G.722.1 encoder for transmission | 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 | | | | | 186 | | | ... | | 187 | | | | | 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+ 190 |MSB... LSB|MSB... LSB| |MSB... LSB| 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+ 192 RTP RTP RTP 193 octet 1 octet 2 octet 194 60, 80, 120 196 Figure 2: The G.722.1 encoder bit stream is split into 197 a sequence of octets (60, 80 or 120 depending on 198 the bit rate), and each octet is in turn 199 mapped into an RTP octet. 201 The ITU-T standardized bit rates for G.722.1 are 24 kbit/s or 202 32kbit/s at 16 Khz sample rate, and 24 kbit/s, 32 kbit/s or 48 kbit/s 203 at 32 Khz sample rate. However, the coding algorithm itself has the 204 capability to run at any user specified bit rate (not just 24, 32 and 205 48 kbit/s) while maintaining an audio bandwidth of 50 Hz to 14 kHz. 206 This rate change is accomplished by a linear scaling of the codec 207 operation, resulting in frames with size in bits equal to 1/50 of the 208 corresponding bit rate. 210 When operating at non-standard rates the payload format MUST follow 211 the guidelines illustrated in Figure 2. It is RECOMMENDED that 212 values in the range 16000 to 48000 be used, and that any value MUST 213 be a multiple of 400 (this maintains octet alignment and does not 214 then require (undefined) padding bits for each frame if not octet 215 aligned). For example, a bit rate of 16.4 kbit/s will result in a 216 frame of size 328 bits or 41 octets which are mapped into RTP per 217 Figure 2. 219 3.3. Multiple G.722.1 frames in a RTP packet 221 More than one consecutive G.722.1 frame may be included in a single 222 RTP packet by a sender. 224 Senders have the following additional restrictions: 226 o Sender SHOULD NOT include more G.722.1 frames in a single RTP 227 packet than will fit in the MTU of the RTP transport protocol. 229 o All frames contained in a single RTP packet MUST be of the same 230 length and sampled at the same clock rate. They MUST have the 231 same bit rate (octets per frame). 233 o Frames MUST NOT be split between RTP packets. 235 It is RECOMMENDED that the number of frames contained within an RTP 236 packet be consistent with the application. For example, in a 237 telephony application where delay is important, then the fewer frames 238 per packet the lower the delay, whereas for a delay insensitive 239 streaming or messaging application, many frames per packet would be 240 acceptable. 242 3.4. Computing the number of G.722.1 frames 244 Information describing the number of frames contained in an RTP 245 packet is not transmitted as part of the RTP payload. The only way 246 to determine the number of G.722.1 frames is to count the total 247 number of octets within the RTP packet, and divide the octet count by 248 the number of expected octets per frame. 250 4. IANA Considerations 252 This document updates the G7221 media type described in RFC3047. 254 4.1. Media Type Registration 256 This section describes the media types and names associated with this 257 payload format. The section registers the media types, as per 258 RFC4288 [RFC4288] 260 4.1.1. Registration of MIME media type audio/G7221 262 MIME media type name: audio 264 MIME subtype name: G7221 266 Required parameters: 268 bitrate: the data rate for the audio bit stream. This parameter 269 is mandatory because the bit rate is not signaled within the 270 G.722.1 bit stream. At the standard G.722.1 bit rates, the value 271 MUST be either 24000 or 32000 at 16 Khz sample rate, and 24000, 272 32000 or 48000 at 32 Khz sample rate. If using the non-standard 273 bit rates, then it is RECOMMENDED that values in the range 16000 274 to 48000 be used, and that any value MUST be a multiple of 400 275 (this maintains octet alignment and does not then require 276 (undefined) padding bits for each frame if not octet aligned). 278 Optional parameters: 280 ptime: see RFC 4566 282 maxptime: see RFC 4566 284 Encoding considerations: 286 This media type is framed and binary, see section 4.8 in 287 [RFC4288]. 289 Security considerations: See Section 6 291 Interoperability considerations: 293 Terminals SHOULD offer a media type at 16 Khz sample rate in order 294 to interoperate with terminals that do not support the new 32 Khz 295 sample rate. 297 Published specification: RFC yyy. 299 Applications which use this media type: 301 Audio and Video streaming and conferencing applications. 303 Additional information: none 305 Person and email address to contact for further information : 307 Roni Even: roni.even@polycom.co.il 309 Intended usage: COMMON 311 Restrictions on usage: 313 This media type depends on RTP framing, and hence is only defined 314 for transfer via RTP [RFC3550]. Transport within other framing 315 protocols is not defined at this time. 317 Author: Roni Even 319 Change controller: 321 IETF Audio/Video Transport working group delegated from the IESG. 323 5. SDP Parameters 325 The media types audio/G7221 are mapped to fields in the Session 326 Description Protocol (SDP) [RFC4566] as follows: 328 o The media name in the "m=" line of SDP MUST be audio. 330 o The encoding name in the "a=rtpmap" line of SDP MUST be G7221 (the 331 MIME subtype). 333 o The clock rate in the "a=rtpmap" line MUST be 16000 or 32000. 335 o Only one bitrate SHALL be defined for each payload type. 337 5.1. Usage with the SDP Offer Answer Model 339 When offering G.722.1 over RTP using SDP in an Offer/Answer model 340 [RFC3264] the following considerations are necessary. 342 The combination of the clock rate in the rtpmap and the bitrate 343 parameter defines the configuration of each payload type. Each 344 configuration intended to be used, MUST be declared. 346 There are two sampling clock rates defined for G.722.1 in this 347 document. RFC3047 [RFC3047] supported only the 16 Khz clock rate. 348 Therefore a system that wants to use G.722.1 SHOULD offer a payload 349 type with clock rate of 16000 for backward interoperability. 351 An example of an offer that includes a 16000 and 32000 clock rate is: 353 m=audio 49000 RTP/AVP 121 122 354 a=rtpmap:121 G7221/16000 355 a=fmtp:121 bitrate=24000 356 a=rtpmap:122 G7221/32000 357 a=fmtp:121 bitrate=48000 359 6. Security Considerations 361 RTP packets using the payload format defined in this specification 362 are subject to the security considerations discussed in the RTP 363 specification [RFC3550], and any appropriate RTP profile. This 364 implies that confidentiality of the media streams is achieved by 365 encryption. 367 A potential denial-of-service threat exists for data encoding using 368 compression techniques that have non-uniform receiver-end 369 computational load. The attacker can inject pathological datagrams 370 into the stream which are complex to decode and cause the receiver to 371 be overloaded. However, this encoding does not exhibit any 372 significant non-uniformity. 374 7. Changes from RFC 3047 376 The new draft updates RFC3047 adding the support for the Wideband 377 audio support defined in the new revision of ITU-T G.722.1. 379 Other changes 381 Update the text to be in line with the current rules for RFC. 383 8. References 385 8.1. Normative References 387 [ITU.G7221] 388 International Telecommunications Union, "Low-complexity 389 coding at 24 and 32 kbit/s for hands-free operation in 390 systems with low frame loss", ITU-T Recommendation 391 G.722.1, 2005. 393 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 394 Requirement Levels", BCP 14, RFC 2119, March 1997. 396 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 397 with Session Description Protocol (SDP)", RFC 3264, 398 June 2002. 400 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 401 Jacobson, "RTP: A Transport Protocol for Real-Time 402 Applications", STD 64, RFC 3550, July 2003. 404 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 405 Description Protocol", RFC 4566, July 2006. 407 8.2. Informative References 409 [RFC3047] Luthi, P., "RTP Payload Format for ITU-T Recommendation 410 G.722.1", RFC 3047, January 2001. 412 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and 413 Registration Procedures", BCP 13, RFC 4288, December 2005. 415 Authors' Addresses 417 Patrick Luthi 418 Tandberg 419 Philip Pedersens vei 22 420 Lysaker 1366 421 Norway 423 Email: patrick.luthi@tandberg.no 425 Roni Even (editor) 426 Polycom 427 94 Derech Em Hamoshavot 428 Petach Tikva 49130 429 Israel 431 Email: roni.even@polycom.co.il 433 Full Copyright Statement 435 Copyright (C) The Internet Society (2006). 437 This document is subject to the rights, licenses and restrictions 438 contained in BCP 78, and except as set forth therein, the authors 439 retain all their rights. 441 This document and the information contained herein are provided on an 442 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 443 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 444 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 445 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 446 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 447 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 449 Intellectual Property 451 The IETF takes no position regarding the validity or scope of any 452 Intellectual Property Rights or other rights that might be claimed to 453 pertain to the implementation or use of the technology described in 454 this document or the extent to which any license under such rights 455 might or might not be available; nor does it represent that it has 456 made any independent effort to identify any such rights. Information 457 on the procedures with respect to rights in RFC documents can be 458 found in BCP 78 and BCP 79. 460 Copies of IPR disclosures made to the IETF Secretariat and any 461 assurances of licenses to be made available, or the result of an 462 attempt made to obtain a general license or permission for the use of 463 such proprietary rights by implementers or users of this 464 specification can be obtained from the IETF on-line IPR repository at 465 http://www.ietf.org/ipr. 467 The IETF invites any interested party to bring to its attention any 468 copyrights, patents or patent applications, or other proprietary 469 rights that may cover technology that may be required to implement 470 this standard. Please address the information to the IETF at 471 ietf-ipr@ietf.org. 473 Acknowledgment 475 Funding for the RFC Editor function is provided by the IETF 476 Administrative Support Activity (IASA).