[xiph-commits] r10157 - trunk/speex/doc
giles at svn.xiph.org
giles at svn.xiph.org
Fri Oct 14 10:29:01 PDT 2005
Author: giles
Date: 2005-10-14 10:29:00 -0700 (Fri, 14 Oct 2005)
New Revision: 10157
Added:
trunk/speex/doc/draft-ietf-avt-rtp-speex-00.txt
Log:
Add a copy of the latest rtp draft.
Added: trunk/speex/doc/draft-ietf-avt-rtp-speex-00.txt
===================================================================
--- trunk/speex/doc/draft-ietf-avt-rtp-speex-00.txt 2005-10-14 12:22:47 UTC (rev 10156)
+++ trunk/speex/doc/draft-ietf-avt-rtp-speex-00.txt 2005-10-14 17:29:00 UTC (rev 10157)
@@ -0,0 +1,784 @@
+
+
+
+AVT Working Group G. Herlein
+Internet-Draft S. Morlat
+Expires: April 15, 2006 J. Jean-Marc
+ R. Hardiman
+ P. Kerr
+ October 12, 2005
+
+
+ draft-ietf-avt-rtp-speex-00
+ RTP Payload Format for the Speex Codec
+
+Status of this Memo
+
+ 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 becomes
+ aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+ 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 April 15, 2006.
+
+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).
+
+
+
+
+Herlein, et al. Expires April 15, 2006 [Page 1]
+
+Internet-Draft draft-ietf-avt-rtp-speex-00 October 2005
+
+
+Editors Note
+
+ All references to RFC XXXX are to be replaced by references to the
+ RFC number of this memo, when published.
+
+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 Use of Speex . . . . . . . . . . . . . . . . . . . 10
+ 11. Security Considerations . . . . . . . . . . . . . . . . . . 10
+ 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 11
+ 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
+ 13.1 Normative References . . . . . . . . . . . . . . . . . . 11
+ 13.2 Informative References . . . . . . . . . . . . . . . . . 12
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 12
+ Intellectual Property and Copyright Statements . . . . . . . 14
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Herlein, et al. Expires April 15, 2006 [Page 2]
+
+Internet-Draft draft-ietf-avt-rtp-speex-00 October 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 [8] 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
+
+
+
+
+
+
+
+
+
+
+
+
+Herlein, et al. Expires April 15, 2006 [Page 3]
+
+Internet-Draft draft-ietf-avt-rtp-speex-00 October 2005
+
+
+ 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 |
+ | ... |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ The RTP header begins with an octet of fields (V, P, X, and CC) to
+ support specialized RTP uses (see [2] and [5] 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.
+
+ 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 conforms to
+ Section 4.1. of [5].
+
+ 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.
+
+
+
+Herlein, et al. Expires April 15, 2006 [Page 4]
+
+Internet-Draft draft-ietf-avt-rtp-speex-00 October 2005
+
+
+ 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].
+
+ 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 [7], 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
+
+
+
+Herlein, et al. Expires April 15, 2006 [Page 5]
+
+Internet-Draft draft-ietf-avt-rtp-speex-00 October 2005
+
+
+ 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
+ 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 [7] are able to detect the bitrate from the payload and
+ are responsible for detecting the 20 msec boundaries between each
+ frame.
+
+
+
+
+
+Herlein, et al. Expires April 15, 2006 [Page 6]
+
+Internet-Draft draft-ietf-avt-rtp-speex-00 October 2005
+
+
+ 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 |
+ | ... |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | ..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 [6].
+
+ MIME media type name: audio
+
+ MIME subtype: speex
+
+ Optional parameters:
+
+ Required parameters: to be included in the Ogg MIME specification.
+
+ Encoding considerations:
+
+ This type is only defined for transfer via HTTP as specified in RFC
+ XXXX.
+
+ Security Considerations:
+
+ See Section 6 of RFC 3047.
+
+ Interoperability considerations: none
+
+ Published specification:
+
+ Applications which use this media type:
+
+
+
+Herlein, et al. Expires April 15, 2006 [Page 7]
+
+Internet-Draft draft-ietf-avt-rtp-speex-00 October 2005
+
+
+ Additional information: none
+
+ Person & email address to contact for further information:
+
+ Greg Herlein <gherlein at herlein.com>
+ Jean-Marc Valin <jean-marc.valin at usherbrooke.ca>
+
+ Intended usage: COMMON
+
+ Author/Change controller:
+
+ Author: Greg Herlein <gherlein at herlein.com>
+ Change controller: Greg Herlein <gherlein at 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 [6], 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.
+
+
+
+
+
+Herlein, et al. Expires April 15, 2006 [Page 8]
+
+Internet-Draft draft-ietf-avt-rtp-speex-00 October 2005
+
+
+ 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
+ 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.
+
+
+ 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 4.
+
+ 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 April 15, 2006 [Page 9]
+
+Internet-Draft draft-ietf-avt-rtp-speex-00 October 2005
+
+
+ a=fmtp:97 mode=any;mode=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 Use of Speex
+
+ It is outside the scope of this document to cover the use of Speex
+ and H.323, more details may be found on the Speex website [9].
+
+11. 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
+
+
+
+Herlein, et al. Expires April 15, 2006 [Page 10]
+
+Internet-Draft draft-ietf-avt-rtp-speex-00 October 2005
+
+
+ no conflict between the two operations.
+
+ A potential denial-of-service threat exists for data encodings using
+ compression techniques that have non-uniform receiver-end
+ computational load. The attacker can inject pathological datagrams
+ into the stream which are complex to decode and cause the receiver to
+ be overloaded. However, this encoding does not exhibit any
+ significant non-uniformity.
+
+ As with any IP-based protocol, in some circumstances a receiver may
+ be overloaded simply by the receipt of too many packets, either
+ desired or undesired. Network-layer authentication may be used to
+ discard packets from undesired sources, but the processing cost of
+ the authentication itself may be too high.
+
+12. 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 at 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.
+
+13. References
+
+13.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] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video
+ Conferences with Minimal Control.", RFC 3551.
+
+
+
+
+Herlein, et al. Expires April 15, 2006 [Page 11]
+
+Internet-Draft draft-ietf-avt-rtp-speex-00 October 2005
+
+
+ [6] Walleij, L., "The application/ogg Media Type", RFC 3534.
+
+13.2 Informative References
+
+ [7] "Speexenc/speexdec, reference command-line encoder/decoder",
+ Speex website http://www.speex.org/.
+
+ [8] "CELP, U.S. Federal Standard 1016.", National Technical
+ Information Service (NTIS) website http://www.ntis.gov/.
+
+ [9] "ITU H.323/H.245 Use of Speex", Speex
+ website http://www.speex.org/itu/.
+
+
+Authors' Addresses
+
+ Greg Herlein
+ 2034 Filbert Street
+ San Francisco, California 94123
+ United States
+
+ Email: gherlein at herlein.com
+
+
+ Simon Morlat
+ 35, av de Vizille App 42
+ Grenoble 38000
+ France
+
+ Email: simon.morlat at 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 at usherbrooke.ca
+
+
+
+
+
+
+
+
+
+
+
+Herlein, et al. Expires April 15, 2006 [Page 12]
+
+Internet-Draft draft-ietf-avt-rtp-speex-00 October 2005
+
+
+ Roger Hardiman
+ 49 Nettleton Road
+ Cheltenham, Gloucestershire GL51 6NR
+ England
+
+ Email: roger at freebsd.org
+
+
+ Phil Kerr
+ England
+
+ Email: phil at plus24.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Herlein, et al. Expires April 15, 2006 [Page 13]
+
+Internet-Draft draft-ietf-avt-rtp-speex-00 October 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 at 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 April 15, 2006 [Page 14]
+
More information about the commits
mailing list