idnits 2.17.1 draft-ietf-avt-rfc3047-bis-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document obsoletes RFC3047, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 11, 2009) is 5494 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) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 AVT P. Luthi 3 Internet-Draft Tandberg 4 Obsoletes: 3047 (If approved) R. Even 5 (if approved) Gesher Erove Ltd 6 Intended status: Standards Track April 11, 2009 7 Expires: October 13, 2009 9 RTP Payload Format for ITU-T Recommendation G.722.1 10 draft-ietf-avt-rfc3047-bis-09.txt 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and BCP 79. This document may contain material 16 from IETF Documents or IETF Contributions published or made publicly 17 available before November 10, 2008. The person(s) controlling the 18 copyright in some of this material may not have granted the IETF 19 Trust the right to allow modifications of such material outside the 20 IETF Standards Process. Without obtaining an adequate license from 21 the person(s) controlling the copyright in such materials, this 22 document may not be modified outside the IETF Standards Process, and 23 derivative works of it may not be created outside the IETF Standards 24 Process, except to format it for publication as an RFC or to 25 translate it into languages other than English. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt. 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html. 43 This Internet-Draft will expire on October 13, 2009. 45 Copyright Notice 47 Copyright (c) 2009 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents in effect on the date of 52 publication of this document (http://trustee.ietf.org/license-info). 53 Please review these documents carefully, as they describe your rights 54 and restrictions with respect to this document. 56 Abstract 58 International Telecommunication Union (ITU-T) Recommendation G.722.1 59 is a wide-band audio codec. This document describes the payload 60 format for including G.722.1 generated bit streams within an RTP 61 packet. The document also describes the syntax and semantics of the 62 SDP parameters needed to support G.722.1 audio codec. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 3. RTP usage for G.722.1 . . . . . . . . . . . . . . . . . . . . 6 69 3.1. RTP G.722.1 Header Fields . . . . . . . . . . . . . . . . 6 70 3.2. RTP payload format for G.722.1 . . . . . . . . . . . . . . 6 71 3.3. Multiple G.722.1 frames in a RTP packet . . . . . . . . . 8 72 3.4. Computing the number of G.722.1 frames . . . . . . . . . . 8 73 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 74 4.1. Media Type Registration . . . . . . . . . . . . . . . . . 9 75 4.1.1. Registration of media type audio/G7221 . . . . . . . . 9 76 5. SDP Parameters . . . . . . . . . . . . . . . . . . . . . . . . 11 77 5.1. Usage with the SDP Offer Answer Model . . . . . . . . . . 11 78 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 79 7. Changes from RFC 3047 . . . . . . . . . . . . . . . . . . . . 13 80 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 81 9. RFC editor note . . . . . . . . . . . . . . . . . . . . . . . 15 82 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 83 10.1. Normative References . . . . . . . . . . . . . . . . . . . 16 84 10.2. Informative References . . . . . . . . . . . . . . . . . . 16 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 87 1. Introduction 89 ITU-T G.722.1 [ITU.G7221] is a low complexity coder, it compresses 50 90 Hz - 14 kHz audio signals into one of the following bit rates, 24 91 kbit/s, 32 kbit/s or 48 kbit/s. 93 The coder may be used for speech, music and other types of audio. 95 Some of the applications for which this coder is suitable are: 97 o Real-time communications such as videoconferencing and telephony. 99 o Streaming audio 101 o Archival and messaging 103 ITU-T G.722.1 [ITU.G7221] uses 20 ms frames and a sampling rate clock 104 of 16 kHz or 32kHz. The encoding and decoding algorithm can change 105 the bit rate at any 20ms frame boundary, but no bit rate change 106 notification is provided in-band with the bit stream. 108 For any given bit rate the number of bits in a frame is a constant. 109 Within this fixed frame, G.722.1 uses variable length coding (e.g. 110 Huffman coding) to represent most of the encoded parameters. All 111 variable length codes are transmitted in order from the left most 112 (most significant - MSB) bit to the right most (least significant - 113 LSB) bit, see [ITU.G7221] for more details. 115 The ITU-T standardized bit rates for G.722.1 are 24 kbit/s or 116 32kbit/s at 16 Khz sample rate, and 24 kbit/s, 32 kbit/s or 48 kbit/s 117 at 32 Khz sample rate. However, the coding algorithm itself has the 118 capability to run at any user specified bit rate (not just 24, 32 and 119 48 kbit/s) while maintaining an audio bandwidth of 50 Hz to 14 kHz. 120 This rate change is accomplished by a linear scaling of the codec 121 operation, resulting in frames with size in bits equal to 1/50 of the 122 corresponding bit rate. 124 2. Terminology 126 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 127 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 128 document are to be interpreted as described in RFC2119 [RFC2119] and 129 indicate requirement levels for compliant RTP implementations. 131 3. RTP usage for G.722.1 133 3.1. RTP G.722.1 Header Fields 135 The RTP header is defined in the RTP specification [RFC3550]. This 136 section defines how fields in the RTP header are used. 138 Payload Type (PT): The assignment of an RTP payload type for this 139 packet format is outside the scope of this document; it is 140 specified by the RTP profile under which this payload format is 141 used, or signaled dynamically out-of-band (e.g., using SDP). 143 Marker (M) bit: The M bit is set to zero. 145 Extension (X) bit: Defined by the RTP profile used. 147 Timestamp: A 32-bit word that corresponds to the sampling instant 148 for the first frame in the RTP packet. The sampling frequency can 149 be 16 Khz or 32 Khz. The RTP timestamp clock frequency of 32 Khz 150 SHOULD be used unless only an RTP stream sampled at 16 Khz is 151 going to be sent. 153 3.2. RTP payload format for G.722.1 155 The RTP payload for G.722.1 has the format shown in Figure 1. No 156 additional header fields specific to this payload format are 157 required. 159 0 1 2 3 160 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 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 | RTP Header | 163 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 164 | | 165 + one or more frames of G.722.1 | 166 | .... | 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 Figure 1: RTP payload for G.722.1 171 Because bit rate is not signaled in-band, a separate out-of-band 172 method is REQUIRED to indicate the bit rate (see section 5 for an 173 example of signaling bit rate information using SDP). For the 174 payload format specified here, the bit rate MUST remain constant for 175 a particular payload type value. An application MAY switch bit rates 176 and clock rates from packet to packet by defining different payload 177 type value and switching between them. 179 The use of Huffman coding means that it is not possible to identify 180 the various encoded parameters/fields contained within the bit stream 181 without first completely decoding the entire frame. For the purposes 182 of packetizing the bit stream in RTP, it is only necessary to 183 consider the sequence of bits as output by the G.722.1 encoder, and 184 present the same sequence to the decoder. The payload format 185 described here maintains this sequence. 187 When operating at 24 kbit/s, 480 bits (60 octets) are produced per 188 frame. When operating at 32 kbit/s, 640 bits (80 octets) are 189 produced per frame. When operating at 48 kbit/s, 960 bits (120 190 octets) are produced per frame. Thus, all three bit rates allow for 191 octet alignment without the need for padding bits. 193 Figure 2 illustrates how the G.722.1 bit stream MUST be mapped into 194 an octet aligned RTP payload. 196 first bit last bit 197 transmitted transmitted 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 | | 200 + sequence of bits (480, 640 or 960) generated by the | 201 | G.722.1 encoder for transmission | 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 | | | | | 205 | | | ... | | 206 | | | | | 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+ 209 |MSB... LSB|MSB... LSB| |MSB... LSB| 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+ 211 RTP RTP RTP 212 octet 1 octet 2 octet 213 60, 80, 120 215 Figure 2: The G.722.1 encoder bit stream is split into 216 a sequence of octets (60, 80 or 120 depending on 217 the bit rate), and each octet is in turn 218 mapped into an RTP octet. 220 When operating at non-standard rates the payload format MUST follow 221 the guidelines illustrated in Figure 2. It is RECOMMENDED that 222 values in the range 16000 to 48000 be used. Non standard rates MUST 223 have a value that is a multiple of 400 (this maintains octet 224 alignment and does not then require (undefined) padding bits for each 225 frame if not octet aligned). For example, a bit rate of 16.4 kbit/s 226 will result in a frame of size 328 bits or 41 octets which are mapped 227 into RTP per Figure 2. 229 3.3. Multiple G.722.1 frames in a RTP packet 231 A sender may include more than one consecutive G.722.1 frame in a 232 single RTP packet. 234 Senders have the following additional restrictions: 236 o Sender SHOULD NOT include more G.722.1 frames in a single RTP 237 packet than will fit in the MTU of the RTP transport protocol. 239 o All frames contained in a single RTP packet MUST be of the same 240 length and sampled at the same clock rate. They MUST have the 241 same bit rate (octets per frame). 243 o Frames MUST NOT be split between RTP packets. 245 It is RECOMMENDED that the number of frames contained within an RTP 246 packet be consistent with the application. For example, in a 247 telephony application where delay is important, then the fewer frames 248 per packet the lower the delay, whereas for a delay insensitive 249 streaming or messaging application, many frames per packet would be 250 acceptable. 252 3.4. Computing the number of G.722.1 frames 254 Information describing the number of frames contained in an RTP 255 packet is not transmitted as part of the RTP payload. The only way 256 to determine the number of G.722.1 frames is to count the total 257 number of octets within the RTP packet, and divide the octet count by 258 the number of expected octets per frame. This expected octet per 259 frame count is derived from the bit rate, and is therefore a function 260 of the payload type. 262 4. IANA Considerations 264 This document updates the G7221 media type described in RFC3047. 266 4.1. Media Type Registration 268 This section describes the media types and names associated with this 269 payload format. The section registers the media types, as per 270 RFC4288 [RFC4288] 272 4.1.1. Registration of media type audio/G7221 274 Media type name: audio 276 Media subtype name: G7221 278 Required parameters: 280 bitrate: the data rate for the audio bit stream. This parameter 281 is mandatory because the bit rate is not signaled within the 282 G.722.1 bit stream. At the standard G.722.1 bit rates, the value 283 MUST be either 24000 or 32000 at 16 Khz sample rate, and 24000, 284 32000 or 48000 at 32 Khz sample rate. If using the non-standard 285 bit rates, then it is RECOMMENDED that values in the range 16000 286 to 48000 be used. Non standard rates MUST have a value that is a 287 multiple of 400 (this maintains octet alignment and does not then 288 require (undefined) padding bits for each frame if not octet 289 aligned). 291 Optional parameters: 293 rate: RTP timestamp clock rate, which is equal to the sampling 294 rate. If the parameter is not specified a clock rate of 16 Khz is 295 assumed. 297 ptime: see RFC 4566. SHOULD be a multiple of 20 msec. 299 maxptime: see RFC 4566. SHOULD be a multiple of 20 msec. 301 Encoding considerations: 303 This media type is framed and binary, see section 4.8 in 304 [RFC4288]. 306 Security considerations: See Section 6 308 Interoperability considerations: 310 Terminals SHOULD offer a media type at 16 Khz sample rate in order 311 to interoperate with terminals that do not support the new 32 Khz 312 sample rate. 314 Published specification: RFC yyy [see RFCeditor notes]. 316 Applications which use this media type: 318 Audio and Video streaming and conferencing applications. 320 Additional information: none 322 Person and email address to contact for further information : 324 Roni Even: ron.even.tlv@gmail.com 326 Intended usage: COMMON 328 Restrictions on usage: 330 This media type depends on RTP framing, and hence is only defined 331 for transfer via RTP [RFC3550]. Transport within other framing 332 protocols is not defined at this time. 334 Author: Roni Even 336 Change controller: 338 IETF Audio/Video Transport working group delegated from the IESG. 340 5. SDP Parameters 342 The media types audio/G7221 are mapped to fields in the Session 343 Description Protocol (SDP) [RFC4566] as follows: 345 o The media name in the "m=" line of SDP MUST be audio. 347 o The encoding name in the "a=rtpmap" line of SDP MUST be G7221 (the 348 media subtype). 350 o The parameters "rate" goes in "a=rtpmap" as clock rate parameter 352 o Only one bitrate SHALL be defined (using the "bitrate=" parameter 353 in the a=fmtp line) for each payload type. 355 5.1. Usage with the SDP Offer Answer Model 357 When offering G.722.1 over RTP using SDP in an Offer/Answer model 358 [RFC3264] the following considerations are necessary. 360 The combination of the clock rate in the rtpmap and the bitrate 361 parameter defines the configuration of each payload type. Each 362 configuration intended to be used, MUST be declared. 364 There are two sampling clock rates defined for G.722.1 in this 365 document. RFC3047 [RFC3047] supported only the 16 Khz clock rate. 366 Therefore a system that wants to use G.722.1 SHOULD offer a payload 367 type with clock rate of 16000 for backward interoperability. 369 An example of an offer that includes a 16000 and 32000 clock rate is: 371 m=audio 49000 RTP/AVP 121 122 372 a=rtpmap:121 G7221/16000 373 a=fmtp:121 bitrate=24000 374 a=rtpmap:122 G7221/32000 375 a=fmtp:122 bitrate=48000 377 6. Security Considerations 379 RTP packets using the payload format defined in this specification 380 are subject to the security considerations discussed in the RTP 381 specification [RFC3550] and any appropriate RTP profile. The main 382 security considerations for the RTP packet carrying the RTP payload 383 format defined within this memo are confidentiality, integrity, and 384 source authenticity. Confidentiality is achieved by encryption of 385 the RTP payload. Integrity of the RTP packets is achieved through a 386 suitable cryptographic integrity protection mechanism. Such a 387 cryptographic system may also allow the authentication of the source 388 of the payload. A suitable security mechanism for this RTP payload 389 format should provide confidentiality, integrity protection, and at 390 least source authentication capable of determining if an RTP packet 391 is from a member of the RTP session. 393 Note that the appropriate mechanism to provide security to RTP and 394 payloads following this memo may vary. It is dependent on the 395 application, the transport, and the signaling protocol employed. 396 Therefore, a single mechanism is not sufficient, although if 397 suitable, usage of the Secure Real-time Transport Protocol (SRTP) 398 [RFC3711] recommended. Other mechanisms that may be used are IPsec 399 [RFC4301] Transport Layer Security (TLS) [RFC5246] (RTP over TCP); 400 other alternatives may exist. 402 This RTP payload format and its media decoder do not exhibit any 403 significant non-uniformity in the receiver-side computational 404 complexity for packet processing, and thus are unlikely to pose a 405 denial-of-service threat due to the receipt of pathological data. 406 Nor does the RTP payload format contain any active content. 408 7. Changes from RFC 3047 410 The new draft obsoletes RFC3047 adding the support for the 411 Superwideband (14 Khz) audio support defined in annex C of the new 412 revision of ITU-T G.722.1. 414 Other changes 416 Update the text to be in line with the current rules for RFC and with 417 media type registration conforming to RFC 4288. 419 8. Acknowledgements 421 The authors would like to thank Tom Taylor for his contribution to 422 this work. 424 9. RFC editor note 426 Please replace RFC yyy giving the number assigned to this RFC. 428 10. References 430 10.1. Normative References 432 [ITU.G7221] 433 International Telecommunications Union, "Low-complexity 434 coding at 24 and 32 kbit/s for hands-free operation in 435 systems with low frame loss", ITU-T Recommendation 436 G.722.1, 2005. 438 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 439 Requirement Levels", BCP 14, RFC 2119, March 1997. 441 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 442 with Session Description Protocol (SDP)", RFC 3264, 443 June 2002. 445 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 446 Jacobson, "RTP: A Transport Protocol for Real-Time 447 Applications", STD 64, RFC 3550, July 2003. 449 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 450 Description Protocol", RFC 4566, July 2006. 452 10.2. Informative References 454 [RFC3047] Luthi, P., "RTP Payload Format for ITU-T Recommendation 455 G.722.1", RFC 3047, January 2001. 457 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 458 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 459 RFC 3711, March 2004. 461 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and 462 Registration Procedures", BCP 13, RFC 4288, December 2005. 464 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 465 Internet Protocol", RFC 4301, December 2005. 467 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 468 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 470 Authors' Addresses 472 Patrick Luthi 473 Tandberg 474 Philip Pedersens vei 22 475 1366 Lysaker 476 Norway 478 Email: patrick.luthi@tandberg.no 480 Roni Even 481 Gesher Erove Ltd 482 14 David Hamelech 483 Tel Aviv 64953 484 Israel 486 Email: ron.even.tlv@gmail.com