doc: remove codec-specific documentation

10 files changed, 0 insertions, 6997 deletions

diff --git a/doc/draft-herlein-avt-rtp-speex-00.txt b/doc/draft-herlein-avt-rtp-speex-00.txt
deleted file mode 100644
index 36733e9..0000000
--- a/doc/draft-herlein-avt-rtp-speex-00.txt
+++ /dev/null
@@ -1,699 +0,0 @@
-
-
-
-
-Internet Engineering Task Force                          Greg Herlein
-Internet Draft                                        Jean-Marc Valin
-draft-herlein-avt-rtp-speex-00.txt                       Simon Morlat
-March 3, 2004                                          Roger Hardiman
-Expires: September 3, 2004                                  Phil Kerr
-
-
-                 RTP Payload Format for the Speex Codec
-
-Status of this Memo
-
-   This document is an Internet-Draft and is in full conformance with
-   all provisions of Section 10 of RFC 2026.
-
-   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
-
-   To view the list Internet-Draft Shadow Directories, see
-   http://www.ietf.org/shadow.html.
-
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2003).  All Rights Reserved.
-
-
-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 within H.323 applications.
-
-
-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 [5].
-
-Herlein, Valin, et. al.     Expires September 3, 2004            [Page 1]
-^L
-Internet-Draft       draft-herlein-avt-rtp-speex-00.txt    March 3, 2004
-
-
-2. Overview of the Speex Codec
-
-   Speex is based on the CELP [12] 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    |
-     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-
-3.1 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            |
-     +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
-     |            contributing source (CSRC) identifiers             |
-     |                              ...                              |
-     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-
-   The RTP header begins with an octet of fields (V, P, X, and CC) to   
-   support specialized RTP uses (see [8] and [9] for details). For 
-   Speex the following values are used.
-
-Herlein, Valin, et. al.     Expires September 3, 2004            [Page 2]
-^L
-Internet-Draft       draft-herlein-avt-rtp-speex-00.txt    March 3, 2004
-
-
-   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 [8], 
-
-   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].
-
-   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].  
-
-
-
-Herlein, Valin, et. al.     Expires September 3, 2004            [Page 3]
-^L
-Internet-Draft       draft-herlein-avt-rtp-speex-00.txt    March 3, 2004
-
-
-3.2 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 [11], 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 byte 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.
-
-
-3.2.1 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              |
-   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
-
-
-Herlein, Valin, et. al.     Expires September 3, 2004            [Page 4]
-^L
-Internet-Draft       draft-herlein-avt-rtp-speex-00.txt    March 3, 2004
-
-
-    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|
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-
-3.4 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 [11] 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                           |
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   |         synchronization source (SSRC) identifier              |
-   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
-   |         contributing source (CSRC) identifiers                |
-   |                              ...                              |
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   |                        ..speex data..                         |
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   |        ..speex data..         |        ..speex data..         |
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   |                        ..speex data..                         |
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-
-4. MIME registration of Speex
-
-   Full definition of the MIME type for Speex will be part of the Ogg
-   Vorbis MIME type definition application [10].  
-
-   MIME media type name: audio
-
-   MIME subtype: speex
-
-Herlein, Valin, et. al.     Expires September 3, 2004            [Page 5]
-^L
-Internet-Draft       draft-herlein-avt-rtp-speex-00.txt    March 3, 2004
-
-
-   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
-
-   Author/Change controller:
-         Author:  Greg Herlein <gherlein@herlein.com>
-         Change controller: Greg Herlein <gherlein@herlein.com>
-
-   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 RFC 3534, with the exception that the
-   content of the Ogg Stream may be assumed to be Speex audio and 
-   Speex audio only.
-
-
-5. 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).  
-
-
-
-Herlein, Valin, et. al.     Expires September 3, 2004            [Page 6]
-^L
-Internet-Draft       draft-herlein-avt-rtp-speex-00.txt    March 3, 2004
-
-
-   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 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).
-
-
-
-
-
-
-Herlein, Valin, et. al.     Expires September 3, 2004            [Page 7]
-^L
-Internet-Draft       draft-herlein-avt-rtp-speex-00.txt    March 3, 2004
-
-
-   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:
-   
-   	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. 
-
-
-
-Herlein, Valin, et. al.     Expires September 3, 2004            [Page 8]
-^L
-Internet-Draft       draft-herlein-avt-rtp-speex-00.txt    March 3, 2004
-
-
-   Care must be taken when setting the value of ptime so that the 
-   RTP packet size does not exceed the path MTU. 
-
-
-6. 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 [6] by
-   using a non-standard codec block definition in the H.245 [7] codec
-   capability negotiations.  
-
-
-6.1 NonStandardMessage format
-
-   For Speex use in H.245 [7] based systems, the fields in the
-   NonStandardMessage should be:
-
-   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 byte 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.   
-
-
-6.2 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.  
-
-Herlein, Valin, et. al.     Expires September 3, 2004            [Page 9]
-^L
-Internet-Draft       draft-herlein-avt-rtp-speex-00.txt    March 3, 2004
-
-
-7. 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
-   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.  
-
-
-8. Normative References
-
-   1.  Bradner, S., "The Internet Standards Process -- Revision 3", BCP
-       9, RFC 2026, October 1996.
-
-   2.  Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP:
-       A Transport Protocol for real-time applications", RFC 1889,
-       January 1996.
-
-   3.  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
-       Extensions (MIME) Part One: Format of Internet Message Bodies",
-       RFC 2045, November 1996.
-
-   4.  Handley, M. and V. Jacobson, "SDP: Session Description 
-       Protocol", RFC 2327, April 1998.
-
-   5.  Bradner, S., "Key words for use in RFCs to Indicate Requirement
-       Levels", BCP 14, RFC 2119, March 1997.
-
-   6.  ITU-T Recommendation H.323.  "Packet-based Multimedia 
-       Communications Systems," 1998.
-
-   7.  ITU-T Recommendation H.245 (1998), "Control of communications
-       between Visual Telephone Systems and Terminal Equipment".
-
-   8.  RTP: A transport protocol for real-time applications. Work   
-       in progress, draft-ietf-avt-rtp-new-12.txt.
-
-Herlein, Valin, et. al.   Expires September 3, 2004             [Page 10]
-^L
-Internet-Draft       draft-herlein-avt-rtp-speex-00.txt    March 3, 2004
-
-
-   9.  RTP Profile for Audio and Video Conferences with Minimal  
-       Control.  Work in progress, draft-ietf-avt-profile-new-13.txt.
-
-   10. L. Walleij, "The application/ogg Media Type", RFC 3534, May 
-       2003.
-
-
-8.1 Informative References
-
-   11. Speexenc/speexdec, reference command-line encoder/decoder, 
-       Speex website, http://www.speex.org/
- 
-   12. CELP, U.S. Federal Standard 1016.  National Technical 
-       Information Service (NTIS) website, http://www.ntis.gov/ 
-
-
-9. 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.
-
-
-10. Author's Address
-
-   Greg Herlein <gherlein@herlein.com>
-   2034 Filbert Street
-   San Francisco, CA 
-   United States 94123
-   
-
-   Jean-Marc Valin <jean-marc.valin@hermes.usherb.ca>
-   Department of Electrical and Computer Engineering
-   University of Sherbrooke
-   2500 blvd UniversitüÃü­üÃé
-   Sherbrooke, Quebec, Canada, J1K 2R1
-
-
-   Simon MORLAT <simon.morlat@linphone.org>
-   35, av de Vizille App 42
-   38000 GRENOBLE
-   FRANCE
-
-
-
-
-Herlein, Valin, et. al.   Expires September 3, 2004             [Page 11]
-^L
-Internet-Draft       draft-herlein-avt-rtp-speex-00.txt    March 3, 2004
-
-
-   Roger Hardiman <roger@freebsd.org>
-   49 Nettleton Road
-   Cheltenham
-   Gloucestershire
-   GL51 6NR
-   England
-
-
-   Phil Kerr <philkerr@elec.gla.ac.uk>
-   Centre for Music Technology
-   University of Glasgow
-   Glasgow
-   G12 8LT
-   Scotland
-
-
-10. Full Copyright Statement
-
-   Copyright (C) The Internet Society (2003).  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.
-
-
-
-
-Herlein, Valin, et. al.   Expires September 3, 2004             [Page 12]
-^L
-
-
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]
-
-
diff --git a/doc/draft-herlein-speex-rtp-profile-03.txt b/doc/draft-herlein-speex-rtp-profile-03.txt
deleted file mode 100644
index d1ad4b3..0000000
--- a/doc/draft-herlein-speex-rtp-profile-03.txt
+++ /dev/null
@@ -1,1232 +0,0 @@
-
-
-AVT Working Group                                             G. Herlein
-Internet-Draft                                                 S. Morlat
-Expires: July 2, 2005                                       J. Jean-Marc
-                                                             R. Hardiman
-                                                                 P. Kerr
-                                                        January 01, 2005
-
-
-                   draft-herlein-speex-rtp-profile-03
-                 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 July 2, 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 July 2, 2005                  [Page 1]
-
-Internet-Draft     draft-herlein-speex-rtp-profile-03       January 2005
-
-
-   within H.323 applications.
-
-Table of Contents
-
-   1.   Conventions used in this document  . . . . . . . . . . . . .   3
-   2.   Overview of the Speex Codec  . . . . . . . . . . . . . . . .   4
-   3.   RTP payload format for Speex . . . . . . . . . . . . . . . .   5
-   4.   RTP Header . . . . . . . . . . . . . . . . . . . . . . . . .   6
-   5.   Speex payload  . . . . . . . . . . . . . . . . . . . . . . .   8
-   6.   Example Speex packet . . . . . . . . . . . . . . . . . . . .   9
-   7.   Multiple Speex frames in a RTP packet  . . . . . . . . . . .  10
-   8.   MIME registration of Speex . . . . . . . . . . . . . . . . .  11
-   9.   SDP usage of Speex . . . . . . . . . . . . . . . . . . . . .  12
-   10.  ITU H.323/H.245 Use of Speex . . . . . . . . . . . . . . . .  15
-   11.  NonStandardMessage format  . . . . . . . . . . . . . . . . .  16
-   12.  RTP Payload Types  . . . . . . . . . . . . . . . . . . . . .  17
-   13.  Security Considerations  . . . . . . . . . . . . . . . . . .  18
-   14.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . .  19
-   15.  References . . . . . . . . . . . . . . . . . . . . . . . . .  20
-   15.1   Normative References . . . . . . . . . . . . . . . . . . .  20
-   15.2   Informative References . . . . . . . . . . . . . . . . . .  20
-        Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  20
-        Intellectual Property and Copyright Statements . . . . . . .  22
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Herlein, et al.           Expires July 2, 2005                  [Page 2]
-
-Internet-Draft     draft-herlein-speex-rtp-profile-03       January 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].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Herlein, et al.           Expires July 2, 2005                  [Page 3]
-
-Internet-Draft     draft-herlein-speex-rtp-profile-03       January 2005
-
-
-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
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Herlein, et al.           Expires July 2, 2005                  [Page 4]
-
-Internet-Draft     draft-herlein-speex-rtp-profile-03       January 2005
-
-
-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    |
-        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Herlein, et al.           Expires July 2, 2005                  [Page 5]
-
-Internet-Draft     draft-herlein-speex-rtp-profile-03       January 2005
-
-
-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            |
-        +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
-        |            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
-
-
-
-Herlein, et al.           Expires July 2, 2005                  [Page 6]
-
-Internet-Draft     draft-herlein-speex-rtp-profile-03       January 2005
-
-
-   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].
-
-   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].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Herlein, et al.           Expires July 2, 2005                  [Page 7]
-
-Internet-Draft     draft-herlein-speex-rtp-profile-03       January 2005
-
-
-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
-   packet, and only to ensure the packet contents ends on an octet
-   boundary.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Herlein, et al.           Expires July 2, 2005                  [Page 8]
-
-Internet-Draft     draft-herlein-speex-rtp-profile-03       January 2005
-
-
-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|
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Herlein, et al.           Expires July 2, 2005                  [Page 9]
-
-Internet-Draft     draft-herlein-speex-rtp-profile-03       January 2005
-
-
-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                           |
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      |         synchronization source (SSRC) identifier              |
-      +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
-      |         contributing source (CSRC) identifiers                |
-      |                              ...                              |
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      |                        ..speex data..                         |
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      |        ..speex data..         |        ..speex data..         |
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      |                        ..speex data..                         |
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Herlein, et al.           Expires July 2, 2005                 [Page 10]
-
-Internet-Draft     draft-herlein-speex-rtp-profile-03       January 2005
-
-
-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
-
-   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.
-
-
-
-
-Herlein, et al.           Expires July 2, 2005                 [Page 11]
-
-Internet-Draft     draft-herlein-speex-rtp-profile-03       January 2005
-
-
-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
-   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
-
-
-
-Herlein, et al.           Expires July 2, 2005                 [Page 12]
-
-Internet-Draft     draft-herlein-speex-rtp-profile-03       January 2005
-
-
-      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:
-
-      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.
-
-
-
-Herlein, et al.           Expires July 2, 2005                 [Page 13]
-
-Internet-Draft     draft-herlein-speex-rtp-profile-03       January 2005
-
-
-   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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Herlein, et al.           Expires July 2, 2005                 [Page 14]
-
-Internet-Draft     draft-herlein-speex-rtp-profile-03       January 2005
-
-
-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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Herlein, et al.           Expires July 2, 2005                 [Page 15]
-
-Internet-Draft     draft-herlein-speex-rtp-profile-03       January 2005
-
-
-11.  NonStandardMessage format
-
-   For Speex use in H.245 [6] based systems, the fields in the
-   NonStandardMessage should be:
-
-      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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Herlein, et al.           Expires July 2, 2005                 [Page 16]
-
-Internet-Draft     draft-herlein-speex-rtp-profile-03       January 2005
-
-
-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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Herlein, et al.           Expires July 2, 2005                 [Page 17]
-
-Internet-Draft     draft-herlein-speex-rtp-profile-03       January 2005
-
-
-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
-   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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Herlein, et al.           Expires July 2, 2005                 [Page 18]
-
-Internet-Draft     draft-herlein-speex-rtp-profile-03       January 2005
-
-
-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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Herlein, et al.           Expires July 2, 2005                 [Page 19]
-
-Internet-Draft     draft-herlein-speex-rtp-profile-03       January 2005
-
-
-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
-        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
-
-
-
-
-
-
-Herlein, et al.           Expires July 2, 2005                 [Page 20]
-
-Internet-Draft     draft-herlein-speex-rtp-profile-03       January 2005
-
-
-   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
-
-
-   Phil Kerr
-   England
-
-   EMail: phil@plus24.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Herlein, et al.           Expires July 2, 2005                 [Page 21]
-
-Internet-Draft     draft-herlein-speex-rtp-profile-03       January 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 July 2, 2005                 [Page 22]
-
diff --git a/doc/draft-herlein-speex-rtp-profile-03.xml b/doc/draft-herlein-speex-rtp-profile-03.xml
deleted file mode 100644
index 709efcd..0000000
--- a/doc/draft-herlein-speex-rtp-profile-03.xml
+++ /dev/null
@@ -1,815 +0,0 @@
-<?xml version='1.0'?>
-<!DOCTYPE rfc SYSTEM 'rfc2629.dtd'>
-<?rfc toc="yes" ?>
-
-<rfc ipr="full3667" docName="RTP Payload Format for the Speex Codec">
-
-<front>
-<title>draft-herlein-speex-rtp-profile-03</title>
-
-<author initials="G" surname="Herlein" fullname="Greg Herlein">
-<organization></organization>
-<address>
-<email>gherlein@herlein.com</email>
-<postal>
-<street>2034 Filbert Street</street>
-<city>San Francisco</city> 
-<region>California</region>
-<code>94123</code>
-<country>United States</country> 
-</postal>
-</address>
-</author>
-
-<author initials="S" surname="Morlat" fullname="Simon Morlat">
-<address>
-<email>simon.morlat@linphone.org</email>
-<postal>
-<street>35, av de Vizille App 42</street>
-<city>Grenoble</city>
-<code>38000</code>
-<country>France</country>
-</postal>
-</address>
-</author>
-
-<author initials="J" surname="Jean-Marc" fullname="Jean-Marc Valin">
-<address>
-<email>jean-marc.valin@hermes.usherb.ca</email>
-<postal>
-<street>Department of Electrical and Computer Engineering</street>
-<street>University of Sherbrooke</street>
-<street>2500 blvd Universite</street>
-<city>Sherbrooke</city>
-<region>Quebec</region>
-<code>J1K 2R1</code>
-<country>Canada</country>
-</postal>
-</address>
-</author>
-
-<author initials="R" surname="Hardiman" fullname="Roger Hardiman">
-<address>
-<email>roger@freebsd.org</email>
-<postal>
-<street>49 Nettleton Road</street>
-<city>Cheltenham</city>
-<region>Gloucestershire</region>
-<code>GL51 6NR</code>
-<country>England</country>
-</postal>
-</address>
-</author>
-
-
-<author initials="P" surname="Kerr" fullname="Phil Kerr">
-<address>
-<email>phil@plus24.com</email>
-<postal>
-<country>England</country>
-</postal>
-</address>
-</author>
-
-<date day="01" month="January" year="2005" />
-
-<area>General</area>
-<workgroup>AVT Working Group</workgroup>
-<keyword>I-D</keyword>
-
-<keyword>Internet-Draft</keyword>
-<keyword>Speex</keyword>
-<keyword>RTP</keyword>
-<abstract>
-<t>
-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 within H.323 applications.
-</t>
-</abstract>
-</front>
-
-<middle>
-
-<section anchor="Conventions used in this document" title="Conventions used in this document">
-<t>
-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 <xref target="rfc2119"></xref>.
-</t>
-</section>
-
-<section anchor="Overview of the Speex Codec" title="Overview of the Speex Codec">
-
-<t>
-Speex is based on the CELP <xref target="CELP"></xref> 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:
-</t>
-
-<t>
-<list style="symbols">
-<t>Free software/open-source</t>
-<t>Integration of wideband and narrowband in the same bit-stream</t>
-<t>Wide range of bit-rates available</t>
-<t>Dynamic bit-rate switching and variable bit-rate (VBR)</t>
-<t>Voice Activity Detection (VAD, integrated with VBR)</t>
-<t>Variable complexity</t>
-</list>
-</t>
-
-</section>
-
-<section anchor="RTP payload format for Speex" title="RTP payload format for Speex">
-
-<t>
-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. 
-</t>
-<artwork><![CDATA[
-      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    |
-     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-]]></artwork>
-
-</section>
-
-<section anchor="RTP Header" title="RTP Header">
-
-<artwork><![CDATA[
-      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             |
-     |                              ...                              |
-     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-]]></artwork>
-
-<t>
-The RTP header begins with an octet of fields (V, P, X, and CC) to   
-support specialized RTP uses (see <xref target="rfc3550"></xref> and <xref target="rfc3551"></xref> for details). For 
-Speex the following values are used.
-</t>
-
-<t>Version (V): 2 bits</t><t>
-   This field identifies the version of RTP. The version
-   used by this specification is two <xref target="rfc3550"></xref>.
-</t>
-
-<t>Padding (P): 1 bit</t><t>
-      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.  
-</t>
-
-<t>Extension (X): 1 bit</t><t>
-      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 <xref target="rfc3550"></xref>. 
-</t>
-
-<t>CSRC count (CC): 4 bits</t><t>
-      The CSRC count contains the number of CSRC identifiers.
-</t>
-
-<t>Marker (M): 1 bit</t><t>
-      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.
-</t>
-
-<t>Payload Type (PT): 7 bits</t><t>
-      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.
-</t>
-
-<t>Sequence number: 16 bits</t><t>
-      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
-      <xref target="rfc3550"></xref>.
-</t>
-
-<t>Timestamp: 32 bits</t><t>
-      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.
-</t>
-
-<t>SSRC/CSRC identifiers:</t><t>
-      These two fields, 32 bits each with one SSRC field and a maximum 
-      of 16 CSRC fields, are as defined in <xref target="rfc3550"></xref>.  
-</t>
-
-</section>
-
-<section anchor="Speex payload" title="Speex payload">
-
-<t>
-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 <xref target="speexenc"></xref>, and present the same sequence to the decoder.  The 
-payload format described here maintains this sequence.  
-</t>
-
-<t>
-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,
-</t>
-
-<t>
-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.
-</t>
-
-<t>
-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.
-</t>
-
-<t>
-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.
-</t>
-
-<t>
-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.
-</t>
-
-</section>
-
-<section anchor="Example Speex packet" title="Example Speex packet">
-
-<t>
-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.
-</t>
-
-<artwork><![CDATA[
-    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|
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-]]></artwork>
-
-</section>
-
-<section anchor="Multiple Speex frames in a RTP packet" title="Multiple Speex frames in a RTP packet">
-
-<t>
-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.
-</t>
-
-<t>
-Speex codecs <xref target="speexenc"></xref> are able to detect the the bitrate from the
-payload and are responsible for detecting the 20 msec boundaries
-between each frame.
-</t>
-
-<artwork><![CDATA[
-    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..                         |
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-]]></artwork>
-
-</section>
-
-<section anchor="MIME registration of Speex" title="MIME registration of Speex">
-
-<t>
-Full definition of the MIME <xref target="rfc2045"></xref> type for Speex will be part of the Ogg
-Vorbis MIME type definition application <xref target="rfc3534"></xref>.  
-</t>
-
-<t>MIME media type name: audio</t>
-
-<t>MIME subtype: speex</t>
-
-<t>Optional parameters:</t>
-
-<t>Required parameters: to be included in the Ogg MIME specification.</t>
-
-<t>Encoding considerations:</t>
-
-<t>Security Considerations:</t>
-<t>See Section 6 of RFC 3047.</t>
-
-<t>Interoperability considerations: none</t>
-
-<t>Published specification:  </t>
-
-<t>Applications which use this media type:</t>
-
-<t>Additional information: none</t>
-
-<t>Person &amp; email address to contact for further information:<vspace blankLines="1" />
-<list style="empty">
-<t>Greg Herlein &lt;gherlein@herlein.com&gt;</t>
-<t>Jean-Marc Valin &lt;jean-marc.valin@hermes.usherb.ca&gt;</t>
-</list>
-</t>
-
-<t>Intended usage: COMMON</t>
-
-<t>Author/Change controller:</t>
-
-<t>
-<list style="empty">
-<t>Author:  Greg Herlein &lt;gherlein@herlein.com&gt;</t>
-<t>Change controller: Greg Herlein &lt;gherlein@herlein.com&gt;</t>          
-<t>Change controller: IETF AVT Working Group</t>
-</list>
-</t>
-
-<t>
-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 <xref target="rfc3534"></xref>, with the exception that the
-content of the Ogg Stream may be assumed to be Speex audio and 
-Speex audio only.
-</t>
-
-</section>
-
-<section anchor="SDP usage of Speex" title="SDP usage of Speex">
-
-<t>
-When conveying information by SDP <xref target="rfc2327"></xref>, 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:
-</t>
-
-<vspace blankLines="1" />
-<list style="empty">
-<t>m=audio 8088 RTP/AVP 97</t>
-<t>a=rtpmap:97 speex/8000</t>
-</list>	
-
-<t>
-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).  
-</t>
-
-<t>
-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.
-</t>
-
-<t>
-If for some reason the offerer has bandwidth limitations, the client 
-may use the "b=" header, as explained in SDP <xref target="rfc2327"></xref>. The following example
-illustrates the case where the offerer cannot receive more than
-10 kbit/s.
-</t>
-
-<vspace blankLines="1" />
-<list style="empty">
-<t>m=audio 8088 RTP/AVP 97</t>
-<t>b=AS:10</t>
-<t>a=rtmap:97 speex/8000</t>
-</list>	
-
-<t>
-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=").
-</t>
-
-<t>
-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:
-</t>
-
-<vspace blankLines="1" />
-<list style="empty">
-<t>ptime: duration of each packet in milliseconds.<vspace blankLines="1" /></t>
-
-<t>sr:    actual sample rate in Hz.<vspace blankLines="1" /></t>
-
-<t>ebw:   encoding bandwidth - either 'narrow' or 'wide' or 
-        'ultra' (corresponds to nominal 8000, 16000, and
-		32000 Hz sampling rates).<vspace blankLines="1" /></t>
-
-<t>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.<vspace blankLines="1" /></t>
-
-<t>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.<vspace blankLines="1" /></t>
-
-<t>mode:  Speex encoding mode. Can be {1,2,3,4,5,6,any}
-                defaults to 3 in narrowband, 6 in wide and ultra-wide.<vspace blankLines="1" /></t>
-
-<t>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).<vspace blankLines="1" /></t>
-</list>	
-
-<t>Examples:</t>
-
-<vspace blankLines="1" />
-<list style="empty">
-   	<t>m=audio 8008 RTP/AVP 97</t>
-	<t>a=rtpmap:97 speex/8000</t>
-	<t>a=fmtp:97 mode=4</t>
-</list>	
-
-<t>
-This examples illustrate an offerer that wishes to receive
-a Speex stream at 8000Hz, but only using speex mode 3.
-</t>
- 
-<t>
-The offerer may suggest to the remote decoder to activate
-its perceptual enhancement filter like this:
-</t>
-
-<vspace blankLines="1" />   
-<list style="empty">
-	<t>m=audio 8088 RTP/AVP 97</t>
-	<t>a=rtmap:97 speex/8000</t>
-	<t>a=fmtp:97 penh=1 </t>
-</list>	
-	
-<t>
-Several Speex specific parameters can be given in a single
-a=fmtp line provided that they are separated by a semi-colon:
-</t>
-
-<vspace blankLines="1" />   
-<list style="empty">
-   	<t>a=fmtp:97 mode=any;penh=1</t>
-</list>	
-
-<t>
-The offerer may indicate that it wishes to send variable bit rate
-frames with comfort noise:
-</t>
-
-<vspace blankLines="1" />
-<list style="empty">
-	<t>m=audio 8088 RTP/AVP 97</t>
-	<t>a=rtmap:97 speex/8000</t>
-	<t>a=fmtp:97 vbr=on;cng=on</t>
-</list>	
-
-<t>
-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.
-</t>
-   
-<t>
-In the example below the ptime value is set to 40, indicating that 
-there are 2 frames in each packet.	
-</t>
-
-<vspace blankLines="1" />   
-<list style="empty">
-   	<t>m=audio 8008 RTP/AVP 97</t>
-	<t>a=rtpmap:97 speex/8000</t>
-	<t>a=ptime:40</t>
-</list>	
-
-<t>
-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.
-</t>
-
-<t>
-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. 
-</t>
-
-<t>
-Care must be taken when setting the value of ptime so that the 
-RTP packet size does not exceed the path MTU. 
-</t>
-
-</section>
-<section anchor="ITU H.323/H.245 Use of Speex" title="ITU H.323/H.245 Use of Speex">
-
-<t>
-Application is underway to make Speex a standard ITU codec.
-However, until that is finalized, Speex MAY be used in H.323 <xref target="H323"></xref> by
-using a non-standard codec block definition in the H.245 <xref target="H245"></xref> codec
-capability negotiations.  
-</t>
-
-</section>
-
-<section anchor="NonStandardMessage format" title="NonStandardMessage format">
-
-<t>
-For Speex use in H.245 <xref target="H245"></xref> based systems, the fields in the
-NonStandardMessage should be:
-</t>
-
-<vspace blankLines="1" />   
-<list style="empty">
-<t>t35CountryCode   = Hex: B5</t>
-<t>t35Extension     = Hex: 00</t>
-<t>manufacturerCode = Hex: 0026</t>
-<t>[Length of the Binary Sequence (8 bit number)]</t>
-<t>[Binary Sequence consisting of an ASCII string, no NULL terminator]</t>
-</list>
-
-<t>
-The binary sequence is an ascii string merely for ease of use.
-The string is not null terminated.  The format of this string is
-</t>
-
-<vspace blankLines="1" />   
-<list style="empty">
-<t>speex [optional variables]</t>
-</list>
-   
-<t>
-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:
-</t>
-
-<vspace blankLines="1" />   
-<list style="empty">
-<t>ebw=narrow;mode=3;vbr=off;cng=off;ptime=20;sr=8000;penh=no;</t>
-</list>
-
-<t>
-The fifth octet of the block is the length of the binary sequence.
-</t>
-
-<t>
-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.   
-</t>
-
-</section>
-
-<section anchor="RTP Payload Types" title="RTP Payload Types">
-
-<t>
-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.  
-</t>
-
-</section>
-
-<section anchor="Security Considerations" title="Security Considerations">
-
-<t>
-RTP packets using the payload format defined in this specification
-are subject to the security considerations discussed in the RTP
-specification <xref target="rfc3550"></xref>, 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.
-</t>
-
-<t>
-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.
-</t>
-
-<t>
-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.  
-</t>
-
-</section> 
-
-<section anchor="Acknowledgments" title="Acknowledgments">
-
-<t>
-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 &lt;brian@streamcomm.com&gt; of StreamComm for his assistance in
-developing the proposed standard for Speex use in H.323
-applications.
-</t>
-
-<t>
-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.
-</t>
-</section> 
-
-</middle>
-
-<back>
-
-<references title="Normative References">
-
-<reference anchor="rfc2119">
-<front>
-<title>Key words for use in RFCs to Indicate Requirement Levels </title>
-<author initials="S." surname="Bradner" fullname="Scott Bradner"></author>
-</front>
-<seriesInfo name="RFC" value="2119" />
-</reference> 
-
-<reference anchor="rfc3550">
-<front>
-<title>RTP: A Transport Protocol for real-time applications</title>
-<author initials="H." surname="Schulzrinne" fullname=""></author>
-<author initials="S." surname="Casner" fullname=""></author>
-<author initials="R." surname="Frederick" fullname=""></author>
-<author initials="V." surname="Jacobson" fullname=""></author>
-</front>
-<seriesInfo name="RFC" value="3550" />
-</reference> 
-
-<reference anchor="rfc2045">
-<front>
-<title>Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies</title>
-<author initials="" surname="" fullname=""></author>
-</front>
-<date month="November" year="1998" />
-<seriesInfo name="RFC" value="2045" />
-</reference> 
-
-<reference anchor="rfc2327">
-<front>
-<title>SDP: Session Description Protocol</title>
-<author initials="V." surname="Jacobson" fullname=""></author>
-<author initials="M." surname="Handley" fullname=""></author>
-</front>
-<date month="April" year="1998" />
-<seriesInfo name="RFC" value="2327" />
-</reference> 
-
-<reference anchor="H323">
-<front>
-<title>Packet-based Multimedia Communications Systems</title>
-<author initials="" surname="" fullname=""></author>
-</front>
-<date month="" year="1998" />
-<seriesInfo name="ITU-T Recommendation" value="H.323" />
-</reference> 
-
-<reference anchor="H245">
-<front>
-<title>Control of communications between Visual Telephone Systems and Terminal Equipment</title>
-<author initials="" surname="" fullname=""></author>
-</front>
-<date month="" year="1998" />
-<seriesInfo name="ITU-T Recommendation" value="H.245" />
-</reference> 
-
-<reference anchor="rfc3551">
-<front>
-<title>RTP Profile for Audio and Video Conferences with Minimal Control.</title>
-<author initials="H." surname="Schulzrinne" fullname=""></author>
-<author initials="S." surname="Casner" fullname=""></author>
-</front>
-<date month="July" year="2003" />
-<seriesInfo name="RFC" value="3551" />
-</reference> 
-
-<reference anchor="rfc3534">
-<front>
-<title>The application/ogg Media Type</title>
-<author initials="L." surname="Walleij" fullname=""></author>
-</front>
-<date month="May" year="2003" />
-<seriesInfo name="RFC" value="3534" />
-</reference> 
-
-</references> 
-
-<references title="Informative References">
-
-<reference anchor="speexenc">
-<front>
-<title>Speexenc/speexdec, reference command-line encoder/decoder</title>
-</front>
-<seriesInfo name="Speex website" value="http://www.speex.org/" />
-</reference> 
-
-<reference anchor="CELP">
-<front>
-<title>CELP, U.S. Federal Standard 1016.</title>
-<author initials="" surname="" fullname=""></author>
-</front>
-<seriesInfo name="National Technical Information Service (NTIS) website" value="http://www.ntis.gov/" />
-</reference> 
-
-</references> 
-
-</back>
-</rfc>
diff --git a/doc/draft-ietf-avt-rtp-speex-00.txt b/doc/draft-ietf-avt-rtp-speex-00.txt
deleted file mode 100644
index 53facab..0000000
--- a/doc/draft-ietf-avt-rtp-speex-00.txt
+++ /dev/null
@@ -1,784 +0,0 @@
-
-
-
-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@herlein.com>
-      Jean-Marc Valin <jean-marc.valin@usherbrooke.ca>
-
-   Intended usage: COMMON
-
-   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 [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@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@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@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@freebsd.org
-
-
-   Phil Kerr
-   England
-
-   Email: phil@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@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]
-
diff --git a/doc/draft-ietf-avt-rtp-speex-01-tmp.txt b/doc/draft-ietf-avt-rtp-speex-01-tmp.txt
deleted file mode 100644
index 1410b85..0000000
--- a/doc/draft-ietf-avt-rtp-speex-01-tmp.txt
+++ /dev/null
@@ -1,1008 +0,0 @@
-
-
-
-AVT                                                           G. Herlein
-Internet-Draft
-Intended status: Standards Track                                J. Valin
-Expires: October 24, 2007                       University of Sherbrooke
-                                                            A. Heggestad
-                                                          April 22, 2007
-
-
-                 RTP Payload Format for the Speex Codec
-                      draft-ietf-avt-rtp-speex-01 (non-final)
-
-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 October 24, 2007.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2007).
-
-
-
-
-
-
-
-
-
-
-
-
-Herlein, et al.         Expires October 24, 2007                [Page 1]
-
-Internet-Draft                    Speex                       April 2007
-
-
-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 October 24, 2007                [Page 2]
-
-Internet-Draft                    Speex                       April 2007
-
-
-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.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
-   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5
-   3.  RTP usage for Speex  . . . . . . . . . . . . . . . . . . . . .  6
-     3.1.  RTP Speex Header Fields  . . . . . . . . . . . . . . . . .  6
-     3.2.  RTP payload format for Speex . . . . . . . . . . . . . . .  6
-     3.3.  Speex payload  . . . . . . . . . . . . . . . . . . . . . .  6
-     3.4.  Example Speex packet . . . . . . . . . . . . . . . . . . .  7
-     3.5.  Multiple Speex frames in a RTP packet  . . . . . . . . . .  7
-   4.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
-     4.1.  Media Type Registration  . . . . . . . . . . . . . . . . .  9
-       4.1.1.  Registration of media type audio/speex . . . . . . . .  9
-   5.  SDP usage of Speex . . . . . . . . . . . . . . . . . . . . . . 11
-   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 14
-   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
-   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
-     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 16
-     8.2.  Informative References . . . . . . . . . . . . . . . . . . 16
-   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
-   Intellectual Property and Copyright Statements . . . . . . . . . . 18
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Herlein, et al.         Expires October 24, 2007                [Page 3]
-
-Internet-Draft                    Speex                       April 2007
-
-
-1.  Introduction
-
-   Speex is based on the CELP [CELP] encoding technique with support for
-   either narrowband (nominal 8kHz), wideband (nominal 16kHz) or ultra-
-   wideband (nominal 32kHz).  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
-
-   To be compliant with this specification, implementations MUST support
-   8 kHz sampling rate (narrowband)" and SHOULD support 8 kbps bitrate.
-   The sampling rate MUST be 8, 16 or 32 kHz.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Herlein, et al.         Expires October 24, 2007                [Page 4]
-
-Internet-Draft                    Speex                       April 2007
-
-
-2.  Terminology
-
-   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 RFC2119 [RFC2119] and
-   indicate requirement levels for compliant RTP implementations.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Herlein, et al.         Expires October 24, 2007                [Page 5]
-
-Internet-Draft                    Speex                       April 2007
-
-
-3.  RTP usage for Speex
-
-3.1.  RTP Speex Header Fields
-
-   The RTP header is defined in the RTP specification [RFC3550].  This
-   section defines how fields in the RTP header are used.
-
-      Payload Type (PT): The assignment of an RTP payload type for this
-      packet format is outside the scope of this document; it is
-      specified by the RTP profile under which this payload format is
-      used, or signaled dynamically out-of-band (e.g., using SDP).
-
-      Marker (M) bit: The M bit is set to one to indicate that the RTP
-      packet payload contains at least one complete frame
-
-      Extension (X) bit: Defined by the RTP profile used.
-
-      Timestamp: A 32-bit word that corresponds to the sampling instant
-      for the first frame in the RTP packet.
-
-3.2.  RTP payload format for Speex
-
-   The RTP payload for Speex has the format shown in Figure 1.  No
-   additional header fields specific to this payload format are
-   required.  For RTP based transportation of Speex encoded audio the
-   standard RTP header [RFC3550] 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    |
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-                     Figure 1: RTP payload for Speex
-
-3.3.  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 [speexenc], 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
-
-
-
-Herlein, et al.         Expires October 24, 2007                [Page 6]
-
-Internet-Draft                    Speex                       April 2007
-
-
-   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.
-
-   Sampling rate values of 8000, 16000 or 32000 Hz MUST be used.  Any
-   other sampling rates MUST NOT be used.
-
-   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.
-
-3.4.  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
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      |                      RTP Header                               |
-      +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
-      |                        ..speex data..                         |
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      |                        ..speex data..               |0 1 1 1 1|
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-3.5.  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 [speexenc] are able to detect the bitrate from the
-
-
-
-Herlein, et al.         Expires October 24, 2007                [Page 7]
-
-Internet-Draft                    Speex                       April 2007
-
-
-   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
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      |                      RTP Header                               |
-      +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
-      |                     ..speex frame 1..                         |
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      |       ..speex frame 1..       |      ..speex frame 2..        |
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      |                      ..speex frame 2..                        |
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Herlein, et al.         Expires October 24, 2007                [Page 8]
-
-Internet-Draft                    Speex                       April 2007
-
-
-4.  IANA Considerations
-
-   This document defines the Speex media type.
-
-4.1.  Media Type Registration
-
-   This section describes the media types and names associated with this
-   payload format.  The section registers the media types, as per
-   RFC4288 [RFC4288]
-
-4.1.1.  Registration of media type audio/speex
-
-   Media type name: audio
-
-   Media subtype name: speex
-
-   Required parameters:
-
-   None
-
-   Optional parameters:
-
-      ptime: see RFC 4566.  SHOULD be a multiple of 20 msec.
-
-      maxptime: see RFC 4566.  SHOULD be a multiple of 20 msec.
-
-   Encoding considerations:
-
-      This media type is framed and binary, see section 4.8 in
-      [RFC4288].
-
-   Security considerations: See Section 6
-
-   Interoperability considerations:
-
-      None.
-
-   Published specification: RFC XXXX [This RFC].
-
-   Applications which use this media type:
-
-      Audio streaming and conferencing applications.
-
-   Additional information: none
-
-   Person and email address to contact for further information :
-
-
-
-
-
-Herlein, et al.         Expires October 24, 2007                [Page 9]
-
-Internet-Draft                    Speex                       April 2007
-
-
-      Alfred E. Heggestad: aeh@db.org
-
-   Intended usage: COMMON
-
-   Restrictions on usage:
-
-      This media type depends on RTP framing, and hence is only defined
-      for transfer via RTP [RFC3550].  Transport within other framing
-      protocols is not defined at this time.
-
-   Author: Alfred E. Heggestad
-
-   Change controller:
-
-      IETF Audio/Video Transport working group delegated from the IESG.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Herlein, et al.         Expires October 24, 2007               [Page 10]
-
-Internet-Draft                    Speex                       April 2007
-
-
-5.  SDP usage of Speex
-
-   When conveying information by SDP [RFC4566], 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 [RFC4566].  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
-   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).
-
-
-
-
-
-
-Herlein, et al.         Expires October 24, 2007               [Page 11]
-
-Internet-Draft                    Speex                       April 2007
-
-
-      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:
-
-      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.
-
-   Implementations SHOULD support ptime of 20 msec (i.e. one frame per
-   packet)
-
-   In the example below the ptime value is set to 40, indicating that
-
-
-
-Herlein, et al.         Expires October 24, 2007               [Page 12]
-
-Internet-Draft                    Speex                       April 2007
-
-
-   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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Herlein, et al.         Expires October 24, 2007               [Page 13]
-
-Internet-Draft                    Speex                       April 2007
-
-
-6.  Security Considerations
-
-   RTP packets using the payload format defined in this specification
-   are subject to the security considerations discussed in the RTP
-   specification [RFC3550], 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
-   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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Herlein, et al.         Expires October 24, 2007               [Page 14]
-
-Internet-Draft                    Speex                       April 2007
-
-
-7.  Acknowledgements
-
-   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.
-
-   Thanks to former authors of this document; Simon Morlat, Roger
-   Hardiman, Phil Kerr
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Herlein, et al.         Expires October 24, 2007               [Page 15]
-
-Internet-Draft                    Speex                       April 2007
-
-
-8.  References
-
-8.1.  Normative References
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC3550]  Schulzrinne, H., Casner, S., Frederick, R., and V.
-              Jacobson, "RTP: A Transport Protocol for Real-Time
-              Applications", STD 64, RFC 3550, July 2003.
-
-   [RFC4566]  Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
-              Description Protocol", RFC 4566, July 2006.
-
-8.2.  Informative References
-
-   [CELP]     "CELP, U.S. Federal Standard 1016.", National Technical
-              Information Service (NTIS) website http://www.ntis.gov/.
-
-   [RFC4288]  Freed, N. and J. Klensin, "Media Type Specifications and
-              Registration Procedures", BCP 13, RFC 4288, December 2005.
-
-   [speexenc]
-              Valin, J., "Speexenc/speexdec, reference command-line
-              encoder/decoder", Speex website http://www.speex.org/.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Herlein, et al.         Expires October 24, 2007               [Page 16]
-
-Internet-Draft                    Speex                       April 2007
-
-
-Authors' Addresses
-
-   Greg Herlein
-   2034 Filbert Street
-   San Francisco, California  94123
-   United States
-
-   Email: gherlein@herlein.com
-
-
-   Jean-Marc Valin
-   University of Sherbrooke
-   Department of Electrical and Computer Engineering
-   University of Sherbrooke
-   2500 blvd Universite
-   Sherbrooke, Quebec  J1K 2R1
-   Canada
-
-   Email: jean-marc.valin@usherbrooke.ca
-
-
-   Alfred E. Heggestad
-   Biskop J. Nilssonsgt. 20a
-   Oslo  0659
-   Norway
-
-   Email: aeh@db.org
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Herlein, et al.         Expires October 24, 2007               [Page 17]
-
-Internet-Draft                    Speex                       April 2007
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2007).
-
-   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.
-
-   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.
-
-
-Intellectual Property
-
-   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.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is provided by the IETF
-   Administrative Support Activity (IASA).
-
-
-
-
-
-Herlein, et al.         Expires October 24, 2007               [Page 18]
-
diff --git a/doc/draft-ietf-avt-rtp-speex-05-tmp.txt b/doc/draft-ietf-avt-rtp-speex-05-tmp.txt
deleted file mode 100644
index 70c8007..0000000
--- a/doc/draft-ietf-avt-rtp-speex-05-tmp.txt
+++ /dev/null
@@ -1,1288 +0,0 @@
-
-
-
-AVT                                                           G. Herlein
-Internet-Draft
-Intended status: Standards Track                                J. Valin
-Expires: August 19, 2008                                           CSIRO
-                                                            A. Heggestad
-                                                             Creytiv.com
-                                                              A. Moizard
-                                                                 Antisip
-                                                       February 16, 2008
-
-
-                 RTP Payload Format for the Speex Codec
-                      draft-ietf-avt-rtp-speex-05
-
-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 August 19, 2008.
-
-Copyright Notice
-
-   Copyright (C) The IETF Trust (2008).
-
-
-
-
-
-
-
-
-
-Herlein, et al.          Expires August 19, 2008                [Page 1]
-
-Internet-Draft                    Speex                    February 2008
-
-
-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 August 19, 2008                [Page 2]
-
-Internet-Draft                    Speex                    February 2008
-
-
-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.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
-   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5
-   3.  RTP usage for Speex  . . . . . . . . . . . . . . . . . . . . .  6
-     3.1.  RTP Speex Header Fields  . . . . . . . . . . . . . . . . .  6
-     3.2.  RTP payload format for Speex . . . . . . . . . . . . . . .  6
-     3.3.  Speex payload  . . . . . . . . . . . . . . . . . . . . . .  6
-     3.4.  Example Speex packet . . . . . . . . . . . . . . . . . . .  7
-     3.5.  Multiple Speex frames in a RTP packet  . . . . . . . . . .  7
-   4.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
-     4.1.  Media Type Registration  . . . . . . . . . . . . . . . . .  9
-       4.1.1.  Registration of media type audio/speex . . . . . . . .  9
-   5.  SDP usage of Speex . . . . . . . . . . . . . . . . . . . . . . 12
-     5.1.  Example supporting all modes, prefer mode 4  . . . . . . . 15
-     5.2.  Example supporting only mode 3 and 5 . . . . . . . . . . . 15
-     5.3.  Example with Variable Bit Rate and Comfort Noise . . . . . 15
-     5.4.  Example with Voice Activity Detection  . . . . . . . . . . 15
-     5.5.  Example with Multiple sampling rates . . . . . . . . . . . 15
-     5.6.  Example with ptime and Multiple Speex frames . . . . . . . 16
-     5.7.  Example with Complete Offer/Answer exchange  . . . . . . . 16
-   6.  Implementation Guidelines  . . . . . . . . . . . . . . . . . . 17
-   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 18
-   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
-   9.  Copying conditions . . . . . . . . . . . . . . . . . . . . . . 20
-   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
-     10.1. Normative References . . . . . . . . . . . . . . . . . . . 21
-     10.2. Informative References . . . . . . . . . . . . . . . . . . 21
-   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
-   Intellectual Property and Copyright Statements . . . . . . . . . . 23
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Herlein, et al.          Expires August 19, 2008                [Page 3]
-
-Internet-Draft                    Speex                    February 2008
-
-
-1.  Introduction
-
-   Speex is based on the CELP [CELP] encoding technique with support for
-   either narrowband (nominal 8kHz), wideband (nominal 16kHz) or ultra-
-   wideband (nominal 32kHz).  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
-
-   The Speex codec supports a wide range of bit-rates from 2.15 kbit/s
-   to 44 kbit/s.  In some cases however, it may not be possible for an
-   implementation to include support for all rates (e.g. because of
-   bandwidth, RAM or CPU constraints).  In those cases, to be compliant
-   with this specification, implementations MUST support at least
-   narrowband (8 kHz) encoding and decoding at 8 kbit/s bit-rate
-   (narrowband mode 3).  Support for narrowband at 15 kbit/s (narrowband
-   mode 5) is RECOMMENDED and support for wideband at 27.8 kbit/s
-   (wideband mode 8) is also RECOMMENDED.  The sampling rate MUST be 8,
-   16 or 32 kHz.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Herlein, et al.          Expires August 19, 2008                [Page 4]
-
-Internet-Draft                    Speex                    February 2008
-
-
-2.  Terminology
-
-   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 RFC2119 [RFC2119] and
-   indicate requirement levels for compliant RTP implementations.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Herlein, et al.          Expires August 19, 2008                [Page 5]
-
-Internet-Draft                    Speex                    February 2008
-
-
-3.  RTP usage for Speex
-
-3.1.  RTP Speex Header Fields
-
-   The RTP header is defined in the RTP specification [RFC3550].  This
-   section defines how fields in the RTP header are used.
-
-      Payload Type (PT): The assignment of an RTP payload type for this
-      packet format is outside the scope of this document; it is
-      specified by the RTP profile under which this payload format is
-      used, or signaled dynamically out-of-band (e.g., using SDP).
-
-      Marker (M) bit: The M bit is set to one on the first packet sent
-      after a silence period, during which packets have not been
-      transmitted contiguously.
-
-      Extension (X) bit: Defined by the RTP profile used.
-
-      Timestamp: A 32-bit word that corresponds to the sampling instant
-      for the first frame in the RTP packet.
-
-3.2.  RTP payload format for Speex
-
-   The RTP payload for Speex has the format shown in Figure 1.  No
-   additional header fields specific to this payload format are
-   required.  For RTP based transportation of Speex encoded audio the
-   standard RTP header [RFC3550] 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    |
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-                     Figure 1: RTP payload for Speex
-
-3.3.  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 [speex_manual], and present the same sequence to the decoder.
-   The payload format described here maintains this sequence.
-
-
-
-
-Herlein, et al.          Expires August 19, 2008                [Page 6]
-
-Internet-Draft                    Speex                    February 2008
-
-
-   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 sampling rate
-   (narrowband, wideband or ultra-wideband) and "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.
-
-   The sampling rate MUST be either 8000 Hz, 16000 Hz, or 32000 Hz.
-
-   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.
-
-3.4.  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
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      |                      RTP Header                               |
-      +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
-      |                        ..speex data..                         |
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      |                        ..speex data..               |0 1 1 1 1|
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-3.5.  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.
-
-   The Speex decoder [speex_manual] can detect the bitrate from the
-
-
-
-Herlein, et al.          Expires August 19, 2008                [Page 7]
-
-Internet-Draft                    Speex                    February 2008
-
-
-   payload and is 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
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      |                      RTP Header                               |
-      +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
-      |                     ..speex frame 1..                         |
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      |       ..speex frame 1..       |      ..speex frame 2..        |
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      |                      ..speex frame 2..                        |
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Herlein, et al.          Expires August 19, 2008                [Page 8]
-
-Internet-Draft                    Speex                    February 2008
-
-
-4.  IANA Considerations
-
-   This document defines the Speex media type.
-
-4.1.  Media Type Registration
-
-   This section describes the media types and names associated with this
-   payload format.  The section registers the media types, as per
-   RFC4288 [RFC4288]
-
-4.1.1.  Registration of media type audio/speex
-
-   Media type name: audio
-
-   Media subtype name: speex
-
-   Required parameters:
-
-      rate: RTP timestamp clock rate, which is equal to the sampling
-      rate in Hz.  The sampling rate MUST be either 8000, 16000, or
-      32000.
-
-   Optional parameters:
-
-      ptime: SHOULD be a multiple of 20 msec [RFC4566]
-
-      maxptime: SHOULD be a multiple of 20 msec [RFC4566]
-
-      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: List supported Speex decoding modes.  The valid modes are
-      different for narrowband and wideband, and are defined as follows:
-
-      *  {1,2,3,4,5,6,7,8,any} for narrowband
-
-      *  {0,1,2,3,4,5,6,7,8,9,10,any} for wideband and ultra-wideband
-
-      Several 'mode' parameters can be provided.  In this case, the
-
-
-
-Herlein, et al.          Expires August 19, 2008                [Page 9]
-
-Internet-Draft                    Speex                    February 2008
-
-
-      remote party SHOULD configure its encoder using the first
-      supported mode provided.  When 'any' is used, the offerer
-      indicates that it supports all decoding modes.  If the 'mode'
-      parameter is not provided, the mode value is considered to be
-      equivalent to 'mode=3;mode=any' in narrowband and
-      'mode=8;mode=any' in wideband and ultra-wideband.  Note that each
-      Speex frame does contains the mode (or bit-rate) that should be
-      used to decode it.  Thus application MUST be able to decode any
-      Speex frame unless the SDP clearly specify that some modes are not
-      supported. (e.g., by not including 'mode=any')
-
-   Encoding considerations:
-
-      This media type is framed and binary, see section 4.8 in
-      [RFC4288].
-
-   Security considerations: See Section 6
-
-   Interoperability considerations:
-
-      None.
-
-   Published specification:
-
-      RFC XXXX [RFC Editor: please replace by the RFC number of this
-      memo, when published]
-
-   Applications which use this media type:
-
-      Audio streaming and conferencing applications.
-
-   Additional information: none
-
-   Person and email address to contact for further information :
-
-      Alfred E. Heggestad: aeh@db.org
-
-   Intended usage: COMMON
-
-   Restrictions on usage:
-
-      This media type depends on RTP framing, and hence is only defined
-      for transfer via RTP [RFC3550].  Transport within other framing
-      protocols is not defined at this time.
-
-   Author: Alfred E. Heggestad
-
-   Change controller:
-
-
-
-Herlein, et al.          Expires August 19, 2008               [Page 10]
-
-Internet-Draft                    Speex                    February 2008
-
-
-      IETF Audio/Video Transport working group delegated from the IESG.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Herlein, et al.          Expires August 19, 2008               [Page 11]
-
-Internet-Draft                    Speex                    February 2008
-
-
-5.  SDP usage of Speex
-
-   The information carried in the media type specification has a
-   specific mapping to fields in the Session Description Protocol (SDP)
-   [RFC4566], which is commonly used to describe RTP sessions.  When SDP
-   is used to specify sessions employing the Speex codec, the mapping is
-   as follows:
-
-   o  The media type ("audio") goes in SDP "m=" as the media name.
-
-   o  The media subtype ("speex") goes in SDP "a=rtpmap" as the encoding
-      name.  The required parameter "rate" also goes in "a=rtpmap" as
-      the clock rate.
-
-   o  The parameters "ptime" and "maxptime" go in the SDP "a=ptime" and
-      "a=maxptime" attributes, respectively.
-
-   o  Any remaining parameters go in the SDP "a=fmtp" attribute by
-      copying them directly from the media type string as a semicolon
-      separated list of parameter=value pairs.
-
-   The tables below include the equivalence between modes and bitrates
-   for narrowband, wideband and ultra-wideband.  Also, the corresponding
-   "Speex quality" setting (see SPEEX_SET_QUALITY in The Speex Codec
-   Manual [speex_manual]) is included as an indication.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Herlein, et al.          Expires August 19, 2008               [Page 12]
-
-Internet-Draft                    Speex                    February 2008
-
-
-                  +------+---------------+-------------+
-                  | mode | Speex quality |   bitrate   |
-                  +------+---------------+-------------+
-                  |   1  |       0       | 2.15 kbit/s |
-                  |      |               |             |
-                  |   2  |       2       | 5.95 kbit/s |
-                  |      |               |             |
-                  |   3  |     3 or 4    | 8.00 kbit/s |
-                  |      |               |             |
-                  |   4  |     5 or 6    | 11.0 kbit/s |
-                  |      |               |             |
-                  |   5  |     7 or 8    | 15.0 kbit/s |
-                  |      |               |             |
-                  |   6  |       9       | 18.2 kbit/s |
-                  |      |               |             |
-                  |   7  |       10      | 24.6 kbit/s |
-                  |      |               |             |
-                  |   8  |       1       | 3.95 kbit/s |
-                  +------+---------------+-------------+
-
-                   Mode vs Bitrate table for narrowband
-
-                                  Table 1
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Herlein, et al.          Expires August 19, 2008               [Page 13]
-
-Internet-Draft                    Speex                    February 2008
-
-
-   +------+---------------+------------------+------------------------+
-   | mode | Speex quality | wideband bitrate | ultra wideband bitrate |
-   +------+---------------+------------------+------------------------+
-   |   0  |       0       |    3.95 kbit/s   |       5.75 kbit/s      |
-   |      |               |                  |                        |
-   |   1  |       1       |    5.75 kbit/s   |       7.55 kbit/s      |
-   |      |               |                  |                        |
-   |   2  |       2       |    7.75 kbit/s   |       9.55 kbit/s      |
-   |      |               |                  |                        |
-   |   3  |       3       |    9.80 kbit/s   |       11.6 kbit/s      |
-   |      |               |                  |                        |
-   |   4  |       4       |    12.8 kbit/s   |       14.6 kbit/s      |
-   |      |               |                  |                        |
-   |   5  |       5       |    16.8 kbit/s   |       18.6 kbit/s      |
-   |      |               |                  |                        |
-   |   6  |       6       |    20.6 kbit/s   |       22.4 kbit/s      |
-   |      |               |                  |                        |
-   |   7  |       7       |    23.8 kbit/s   |       25.6 kbit/s      |
-   |      |               |                  |                        |
-   |   8  |       8       |    27.8 kbit/s   |       29.6 kbit/s      |
-   |      |               |                  |                        |
-   |   9  |       9       |    34.2 kbit/s   |       36.0 kbit/s      |
-   |      |               |                  |                        |
-   |  10  |       10      |    42.2 kbit/s   |       44.0 kbit/s      |
-   +------+---------------+------------------+------------------------+
-
-           Mode vs Bitrate table for wideband and ultra-wideband
-
-                                  Table 2
-
-   The Speex parameters indicate the decoding capabilities of the agent,
-   and what the agent prefers to receive.
-
-   The Speex parameters in an SDP Offer/Answer exchange are completely
-   orthogonal, and there is no relationship between the SDP Offer and
-   the Answer.
-
-   Several Speex specific parameters can be given in a single a=fmtp
-   line provided that they are separated by a semi-colon:
-
-             a=fmtp:97 mode=1;mode=any;vbr=on
-
-   Some example SDP session descriptions utilizing Speex encodings
-   follow.
-
-
-
-
-
-
-
-Herlein, et al.          Expires August 19, 2008               [Page 14]
-
-Internet-Draft                    Speex                    February 2008
-
-
-5.1.  Example supporting all modes, prefer mode 4
-
-   The offerer indicates that it wishes to receive a Speex stream at
-   8000Hz, and wishes to receive Speex 'mode 4'.  It is important to
-   understand that any other mode might still be sent by remote party:
-   the device might have bandwidth limitation or might only be able to
-   send 'mode=3'.  Thus, application that support all decoding modes
-   SHOULD include 'mode=any' as shown in the example below:
-
-             m=audio 8088 RTP/AVP 97
-             a=rtpmap:97 speex/8000
-             a=fmtp:97 mode=4;mode=any
-
-5.2.  Example supporting only mode 3 and 5
-
-   The offerer indicates the mode he wishes to receive (Speex 'mode 3').
-   This offer indicates mode 3 and mode 5 are supported and that no
-   other modes are supported.  The remote party MUST NOT configure its
-   encoder using another Speex mode.
-
-             m=audio 8088 RTP/AVP 97
-             a=rtmap:97 speex/8000
-             a=fmtp:97 mode=3;mode=5
-
-5.3.  Example with Variable Bit Rate and Comfort Noise
-
-   The offerer indicates that it wishes to receive 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
-
-5.4.  Example with Voice Activity Detection
-
-   The offerer indicates that it wishes to use silence suppression.  In
-   this case vbr=vad parameter will be used:
-
-             m=audio 8088 RTP/AVP 97
-             a=rtmap:97 speex/8000
-             a=fmtp:97 vbr=vad
-
-5.5.  Example with Multiple sampling rates
-
-   The offerer indicates that it wishes to receive Speex audio at 16000
-   Hz with mode 10 (42.2 kbit/s), alternatively Speex audio at 8000 Hz
-   with mode 7 (24.6 kbit/s).  The offerer supports decoding all modes.
-
-
-
-
-Herlein, et al.          Expires August 19, 2008               [Page 15]
-
-Internet-Draft                    Speex                    February 2008
-
-
-             m=audio 8088 RTP/AVP 97 98
-             a=rtmap:97 speex/16000
-             a=fmtp:97 mode=10;mode=any
-             a=rtmap:98 speex/8000
-             a=fmtp:98 mode=7;mode=any
-
-5.6.  Example with ptime and Multiple Speex frames
-
-   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 rounded up to the first multiple of
-   20 above the ptime value.
-
-   In the example below the ptime value is set to 40, indicating that
-   there are 2 frames in each packet.
-
-             m=audio 8088 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.
-
-   Care must be taken when setting the value of ptime so that the RTP
-   packet size does not exceed the path MTU.
-
-5.7.  Example with Complete Offer/Answer exchange
-
-   The offerer indicates that it wishes to receive Speex audio at 16000
-   Hz, alternatively Speex audio at 8000 Hz.  The offerer does support
-   ALL modes because no mode is specified.
-
-             m=audio 8088 RTP/AVP 97 98
-             a=rtmap:97 speex/16000
-             a=rtmap:98 speex/8000
-
-   The answerer indicates that it wishes to receive Speex audio at 8000
-   Hz, which is the only sampling rate it supports.  The answerer does
-   support ALL modes because no mode is specified.
-
-             m=audio 8088 RTP/AVP 99
-             a=rtmap:99 speex/8000
-
-
-
-
-
-
-
-Herlein, et al.          Expires August 19, 2008               [Page 16]
-
-Internet-Draft                    Speex                    February 2008
-
-
-6.  Implementation Guidelines
-
-   Implementations that supports Speex are responsible for correctly
-   decoding incoming Speex frames.
-
-   Each Speex frame does contains all needed informations to decode
-   itself.  In particular, the 'mode' and 'ptime' values proposed in the
-   SDP contents MUST NOT be used for decoding: those values are not
-   needed to properly decode a RTP Speex stream.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Herlein, et al.          Expires August 19, 2008               [Page 17]
-
-Internet-Draft                    Speex                    February 2008
-
-
-7.  Security Considerations
-
-   RTP packets using the payload format defined in this specification
-   are subject to the security considerations discussed in the RTP
-   specification [RFC3550], 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
-   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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Herlein, et al.          Expires August 19, 2008               [Page 18]
-
-Internet-Draft                    Speex                    February 2008
-
-
-8.  Acknowledgements
-
-   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, Colin
-   Perkins, Ivo Emanuel Goncalves.
-
-   Thanks to former authors of this document; Simon Morlat, Roger
-   Hardiman, Phil Kerr.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Herlein, et al.          Expires August 19, 2008               [Page 19]
-
-Internet-Draft                    Speex                    February 2008
-
-
-9.  Copying conditions
-
-   The authors agree to grant third parties the irrevocable right to
-   copy, use and distribute the work, with or without modification, in
-   any medium, without royalty, provided that, unless separate
-   permission is granted, redistributed modified works do not contain
-   misleading author, version, name of work, or endorsement information.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Herlein, et al.          Expires August 19, 2008               [Page 20]
-
-Internet-Draft                    Speex                    February 2008
-
-
-10.  References
-
-10.1.  Normative References
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC3550]  Schulzrinne, H., Casner, S., Frederick, R., and V.
-              Jacobson, "RTP: A Transport Protocol for Real-Time
-              Applications", STD 64, RFC 3550, July 2003.
-
-   [RFC4566]  Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
-              Description Protocol", RFC 4566, July 2006.
-
-10.2.  Informative References
-
-   [CELP]     "CELP, U.S. Federal Standard 1016.", National Technical
-              Information Service (NTIS) website http://www.ntis.gov/.
-
-   [RFC4288]  Freed, N. and J. Klensin, "Media Type Specifications and
-              Registration Procedures", BCP 13, RFC 4288, December 2005.
-
-   [speex_manual]
-              Valin, J., "The Speex Codec Manual", Speex
-              website http://www.speex.org/docs/.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Herlein, et al.          Expires August 19, 2008               [Page 21]
-
-Internet-Draft                    Speex                    February 2008
-
-
-Authors' Addresses
-
-   Greg Herlein
-   2034 Filbert Street
-   San Francisco, California  94123
-   United States
-
-   Email: gherlein@herlein.com
-
-
-   Jean-Marc Valin
-   CSIRO
-   PO Box 76
-   Epping, NSW  1710
-   Australia
-
-   Email: jean-marc.valin@usherbrooke.ca
-
-
-   Alfred E. Heggestad
-   Creytiv.com
-   Biskop J. Nilssonsgt. 20a
-   Oslo  0659
-   Norway
-
-   Email: aeh@db.org
-
-
-   Aymeric Moizard
-   Antisip
-   4 Quai Perrache
-   Lyon  69002
-   France
-
-   Email: jack@atosc.org
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Herlein, et al.          Expires August 19, 2008               [Page 22]
-
-Internet-Draft                    Speex                    February 2008
-
-
-Full Copyright Statement
-
-   Copyright (C) The IETF Trust (2008).
-
-   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.
-
-   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, THE IETF TRUST 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.
-
-
-Intellectual Property
-
-   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.
-
-
-Acknowledgment
-
-   Funding for the RFC Editor function is provided by the IETF
-   Administrative Support Activity (IASA).
-
-
-
-
-
-Herlein, et al.          Expires August 19, 2008               [Page 23]
-
diff --git a/doc/rtp.txt b/doc/rtp.txt
deleted file mode 100644
index 1c25153..0000000
--- a/doc/rtp.txt
+++ /dev/null
@@ -1,76 +0,0 @@
-The Speex RTP payload is defined as a header, followed by any number of
-requests to the remote encoder and all encoded speech frames.
-
-+--------+----------+----------------+
-| Header | Requests | Speech data... |
-+--------+----------+----------------+
-
-The header contains only the number of frames sent 
-encoded in 6 bits
-
- 0 1 2 3 4 5 
-+-+-+-+-+-+-+
-| NB frames |
-+-+-+-+-+-+-+
-
-There can be any number of requests of the form
-
- 0 1 2 3 4 5 6 7 0 1
-+-+-+-+-+-+-+-+-+-+-+
-|R| ReqID | ReqVal  |
-+-+-+-+-+-+-+-+-+-+-+
-
-where R is 1 when a request is following and 0 when there is no more
-request. Each request (if R=1) is composed of a 4-bit request ID (ReqID) and
-a 5-bit value (ReqVal)
-
-Possible values for ReqID are:
- 0: REQ_PERSIST   ReqVal=1 for persistent requests/mode selection, 
-                  0 otherwise
- 1: PERSIST_ACK   Acknowledge a REQ_PERSIST from the other end, 
-                  ReqVal equals the value received
- 2: MODE          Choose the encoder mode directly
- 3: QUALITY       Choose the encoder quality
- 4: VBR           Set VBR on (ReqVal=1) or off (ReqVal=2)
- 5: VBR_QUALITY   Set the encoder quality for VBR mode
- 6: LOW_MODE      Set the encoder mode for low-band (wideband only)
- 7: HIGH_MODE     Set the encoder mode for high-band (wideband only)
-
-All requests should be considered at the receiver as a suggestion and
-compliance is not mandatory. The PERSIST_ACK should be sent upon receiving a
-REQ_PERSIST request to indicate that the request has been received.
-
-The speech data part contains speech frames one after the other. The size of
-the encoded frames can be found since the mode is directly encoded into each
-frame.
-
-For example, a frame where we request VBR to be on with quality 8 and we
-transmit two frames encoded at 8.35 kbps (167 bits/frame) will be:
-
- 0               1               2               3
- 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-|   NB=2    |1|ReqID=2| ReqVal=0|1|ReqID=3|ReqVal=8 |0| frame 1 |
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-|                         frame 1                               |
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-|                         frame 1                               |
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-|                         frame 1                               |
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-|                         frame 1                               |
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-|                         frame 1                               |
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-|end|                     frame 2                               |
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-|                         frame 2                               |
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-|                         frame 2                               |
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-|                         frame 2                               |
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-|                         frame 2                               |
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-|    end frame 2    |P|P|P|P|P|P|
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
diff --git a/html/index.html b/html/index.html
deleted file mode 100644
index 789a796..0000000
--- a/html/index.html
+++ /dev/null
@@ -1,215 +0,0 @@
-<!DOCTYPE doctype PUBLIC "-//w3c//dtd html 4.0 transitional//en"><html><head>
-                                                    
-  
-  
-  
-  <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
-
-
-
-                                                    
-  
-  
-  
-  <meta name="GENERATOR" content="Mozilla/4.78 [fr] (X11; U; Linux 2.4.17 i686) [Netscape]">
-
-
-
-                                                    
-  
-  
-  
-  <meta name="Author" content="Jean-Marc Valin">
-  <title>The Speex Speech Codec</title>
-
-  
-
-  
-
-  
-                               </head>
-
-<body text="#000000" bgcolor="#ffffff" link="#0000ef" vlink="#59188e" alink="#ff0000">
-                          
-<center>             
-<img src="speex.png" alt="Speex">
-</center>
-<br>
-<br>
-
-
-             <a href="http://sourceforge.net/projects/speex">The Speex project</a>
-          aims  to build an open-source (LGPL) <A href="patents.html">patent-free</A> voice codec. Unlike 
-  other codecs   like  MP3 and <a href="http://www.vorbis.org/">Ogg Vorbis</a>, 
-Speex is specially designed for compressing voice at low bit-rates in the 
-8-32 kbps/channel range. Possible applications include Voice over IP (VoIP), 
- Internet audio streaming, archiving of speech data (e.g. voice mail), and
-audio books. In some sense, it is meant to  be complementary to the 
-Ogg Vorbis codec.             
-<p>If you are interested in participating to the project, contact us at <a href="mailto:speex-devel@lists.sourceforge.net">
-           speex-devel@lists.sourceforge.net</a>  or <a href="http://lists.sourceforge.net/lists/listinfo/speex-devel">
-           join  our mailing list</a>. Right now, we are mostly looking for 
- developers with signal processing and speech coding knowledge, as well 
- as people with knowledge about patents in that field. See the 
-<A href="http://sourceforge.net/pm/task.php?group_project_id=19556&group_id=46651&func=browse">task list</A> for more details about what's left to do in Speex<br>
-</p>
-
-
-
-                       
-<h2>Download</h2>
-
-
-
-           You can download Speex from <a href="http://sourceforge.net/project/showfiles.php?group_id=46651">
-           here</a>.<br>
-
-
-<h2>Documentation</h2>
-This Speex manual includes information about the
-algorithms used in Speex, the bit-stream, the API and more.
-<br>
-<A href="manual.pdf">Speex manual (PDF)</A> 
-<br>
-<A href="manual.ps">Speex manual (Postscript)</A>
-<br>
-<A href="manual/">Speex manual (HTML online)</A>
-<br>
-<A href="manual.tar.gz">Speex manual (HTML tarball)</A>
-<br><br>
-There is also some API documentation generated by Doxygen directly from the header files
-<br>
-<A href="refman.pdf">Speex API (PDF)</A>
-           
-<h2>Samples</h2>
-
-You can listen to samples encoded with Speex <A href="/audio/samples/">here</A>
-
-<h2>Who uses Speex</h2>
-
-<A href="http://www.linphone.org">LinPhone</a>: A SIP-based VoIP phone written for GNOME
-<br>
-<A href="http://jzb.rapanden.dk/speex/">Speex XMMS plugin</a> written by <a href="mailto:jzb@rapanden.dk">Jens Burkal</a>
-<br>
-<A href="http://www.openh323.org">OpenH323</a>: An open-source H.323 stack
-<br>
-<A href="http://www.gnomemeeting.org">GnomeMeeting</A>: A H323 Video Conferencing Program
-
-<br><br>
-In development:
-<br>
-<A href="http://www.asteriskpbx.org">Asterisk</a>: An open-source PBX
-
-<h2>News</h2>
-
-<h3>2002/09/04</h3>
-
-Speex 0.8.1 released. This release fixes a bug in the new 0.8 API (function
-speex_mode_query). For those using only speexenc/speexdec, no need to upgrade
-but those using libspeex (directly or through another application) should.
-
-<h3>2002/08/24</h3>
-  Speex 0.8.0 released. The speex_decode() function no longer uses the
-'lost' parameter. Applications will need
-  to be updated.
-
-<h3>2002/08/09</h3>
-  Speex 0.7.0 released. The format of the bit stream has changed once again
-and the bandwidth required has been
-  reduced slightly.
-
-<h3>2002/08/01</h3>
-
-Speex 0.6.0 has been released. This is a major release that contains many improvements and lots of bug-fixing. The post-filter that was causing problems throughout 0.5.x was replaced with a new perceptual enhancement system, which sounds better and consume much less CPU. Also many changes to Ogg encoder/decoder, including possibility to see the bit-rate being played/encoded. There is also a discontinuous transmission (DTX) mode. Last but not least, 0.6.0 now reports no error when being run with the valgrind memory debugger. 
-
-<h3>2002/07/26</h3>
-
-Speex 0.5.2 is out and brings a number of improvements and bug fixes. First,
-the search has been improved and it is now possible to choose the right
-quality/encoding time tradeoff (--comp option). Is is also possible to pack
-more that one frame in an Ogg packet (--nframes), reducing the overhead for
-low bit-rates. Last but not least: there is now some documentation about
-Speex!
-
-
-<h3>2002/07/17</h3> 
-
-Version 0.5.1 is released. This release brings quality improvements at very
-low bit-rate (5.7 kbps) and a new post-filter. VBR should also be a bit
-better though there's still a lot to do. Most of the modes are bit-rate
-compatible with 0.5.0, with the exception of the very low bit-rate (which is
-sometimes used in VBR, so expect some glitches). The source (and probably
-binary) compatibility with 0.5.0 is maintained.
-
-<h3>2002/07/08</h3>
-
-Speex 0.5.0 is out. The most important new feature is Varible Bit-Rate
-(VBR). It can be enabled by using the --vbr option to speexenc. When
-encoding in VBR, the --quality option can still be used. Note VBR
-implementation in this release is experimental and still requires lots of
-tuning.
-
-<h3>2002/06/23</h3>
-
-Speex 0.4.0 is here, adding many more bit-rates to both narrowband and wideband, as
-well as the ability to change bit-rate dynamically from frame to frame. The
-narrowband modes now range from 8 kbps to 18 kbps, while wideband range from
-10 kbps to 28 kbps. There is also a "noise coding" mode at 2 kbps for
-narrowband and 3 kbps for wideband. All this will lead to real Variable
-Bit-Rate (VBR) in the future. Also, worth mentioning the codec latency has
-been reduced from 40 ms to 30 ms (20 ms frames + 10 ms lookahead).
-
-<h3>2002/06/12</h3>
-
-Speex 0.3.0 has been released. There is now a new "low bit-rate" narrowband
-mode for coding speech at 8 kbps. There's also support for big-endian
-machines (untested, please report bugs). Speex files now have real header
-containing information like bit-stream version (revents from playing an
-incompatible bit-stream), sampling rate, bit-rate and user comments. On the
-quality side, the post-filter has been improved and there has been more
-codebook optimization. Note that this release breaks bit-stream
-compatibility with previous releases.
-
-<h3>2002/06/07</h3>
-
-Speex 0.2.0 is out. This is a major release with lots of improvements and
-bugfixes. First, the encoder and decoder can work directly from wav files
-(mono only for now) and the decoder can play directly to soundcard. Also,
-most of the codebooks have been re-trained in order to improve quality (but
-this also breaks format compatibility with previous versions), while
-slightly decreasing complexity. Speex is now able to encode both DTMF and
-music (not as good as Vorbis of course) after bugs were fixed in the pitch
-prediction and LSP quantization. Last but not the least, the perceptual
-post-filter has been improved.
-
-<h3>2002/06/04</h3>
-
-Speex 0.1.2 is out. This adds a perceptual post-filter at the decoder to 
-(hopefully) increase quality. It can be enabled with the --pf option to 
-speexdec. The Speex format remains the same for both narrowband 
-and wideband.
-
-<h3>2002/05/15</h3>
-
-Speex 0.1.0 has been released. Speex now uses the Ogg bitstream (using
-libogg). That means that there is now (limited) bitstream error
-recovery. Also, the narrowband bit-rate has been reduced from 15.7 kbps to
-15.1 kbps and the wideband bit-rate has been reduced from 31.3 kbps to 27.7
-kbps.  The quality remains roughly the same for both narrowband and
-wideband.  Once again, this breaks compatibility with previous versions.
-
-<hr width="100%" size="2">          
-<div align="right"><a href="http://uk.eurorights.org/issues/cd/quick/"><img 
-border="0" width="160" height="40" src="badcd002.png" 
-alt="Say NO to corrupt audio discs" /></a>
-<br>
-<img src="http://sourceforge.net/sflogo.php?group_id=46651&amp;amp;type=5" alt="SourceForge Logo">
-<br>
-
-<a href="mailto:jean-marc.valin@hermes.usherb.ca">Jean-Mrc Valin</a>       <br>
-            $Date: 2002/09/16 00:59:10 $</div>
-
-
-
-                          
-</body></html>
diff --git a/html/patents.html b/html/patents.html
deleted file mode 100644
index d81c961..0000000
--- a/html/patents.html
+++ /dev/null
@@ -1,39 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
-<html>
-<head>
-  <title>Speex and patents</title>
-      
-  <meta name="author" content="Jean-Marc Valin">
-</head>
-  <body>
- 
-<div align="center"> 
-<h1>Position regarding patents</h1>
- 
-<div align="left">The goal of Speex is to provide a codec that is open-source
-(released under the <a href="http://www.gnu.org/licenses/lgpl.html">LGPL</a>)
-and that can be used in open-source software. This implies that it also has
-to be free from patent restrictions. Unfortunately, the field of speech coding
-known to be a real patent minefield and to make the matter worse, each country
-has its own patent laws and list of granted patents so tracking them all
-would be next to impossible. This is why we cannot provide an absolute warranty
-that Speex is indeed completely patent-free.<br>
-<br>
- That being said, we are doing our best to keep away from known patents and 
-we do not patent the algorithms we use. That's about all we can do about it.
-If you are aware of a patent issue with Speex, please <a
- href="mailto:speex-devel@lists.sourceforge.net">let us know</a>.<br>
- <br>
-Normally there shouldn't be any problem when you use Speex. However for the
-reasons explained above, if you are thinking about using Speex commercially,
-we strongly suggest that you have a closer look at patent issues with respect
-to your country. Note that this is not specific to Speex, since many "standardized"
-codecs have an unclear patent status (like <a
- href="http://www.mp3-tech.org/patents.html">MP3</a>, <a
- href="http://kbs.cs.tu-berlin.de/%7Ejutta/toast.html">GSM</a> and probably 
-others), not to mention the risks of a previously unknown patent holder claiming
-rights on a standardized codec long after standardization (<a href="http://lpf.ai.mit.edu/Patents/Gif/Gif.html">GIF</a>, <a href="http://www.itworld.com/Man/2687/020719jpegpatent/">JPEG</a>).<br>
-</div>
- </div>
-</body>
-</html>