| d3R(147)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.4. Octet-aligned Mode
4.4.1. The Payload Header
In octet-aligned mode, the payload header consists of a 4 bit CMR, 4
reserved bits, and optionally, an 8 bit interleaving header, as shown
below:
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+- - - - - - - -
| CMR |R|R|R|R| ILL | ILP |
+-+-+-+-+-+-+-+-+- - - - - - - -
CMR (4 bits): same as defined in section 4.3.1.
R: is a reserved bit that MUST be set to zero. All R bits MUST be
ignored by the receiver.
ILL (4 bits, unsigned integer): This is an OPTIONAL field that is
present only if interleaving is signalled out-of-band for the
session. ILL=L indicates to the receiver that the interleaving
length is L+1, in number of frame-blocks.
ILP (4 bits, unsigned integer): This is an OPTIONAL field that is
present only if interleaving is signalled. ILP MUST take a value
between 0 and ILL, inclusive, indicating the interleaving index
for frame-blocks in this payload in the interleave group. If the
value of ILP is found greater than ILL, the payload SHOULD be
discarded.
ILL and ILP fields MUST be present in each packet in a session if
interleaving is signalled for the session. Interleaving MUST be
performed on a frame-block basis (i.e., NOT on a frame basis) in a
multi-channel session.
The following example illustrates the arrangement of speech frame-
blocks in an interleave group during an interleave session. Here we
assume ILL=L for the interleave group that starts at speech frame-
block n. We also assume that the first payload packet of the
interleave group is s and the number of speech frame-blocks carried
in each payload is N. Then we will have:
Payload s (the first packet of this interleave group):
ILL=L, ILP=0,
Carry frame-blocks: n, n+(L+1), n+2*(L+1), ..., n+(N-1)*(L+1)
Payload s+1 (the second packet of this interleave group):
ILL=L, ILP=1,
frame-blocks: n+1, n+1+(L+1), n+1+2*(L+1), ..., n+1+(N-1)*(L+1)
...
Payload s+L (the last packet of this interleave group):
ILL=L, ILP=L,
frame-blocks: n+L, n+L+(L+1), n+L+2*(L+1), ..., n+L+(N-1)*(L+1)
The next interleave group will start at frame-block n+N*(L+1).
There will be no interleaving effect unless the number of frame-
blocks per packet (N) is at least 2. Moreover, the number of frame-
blocks per payload (N) and the value of ILL MUST NOT be changed
inside an interleave group. In other words, all payloads in an
interleave group MUST have the same ILL and MUST contain the same
number of speech frame-blocks.
The sender of the payload MUST only apply interleaving if the
receiver has signalled its use through out-of-band means. Since
interleaving will increase buffering requirements at the receiver,
the receiver uses MIME parameter "interleaving=I" to set the maximum
number of frame-blocks allowed in an interleaving group to I.
When performing interleaving the sender MUST use a proper number of
frame-blocks per payload (N) and ILL so that the resulting size of an
interleave group is less or equal to I, i.e., N*(L+1)<=I.
4.4.2. The Payload Table of Contents and Frame CRCs
The table of contents (ToC) in octet-aligned mode consists of a list
of ToC entries where each entry corresponds to a speech frame carried
in the payload and, optionally, a list of speech frame CRCs, i.e.,
+---------------------+
| list of ToC entries |
+---------------------+
| list of frame CRCs | (optional)
- - - - - - - - - - -
Note, for ToC entries with FT=14 or 15, there will be no
corresponding speech frame or frame CRC present in the payload.
The list of ToC entries is organized in the same way as described for
bandwidth-efficient mode in 4.3.2, with the following exception; when
interleaving is used the frame-blocks in the ToC will almost never be
placed consecutive in time. Instead, the presence and order of the
frame-blocks in a packet will follow the pattern described in 4.4.1.
The following example shows the ToC of three consecutive packets,
each carrying 3 frame-blocks, in an interleaved two-channel session.
Here, the two channels are left (L) and right (R) with L coming
before R, and the interleaving length is 3 (i.e., ILL=2). This makes
the interleave group 9 frame-blocks large.
Packet #1
---------
ILL=2, ILP=0:
+----+----+----+----+----+----+
| 1L | 1R | 4L | 4R | 7L | 7R |
+----+----+----+----+----+----+
|<------->|<------->|<------->|
Frame- Frame- Frame-
Block 1 Block 4 Block 7
Packet #2
---------
ILL=2, ILP=1:
+----+----+----+----+----+----+
| 2L | 2R | 5L | 5R | 8L | 8R |
+----+----+----+----+----+----+
|<------->|<------->|<------->|
Frame- Frame- Frame-
Block 2 Block 5 Block 8
Packet #3
---------
ILL=2, ILP=2:
+----+----+----+----+----+----+
| 3L | 3R | 6L | 6R | 9L | 9R |
+----+----+----+----+----+----+
|<------->|<------->|<------->|
Frame- Frame- Frame-
Block 3 Block 6 Block 9
A ToC entry takes the following format in octet-aligned mode:
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|F| FT |Q|P|P|
+-+-+-+-+-+-+-+-+
F (1 bit): see definition in Section 4.3.2.
FT (4 bits unsigned integer): see definition in Section 4.3.2.
Q (1 bit): see definition in Section 4.3.2.
P bits: padding bits, MUST be set to zero.
The list of CRCs is OPTIONAL. It only exists if the use of CRC is
signalled out-of-band for the session. When present, each CRC in the
list is 8 bit long and corresponds to a speech frame (NOT a frame-
block) carried in the payload. Calculation and use of the CRC is
specified in the next section.
4.4.2.1. Use of Frame CRC for UED over IP
The general concept of UED/UEP over IP is discussed in Section 3.6.
This section provides more details on how to use the frame CRC in the
octet-aligned payload header together with a partial transport layer
checksum to achieve UED.
To achieve UED, one SHOULD use a transport layer checksum, for
example, the one defined in UDP-Lite [15], to protect the RTP header,
payload header, and table of contents bits in a payload. The frame
CRC, when used, MUST be calculated only over all class A bits in the
frame. Class B and C bits in the frame MUST NOT be included in the
CRC calculation and SHOULD NOT be covered by the transport checksum.
Note, the number of class A bits for various coding modes in AMR
codec is specified as informative in [2] and is therefore copied
into Table 1 in Section 3.6 to make it normative for this payload
format. The number of class A bits for various coding modes in
AMR-WB codec is specified as normative in table 2 in [4], and the
SID frame (FT=9) has 40 class A bits. These definitions of class
A bits MUST be used for this payload format.
Packets SHOULD be discarded if the transport layer checksum detects
errors.
The receiver of the payload SHOULD examine the data integrity of the
received class A bits by re-calculating the CRC over the received
class A bits and comparing the result to the value found in the
received payload header. If the two values mismatch, the receiver
SHALL consider the class A bits in the receiver frame damaged and
MUST clear the Q flag of the frame (i.e., set it to 0). This will
subsequently cause the frame to be marked as SPEECH_BAD, if the FT of
the frame is 0..7 for AMR or 0..8 for AMR-WB, or SID_BAD if the FT of
the frame is 8 for AMR or 9 for AMR-WB, before it is passed to the
speech decoder. See [6] and [7] more details.
The following example shows an octet-aligned ToC with a CRC list for
a payload containing 3 speech frames from a single channel session
(assuming none of the FTs is equal to 14 or 15):
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| FT#1 |Q|P|P|1| FT#2 |Q|P|P|0| FT#3 |Q|P|P| CRC#1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CRC#2 | CRC#3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Each of the CRC's takes 8 bits
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| c0| c1| c2| c3| c4| c5| c6| c7|
+---+---+---+---+---+---+---+---+
and is calculated by the cyclic generator polynomial,
C(x) = 1 + x^2 + x^3 + x^4 + x^8
where ^ is the exponentiation operator.
In binary form the polynomial has the following form: 101110001
(MSB..LSB).
The actual calculation of the CRC is made as follows: First, an 8-
bit CRC register is reset to zero: 00000000. For each bit over which
the CRC shall be calculated, an XOR operation is made between the
rightmost bit of the CRC register and the bit. The CRC register is
then right shifted one step (inputting a "0" as the leftmost bit).
If the result of the XOR operation mentioned above is a "1"
"10111000" is then bit-wise XOR-ed into the CRC register. This
operation is repeated for each bit that the CRC should cover. In
this case, the first bit would be d(0) for the speech frame for which
the CRC should cover. When the last bit (e.g., d(54) for AMR 5.9
according to Table 1 in Section 3.6) have been used in this CRC
calculation, the contents in CRC register should simply be copied to
the corresponding field in the list of CRC's.
Fast calculation of the CRC on a general-purpose CPU is possible
using a table-driven algorithm.
4.4.3. Speech Data
In octet-aligned mode, speech data is carried in a similar way to
that in the bandwidth-efficient mode as discussed in Section 4.3.3,
with the following exceptions:
- The last octet of each speech frame MUST be padded with zeroes
at the end if not all bits in the octet are used. In other
words, each speech frame MUST be octet-aligned.
- When multiple speech frames are present in the speech data
(i.e., compound payload), the speech frames can be arranged
either one whole frame after another as usual, or with the
octets of all frames interleaved together at the octet level.
Since the bits within each frame are ordered with the most
error-sensitive bits first, interleaving the octets collects
those sensitive bits from all frames to be nearer the beginning
of the packet. This is called "robust sorting order" which
allows the application of UED (such as UDP-Lite [15]) or UEP
(such as the ULP [18]) mechanisms to the payload data. The
details of assembling the payload are given in the next
section.
The use of robust sorting order for a session MUST be agreed via
out-of-band means. Section 8 specifies a MIME parameter for this
purpose.
Note, robust sorting order MUST only be performed on the frame level
and thus is independent of interleaving which is at the frame-block
level, as described in Section 4.4.1. In other words, robust sorting
can be applied to either non-interleaved or interleaved sessions.
4.4.4. Methods for Forming the Payload
Two different packetization methods, namely normal order and robust
sorting order, exist for forming a payload in octet-aligned mode. In
both cases, the payload header and table of contents are packed into
the payload the same way; the difference is in the packing of the
speech frames.
The payload begins with the payload header of one octet or two if
frame interleaving is selected. The payload header is followed by
the table of contents consisting of a list of one-octet ToC entries.
If frame CRCs are to be included, they follow the table of contents
with one 8-bit CRC filling each octet. Note that if a given frame
has a ToC entry with FT=14 or 15, there will be no CRC present.
The speech data follows the table of contents, or the CRCs if
present. For packetization in the normal order, all of the octets
comprising a speech frame are appended to the payload as a unit. The
speech frames are packed in the same order as their corresponding ToC
entries are arranged in the ToC list, with the exception that if a
given frame has a ToC entry with FT=14 or 15, there will be no data
octets present for that frame.
For packetization in robust sorting order, the octets of all speech
frames are interleaved together at the octet level. That is, the
data portion of the payload begins with the first octet of the first
frame, followed by the first octet of the second frame, then the
first octet of the third frame, and so on. After the first octet of
the last frame has been appended, the cycle repeats with the second
octet of each frame. The process continues for as many octets as are
present in the longest frame. If the frames are not all the same
octet length, a shorter frame is skipped once all octets in it have
been appended. The order of the frames in the cycle will be
sequential if frame interleaving is not in use, or according to the
interleave pattern specified in the payload header if frame
interleaving is in use. Note that if a given frame has a ToC entry
with FT=14 or 15, there will be no data octets present for that frame
so that frame is skipped in the robust sorting cycle.
The UED and/or UEP is RECOMMENDED to cover at least the RTP header,
payload header, table of contents, and class A bits of a sorted
payload. Exactly how many octets need to be covered depends on the
network and application. If CRCs are used together with robust
sorting, only the RTP header, the payload header, and the ToC SHOULD
be covered by UED/UEP. The means to communicate to other layers
performing UED/UEP the number of octets to be covered is beyond the
scope of this specification.
4.4.5. Payload Examples
4.4.5.1. Basic Single Channel Payload Carrying Multiple Frames
The following diagram shows an octet aligned payload from a single
channel session that carries two AMR frames of 7.95 kbps coding mode
(FT=5). In the payload, a codec mode request is sent (CMR=6),
requesting the encoder at the receiver's side to use AMR 10.2 kbps
coding mode. No frame CRC, interleaving, or robust-sorting is in
use.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CMR=6 |R|R|R|R|1|FT#1=5 |Q|P|P|0|FT#2=5 |Q|P|P| f1(0..7) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| f1(8..15) | f1(16..23) | .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |f1(152..158) |P| f2(0..7) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| f2(8..15) | f2(16..23) | .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |f2(152..158) |P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note, in above example the last octet in both speech frames is padded
with one 0 to make it octet-aligned.
4.4.5.2. Two Channel Payload with CRC, Interleaving, and Robust-sorting
This example shows an octet aligned payload from a two channel
session. Two frame-blocks, each containing 2 speech frames of 7.95
kbps coding mode (FT=5), are carried in this payload,
The two channels are left (L) and right (R) with L coming before R.
In the payload, a codec mode request is also sent (CMR=6), requesting
the encoder at the receiver's side to use AMR 10.2 kbps coding mode.
Moreover, frame CRC and frame-block interleaving are both enabled for
the session. The interleaving length is 2 (ILL=1) and this payload
is the first one in an interleave group (ILP=0).
The first two frames in the payload are the L and R channel speech
frames of frame-block #1, consisting of bits f1L(0..158) and
f1R(0..158), respectively. The next two frames are the L and R
channel frames of frame-block #3, consisting of bits f3L(0..158) and
f3R(0..158), respectively, due to interleaving. For each of the four
speech frames a CRC is calculated as CRC1L(0..7), CRC1R(0..7),
CRC3L(0..7), and CRC3R(0..7), respectively. Finally, the payload is
robust sorted.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CMR=6 |R|R|R|R| ILL=1 | ILP=0 |1|FT#1L=5|Q|P|P|1|FT#1R=5|Q|P|P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|FT#3L=5|Q|P|P|0|FT#3R=5|Q|P|P| CRC1L | CRC1R |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CRC3L | CRC3R | f1L(0..7) | f1R(0..7) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| f3L(0..7) | f3R(0..7) | f1L(8..15) | f1R(8..15) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| f3L(8..15) | f3R(8..15) | f1L(16..23) | f1R(16..23) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| f3L(144..151) | f3R(144..151) |f1L(152..158)|P|f1R(152..158)|P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|f3L(152..158)|P|f3R(152..158)|P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note, in above example the last octet in all the four speech frames
is padded with one zero bit to make it octet-aligned.
4.5. Implementation Considerations
An application implementing this payload format MUST understand all
the payload parameters in the out-of-band signaling used. For
example, if an application uses SDP, all the SDP and MIME parameters
in this document MUST be understood. This requirement ensures that
an implementation always can decide if it is capable or not of
communicating.
No operation mode of the payload format is mandatory to implement.
The requirements of the application using the payload format should
be used to determine what to implement. To achieve basic
interoperability an implementation SHOULD at least implement both
bandwidth-efficient and octet-aligned mode for single channel. The
other operations mode: interleaving, robust sorting, frame-wise CRC
in both single and multi-channel is OPTIONAL to implement.
5. AMR and AMR-WB Storage Format
The storage format is used for storing AMR or AMR-WB speech frames in
a file or as an e-mail attachment. Multiple channel content is
supported.
In general, an AMR or AMR-WB file has the following structure:
+------------------+
| Header |
+------------------+
| Speech frame 1 |
+------------------+
: ... :
+------------------+
| Speech frame n |
+------------------+
Note, to preserve interoperability with already deployed
implementations, single channel content uses a file header format
different from that of multi-channel content.
5.1. Single channel Header
A single channel AMR or AMR-WB file header contains only a magic
number and different magic numbers are defined to distinguish AMR
from AMR-WB.
The magic number for single channel AMR files MUST consist of ASCII
character string:
"#!AMR\n"
(or 0x2321414d520a in hexadecimal).
The magic number for single channel AMR-WB files MUST consist of
ASCII character string:
"#!AMR-WB\n"
(or 0x2321414d522d57420a in hexadecimal).
Note, the "\n" is an important part of the magic numbers and MUST be
included in the comparison, since, otherwise, the single channel
magic numbers above will become indistinguishable from those of the
multi-channel files defined in the next section.
5.2. Multi-channel Header
The multi-channel header consists of a magic number followed by a 32
bit channel description field, giving the multi-channel header the
following structure:
+------------------+
| magic number |
+------------------+
| chan-desc field |
+------------------+
The magic number for multi-channel AMR files MUST consist of the
ASCII character string:
"#!AMR_MC1.0\n"
(or 0x2321414d525F4D43312E300a in hexadecimal).
The magic number for multi-channel AMR-WB files MUST consist of the
ASCII character string:
"#!AMR-WB_MC1.0\n"
(or 0x2321414d522d57425F4D43312E300a in hexadecimal).
The version number in the magic numbers refers to the version of the
file format.
The 32 bit channel description field is defined as:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved bits | CHAN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved bits: MUST be set to 0 when written, and a reader MUST
ignore them.
CHAN (4 bit unsigned integer): Indicates the number of audio channels
contained in this storage file. The valid values and the order of
the channels within a frame block are specified in Section 4.1 in
[24].
5.3. Speech Frames
After the file header, speech frame-blocks consecutive in time are
stored in the file. Each frame-block contains a number of octet-
aligned speech frames equal to the number of channels, and stored in
increasing order, starting with channel 1.
Each stored speech frame starts with a one octet frame header with
the following format:
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|P| FT |Q|P|P|
+-+-+-+-+-+-+-+-+
The FT field and the Q bit are defined in the same way as in Section
4.1.2. The P bits are padding and MUST be set to 0.
Following this one octet header come the speech bits as defined in
4.3.3. The last octet of each frame is padded with zeroes, if
needed, to achieve octet alignment.
The following example shows an AMR frame in 5.9 kbit coding mode
(with 118 speech bits) in the storage format.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|P| FT=2 |Q|P|P| |
+-+-+-+-+-+-+-+-+ +
| |
+ Speech bits for frame-block n, channel k +
| |
+ +-+-+
| |P|P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Frame-blocks or speech frames lost in transmission and non-received
frame-blocks between SID updates during non-speech periods MUST be
stored as NO_DATA frames (frame type 15, as defined in [2] and [4])
or SPEECH_LOST (frame type 14, only available for AMR-WB) in complete
frame-blocks to keep synchronization with the original media.
6. Congestion Control
The general congestion control considerations for transporting RTP
data apply to AMR or AMR-WB speech over RTP as well. However, the
multi-rate capability of AMR and AMR-WB speech coding may provide an
advantage over other payload formats for controlling congestion since
the bandwidth demand can be adjusted by selecting a different coding
mode.
Another parameter that may impact the bandwidth demand for AMR and
AMR-WB is the number of frame-blocks that are encapsulated in each
RTP payload. Packing more frame-blocks in each RTP payload can
reduce the number of packets sent and hence the overhead from
IP/UDP/RTP headers, at the expense of increased delay.
If forward error correction (FEC) is used to combat packet loss, the
amount of redundancy added by FEC will need to be regulated so that
the use of FEC itself does not cause a congestion problem.
It is RECOMMENDED that AMR or AMR-WB applications using this payload
format employ congestion control. The actual mechanism for
congestion control is not specified but should be suitable for real-
time flows, e.g., "Equation-Based Congestion Control for Unicast
Applications" [17].
7. Security Considerations
RTP packets using the payload format defined in this specification
are subject to the general security considerations discussed in [8].
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.
External mechanisms, such as SRTP [22], MAY be used.
This payload format does not exhibit any significant non-uniformity
in the receiver side computational complexity for packet processing
and thus is unlikely to pose a denial-of-service threat due to the
receipt of pathological data.
7.1. Confidentiality
To achieve confidentiality of the encoded AMR or AMR-WB speech, all
speech data bits will need to be encrypted. There is less a need to
encrypt the payload header or the table of contents due to 1) that
they only carry information about the requested speech mode, frame
type, and frame quality, and 2) that this information could be useful
to some third party, e.g., quality monitoring.
As long as the AMR or AMR-WB payload is only packed and unpacked at
either end, encryption may be performed after packet encapsulation so
that there is no conflict between the two operations.
Interleaving may affect encryption. Depending on the encryption
scheme used, there may be restrictions on, for example, the time when
keys can be changed. Specifically, the key change may need to occur
at the boundary between interleave groups.
The type of encryption method used may impact the error robustness of
the payload data. The error robustness may be severely reduced when
the data is encrypted unless an encryption method without error-
propagation is used, e.g., a stream cipher. Therefore, UED/UEP based
on robust sorting may be difficult to apply when the payload data is
encrypted.
7.2. Authentication
To authenticate the sender of the speech, an external mechanism has
to be used. It is RECOMMENDED that such a mechanism protect all the
speech data bits. Note that the use of UED/UEP may be difficult to
combine with authentication because any bit errors will cause
authentication to fail.
Data tampering by a man-in-the-middle attacker could result in
erroneous depacketization/decoding that could lower the speech
quality. Tampering with the CMR field may result in speech in a
different quality than desired.
To prevent a man-in-the-middle attacker from tampering with the
payload packets, some additional information besides the speech bits
SHOULD be protected. This may include the payload header, ToC, frame
CRCs, RTP timestamp, RTP sequence number, and the RTP marker bit.
7.3. Decoding Validation
When processing a received payload packet, if the receiver finds that
the calculated payload length, based on the information of the
session and the values found in the payload header fields, does not
match the size of the received packet, the receiver SHOULD discard
the packet. This is because decoding a packet that has errors in its
length field could severely degrade the speech quality.
8. Payload Format Parameters
This section defines the parameters that may be used to select
optional features of the AMR and AMR-WB payload formats. The
parameters are defined here as part of the MIME subtype registrations
for the AMR and AMR-WB speech codecs. A mapping of the parameters
into the Session Description Protocol (SDP) [11] is also provided for
those applications that use SDP. Equivalent parameters could be
defined elsewhere for use with control protocols that do not use MIME
or SDP.
Two separate MIME registrations are made, one for AMR and one for
AMR-WB, because they are distinct encodings that must be
distinguished by the MIME subtype.
The data format and parameters are specified for both real-time
transport in RTP and for storage type applications such as e-mail
attachments.
8.1. AMR MIME Registration
The MIME subtype for the Adaptive Multi-Rate (AMR) codec is allocated
from the IETF tree since AMR is expected to be a widely used speech
codec in general VoIP applications. This MIME registration covers
both real-time transfer via RTP and non-real-time transfers via
stored files.
Note, any unspecified parameter MUST be ignored by the receiver.
Media Type name: audio
Media subtype name: AMR
Required parameters: none
Optional parameters:
These parameters apply to RTP transfer only.
octet-align: Permissible values are 0 and 1. If 1, octet-aligned
operation SHALL be used. If 0 or if not present,
bandwidth efficient operation is employed.
mode-set: Requested AMR mode set. Restricts the active codec
mode set to a subset of all modes. Possible values are a
comma separated list of modes from the set: 0,...,7 (see
Table 1a [2]). If such mode set is specified by the
decoder, the encoder MUST abide by the request and MUST
NOT use modes outside of the subset. If not present, all
codec modes are allowed for the session.
mode-change-period: Specifies a number of frame-blocks, N, that is
the interval at which codec mode changes are allowed.
The initial phase of the interval is arbitrary, but
changes must be separated by multiples of N frame-blocks.
If this parameter is not present, mode changes are
allowed at any time during the session.
mode-change-neighbor: Permissible values are 0 and 1. If 1, mode
changes SHALL only be made to the neighboring modes in
the active codec mode set. Neighboring modes are the
ones closest in bit rate to the current mode, either the
next higher or next lower rate. If 0 or if not present,
change between any two modes in the active codec mode set
is allowed.
maxptime: The maximum amount of media which can be encapsulated
in a payload packet, expressed as time in milliseconds.
The time is calculated as the sum of the time the media
present in the packet represents. The time SHOULD be a
multiple of the frame size. If this parameter is not
present, the sender MAY encapsulate any number of speech
frames into one RTP packet.
crc: Permissible values are 0 and 1. If 1, frame CRCs SHALL be
included in the payload, otherwise not. If crc=1, this
also implies automatically that octet-aligned operation
SHALL be used for the session.
robust-sorting: Permissible values are 0 and 1. If 1, the payload
SHALL employ robust payload sorting. If 0 or if not
present, simple payload sorting SHALL be used. If
robust-sorting=1, this also implies automatically that
octet-aligned operation SHALL be used for the session.
interleaving: Indicates that frame-block level interleaving SHALL
be used for the session and its value defines the maximum
number of frame-blocks allowed in an interleaving group
(see Section 4.4.1). If this parameter is not present,
interleaving SHALL not be used. The presence of this
parameter also implies automatically that octet-aligned
operation SHALL be used.
ptime: see RFC2327 [11].
channels: The number of audio channels. The possible values and
their respective channel order is specified in section
4.1 in [24]. If omitted it has the default value of 1.
Encoding considerations:
This type is defined for transfer via both RTP (RFC1889)
and stored-file methods as described in Sections 4 and 5,
respectively, of RFC3267. Audio data is binary data,
and must be encoded for non-binary transport; the Base64
encoding is suitable for Email.
Security considerations:
See Section 7 of RFC3267.
Public specification:
Please refer to Section 11 of RFC3267.
Additional information:
The following applies to stored-file transfer methods:
Magic numbers:
single channel:
ASCII character string "#!AMR\n"
(or 0x2321414d520a in hexadecimal)
multi-channel:
ASCII character string "#!AMR_MC1.0\n"
(or 0x2321414d525F4D43312E300a in hexadecimal)
File extensions: amr, AMR
Macintosh file type code: none
Object identifier or OID: none
Person & email address to contact for further information:
johan.sjoberg@ericsson.com
ari.lakaniemi@nokia.com
Intended usage: COMMON.
It is expected that many VoIP applications (as well as
mobile applications) will use this type.
Author/Change controller:
johan.sjoberg@ericsson.com
ari.lakaniemi@nokia.com
IETF Audio/Video transport working group
8.2. AMR-WB MIME Registration
The MIME subtype for the Adaptive Multi-Rate Wideband (AMR-WB) codec
is allocated from the IETF tree since AMR-WB is expected to be a
widely used speech codec in general VoIP applications. This MIME
registration covers both real-time transfer via RTP and non-real-time
transfers via stored files.
Note, any unspecified parameter MUST be ignored by the receiver.
Media Type name: audio
Media subtype name: AMR-WB
Required parameters: none
Optional parameters:
These parameters apply to RTP transfer only.
octet-align: Permissible values are 0 and 1. If 1, octet-aligned
operation SHALL be used. If 0 or if not present,
bandwidth efficient operation is employed.
mode-set: Requested AMR-WB mode set. Restricts the active codec
mode set to a subset of all modes. Possible values are a
comma separated list of modes from the set: 0,...,8 (see
Table 1a [4]). If such mode set is specified by the
decoder, the encoder MUST abide by the request and MUST
NOT use modes outside of the subset. If not present, all
codec modes are allowed for the session.
mode-change-period: Specifies a number of frame-blocks, N, that is
the interval at which codec mode changes are allowed.
The initial phase of the interval is arbitrary, but
changes must be separated by multiples of N frame-blocks.
If this parameter is not present, mode changes are
allowed at any time during the session.
mode-change-neighbor: Permissible values are 0 and 1. If 1, mode
changes SHALL only be made to the neighboring modes in
the active codec mode set. Neighboring modes are the
ones closest in bit rate to the current mode, either the
next higher or next lower rate. If 0 or if not present,
change between any two modes in the active codec mode set
is allowed.
maxptime: The maximum amount of media which can be encapsulated
in a payload packet, expressed as time in milliseconds.
The time is calculated as the sum of the time the media
present in the packet represents. The time SHOULD be a
multiple of the frame size. If this parameter is not
present, the sender MAY encapsulate any number of speech
frames into one RTP packet.
crc: Permissible values are 0 and 1. If 1, frame CRCs SHALL be
included in the payload, otherwise not. If crc=1, this
also implies automatically that octet-aligned operation
SHALL be used for the session.
robust-sorting: Permissible values are 0 and 1. If 1, the payload
SHALL employ robust payload sorting. If 0 or if not
present, simple payload sorting SHALL be used. If
robust-sorting=1, this also implies automatically that
octet-aligned operation SHALL be used for the session.
interleaving: Indicates that frame-block level interleaving SHALL
be used for the session and its value defines the maximum
number of frame-blocks allowed in an interleaving group
(see Section 4.4.1). If this parameter is not present,
interleaving SHALL not be used. The presence of this
parameter also implies automatically that octet-aligned
operation SHALL be used.
ptime: see RFC2327 [11].
channels: The number of audio channels. The possible values and
their respective channel order is specified in section
4.1 in [24]. If omitted it has the default value of 1.
Encoding considerations:
This type is defined for transfer via both RTP (RFC1889)
and stored-file methods as described in Sections 4 and 5,
respectively, of RFC3267. Audio data is binary data,
and must be encoded for non-binary transport; the Base64
encoding is suitable for Email.
Security considerations:
See Section 7 of RFC3267.
Public specification:
Please refer to Section 11 of RFC3267.
Additional information:
The following applies to stored-file transfer methods:
Magic numbers:
single channel:
ASCII character string "#!AMR-WB\n"
(or 0x2321414d522d57420a in hexadecimal)
multi-channel:
ASCII character string "#!AMR-WB_MC1.0\n"
(or 0x2321414d522d57425F4D43312E300a in hexadecimal)
File extensions: awb, AWB
Macintosh file type code: none
Object identifier or OID: none
Person & email address to contact for further information:
johan.sjoberg@ericsson.com
ari.lakaniemi@nokia.com
Intended usage: COMMON.
It is expected that many VoIP applications (as well as
mobile applications) will use this type.
Author/Change controller:
johan.sjoberg@ericsson.com
ari.lakaniemi@nokia.com
IETF Audio/Video transport working group
8.3. Mapping MIME Parameters into SDP
The information carried in the MIME media type specification has a
specific mapping to fields in the Session Description Protocol (SDP)
[11], which is commonly used to describe RTP sessions. When SDP is
used to specify sessions employing the AMR or AMR-WB codec, the
mapping is as follows:
- The MIME type ("audio") goes in SDP "m=" as the media name.
- The MIME subtype (payload format name) goes in SDP "a=rtpmap"
as the encoding name. The RTP clock rate in "a=rtpmap" MUST be
8000 for AMR and 16000 for AMR-WB, and the encoding parameters
(number of channels) MUST either be explicitly set to N or
omitted, implying a default value of 1. The values of N that
are allowed is specified in Section 4.1 in [24].
- The parameters "ptime" and "maxptime" go in the SDP "a=ptime"
and "a=maxptime" attributes, respectively.
- Any remaining parameters go in the SDP "a=fmtp" attribute by
copying them directly from the MIME media type string as a
semicolon separated list of parameter=value pairs.
Some example SDP session descriptions utilizing AMR and AMR-WB
encodings follow. In these examples, long a=fmtp lines are folded to
meet the column width constraints of this document; the backslash
("\") at the end of a line and the carriage return that follows it
should be ignored.
Example of usage of AMR in a possible GSM gateway scenario:
m=audio 49120 RTP/AVP 97
a=rtpmap:97 AMR/8000/1
a=fmtp:97 mode-set=0,2,5,7; mode-change-period=2; \
mode-change-neighbor=1
a=maxptime:20
Example of usage of AMR-WB in a possible VoIP scenario:
m=audio 49120 RTP/AVP 98
a=rtpmap:98 AMR-WB/16000
a=fmtp:98 octet-align=1
Example of usage of AMR-WB in a possible streaming scenario (two
channel stereo):
m=audio 49120 RTP/AVP 99
a=rtpmap:99 AMR-WB/16000/2
a=fmtp:99 interleaving=30
a=maxptime:100
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.
9. IANA Considerations
Two new MIME subtypes have been registered, see Section 8. A new SDP
attribute "maxptime", defined in Section 8, has also been registered.
The "maxptime" attribute is expected to be defined in the revision of
RFC2327 [11] and is added here with a consistent definition.
10. Acknowledgements
The authors would like to thank Petri Koskelainen, Bernhard Wimmer,
Tim Fingscheidt, Sanjay Gupta, Stephen Casner, and Colin Perkins for
their significant contributions made throughout the writing and
reviewing of this document.
11. References
[1] 3GPP TS 26.090, "Adaptive Multi-Rate (AMR) speech transcoding",
version 4.0.0 (2001-03), 3rd Generation Partnership Project
(3GPP).
[2] 3GPP TS 26.101, "AMR Speech Codec Frame Structure", version
4.1.0 (2001-06), 3rd Generation Partnership Project (3GPP).
[3] 3GPP TS 26.190 "AMR Wideband speech codec; Transcoding
functions", version 5.0.0 (2001-03), 3rd Generation Partnership
Project (3GPP).
[4] 3GPP TS 26.201 "AMR Wideband speech codec; Frame Structure",
version 5.0.0 (2001-03), 3rd Generation Partnership Project
(3GPP).
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC2119, March 1997.
[6] 3GPP TS 26.093, "AMR Speech Codec; Source Controlled Rate
operation", version 4.0.0 (2000-12), 3rd Generation Partnership
Project (3GPP).
[7] 3GPP TS 26.193 "AMR Wideband Speech Codec; Source Controlled
Rate operation", version 5.0.0 (2001-03), 3rd Generation
Partnership Project (3GPP).
[8] Schulzrinne, H, Casner, S., Frederick, R. and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", RFC
1889, January 1996.
[9] 3GPP TS 26.092, "AMR Speech Codec; Comfort noise aspects",
version 4.0.0 (2001-03), 3rd Generation Partnership Project
(3GPP).
[10] 3GPP TS 26.192 "AMR Wideband speech codec; Comfort Noise
aspects", version 5.0.0 (2001-03), 3rd Generation Partnership
Project (3GPP).
[11] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC2327, April 1998.
[24] Schulzrinne, H., "RTP Profile for Audio and Video Conferences
with Minimal Control" RFC1890, January 1996.
11.1 Informative References
[12] GSM 06.60, "Enhanced Full Rate (EFR) speech transcoding",
version 8.0.1 (2000-11), European Telecommunications Standards
Institute (ETSI).
[13] ANSI/TIA/EIA-136-Rev.C, part 410 - "TDMA Cellular/PCS - Radio
Interface, Enhanced Full Rate Voice Codec (ACELP)." Formerly
IS-641. TIA published standard, June 1 2001.
[14] ARIB, RCR STD-27H, "Personal Digital Cellular Telecommunication
System RCR Standard", Association of Radio Industries and
Businesses (ARIB).
[15] Larzon, L., Degermark, M. and S. Pink, "The UDP Lite Protocol",
Work in Progress.
[16] 3GPP TS 25.415 "UTRAN Iu Interface User Plane Protocols",
version 4.2.0 (2001-09), 3rd Generation Partnership Project
(3GPP).
[17] S. Floyd, M. Handley, J. Padhye, J. Widmer, "Equation-Based
Congestion Control for Unicast Applications", ACM SIGCOMM 2000,
Stockholm, Sweden .
[18] Li, A., et. al., "An RTP Payload Format for Generic FEC with
Uneven Level Protection", Work in Progress.
[19] Rosenberg, J. and H. Schulzrinne, "An RTP Payload Format for
Generic Forward Error Correction", RFC2733, December 1999.
[20] 3GPP TS 26.102, "AMR speech codec interface to Iu and Uu",
version 4.0.0 (2001-03), 3rd Generation Partnership Project
(3GPP).
[21] 3GPP TS 26.202 "AMR Wideband speech codec; Interface to Iu and
Uu", version 5.0.0 (2001-03), 3rd Generation Partnership
Project (3GPP).
[22] Baugher, et. al., "The Secure Real Time Transport Protocol",
Work in Progress.
[23] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., Handley,
M., Bolot, J., Vega-Garcia, A. and S. Fosse-Parisis, "RTP
Payload for Redundant Audio Data", RFC2198, September 1997.
ETSI documents can be downloaded from the ETSI web server,
"http://www.etsi.org/". Any 3GPP document can be downloaded from the
3GPP webserver, "http://www.3gpp.org/", see specifications. TIA
documents can be obtained from "www.tiaonline.org".
12. Authors' Addresses
Johan Sjoberg
Ericsson Research
Ericsson AB
SE-164 80 Stockholm, SWEDEN
Phone: +46 8 50878230
EMail: Johan.Sjoberg@ericsson.com
Magnus Westerlund
Ericsson Research
Ericsson AB
SE-164 80 Stockholm, SWEDEN
Phone: +46 8 4048287
EMail: Magnus.Westerlund@ericsson.com
Ari Lakaniemi
Nokia Research Center
P.O.Box 407
FIN-00045 Nokia Group, FINLAND
Phone: +358-71-8008000
EMail: ari.lakaniemi@nokia.com
Qiaobing Xie
Motorola, Inc.
1501 W. Shure Drive, 2-B8
Arlington Heights, IL 60004, USA
Phone: +1-847-632-3028
EMail: qxie1@email.mot.com
13. Full Copyright Statement
Copyright (C) The Internet Society (2002). 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 RFCEditor function is currently provided by the
Internet Society.