idnits 2.17.1 draft-crossman-avt-rtp-g7221-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == Mismatching filename: the document gives the document name as 'draft-ietf-avt-rtp-g7221-00', but the file name used is 'draft-crossman-avt-rtp-g7221-00' == There are 4 instances of lines with non-ascii characters in the document. == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 312 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 5 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: o MUST not include more G.722.1 frames in a single RTP packet than will fit in the MTU of the RTP transport protocol. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: o Frames MUST not be split between RTP packets. -- 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 (December 1999) is 8891 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) -- Missing reference section? '3' on line 70 looks like a reference -- Missing reference section? '2' on line 91 looks like a reference -- Missing reference section? '5' on line 199 looks like a reference Summary: 7 errors (**), 0 flaws (~~), 5 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Name 2 A. Crossman 3 Internet Draft 4 PictureTel 5 Document: 6 December 1999 7 Category: Standards Track 9 RTP Payload Load Format for ITU-T Recommendation G.722.1 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026 [ ]. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. Internet-Drafts are draft documents valid for a maximum of 20 six months and may be updated, replaced, or obsoleted by other 21 documents at any time. It is inappropriate to use Internet- Drafts 22 as reference material or to cite them other than as "work in 23 progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 1. Abstract 33 ITU-T Recommendation G.722.1 [ ] is a wideband coder, it operates at 34 one of two selectable bit rates, 24kbit/s or 32kbit/s. This 35 document describes the payload format for including G.722.1 36 generated bit streams within an RTP packet [ ]. Also included here 37 are the necessary details for the use of G.722.1 with MIME [ ] and 38 SDP [ ]. 40 2. Conventions used in this document 42 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 43 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 44 this document are to be interpreted as described in RFC-2119 [ ]. 46 3. Overview of ITU-T Recommendation G.722.1 48 G.722.1 is a low complexity coder, it compresses 50Hz - 7kHz audio 49 signals into one of two bit rates, 24 kbit/s or 32 kbit/s. The 50 coder may be used for speech, music and other types of audio. 52 Some of the applications for which this coder is suitable are: 54 o Real-time communications such as videoconferencing and 55 telephony. 56 o Streaming audio 57 o Archival and messaging 59 A fixed frame size of 20ms is used, and for any given bit rate the 60 number of bits in a frame is a constant. 62 4. RTP payload format for G.722.1 64 The RTP timestamp MUST be in units of 1/16000 of a second. The RTP 65 payload for G.722.1 has the following format: 67 0 1 2 3 68 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 69 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 70 | RTP Header [3] | 71 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 72 | | 73 + one or more frames of G.722.1 | 74 | .... | 75 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 77 G.722.1 uses 20 ms frames and a sampling rate clock of 16 kHz. The 78 bit rate can be changed at any 20ms frame boundary, although bit 79 rate change notification is not provided inband with the bit stream 80 - therefore a separate out-of-band method is REQUIRED to indicate 81 the bit rate (see section 6 for an example of signaling bit rate 82 information using SDP). When operating at 24 kbit/s, 480 bits (60 83 octets) are produced per frame, and when operating at 32 kbit/s, 640 84 bits (80 octets) are produced per frame. Thus, both bit rates allow 85 for octet alignment without the need for padding bits. 87 The number of bits within a frame is fixed, and within this fixed 88 frame G.722.1 uses variable length coding (e.g. Huffman coding) to 89 represent most of the encoded parameters [2]. All variable length 90 codes are transmitted in order from the left most (most significant 91 - MSB) bit to the right most (least significant - LSB) bit, see [2] 92 for more details. 94 The use of Huffman coding means that it is not possible to identify 95 the various coder parameters/fields contained within the bit stream 96 without first completely decoding the entire frame. 98 For the purposes of packetizing the bit stream in RTP, it is only 99 necessary to consider the sequence of bits as output by the G.722.1 100 encoder, and present the same sequence to the decoder. The payload 101 format described here maintains this sequence. 103 Figure 3.1 illustrates how the G.722.1 bit stream MUST be mapped 104 into an octet aligned RTP payload. 106 An RTP packet SHALL only contain G.722.1 frames of the same bit 107 rate. 109 first bit last bit 110 transmitted transmitted 111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 112 | | 113 + sequence of bits (480 or 640) generated by the | 114 | G.722.1 encoder for transmission | 115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 117 | | | | | 118 | | | ... | | 119 | | | | | 121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+ 122 |MSB... LSB|MSB... LSB| |MSB... LSB| 123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+ 124 RTP RTP RTP 125 octet 1 octet 2 octet 126 60 or 80 128 Figure 3.1 The G.722.1 encoder bit stream is split into a 129 sequence of octets (60 or 80 depending on the bit rate), 130 and each octet is in turn mapped into an RTP octet. 132 The ITU-T standardized bit rates for G.722.1 are 24 kbit/s and 133 32kbit/s. However, the coding algorithm itself has the capability 134 to run at any user specified bit rate (not just 24 and 32kbit/s � 135 see section 5 for further details on acceptable non-standard bit 136 rate values) while maintaining an audio bandwidth of 50 Hz to 7 kHz. 138 When operating at non-standard rates the payload format SHOULD 139 follow the guidelines illustrated in Figure 3.1. For example, a bit 140 rate of 16.4 kbit/s will result in a frame of size 328 bits or 41 141 octets which are mapped into RTP per Figure 3.1. 143 4.1 Multiple G.722.1 frames in a RTP packet 145 More than one G.722.1 frame may be included in a single RTP packet 146 by a sender. 148 Senders have the following additional restrictions: 150 o MUST not include more G.722.1 frames in a single RTP packet than 151 will fit in the MTU of the RTP transport protocol. 153 o Frames MUST not be split between RTP packets. 155 It is RECOMMENDED that the number of frames contained within an RTP 156 packet be consistent with the application. For example, in a 157 telephony application where delay is important, then the fewer 158 frames per packet the lower the delay, whereas for a delay 159 insensitive streaming or messaging application, many frames per 160 packet would be acceptable. 162 4.2 Computing the number of G.722.1 frames 164 Information describing the number of frames contained in an RTP 165 packet is not transmitted as part of the RTP payload. The only way 166 to determine the number of G.722.1 frames is to count the total 167 number of octets within the RTP packet, and divide the octet count 168 by the number of expected octets per frame (either 60 or 80 per 169 frame, for 24 kbit/s and 32 kbit/s respectively). 171 5. MIME registration of G.722.1 173 MIME media type name: audio 175 MIME subtype: g7221 177 Required parameters: None 179 Optional parameters: 181 bitrate: the data rate for the audio bit stream. This 182 parameter is necessary because the bit rate is not signaled 183 within the G.722.1 bit stream. At the standard G.722.1 bit 184 rates, the value MUST be either 24000 or 32000. If using the 185 non-standard bit rates, then it is RECOMMENDED values in the 186 range 16000 to 32000 be used, and that any value SHOULD be a 187 multiple of 400 (this maintains octet alignment and does not 188 then require (undefined) padding bits for each frame if not 189 octet aligned). 191 ptime: RECOMMENDED duration of each packet in milliseconds. 193 Published specification: 194 see ITU-T Recommendation G.722.1 for encoding algorithm 195 details. 197 6. SDP usage of G.722.1 199 When conveying information by SDP [5], the encoding name SHALL be 200 �g7221� (the same as the MIME subtype). An example of the media 201 representation in SDP might be: 203 m=audio 49000 RTP/AVP 121 204 a=rtpmap:121 g7221/16000 205 a=fmtp:121 bitrate=24000 207 where �bitrate� is a variable that may take on values of 24000 or 208 32000 at the standard rates, or values from 16000 to 32000 (and 209 SHOULD be an integer multiple of 400) at the non-standard rates. 211 7. Security Considerations 213 The registration procedure specified in this memo does not impose 214 any security considerations on its own. 216 8. References 218 9. Acknowledgments 220 The author wishes to thank Steve Casner and Colin Perkins for their 221 review of this draft. 223 10. Author's Addresses 225 Antony Crossman 226 PictureTel Corporation 227 100 Minuteman Road 228 Andover, MA 01810 229 USA 230 Phone: +1 (978) 292 4557 231 Email: tonyc@pictel.com 233 Full Copyright Statement 235 "Copyright (C) The Internet Society (December, 1999). All Rights 236 Reserved. This document and translations of it may be copied and 237 furnished to others, and derivative works that comment on or 238 otherwise explain it or assist in its implementation may be 239 prepared, copied, published and distributed, in whole or in part, 240 without restriction of any kind, provided that the above copyright 241 notice and this paragraph are included on all such copies and 242 derivative works. However, this document itself may not be modified 243 in any way, such as by removing the copyright notice or references 244 to the Internet Society or other Internet organizations, except as 245 needed for the purpose of developing Internet standards in which 246 case the procedures for copyrights defined in the Internet Standards 247 process must be followed, or as required to translate it into 249 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 250 9, RFC 2026, October 1996. 252 ITU-T Recommendation G.722.1, available online from the ITU 253 bookstore at http://www.itu.int 255 H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: A 256 Transport Protocol for real-time applications, �RFC 1889, January 257 1996, updated by draft-ietf-avt-rtp-new (work in porgress). 259 N. Freed & N. Borenstein, "Multipurpose Internet Mail Extensions 260 (MIME) Part One: Format of Internet Message Bodies", RFC 2045, 261 November 1996. 263 M. Handley and V. Jacobson, "SDP: Session Description Protocol", 264 RFC 2327, April 1998. 266 Bradner, S., "Key words for use in RFCs to Indicate Requirement 267 Levels", BCP 14, RFC 2119, March 1997 269 Payload Load Format G.722.1 Dec 1999 271 Crossman Category - Expiration 4 273 Crossman Category - Expiration 1