700 lines
26 KiB
Plaintext
700 lines
26 KiB
Plaintext
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Internet Engineering Task Force Greg Herlein
|
|||
|
Internet Draft Jean-Marc Valin
|
|||
|
draft-herlein-avt-rtp-speex-00.txt Simon Morlat
|
|||
|
March 3, 2004 Roger Hardiman
|
|||
|
Expires: September 3, 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 RFC 2026.
|
|||
|
|
|||
|
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 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 September 3, 2004 [Page 1]
|
|||
|
^L
|
|||
|
Internet-Draft draft-herlein-avt-rtp-speex-00.txt March 3, 2004
|
|||
|
|
|||
|
|
|||
|
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 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 |
|
|||
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|||
|
|
|||
|
|
|||
|
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 September 3, 2004 [Page 2]
|
|||
|
^L
|
|||
|
Internet-Draft draft-herlein-avt-rtp-speex-00.txt March 3, 2004
|
|||
|
|
|||
|
|
|||
|
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 September 3, 2004 [Page 3]
|
|||
|
^L
|
|||
|
Internet-Draft draft-herlein-avt-rtp-speex-00.txt March 3, 2004
|
|||
|
|
|||
|
|
|||
|
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
|
|||
|
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 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 byte 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.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 |
|
|||
|
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
|
|||
|
|
|||
|
|
|||
|
Herlein, Valin, et. al. Expires September 3, 2004 [Page 4]
|
|||
|
^L
|
|||
|
Internet-Draft draft-herlein-avt-rtp-speex-00.txt March 3, 2004
|
|||
|
|
|||
|
|
|||
|
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|
|
|||
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|||
|
|
|||
|
|
|||
|
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
|
|||
|
|
|||
|
Herlein, Valin, et. al. Expires September 3, 2004 [Page 5]
|
|||
|
^L
|
|||
|
Internet-Draft draft-herlein-avt-rtp-speex-00.txt March 3, 2004
|
|||
|
|
|||
|
|
|||
|
Optional parameters:
|
|||
|
|
|||
|
Required parameters: to be included in the Ogg MIME specification.
|
|||
|
|
|||
|
Encoding considerations:
|
|||
|
|
|||
|
Security Considerations:
|
|||
|
See Section 6 of RFC 3047.
|
|||
|
|
|||
|
Interoperability considerations: none
|
|||
|
|
|||
|
Published specification:
|
|||
|
|
|||
|
Applications which use this media type:
|
|||
|
|
|||
|
Additional information: none
|
|||
|
|
|||
|
Person & email address to contact for further information:
|
|||
|
Greg Herlein <gherlein@herlein.com>
|
|||
|
Jean-Marc Valin <jean-marc.valin@hermes.usherb.ca>
|
|||
|
|
|||
|
Intended usage: COMMON
|
|||
|
|
|||
|
Author/Change controller:
|
|||
|
Author: Greg Herlein <gherlein@herlein.com>
|
|||
|
Change controller: Greg Herlein <gherlein@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).
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Herlein, Valin, et. al. Expires September 3, 2004 [Page 6]
|
|||
|
^L
|
|||
|
Internet-Draft draft-herlein-avt-rtp-speex-00.txt March 3, 2004
|
|||
|
|
|||
|
|
|||
|
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
|
|||
|
|
|||
|
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).
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Herlein, Valin, et. al. Expires September 3, 2004 [Page 7]
|
|||
|
^L
|
|||
|
Internet-Draft draft-herlein-avt-rtp-speex-00.txt March 3, 2004
|
|||
|
|
|||
|
|
|||
|
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
|
|||
|
|
|||
|
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.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Herlein, Valin, et. al. Expires September 3, 2004 [Page 8]
|
|||
|
^L
|
|||
|
Internet-Draft draft-herlein-avt-rtp-speex-00.txt March 3, 2004
|
|||
|
|
|||
|
|
|||
|
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:
|
|||
|
|
|||
|
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.
|
|||
|
|
|||
|
Herlein, Valin, et. al. Expires September 3, 2004 [Page 9]
|
|||
|
^L
|
|||
|
Internet-Draft draft-herlein-avt-rtp-speex-00.txt March 3, 2004
|
|||
|
|
|||
|
|
|||
|
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
|
|||
|
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-12.txt.
|
|||
|
|
|||
|
Herlein, Valin, et. al. Expires September 3, 2004 [Page 10]
|
|||
|
^L
|
|||
|
Internet-Draft draft-herlein-avt-rtp-speex-00.txt March 3, 2004
|
|||
|
|
|||
|
|
|||
|
9. RTP Profile for Audio and Video Conferences with Minimal
|
|||
|
Control. Work in progress, draft-ietf-avt-profile-new-13.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/
|
|||
|
|
|||
|
|
|||
|
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@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@herlein.com>
|
|||
|
2034 Filbert Street
|
|||
|
San Francisco, CA
|
|||
|
United States 94123
|
|||
|
|
|||
|
|
|||
|
Jean-Marc Valin <jean-marc.valin@hermes.usherb.ca>
|
|||
|
Department of Electrical and Computer Engineering
|
|||
|
University of Sherbrooke
|
|||
|
2500 blvd Universit<69><74><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
|
|||
|
Sherbrooke, Quebec, Canada, J1K 2R1
|
|||
|
|
|||
|
|
|||
|
Simon MORLAT <simon.morlat@linphone.org>
|
|||
|
35, av de Vizille App 42
|
|||
|
38000 GRENOBLE
|
|||
|
FRANCE
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Herlein, Valin, et. al. Expires September 3, 2004 [Page 11]
|
|||
|
^L
|
|||
|
Internet-Draft draft-herlein-avt-rtp-speex-00.txt March 3, 2004
|
|||
|
|
|||
|
|
|||
|
Roger Hardiman <roger@freebsd.org>
|
|||
|
49 Nettleton Road
|
|||
|
Cheltenham
|
|||
|
Gloucestershire
|
|||
|
GL51 6NR
|
|||
|
England
|
|||
|
|
|||
|
|
|||
|
Phil Kerr <philkerr@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 September 3, 2004 [Page 12]
|
|||
|
^L
|
|||
|
|
|||
|
|