785 lines
26 KiB
Plaintext
785 lines
26 KiB
Plaintext
|
||
|
||
|
||
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@herlein.com>
|
||
Jean-Marc Valin <jean-marc.valin@usherbrooke.ca>
|
||
|
||
Intended usage: COMMON
|
||
|
||
Author/Change controller:
|
||
|
||
Author: Greg Herlein <gherlein@herlein.com>
|
||
Change controller: Greg Herlein <gherlein@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@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@herlein.com
|
||
|
||
|
||
Simon Morlat
|
||
35, av de Vizille App 42
|
||
Grenoble 38000
|
||
France
|
||
|
||
Email: simon.morlat@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@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@freebsd.org
|
||
|
||
|
||
Phil Kerr
|
||
England
|
||
|
||
Email: phil@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@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]
|
||
|