Manual update

git-svn-id: http://svn.xiph.org/trunk/speex@12970 0101bb08-14d6-0310-b084-bc0e0c8e3800

3 files changed, 1021 insertions, 1 deletions

diff --git a/doc/draft-ietf-avt-rtp-speex-01-tmp.txt b/doc/draft-ietf-avt-rtp-speex-01-tmp.txt
new file mode 100644
index 0000000..1410b85
--- /dev/null
+++ b/doc/draft-ietf-avt-rtp-speex-01-tmp.txt
@@ -0,0 +1,1008 @@
+
+
+
+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/manual.lyx b/doc/manual.lyx
index de3654c..fdd2a82 100644
--- a/doc/manual.lyx
+++ b/doc/manual.lyx
@@ -7401,6 +7401,13 @@ For the wideband mode, the entire narrowband frame is packed before the
 \end_inset
 
 .
+ For wideband, the mode ID is the same as the Speex quality setting and
+ is defined in table 
+\begin_inset LatexCommand \ref{tab:wideband-quality}
+
+\end_inset
+
+.
  This also means that a wideband frame may be correctly decoded by a narrowband
  decoder with the only caveat that if more than one frame is packed in the
  same packet, the decoder will need to skip the high-band parts in order
@@ -8329,6 +8336,11 @@ end{center}
 
 \begin_layout Caption
 Quality versus bit-rate for the wideband encoder
+\begin_inset LatexCommand \label{tab:wideband-quality}
+
+\end_inset
+
+
 \end_layout
 
 \end_inset
@@ -8787,7 +8799,7 @@ IETF RTP Profile
 \end_layout
 
 \begin_layout Standard
-\begin_inset Include \verbatiminput{draft-herlein-speex-rtp-profile-02.txt}
+\begin_inset Include \verbatiminput{draft-ietf-avt-rtp-speex-01-tmp.txt}
 preview false
 
 \end_inset
diff --git a/doc/manual.pdf b/doc/manual.pdf
index ec77341..361a41a 100644
--- a/doc/manual.pdf
+++ b/doc/manual.pdf