As per Relevance of the word document, we have this rfc below:
Network Working Group P.
Request for Comments: 3047
Category: Standards Track January 2001
RTP Payload Format for ITU-T Recommendation G.722.1
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (2001). All Rights Reserved
International Telecommunication Union (ITU-T) Recommendation G.722.1
is a wide-band audio codec, which operates at one of two
bit rates, 24kbit/s or 32kbit/s. This document describes the
format for including G.722.1 generated bit streams within an
packet. Also included here are the necessary details for the use
G.722.1 with MIME and SDP
1. Conventions used in this
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
document are to be interpreted as described in RFC-2119 [6].
2. Overview of ITU-T Recommendation G.722.1
G.722.1 is a low complexity coder, it compresses 50Hz - 7kHz
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
o Archival and
Luthi Standards Track [Page 1]
RFC 3047 Payload Format G.722.1 January 2001
A fixed frame size of 20 ms is used, and for any given bit rate
number of bits in a frame is a constant
3. RTP payload format for G.722.1
G.722.1 uses 20 ms frames and a sampling rate clock of 16 kHz, so
RTP timestamp MUST be in units of 1/16000 of a second. The
payload for G.722.1 has the format shown in Figure 1. No
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
20ms frame boundary, but no bit rate change notification is
in-band with the bit stream. Therefore, a separate out-of-
method is REQUIRED to indicate the bit rate (see section 6 for
example of signaling bit rate information using SDP). For
payload format specified here, the bit rate MUST remain constant
a particular payload type value. An application MAY switch bit
from packet to packet by defining two payload type values
switching between them
The assignment of an RTP payload type for this new packet format
outside the scope of this document, and will not be specified here
It is expected that the RTP profile for a particular class
applications will assign a payload type for this encoding, or if
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
frame G.722.1 uses variable length coding (e.g., Huffman coding)
represent most of the encoded parameters [2]. All variable
codes are transmitted in order from the left most (most significant -
MSB) bit to the right most (least significant - LSB) bit, see [2]
more details
The use of Huffman coding means that it is not possible to
the various encoded parameters/fields contained within the bit
without first completely decoding the entire frame
Luthi Standards Track [Page 2]
RFC 3047 Payload Format G.722.1 January 2001
For the purposes of packetizing the bit stream in RTP, it is
necessary to consider the sequence of bits as output by the G.722.1
encoder, and present the same sequence to the decoder. The
format described here maintains this sequence
When operating at 24 kbit/s, 480 bits (60 octets) are produced
frame, and when operating at 32 kbit/s, 640 bits (80 octets)
produced per frame. Thus, both bit rates allow for octet
without the need for padding bits
Figure 2 illustrates how the G.722.1 bit stream MUST be mapped
an octet aligned RTP payload
An RTP packet SHALL only contain G.722.1 frames of the same bit rate
first bit last
transmitted
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ sequence of bits (480 or 640) generated by the |
| G.722.1 encoder for transmission |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | |
| | | ... | |
| | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+
|MSB... LSB|MSB... LSB| |MSB... LSB
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+
RTP RTP
octet 1 octet 2
60 or 80
Figure 2: The G.722.1 encoder bit stream is split
a sequence of octets (60 or 80 depending
the bit rate), and each octet is in
mapped into an RTP octet
The ITU-T standardized bit rates for G.722.1 are 24 kbit/s
32kbit/s. However, the coding algorithm itself has the capability
run at any user specified bit rate (not just 24 and 32kbit/s)
maintaining an audio bandwidth of 50 Hz to 7 kHz. This rate
is accomplished by a linear scaling of the codec operation,
in frames with size in bits equal to 1/50 of the corresponding
rate
Luthi Standards Track [Page 3]
RFC 3047 Payload Format G.722.1 January 2001
When operating at non-standard rates the payload format MUST
the guidelines illustrated in Figure 2. It is RECOMMENDED
values in the range 16000 to 32000 be used, and that any value
be a multiple of 400 (this maintains octet alignment and does
then require (undefined) padding bits for each frame if not
aligned). For example, a bit rate of 16.4 kbit/s will result in
frame of size 328 bits or 41 octets which are mapped into RTP
Figure 2.
3.1 Multiple G.722.1 frames in a RTP
More than one G.722.1 frame may be included in a single RTP packet
a sender
Senders have the following additional restrictions
o SHOULD NOT include more G.722.1 frames in a single RTP packet
will fit in the MTU of the RTP transport protocol
o All frames contained in a single RTP packet MUST be of the
length, that is they MUST have the same bit rate (octets
frame).
o Frames MUST NOT be split between RTP packets
It is RECOMMENDED that the number of frames contained within an
packet be consistent with the application. For example, in
telephony application where delay is important, then the fewer
per packet the lower the delay, whereas for a delay
streaming or messaging application, many frames per packet would
acceptable
3.2 Computing the number of G.722.1
Information describing the number of frames contained in an
packet is not transmitted as part of the RTP payload. The only
to determine the number of G.722.1 frames is to count the
number of octets within the RTP packet, and divide the octet count
the number of expected octets per frame (either 60 or 80 per frame
for 24 kbit/s and 32 kbit/s respectively).
4. MIME registration of G.722.1
MIME media type name:
MIME subtype: G7221
Luthi Standards Track [Page 4]
RFC 3047 Payload Format G.722.1 January 2001
Required parameters
bitrate: the data rate for the audio bit stream.
parameter is necessary because the bit rate is not
within the G.722.1 bit stream. At the standard G.722.1
rates, the value MUST be either 24000 or 32000. If using
non-standard bit rates, then it is RECOMMENDED that values
the range 16000 to 32000 be used, and that any value MUST be
multiple of 400 (this maintains octet alignment and does
then require (undefined) padding bits for each frame if
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
a Work in Progress
Security Considerations
See Section 6 of RFC 3047.
Interoperability considerations:
Published specification
See ITU-T Recommendation G.722.1 [2] for encoding
details
Applications which use this media type
Audio and video streaming and conferencing
Additional information:
Person & email address to contact for further information
Patrick
Luthip@pictel.
Intended usage:
Author/Change controller
Author: Patrick
Change controller: IETF AVT Working
Luthi Standards Track [Page 5]
RFC 3047 Payload Format G.722.1 January 2001
5. SDP usage of G.722.1
When conveying information by SDP [5], the encoding name SHALL
"G7221" (the same as the MIME subtype). An example of the
representation in SDP for describing G.722.1 at 24000 bits/sec
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
32000 at the standard rates, or values from 16000 to 32000 (and
be an integer multiple of 400) at the non-standard rates
6. Security
RTP packets using the payload format defined in this
are subject to the security considerations discussed in the
specification [3], and any appropriate RTP profile. This
that confidentiality of the media streams is achieved by encryption
Because the data compression used with this payload format is
end-to-end, encryption may be performed after compression so there
no conflict between the two operations
A potential denial-of-service threat exists for data encodings
compression techniques that have non-uniform receiver-
computational load. The attacker can inject pathological
into the stream which are complex to decode and cause the receiver
be overloaded. However, this encoding does not exhibit
significant non-uniformity
As with any IP-based protocol, in some circumstances a receiver
be overloaded simply by the receipt of too many packets,
desired or undesired. Network-layer authentication may be used
discard packets from undesired sources, but the processing cost
the authentication itself may be too high. In a
environment, pruning of specific sources may be implemented in
versions of IGMP [7] and in multicast routing protocols to allow
receiver to select which sources are allowed to reach it
Luthi Standards Track [Page 6]
RFC 3047 Payload Format G.722.1 January 2001
7.
1. Bradner, S., "The Internet Standards Process -- Revision 3",
9, RFC 2026, October 1996.
2. ITU-T Recommendation G.722.1, available online from the
bookstore at http://www.itu.int
3. Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP
A Transport Protocol for real-time applications", RFC 1889,
January 1996. (Updated by a Work in Progress.)
4. Freed, N. and N. Borenstein, "Multipurpose Internet
Extensions (MIME) Part One: Format of Internet Message Bodies",
RFC 2045, November 1996.
5. Handley, M. and V. Jacobson, "SDP: Session Description Protocol",
RFC 2327, April 1998.
6. Bradner, S., "Key words for use in RFCs to Indicate
Levels", BCP 14, RFC 2119, March 1997.
7. Deering, S., "Host Extensions for IP Multicasting", STD 5,
1112, August 1989.
8.
The author wishes to thank Tony Crossman for starting this work
G.722.1 packetization and for authoring the initial draft.
author also wishes to thank Steve Casner and Colin Perkins for
valuable feedback and helpful comments
9. Author's
Patrick
PictureTel
100 Minuteman
Andover, MA 01810
Phone: +1 (978) 292 4354
EMail: luthip@pictel.
Luthi Standards Track [Page 7]
RFC 3047 Payload Format G.722.1 January 2001
10. Full Copyright
Copyright (C) The Internet Society (2001). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
Luthi Standards Track [Page 8]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
