1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
|
<pre>Network Working Group P. Luthi
Request for Comments: 3047 PictureTel
Category: Standards Track January 2001
<span class="h1">RTP Payload Format for ITU-T Recommendation G.722.1</span>
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract
International Telecommunication Union (ITU-T) Recommendation G.722.1
is a wide-band audio codec, which operates at one of two selectable
bit rates, 24kbit/s or 32kbit/s. This document describes the payload
format for including G.722.1 generated bit streams within an RTP
packet. Also included here are the necessary details for the use of
G.722.1 with MIME and SDP.
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Conventions used in this document</span>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <a href="./rfc2119">RFC-2119</a> [6].
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Overview of ITU-T Recommendation G.722.1</span>
G.722.1 is a low complexity coder, it compresses 50Hz - 7kHz audio
signals into one of two bit rates, 24 kbit/s or 32 kbit/s.
The coder may be used for speech, music and other types of audio.
Some of the applications for which this coder is suitable are:
o Real-time communications such as videoconferencing and telephony.
o Streaming audio
o Archival and messaging
<span class="grey">Luthi Standards Track [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc3047">RFC 3047</a> Payload Format G.722.1 January 2001</span>
A fixed frame size of 20 ms is used, and for any given bit rate the
number of bits in a frame is a constant.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. RTP payload format for G.722.1</span>
G.722.1 uses 20 ms frames and a sampling rate clock of 16 kHz, so the
RTP timestamp MUST be in units of 1/16000 of a second. The RTP
payload for G.722.1 has the format shown in Figure 1. No additional
header specific to this payload format is required.
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP Header [3] |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| |
+ one or more frames of G.722.1 |
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: RTP payload for G.722.1
The encoding and decoding algorithm can change the bit rate at any
20ms frame boundary, but no bit rate change notification is provided
in-band with the bit stream. Therefore, a separate out-of-band
method is REQUIRED to indicate the bit rate (see <a href="#section-6">section 6</a> for an
example of signaling bit rate information using SDP). For the
payload format specified here, the bit rate MUST remain constant for
a particular payload type value. An application MAY switch bit rates
from packet to packet by defining two payload type values and
switching between them.
The assignment of an RTP payload type for this new packet format is
outside the scope of this document, and will not be specified here.
It is expected that the RTP profile for a particular class of
applications will assign a payload type for this encoding, or if that
is not done then a payload type in the dynamic range shall be chosen.
The number of bits within a frame is fixed, and within this fixed
frame G.722.1 uses variable length coding (e.g., Huffman coding) to
represent most of the encoded parameters [2]. All variable length
codes are transmitted in order from the left most (most significant -
MSB) bit to the right most (least significant - LSB) bit, see [2] for
more details.
The use of Huffman coding means that it is not possible to identify
the various encoded parameters/fields contained within the bit stream
without first completely decoding the entire frame.
<span class="grey">Luthi Standards Track [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc3047">RFC 3047</a> Payload Format G.722.1 January 2001</span>
For the purposes of packetizing the bit stream in RTP, it is only
necessary to consider the sequence of bits as output by the G.722.1
encoder, and present the same sequence to the decoder. The payload
format described here maintains this sequence.
When operating at 24 kbit/s, 480 bits (60 octets) are produced per
frame, and when operating at 32 kbit/s, 640 bits (80 octets) are
produced per frame. Thus, both bit rates allow for octet alignment
without the need for padding bits.
Figure 2 illustrates how the G.722.1 bit stream MUST be mapped into
an octet aligned RTP payload.
An RTP packet SHALL only contain G.722.1 frames of the same bit rate.
first bit last bit
transmitted transmitted
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ sequence of bits (480 or 640) generated by the |
| G.722.1 encoder for transmission |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | |
| | | ... | |
| | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+
|MSB... LSB|MSB... LSB| |MSB... LSB|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+
RTP RTP RTP
octet 1 octet 2 octet
60 or 80
Figure 2: The G.722.1 encoder bit stream is split into
a sequence of octets (60 or 80 depending on
the bit rate), and each octet is in turn
mapped into an RTP octet.
The ITU-T standardized bit rates for G.722.1 are 24 kbit/s and
32kbit/s. However, the coding algorithm itself has the capability to
run at any user specified bit rate (not just 24 and 32kbit/s) while
maintaining an audio bandwidth of 50 Hz to 7 kHz. This rate change
is accomplished by a linear scaling of the codec operation, resulting
in frames with size in bits equal to 1/50 of the corresponding bit
rate.
<span class="grey">Luthi Standards Track [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc3047">RFC 3047</a> Payload Format G.722.1 January 2001</span>
When operating at non-standard rates the payload format MUST follow
the guidelines illustrated in Figure 2. It is RECOMMENDED that
values in the range 16000 to 32000 be used, and that any value MUST
be a multiple of 400 (this maintains octet alignment and does not
then require (undefined) padding bits for each frame if not octet
aligned). For example, a bit rate of 16.4 kbit/s will result in a
frame of size 328 bits or 41 octets which are mapped into RTP per
Figure 2.
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a> Multiple G.722.1 frames in a RTP packet</span>
More than one G.722.1 frame may be included in a single RTP packet by
a sender.
Senders have the following additional restrictions:
o SHOULD NOT include more G.722.1 frames in a single RTP packet than
will fit in the MTU of the RTP transport protocol.
o All frames contained in a single RTP packet MUST be of the same
length, that is they MUST have the same bit rate (octets per
frame).
o Frames MUST NOT be split between RTP packets.
It is RECOMMENDED that the number of frames contained within an RTP
packet be consistent with the application. For example, in a
telephony application where delay is important, then the fewer frames
per packet the lower the delay, whereas for a delay insensitive
streaming or messaging application, many frames per packet would be
acceptable.
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a> Computing the number of G.722.1 frames</span>
Information describing the number of frames contained in an RTP
packet is not transmitted as part of the RTP payload. The only way
to determine the number of G.722.1 frames is to count the total
number of octets within the RTP packet, and divide the octet count by
the number of expected octets per frame (either 60 or 80 per frame,
for 24 kbit/s and 32 kbit/s respectively).
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. MIME registration of G.722.1</span>
MIME media type name: audio
MIME subtype: G7221
<span class="grey">Luthi Standards Track [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc3047">RFC 3047</a> Payload Format G.722.1 January 2001</span>
Required parameters:
bitrate: the data rate for the audio bit stream. This
parameter is necessary because the bit rate is not signaled
within the G.722.1 bit stream. At the standard G.722.1 bit
rates, the value MUST be either 24000 or 32000. If using the
non-standard bit rates, then it is RECOMMENDED that values in
the range 16000 to 32000 be used, and that any value MUST be a
multiple of 400 (this maintains octet alignment and does not
then require (undefined) padding bits for each frame if not
octet aligned).
Optional parameters:
ptime: RECOMMENDED duration of each packet in milliseconds.
Encoding considerations:
This type is only defined for transfer via RTP as specified in
a Work in Progress.
Security Considerations:
See <a href="./rfc3047#section-6">Section 6 of RFC 3047</a>.
Interoperability considerations: none
Published specification:
See ITU-T Recommendation G.722.1 [2] for encoding algorithm
details.
Applications which use this media type:
Audio and video streaming and conferencing tools
Additional information: none
Person & email address to contact for further information:
Patrick Luthi
Luthip@pictel.com
Intended usage: COMMON
Author/Change controller:
Author: Patrick Luthi
Change controller: IETF AVT Working Group
<span class="grey">Luthi Standards Track [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc3047">RFC 3047</a> Payload Format G.722.1 January 2001</span>
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. SDP usage of G.722.1</span>
When conveying information by SDP [5], the encoding name SHALL be
"G7221" (the same as the MIME subtype). An example of the media
representation in SDP for describing G.722.1 at 24000 bits/sec might
be:
m=audio 49000 RTP/AVP 121
a=rtpmap:121 G7221/16000
a=fmtp:121 bitrate=24000
where "bitrate" is a variable that may take on values of 24000 or
32000 at the standard rates, or values from 16000 to 32000 (and MUST
be an integer multiple of 400) at the non-standard rates.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Security Considerations</span>
RTP packets using the payload format defined in this specification
are subject to the security considerations discussed in the RTP
specification [3], and any appropriate RTP profile. This implies
that confidentiality of the media streams is achieved by encryption.
Because the data compression used with this payload format is applied
end-to-end, encryption may be performed after compression so there is
no conflict between the two operations.
A potential denial-of-service threat exists for data encodings using
compression techniques that have non-uniform receiver-end
computational load. The attacker can inject pathological datagrams
into the stream which are complex to decode and cause the receiver to
be overloaded. However, this encoding does not exhibit any
significant non-uniformity.
As with any IP-based protocol, in some circumstances a receiver may
be overloaded simply by the receipt of too many packets, either
desired or undesired. Network-layer authentication may be used to
discard packets from undesired sources, but the processing cost of
the authentication itself may be too high. In a multicast
environment, pruning of specific sources may be implemented in future
versions of IGMP [7] and in multicast routing protocols to allow a
receiver to select which sources are allowed to reach it.
<span class="grey">Luthi Standards Track [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc3047">RFC 3047</a> Payload Format G.722.1 January 2001</span>
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. References</span>
1. Bradner, S., "The Internet Standards Process -- Revision 3", <a href="https://www.rfc-editor.org/bcp/bcp9">BCP</a>
<a href="https://www.rfc-editor.org/bcp/bcp9">9</a>, <a href="./rfc2026">RFC 2026</a>, October 1996.
2. ITU-T Recommendation G.722.1, available online from the ITU
bookstore at <a href="http://www.itu.int">http://www.itu.int</a>.
3. Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP:
A Transport Protocol for real-time applications", <a href="./rfc1889">RFC 1889</a>,
January 1996. (Updated by a Work in Progress.)
4. Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Bodies",
<a href="./rfc2045">RFC 2045</a>, November 1996.
5. Handley, M. and V. Jacobson, "SDP: Session Description Protocol",
<a href="./rfc2327">RFC 2327</a>, April 1998.
6. Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.
7. Deering, S., "Host Extensions for IP Multicasting", STD 5, <a href="./rfc1112">RFC</a>
<a href="./rfc1112">1112</a>, August 1989.
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. Acknowledgments</span>
The author wishes to thank Tony Crossman for starting this work on
G.722.1 packetization and for authoring the initial draft. The
author also wishes to thank Steve Casner and Colin Perkins for their
valuable feedback and helpful comments.
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. Author's Address</span>
Patrick Luthi
PictureTel Corporation
100 Minuteman Road
Andover, MA 01810
USA
Phone: +1 (978) 292 4354
EMail: luthip@pictel.com
<span class="grey">Luthi Standards Track [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc3047">RFC 3047</a> Payload Format G.722.1 January 2001</span>
<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>. Full Copyright Statement</span>
Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Luthi Standards Track [Page 8]
</pre>
|
