[speex-dev] Updated Speex RTP Internet Draft

Simon Morlat simon.morlat at linphone.org
Mon Jun 30 00:29:52 PDT 2003



Hello,

What's the purpose of the 'sr' sdp parameter ?
The sample rate is already given in the a=rtpmap line ?
Simon

Le dim 29/06/2003 à 12:12, philkerr at elec.gla.ac.uk a écrit :
> Hi all,
> 
> Please find below an updated Speex Internet Draft document.
> 
> It would be good if we could book some time for discussion on Speex at the IETF
> meeting in Vienna (scheduled for 14th July).  The cutoff for submission is
> 9:00am EDT, (GMT -04:00), 30th June.    
> 
> Comments and feedback welcomed!
> 
> Regards
> 
> Phil
> 
> -----------------8<--------------------------------------------8<-------------------------------
> 
> 
> 
> 
> 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 RFC2026.
> 
>    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        July 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 summerized 
>    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 a four bit header block which is 
>    used to indicate the presence of 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        July 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        July 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
>    20ms frame boundary but the bit rate change notification is
>    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 or 16000 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              |
>    +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
>    |         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
> 
>    Required parameters: to be included in the Ogg MIME specification.
> 
>    Optional parameters:
> 
>    Encoding considerations:
> 
>    Security Considerations:
>          See Section 6 of RFC 3047.
> 
>    Interoperability considerations: none
> 
>    Published specification:  
> 
> 
> Herlein, Valin, et. al.   Expires January 30, 2004              [Page 4]
> ^L
> Internet-Draft       draft-herlein-speex-rtp-profile-01        July 2003
> 
> 
>    Applications which use this media type:
> 
>    Additional information: none
> 
>    Person & email address to contact for further information:
> 	 Greg Herlein <gherlein at herlein.com>
> 	 Jean-Marc Valin <jean-marc.valin at hermes.usherb.ca>
> 
>    Intended usage: COMMON
> 
>    Author/Change controller:
>          Author:  Greg Herlein <gherlein at herlein.com>
>          Change controller: Greg Herlein <gherlein at 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).  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
> 
> 
> 
> 
> Herlein, Valin, et. al.   Expires January 30, 2004              [Page 5]
> ^L
> Internet-Draft       draft-herlein-speex-rtp-profile-01        July 2003
> 
> 
>    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).
> 
>    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 
> 	
> 
> 
> Herlein, Valin, et. al.   Expires January 30, 2004              [Page 6]
> ^L
> Internet-Draft       draft-herlein-speex-rtp-profile-01        July 2003
> 
> 
>    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. 
> 
>    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:
> 
>    
> 
> 
> 
> Herlein, Valin, et. al.   Expires January 30, 2004              [Page 7]
> ^L
> Internet-Draft       draft-herlein-speex-rtp-profile-01        July 2003
> 
> 
>    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.  
> 
> 
> 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
> 
> 
> Herlein, Valin, et. al.   Expires January 30, 2004              [Page 8]
> ^L
> Internet-Draft       draft-herlein-speex-rtp-profile-01        July 2003
> 
> 
>    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-11.txt.
> 
>    9.  RTP Profile for Audio and Video Conferences with Minimal  
>        Control.  Work in progress, draft-ietf-avt-profile-new-12.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/
> 
> Herlein, Valin, et. al.   Expires January 30, 2004              [Page 9]
> ^L
> Internet-Draft       draft-herlein-speex-rtp-profile-01        July 2003
> 
> 
> 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 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.
> 
> 
> 10. Author's Address
> 
>    Greg Herlein <gherlein at herlein.com>
>    2034 Filbert Street
>    San Francisco, CA 
>    United States 94123
>    
> 
>    Jean-Marc Valin <jean-marc.valin at hermes.usherb.ca>
>    Department of Electrical and Computer Engineering
>    University of Sherbrooke
>    2500 blvd Universit‰
>    Sherbrooke, Quebec, Canada, J1K 2R1
> 
> 
>    Simon MORLAT <simon.morlat at linphone.org>
>    35, av de Vizille App 42
>    38000 GRENOBLE
>    FRANCE
> 
> 
>    Roger Hardiman <roger at freebsd.org>
>    49 Nettleton Road
>    Cheltenham
>    Gloucestershire
>    GL51 6NR
>    England
> 
> 
>    Phil Kerr <philkerr at 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 10]
> ^L
> 
> 
> 
> 
> 
> -------------------------------------------------
> This mail sent through IMP: http://horde.org/imp/
> --- >8 ----
> List archives:  http://www.xiph.org/archives/
> Ogg project homepage: http://www.xiph.org/ogg/
> To unsubscribe from this list, send a message to 'speex-dev-request at xiph.org'
> containing only the word 'unsubscribe' in the body.  No subject is needed.
> Unsubscribe messages sent to the list will be ignored/filtered.

-- 
Simon Morlat <simon.morlat at linphone.org>

--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to 'speex-dev-request at xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.




More information about the Speex-dev mailing list