Network Working Group M. Ramalho
Internet-Draft Cisco Systems, Inc.
Expires: May 9, 2003 November 8, 2002
RTP Payload Format for RGL Codec
draft-ramalho-rgl-rtpformat-00.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 9, 2003.
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract
This document describes the RTP payload format for the RGL Codec
described in draft-ramalho-rgl-desc-00.txt [4] and documented fully
at www.vovida.org [9]. The necessary details for the use of the RGL
codec with SDP are included in this document.
Ramalho Expires May 9, 2003 [Page 1]
Internet-Draft RTP Payload Format for RGL Codec November 2002
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. RTP Payload Format for RGL Codec . . . . . . . . . . . . . . . 6
4. SDP Issues . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5. Security Considerations . . . . . . . . . . . . . . . . . . . 14
6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 15
References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 17
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 18
Ramalho Expires May 9, 2003 [Page 2]
Internet-Draft RTP Payload Format for RGL Codec November 2002
1. Introduction
The RGL (short for Ramalho G.711 Lossless) Codec obtains lossless
compression of speech/audio packet payloads encoded with ITU-T
Recommendation G.711 PCM (mu-law or A-law) with trivial complexity
and virtually no delay. The RGL Codec is described in draft-ramalho-
rgl-desc-00.txt [4] and documented fully at www.vovida.org [10]. The
RGL codec is freeware subject to the Vovida.org licensing terms found
at www.vovida.org [11].
The RGL codec performs lossless compression of G.711 encoded frames
of arbitrary frame length. However, as described the RGL Codec
whitepaper at www.vovida.org [12], the recommended size for optimal
RGL compression gains during speech segments is less than 20
milliseconds. For example, ten milliseconds is near optimum and
corresponds to exactly 80 samples of 8k sampled (G.711) speech/audio
input.
The RTP payload format described below accommodates RGL frames with
up to 255 samples (31.875 milliseconds of speech/audio). As the
interfaces at the RGL end systems are often PSTN/GSTN networks, note
that a range of up to 255 (G.711) samples includes convenient frame
sizes for optimal transcoding into payloads of virtually all PSTN/
GSTN transport systems (e.g., ATM VoAAL2 frame of 44 bytes/5.5
milliseconds or ATM VoAAL5 frame of 48 bytes/6.0 milliseconds).
Additionally, the RTP payload format to be described allows for
multiple RGL encoded frames (each of up to 255 samples) to be
transported in one RTP packet. For example, this allows for two, 10
millisecond RGL frames per RTP packet (20 milliseconds being a common
VoIP payload inter-packet interval). The 255 sample RGL frame
limitation does not apply for RTP payloads containing only one RGL
frame; instead the optional Session Description Protocol (SDP [7])
parameter "ptime" specifies the length of time (in milliseconds)
represented by the media in a packet. Thus for RTP payload
containing only one RGL packet, the number of samples contained in
the RGL frame is ptime*8 (e.g., a 20 millisecond RGL payload
represents 160 samples and maps to precisely 160 bytes of G.711
data). If ptime isn't explicitly signaled in SDP, the default ptime
of 20 msec for the RGL codec is used.
The RGL codec compresses a frame of Y G.711 bytes into the compressed
RGL frame that can be of length 1 to (Y+1) bytes. There are two
implications of this compression relative to a native G.711 RTP
payload: 1) one cannot a priori determine the length of a RGL frame
in bytes, and 2) on relatively infrequent basis, the RGL frame is one
byte *longer* than the corresponding native G.711 frame. The first
implication implies that if more than one RGL frame is packetized in
one RTP payload, that information must be placed in the RTP header
Ramalho Expires May 9, 2003 [Page 3]
Internet-Draft RTP Payload Format for RGL Codec November 2002
(specifically in the RTP header extension) to demark the RGL frame
boundaries. Note that this is not necessary for native G.711
encodings, as Y bytes of G.711 RTP payload is equal to exactly Y
G.711 samples. The second implication is that the RGL encoding
occasionally expands the payload relative to G.711. This expansion
has been explicitly limited to be one byte in the design of the RGL
codec. To obtain RTP byte payload parity relative to G.711 for a RTP
payload containing only one RGL frame, the proposed RTP payload
format for the RGL codec has an optimization that is fully described
below.
As a major goal of compression is to reduce overall session
bandwidth, including RTP overhead, the proposed RTP format below has
optimizations to reduce RTP header overhead for the most common RGL
codec packetizations and the RGL compression characteristics noted
above.
Ramalho Expires May 9, 2003 [Page 4]
Internet-Draft RTP Payload Format for RGL Codec November 2002
2. Conventions
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when
they appear in this document, are to be interpreted as described in
RFC2119 [2].
Ramalho Expires May 9, 2003 [Page 5]
Internet-Draft RTP Payload Format for RGL Codec November 2002
3. RTP Payload Format for RGL Codec
The RTP payload format for RGL codec conforms to the Real-Time
Transport Protocol (RTP [5]) RFC 1889 in every aspect. A RTP packet
for the RGL codec looks like:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X| CC |M| PT | sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
\ contributing source (CSRC) identifiers \
/ (zero up to fifteen) /
\ ..... \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ Zero or One RTP Header Extension \
/ (only if X bit =1) /
\ ..... \
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
\ \
/ RTP PAYLOAD (One or more RGL Codec Frames) /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The first twelve octets are present in every RTP packet as per RFC
1889, while the list of CSRC identifiers is present only when
inserted by a mixer. This profile follows the RTP profile
recommendations in RFC 1890 [6].
There are two bits in the mandatory twelve octet header that are
defined by this profile, the extension (X) bit and the marker (M)
bit. The X bit determines if a header extension is present, if it
equals one, exactly one header extension is present. When the X bit
is zero, the RTP payload contains *only one* RGL frame. The M bit is
generally defined as being profile specific. The proposed uses of
these bits are as follows:
Ramalho Expires May 9, 2003 [Page 6]
Internet-Draft RTP Payload Format for RGL Codec November 2002
X bit M bit Meaning
(value) (value)
----------------------------------------------------------------
0 0 Exactly one RGL frame in RTP payload. The number
of samples in the RGL frame is ptime*8. No RTP
header extension used.
0 1 Exactly one "eight bit encoded" RGL frame in
payload without first overhead byte (of
{00011110}, see explanation below). No RTP header
extension used.
1 0 One, four-octet RTP Extension is present (length
field in RTP header extension set to zero, as per
RFC 1889). The format for the four-octet header
extension is described below. Exactly one or two
RGL frames in RTP payload. If two RGL frames are
present in the RTP payload, each RGL frame
contains exactly the same number of samples and
this number is specified in the header extension
(i.e., not derived from the optional SDP
parameter "ptime").
1 1 A RTP header extension is present (length defined
by the length field of the RTP header extension).
An arbitrary number of RGL frames are in the RTP
payload, the length of each individual RGL frame
is specified independently in the format of the
RTP header extension described below (i.e., not
derived from the optional SDP parameter "ptime").
The values of the X and M bits proposed are an attempt to minimize
bandwidth for the most commonly envisioned packetizations and to
overcome one detriment with the RGL coding when the G.711 frame is
"RGL uncompressible".
Case One: X=0, M=0: (One RGL frame in RTP payload)
Exactly one RGL frame is placed in RTP payload. The number of
samples contained in this payload is specified by the SDP [7]
"ptime" parameter and is exactly ptime*8 samples. If ptime isn't
explicitly signaled in SDP, the default ptime for the RGL codec is
used (which is defined later to be 20 msec). As described in
draft-ramalho-rgl-desc-00.txt [4] the RGL payload for a ptime=10
millisecond payload (this would map to 10*8 = 80 G.711 samples)
can be from one to 81 bytes long.
Ramalho Expires May 9, 2003 [Page 7]
Internet-Draft RTP Payload Format for RGL Codec November 2002
The entire RTP payload is passed to the RGL decoder at the far-
end.
Case Two: X=0,M=1: (Optional Optimization for One RGL frame in RTP
payload)
Special case to overcome RGL expansion for "uncompressible" G.711
frames.
One deficiency of the RGL codec occurs when the codec determines
that a given frame is "RGL uncompressible". This case occurs when
the full range or almost the full dynamic range of input signals
are present in the G.711 samples input to the coder (see draft-
ramalho-rgl-desc-00.txt [4] for details). When an input G.711
frame is "RGL uncompressible" virtually every bit in the original
frame had significance (high entropy), the codec essentially uses
the same number of bits to encode the frame as the native G.711
encoding (this is called an "eight bit per sample RGL encoding").
Eight bit RGL encodings are always signaled by an overhead byte of
the RGL encoded frame being {00011110} which is placed before the
RGL coded data payload; unfortunately this actually *expands* the
Y sample input frame (Y octets of G.711 PCM) into a Y+1 octet RGL
output frame. This "eight bit per sample" encoding case is the
*only* case where RGL encoding does not compress relative to
native G.711 encoding. When this occurs, the first byte of a RGL
encoded frame is *always* {000011110}. Therefore, it is proposed
that when single RGL encoded frame are being packetized under this
RTP profile, that if the first RGL byte is {00011110}, then this
byte is stripped off, the X and M bit be set to 0 and 1, and the
remainder of the RGL frame be placed in the payload. The RTP
decoder at the far end must pre-append the {00011110} byte to the
Y octet RGL frame in the RTP payload before providing the (Y+1)
octet data frame to the RGL decoder.
Note that if the first byte of the single RGL frame RTP
packetization is not {00011110} (there was a zero-through seven
bit RGL encoding for this frame), then the X and M bits are set to
zero (Case One above) and the entire RGL frame is placed in the
RTP payload.
This optimization ensures that no additional bandwidth over native
G.711 will be used - as "eight bit per sample" RGL frames are
encoded with X=0, M=1 in the RTP header (resulting in exactly as
many RGL octets in the RTP payload as native G.711 octets) and
zero through seven bit encodings are encoded with X=0, M=0 in the
RTP header (and always have less than 73 byte RGL payloads).
Lastly note that this X=0, M=1 encoding technique could be made
Ramalho Expires May 9, 2003 [Page 8]
Internet-Draft RTP Payload Format for RGL Codec November 2002
optional by the RTP encoder and correct RTP decoding at the far-
end is possible. That is, if one does not desire to support this
optimization for a single RGL frame with an eight bit encoding,
one could simply insert the Y+1 octet payload of an eight bit
encoded frame in the RTP payload and use the X=0 and M=0 coding as
above. The processing by the RTP decoding will function
correctly. Thus all RTP encoding implementations of this RTP
payload format MAY use the X=0, M=1 optimization when appropriate,
however all RTP decoding implementations of this RTP payload
format MUST be able to accept the X=0, M=1 format.
The entire RTP payload is passed to the RGL decoder at the far-
end.
Case Three: X=1, M=0: (Two RGL frames of identical number of samples
or One RGL frame in RTP payload)
A very common case of one or two RGL frames per RTP packet where
if a second RGL frame is present, it contains the identical number
of samples as the first frame.
In draft-ramalho-rgl-desc-00.txt [4], the size of the RGL frame
can be deduced by knowing the number of samples in the RGL frame
and the value of the first byte of a RGL frame (called the first
overhead byte). Therefore one can deduce where the second RGL
frame in a RTP packet begins by knowing these two pieces of
information. However, deducing the length of the first of
multiple RGL frames in a RTP payload may be undesirable using this
approach. Therefore an explicit calculation can be made at the
RTP layer to determine the beginning of the second RGL frame by
knowing the size (in octets) of the first RGL frame. The proposed
four octet header extension is as below.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RGL_Size_1 | Num_of_Samps | RTP_Extension_Header_Length |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
\ \
/ RTP PAYLOAD: One or two RGL Codec Frames /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The first four octets are the actual RTP header extension and the
first two octets are defined in RFC1889 [5] as defined for RTP
profile use. This draft proposes that the first two octets, the
RGL_Size_1 and Num_of_Samps, have the following meaning:
Ramalho Expires May 9, 2003 [Page 9]
Internet-Draft RTP Payload Format for RGL Codec November 2002
Field Length Meaning
----------------------------------------------------------------------
RGL_Size_1 8 bits If two RGL frames are present in RTP payload,
(unsigned, the beginning of the second RGL frame begins
uchar8) "RGL_Size_1+1" octets into the RTP payload.
Since the RGL payload size is a minimum of
one byte, RGL_Size_1=0 is used to indicate
that there is only one RGL frame in the RTP
payload (the entire RTP payload is passed to
the RGL decoder at the far-end). This
encoding allows for RGL payloads of maximum
length of 255 bytes and therefore worst case
RGL frames containing a maximum of 255
samples (31.875 milliseconds of G.711).
Num_of_Samps 8 bits The number of samples in the RGL encoded
(unsigned, frame(s). As noted above, this range should
uchar8) be from 1 to 255 samples.
The entire RTP payload is passed to the RGL decoder at the far-end
if the RGL_Size_1 field is 0 (only one RGL frame in RTP payload).
If the RGL_Size_1 field is not equal to 0, then the RTP payload up
to RGL_Size_1 bytes past the RTP extension length field byte is
passed to the RGL decoder at the far-end as the first RGL frame
and the remainder of the RTP payload is passed to the RGL decoder
as the second RGL frame. The Num_of_Samps octet is also passed to
the RGL decoder along with the individual RGL frames.
As noted previously, the RGL decoder can infer the true length of
RGL encoded frame from knowledge of the first RGL byte and the
number of samples included in the frame. Thus, the RGL decoder
can infer the length of it's data for the case in which padding
bytes were added to the RGL octets during RTP payload processing.
Therefore, there is no need to explicitly specify the length of
the second RGL frame (if it is present).
Case Four: X=1, M=1: (Arbitrary number of RGL frames in RTP payload,
each of arbitrary size)
This case is included to have the most flexible packing of an
arbitrary number of RGL frames, each of arbitrary length, into a
RTP payload. This flexibility comes at a cost of longer RTP
header extensions; however for delay-insensitive applications this
option may save overall bandwidth due the need send fewer packets
(saving RTP/UDP/IP overheads). The proposed RTP header extension
is as below.
Ramalho Expires May 9, 2003 [Page 10]
Internet-Draft RTP Payload Format for RGL Codec November 2002
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RGL_Size_1 | Num_Samps_1 | RTP_Extension_Header_Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RGL_Size_2 | Num_Samps_2 | RGL_Size_3 | Num_Samps_3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RGL_Size_4 | Num_Samps_4 | RGL_Size_5 | Num_Samps_5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Additional lines of identical format to above, as needed /
\ \
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
\ \
/ RTP PAYLOAD: Multiple RGL Codec Frame(s) /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The first four octet of RTP header extension have been designed
using a methodology similar to the X=1, M=0 case above. Let the
number of RGL frames in the RTP payload be N and let the frame
under consideration be indexed by "j". The two octet tuple
{RGL_Size_j, Num_Samps_j} are added in the RTP header extension
for each RGL frame carried in the RTP payload as depicted above.
If the last such tuple added results in a RTP header extension
that is not 32-bit word aligned, the remaining octets on that 32-
bit word boundary MUST be padded with zeros. Thus if an even
number of RGL frames are in the RTP payload, this ensures that the
last "RGL_Size_j" octet in the RTP extension header is zero.
Ramalho Expires May 9, 2003 [Page 11]
Internet-Draft RTP Payload Format for RGL Codec November 2002
Field Length Meaning
----------------------------------------------------------------------
RGL_Size_1 8 bits The beginning of the first RGL frame
(unsigned, begins at the first byte of the RTP
uchar8) payload. If RGL_Size_1=0, then the entire
payload contains only one RGL frame and
the entire payload is passed to the RGL
decoder. Note the if there is only one RGL
frame in the RTP payload, the X=1, M=0
(Case Three) packetization could be
equivalently used. RGL_Size_1=0 is
specified identically to the X=1, M=0 case
in order to make the extension header
processing for the first 32-bytes of the
RTP header extension identical for both
cases.
RGL_Size_2 8 bits The beginning of the second RGL frame,
(unsigned, if present, is RGL_Size_1+1 bytes into the
uchar8) RGL payload. The size of the RGL frame is
exactly RGL_Size_2 octets.
RGL_Size_j 8 bits The beginning of the RGL frame j
(unsigned, (for j>2), if present, is
uchar8) [RGL_Size_1+ ... +RGL_Size_(j-1)]+1 bytes
into the RTP payload. The size of RGL
frame j, if present, is exactly RGL_Size_j
octets. If RGL_Size_j=0, then the RTP
payload has precisely (j-1) RGL payloads
in it.
Num_Samps_j 8 bits The number of samples in RGL encoded frame j.
(unsigned, As noted above, this range should be from 1 to
uchar8) 255 samples.
For each RGL frame j, the Num_Samps_j octet (the number of samples
in RGL frame j), is passed to the RGL decoder along with the
corresponding RGL frame data.
Ramalho Expires May 9, 2003 [Page 12]
Internet-Draft RTP Payload Format for RGL Codec November 2002
4. SDP Issues
Until further experience is gained with the RGL codec, it is
RECOMMENDED that the RGL codec be referred to as an experimental
encoding with name: X-RGLv0 (v0 for version 0). Additionally, as the
RGL codec is not a defined SDP [7] static codec type, it must use a
SDP dynamic payload type and be referenced via an SDP rtpmap
attribute. Lastly, noting that the number of samples in a RTP
payload that contains only one RGL frame is determined by the
optional SDP parameter "ptime" [7], we must specify ptime in the SDP
if we desire other than the default ptime for X-RGLv0.
Putting this together, we have an example SDP of:
m=audio 49232 RTP/AVT 94
94=rtpmap:94 X-RGLv0/8000
a=ptime:10
Where the dynamic payload type of 94 is used (as an example), the
default sampling rate is identical to PCMU/PCMA (i.e., 8kHz), and the
default RGL frame size for RTP payload containing one RGL frame is 10
milliseconds (i.e., 80 G.711 samples in each RGL frame). As noted
previously, knowledge of ptime is only required for the case where
there is only one RGL frame in the RTP payload; for multiple RGL
frames per RTP payload the length of each RGL frame (in bytes) in
contained in the RTP header extension along with the number of G711
samples in each RGL frame. If the ptime line is not specified in the
SDP, then the default ptime of 20 msec is used. In this way ptime is
not used in RTP decoding (a RFC 2327 [7] requirement).
The default ptime for the X-RGL codec is defined here to be 20
milliseconds, thereby making it consistent with the default G.711
(PCMU/PCMA) ptime in RFC 1889 [5]. However, it is recommended that
ptime be set to 10 milliseconds for general use (see RGL Codec
Whitepaper at www.vovida.org [13] for rationale) or a more
appropriate value for interworking with existing PSTN/GSTN endpoints
(e.g., 5.5 milliseconds for ATMVoAAL2).
Ramalho Expires May 9, 2003 [Page 13]
Internet-Draft RTP Payload Format for RGL Codec November 2002
5. Security Considerations
RTP packets using the payload format defined in this specification
are subject to the general security considerations discussed in [5]
and any appropriate profile (e.g.[6]).
As this format transports encoded speech, the main security issues
include confidentiality and authentication of the speech itself. The
payload format itself does not have any built-in security mechanisms.
Confidentiality of the media streams is achieved by encryption,
therefore external mechanisms, such as SRTP [8], MAY be used for that
purpose. The data compression used with this payload format is
applied end-to-end; hence encryption may be performed after
compression with no conflict between the two operations. Note also
that the RGL payload format is self-describing; if padding of the RGL
payload is required by the encryption operation, the decoding of the
RGL payload can occur at the far-end without knowledge of the amount
of padding.
A potential Denial-Of-Service (DOS) threat exists for data encoding
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 (e.g., inject hard or
impossible inverse root-finding situations) and cause the receiver to
become overloaded. The RGL codec, due to its trivial complexity, has
bounded receiver-end load for any "bogus RGL" compressed frames and
thus does not suffer from this fate. The only known DOS attack is
simply a stream of more frames than the RTP/DSP flow can accommodate.
Ramalho Expires May 9, 2003 [Page 14]
Internet-Draft RTP Payload Format for RGL Codec November 2002
6. IANA considerations
Until more experience is gained with the RGL codec, it is recommended
to be used as an experimental codec with name: X-RGL.
When and if the RGL codec becomes mainstream, IANA registration may
be necessary.
Ramalho Expires May 9, 2003 [Page 15]
Internet-Draft RTP Payload Format for RGL Codec November 2002
References
[1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[3] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[4] Ramalho, M., "RGL Codec Description Document", draft-ramalho-
rgl-desc-00.txt (work in progress), November 2002.
[5] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson,
"RTP: A transport Protocol for Real-Time Applications", RFC
1889, January 1996.
[6] Schulzrinne, H., "RTP Profile for Audio and Video Conferences
with Minimal Control", RFC 1890, January 1996.
[7] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998.
[8] Baugher, M., Blom, R., Carrara, E., McGrew, D., Naslund, M.,
Noorman, K. and D. Oran, "The Secure Real-TIme Transport
Protocol", draft-ietf-avt-srtp-05.txt (work in progress), June
2002.
[9] <http://www.vovida.org>
[10] <http://www.vovida.org>
[11] <http://www.vovida.org>
[12] <http://www.vovida.org>
[13] <http://www.vovida.org>
Ramalho Expires May 9, 2003 [Page 16]
Internet-Draft RTP Payload Format for RGL Codec November 2002
Author's Address
Michael A. Ramalho
Cisco Systems, Inc.
1802 Rue de la Porte
Wall Township, NJ 07719-3784
USA
Phone: +1.941.708.4650
EMail: mramalho@cisco.com
Ramalho Expires May 9, 2003 [Page 17]
Internet-Draft RTP Payload Format for RGL Codec November 2002
Full Copyright Statement
Copyright (C) The Internet Society (2002). 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.
Ramalho Expires May 9, 2003 [Page 18]