842 lines
28 KiB
Plaintext
842 lines
28 KiB
Plaintext
|
|
|
|
AVT Working Group G. Herlein
|
|
Internet-Draft S. Morlat
|
|
Expires: October 3, 2005 J. Jean-Marc
|
|
R. Hardiman
|
|
P. Kerr
|
|
April 04, 2005
|
|
|
|
|
|
draft-herlein-speex-rtp-profile-02
|
|
RTP Payload Format for the Speex Codec
|
|
|
|
Status of this Memo
|
|
|
|
This document is an Internet-Draft and is subject to all provisions
|
|
of section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with
|
|
RFC 3668.
|
|
|
|
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 October 3, 2005.
|
|
|
|
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) and a preliminary method of using Speex
|
|
|
|
|
|
|
|
Herlein, et al. Expires October 3, 2005 [Page 1]
|
|
|
|
Internet-Draft draft-herlein-speex-rtp-profile-02 April 2005
|
|
|
|
|
|
within H.323 applications.
|
|
|
|
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/H.245 Use of Speex . . . . . . . . . . . . . . . . 10
|
|
11. NonStandardMessage format . . . . . . . . . . . . . . . . . 10
|
|
12. RTP Payload Types . . . . . . . . . . . . . . . . . . . . . 11
|
|
13. Security Considerations . . . . . . . . . . . . . . . . . . 11
|
|
14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 12
|
|
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
|
|
15.1 Normative References . . . . . . . . . . . . . . . . . . . 12
|
|
15.2 Informative References . . . . . . . . . . . . . . . . . . 13
|
|
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 13
|
|
Intellectual Property and Copyright Statements . . . . . . . 15
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Herlein, et al. Expires October 3, 2005 [Page 2]
|
|
|
|
Internet-Draft draft-herlein-speex-rtp-profile-02 April 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 [10] 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
|
|
|
|
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, et al. Expires October 3, 2005 [Page 3]
|
|
|
|
Internet-Draft draft-herlein-speex-rtp-profile-02 April 2005
|
|
|
|
|
|
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
|
|
| 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 [7] 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. 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 [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 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].
|
|
|
|
|
|
|
|
Herlein, et al. Expires October 3, 2005 [Page 4]
|
|
|
|
Internet-Draft draft-herlein-speex-rtp-profile-02 April 2005
|
|
|
|
|
|
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 [9], 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
|
|
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
|
|
|
|
|
|
|
|
Herlein, et al. Expires October 3, 2005 [Page 5]
|
|
|
|
Internet-Draft draft-herlein-speex-rtp-profile-02 April 2005
|
|
|
|
|
|
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 [9] 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 |
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
|
|
|
|
|
|
Herlein, et al. Expires October 3, 2005 [Page 6]
|
|
|
|
Internet-Draft draft-herlein-speex-rtp-profile-02 April 2005
|
|
|
|
|
|
| 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 [8].
|
|
|
|
MIME media type name: audio
|
|
|
|
MIME subtype: speex
|
|
|
|
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
|
|
|
|
|
|
|
|
|
|
Herlein, et al. Expires October 3, 2005 [Page 7]
|
|
|
|
Internet-Draft draft-herlein-speex-rtp-profile-02 April 2005
|
|
|
|
|
|
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 [8], 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.
|
|
|
|
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
|
|
|
|
|
|
|
|
Herlein, et al. Expires October 3, 2005 [Page 8]
|
|
|
|
Internet-Draft draft-herlein-speex-rtp-profile-02 April 2005
|
|
|
|
|
|
to use its specific parameters via the a=fmtp: directive. The
|
|
following parameters are defined for use in this way:
|
|
|
|
ptime: duration of each packet in milliseconds.
|
|
|
|
sr: actual sample rate in Hz.
|
|
|
|
ebw: encoding bandwidth - either 'narrow' or 'wide' or 'ultra'
|
|
(corresponds to nominal 8000, 16000, and 32000 Hz sampling rates).
|
|
|
|
vbr: variable bit rate - either 'on' 'off' or 'vad' (defaults
|
|
to off). If on, variable bit rate is enabled. If off, disabled.
|
|
If set to 'vad' then constant bit rate is used but silence will be
|
|
encoded with special short frames to indicate a lack of voice for
|
|
that period.
|
|
|
|
cng: comfort noise generation - either 'on' or 'off'. If off
|
|
then silence frames will be silent; if 'on' then those frames will
|
|
be filled with comfort noise.
|
|
|
|
mode: Speex encoding mode. Can be {1,2,3,4,5,6,any} defaults to
|
|
3 in narrowband, 6 in wide and ultra-wide.
|
|
|
|
penh: use of perceptual enhancement. 1 indicates to the decoder
|
|
that perceptual enhancement is recommended, 0 indicates that it is
|
|
not. Defaults to on (1).
|
|
|
|
|
|
Examples:
|
|
|
|
m=audio 8008 RTP/AVP 97
|
|
a=rtpmap:97 speex/8000
|
|
a=fmtp:97 mode=4
|
|
|
|
This examples illustrate an offerer that wishes to receive a Speex
|
|
stream at 8000Hz, but only using speex mode 3.
|
|
|
|
The offerer may suggest to the remote decoder to activate its
|
|
perceptual enhancement filter like this:
|
|
|
|
m=audio 8088 RTP/AVP 97
|
|
a=rtmap:97 speex/8000
|
|
a=fmtp:97 penh=1
|
|
|
|
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 October 3, 2005 [Page 9]
|
|
|
|
Internet-Draft draft-herlein-speex-rtp-profile-02 April 2005
|
|
|
|
|
|
a=fmtp:97 mode=any;penh=1
|
|
|
|
The offerer may indicate that it wishes to send variable bit rate
|
|
frames with comfort noise:
|
|
|
|
m=audio 8088 RTP/AVP 97
|
|
a=rtmap:97 speex/8000
|
|
a=fmtp:97 vbr=on;cng=on
|
|
|
|
The "ptime" attribute is used to denote the packetization interval
|
|
(ie, how many milliseconds of audio is encoded in a single RTP
|
|
packet). Since Speex uses 20 msec frames, ptime values of multiples
|
|
of 20 denote multiple Speex frames per packet. Values of ptime which
|
|
are not multiples of 20 MUST be ignored and clients MUST use the
|
|
default value of 20 instead.
|
|
|
|
In the example below the ptime value is set to 40, indicating that
|
|
there are 2 frames in each packet.
|
|
|
|
m=audio 8008 RTP/AVP 97
|
|
a=rtpmap:97 speex/8000
|
|
a=ptime:40
|
|
|
|
Note that the ptime parameter applies to all payloads listed in the
|
|
media line and is not used as part of an a=fmtp directive.
|
|
|
|
Values of ptime not multiple of 20 msec are meaningless, so the
|
|
receiver of such ptime values MUST ignore them. If during the life
|
|
of an RTP session the ptime value changes, when there are multiple
|
|
Speex frames for example, the SDP value must also reflect the new
|
|
value.
|
|
|
|
Care must be taken when setting the value of ptime so that the RTP
|
|
packet size does not exceed the path MTU.
|
|
|
|
10. 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 [5] by using a
|
|
non-standard codec block definition in the H.245 [6] codec capability
|
|
negotiations.
|
|
|
|
11. NonStandardMessage format
|
|
|
|
For Speex use in H.245 [6] based systems, the fields in the
|
|
NonStandardMessage should be:
|
|
|
|
|
|
|
|
|
|
|
|
Herlein, et al. Expires October 3, 2005 [Page 10]
|
|
|
|
Internet-Draft draft-herlein-speex-rtp-profile-02 April 2005
|
|
|
|
|
|
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 octet 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.
|
|
|
|
12. 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.
|
|
|
|
13. 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
|
|
|
|
|
|
|
|
Herlein, et al. Expires October 3, 2005 [Page 11]
|
|
|
|
Internet-Draft draft-herlein-speex-rtp-profile-02 April 2005
|
|
|
|
|
|
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.
|
|
|
|
14. 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.
|
|
|
|
15. References
|
|
|
|
15.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] "Packet-based Multimedia Communications Systems", ITU-T
|
|
Recommendation H.323.
|
|
|
|
[6] "Control of communications between Visual Telephone Systems and
|
|
Terminal Equipment", ITU-T Recommendation H.245.
|
|
|
|
[7] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video
|
|
|
|
|
|
|
|
Herlein, et al. Expires October 3, 2005 [Page 12]
|
|
|
|
Internet-Draft draft-herlein-speex-rtp-profile-02 April 2005
|
|
|
|
|
|
Conferences with Minimal Control.", RFC 3551.
|
|
|
|
[8] Walleij, L., "The application/ogg Media Type", RFC 3534.
|
|
|
|
15.2 Informative References
|
|
|
|
[9] "Speexenc/speexdec, reference command-line encoder/decoder",
|
|
Speex website http://www.speex.org/.
|
|
|
|
[10] "CELP, U.S. Federal Standard 1016.", National Technical
|
|
Information Service (NTIS) website http://www.ntis.gov/.
|
|
|
|
|
|
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@hermes.usherb.ca
|
|
|
|
|
|
Roger Hardiman
|
|
49 Nettleton Road
|
|
Cheltenham, Gloucestershire GL51 6NR
|
|
England
|
|
|
|
EMail: roger@freebsd.org
|
|
|
|
|
|
|
|
|
|
Herlein, et al. Expires October 3, 2005 [Page 13]
|
|
|
|
Internet-Draft draft-herlein-speex-rtp-profile-02 April 2005
|
|
|
|
|
|
Phil Kerr
|
|
England
|
|
|
|
EMail: phil@plus24.com
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Herlein, et al. Expires October 3, 2005 [Page 14]
|
|
|
|
Internet-Draft draft-herlein-speex-rtp-profile-02 April 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 October 3, 2005 [Page 15]
|
|
|
|
|