[Speex-dev] draft-ietf-avt-rtp-speex-01.txt
Jean-Marc Valin
jean-marc.valin at usherbrooke.ca
Thu Jun 7 07:12:26 PDT 2007
Looks good to me.
Jean-Marc
Alfred E. Heggestad a écrit :
> Hi
>
> Please find an updated version of the Speex I-D attached. The only
> change is addition of the copyright conditions in Appendix A,
> as requested by Ivo.
>
> Many thanks for your input.
>
> I will give you a few more days before submitting to AVT working group
>
>
> /alfred
>
> Ivo Emanuel Gonçalves wrote:
>> Do not forget to add the "Copying conditions" to the RFC.
>>
>> Check http://wiki.debian.org/NonFreeIETFDocuments
>>
>> That page contains a section titled "Template for RFC authors to
>> release additional rights". To follow that guideline a
>> section like the following should be added:
>>
>> x. Copying conditions
>>
>> The author(s) agree to grant third parties the irrevocable
>> right to copy, use and distribute the work, with
>> or without modification, in any medium, without royalty,
>> provided that, unless separate permission is granted,
>> redistributed modified works do not contain misleading
>> author, version, name of work, or endorsement information.
>>
>>
>> -Ivo
>> _______________________________________________
>> Speex-dev mailing list
>> Speex-dev at xiph.org
>> http://lists.xiph.org/mailman/listinfo/speex-dev
>
>
> ------------------------------------------------------------------------
>
>
>
>
> AVT G. Herlein
> Internet-Draft
> Intended status: Standards Track J. Valin
> Expires: December 7, 2007 CSIRO
> A. Heggestad
> Creytiv.com
> A. Moizard
> Antisip
> June 5, 2007
>
>
> RTP Payload Format for the Speex Codec
> draft-ietf-avt-rtp-speex-01
>
> 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 December 7, 2007.
>
> Copyright Notice
>
> Copyright (C) The IETF Trust (2007).
>
>
>
>
>
>
>
>
>
> Herlein, et al. Expires December 7, 2007 [Page 1]
>
> Internet-Draft Speex June 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 December 7, 2007 [Page 2]
>
> Internet-Draft Speex June 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. Implementation Guidelines . . . . . . . . . . . . . . . . . . 15
> 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16
> 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
> 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
> 9.1. Normative References . . . . . . . . . . . . . . . . . . . 18
> 9.2. Informative References . . . . . . . . . . . . . . . . . . 18
> Appendix A. Copying conditions . . . . . . . . . . . . . . . . . 19
> Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
> Intellectual Property and Copyright Statements . . . . . . . . . . 21
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Herlein, et al. Expires December 7, 2007 [Page 3]
>
> Internet-Draft Speex June 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
>
> The Speex codec supports a wide range of bit-rates from 2.15 kbit/s
> to 44 kbit/s. In some cases however, it may not be possible for an
> implementation to include support for all rates (e.g. because of
> bandwidth, RAM or CPU constraints). In those cases, to be compliant
> with this specification, implementations MUST support at least
> narrowband (8 kHz) encoding and decoding at 8 kbit/s bit-rate
> (narrowband mode 3). Support for narrowband at 15 kbit/s (narrowband
> mode 5) is RECOMMENDED and support for wideband at 27.8 kbit/s
> (wideband mode 8) is also RECOMMENDED. The sampling rate MUST be 8,
> 16 or 32 kHz.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Herlein, et al. Expires December 7, 2007 [Page 4]
>
> Internet-Draft Speex June 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 December 7, 2007 [Page 5]
>
> Internet-Draft Speex June 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 [speex_manual], 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 December 7, 2007 [Page 6]
>
> Internet-Draft Speex June 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 sampling rate
> (narrowband, wideband or ultra-wideband) and "mode" (bit-rate)
> information in the bit stream. No out-of-band notification is
> required for the decoder to process changes in the bit rate sent by
> the encoder.
>
> 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.
>
> The Speex decoder [speex_manual] can detect the bitrate from the
>
>
>
> Herlein, et al. Expires December 7, 2007 [Page 7]
>
> Internet-Draft Speex June 2007
>
>
> payload and is responsible for detecting the 20 msec boundaries
> between each frame.
>
> 0 1 2 3
> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | RTP Header |
> +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
> | ..speex frame 1.. |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | ..speex frame 1.. | ..speex frame 2.. |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | ..speex frame 2.. |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Herlein, et al. Expires December 7, 2007 [Page 8]
>
> Internet-Draft Speex June 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: SHOULD be a multiple of 20 msec [RFC4566]
>
> maxptime: SHOULD be a multiple of 20 msec [RFC4566]
>
> 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 December 7, 2007 [Page 9]
>
> Internet-Draft Speex June 2007
>
>
> Alfred E. Heggestad: aeh at 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 December 7, 2007 [Page 10]
>
> Internet-Draft Speex June 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 MUST be either 8000 for narrow
> band operation, 16000 for wide band operation, and 32000 for ultra-
> wide band operation.
>
> As specified in RFC 4566 [RFC4566] if the ptime attribute is present
> for a stream, it indicates the desired packetization interval that
> the offerer would like to receive. The ptime attribute MUST be
> greater than zero. Note that the sender is still allowed to use a
> different packetisation interval. Since Speex uses 20 msec frames,
> if the ptime attribute is not a multiple of 20 msec, the value MUST
> be rounded up to a multiple of 20 msec. Rounding up is mandatory to
> satisfy bandwidth limitations.
>
> Implementations MUST support ptime of 20 msec (i.e. one frame per
> packet)
>
> 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:
>
> 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.
>
>
>
>
>
>
> Herlein, et al. Expires December 7, 2007 [Page 11]
>
> Internet-Draft Speex June 2007
>
>
> mode: List supported Speex decoding modes. The valid modes are
> different for narrowband and wideband, and are defined as follows:
>
> * {1,2,3,4,5,6,7,8,any} for narrowband
>
> * {0,1,2,3,4,5,6,7,8,9,10,any} for wideband and ultra-wideband
>
> Several 'mode' parameters can be provided. In this case, the
> remote party SHOULD configure its encoder using the first
> supported mode provided. When 'any' is used, the offerer
> indicates that it supports all decoding modes. If the 'mode'
> parameter is not provided, the mode value is considered to be
> equivalent to 'mode=3;mode=any' in narrowband and
> 'mode=8;mode=any' in wideband and ultra-wideband.
>
> Note that each speex frame does contains the mode (or bit-rate)
> that should be used to decode it. Thus application MUST be able
> to decode any speex frame unless the SDP clearly specify that some
> modes are not supported. (e.g., by not including 'mode=any')
>
> The tables below include the equivalence between modes and bitrates
> for narrowband, wideband and ultra-wideband. Also, the corresponding
> "Speex quality" setting (see SPEEX_SET_QUALITY in The Speex Codec
> Manual [speex_manual]) is included as an indication.
>
> +------+---------------+-------------+
> | mode | Speex quality | bitrate |
> +------+---------------+-------------+
> | 1 | 0 | 2.15 kbit/s |
> | | | |
> | 2 | 2 | 5.95 kbit/s |
> | | | |
> | 3 | 3 or 4 | 8.00 kbit/s |
> | | | |
> | 4 | 5 or 6 | 11.0 kbit/s |
> | | | |
> | 5 | 7 or 8 | 15.0 kbit/s |
> | | | |
> | 6 | 9 | 18.2 kbit/s |
> | | | |
> | 7 | 10 | 24.6 kbit/s |
> | | | |
> | 8 | 1 | 3.95 kbit/s |
> +------+---------------+-------------+
>
> Mode vs Bitrate table for narrowband
>
> Table 1
>
>
>
> Herlein, et al. Expires December 7, 2007 [Page 12]
>
> Internet-Draft Speex June 2007
>
>
> +------+---------------+------------------+------------------------+
> | mode | Speex quality | wideband bitrate | ultra wideband bitrate |
> +------+---------------+------------------+------------------------+
> | 0 | 0 | 3.95 kbit/s | 5.75 kbit/s |
> | | | | |
> | 1 | 1 | 5.75 kbit/s | 7.55 kbit/s |
> | | | | |
> | 2 | 2 | 7.75 kbit/s | 9.55 kbit/s |
> | | | | |
> | 3 | 3 | 9.80 kbit/s | 11.6 kbit/s |
> | | | | |
> | 4 | 4 | 12.8 kbit/s | 14.6 kbit/s |
> | | | | |
> | 5 | 5 | 16.8 kbit/s | 18.6 kbit/s |
> | | | | |
> | 6 | 6 | 20.6 kbit/s | 22.4 kbit/s |
> | | | | |
> | 7 | 7 | 23.8 kbit/s | 25.6 kbit/s |
> | | | | |
> | 8 | 8 | 27.8 kbit/s | 29.6 kbit/s |
> | | | | |
> | 9 | 9 | 34.2 kbit/s | 36.0 kbit/s |
> | | | | |
> | 10 | 10 | 42.2 kbit/s | 44.0 kbit/s |
> +------+---------------+------------------+------------------------+
>
> Mode vs Bitrate table for wideband and ultra-wideband
>
> Table 2
>
> Examples:
>
> m=audio 8008 RTP/AVP 97
> a=rtpmap:97 speex/8000
> a=fmtp:97 mode=4;mode=any
>
> This examples illustrate an offerer that wishes to receive a Speex
> stream at 8000Hz, and wishes to receive speex 'mode 4'. It is
> important to understand that any other mode might still be sent by
> remote party: the device might have bandwidth limitation or might
> only be able to send 'mode=3'. Thus, application that support all
> decoding modes SHOULD include 'mode=any' as shown in the example.
>
> The offerer indicates the mode he wishes to receive (speex 'mode 6')
> followed by all supported modes (all speex mode).
>
>
>
>
>
>
> Herlein, et al. Expires December 7, 2007 [Page 13]
>
> Internet-Draft Speex June 2007
>
>
> m=audio 8088 RTP/AVP 97
> a=rtmap:97 speex/8000
> a=fmtp:97 mode=6;mode=any
>
> The offerer indicates the mode he wishes to receive (speex 'mode 3').
> This offer indicates mode 3 and mode 5 are supported and that no
> other modes are supported. The remote party MUST not configure its
> encoder using another speex mode.
>
> m=audio 8088 RTP/AVP 97
> a=rtmap:97 speex/8000
> a=fmtp:97 mode=3;mode=5
>
> Several Speex specific parameters can be given in a single a=fmtp
> line provided that they are separated by a semi-colon:
>
> a=fmtp:97 mode=1;mode=any;vbr=on
>
> 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 rounded up to the first multiple of
> 20 above the ptime value.
>
> In the example below the ptime value is set to 40, indicating that
> there are 2 frames in each packet.
>
> m=audio 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.
>
> 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 December 7, 2007 [Page 14]
>
> Internet-Draft Speex June 2007
>
>
> 6. Implementation Guidelines
>
> Implementations that supports speex are responsible for correctly
> decoding incoming speex frames.
>
> Each speex frame does contains all needed informations to decode
> itself. In particular, the 'mode' and 'ptime' values proposed in the
> SDP contents MUST not be used for decoding: those values are not
> needed to properly decode a RTP speex stream.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Herlein, et al. Expires December 7, 2007 [Page 15]
>
> Internet-Draft Speex June 2007
>
>
> 7. Security Considerations
>
> RTP packets using the payload format defined in this specification
> are subject to the security considerations discussed in the RTP
> specification [RFC3550], and any appropriate RTP profile. This
> implies that confidentiality of the media streams is achieved by
> encryption. Because the data compression used with this payload
> format is applied end-to-end, encryption may be performed after
> compression so there is no conflict between the two operations.
>
> A potential denial-of-service threat exists for data encodings using
> compression techniques that have non-uniform receiver-end
> computational load. The attacker can inject pathological datagrams
> into the stream which are complex to decode and cause the receiver to
> be overloaded. However, this encoding does not exhibit any
> significant non-uniformity.
>
> As with any IP-based protocol, in some circumstances a receiver may
> be overloaded simply by the receipt of too many packets, either
> desired or undesired. Network-layer authentication may be used to
> discard packets from undesired sources, but the processing cost of
> the authentication itself may be too high.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Herlein, et al. Expires December 7, 2007 [Page 16]
>
> Internet-Draft Speex June 2007
>
>
> 8. Acknowledgements
>
> The authors would like to thank Equivalence Pty Ltd of Australia for
> their assistance in attempting to standardize the use of Speex in
> H.323 applications, and for implementing Speex in their open source
> OpenH323 stack. The authors would also like to thank Brian C. Wiles
> <brian 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.
>
> Thanks to former authors of this document; Simon Morlat, Roger
> Hardiman, Phil Kerr.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Herlein, et al. Expires December 7, 2007 [Page 17]
>
> Internet-Draft Speex June 2007
>
>
> 9. References
>
> 9.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.
>
> 9.2. Informative References
>
> [CELP] "CELP, U.S. Federal Standard 1016.", National Technical
> Information Service (NTIS) website http://www.ntis.gov/.
>
> [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and
> Registration Procedures", BCP 13, RFC 4288, December 2005.
>
> [speex_manual]
> Valin, J., "The Speex Codec Manual", Speex
> website http://www.speex.org/docs/.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Herlein, et al. Expires December 7, 2007 [Page 18]
>
> Internet-Draft Speex June 2007
>
>
> Appendix A. Copying conditions
>
> The author(s) agree to grant third parties the irrevocable right to
> copy, use and distribute the work, with or without modification, in
> any medium, without royalty, provided that, unless separate
> permission is granted, redistributed modified works do not contain
> misleading author, version, name of work, or endorsement information.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Herlein, et al. Expires December 7, 2007 [Page 19]
>
> Internet-Draft Speex June 2007
>
>
> Authors' Addresses
>
> Greg Herlein
> 2034 Filbert Street
> San Francisco, California 94123
> United States
>
> Email: gherlein at herlein.com
>
>
> Jean-Marc Valin
> CSIRO
> PO Box 76
> Epping, NSW 1710
> Australia
>
> Email: jean-marc.valin at usherbrooke.ca
>
>
> Alfred E. Heggestad
> Creytiv.com
> Biskop J. Nilssonsgt. 20a
> Oslo 0659
> Norway
>
> Email: aeh at db.org
>
>
> Aymeric Moizard
> Antisip
> 4 Quai Perrache
> Lyon 69002
> France
>
> Email: jack at atosc.org
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Herlein, et al. Expires December 7, 2007 [Page 20]
>
> Internet-Draft Speex June 2007
>
>
> Full Copyright Statement
>
> Copyright (C) The IETF Trust (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, THE IETF TRUST AND
> THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
> OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
> THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
> WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
>
>
> Intellectual Property
>
> The IETF takes no position regarding the validity or scope of any
> Intellectual Property Rights or other rights that might be claimed to
> pertain to the implementation or use of the technology described in
> this document or the extent to which any license under such rights
> might or might not be available; nor does it represent that it has
> made any independent effort to identify any such rights. Information
> on the procedures with respect to rights in RFC documents can be
> found in BCP 78 and BCP 79.
>
> Copies of IPR disclosures made to the IETF Secretariat and any
> assurances of licenses to be made available, or the result of an
> attempt made to obtain a general license or permission for the use of
> such proprietary rights by implementers or users of this
> specification can be obtained from the IETF on-line IPR repository at
> http://www.ietf.org/ipr.
>
> The IETF invites any interested party to bring to its attention any
> copyrights, patents or patent applications, or other proprietary
> rights that may cover technology that may be required to implement
> this standard. Please address the information to the IETF at
> ietf-ipr at ietf.org.
>
>
> Acknowledgment
>
> Funding for the RFC Editor function is provided by the IETF
> Administrative Support Activity (IASA).
>
>
>
>
>
> Herlein, et al. Expires December 7, 2007 [Page 21]
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Speex-dev mailing list
> Speex-dev at xiph.org
> http://lists.xiph.org/mailman/listinfo/speex-dev
More information about the Speex-dev
mailing list