[Speex-dev] draft-ietf-avt-rtp-speex-01.txt
Aymeric Moizard
jack at atosc.org
Fri Jun 8 11:29:33 PDT 2007
On Fri, 8 Jun 2007, Jean-Marc Valin wrote:
> Looks good to me.
You have my "go!" too...
Aymeric
> 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
> _______________________________________________
> 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