idnits 2.17.1 draft-ietf-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 458. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 435. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 442. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 448. ** 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 (January 25, 2006) is 6666 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 105 -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU.G7221' ** Obsolete normative reference: RFC 2327 (Obsoleted by RFC 4566) ** Obsolete normative reference: RFC 3047 (Obsoleted by RFC 5577) -- Obsolete informational reference (is this intentional?): RFC 4288 (Obsoleted by RFC 6838) Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 10 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: July 29, 2006 R. Even, Ed. 5 Polycom 6 January 25, 2006 8 RTP Payload Format for ITU-T Recommendation G.722.1 9 draft-ietf-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 July 29, 2006. 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 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. Media Type Registration . . . . . . . . . . . . . . . . . 8 57 4.1.1. Registration of MIME media type audio/G7221 . . . . . 8 58 5. SDP Parameters . . . . . . . . . . . . . . . . . . . . . . . . 10 59 5.1. Usage with the SDP Offer Answer Model . . . . . . . . . . 10 60 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 61 7. Changes from RFC 3047 . . . . . . . . . . . . . . . . . . . . 12 62 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 63 8.1. Normative References . . . . . . . . . . . . . . . . . . . 13 64 8.2. Informative References . . . . . . . . . . . . . . . . . . 13 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 66 Intellectual Property and Copyright Statements . . . . . . . . . . 15 68 1. Introduction 70 ITU-T G.722.1 [ITU.G7221] is a low complexity coder, it compresses 71 50Hz - 14kHz audio signals into one of the following bit rates, 24 72 kbit/s, 32 kbit/s or 48 kbit/s. 74 The coder may be used for speech, music and other types of audio. 76 Some of the applications for which this coder is suitable are: 78 o Real-time communications such as videoconferencing and telephony. 80 o Streaming audio 82 o Archival and messaging 84 A fixed frame size of 20 ms is used, and for any given bit rate the 85 number of bits in a frame is a constant. 87 2. Terminology 89 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 90 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 91 document are to be interpreted as described in RFC2119 [RFC2119] and 92 indicate requirement levels for compliant RTP implementations. 94 3. RTP payload format for G.722.1 96 ITU-T G.722.1 [ITU.G7221] uses 20 ms frames and a sampling rate clock 97 of 16 kHz or 32kHz, so the RTP [RFC3550] timestamp MUST be in units 98 of 1/16000 or 1/32000 of a second. The RTP payload for G.722.1 has 99 the format shown in Figure 1. No additional header specific to this 100 payload format is required. 102 0 1 2 3 103 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 104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 105 | RTP Header [3] | 106 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 107 | | 108 + one or more frames of G.722.1 | 109 | .... | 110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 112 Figure 1: RTP payload for G.722.1 114 The encoding and decoding algorithm can change the bit rate at any 115 20ms frame boundary, but no bit rate change notification is provided 116 in-band with the bit stream. Therefore, a separate out-of-band 117 method is REQUIRED to indicate the bit rate (see section 6 for an 118 example of signaling bit rate information using SDP). For the 119 payload format specified here, the bit rate MUST remain constant for 120 a particular payload type value. An application MAY switch bit rates 121 from packet to packet by defining two payload type values and 122 switching between them. 124 The assignment of an RTP payload type for this new packet format is 125 outside the scope of this document, and will not be specified here. 126 It is expected that the RTP profile for a particular class of 127 applications will assign a payload type for this encoding, or if that 128 is not done then a payload type in the dynamic range shall be chosen. 130 The number of bits within a frame is fixed, and within this fixed 131 frame G.722.1 uses variable length coding (e.g., Huffman coding) to 132 represent most of the encoded parameters. All variable length codes 133 are transmitted in order from the left most (most significant - MSB) 134 bit to the right most (least significant - LSB) bit, see [ITU.G7221] 135 for more details. 137 The use of Huffman coding means that it is not possible to identify 138 the various encoded parameters/fields contained within the bit stream 139 without first completely decoding the entire frame. For the purposes 140 of packetizing the bit stream in RTP, it is only necessary to 141 consider the sequence of bits as output by the G.722.1 encoder, and 142 present the same sequence to the decoder. The payload format 143 described here maintains this sequence. 145 When operating at 24 kbit/s, 480 bits (60 octets) are produced per 146 frame. When operating at 32 kbit/s, 640 bits (80 octets) are 147 produced per frame. When operating at 48 kbit/s, 960 bits (120 148 octets) are produced per frame. Thus, all three bit rates allow for 149 octet alignment without the need for padding bits. 151 Figure 2 illustrates how the G.722.1 bit stream MUST be mapped into 152 an octet aligned RTP payload. 154 first bit last bit 155 transmitted transmitted 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 | | 158 + sequence of bits (480, 640 or 960) generated by the | 159 | G.722.1 encoder for transmission | 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 | | | | | 163 | | | ... | | 164 | | | | | 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+ 167 |MSB... LSB|MSB... LSB| |MSB... LSB| 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+ 169 RTP RTP RTP 170 octet 1 octet 2 octet 171 60, 80, 120 173 Figure 2: The G.722.1 encoder bit stream is split into 174 a sequence of octets (60, 80 or 120 depending on 175 the bit rate), and each octet is in turn 176 mapped into an RTP octet. 178 The ITU-T standardized bit rates for G.722.1 are 24 kbit/s or 179 32kbit/s at 16 Khz sample rate, and 24 kbit/s, 32 kbit/s or 48 kbit/s 180 at 32 Khz sample rate. However, the coding algorithm itself has the 181 capability to run at any user specified bit rate (not just 24, 32 and 182 48 kbit/s) while maintaining an audio bandwidth of 50 Hz to 14 kHz. 183 This rate change is accomplished by a linear scaling of the codec 184 operation, resulting in frames with size in bits equal to 1/50 of the 185 corresponding bit rate. 187 When operating at non-standard rates the payload format MUST follow 188 the guidelines illustrated in Figure 2. It is RECOMMENDED that 189 values in the range 16000 to 48000 be used, and that any value MUST 190 be a multiple of 400 (this maintains octet alignment and does not 191 then require (undefined) padding bits for each frame if not octet 192 aligned). For example, a bit rate of 16.4 kbit/s will result in a 193 frame of size 328 bits or 41 octets which are mapped into RTP per 194 Figure 2. 196 3.1. Multiple G.722.1 frames in a RTP packet 198 More than one G.722.1 frame may be included in a single RTP packet by 199 a sender. 201 Senders have the following additional restrictions: 203 o Sender SHOULD NOT include more G.722.1 frames in a single RTP 204 packet than will fit in the MTU of the RTP transport protocol. 206 o All frames contained in a single RTP packet MUST be of the same 207 length, that is they MUST have the same bit rate (octets per 208 frame). 210 o Frames MUST NOT be split between RTP packets. 212 It is RECOMMENDED that the number of frames contained within an RTP 213 packet be consistent with the application. For example, in a 214 telephony application where delay is important, then the fewer frames 215 per packet the lower the delay, whereas for a delay insensitive 216 streaming or messaging application, many frames per packet would be 217 acceptable. 219 3.2. Computing the number of G.722.1 frames 221 Information describing the number of frames contained in an RTP 222 packet is not transmitted as part of the RTP payload. The only way 223 to determine the number of G.722.1 frames is to count the total 224 number of octets within the RTP packet, and divide the octet count by 225 the number of expected octets per frame. 227 4. IANA Considerations 229 This document updates the G7221 media type described in RFC3047. 231 4.1. Media Type Registration 233 This section describes the media types and names associated with this 234 payload format. The section registers the media types, as per 235 RFC4288 [RFC4288] 237 4.1.1. Registration of MIME media type audio/G7221 239 MIME media type name: audio 241 MIME subtype name: G7221 243 Required parameters: 245 bitrate: the data rate for the audio bit stream. This parameter 246 is mandatory because the bit rate is not signaled within the 247 G.722.1 bit stream. At the standard G.722.1 bit rates, the value 248 MUST be either 24000 or 32000 at 16 Khz sample rate, and 24000, 249 32000 or 48000 at 32 Khz sample rate. If using the non-standard 250 bit rates, then it is RECOMMENDED that values in the range 16000 251 to 48000 be used, and that any value MUST be a multiple of 400 252 (this maintains octet alignment and does not then require 253 (undefined) padding bits for each frame if not octet aligned). 255 Optional parameters: 257 ptime: RECOMMENDED duration of each packet in milliseconds. 259 Encoding considerations: 261 This media type is framed and binary, see section 4.8 in 262 [RFC4288]. 264 Security considerations: See Section 6 266 Interoperability considerations: 268 Terminals SHOULD offer a media type at 16 Khz sample rate in order 269 to interoperate with terminals that do not support the new 32 Khz 270 sample rate. 272 Published specification: RFC yyy. 274 Applications which use this media type: 276 Audio and Video streaming and conferencing applications. 278 Additional information: none 280 Person and email address to contact for further information : 282 Roni Even: roni.even@polycom.co.il 284 Intended usage: COMMON 286 Restrictions on usage: 288 This media type depends on RTP framing, and hence is only defined 289 for transfer via RTP [RFC3550]. Transport within other framing 290 protocols is not defined at this time. 292 Author: Roni Even 294 Change controller: 296 IETF Audio/Video Transport working group delegated from the IESG. 298 5. SDP Parameters 300 The media types audio/G7221 are mapped to fields in the Session 301 Description Protocol (SDP) [RFC2327] as follows: 303 o The media name in the "m=" line of SDP MUST be audio. 305 o The encoding name in the "a=rtpmap" line of SDP MUST be G7221 (the 306 MIME subtype). 308 o The clock rate in the "a=rtpmap" line MUST be 16000 or 32000. 310 o One optional parameter MUST be included in the "a=fmtp" line of 311 SDP. One bitrate SHALL be defined for each payload type. 313 5.1. Usage with the SDP Offer Answer Model 315 When offering G.722.1 over RTP using SDP in an Offer/Answer model 316 [RFC3264] the following considerations are necessary. 318 There are two clock rates defined for the updated G.722.1. RFC3047 319 [RFC3047] supported only the 16 Khz clock rate. Therefore a system 320 that wants to use G.722.1 SHOULD offer a payload type with clock rate 321 of 16000. 323 An example of an offer that includes a 16000 and 32000 clock rate is: 325 m=audio 49000 RTP/AVP 121 122 327 a=rtpmap:121 G7221/16000 329 a=fmtp:121 bitrate=24000 331 a=rtpmap:122 G7221/32000 333 a=fmtp:121 bitrate=48000 335 6. Security Considerations 337 RTP packets using the payload format defined in this specification 338 are subject to the security considerations discussed in the RTP 339 specification [RFC3550], and any appropriate RTP profile. As this 340 format transports encoded audio, the main security issues include 341 confidentiality, integrity protection, and data origin authentication 342 of the audio itself. The payload format itself does not have any 343 built-in security mechanisms. Any suitable external mechanisms, such 344 as SRTP [RFC3711], MAY be used. Because the data compression used 345 with this payload format is applied end-to-end, encryption will be 346 performed after compression so there is no conflict between the two 347 operations. 349 A potential denial-of-service threat exists for data encoding using 350 compression techniques that have non-uniform receiver-end 351 computational load. The attacker can inject pathological datagrams 352 into the stream which are complex to decode and cause the receiver to 353 be overloaded. However, this encoding does not exhibit any 354 significant non-uniformity and thus are unlikely to pose a denial-of- 355 service threat due to the receipt of pathological data. . 357 Note that the appropriate mechanism to ensure confidentiality and 358 integrity of RTP packets and their payloads is very dependent on the 359 application and on the transport and signaling protocols employed. 360 Thus, although SRTP is given as an example above, other possible 361 choices exist. 363 7. Changes from RFC 3047 365 The new draft updates RFC3047 adding the support for the Wideband 366 audio support defined in the new revision of ITU-T G.722.1. 368 Other changes 370 Update the text to be in line with the current rules for RFC. 372 8. References 374 8.1. Normative References 376 [ITU.G7221] 377 International Telecommunications Union, "Low-complexity 378 coding at 24 and 32 kbit/s for hands-free operation in 379 systems with low frame loss", ITU-T Recommendation 380 G.722.1, 2005. 382 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 383 Requirement Levels", BCP 14, RFC 2119, March 1997. 385 [RFC2327] Handley, M. and V. Jacobson, "SDP: Session Description 386 Protocol", RFC 2327, April 1998. 388 [RFC3047] Luthi, P., "RTP Payload Format for ITU-T Recommendation 389 G.722.1", RFC 3047, January 2001. 391 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 392 with Session Description Protocol (SDP)", RFC 3264, 393 June 2002. 395 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 396 Jacobson, "RTP: A Transport Protocol for Real-Time 397 Applications", STD 64, RFC 3550, July 2003. 399 8.2. Informative References 401 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 402 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 403 RFC 3711, March 2004. 405 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and 406 Registration Procedures", BCP 13, RFC 4288, December 2005. 408 Authors' Addresses 410 Patrick Luthi 411 Tandberg 412 Philip Pedersens vei 22 413 Lysaker 1366 414 Norway 416 Email: patrick.luthi@tandberg.no 418 Roni Even (editor) 419 Polycom 420 94 Derech Em Hamoshavot 421 Petach Tikva 49130 422 Israel 424 Email: roni.even@polycom.co.il 426 Intellectual Property Statement 428 The IETF takes no position regarding the validity or scope of any 429 Intellectual Property Rights or other rights that might be claimed to 430 pertain to the implementation or use of the technology described in 431 this document or the extent to which any license under such rights 432 might or might not be available; nor does it represent that it has 433 made any independent effort to identify any such rights. Information 434 on the procedures with respect to rights in RFC documents can be 435 found in BCP 78 and BCP 79. 437 Copies of IPR disclosures made to the IETF Secretariat and any 438 assurances of licenses to be made available, or the result of an 439 attempt made to obtain a general license or permission for the use of 440 such proprietary rights by implementers or users of this 441 specification can be obtained from the IETF on-line IPR repository at 442 http://www.ietf.org/ipr. 444 The IETF invites any interested party to bring to its attention any 445 copyrights, patents or patent applications, or other proprietary 446 rights that may cover technology that may be required to implement 447 this standard. Please address the information to the IETF at 448 ietf-ipr@ietf.org. 450 Disclaimer of Validity 452 This document and the information contained herein are provided on an 453 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 454 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 455 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 456 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 457 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 458 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 460 Copyright Statement 462 Copyright (C) The Internet Society (2006). This document is subject 463 to the rights, licenses and restrictions contained in BCP 78, and 464 except as set forth therein, the authors retain all their rights. 466 Acknowledgment 468 Funding for the RFC Editor function is currently provided by the 469 Internet Society.