diff options
Diffstat (limited to 'doc/draft-herlein-speex-rtp-profile-02.txt')
| -rw-r--r-- | doc/draft-herlein-speex-rtp-profile-02.txt | 841 |
1 files changed, 0 insertions, 841 deletions
diff --git a/doc/draft-herlein-speex-rtp-profile-02.txt b/doc/draft-herlein-speex-rtp-profile-02.txt deleted file mode 100644 index 2b25ea6..0000000 --- a/doc/draft-herlein-speex-rtp-profile-02.txt +++ /dev/null @@ -1,841 +0,0 @@ - - -AVT Working Group G. Herlein -Internet-Draft S. Morlat -Expires: October 3, 2005 J. Jean-Marc - R. Hardiman - P. Kerr - April 04, 2005 - - - draft-herlein-speex-rtp-profile-02 - RTP Payload Format for the Speex Codec - -Status of this Memo - - This document is an Internet-Draft and is subject to all provisions - of section 3 of RFC 3667. By submitting this Internet-Draft, each - author represents that any applicable patent or other IPR claims of - which he or she is aware have been or will be disclosed, and any of - which he or she become aware will be disclosed, in accordance with - RFC 3668. - - 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 October 3, 2005. - -Copyright Notice - - Copyright (C) The Internet Society (2005). - -Abstract - - Speex is an open-source voice codec suitable for use in Voice over IP - (VoIP) type applications. This document describes the payload format - for Speex generated bit streams within an RTP packet. Also included - here are the necessary details for the use of Speex with the Session - Description Protocol (SDP) and a preliminary method of using Speex - - - -Herlein, et al. Expires October 3, 2005 [Page 1] - -Internet-Draft draft-herlein-speex-rtp-profile-02 April 2005 - - - within H.323 applications. - -Table of Contents - - 1. Conventions used in this document . . . . . . . . . . . . . 3 - 2. Overview of the Speex Codec . . . . . . . . . . . . . . . . 3 - 3. RTP payload format for Speex . . . . . . . . . . . . . . . . 3 - 4. RTP Header . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 5. Speex payload . . . . . . . . . . . . . . . . . . . . . . . 5 - 6. Example Speex packet . . . . . . . . . . . . . . . . . . . . 6 - 7. Multiple Speex frames in a RTP packet . . . . . . . . . . . 6 - 8. MIME registration of Speex . . . . . . . . . . . . . . . . . 7 - 9. SDP usage of Speex . . . . . . . . . . . . . . . . . . . . . 8 - 10. ITU H.323/H.245 Use of Speex . . . . . . . . . . . . . . . . 10 - 11. NonStandardMessage format . . . . . . . . . . . . . . . . . 10 - 12. RTP Payload Types . . . . . . . . . . . . . . . . . . . . . 11 - 13. Security Considerations . . . . . . . . . . . . . . . . . . 11 - 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 12 - 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 - 15.1 Normative References . . . . . . . . . . . . . . . . . . . 12 - 15.2 Informative References . . . . . . . . . . . . . . . . . . 13 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 13 - Intellectual Property and Copyright Statements . . . . . . . 15 - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Herlein, et al. Expires October 3, 2005 [Page 2] - -Internet-Draft draft-herlein-speex-rtp-profile-02 April 2005 - - -1. Conventions used in this document - - 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 RFC 2119 [1]. - -2. Overview of the Speex Codec - - Speex is based on the CELP [10] encoding technique with support for - either narrowband (nominal 8kHz), wideband (nominal 16kHz) or - ultra-wideband (nominal 32kHz), and (non-optimal) rates up to 48 kHz - sampling also available. The main characteristics can be summarized - as follows: - - o Free software/open-source - o Integration of wideband and narrowband in the same bit-stream - o Wide range of bit-rates available - o Dynamic bit-rate switching and variable bit-rate (VBR) - o Voice Activity Detection (VAD, integrated with VBR) - o Variable complexity - -3. RTP payload format for Speex - - For RTP based transportation of Speex encoded audio the standard RTP - header [2] is followed by one or more payload data blocks. An - optional padding terminator may also be used. - - 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 | - +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ - | one or more frames of Speex .... | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | one or more frames of Speex .... | padding | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - -4. RTP Header - - 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 | - - - -Herlein, et al. Expires October 3, 2005 [Page 3] - -Internet-Draft draft-herlein-speex-rtp-profile-02 April 2005 - - - +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ - | contributing source (CSRC) identifiers | - | ... | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - The RTP header begins with an octet of fields (V, P, X, and CC) to - support specialized RTP uses (see [2] and [7] for details). For - Speex the following values are used. - - Version (V): 2 bits - - This field identifies the version of RTP. The version used by this - specification is two [2]. - - Padding (P): 1 bit - - If the padding bit is set, the packet contains one or more additional - padding octets at the end which are not part of the payload. P is - set if the total packet size is less than the MTU. - - Extension (X): 1 bit - - If the extension, X, bit is set, the fixed header MUST be followed by - exactly one header extension, with a format defined in Section 5.3.1. - of [2]. - - CSRC count (CC): 4 bits - - The CSRC count contains the number of CSRC identifiers. - - Marker (M): 1 bit - - The M bit indicates if the packet contains comfort noise. This field - is used in conjunction with the cng SDP attribute and is detailed - further in section 5 below. In normal usage this bit is set if the - packet contains comfort noise. - - Payload Type (PT): 7 bits - - An RTP profile for a class of applications is expected to assign a - payload type for this format, or a dynamically allocated payload type - SHOULD be chosen which designates the payload as Speex. - - Sequence number: 16 bits - - The sequence number increments by one for each RTP data packet sent, - and may be used by the receiver to detect packet loss and to restore - packet sequence. This field is detailed further in [2]. - - - -Herlein, et al. Expires October 3, 2005 [Page 4] - -Internet-Draft draft-herlein-speex-rtp-profile-02 April 2005 - - - Timestamp: 32 bits - - A timestamp representing the sampling time of the first sample of the - first Speex packet in the RTP packet. The clock frequency MUST be - set to the sample rate of the encoded audio data. Speex uses 20 msec - frames and a variable sampling rate clock. The RTP timestamp MUST be - in units of 1/X of a second where X is the sample rate used. Speex - uses a nominal 8kHz sampling rate for narrowband use, a nominal 16kHz - sampling rate for wideband use, and a nominal 32kHz sampling rate for - ultra-wideband use. - - SSRC/CSRC identifiers: - - These two fields, 32 bits each with one SSRC field and a maximum of - 16 CSRC fields, are as defined in [2]. - -5. Speex payload - - For the purposes of packetizing the bit stream in RTP, it is only - necessary to consider the sequence of bits as output by the Speex - encoder [9], and present the same sequence to the decoder. The - payload format described here maintains this sequence. - - A typical Speex frame, encoded at the maximum bitrate, is approx. - 110 octets and the total number of Speex frames SHOULD be kept less - than the path MTU to prevent fragmentation. Speex frames MUST NOT be - fragmented across multiple RTP packets, - - An RTP packet MAY contain Speex frames of the same bit rate or of - varying bit rates, since the bit-rate for a frame is conveyed in band - with the signal. - - The encoding and decoding algorithm can change the bit rate at any 20 - msec frame boundary, with the bit rate change notification provided - in-band with the bit stream. Each frame contains both "mode" - (narrowband, wideband or ultra-wideband) and "sub-mode" (bit-rate) - information in the bit stream. No out-of-band notification is - required for the decoder to process changes in the bit rate sent by - the encoder. - - It is RECOMMENDED that values of 8000, 16000 and 32000 be used for - normal internet telephony applications, though the sample rate is - supported at rates as low as 6000 Hz and as high as 48 kHz. - - The RTP payload MUST be padded to provide an integer number of octets - as the payload length. These padding bits are LSB aligned in network - octet order and consist of a 0 followed by all ones (until the end of - the octet). This padding is only required for the last frame in the - - - -Herlein, et al. Expires October 3, 2005 [Page 5] - -Internet-Draft draft-herlein-speex-rtp-profile-02 April 2005 - - - packet, and only to ensure the packet contents ends on an octet - boundary. - -6. Example Speex packet - - In the example below we have a single Speex frame with 5 bits of - padding to ensure the packet size falls on an octet boundary. - - 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 | - +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ - - 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 - +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ - | contributing source (CSRC) identifiers | - | ... | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | ..speex data.. | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | ..speex data.. |0 1 1 1 1| - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - -7. Multiple Speex frames in a RTP packet - - Below is an example of two Speex frames contained within one RTP - packet. The Speex frame length in this example fall on an octet - boundary so there is no padding. - - Speex codecs [9] are able to detect the the bitrate from the payload - and are responsible for detecting the 20 msec boundaries between each - frame. - - 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 | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - -Herlein, et al. Expires October 3, 2005 [Page 6] - -Internet-Draft draft-herlein-speex-rtp-profile-02 April 2005 - - - | synchronization source (SSRC) identifier | - +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ - | contributing source (CSRC) identifiers | - | ... | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | ..speex data.. | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | ..speex data.. | ..speex data.. | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | ..speex data.. | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - -8. MIME registration of Speex - - Full definition of the MIME [3] type for Speex will be part of the - Ogg Vorbis MIME type definition application [8]. - - MIME media type name: audio - - MIME subtype: speex - - Optional parameters: - - Required parameters: to be included in the Ogg MIME specification. - - Encoding considerations: - - Security Considerations: - - See Section 6 of RFC 3047. - - Interoperability considerations: none - - Published specification: - - Applications which use this media type: - - Additional information: none - - Person & email address to contact for further information: - - Greg Herlein <gherlein@herlein.com> - Jean-Marc Valin <jean-marc.valin@hermes.usherb.ca> - - Intended usage: COMMON - - - - -Herlein, et al. Expires October 3, 2005 [Page 7] - -Internet-Draft draft-herlein-speex-rtp-profile-02 April 2005 - - - Author/Change controller: - - Author: Greg Herlein <gherlein@herlein.com> - Change controller: Greg Herlein <gherlein@herlein.com> - Change controller: IETF AVT Working Group - - This transport type signifies that the content is to be interpreted - according to this document if the contents are transmitted over RTP. - Should this transport type appear over a lossless streaming protocol - such as TCP, the content encapsulation should be interpreted as an - Ogg Stream in accordance with [8], with the exception that the - content of the Ogg Stream may be assumed to be Speex audio and Speex - audio only. - -9. SDP usage of Speex - - When conveying information by SDP [4], the encoding name MUST be set - to "speex". An example of the media representation in SDP for - offering a single channel of Speex at 8000 samples per second might - be: - - m=audio 8088 RTP/AVP 97 - a=rtpmap:97 speex/8000 - - Note that the RTP payload type code of 97 is defined in this media - definition to be 'mapped' to the speex codec at an 8kHz sampling - frequency using the 'a=rtpmap' line. Any number from 96 to 127 could - have been chosen (the allowed range for dynamic types). - - The value of the sampling frequency is typically 8000 for narrow band - operation, 16000 for wide band operation, and 32000 for ultra-wide - band operation. - - If for some reason the offerer has bandwidth limitations, the client - may use the "b=" header, as explained in SDP [4]. The following - example illustrates the case where the offerer cannot receive more - than 10 kbit/s. - - m=audio 8088 RTP/AVP 97 - b=AS:10 - a=rtmap:97 speex/8000 - - In this case, if the remote part agrees, it should configure its - Speex encoder so that it does not use modes that produce more than 10 - kbit/s. Note that the "b=" constraint also applies on all payload - types that may be proposed in the media line ("m="). - - An other way to make recommendations to the remote Speex encoder is - - - -Herlein, et al. Expires October 3, 2005 [Page 8] - -Internet-Draft draft-herlein-speex-rtp-profile-02 April 2005 - - - to use its specific parameters via the a=fmtp: directive. The - following parameters are defined for use in this way: - - ptime: duration of each packet in milliseconds. - - sr: actual sample rate in Hz. - - ebw: encoding bandwidth - either 'narrow' or 'wide' or 'ultra' - (corresponds to nominal 8000, 16000, and 32000 Hz sampling rates). - - vbr: variable bit rate - either 'on' 'off' or 'vad' (defaults - to off). If on, variable bit rate is enabled. If off, disabled. - If set to 'vad' then constant bit rate is used but silence will be - encoded with special short frames to indicate a lack of voice for - that period. - - cng: comfort noise generation - either 'on' or 'off'. If off - then silence frames will be silent; if 'on' then those frames will - be filled with comfort noise. - - mode: Speex encoding mode. Can be {1,2,3,4,5,6,any} defaults to - 3 in narrowband, 6 in wide and ultra-wide. - - penh: use of perceptual enhancement. 1 indicates to the decoder - that perceptual enhancement is recommended, 0 indicates that it is - not. Defaults to on (1). - - - Examples: - - m=audio 8008 RTP/AVP 97 - a=rtpmap:97 speex/8000 - a=fmtp:97 mode=4 - - This examples illustrate an offerer that wishes to receive a Speex - stream at 8000Hz, but only using speex mode 3. - - The offerer may suggest to the remote decoder to activate its - perceptual enhancement filter like this: - - m=audio 8088 RTP/AVP 97 - a=rtmap:97 speex/8000 - a=fmtp:97 penh=1 - - Several Speex specific parameters can be given in a single a=fmtp - line provided that they are separated by a semi-colon: - - - - - -Herlein, et al. Expires October 3, 2005 [Page 9] - -Internet-Draft draft-herlein-speex-rtp-profile-02 April 2005 - - - a=fmtp:97 mode=any;penh=1 - - The offerer may indicate that it wishes to send variable bit rate - frames with comfort noise: - - m=audio 8088 RTP/AVP 97 - a=rtmap:97 speex/8000 - a=fmtp:97 vbr=on;cng=on - - The "ptime" attribute is used to denote the packetization interval - (ie, how many milliseconds of audio is encoded in a single RTP - packet). Since Speex uses 20 msec frames, ptime values of multiples - of 20 denote multiple Speex frames per packet. Values of ptime which - are not multiples of 20 MUST be ignored and clients MUST use the - default value of 20 instead. - - In the example below the ptime value is set to 40, indicating that - there are 2 frames in each packet. - - m=audio 8008 RTP/AVP 97 - a=rtpmap:97 speex/8000 - a=ptime:40 - - Note that the ptime parameter applies to all payloads listed in the - media line and is not used as part of an a=fmtp directive. - - Values of ptime not multiple of 20 msec are meaningless, so the - receiver of such ptime values MUST ignore them. If during the life - of an RTP session the ptime value changes, when there are multiple - Speex frames for example, the SDP value must also reflect the new - value. - - Care must be taken when setting the value of ptime so that the RTP - packet size does not exceed the path MTU. - -10. ITU H.323/H.245 Use of Speex - - Application is underway to make Speex a standard ITU codec. However, - until that is finalized, Speex MAY be used in H.323 [5] by using a - non-standard codec block definition in the H.245 [6] codec capability - negotiations. - -11. NonStandardMessage format - - For Speex use in H.245 [6] based systems, the fields in the - NonStandardMessage should be: - - - - - -Herlein, et al. Expires October 3, 2005 [Page 10] - -Internet-Draft draft-herlein-speex-rtp-profile-02 April 2005 - - - t35CountryCode = Hex: B5 - t35Extension = Hex: 00 - manufacturerCode = Hex: 0026 - [Length of the Binary Sequence (8 bit number)] - [Binary Sequence consisting of an ASCII string, no NULL - terminator] - - The binary sequence is an ascii string merely for ease of use. The - string is not null terminated. The format of this string is - - speex [optional variables] - - The optional variables are identical to those used for the SDP a=fmtp - strings discussed in section 5 above. The string is built to be all - on one line, each key-value pair separated by a semi-colon. The - optional variables MAY be omitted, which causes the default values to - be assumed. They are: - - ebw=narrow;mode=3;vbr=off;cng=off;ptime=20;sr=8000;penh=no; - - The fifth octet of the block is the length of the binary sequence. - - NOTE: this method can result in the advertising of a large number of - Speex 'codecs' based on the number of variables possible. For most - VoIP applications, use of the default binary sequence of 'speex' is - RECOMMENDED to be used in addition to all other options. This - maximizes the chances that two H.323 based applications that support - Speex can find a mutual codec. - -12. RTP Payload Types - - Dynamic payload type codes MUST be negotiated 'out-of-band' for the - assignment of a dynamic payload type from the range of 96-127. H.323 - applications MUST use the H.245 H2250LogicalChannelParameters - encoding to accomplish this. - -13. Security Considerations - - RTP packets using the payload format defined in this specification - are subject to the security considerations discussed in the RTP - specification [2], 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 - - - -Herlein, et al. Expires October 3, 2005 [Page 11] - -Internet-Draft draft-herlein-speex-rtp-profile-02 April 2005 - - - 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. - -14. Acknowledgments - - The authors would like to thank Equivalence Pty Ltd of Australia for - their assistance in attempting to standardize the use of Speex in - H.323 applications, and for implementing Speex in their open source - OpenH323 stack. The authors would also like to thank Brian C. Wiles - <brian@streamcomm.com> of StreamComm for his assistance in developing - the proposed standard for Speex use in H.323 applications. - - The authors would also like to thank the following members of the - Speex and AVT communities for their input: Ross Finlayson, Federico - Montesino Pouzols, Henning Schulzrinne, Magnus Westerlund. - -15. References - -15.1 Normative References - - [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement - Levels", RFC 2119. - - [2] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, - "RTP: A Transport Protocol for real-time applications", RFC - 3550. - - [3] "Multipurpose Internet Mail Extensions (MIME) Part One: Format - of Internet Message Bodies", RFC 2045. - - [4] Jacobson, V. and M. Handley, "SDP: Session Description - Protocol", RFC 2327. - - [5] "Packet-based Multimedia Communications Systems", ITU-T - Recommendation H.323. - - [6] "Control of communications between Visual Telephone Systems and - Terminal Equipment", ITU-T Recommendation H.245. - - [7] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video - - - -Herlein, et al. Expires October 3, 2005 [Page 12] - -Internet-Draft draft-herlein-speex-rtp-profile-02 April 2005 - - - Conferences with Minimal Control.", RFC 3551. - - [8] Walleij, L., "The application/ogg Media Type", RFC 3534. - -15.2 Informative References - - [9] "Speexenc/speexdec, reference command-line encoder/decoder", - Speex website http://www.speex.org/. - - [10] "CELP, U.S. Federal Standard 1016.", National Technical - Information Service (NTIS) website http://www.ntis.gov/. - - -Authors' Addresses - - Greg Herlein - 2034 Filbert Street - San Francisco, California 94123 - United States - - EMail: gherlein@herlein.com - - - Simon Morlat - 35, av de Vizille App 42 - Grenoble 38000 - France - - EMail: simon.morlat@linphone.org - - - Jean-Marc Valin - Department of Electrical and Computer Engineering - University of Sherbrooke - 2500 blvd Universite - Sherbrooke, Quebec J1K 2R1 - Canada - - EMail: jean-marc.valin@hermes.usherb.ca - - - Roger Hardiman - 49 Nettleton Road - Cheltenham, Gloucestershire GL51 6NR - England - - EMail: roger@freebsd.org - - - - -Herlein, et al. Expires October 3, 2005 [Page 13] - -Internet-Draft draft-herlein-speex-rtp-profile-02 April 2005 - - - Phil Kerr - England - - EMail: phil@plus24.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Herlein, et al. Expires October 3, 2005 [Page 14] - -Internet-Draft draft-herlein-speex-rtp-profile-02 April 2005 - - -Intellectual Property Statement - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - - -Disclaimer of Validity - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM 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. - - -Copyright Statement - - Copyright (C) The Internet Society (2005). This document is subject - to the rights, licenses and restrictions contained in BCP 78, and - except as set forth therein, the authors retain all their rights. - - -Acknowledgment - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - -Herlein, et al. Expires October 3, 2005 [Page 15] - - |