idnits 2.17.1 draft-ietf-avt-rfc3047-bis-07.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, updated by RFC 4748 on line 465. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 476. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 483. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 489. 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 IETF Trust 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 14, 2008) is 5732 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. 'ITU.G7221' ** 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: 2 errors (**), 0 flaws (~~), 1 warning (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 AVT R. Even 3 Internet-Draft REL 4 Intended status: Standards Track P. Luthi 5 Expires: February 15, 2009 Tandberg 6 August 14, 2008 8 RTP Payload Format for ITU-T Recommendation G.722.1 9 draft-ietf-avt-rfc3047-bis-07.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 15, 2009. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2008). 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 describes 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 . . . . . . . . . . 7 57 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 58 4.1. Media Type Registration . . . . . . . . . . . . . . . . . 8 59 4.1.1. Registration of media type audio/G7221 . . . . . . . . 8 60 5. SDP Parameters . . . . . . . . . . . . . . . . . . . . . . . . 10 61 5.1. Usage with the SDP Offer Answer Model . . . . . . . . . . 10 62 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 63 7. Changes from RFC 3047 . . . . . . . . . . . . . . . . . . . . 12 64 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 65 9. RFC editor note . . . . . . . . . . . . . . . . . . . . . . . 14 66 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 67 10.1. Normative References . . . . . . . . . . . . . . . . . . . 15 68 10.2. Informative References . . . . . . . . . . . . . . . . . . 15 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 70 Intellectual Property and Copyright Statements . . . . . . . . . . 17 72 1. Introduction 74 ITU-T G.722.1 [ITU.G7221] is a low complexity coder, it compresses 50 75 Hz - 14 kHz audio signals into one of the following bit rates, 24 76 kbit/s, 32 kbit/s or 48 kbit/s. 78 The coder may be used for speech, music and other types of audio. 80 Some of the applications for which this coder is suitable are: 82 o Real-time communications such as videoconferencing and telephony. 84 o Streaming audio 86 o Archival and messaging 88 ITU-T G.722.1 [ITU.G7221] uses 20 ms frames and a sampling rate clock 89 of 16 kHz or 32kHz. The encoding and decoding algorithm can change 90 the bit rate at any 20ms frame boundary, but no bit rate change 91 notification is provided in-band with the bit stream. 93 For any given bit rate the number of bits in a frame is a constant. 94 Within this fixed frame, G.722.1 uses variable length coding (e.g. 95 Huffman coding) to represent most of the encoded parameters. All 96 variable length codes are transmitted in order from the left most 97 (most significant - MSB) bit to the right most (least significant - 98 LSB) bit, see [ITU.G7221] for more details. 100 The ITU-T standardized bit rates for G.722.1 are 24 kbit/s or 101 32kbit/s at 16 Khz sample rate, and 24 kbit/s, 32 kbit/s or 48 kbit/s 102 at 32 Khz sample rate. However, the coding algorithm itself has the 103 capability to run at any user specified bit rate (not just 24, 32 and 104 48 kbit/s) while maintaining an audio bandwidth of 50 Hz to 14 kHz. 105 This rate change is accomplished by a linear scaling of the codec 106 operation, resulting in frames with size in bits equal to 1/50 of the 107 corresponding bit rate. 109 2. Terminology 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in RFC2119 [RFC2119] and 114 indicate requirement levels for compliant RTP implementations. 116 3. RTP usage for G.722.1 118 3.1. RTP G.722.1 Header Fields 120 The RTP header is defined in the RTP specification [RFC3550]. This 121 section defines how fields in the RTP header are used. 123 Payload Type (PT): The assignment of an RTP payload type for this 124 packet format is outside the scope of this document; it is 125 specified by the RTP profile under which this payload format is 126 used, or signaled dynamically out-of-band (e.g., using SDP). 128 Marker (M) bit: The M bit is set to zero. 130 Extension (X) bit: Defined by the RTP profile used. 132 Timestamp: A 32-bit word that corresponds to the sampling instant 133 for the first frame in the RTP packet. The sampling frequency can 134 be 16 Khz or 32 Khz. The RTP timestamp clock frequency of 32 Khz 135 SHOULD be used unless only an RTP stream sampled at 16 Khz is 136 going to be sent. 138 3.2. RTP payload format for G.722.1 140 The RTP payload for G.722.1 has the format shown in Figure 1. No 141 additional header fields specific to this payload format are 142 required. 144 0 1 2 3 145 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 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 | RTP Header | 148 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 149 | | 150 + one or more frames of G.722.1 | 151 | .... | 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 Figure 1: RTP payload for G.722.1 156 Because bit rate is not signaled in-band, a separate out-of-band 157 method is REQUIRED to indicate the bit rate (see section 5 for an 158 example of signaling bit rate information using SDP). For the 159 payload format specified here, the bit rate MUST remain constant for 160 a particular payload type value. An application MAY switch bit rates 161 and clock rates from packet to packet by defining different payload 162 type value and switching between them. 164 The use of Huffman coding means that it is not possible to identify 165 the various encoded parameters/fields contained within the bit stream 166 without first completely decoding the entire frame. For the purposes 167 of packetizing the bit stream in RTP, it is only necessary to 168 consider the sequence of bits as output by the G.722.1 encoder, and 169 present the same sequence to the decoder. The payload format 170 described here maintains this sequence. 172 When operating at 24 kbit/s, 480 bits (60 octets) are produced per 173 frame. When operating at 32 kbit/s, 640 bits (80 octets) are 174 produced per frame. When operating at 48 kbit/s, 960 bits (120 175 octets) are produced per frame. Thus, all three bit rates allow for 176 octet alignment without the need for padding bits. 178 Figure 2 illustrates how the G.722.1 bit stream MUST be mapped into 179 an octet aligned RTP payload. 181 first bit last bit 182 transmitted transmitted 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 | | 185 + sequence of bits (480, 640 or 960) generated by the | 186 | G.722.1 encoder for transmission | 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 | | | | | 190 | | | ... | | 191 | | | | | 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+ 194 |MSB... LSB|MSB... LSB| |MSB... LSB| 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+ 196 RTP RTP RTP 197 octet 1 octet 2 octet 198 60, 80, 120 200 Figure 2: The G.722.1 encoder bit stream is split into 201 a sequence of octets (60, 80 or 120 depending on 202 the bit rate), and each octet is in turn 203 mapped into an RTP octet. 205 When operating at non-standard rates the payload format MUST follow 206 the guidelines illustrated in Figure 2. It is RECOMMENDED that 207 values in the range 16000 to 48000 be used. Non standard rates MUST 208 have a value that is a multiple of 400 (this maintains octet 209 alignment and does not then require (undefined) padding bits for each 210 frame if not octet aligned). For example, a bit rate of 16.4 kbit/s 211 will result in a frame of size 328 bits or 41 octets which are mapped 212 into RTP per Figure 2. 214 3.3. Multiple G.722.1 frames in a RTP packet 216 A sender may include more than one consecutive G.722.1 frame in a 217 single RTP packet. 219 Senders have the following additional restrictions: 221 o Sender SHOULD NOT include more G.722.1 frames in a single RTP 222 packet than will fit in the MTU of the RTP transport protocol. 224 o All frames contained in a single RTP packet MUST be of the same 225 length and sampled at the same clock rate. They MUST have the 226 same bit rate (octets per frame). 228 o Frames MUST NOT be split between RTP packets. 230 It is RECOMMENDED that the number of frames contained within an RTP 231 packet be consistent with the application. For example, in a 232 telephony application where delay is important, then the fewer frames 233 per packet the lower the delay, whereas for a delay insensitive 234 streaming or messaging application, many frames per packet would be 235 acceptable. 237 3.4. Computing the number of G.722.1 frames 239 Information describing the number of frames contained in an RTP 240 packet is not transmitted as part of the RTP payload. The only way 241 to determine the number of G.722.1 frames is to count the total 242 number of octets within the RTP packet, and divide the octet count by 243 the number of expected octets per frame. This expected octet per 244 frame count is derived from the bit rate, and is therefore a function 245 of the payload type. 247 4. IANA Considerations 249 This document updates the G7221 media type described in RFC3047. 251 4.1. Media Type Registration 253 This section describes the media types and names associated with this 254 payload format. The section registers the media types, as per 255 RFC4288 [RFC4288] 257 4.1.1. Registration of media type audio/G7221 259 Media type name: audio 261 Media subtype name: G7221 263 Required parameters: 265 bitrate: the data rate for the audio bit stream. This parameter 266 is mandatory because the bit rate is not signaled within the 267 G.722.1 bit stream. At the standard G.722.1 bit rates, the value 268 MUST be either 24000 or 32000 at 16 Khz sample rate, and 24000, 269 32000 or 48000 at 32 Khz sample rate. If using the non-standard 270 bit rates, then it is RECOMMENDED that values in the range 16000 271 to 48000 be used. Non standard rates MUST have a value that is a 272 multiple of 400 (this maintains octet alignment and does not then 273 require (undefined) padding bits for each frame if not octet 274 aligned). 276 Optional parameters: 278 rate: RTP timestamp clock rate, which is equal to the sampling 279 rate. If the parameter is not specified a clock rate of 16 Khz is 280 assumed. 282 ptime: see RFC 4566. SHOULD be a multiple of 20 msec. 284 maxptime: see RFC 4566. SHOULD be a multiple of 20 msec. 286 Encoding considerations: 288 This media type is framed and binary, see section 4.8 in 289 [RFC4288]. 291 Security considerations: See Section 6 293 Interoperability considerations: 295 Terminals SHOULD offer a media type at 16 Khz sample rate in order 296 to interoperate with terminals that do not support the new 32 Khz 297 sample rate. 299 Published specification: RFC yyy [see RFCeditor notes]. 301 Applications which use this media type: 303 Audio and Video streaming and conferencing applications. 305 Additional information: none 307 Person and email address to contact for further information : 309 Roni Even: roni.even@polycom.co.il 311 Intended usage: COMMON 313 Restrictions on usage: 315 This media type depends on RTP framing, and hence is only defined 316 for transfer via RTP [RFC3550]. Transport within other framing 317 protocols is not defined at this time. 319 Author: Roni Even 321 Change controller: 323 IETF Audio/Video Transport working group delegated from the IESG. 325 5. SDP Parameters 327 The media types audio/G7221 are mapped to fields in the Session 328 Description Protocol (SDP) [RFC4566] as follows: 330 o The media name in the "m=" line of SDP MUST be audio. 332 o The encoding name in the "a=rtpmap" line of SDP MUST be G7221 (the 333 media subtype). 335 o The clock rate in the "a=rtpmap" line MUST be 16000 or 32000. For 336 backward compatibility if the optional rate parameter is not 337 specified the RTP timestamp clock rate may be based on this 338 parameter. 340 o Only one bitrate SHALL be defined (using the "bitrate=" parameter 341 in the a=fmtp line) for each payload type. The optional "rate " 342 parameter may be added using a semicolon as a separator. 344 5.1. Usage with the SDP Offer Answer Model 346 When offering G.722.1 over RTP using SDP in an Offer/Answer model 347 [RFC3264] the following considerations are necessary. 349 The combination of the clock rate in the rtpmap and the bitrate 350 parameter defines the configuration of each payload type. Each 351 configuration intended to be used, MUST be declared. 353 There are two sampling clock rates defined for G.722.1 in this 354 document. RFC3047 [RFC3047] supported only the 16 Khz clock rate. 355 Therefore a system that wants to use G.722.1 SHOULD offer a payload 356 type with clock rate of 16000 for backward interoperability. 358 An example of an offer that includes a 16000 and 32000 clock rate is: 360 m=audio 49000 RTP/AVP 121 122 361 a=rtpmap:121 G7221/16000 362 a=fmtp:121 bitrate=24000 363 a=rtpmap:122 G7221/32000 ; rate=32000 364 a=fmtp:122 bitrate=48000 366 6. Security Considerations 368 RTP packets using the payload format defined in this specification 369 are subject to the security considerations discussed in the RTP 370 specification [RFC3550], and any appropriate RTP profile. This 371 implies that confidentiality of the media streams is achieved by 372 encryption. 374 A potential denial-of-service threat exists for data encoding using 375 compression techniques that have non-uniform receiver-end 376 computational load. The attacker can inject pathological datagrams 377 into the stream which are complex to decode and cause the receiver to 378 be overloaded. However, this encoding does not exhibit any 379 significant non-uniformity. 381 7. Changes from RFC 3047 383 The new draft obsoletes RFC3047 adding the support for the 384 Superwideband (14 Khz) audio support defined in annex C of the new 385 revision of ITU-T G.722.1. 387 Other changes 389 Update the text to be in line with the current rules for RFC and with 390 media type registration conforming to RFC 4288. 392 8. Acknowledgements 394 The authors would like to thank Tom Taylor for his contribution to 395 this work. 397 9. RFC editor note 399 Please replace RFC yyy giving the number assigned to this RFC. 401 10. References 403 10.1. Normative References 405 [ITU.G7221] 406 International Telecommunications Union, "Low-complexity 407 coding at 24 and 32 kbit/s for hands-free operation in 408 systems with low frame loss", ITU-T Recommendation 409 G.722.1, 2005. 411 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 412 Requirement Levels", BCP 14, RFC 2119, March 1997. 414 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 415 with Session Description Protocol (SDP)", RFC 3264, 416 June 2002. 418 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 419 Jacobson, "RTP: A Transport Protocol for Real-Time 420 Applications", STD 64, RFC 3550, July 2003. 422 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 423 Description Protocol", RFC 4566, July 2006. 425 10.2. Informative References 427 [RFC3047] Luthi, P., "RTP Payload Format for ITU-T Recommendation 428 G.722.1", RFC 3047, January 2001. 430 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and 431 Registration Procedures", BCP 13, RFC 4288, December 2005. 433 Authors' Addresses 435 Roni Even 436 REL 437 94 Derech Em Hamoshavot 438 Petach Tikva 49130 439 Israel 441 Email: ron.even.tlv@gmail.com 443 Patrick Luthi 444 Tandberg 445 Philip Pedersens vei 22 446 Lysaker 1366 447 Norway 449 Email: patrick.luthi@tandberg.no 451 Full Copyright Statement 453 Copyright (C) The IETF Trust (2008). 455 This document is subject to the rights, licenses and restrictions 456 contained in BCP 78, and except as set forth therein, the authors 457 retain all their rights. 459 This document and the information contained herein are provided on an 460 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 461 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 462 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 463 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 464 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 465 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 467 Intellectual Property 469 The IETF takes no position regarding the validity or scope of any 470 Intellectual Property Rights or other rights that might be claimed to 471 pertain to the implementation or use of the technology described in 472 this document or the extent to which any license under such rights 473 might or might not be available; nor does it represent that it has 474 made any independent effort to identify any such rights. Information 475 on the procedures with respect to rights in RFC documents can be 476 found in BCP 78 and BCP 79. 478 Copies of IPR disclosures made to the IETF Secretariat and any 479 assurances of licenses to be made available, or the result of an 480 attempt made to obtain a general license or permission for the use of 481 such proprietary rights by implementers or users of this 482 specification can be obtained from the IETF on-line IPR repository at 483 http://www.ietf.org/ipr. 485 The IETF invites any interested party to bring to its attention any 486 copyrights, patents or patent applications, or other proprietary 487 rights that may cover technology that may be required to implement 488 this standard. Please address the information to the IETF at 489 ietf-ipr@ietf.org. 491 Acknowledgment 493 Funding for the RFC Editor function is provided by the IETF 494 Administrative Support Activity (IASA).