manual update (including latest IETF draft) for 1.0.2Speex-1.0.2

git-svn-id: http://svn.xiph.org/branches/rel-1-0-branch/speex@5368 0101bb08-14d6-0310-b084-bc0e0c8e3800

3 files changed, 769 insertions, 4 deletions

diff --git a/doc/draft-herlein-speex-rtp-profile-01.txt b/doc/draft-herlein-speex-rtp-profile-01.txt
new file mode 100644
index 0000000..ae83a4c
--- /dev/null
+++ b/doc/draft-herlein-speex-rtp-profile-01.txt
@@ -0,0 +1,701 @@
+
+
+
+
+Internet Engineering Task Force                          Greg Herlein
+Internet Draft                                        Jean-Marc Valin
+draft-herlein-speex-rtp-profile-01                       Simon Morlat
+June 30, 2003                                          Roger Hardiman
+Expires: January 30, 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, patent-free, 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 January 30, 2004            [Page 1]
+^L
+Internet-Draft       draft-herlein-speex-rtp-profile-01    June 30, 2003
+
+
+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, royalty-free
+   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 January 30, 2004            [Page 2]
+^L
+Internet-Draft       draft-herlein-speex-rtp-profile-01    June 30, 2003
+
+
+   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 January 30, 2004            [Page 3]
+^L
+Internet-Draft       draft-herlein-speex-rtp-profile-01    June 30, 2003
+
+
+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 set in 
+   the pattern of a zero, LSB aligned network byte order, 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 January 30, 2004            [Page 4]
+^L
+Internet-Draft       draft-herlein-speex-rtp-profile-01    June 30, 2003
+
+
+    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 January 30, 2004            [Page 5]
+^L
+Internet-Draft       draft-herlein-speex-rtp-profile-01    June 30, 2003
+
+
+   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 January 30, 2004            [Page 6]
+^L
+Internet-Draft       draft-herlein-speex-rtp-profile-01    June 30, 2003
+
+
+   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 January 30, 2004            [Page 7]
+^L
+Internet-Draft       draft-herlein-speex-rtp-profile-01    June 30, 2003
+
+
+   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 January 30, 2004            [Page 8]
+^L
+Internet-Draft       draft-herlein-speex-rtp-profile-01    June 30, 2003
+
+
+   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 January 30, 2004            [Page 9]
+^L
+Internet-Draft       draft-herlein-speex-rtp-profile-01    June 30, 2003
+
+
+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 January 30, 2004             [Page 10]
+^L
+Internet-Draft       draft-herlein-speex-rtp-profile-01    June 30, 2003
+
+
+   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 January 30, 2004             [Page 11]
+^L
+Internet-Draft       draft-herlein-speex-rtp-profile-01    June 30, 2003
+
+
+   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 January 30, 2004             [Page 12]
+^L
+
+
+-------------------------------------------------
+This mail sent through IMP: http://horde.org/imp/
diff --git a/doc/manual.lyx b/doc/manual.lyx
index 2a552fe..39683bb 100644
--- a/doc/manual.lyx
+++ b/doc/manual.lyx
@@ -28,7 +28,7 @@
 
 The Speex Codec Manual
 \newline 
-(version 1.0)
+(version 1.0.2)
 \layout Author
 
 Jean-Marc Valin
@@ -1143,7 +1143,10 @@ Sometimes it is desirable to pack more than one frame per packet (or other
 \end_inset 
 
 .
- 
+ Note that as of version 1.0.2, calling speex_bits_write automatically inserts
+ the terminator so as to fill the last byte.
+ This doesn't involves any overhead and makes sure Speex can always detect
+ when there is no more frame in a packet.
 \layout Standard
 
 It is also possible to send in-band 
@@ -5460,10 +5463,31 @@ First of all, it's not clear whether GSM-FR is covered by a Philips patent
 Under what license is Speex released?
 \layout Standard
 
-As of version 1.0 beta 1, Speex is released under Xiph's BSD-like license.
+As of version 1.0 beta 1, Speex is released under Xiph's version of the (revised)
+ BSD license (see Appendix 
+\begin_inset LatexCommand \ref{sec:Speex-License}
+
+\end_inset 
+
+).
  This license is the most permissive of the open-source licenses.
 \layout Subsection*
 
+Am I allowed to use Speex in commercial software?
+\layout Standard
+
+Yes.
+ As long as you comply with the license.
+ This basically means you have to keep the copyright notice and you can't
+ use our name to promote your product without authorization.
+ For more details, see license in Appendix 
+\begin_inset LatexCommand \ref{sec:Speex-License}
+
+\end_inset 
+
+.
+\layout Subsection*
+
 Ogg
 \begin_inset LatexCommand \index{Ogg}
 
@@ -5757,7 +5781,7 @@ IETF RTP Profile
 \layout Standard
 
 
-\begin_inset Include \verbatiminput{draft-herlein-speex-rtp-profile-00.txt}
+\begin_inset Include \verbatiminput{draft-herlein-speex-rtp-profile-01.txt}
 preview false
 
 \end_inset 
@@ -5765,6 +5789,46 @@ preview false
 
 \layout Section
 \pagebreak_top 
+Speex License
+\begin_inset LatexCommand \label{sec:Speex-License}
+
+\end_inset 
+
+
+\layout Standard
+
+Redistribution and use in source and binary forms, with or without modification,
+ are permitted provided that the following conditions are met:
+\layout Itemize
+
+Redistributions of source code must retain the above copyright notice, this
+ list of conditions and the following disclaimer.
+\layout Itemize
+
+Redistributions in binary form must reproduce the above copyright notice,
+ this list of conditions and the following disclaimer in the documentation
+ and/or other materials provided with the distribution.
+\layout Itemize
+
+Neither the name of the Xiph.org Foundation nor the names of its contributors
+ may be used to endorse or promote products derived from this software without
+ specific prior written permission.
+\layout Standard
+
+THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS ``AS
+ IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
+ TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
+ PURPOSE ARE DISCLAIMED.
+ IN NO EVENT SHALL THE FOUNDATION OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT,
+ INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,
+ BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
+ USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
+ ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
+ THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ 
+\layout Section
+\pagebreak_top 
 GNU Free Documentation License
 \layout Standard
 
diff --git a/doc/manual.pdf b/doc/manual.pdf
index 8a076c4..0a8e16d 100644
--- a/doc/manual.pdf
+++ b/doc/manual.pdf