[xiph-commits] r10157 - trunk/speex/doc

giles at svn.xiph.org giles at svn.xiph.org
Fri Oct 14 10:29:01 PDT 2005


Author: giles
Date: 2005-10-14 10:29:00 -0700 (Fri, 14 Oct 2005)
New Revision: 10157

Added:
   trunk/speex/doc/draft-ietf-avt-rtp-speex-00.txt
Log:
Add a copy of the latest rtp draft.


Added: trunk/speex/doc/draft-ietf-avt-rtp-speex-00.txt
===================================================================
--- trunk/speex/doc/draft-ietf-avt-rtp-speex-00.txt	2005-10-14 12:22:47 UTC (rev 10156)
+++ trunk/speex/doc/draft-ietf-avt-rtp-speex-00.txt	2005-10-14 17:29:00 UTC (rev 10157)
@@ -0,0 +1,784 @@
+
+
+
+AVT Working Group                                             G. Herlein
+Internet-Draft                                                 S. Morlat
+Expires: April 15, 2006                                     J. Jean-Marc
+                                                             R. Hardiman
+                                                                 P. Kerr
+                                                        October 12, 2005
+
+
+                      draft-ietf-avt-rtp-speex-00
+                 RTP Payload Format for the Speex Codec
+
+Status of this Memo
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF), its areas, and its working groups.  Note that
+   other groups may also distribute working documents as Internet-
+   Drafts.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/ietf/1id-abstracts.txt.
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+   This Internet-Draft will expire on April 15, 2006.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).
+
+Abstract
+
+   Speex is an open-source voice codec suitable for use in Voice over IP
+   (VoIP) type applications.  This document describes the payload format
+   for Speex generated bit streams within an RTP packet.  Also included
+   here are the necessary details for the use of Speex with the Session
+   Description Protocol (SDP).
+
+
+
+
+Herlein, et al.          Expires April 15, 2006                 [Page 1]
+
+Internet-Draft         draft-ietf-avt-rtp-speex-00          October 2005
+
+
+Editors Note
+
+   All references to RFC XXXX are to be replaced by references to the
+   RFC number of this memo, when published.
+
+Table of Contents
+
+   1.   Conventions used in this document  . . . . . . . . . . . . .   3
+   2.   Overview of the Speex Codec  . . . . . . . . . . . . . . . .   3
+   3.   RTP payload format for Speex . . . . . . . . . . . . . . . .   3
+   4.   RTP Header . . . . . . . . . . . . . . . . . . . . . . . . .   3
+   5.   Speex payload  . . . . . . . . . . . . . . . . . . . . . . .   5
+   6.   Example Speex packet . . . . . . . . . . . . . . . . . . . .   6
+   7.   Multiple Speex frames in a RTP packet  . . . . . . . . . . .   6
+   8.   MIME registration of Speex . . . . . . . . . . . . . . . . .   7
+   9.   SDP usage of Speex . . . . . . . . . . . . . . . . . . . . .   8
+   10.  ITU H.323 Use of Speex . . . . . . . . . . . . . . . . . . .  10
+   11.  Security Considerations  . . . . . . . . . . . . . . . . . .  10
+   12.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . .  11
+   13.  References . . . . . . . . . . . . . . . . . . . . . . . . .  11
+     13.1   Normative References . . . . . . . . . . . . . . . . . .  11
+     13.2   Informative References . . . . . . . . . . . . . . . . .  12
+        Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  12
+        Intellectual Property and Copyright Statements . . . . . . .  14
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Herlein, et al.          Expires April 15, 2006                 [Page 2]
+
+Internet-Draft         draft-ietf-avt-rtp-speex-00          October 2005
+
+
+1.  Conventions used in this document
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [1].
+
+2.  Overview of the Speex Codec
+
+   Speex is based on the CELP [8] encoding technique with support for
+   either narrowband (nominal 8kHz), wideband (nominal 16kHz) or ultra-
+   wideband (nominal 32kHz), and (non-optimal) rates up to 48 kHz
+   sampling also available.  The main characteristics can be summarized
+   as follows:
+
+   o  Free software/open-source
+   o  Integration of wideband and narrowband in the same bit-stream
+   o  Wide range of bit-rates available
+   o  Dynamic bit-rate switching and variable bit-rate (VBR)
+   o  Voice Activity Detection (VAD, integrated with VBR)
+   o  Variable complexity
+
+3.  RTP payload format for Speex
+
+   For RTP based transportation of Speex encoded audio the standard RTP
+   header [2] is followed by one or more payload data blocks.  An
+   optional padding terminator may also be used.
+
+        0                   1                   2                   3
+        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       |                         RTP Header                            |
+       +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
+       |                 one or more frames of Speex ....              |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       |        one or more frames of Speex ....       |    padding    |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+4.  RTP Header
+
+
+
+
+
+
+
+
+
+
+
+
+Herlein, et al.          Expires April 15, 2006                 [Page 3]
+
+Internet-Draft         draft-ietf-avt-rtp-speex-00          October 2005
+
+
+        0                   1                   2                   3
+        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       |V=2|P|X|  CC   |M|     PT      |       sequence number         |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       |                           timestamp                           |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       |           synchronization source (SSRC) identifier            |
+       +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
+       |            contributing source (CSRC) identifiers             |
+       |                              ...                              |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   The RTP header begins with an octet of fields (V, P, X, and CC) to
+   support specialized RTP uses (see [2] and [5] for details).  For
+   Speex the following values are used.
+
+   Version (V): 2 bits
+
+   This field identifies the version of RTP.  The version used by this
+   specification is two [2].
+
+   Padding (P): 1 bit
+
+   If the padding bit is set, the packet contains one or more additional
+   padding octets at the end which are not part of the payload.
+
+   Extension (X): 1 bit
+
+   If the extension, X, bit is set, the fixed header MUST be followed by
+   exactly one header extension, with a format defined in Section 5.3.1.
+   of [2].
+
+   CSRC count (CC): 4 bits
+
+   The CSRC count contains the number of CSRC identifiers.
+
+   Marker (M): 1 bit
+
+   The M bit indicates if the packet contains comfort noise.  This field
+   is used in conjunction with the cng SDP attribute and conforms to
+   Section 4.1. of [5].
+
+   Payload Type (PT): 7 bits
+
+   An RTP profile for a class of applications is expected to assign a
+   payload type for this format, or a dynamically allocated payload type
+   SHOULD be chosen which designates the payload as Speex.
+
+
+
+Herlein, et al.          Expires April 15, 2006                 [Page 4]
+
+Internet-Draft         draft-ietf-avt-rtp-speex-00          October 2005
+
+
+   Sequence number: 16 bits
+
+   The sequence number increments by one for each RTP data packet sent,
+   and may be used by the receiver to detect packet loss and to restore
+   packet sequence.  This field is detailed further in [2].
+
+   Timestamp: 32 bits
+
+   A timestamp representing the sampling time of the first sample of the
+   first Speex packet in the RTP packet.  The clock frequency MUST be
+   set to the sample rate of the encoded audio data.  Speex uses 20 msec
+   frames and a variable sampling rate clock.  The RTP timestamp MUST be
+   in units of 1/X of a second where X is the sample rate used.  Speex
+   uses a nominal 8kHz sampling rate for narrowband use, a nominal 16kHz
+   sampling rate for wideband use, and a nominal 32kHz sampling rate for
+   ultra-wideband use.
+
+   SSRC/CSRC identifiers:
+
+   These two fields, 32 bits each with one SSRC field and a maximum of
+   16 CSRC fields, are as defined in [2].
+
+5.  Speex payload
+
+   For the purposes of packetizing the bit stream in RTP, it is only
+   necessary to consider the sequence of bits as output by the Speex
+   encoder [7], and present the same sequence to the decoder.  The
+   payload format described here maintains this sequence.
+
+   A typical Speex frame, encoded at the maximum bitrate, is approx. 110
+   octets and the total number of Speex frames SHOULD be kept less than
+   the path MTU to prevent fragmentation.  Speex frames MUST NOT be
+   fragmented across multiple RTP packets,
+
+   An RTP packet MAY contain Speex frames of the same bit rate or of
+   varying bit rates, since the bit-rate for a frame is conveyed in band
+   with the signal.
+
+   The encoding and decoding algorithm can change the bit rate at any 20
+   msec frame boundary, with the bit rate change notification provided
+   in-band with the bit stream.  Each frame contains both "mode"
+   (narrowband, wideband or ultra-wideband) and "sub-mode" (bit-rate)
+   information in the bit stream.  No out-of-band notification is
+   required for the decoder to process changes in the bit rate sent by
+   the encoder.
+
+   It is RECOMMENDED that values of 8000, 16000 and 32000 be used for
+   normal internet telephony applications, though the sample rate is
+
+
+
+Herlein, et al.          Expires April 15, 2006                 [Page 5]
+
+Internet-Draft         draft-ietf-avt-rtp-speex-00          October 2005
+
+
+   supported at rates as low as 6000 Hz and as high as 48 kHz.
+
+   The RTP payload MUST be padded to provide an integer number of octets
+   as the payload length.  These padding bits are LSB aligned in network
+   octet order and consist of a 0 followed by all ones (until the end of
+   the octet).  This padding is only required for the last frame in the
+   packet, and only to ensure the packet contents ends on an octet
+   boundary.
+
+6.  Example Speex packet
+
+   In the example below we have a single Speex frame with 5 bits of
+   padding to ensure the packet size falls on an octet boundary.
+
+       0                   1                   2                   3
+       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |V=2|P|X|  CC   |M|     PT      |       sequence number         |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                           timestamp                           |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |         synchronization source (SSRC) identifier              |
+      +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
+
+       0                   1                   2                   3
+       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+      +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
+      |         contributing source (CSRC) identifiers                |
+      |                              ...                              |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                        ..speex data..                         |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                        ..speex data..               |0 1 1 1 1|
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+7.  Multiple Speex frames in a RTP packet
+
+   Below is an example of two Speex frames contained within one RTP
+   packet.  The Speex frame length in this example fall on an octet
+   boundary so there is no padding.
+
+   Speex codecs [7] are able to detect the bitrate from the payload and
+   are responsible for detecting the 20 msec boundaries between each
+   frame.
+
+
+
+
+
+Herlein, et al.          Expires April 15, 2006                 [Page 6]
+
+Internet-Draft         draft-ietf-avt-rtp-speex-00          October 2005
+
+
+       0                   1                   2                   3
+       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |V=2|P|X|  CC   |M|     PT      |       sequence number         |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                           timestamp                           |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |         synchronization source (SSRC) identifier              |
+      +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
+      |         contributing source (CSRC) identifiers                |
+      |                              ...                              |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                        ..speex data..                         |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |        ..speex data..         |        ..speex data..         |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                        ..speex data..                         |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+8.  MIME registration of Speex
+
+   Full definition of the MIME [3] type for Speex will be part of the
+   Ogg Vorbis MIME type definition application [6].
+
+   MIME media type name: audio
+
+   MIME subtype: speex
+
+   Optional parameters:
+
+   Required parameters: to be included in the Ogg MIME specification.
+
+   Encoding considerations:
+
+   This type is only defined for transfer via HTTP as specified in RFC
+   XXXX.
+
+   Security Considerations:
+
+   See Section 6 of RFC 3047.
+
+   Interoperability considerations: none
+
+   Published specification:
+
+   Applications which use this media type:
+
+
+
+Herlein, et al.          Expires April 15, 2006                 [Page 7]
+
+Internet-Draft         draft-ietf-avt-rtp-speex-00          October 2005
+
+
+   Additional information: none
+
+   Person & email address to contact for further information:
+
+      Greg Herlein <gherlein at herlein.com>
+      Jean-Marc Valin <jean-marc.valin at usherbrooke.ca>
+
+   Intended usage: COMMON
+
+   Author/Change controller:
+
+      Author:  Greg Herlein <gherlein at herlein.com>
+      Change controller: Greg Herlein <gherlein at herlein.com>
+      Change controller: IETF AVT Working Group
+
+   This transport type signifies that the content is to be interpreted
+   according to this document if the contents are transmitted over RTP.
+   Should this transport type appear over a lossless streaming protocol
+   such as TCP, the content encapsulation should be interpreted as an
+   Ogg Stream in accordance with [6], with the exception that the
+   content of the Ogg Stream may be assumed to be Speex audio and Speex
+   audio only.
+
+9.  SDP usage of Speex
+
+   When conveying information by SDP [4], the encoding name MUST be set
+   to "speex".  An example of the media representation in SDP for
+   offering a single channel of Speex at 8000 samples per second might
+   be:
+
+      m=audio 8088 RTP/AVP 97
+      a=rtpmap:97 speex/8000
+
+   Note that the RTP payload type code of 97 is defined in this media
+   definition to be 'mapped' to the speex codec at an 8kHz sampling
+   frequency using the 'a=rtpmap' line.  Any number from 96 to 127 could
+   have been chosen (the allowed range for dynamic types).
+
+   The value of the sampling frequency is typically 8000 for narrow band
+   operation, 16000 for wide band operation, and 32000 for ultra-wide
+   band operation.
+
+   If for some reason the offerer has bandwidth limitations, the client
+   may use the "b=" header, as explained in SDP [4].  The following
+   example illustrates the case where the offerer cannot receive more
+   than 10 kbit/s.
+
+
+
+
+
+Herlein, et al.          Expires April 15, 2006                 [Page 8]
+
+Internet-Draft         draft-ietf-avt-rtp-speex-00          October 2005
+
+
+      m=audio 8088 RTP/AVP 97
+      b=AS:10
+      a=rtmap:97 speex/8000
+
+   In this case, if the remote part agrees, it should configure its
+   Speex encoder so that it does not use modes that produce more than 10
+   kbit/s.  Note that the "b=" constraint also applies on all payload
+   types that may be proposed in the media line ("m=").
+
+   An other way to make recommendations to the remote Speex encoder is
+   to use its specific parameters via the a=fmtp: directive.  The
+   following parameters are defined for use in this way:
+
+      ptime: duration of each packet in milliseconds.
+
+      sr:    actual sample rate in Hz.
+
+      ebw:   encoding bandwidth - either 'narrow' or 'wide' or 'ultra'
+      (corresponds to nominal 8000, 16000, and 32000 Hz sampling rates).
+
+      vbr:   variable bit rate  - either 'on' 'off' or 'vad' (defaults
+      to off).  If on, variable bit rate is enabled.  If off, disabled.
+      If set to 'vad' then constant bit rate is used but silence will be
+      encoded with special short frames to indicate a lack of voice for
+      that period.
+
+      cng:   comfort noise generation - either 'on' or 'off'.  If off
+      then silence frames will be silent; if 'on' then those frames will
+      be filled with comfort noise.
+
+      mode:  Speex encoding mode.  Can be {1,2,3,4,5,6,any} defaults to
+      3 in narrowband, 6 in wide and ultra-wide.
+
+
+   Examples:
+
+      m=audio 8008 RTP/AVP 97
+      a=rtpmap:97 speex/8000
+      a=fmtp:97 mode=4
+
+   This examples illustrate an offerer that wishes to receive a Speex
+   stream at 8000Hz, but only using speex mode 4.
+
+   Several Speex specific parameters can be given in a single a=fmtp
+   line provided that they are separated by a semi-colon:
+
+
+
+
+
+
+Herlein, et al.          Expires April 15, 2006                 [Page 9]
+
+Internet-Draft         draft-ietf-avt-rtp-speex-00          October 2005
+
+
+      a=fmtp:97 mode=any;mode=1
+
+   The offerer may indicate that it wishes to send variable bit rate
+   frames with comfort noise:
+
+      m=audio 8088 RTP/AVP 97
+      a=rtmap:97 speex/8000
+      a=fmtp:97 vbr=on;cng=on
+
+   The "ptime" attribute is used to denote the packetization interval
+   (ie, how many milliseconds of audio is encoded in a single RTP
+   packet).  Since Speex uses 20 msec frames, ptime values of multiples
+   of 20 denote multiple Speex frames per packet.  Values of ptime which
+   are not multiples of 20 MUST be ignored and clients MUST use the
+   default value of 20 instead.
+
+   In the example below the ptime value is set to 40, indicating that
+   there are 2 frames in each packet.
+
+      m=audio 8008 RTP/AVP 97
+      a=rtpmap:97 speex/8000
+      a=ptime:40
+
+   Note that the ptime parameter applies to all payloads listed in the
+   media line and is not used as part of an a=fmtp directive.
+
+   Values of ptime not multiple of 20 msec are meaningless, so the
+   receiver of such ptime values MUST ignore them.  If during the life
+   of an RTP session the ptime value changes, when there are multiple
+   Speex frames for example, the SDP value must also reflect the new
+   value.
+
+   Care must be taken when setting the value of ptime so that the RTP
+   packet size does not exceed the path MTU.
+
+10.  ITU H.323 Use of Speex
+
+   It is outside the scope of this document to cover the use of Speex
+   and H.323, more details may be found on the Speex website [9].
+
+11.  Security Considerations
+
+   RTP packets using the payload format defined in this specification
+   are subject to the security considerations discussed in the RTP
+   specification [2], and any appropriate RTP profile.  This implies
+   that confidentiality of the media streams is achieved by encryption.
+   Because the data compression used with this payload format is applied
+   end-to-end, encryption may be performed after compression so there is
+
+
+
+Herlein, et al.          Expires April 15, 2006                [Page 10]
+
+Internet-Draft         draft-ietf-avt-rtp-speex-00          October 2005
+
+
+   no conflict between the two operations.
+
+   A potential denial-of-service threat exists for data encodings using
+   compression techniques that have non-uniform receiver-end
+   computational load.  The attacker can inject pathological datagrams
+   into the stream which are complex to decode and cause the receiver to
+   be overloaded.  However, this encoding does not exhibit any
+   significant non-uniformity.
+
+   As with any IP-based protocol, in some circumstances a receiver may
+   be overloaded simply by the receipt of too many packets, either
+   desired or undesired.  Network-layer authentication may be used to
+   discard packets from undesired sources, but the processing cost of
+   the authentication itself may be too high.
+
+12.  Acknowledgments
+
+   The authors would like to thank Equivalence Pty Ltd of Australia for
+   their assistance in attempting to standardize the use of Speex in
+   H.323 applications, and for implementing Speex in their open source
+   OpenH323 stack.  The authors would also like to thank Brian C. Wiles
+   <brian at streamcomm.com> of StreamComm for his assistance in developing
+   the proposed standard for Speex use in H.323 applications.
+
+   The authors would also like to thank the following members of the
+   Speex and AVT communities for their input:  Ross Finlayson, Federico
+   Montesino Pouzols, Henning Schulzrinne, Magnus Westerlund.
+
+13.  References
+
+13.1  Normative References
+
+   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
+        Levels", RFC 2119.
+
+   [2]  Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
+        "RTP: A Transport Protocol for real-time applications",
+        RFC 3550.
+
+   [3]  "Multipurpose Internet Mail Extensions (MIME) Part One: Format
+        of Internet Message Bodies", RFC 2045.
+
+   [4]  Jacobson, V. and M. Handley, "SDP: Session Description
+        Protocol", RFC 2327.
+
+   [5]  Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video
+        Conferences with Minimal Control.", RFC 3551.
+
+
+
+
+Herlein, et al.          Expires April 15, 2006                [Page 11]
+
+Internet-Draft         draft-ietf-avt-rtp-speex-00          October 2005
+
+
+   [6]  Walleij, L., "The application/ogg Media Type", RFC 3534.
+
+13.2  Informative References
+
+   [7]  "Speexenc/speexdec, reference command-line encoder/decoder",
+        Speex website http://www.speex.org/.
+
+   [8]  "CELP, U.S. Federal Standard 1016.", National Technical
+        Information Service (NTIS) website http://www.ntis.gov/.
+
+   [9]  "ITU H.323/H.245 Use of Speex", Speex
+        website http://www.speex.org/itu/.
+
+
+Authors' Addresses
+
+   Greg Herlein
+   2034 Filbert Street
+   San Francisco, California  94123
+   United States
+
+   Email: gherlein at herlein.com
+
+
+   Simon Morlat
+   35, av de Vizille App 42
+   Grenoble  38000
+   France
+
+   Email: simon.morlat at linphone.org
+
+
+   Jean-Marc Valin
+   Department of Electrical and Computer Engineering
+   University of Sherbrooke
+   2500 blvd Universite
+   Sherbrooke, Quebec  J1K 2R1
+   Canada
+
+   Email: jean-marc.valin at usherbrooke.ca
+
+
+
+
+
+
+
+
+
+
+
+Herlein, et al.          Expires April 15, 2006                [Page 12]
+
+Internet-Draft         draft-ietf-avt-rtp-speex-00          October 2005
+
+
+   Roger Hardiman
+   49 Nettleton Road
+   Cheltenham, Gloucestershire  GL51 6NR
+   England
+
+   Email: roger at freebsd.org
+
+
+   Phil Kerr
+   England
+
+   Email: phil at plus24.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Herlein, et al.          Expires April 15, 2006                [Page 13]
+
+Internet-Draft         draft-ietf-avt-rtp-speex-00          October 2005
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr at ietf.org.
+
+
+Disclaimer of Validity
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2005).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Herlein, et al.          Expires April 15, 2006                [Page 14]
+



More information about the commits mailing list