Request for Comments: 3267 M. Westerlund
Category: Standards Track Ericsson
A. Lakaniemi
Nokia
Q. Xie
Motorola
June 2002
Real-Time Transport Protocol (RTP) Payload Format and File Storage
Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate
Wideband (AMR-WB) Audio Codecs
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract
This document specifies a real-time transport protocol (RTP) payload
format to be used for Adaptive Multi-Rate (AMR) and Adaptive Multi-
Rate Wideband (AMR-WB) encoded speech signals. The payload format is
designed to be able to interoperate with existing AMR and AMR-WB
transport formats on non-IP networks. In addition, a file format is
specified for transport of AMR and AMR-WB speech data in storage mode
applications such as email. Two separate MIME type registrations are
included, one for AMR and one for AMR-WB, specifying use of both the
RTP payload format and the storage format.
Table of Contents
1. Introduction.................................................... 3
2. Conventions and Acronyms........................................ 3
3. Background on AMR/AMR-WB and Design Principles.................. 4
3.1. The Adaptive Multi-Rate (AMR) Speech Codec.................. 4
3.2. The Adaptive Multi-Rate Wideband (AMR-WB) Speech Codec...... 5
3.3. Multi-rate Encoding and Mode Adaptation..................... 5
3.4. Voice Activity Detection and Discontinuous Transmission..... 6
3.5. Support for Multi-Channel Session........................... 6
3.6. Unequal Bit-error Detection and Protection.................. 7
3.6.1. Applying UEP and UED in an IP Network................... 7
3.7. Robustness against Packet Loss.............................. 9
3.7.1. Use of Forward Error Correction (FEC)................... 9
3.7.2. Use of Frame Interleaving...............................11
3.8. Bandwidth Efficient or Octet-aligned Mode...................11
3.9. AMR or AMR-WB Speech over IP scenarios......................12
4. AMR and AMR-WB RTP Payload Formats..............................14
4.1. RTP Header Usage............................................14
4.2. Payload Structure...........................................16
4.3. Bandwidth-Efficient Mode....................................16
4.3.1. The Payload Header......................................16
4.3.2. The Payload Table of Contents...........................17
4.3.3. Speech Data.............................................19
4.3.4. Algorithm for Forming the Payload.......................20
4.3.5 Payload Examples.........................................21
4.3.5.1. Single Channel Payload Carrying a Single Frame...21
4.3.5.2. Single Channel Payload Carrying Multiple Frames..22
4.3.5.3. Multi-Channel Payload Carrying Multiple Frames...23
4.4. Octet-aligned Mode..........................................25
4.4.1. The Payload Header......................................25
4.4.2. The Payload Table of Contents and Frame CRCs............26
4.4.2.1. Use of Frame CRC for UED over IP....................28
4.4.3. Speech Data.............................................30
4.4.4. Methods for Forming the Payload.........................30
4.4.5. Payload Examples........................................32
4.4.5.1. Basic Single Channel Payload Carrying
Multiple Frames..................................32
4.4.5.2. Two Channel Payload with CRC, Interleaving,
and Robust-sorting...............................32
4.5. Implementation Considerations...............................33
5. AMR and AMR-WB Storage Format...................................34
5.1. Single Channel Header.......................................34
5.2. Multi-channel Header........................................35
5.3. Speech Frames...............................................36
6. Congestion Control..............................................37
7. Security Considerations.........................................37
7.1. Confidentiality.............................................37
7.2. Authentication..............................................38
7.3. Decoding Validation.........................................38
8. Payload Format Parameters.......................................38
8.1. AMR MIME Registration.......................................39
8.2. AMR-WB MIME Registration....................................41
8.3. Mapping MIME Parameters into SDP............................44
9. IANA Considerations.............................................45
10. Acknowledgements...............................................45
11. References.....................................................45
11.1 Informative References......................................46
12. Authors' Addresses.............................................48
13. Full Copyright Statement.......................................49
1. Introduction
This document specifies the payload format for packetization of AMR
and AMR-WB encoded speech signals into the Real-time Transport
Protocol (RTP) [8]. The payload format supports transmission of
multiple channels, multiple frames per payload, the use of fast codec
mode adaptation, robustness against packet loss and bit errors, and
interoperation with existing AMR and AMR-WB transport formats on
non-IP networks, as described in Section 3.
The payload format itself is specified in Section 4. A related file
format is specified in Section 5 for transport of AMR and AMR-WB
speech data in storage mode applications such as email. In Section
8, two separate MIME type registrations are provided, one for AMR and
one for AMR-WB.
Even though this RTP payload format definition supports the transport
of both AMR and AMR-WB speech, it is important to remember that AMR
and AMR-WB are two different codecs and they are always handled as
different payload types in RTP.
2. Conventions and Acronyms
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 RFC2119 [5].
The following acronyms are used in this document:
3GPP - the Third Generation Partnership Project
AMR - Adaptive Multi-Rate Codec
AMR-WB - Adaptive Multi-Rate Wideband Codec
CMR - Codec Mode Request
CN - Comfort Noise
DTX - Discontinuous Transmission
ETSI - European Telecommunications Standards Institute
FEC - Forward Error Correction
SCR - Source Controlled Rate Operation
SID - Silence Indicator (the frames containing only CN
parameters)
VAD - Voice Activity Detection
UED - Unequal Error Detection
UEP - Unequal Error Protection
The term "frame-block" is used in this document to describe the
time-synchronized set of speech frames in a multi-channel AMR or
AMR-WB session. In particular, in an N-channel session, a frame-
block will contain N speech frames, one from each of the channels,
and all N speech frames represents exactly the same time period.
3. Background on AMR/AMR-WB and Design Principles
AMR and AMR-WB were originally designed for circuit-switched mobile
radio systems. Due to their flexibility and robustness, they are
also suitable for other real-time speech communication services over
packet-switched networks such as the Internet.
Because of the flexibility of these codecs, the behavior in a
particular application is controlled by several parameters that
select options or specify the acceptable values for a variable.
These options and variables are described in general terms at
appropriate points in the text of this specification as parameters to
be established through out-of-band means. In Section 8, all of the
parameters are specified in the form of MIME subtype registrations
for the AMR and AMR-WB encodings. The method used to signal these
parameters at session setup or to arrange prior agreement of the
participants is beyond the scope of this document; however, Section
8.3 provides a mapping of the parameters into the Session Description
Protocol (SDP) [11] for those applications that use SDP.
3.1. The Adaptive Multi-Rate (AMR) Speech Codec
The AMR codecs was originally developed and standardized by the
European Telecommunications Standards Institute (ETSI) for GSM
cellular systems. It is now chosen by the Third Generation
Partnership Project (3GPP) as the mandatory codec for third
generation (3G) cellular systems [1].
The AMR codec is a multi-mode codec that supports 8 narrow band
speech encoding modes with bit rates between 4.75 and 12.2 kbps. The
sampling frequency used in AMR is 8000 Hz and the speech encoding is
performed on 20 ms speech frames. Therefore, each encoded AMR speech
frame represents 160 samples of the original speech.
Among the 8 AMR encoding modes, three are already separately adopted
as standards of their own. Particularly, the 6.7 kbps mode is
adopted as PDC-EFR [14], the 7.4 kbps mode as IS-641 codec in TDMA
[13], and the 12.2 kbps mode as GSM-EFR [12].
3.2. The Adaptive Multi-Rate Wideband (AMR-WB) Speech Codec
The Adaptive Multi-Rate Wideband (AMR-WB) speech codec [3] was
originally developed by 3GPP to be used in GSM and 3G cellular
systems.
Similar to AMR, the AMR-WB codec is also a multi-mode speech codec.
AMR-WB supports 9 wide band speech coding modes with respective bit
rates ranging from 6.6 to 23.85 kbps. The sampling frequency used in
AMR-WB is 16000 Hz and the speech processing is performed on 20 ms
frames. This means that each AMR-WB encoded frame represents 320
speech samples.
3.3. Multi-rate Encoding and Mode Adaptation
The multi-rate encoding (i.e., multi-mode) capability of AMR and
AMR-WB is designed for preserving high speech quality under a wide
range of transmission conditions.
With AMR or AMR-WB, mobile radio systems are able to use available
bandwidth as effectively as possible. E.g., in GSM it is possible to
dynamically adjust the speech encoding rate during a session so as to
continuously adapt to the varying transmission conditions by dividing
the fixed overall bandwidth between speech data and error protective
coding to enable best possible trade-off between speech compression
rate and error tolerance. To perform mode adaptation, the decoder
(speech receiver) needs to signal the encoder (speech sender) the new
mode it prefers. This mode change signal is called Codec Mode
Request or CMR.
Since in most sessions speech is sent in both directions between the
two ends, the mode requests from the decoder at one end to the
encoder at the other end are piggy-backed over the speech frames in
the reverse direction. In other words, there is no out-of-band
signaling needed for sending CMRs.
Every AMR or AMR-WB codec implementation is required to support all
the respective speech coding modes defined by the codec and must be
able to handle mode switching to any of the modes at any time.
However, some transport systems may impose limitations in the number
of modes supported and how often the mode can change due to bandwidth
limitations or other constraints. For this reason, the decoder is
allowed to indicate its acceptance of a particular mode or a subset
of the defined modes for the session using out-of-band means.
For example, the GSM radio link can only use a subset of at most four
different modes in a given session. This subset can be any
combination of the 8 AMR modes for an AMR session or any combination
of the 9 AMR-WB modes for an AMR-WB session.
Moreover, for better interoperability with GSM through a gateway, the
decoder is allowed to use out-of-band means to set the minimum number
of frames between two mode changes and to limit the mode change among
neighboring modes only.
Section 8 specifies a set of MIME parameters that may be used to
signal these mode adaptation controls at session setup.
3.4. Voice Activity Detection and Discontinuous Transmission
Both codecs support voice activity detection (VAD) and generation of
comfort noise (CN) parameters during silence periods. Hence, the
codecs have the option to reduce the number of transmitted bits and
packets during silence periods to a minimum. The operation of
sending CN parameters at regular intervals during silence periods is
usually called discontinuous transmission (DTX) or source controlled
rate (SCR) operation. The AMR or AMR-WB frames containing CN
parameters are called Silence Indicator (SID) frames. See more
details about VAD and DTX functionality in [9] and [10].
3.5. Support for Multi-Channel Session
Both the RTP payload format and the storage format defined in this
document support multi-channel audio content (e.g., a stereophonic
speech session).
Although AMR and AMR-WB codecs themselves do not support encoding of
multi-channel audio content into a single bit stream, they can be
used to separately encode and decode each of the individual channels.
To transport (or store) the separately encoded multi-channel content,
the speech frames for all channels that are framed and encoded for
the same 20 ms periods are logically collected in a frame-block.
At the session setup, out-of-band signaling must be used to indicate
the number of channels in the session and the order of the speech
frames from different channels in each frame-block. When using SDP
for signaling, the number of channels is specified in the rtpmap
attribute and the order of channels carried in each frame-block is
implied by the number of channels as specified in Section 4.1 in
[24].
3.6. Unequal Bit-error Detection and Protection
The speech bits encoded in each AMR or AMR-WB frame have different
perceptual sensitivity to bit errors. This property has been
exploited in cellular systems to achieve better voice quality by
using unequal error protection and detection (UEP and UED)
mechanisms.
The UEP/UED mechanisms focus the protection and detection of
corrupted bits to the perceptually most sensitive bits in an AMR or
AMR-WB frame. In particular, speech bits in an AMR or AMR-WB frame
are divided into class A, B, and C, where bits in class A are most
sensitive and bits in class C least sensitive (see Table 1 below for
AMR and [4] for AMR-WB). A frame is only declared damaged if there
are bit errors found in the most sensitive bits, i.e., the class A
bits. On the other hand, it is acceptable to have some bit errors in
the other bits, i.e., class B and C bits.
Class A total speech
Index Mode bits bits
----------------------------------------
0 AMR 4.75 42 95
1 AMR 5.15 49 103
2 AMR 5.9 55 118
3 AMR 6.7 58 134
4 AMR 7.4 61 148
5 AMR 7.95 75 159
6 AMR 10.2 65 204
7 AMR 12.2 81 244
8 AMR SID 39 39
Table 1. The number of class A bits for the AMR codec.
Moreover, a damaged frame is still useful for error concealment at
the decoder since some of the less sensitive bits can still be used.
This approach can improve the speech quality compared to discarding
the damaged frame.
3.6.1. Applying UEP and UED in an IP Network
To take full advantage of the bit-error robustness of the AMR and
AMR-WB codec, the RTP payload format is designed to facilitate
UEP/UED in an IP network. It should be noted however that the
utilization of UEP and UED discussed below is OPTIONAL.
UEP/UED in an IP network can be achieved by detecting bit errors in
class A bits and tolerating bit errors in class B/C bits of the AMR
or AMR-WB frame(s) in each RTP payload.
Today there exist some link layers that do not discard packets with
bit errors, e.g., SLIP and some wireless links. With the Internet
traffic pattern shifting towards a more multimedia-centric one, more
link layers of such nature may emerge in the future. With transport
layer support for partial checksums, for example those supported by
UDP-Lite [15], bit error tolerant AMR and AMR-WB traffic could
achieve better performance over these types of links.
There are at least two basic approaches for carrying AMR and AMR-WB
traffic over bit error tolerant IP networks:
1) Utilizing a partial checksum to cover headers and the most
important speech bits of the payload. It is recommended that at
least all class A bits are covered by the checksum.
2) Utilizing a partial checksum to only cover headers, but a frame
CRC to cover the class A bits of each speech frame in the RTP
payload.
In either approach, at least part of the class B/C bits are left
without error-check and thus bit error tolerance is achieved.
Note, it is still important that the network designer pay
attention to the class B and C residual bit error rate. Though
less sensitive to errors than class A bits, class B and C bits are
not insignificant and undetected errors in these bits cause
degradation in speech quality. An example of residual error rates
considered acceptable for AMR in UMTS can be found in [20] and for
AMR-WB in [21].
The application interface to the UEP/UED transport protocol (e.g.,
UDP-Lite) may not provide any control over the link error rate,
especially in a gateway scenario. Therefore, it is incumbent upon
the designer of a node with a link interface of this type to choose a
residual bit error rate that is low enough to support applications
such as AMR encoding when transmitting packets of a UEP/UED transport
protocol.
Approach 1 is a bit efficient, flexible and simple way, but comes
with two disadvantages, namely, a) bit errors in protected speech
bits will cause the payload to be discarded, and b) when transporting
multiple frames in a payload there is the possibility that a single
bit error in protected bits will cause all the frames to be
discarded.
These disadvantages can be avoided, if needed, with some overhead in
the form of a frame-wise CRC (Approach 2). In problem a), the CRC
makes it possible to detect bit errors in class A bits and use the
frame for error concealment, which gives a small improvement in
speech quality. For b), when transporting multiple frames in a
payload, the CRCs remove the possibility that a single bit error in a
class A bit will cause all the frames to be discarded. Avoiding that
gives an improvement in speech quality when transporting multiple
frames over links subject to bit errors.
The choice between the above two approaches must be made based on the
available bandwidth, and desired tolerance to bit errors. Neither
solution is appropriate to all cases. Section 8 defines parameters
that may be used at session setup to select between these approaches.
3.7. Robustness against Packet Loss
The payload format supports several means, including forward error
correction (FEC) and frame interleaving, to increase robustness
against packet loss.
3.7.1. Use of Forward Error Correction (FEC)
The simple scheme of repetition of previously sent data is one way of
achieving FEC. Another possible scheme which is more bandwidth
efficient is to use payload external FEC, e.g., RFC2733 [19], which
generates extra packets containing repair data. The whole payload
can also be sorted in sensitivity order to support external FEC
schemes using UEP. There is also a work in progress on a generic
version of such a scheme [18] that can be applied to AMR or AMR-WB
payload transport.
With AMR or AMR-WB, it is possible to use the multi-rate capability
of the codec to send redundant copies of the same mode or of another
mode, e.g., one with lower-bandwidth. We describe such a scheme
next.
This involves the simple retransmission of previously transmitted
frame-blocks together with the current frame-block(s). This is done
by using a sliding window to group the speech frame-blocks to send in
each payload. Figure 1 below shows us an example.
--+--------+--------+--------+--------+--------+--------+--------+--
| f(n-2) | f(n-1) | f(n) | f(n+1) | f(n+2) | f(n+3) | f(n+4) |
--+--------+--------+--------+--------+--------+--------+--------+--
<---- p(n-1) ---->
<----- p(n) ----->
<---- p(n+1) ---->
<---- p(n+2) ---->
<---- p(n+3) ---->
<---- p(n+4) ---->
Figure 1: An example of redundant transmission.
In this example each frame-block is retransmitted one time in the
following RTP payload packet. Here, f(n-2)..f(n+4) denotes a
sequence of speech frame-blocks and p(n-1)..p(n+4) a sequence of
payload packets.
The use of this approach does not require signaling at the session
setup. In other words, the speech sender can choose to use this
scheme without consulting the receiver. This is because a packet
containing redundant frames will not look different from a packet
with only new frames. The receiver may receive multiple copies or
versions (encoded with different modes) of a frame for a certain
timestamp if no packet is lost. If multiple versions of the same
speech frame are received, it is recommended that the mode with the
highest rate be used by the speech decoder.
This redundancy scheme provides the same functionality as the one
described in RFC2198 "RTP Payload for Redundant Audio Data" [24].
In most cases the mechanism in this payload format is more efficient
and simpler than requiring both endpoints to support RFC2198 in
addition. There are two situations in which use of RFC2198 is
indicated: if the spread in time required between the primary and
redundant encodings is larger than 5 frame times, the bandwidth
overhead of RFC2198 will be lower; or, if a non-AMR codec is desired
for the redundant encoding, the AMR payload format won't be able to
carry it.
The sender is responsible for selecting an appropriate amount of
redundancy based on feedback about the channel, e.g., in RTCP
receiver reports. A sender should not base selection of FEC on the
CMR, as this parameter most probably was set based on none-IP
information, e.g., radio link performance measures. The sender is
also responsible for avoiding congestion, which may be exacerbated by
redundancy (see Section 6 for more details).
3.7.2. Use of Frame Interleaving
To decrease protocol overhead, the payload design allows several
speech frame-blocks be encapsulated into a single RTP packet. One of
the drawbacks of such an approach is that in case of packet loss this
means loss of several consecutive speech frame-blocks, which usually
causes clearly audible distortion in the reconstructed speech.
Interleaving of frame-blocks can improve the speech quality in such
cases by distributing the consecutive losses into a series of single
frame-block losses. However, interleaving and bundling several
frame-blocks per payload will also increase end-to-end delay and is
therefore not appropriate for all types of applications. Streaming
applications will most likely be able to exploit interleaving to
improve speech quality in lossy transmission conditions.
This payload design supports the use of frame interleaving as an
option. For the encoder (speech sender) to use frame interleaving in
its outbound RTP packets for a given session, the decoder (speech
receiver) needs to indicate its support via out-of-band means (see
Section 8).
3.8. Bandwidth Efficient or Octet-aligned Mode
For a given session, the payload format can be either bandwidth
efficient or octet aligned, depending on the mode of operation that
is established for the session via out-of-band means.
In the octet-aligned format, all the fields in a payload, including
payload header, table of contents entries, and speech frames
themselves, are individually aligned to octet boundaries to make
implementations efficient. In the bandwidth efficient format only
the full payload is octet aligned, so fewer padding bits are added.
Note, octet alignment of a field or payload means that the last
octet is padded with zeroes in the least significant bits to fill
the octet. Also note that this padding is separate from padding
indicated by the P bit in the RTP header.
Between the two operation modes, only the octet-aligned mode has the
capability to use the robust sorting, interleaving, and frame CRC to
make the speech transport robust to packet loss and bit errors.
3.9. AMR or AMR-WB Speech over IP scenarios
The primary scenario for this payload format is IP end-to-end between
two terminals, as shown in Figure 2. This payload format is expected
to be useful for both conversational and streaming services.
+----------+ +----------+
| | IP/UDP/RTP/AMR or | |
| TERMINAL |<----------------------->| TERMINAL |
| | IP/UDP/RTP/AMR-WB | |
+----------+ +----------+
Figure 2: IP terminal to IP terminal scenario
A conversational service puts requirements on the payload format.
Low delay is one very important factor, i.e., few speech frame-blocks
per payload packet. Low overhead is also required when the payload
format traverses low bandwidth links, especially as the frequency of
packets will be high. For low bandwidth links it also an advantage
to support UED which allows a link provider to reduce delay and
packet loss or to reduce the utilization of link resources.
Streaming service has less strict real-time requirements and
therefore can use a larger number of frame-blocks per packet than
conversational service. This reduces the overhead from IP, UDP, and
RTP headers. However, including several frame-blocks per packet
makes the transmission more vulnerable to packet loss, so
interleaving may be used to reduce the effect packet loss will have
on speech quality. A streaming server handling a large number of
clients also needs a payload format that requires as few resources as
possible when doing packetization. The octet-aligned and
interleaving modes require the least amount of resources, while CRC,
robust sorting, and bandwidth efficient modes have higher demands.
Another scenario occurs when AMR or AMR-WB encoded speech will be
transmitted from a non-IP system (e.g., a GSM or 3GPP network) to an
IP/UDP/RTP VoIP terminal, and/or vice versa, as depicted in Figure 3.
AMR or AMR-WB
over
I.366.{2,3} or +------+ +----------+
3G Iu or | | IP/UDP/RTP/AMR or | |
<------------->| GW |<---------------------->| TERMINAL |
GSM Abis | | IP/UDP/RTP/AMR-WB | |
etc. +------+ +----------+
|
GSM/3GPP network | IP network
|
Figure 3: GW to VoIP terminal scenario
In such a case, it is likely that the AMR or AMR-WB frame is
packetized in a different way in the non-IP network and will need to
be re-packetized into RTP at the gateway. Also, speech frames from
the non-IP network may come with some UEP/UED information (e.g., a
frame quality indicator) that will need to be preserved and forwarded
on to the decoder along with the speech bits. This is specified in
Section 4.3.2.
AMR's capability to do fast mode switching is exploited in some non-
IP networks to optimize speech quality. To preserve this
functionality in scenarios including a gateway to an IP network, a
codec mode request (CMR) field is needed. The gateway will be
responsible for forwarding the CMR between the non-IP and IP parts in
both directions. The IP terminal should follow the CMR forwarded by
the gateway to optimize speech quality going to the non-IP decoder.
The mode control algorithm in the gateway must accommodate the delay
imposed by the IP network on the response to CMR by the IP terminal.
The IP terminal should not set the CMR (see Section 4.3.1), but the
gateway can set the CMR value on frames going toward the encoder in
the non-IP part to optimize speech quality from that encoder to the
gateway. The gateway can alternatively set a lower CMR value, if
desired, as one means to control congestion on the IP network.
A third likely scenario is that IP/UDP/RTP is used as transport
between two non-IP systems, i.e., IP is originated and terminated in
gateways on both sides of the IP transport, as illustrated in Figure
4 below.
AMR or AMR-WB AMR or AMR-WB
over over
I.366.{2,3} or +------+ +------+ I.366.{2,3} or
3G Iu or | | IP/UDP/RTP/AMR or | | 3G Iu or
<------------->| GW |<------------------->| GW |<------------->
GSM Abis | | IP/UDP/RTP/AMR-WB | | GSM Abis
etc. +------+ +------+ etc.
| |
GSM/3GPP network | IP network | GSM/3GPP network
| |
Figure 4: GW to GW scenario
This scenario requires the same mechanisms for preserving UED/UEP and
CMR information as in the single gateway scenario. In addition, the
CMR value may be set in packets received by the gateways on the IP
network side. The gateway should forward to the non-IP side a CMR
value that is the minimum of three values:
- the CMR value it receives on the IP side;
- the CMR value it calculates based on its reception quality on
the non-IP side; and
- a CMR value it may choose for congestion control of transmission
on the IP side.
The details of the control algorithm are left to the implementation.
4. AMR and AMR-WB RTP Payload Formats
The AMR and AMR-WB payload formats have identical structure, so they
are specified together. The only differences are in the types of
codec frames contained in the payload. The payload format consists
of the RTP header, payload header and payload data.
4.1. RTP Header Usage
The format of the RTP header is specified in [8]. This payload
format uses the fields of the header in a manner consistent with that
specification.
The RTP timestamp corresponds to the sampling instant of the first
sample encoded for the first frame-block in the packet. The
timestamp clock frequency is the same as the sampling frequency, so
the timestamp unit is in samples.
The duration of one speech frame-block is 20 ms for both AMR and
AMR-WB. For AMR, the sampling frequency is 8 kHz, corresponding to
160 encoded speech samples per frame from each channel. For AMR-WB,
the sampling frequency is 16 kHz, corresponding to 320 samples per
frame from each channel. Thus, the timestamp is increased by 160 for
AMR and 320 for AMR-WB for each consecutive frame-block.
A packet may contain multiple frame-blocks of encoded speech or
comfort noise parameters. If interleaving is employed, the frame-
blocks encapsulated into a payload are picked according to the
interleaving rules as defined in Section 4.4.1. Otherwise, each
packet covers a period of one or more contiguous 20 ms frame-block
intervals. In case the data from all the channels for a particular
frame-block in the period is missing, for example at a gateway from
some other transport format, it is possible to indicate that no data
is present for that frame-block rather than breaking a multi-frame-
block packet into two, as explained in Section 4.3.2.
To allow for error resiliency through redundant transmission, the
periods covered by multiple packets MAY overlap in time. A receiver
MUST be prepared to receive any speech frame multiple times, either
in exact duplicates, or in different AMR rate modes, or with data
present in one packet and not present in another. If multiple
versions of the same speech frame are received, it is RECOMMENDED
that the mode with the highest rate be used by the speech decoder. A
given frame MUST NOT be encoded as speech in one packet and comfort
noise parameters in another.
The payload is always made an integral number of octets long by
padding with zero bits if necessary. If additional padding is
required to bring the payload length to a larger multiple of octets
or for some other purpose, then the P bit in the RTP in the header
may be set and padding appended as specified in [8].
The RTP header marker bit (M) SHALL be set to 1 if the first frame-
block carried in the packet contains a speech frame which is the
first in a talkspurt. For all other packets the marker bit SHALL be
set to zero (M=0).
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 under which this payload format
is being used will assign a payload type for this encoding or specify
that the payload type is to be bound dynamically.
4.2. Payload Structure
The complete payload consists of a payload header, a payload table of
contents, and speech data representing one or more speech frame-
blocks. The following diagram shows the general payload format
layout:
+----------------+-------------------+----------------
| payload header | table of contents | speech data ...
+----------------+-------------------+----------------
Payloads containing more than one speech frame-block are called
compound payloads.
The following sections describe the variations taken by the payload
format depending on whether the AMR session is set up to use the
bandwidth-efficient mode or octet-aligned mode and any of the
OPTIONAL functions for robust sorting, interleaving, and frame CRCs.
Implementations SHOULD support both bandwidth-efficient and octet-
aligned operation to increase interoperability.
4.3. Bandwidth-Efficient Mode
4.3.1. The Payload Header
In bandwidth-efficient mode, the payload header simply consists of a
4 bit codec mode request:
0 1 2 3
+-+-+-+-+
| CMR |
+-+-+-+-+
CMR (4 bits): Indicates a codec mode request sent to the speech
encoder at the site of the receiver of this payload. The value of
the CMR field is set to the frame type index of the corresponding
speech mode being requested. The frame type index may be 0-7 for
AMR, as defined in Table 1a in [2], or 0-8 for AMR-WB, as defined
in Table 1a in [4]. CMR value 15 indicates that no mode request
is present, and other values are for future use.
The mode request received in the CMR field is valid until the next
CMR is received, i.e., a newly received CMR value overrides the
previous one. Therefore, if a terminal continuously wishes to
receive frames in the same mode X, it needs to set CMR=X for all its
outbound payloads, and if a terminal has no preference in which mode
to receive, it SHOULD set CMR=15 in all its outbound payloads.
If receiving a payload with a CMR value which is not a speech mode or
NO_DATA, the CMR MUST be ignored by the receiver.
In a multi-channel session, CMR SHOULD be interpreted by the receiver
of the payload as the desired encoding mode for all the channels in
the session.
An IP end-point SHOULD NOT set the CMR based on packet losses or
other congestion indications, for several reasons:
- The other end of the IP path may be a gateway to a non-IP
network (such as a radio link) that needs to set the CMR field
to optimize performance on that network.
- Congestion on the IP network is managed by the IP sender, in
this case at the other end of the IP path. Feedback about
congestion SHOULD be provided to that IP sender through RTCP or
other means, and then the sender can choose to avoid congestion
using the most appropriate mechanism. That may include
adjusting the codec mode, but also includes adjusting the level
of redundancy or number of frames per packet.
The encoder SHOULD follow a received mode request, but MAY change to
a lower-numbered mode if it so chooses, for example to control
congestion.
The CMR field MUST be set to 15 for packets sent to a multicast
group. The encoder in the speech sender SHOULD ignore mode requests
when sending speech to a multicast session but MAY use RTCP feedback
information as a hint that a mode change is needed.
The codec mode selection MAY be restricted by a session parameter to
a subset of the available modes. If so, the requested mode MUST be
among the signalled subset (see Section 8).
4.3.2. The Payload Table of Contents
The table of contents (ToC) consists of a list of ToC entries, each
representing a speech frame.
In bandwidth-efficient mode, a ToC entry takes the following format:
0 1 2 3 4 5
+-+-+-+-+-+-+
|F| FT |Q|
+-+-+-+-+-+-+
F (1 bit): If set to 1, indicates that this frame is followed by
another speech frame in this payload; if set to 0, indicates that
this frame is the last frame in this payload.
FT (4 bits): Frame type index, indicating either the AMR or AMR-WB
speech coding mode or comfort noise (SID) mode of the
corresponding frame carried in this payload.
The value of FT is defined in Table 1a in [2] for AMR and in Table 1a
in [4] for AMR-WB. FT=14 (SPEECH_LOST, only available for AMR-WB)
and FT=15 (NO_DATA) are used to indicate frames that are either lost
or not being transmitted in this payload, respectively.
NO_DATA (FT=15) frame could mean either that there is no data
produced by the speech encoder for that frame or that no data for
that frame is transmitted in the current payload (i.e., valid data
for that frame could be sent in either an earlier or later packet).
If receiving a ToC entry with a FT value in the range 9-14 for AMR or
10-13 for AMR-WB the whole packet SHOULD be discarded. This is to
avoid the loss of data synchronization in the depacketization
process, which can result in a huge degradation in speech quality.
Note that packets containing only NO_DATA frames SHOULD NOT be
transmitted. Also, frame-blocks containing only NO_DATA frames at
the end of a packet SHOULD NOT be transmitted, except in the case of
interleaving. The AMR SCR/DTX is described in [6] and AMR-WB SCR/DTX
in [7].
The extra comfort noise frame types specified in table 1a in [2]
(i.e., GSM-EFR CN, IS-641 CN, and PDC-EFR CN) MUST NOT be used in
this payload format because the standardized AMR codec is only
required to implement the general AMR SID frame type and not those
that are native to the incorporated encodings.
Q (1 bit): Frame quality indicator. If set to 0, indicates the
corresponding frame is severely damaged and the receiver should
set the RX_TYPE (see [6]) to either SPEECH_BAD or SID_BAD
depending on the frame type (FT).
The frame quality indicator is included for interoperability with the
ATM payload format described in ITU-T I.366.2, the UMTS Iu interface
[16], as well as other transport formats. The frame quality
indicator enables damaged frames to be forwarded to the speech
decoder for error concealment. This can improve the speech quality
comparing to dropping the damaged frames. See Section 4.4.2.1 for
more details.
For multi-channel sessions, the ToC entries of all frames from a
frame-block are placed in the ToC in consecutive order as defined in
Section 4.1 in [24]. When multiple frame-blocks are present in a
packet in bandwidth-efficient mode, they will be placed in the packet
in order of their creation time.
Therefore, with N channels and K speech frame-blocks in a packet,
there MUST be N*K entries in the ToC, and the first N entries will be
from the first frame-block, the second N entries will be from the
second frame-block, and so on.
The following figure shows an example of a ToC of three entries in a
single channel session using bandwidth efficient mode.
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| FT |Q|1| FT |Q|0| FT |Q|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Below is an example of how the ToC entries will appear in the ToC of
a packet carrying 3 consecutive frame-blocks in a session with two
channels (L and R).
+----+----+----+----+----+----+
| 1L | 1R | 2L | 2R | 3L | 3R |
+----+----+----+----+----+----+
|<------->|<------->|<------->|
Frame- Frame- Frame-
Block 1 Block 2 Block 3
4.3.3. Speech Data
Speech data of a payload contains one or more speech frames or
comfort noise frames, as described in the ToC of the payload.
Note, for ToC entries with FT=14 or 15, there will be no
corresponding speech frame present in the speech data.
Each speech frame represents 20 ms of speech encoded with the mode
indicated in the FT field of the corresponding ToC entry. The length
of the speech frame is implicitly defined by the mode indicated in
the FT field. The order and numbering notation of the bits are as
specified for Interface Format 1 (IF1) in [2] for AMR and [4] for
AMR-WB. As specified there, the bits of speech frames have been
rearranged in order of decreasing sensitivity, while the bits of
comfort noise frames are in the order produced by the encoder. The
resulting bit sequence for a frame of length K bits is denoted d(0),
d(1), ..., d(K-1).
4.3.4. Algorithm for Forming the Payload
The complete RTP payload in bandwidth-efficient mode is formed by
packing bits from the payload header, table of contents, and speech
frames, in order as defined by their corresponding ToC entries in the
ToC list, contiguously into octets beginning with the most
significant bits of the fields and the octets.
To be precise, the four-bit payload header is packed into the first
octet of the payload with bit 0 of the payload header in the most
significant bit of the octet. The four most significant bits
(numbered 0-3) of the first ToC entry are packed into the least
significant bits of the octet, ending with bit 3 in the least
significant bit. Packing continues in the second octet with bit 4 of
the first ToC entry in the most significant bit of the octet. If
more than one frame is contained in the payload, then packing
continues with the second and successive ToC entries. Bit 0 of the
first data frame follows immediately after the last ToC bit,
proceeding through all the bits of the frame in numerical order.
Bits from any successive frames follow contiguously in numerical
order for each frame and in consecutive order of the frames.
If speech data is missing for one or more speech frame within the
sequence, because of, for example, DTX, a ToC entry with FT set to
NO_DATA SHALL be included in the ToC for each of the missing frames,
but no data bits are included in the payload for the missing frame
(see Section 4.3.5.2 for an example).
4.3.5 Payload Examples
4.3.5.1. Single Channel Payload Carrying a Single Frame
The following diagram shows a bandwidth-efficient AMR payload from a
single channel session carrying a single speech frame-block.
In the payload, no specific mode is requested (CMR=15), the speech
frame is not damaged at the IP origin (Q=1), and the coding mode is
AMR 7.4 kbps (FT=4). The encoded speech bits, d(0) to d(147), are
arranged in descending sensitivity order according to [2]. Finally,
two zero bits are added to the end as padding to make the payload
octet aligned.
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=15|0| FT=4 |1|d(0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| d(147)|P|P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.3.5.2. Single Channel Payload Carrying Multiple Frames
The following diagram shows a single channel, bandwidth efficient
compound AMR-WB payload that contains four frames, of which one has
no speech data. The first frame is a speech frame at 6.6 kbps mode
(FT=0) that is composed of speech bits d(0) to d(131). The second
frame is an AMR-WB SID frame (FT=9), consisting of bits g(0) to
g(39). The third frame is NO_DATA frame and does not carry any
speech information, it is represented in the payload by its ToC
entry. The fourth frame in the payload is a speech frame at 8.85
kpbs mode (FT=1), it consists of speech bits h(0) to h(176).
As shown below, the payload carries a mode request for the encoder on
the receiver's side to change its future coding mode to AMR-WB 8.85
kbps (CMR=1). None of the frames is damaged at IP origin (Q=1). The
encoded speech and SID bits, d(0) to d(131), g(0) to g(39) and h(0)
to h(176), are arranged in the payload in descending sensitivity
order according to [4]. (Note, no speech bits are present for the
third frame). Finally, seven 0s are padded to the end to make the
payload octet aligned.
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=1 |1| FT=0 |1|1| FT=9 |1|1| FT=15 |1|0| FT=1 |1|d(0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| d(131)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|g(0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| g(39)|h(0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h(176)|P|P|P|P|P|P|P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.3.5.3. Multi-Channel Payload Carrying Multiple Frames
The following diagram shows a two channel payload carrying 3 frame-
blocks, i.e., the payload will contain 6 speech frames.
In the payload all speech frames contain the same mode 7.4 kbit/s
(FT=4) and are not damaged at IP origin. The CMR is set to 15, i.e.,
no specific mode is requested. The two channels are defined as left
(L) and right (R) in that order. The encoded speech bits is
designated dXY(0).. dXY(K-1), where X = block number, Y = channel,
and K is the number of speech bits for that mode. Exemplifying this,
for frame-block 1 of the left channel the encoded bits are designated
as d1L(0) to d1L(147).
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=15|1|1L FT=4|1|1|1R FT=4|1|1|2L FT=4|1|1|2R FT=4|1|1|3L FT|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|4|1|0|3R FT=4|1|d1L(0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| d1L(147)|d1R(0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| d1R(147)|d2L(0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|d2L(147|d2R(0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| d2R(147)|d3L(0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| d3L(147)|d3R(0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+