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] [10] [11] [12] [13] 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]