732 lines
28 KiB
Plaintext
732 lines
28 KiB
Plaintext
|
||
|
||
|
||
|
||
|
||
|
||
Network Working Group A. Duric
|
||
Request for Comments: 3952 Telio
|
||
Category: Experimental S. Andersen
|
||
Aalborg University
|
||
December 2004
|
||
|
||
|
||
Real-time Transport Protocol (RTP) Payload Format
|
||
for internet Low Bit Rate Codec (iLBC) Speech
|
||
|
||
Status of this Memo
|
||
|
||
This memo defines an Experimental Protocol for the Internet
|
||
community. It does not specify an Internet standard of any kind.
|
||
Discussion and suggestions for improvement are requested.
|
||
Distribution of this memo is unlimited.
|
||
|
||
Copyright Notice
|
||
|
||
Copyright (C) The Internet Society (2004).
|
||
|
||
Abstract
|
||
|
||
This document describes the Real-time Transport Protocol (RTP)
|
||
payload format for the internet Low Bit Rate Codec (iLBC) Speech
|
||
developed by Global IP Sound (GIPS). Also, within the document there
|
||
are included necessary details for the use of iLBC with MIME and
|
||
Session Description Protocol (SDP).
|
||
|
||
Table of Contents
|
||
|
||
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . 2
|
||
2. Background. . . . . . . . . . . . . . . . . . . . . . . . . . . 2
|
||
3. RTP Payload Format. . . . . . . . . . . . . . . . . . . . . . . 3
|
||
3.1. Bitstream definition . . . . . . . . . . . . . . . . . . . 3
|
||
3.2. Multiple iLBC frames in a RTP packet . . . . . . . . . . . 6
|
||
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
|
||
4.1. Storage Mode . . . . . . . . . . . . . . . . . . . . . . . 7
|
||
4.2. MIME registration of iLBC. . . . . . . . . . . . . . . . . 8
|
||
5. Mapping to SDP Parameters . . . . . . . . . . . . . . . . . . . 9
|
||
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 11
|
||
7. References. . . . . . . . . . . . . . . . . . . . . . . . . . . 11
|
||
7.1. Normative References . . . . . . . . . . . . . . . . . . . 11
|
||
7.2. Informative References . . . . . . . . . . . . . . . . . . 12
|
||
8. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . . 12
|
||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
|
||
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 13
|
||
|
||
|
||
|
||
|
||
Duric & Andersen Experimental [Page 1]
|
||
|
||
RFC 3952 RTP Payload Format for iLBC Speech December 2004
|
||
|
||
|
||
1. Introduction
|
||
|
||
This document describes how compressed iLBC speech, as produced by
|
||
the iLBC codec [1], may be formatted for use as an RTP payload type.
|
||
Methods are provided to packetize the codec data frames into RTP
|
||
packets. The sender may send one or more codec data frames per
|
||
packet depending on the application scenario or based on the
|
||
transport network condition, bandwidth restriction, delay
|
||
requirements and packet-loss tolerance.
|
||
|
||
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 BCP 14, RFC 2119 [2].
|
||
|
||
2. Background
|
||
|
||
Global IP Sound (GIPS) has developed a speech compression algorithm
|
||
for use in IP based communications [1]. The iLBC codec enables
|
||
graceful speech quality degradation in the case of lost frames, which
|
||
occurs in connection with lost or delayed IP packets.
|
||
|
||
This codec is suitable for real time communications such as,
|
||
telephony and videoconferencing, streaming audio, archival and
|
||
messaging.
|
||
|
||
The iLBC codec [1] is an algorithm that compresses each basic frame
|
||
(20 ms or 30 ms) of 8000 Hz, 16-bit sampled input speech, into output
|
||
frames with rate of 400 bits for 30 ms basic frame size and 304 bits
|
||
for 20 ms basic frame size.
|
||
|
||
The codec supports two basic frame lengths: 30 ms at 13.33 kbit/s and
|
||
20 ms at 15.2 kbit/s, using a block independent linear-predictive
|
||
coding (LPC) algorithm. When the codec operates at block lengths of
|
||
20 ms, it produces 304 bits per block which MUST be packetized in 38
|
||
bytes. Similarly, for block lengths of 30 ms it produces 400 bits
|
||
per block which MUST be packetized in 50 bytes. This algorithm
|
||
results in a speech coding system with a controlled response to
|
||
packet losses similar to what is known from pulse code modulation
|
||
(PCM) with a packet loss concealment (PLC), such as ITU-T G711
|
||
standard [7], which operates at a fixed bit rate of 64 kbit/s. At
|
||
the same time, this algorithm enables fixed bit rate coding with a
|
||
quality-versus-bit rate tradeoff close to what is known from code-
|
||
excited linear prediction (CELP).
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Duric & Andersen Experimental [Page 2]
|
||
|
||
RFC 3952 RTP Payload Format for iLBC Speech December 2004
|
||
|
||
|
||
3. RTP Payload Format
|
||
|
||
The iLBC codec uses 20 or 30 ms frames and a sampling rate clock of 8
|
||
kHz, so the RTP timestamp MUST be in units of 1/8000 of a second. The
|
||
RTP payload for iLBC has the format shown in the figure bellow. No
|
||
addition header specific to this payload format is required.
|
||
|
||
This format is intended for the situations where the sender and the
|
||
receiver send one or more codec data frames per packet. The RTP
|
||
packet looks as follows:
|
||
|
||
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 [3] |
|
||
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
|
||
| |
|
||
+ one or more frames of iLBC [1] |
|
||
| |
|
||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||
|
||
Figure 1, Packet format diagram
|
||
|
||
The RTP header of the packetized encoded iLBC speech has the expected
|
||
values as described in [3]. The usage of M bit SHOULD be as
|
||
specified in the applicable RTP profile, for example, RFC 3551 [4]
|
||
specifies that if the sender does not suppress silence (i.e., sends a
|
||
frame on every frame interval), the M bit will always be zero. When
|
||
more then one codec data frame is present in a single RTP packet, the
|
||
timestamp is, as always, the oldest data frame represented in the RTP
|
||
packet.
|
||
|
||
The assignment of an RTP payload type for this new packet format is
|
||
outside the scope of this document, and will not be specified here.
|
||
It is expected that the RTP profile for a particular class of
|
||
applications will assign a payload type for this encoding, or if that
|
||
is not done, then a payload type in the dynamic range shall be chosen
|
||
by the sender.
|
||
|
||
3.1. Bitstream definition
|
||
|
||
The total number of bits used to describe one frame of 20 ms speech
|
||
is 304, which fits in 38 bytes and results in a bit rate of 15.20
|
||
kbit/s. For the case with a frame length of 30 ms speech the total
|
||
number of bits used is 400, which fits in 50 bytes and results in a
|
||
bit rate of 13.33 kbit/s. In the bitstream definition, the bits are
|
||
distributed into three classes according to their bit error or loss
|
||
sensitivity. The most sensitive bits (class 1) are placed first in
|
||
|
||
|
||
|
||
Duric & Andersen Experimental [Page 3]
|
||
|
||
RFC 3952 RTP Payload Format for iLBC Speech December 2004
|
||
|
||
|
||
the bitstream for each frame. The less sensitive bits (class 2) are
|
||
placed after the class 1 bits. The least sensitive bits (class 3)
|
||
are placed at the end of the bitstream for each frame.
|
||
|
||
Looking at the 20/30 ms frame length cases for each class: The class
|
||
1 bits occupy a total of 6/8 bytes (48/64 bits), the class 2 bits
|
||
occupy 8/12 bytes (64/96 bits), and the class 3 bits occupy 24/30
|
||
bytes (191/239 bits). This distribution of the bits enables the use
|
||
of uneven level protection (ULP). The detailed bit allocation is
|
||
shown in the table below. When a quantization index is distributed
|
||
between more classes the more significant bits belong to the lowest
|
||
class.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Duric & Andersen Experimental [Page 4]
|
||
|
||
RFC 3952 RTP Payload Format for iLBC Speech December 2004
|
||
|
||
|
||
Bitstream structure:
|
||
|
||
------------------------------------------------------------------+
|
||
Parameter | Bits Class <1,2,3> |
|
||
| 20 ms frame | 30 ms frame |
|
||
----------------------------------+---------------+---------------+
|
||
Split 1 | 6 <6,0,0> | 6 <6,0,0> |
|
||
LSF 1 Split 2 | 7 <7,0,0> | 7 <7,0,0> |
|
||
LSF Split 3 | 7 <7,0,0> | 7 <7,0,0> |
|
||
------------------+---------------+---------------+
|
||
Split 1 | NA (Not Appl.)| 6 <6,0,0> |
|
||
LSF 2 Split 2 | NA | 7 <7,0,0> |
|
||
Split 3 | NA | 7 <7,0,0> |
|
||
------------------+---------------+---------------+
|
||
Sum | 20 <20,0,0> | 40 <40,0,0> |
|
||
----------------------------------+---------------+---------------+
|
||
Block Class. | 2 <2,0,0> | 3 <3,0,0> |
|
||
----------------------------------+---------------+---------------+
|
||
Position 22 sample segment | 1 <1,0,0> | 1 <1,0,0> |
|
||
----------------------------------+---------------+---------------+
|
||
Scale Factor State Coder | 6 <6,0,0> | 6 <6,0,0> |
|
||
----------------------------------+---------------+---------------+
|
||
Sample 0 | 3 <0,1,2> | 3 <0,1,2> |
|
||
Quantized Sample 1 | 3 <0,1,2> | 3 <0,1,2> |
|
||
Residual : | : : | : : |
|
||
State : | : : | : : |
|
||
Samples : | : : | : : |
|
||
Sample 56 | 3 <0,1,2> | 3 <0,1,2> |
|
||
Sample 57 | NA | 3 <0,1,2> |
|
||
------------------+---------------+---------------+
|
||
Sum | 171 <0,57,114>| 174 <0,58,116>|
|
||
----------------------------------+---------------+---------------+
|
||
Stage 1 | 7 <6,0,1> | 7 <4,2,1> |
|
||
CB for 22/23 Stage 2 | 7 <0,0,7> | 7 <0,0,7> |
|
||
sample block Stage 3 | 7 <0,0,7> | 7 <0,0,7> |
|
||
------------------+---------------+---------------+
|
||
Sum | 21 <6,0,15> | 21 <4,2,15> |
|
||
----------------------------------+---------------+---------------+
|
||
Stage 1 | 5 <2,0,3> | 5 <1,1,3> |
|
||
Gain for 22/23 Stage 2 | 4 <1,1,2> | 4 <1,1,2> |
|
||
sample block Stage 3 | 3 <0,0,3> | 3 <0,0,3> |
|
||
------------------+---------------+---------------+
|
||
Sum | 12 <3,1,8> | 12 <2,2,8> |
|
||
----------------------------------+---------------+---------------+
|
||
Stage 1 | 8 <7,0,1> | 8 <6,1,1> |
|
||
sub-block 1 Stage 2 | 7 <0,0,7> | 7 <0,0,7> |
|
||
Stage 3 | 7 <0,0,7> | 7 <0,0,7> |
|
||
------------------+---------------+---------------+
|
||
|
||
|
||
|
||
Duric & Andersen Experimental [Page 5]
|
||
|
||
RFC 3952 RTP Payload Format for iLBC Speech December 2004
|
||
|
||
|
||
Stage 1 | 8 <0,0,8> | 8 <0,7,1> |
|
||
sub-block 2 Stage 2 | 8 <0,0,8> | 8 <0,0,8> |
|
||
Indices Stage 3 | 8 <0,0,8> | 8 <0,0,8> |
|
||
for CB ------------------+---------------+---------------+
|
||
sub-blocks Stage 1 | NA | 8 <0,7,1> |
|
||
sub-block 3 Stage 2 | NA | 8 <0,0,8> |
|
||
Stage 3 | NA | 8 <0,0,8> |
|
||
------------------+---------------+---------------+
|
||
Stage 1 | NA | 8 <0,7,1> |
|
||
sub-block 4 Stage 2 | NA | 8 <0,0,8> |
|
||
Stage 3 | NA | 8 <0,0,8> |
|
||
------------------+---------------+---------------+
|
||
Sum | 46 <7,0,39> | 94 <6,22,66> |
|
||
----------------------------------+---------------+---------------+
|
||
Stage 1 | 5 <1,2,2> | 5 <1,2,2> |
|
||
sub-block 1 Stage 2 | 4 <1,1,2> | 4 <1,2,1> |
|
||
Stage 3 | 3 <0,0,3> | 3 <0,0,3> |
|
||
------------------+---------------+---------------+
|
||
Stage 1 | 5 <1,1,3> | 5 <0,2,3> |
|
||
sub-block 2 Stage 2 | 4 <0,2,2> | 4 <0,2,2> |
|
||
Stage 3 | 3 <0,0,3> | 3 <0,0,3> |
|
||
Gains for ------------------+---------------+---------------+
|
||
sub-blocks Stage 1 | NA | 5 <0,1,4> |
|
||
sub-block 3 Stage 2 | NA | 4 <0,1,3> |
|
||
Stage 3 | NA | 3 <0,0,3> |
|
||
------------------+---------------+---------------+
|
||
Stage 1 | NA | 5 <0,1,4> |
|
||
sub-block 4 Stage 2 | NA | 4 <0,1,3> |
|
||
Stage 3 | NA | 3 <0,0,3> |
|
||
------------------+---------------+---------------+
|
||
Sum | 24 <3,6,15> | 48 <2,12,34> |
|
||
-------------------------------------------------------------------
|
||
Empty frame indicator | 1 <0,0,1> | 1 <0,0,1> |
|
||
-------------------------------------------------------------------
|
||
SUM 304 <48,64,192> 400 <64,96,240>
|
||
|
||
Table 3.1 The bitstream definition for iLBC.
|
||
|
||
When packetized into the payload, all the class 1 bits MUST be sorted
|
||
in order (from top and down) as they were specified in the table.
|
||
Additionally, all the class 2 bits MUST be sorted (from top and down)
|
||
and all the class 3 bits MUST be sorted in the same sequential order.
|
||
|
||
3.2. Multiple iLBC frames in a RTP packet
|
||
|
||
More than one iLBC frame may be included in a single RTP packet by a
|
||
sender.
|
||
|
||
|
||
|
||
|
||
Duric & Andersen Experimental [Page 6]
|
||
|
||
RFC 3952 RTP Payload Format for iLBC Speech December 2004
|
||
|
||
|
||
It is important to observe that senders have the following additional
|
||
restrictions:
|
||
|
||
o SHOULD NOT include more iLBC frames in a single RTP packet than
|
||
will fit in the MTU of the RTP transport protocol.
|
||
|
||
o Frames MUST NOT be split between RTP packets.
|
||
|
||
o Frames of the different modes (20 ms and 30 ms) MUST NOT be
|
||
included within the same packet.
|
||
|
||
It is RECOMMENDED that the number of frames contained within an RTP
|
||
packet are consistent with the application. For example, in
|
||
telephony and other real time applications where delay is important,
|
||
the delay is lower depending on the amount of frames per packet
|
||
(i.e., fewer frames per packet, the lower the delay). Whereas for
|
||
bandwidth constrained links or delay insensitive streaming messaging
|
||
application, one or more frames per packet would be acceptable.
|
||
|
||
Information describing the number of frames contained in an RTP
|
||
packet is not transmitted as part of the RTP payload. The way to
|
||
determine the number of iLBC frames is to count the total number of
|
||
octets within the RTP packet, and divide the octet count by the
|
||
number of expected octets per frame (32/50 per frame).
|
||
|
||
4. IANA Considerations
|
||
|
||
One new MIME sub-type as described in this section has been
|
||
registered.
|
||
|
||
4.1. Storage Mode
|
||
|
||
The storage mode is used for storing speech frames (e.g., as a file
|
||
or email attachment).
|
||
|
||
+------------------+
|
||
| Header |
|
||
+------------------+
|
||
| Speech frame 1 |
|
||
+------------------+
|
||
: :
|
||
+------------------+
|
||
| Speech frame n |
|
||
+------------------+
|
||
|
||
Figure 2, Storage format diagram
|
||
|
||
|
||
|
||
|
||
|
||
Duric & Andersen Experimental [Page 7]
|
||
|
||
RFC 3952 RTP Payload Format for iLBC Speech December 2004
|
||
|
||
|
||
The file begins with a header that includes only a magic number to
|
||
identify that it is an iLBC file.
|
||
|
||
The magic number for iLBC file MUST correspond to the ASCII character
|
||
string:
|
||
|
||
o for 30 ms frame size mode:"#!iLBC30\n", or "0x23 0x21 0x69
|
||
0x4C 0x42 0x43 0x33 0x30 0x0A" in hexadecimal form,
|
||
|
||
o for 20 ms frame size mode:"#!iLBC20\n", or "0x23 0x21 0x69
|
||
0x4C 0x42 0x43 0x32 0x30 0x0A" in hexadecimal form.
|
||
|
||
After the header, follow the speech frames in consecutive order.
|
||
|
||
Speech frames lost in transmission MUST be stored as "empty frames",
|
||
as defined in [1].
|
||
|
||
4.2. MIME Registration of iLBC
|
||
|
||
MIME media type name: audio
|
||
|
||
MIME subtype: iLBC
|
||
|
||
Optional parameters:
|
||
|
||
All of the parameters does apply for RTP transfer only.
|
||
|
||
maxptime:The maximum amount of media which can be encapsulated in
|
||
each packet, expressed as time in milliseconds. The time
|
||
SHALL be calculated as the sum of the time the media present
|
||
in the packet represents. The time SHOULD be a multiple of
|
||
the frame size. This attribute is probably only meaningful
|
||
for audio data, but may be used with other media types if it
|
||
makes sense. It is a media attribute, and is not dependent
|
||
on charset. Note that this attribute was introduced after
|
||
RFC 2327, and non updated implementations will ignore this
|
||
attribute.
|
||
|
||
mode: The iLBC operating frame mode (20 or 30 ms) that will be
|
||
encapsulated in each packet. Values can be 0, 20 and 30
|
||
(where 0 is reserved, 20 stands for preferred 20 ms frame
|
||
size and 30 stands for preferred 30 ms frame size).
|
||
|
||
ptime: Defined as usual for RTP audio (see [5]).
|
||
|
||
Encoding considerations:
|
||
This type is defined for transfer via both RTP (RFC 3550)
|
||
and stored-file methods as described in Section 4.1, of RFC
|
||
|
||
|
||
|
||
Duric & Andersen Experimental [Page 8]
|
||
|
||
RFC 3952 RTP Payload Format for iLBC Speech December 2004
|
||
|
||
|
||
3952. Audio data is binary data, and must be encoded for
|
||
non-binary transport; the Base64 encoding is suitable for
|
||
email.
|
||
|
||
Security considerations:
|
||
See Section 6 of RFC 3952.
|
||
|
||
Public specification:
|
||
Please refer to RFC 3951 [1].
|
||
|
||
Additional information:
|
||
The following applies to stored-file transfer methods:
|
||
|
||
Magic number:
|
||
ASCII character string for:
|
||
o 30 ms frame size mode "#!iLBC30\n" (or 0x23 0x21
|
||
0x69 0x4C 0x42 0x43 0x33 0x30 0x0A in hexadecimal)
|
||
o 20 ms frame size mode "#!iLBC20\n" (or 0x23 0x21
|
||
0x69 0x4C 0x42 0x43 0x32 0x30 0x0A in hexadecimal)
|
||
|
||
File extensions: lbc, LBC
|
||
Macintosh file type code: none
|
||
Object identifier or OID: none
|
||
|
||
Person & email address to contact for further information:
|
||
alan.duric@telio.no
|
||
|
||
Intended usage: COMMON.
|
||
It is expected that many VoIP applications will use this
|
||
type.
|
||
|
||
Author/Change controller:
|
||
alan.duric@telio.no
|
||
IETF Audio/Video transport working group
|
||
|
||
5. Mapping To SDP Parameters
|
||
|
||
The information carried in the MIME media type specification has a
|
||
specific mapping to fields in the Session Description Protocol (SDP)
|
||
[5], which is commonly used to describe RTP sessions. When SDP is
|
||
used to specify sessions employing the iLBC codec, the mapping is as
|
||
follows:
|
||
|
||
o The MIME type ("audio") goes in SDP "m=" as the media name.
|
||
|
||
o The MIME subtype (payload format name) goes in SDP "a=rtpmap" as
|
||
the encoding name.
|
||
|
||
|
||
|
||
|
||
Duric & Andersen Experimental [Page 9]
|
||
|
||
RFC 3952 RTP Payload Format for iLBC Speech December 2004
|
||
|
||
|
||
o The parameters "ptime" and "maxptime" go in the SDP "a=ptime" and
|
||
"a=maxptime" attributes, respectively.
|
||
|
||
o The parameter "mode" goes in the SDP "a=fmtp" attribute by copying
|
||
it directly from the MIME media type string as "mode=value".
|
||
|
||
When conveying information by SDP, the encoding name SHALL be "iLBC"
|
||
(the same as the MIME subtype).
|
||
|
||
An example of the media representation in SDP for describing iLBC
|
||
might be:
|
||
|
||
m=audio 49120 RTP/AVP 97
|
||
a=rtpmap:97 iLBC/8000
|
||
|
||
If 20 ms frame size mode is used, remote iLBC encoder SHALL receive
|
||
"mode" parameter in the SDP "a=fmtp" attribute by copying them
|
||
directly from the MIME media type string as a semicolon separated
|
||
with parameter=value, where parameter is "mode", and values can be 0
|
||
and 20 (where 0 is reserved and 20 stands for preferred 20 ms frame
|
||
size). An example of the media representation in SDP for describing
|
||
iLBC when 20 ms frame size mode is used might be:
|
||
|
||
m=audio 49120 RTP/AVP 97
|
||
a=rtpmap:97 iLBC/8000
|
||
a=fmtp:97 mode=20
|
||
|
||
It is important to emphasize the bi-directional character of the
|
||
"mode" parameter - both sides of a bi-directional session MUST use
|
||
the same "mode" value.
|
||
|
||
The offer contains the preferred mode of the offerer. The answerer
|
||
may agree to that mode by including the same mode in the answer, or
|
||
may include a different mode. The resulting mode used by both
|
||
parties SHALL be the lower of the bandwidth modes in the offer and
|
||
answer.
|
||
|
||
That is, an offer of "mode=20" receiving an answer of "mode=30" will
|
||
result in "mode=30" being used by both participants. Similarly, an
|
||
offer of "mode=30" and an answer of "mode=20" will result in
|
||
"mode=30" being used by both participants.
|
||
|
||
This is important when one end point utilizes a bandwidth constrained
|
||
link (e.g., 28.8k modem link or slower), where only the lower frame
|
||
size will work.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Duric & Andersen Experimental [Page 10]
|
||
|
||
RFC 3952 RTP Payload Format for iLBC Speech December 2004
|
||
|
||
|
||
Parameter ptime can not be used for the purpose of specifying iLBC
|
||
operating mode, due to fact that for the certain values it will be
|
||
impossible to distinguish which mode is about to be used (e.g., when
|
||
ptime=60, it would be impossible to distinguish if packet is carrying
|
||
2 frames of 30 ms or 3 frames of 20 ms, etc.).
|
||
|
||
Note that the payload format (encoding) names are commonly shown in
|
||
upper case. MIME subtypes are commonly shown in lower case. These
|
||
names are case-insensitive in both places. Similarly, parameter
|
||
names are case-insensitive both in MIME types and in the default
|
||
mapping to the SDP a=fmtp attribute
|
||
|
||
6. Security Considerations
|
||
|
||
RTP packets using the payload format defined in this specification
|
||
are subject to the general security considerations discussed in [3]
|
||
and any appropriate profile (e.g., [4]).
|
||
|
||
As this format transports encoded speech, the main security issues
|
||
include confidentiality and authentication of the speech itself. The
|
||
payload format itself does not have any built-in security mechanisms.
|
||
Confidentiality of the media streams is achieved by encryption,
|
||
therefore external mechanisms, such as SRTP [6], MAY be used for that
|
||
purpose. The data compression used with this payload format is
|
||
applied end-to-end; hence encryption may be performed after
|
||
compression with no conflict between the two operations.
|
||
|
||
A potential denial-of-service threat exists for data encoding 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
|
||
become overloaded. However, the encodings covered in this document
|
||
do not exhibit any significant non-uniformity.
|
||
|
||
7. References
|
||
|
||
7.1. Normative References
|
||
|
||
[1] Andersen, S., Duric, A., Astrom, H., Hagen, R., Kleijn, W., and
|
||
J. Linden, "Internet Low Bit Rate Codec (iLBC)", RFC 3951,
|
||
December 2004.
|
||
|
||
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
|
||
Levels", BCP 14, RFC 2119, March 1997.
|
||
|
||
[3] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
|
||
"RTP: A Transport Protocol for Real-Time Applications", STD 64,
|
||
RFC 3550, July 2003.
|
||
|
||
|
||
|
||
Duric & Andersen Experimental [Page 11]
|
||
|
||
RFC 3952 RTP Payload Format for iLBC Speech December 2004
|
||
|
||
|
||
[4] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video
|
||
Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
|
||
|
||
[5] Handley, M. and V. Jacobson, "SDP: Session Description
|
||
Protocol", RFC 2327, April 1998.
|
||
|
||
[6] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
|
||
Norrman, "The Secure Real-time Transport Protocol", RFC 3711,
|
||
March 2004.
|
||
|
||
7.2. Informative References
|
||
|
||
[7] ITU-T Recommendation G.711, available online from the ITU
|
||
bookstore at http://www.itu.int.
|
||
|
||
8. Acknowledgements
|
||
|
||
Henry Sinnreich, Patrik Faltstrom, Alan Johnston and Jean-Francois
|
||
Mule for great support of the iLBC initiative and for valuable
|
||
feedback and comments.
|
||
|
||
Authors' Addresses
|
||
|
||
Alan Duric
|
||
Telio AS
|
||
Stoperigt. 2
|
||
Oslo, N-0250
|
||
Norway
|
||
|
||
Phone: +47 21673505
|
||
EMail: alan.duric@telio.no
|
||
|
||
|
||
Soren Vang Andersen
|
||
Department of Communication Technology
|
||
Aalborg University
|
||
Fredrik Bajers Vej 7A
|
||
9200 Aalborg
|
||
Denmark
|
||
|
||
Phone: ++45 9 6358627
|
||
EMail: sva@kom.auc.dk
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Duric & Andersen Experimental [Page 12]
|
||
|
||
RFC 3952 RTP Payload Format for iLBC Speech December 2004
|
||
|
||
|
||
Full Copyright Statement
|
||
|
||
Copyright (C) The Internet Society (2004).
|
||
|
||
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 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 IETF's procedures with respect to rights in IETF 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.
|
||
|
||
|
||
Acknowledgement
|
||
|
||
Funding for the RFC Editor function is currently provided by the
|
||
Internet Society.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Duric & Andersen Experimental [Page 13]
|
||
|