As per Relevance of the word parameter, we have this rfc below:
Network Working Group J.
Request for Comments: 3267 M.
Category: Standards Track
A.
Q.
June 2002
Real-Time Transport Protocol (RTP) Payload Format and File
Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-
Wideband (AMR-WB) Audio
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (2002). All Rights Reserved
This document specifies a real-time transport protocol (RTP)
format to be used for Adaptive Multi-Rate (AMR) and Adaptive Multi
Rate Wideband (AMR-WB) encoded speech signals. The payload format
designed to be able to interoperate with existing AMR and AMR-
transport formats on non-IP networks. In addition, a file format
specified for transport of AMR and AMR-WB speech data in storage
applications such as email. Two separate MIME type registrations
included, one for AMR and one for AMR-WB, specifying use of both
RTP payload format and the storage format
Sjoberg, et. al. Standards Track [Page 1]
RFC 3267 RTP Payload Format for AMR and AMR-WB June 2002
Table of
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
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
Sjoberg, et. al. Standards Track [Page 2]
RFC 3267 RTP Payload Format for AMR and AMR-WB June 2002
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.
This document specifies the payload format for packetization of
and AMR-WB encoded speech signals into the Real-time
Protocol (RTP) [8]. The payload format supports transmission
multiple channels, multiple frames per payload, the use of fast
mode adaptation, robustness against packet loss and bit errors,
interoperation with existing AMR and AMR-WB transport formats
non-IP networks, as described in Section 3.
The payload format itself is specified in Section 4. A related
format is specified in Section 5 for transport of AMR and AMR-
speech data in storage mode applications such as email. In
8, two separate MIME type registrations are provided, one for AMR
one for AMR-WB
Even though this RTP payload format definition supports the
of both AMR and AMR-WB speech, it is important to remember that
and AMR-WB are two different codecs and they are always handled
different payload types in RTP
2. Conventions and
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
document are to be interpreted as described in RFC2119 [5].
The following acronyms are used in this document
3GPP - the Third Generation Partnership
AMR - Adaptive Multi-Rate
AMR-WB - Adaptive Multi-Rate Wideband
CMR - Codec Mode
CN - Comfort
DTX - Discontinuous
Sjoberg, et. al. Standards Track [Page 3]
RFC 3267 RTP Payload Format for AMR and AMR-WB June 2002
ETSI - European Telecommunications Standards
FEC - Forward Error
SCR - Source Controlled Rate
SID - Silence Indicator (the frames containing only
parameters
VAD - Voice Activity
UED - Unequal Error
UEP - Unequal Error
The term "frame-block" is used in this document to describe
time-synchronized set of speech frames in a multi-channel AMR
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
AMR and AMR-WB were originally designed for circuit-switched
radio systems. Due to their flexibility and robustness, they
also suitable for other real-time speech communication services
packet-switched networks such as the Internet
Because of the flexibility of these codecs, the behavior in
particular application is controlled by several parameters
select options or specify the acceptable values for a variable
These options and variables are described in general terms
appropriate points in the text of this specification as parameters
be established through out-of-band means. In Section 8, all of
parameters are specified in the form of MIME subtype
for the AMR and AMR-WB encodings. The method used to signal
parameters at session setup or to arrange prior agreement of
participants is beyond the scope of this document; however,
8.3 provides a mapping of the parameters into the Session
Protocol (SDP) [11] for those applications that use SDP
3.1. The Adaptive Multi-Rate (AMR) Speech
The AMR codecs was originally developed and standardized by
European Telecommunications Standards Institute (ETSI) for
cellular systems. It is now chosen by the Third
Partnership Project (3GPP) as the mandatory codec for
generation (3G) cellular systems [1].
The AMR codec is a multi-mode codec that supports 8 narrow
speech encoding modes with bit rates between 4.75 and 12.2 kbps.
sampling frequency used in AMR is 8000 Hz and the speech encoding
performed on 20 ms speech frames. Therefore, each encoded AMR
frame represents 160 samples of the original speech
Sjoberg, et. al. Standards Track [Page 4]
RFC 3267 RTP Payload Format for AMR and AMR-WB June 2002
Among the 8 AMR encoding modes, three are already separately
as standards of their own. Particularly, the 6.7 kbps mode
adopted as PDC-EFR [14], the 7.4 kbps mode as IS-641 codec in
[13], and the 12.2 kbps mode as GSM-EFR [12].
3.2. The Adaptive Multi-Rate Wideband (AMR-WB) Speech
The Adaptive Multi-Rate Wideband (AMR-WB) speech codec [3]
originally developed by 3GPP to be used in GSM and 3G
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
rates ranging from 6.6 to 23.85 kbps. The sampling frequency used
AMR-WB is 16000 Hz and the speech processing is performed on 20
frames. This means that each AMR-WB encoded frame represents 320
speech samples
3.3. Multi-rate Encoding and Mode
The multi-rate encoding (i.e., multi-mode) capability of AMR
AMR-WB is designed for preserving high speech quality under a
range of transmission conditions
With AMR or AMR-WB, mobile radio systems are able to use
bandwidth as effectively as possible. E.g., in GSM it is possible
dynamically adjust the speech encoding rate during a session so as
continuously adapt to the varying transmission conditions by
the fixed overall bandwidth between speech data and error
coding to enable best possible trade-off between speech
rate and error tolerance. To perform mode adaptation, the
(speech receiver) needs to signal the encoder (speech sender) the
mode it prefers. This mode change signal is called Codec
Request or CMR
Since in most sessions speech is sent in both directions between
two ends, the mode requests from the decoder at one end to
encoder at the other end are piggy-backed over the speech frames
the reverse direction. In other words, there is no out-of-
signaling needed for sending CMRs
Every AMR or AMR-WB codec implementation is required to support
the respective speech coding modes defined by the codec and must
able to handle mode switching to any of the modes at any time
However, some transport systems may impose limitations in the
of modes supported and how often the mode can change due to
Sjoberg, et. al. Standards Track [Page 5]
RFC 3267 RTP Payload Format for AMR and AMR-WB June 2002
limitations or other constraints. For this reason, the decoder
allowed to indicate its acceptance of a particular mode or a
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
different modes in a given session. This subset can be
combination of the 8 AMR modes for an AMR session or any
of the 9 AMR-WB modes for an AMR-WB session
Moreover, for better interoperability with GSM through a gateway,
decoder is allowed to use out-of-band means to set the minimum
of frames between two mode changes and to limit the mode change
neighboring modes only
Section 8 specifies a set of MIME parameters that may be used
signal these mode adaptation controls at session setup
3.4. Voice Activity Detection and Discontinuous
Both codecs support voice activity detection (VAD) and generation
comfort noise (CN) parameters during silence periods. Hence,
codecs have the option to reduce the number of transmitted bits
packets during silence periods to a minimum. The operation
sending CN parameters at regular intervals during silence periods
usually called discontinuous transmission (DTX) or source
rate (SCR) operation. The AMR or AMR-WB frames containing
parameters are called Silence Indicator (SID) frames. See
details about VAD and DTX functionality in [9] and [10].
3.5. Support for Multi-Channel
Both the RTP payload format and the storage format defined in
document support multi-channel audio content (e.g., a
speech session).
Although AMR and AMR-WB codecs themselves do not support encoding
multi-channel audio content into a single bit stream, they can
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
the same 20 ms periods are logically collected in a frame-block
At the session setup, out-of-band signaling must be used to
the number of channels in the session and the order of the
frames from different channels in each frame-block. When using
for signaling, the number of channels is specified in the
Sjoberg, et. al. Standards Track [Page 6]
RFC 3267 RTP Payload Format for AMR and AMR-WB June 2002
attribute and the order of channels carried in each frame-block
implied by the number of channels as specified in Section 4.1
[24].
3.6. Unequal Bit-error Detection and
The speech bits encoded in each AMR or AMR-WB frame have
perceptual sensitivity to bit errors. This property has
exploited in cellular systems to achieve better voice quality
using unequal error protection and detection (UEP and UED
mechanisms
The UEP/UED mechanisms focus the protection and detection
corrupted bits to the perceptually most sensitive bits in an AMR
AMR-WB frame. In particular, speech bits in an AMR or AMR-WB
are divided into class A, B, and C, where bits in class A are
sensitive and bits in class C least sensitive (see Table 1 below
AMR and [4] for AMR-WB). A frame is only declared damaged if
are bit errors found in the most sensitive bits, i.e., the class
bits. On the other hand, it is acceptable to have some bit errors
the other bits, i.e., class B and C bits
Class A total
Index Mode 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
the decoder since some of the less sensitive bits can still be used
This approach can improve the speech quality compared to
the damaged frame
3.6.1. Applying UEP and UED in an IP
To take full advantage of the bit-error robustness of the AMR
AMR-WB codec, the RTP payload format is designed to
UEP/UED in an IP network. It should be noted however that
utilization of UEP and UED discussed below is OPTIONAL
Sjoberg, et. al. Standards Track [Page 7]
RFC 3267 RTP Payload Format for AMR and AMR-WB June 2002
UEP/UED in an IP network can be achieved by detecting bit errors
class A bits and tolerating bit errors in class B/C bits of the
or AMR-WB frame(s) in each RTP payload
Today there exist some link layers that do not discard packets
bit errors, e.g., SLIP and some wireless links. With the
traffic pattern shifting towards a more multimedia-centric one,
link layers of such nature may emerge in the future. With
layer support for partial checksums, for example those supported
UDP-Lite [15], bit error tolerant AMR and AMR-WB traffic
achieve better performance over these types of links
There are at least two basic approaches for carrying AMR and AMR-
traffic over bit error tolerant IP networks
1) Utilizing a partial checksum to cover headers and the
important speech bits of the payload. It is recommended that
least all class A bits are covered by the checksum
2) Utilizing a partial checksum to only cover headers, but a
CRC to cover the class A bits of each speech frame in the
payload
In either approach, at least part of the class B/C bits are
without error-check and thus bit error tolerance is achieved
Note, it is still important that the network designer
attention to the class B and C residual bit error rate.
less sensitive to errors than class A bits, class B and C bits
not insignificant and undetected errors in these bits
degradation in speech quality. An example of residual error
considered acceptable for AMR in UMTS can be found in [20] and
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
the designer of a node with a link interface of this type to choose
residual bit error rate that is low enough to support
such as AMR encoding when transmitting packets of a UEP/UED
protocol
Approach 1 is a bit efficient, flexible and simple way, but
with two disadvantages, namely, a) bit errors in protected
bits will cause the payload to be discarded, and b) when
multiple frames in a payload there is the possibility that a
bit error in protected bits will cause all the frames to
discarded
Sjoberg, et. al. Standards Track [Page 8]
RFC 3267 RTP Payload Format for AMR and AMR-WB June 2002
These disadvantages can be avoided, if needed, with some overhead
the form of a frame-wise CRC (Approach 2). In problem a), the
makes it possible to detect bit errors in class A bits and use
frame for error concealment, which gives a small improvement
speech quality. For b), when transporting multiple frames in
payload, the CRCs remove the possibility that a single bit error in
class A bit will cause all the frames to be discarded. Avoiding
gives an improvement in speech quality when transporting
frames over links subject to bit errors
The choice between the above two approaches must be made based on
available bandwidth, and desired tolerance to bit errors.
solution is appropriate to all cases. Section 8 defines
that may be used at session setup to select between these approaches
3.7. Robustness against Packet
The payload format supports several means, including forward
correction (FEC) and frame interleaving, to increase
against packet loss
3.7.1. Use of Forward Error Correction (FEC
The simple scheme of repetition of previously sent data is one way
achieving FEC. Another possible scheme which is more
efficient is to use payload external FEC, e.g., RFC2733 [19],
generates extra packets containing repair data. The whole
can also be sorted in sensitivity order to support external
schemes using UEP. There is also a work in progress on a
version of such a scheme [18] that can be applied to AMR or AMR-
payload transport
With AMR or AMR-WB, it is possible to use the multi-rate
of the codec to send redundant copies of the same mode or of
mode, e.g., one with lower-bandwidth. We describe such a
next
Sjoberg, et. al. Standards Track [Page 9]
RFC 3267 RTP Payload Format for AMR and AMR-WB June 2002
This involves the simple retransmission of previously
frame-blocks together with the current frame-block(s). This is
by using a sliding window to group the speech frame-blocks to send
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
following RTP payload packet. Here, f(n-2)..f(n+4) denotes
sequence of speech frame-blocks and p(n-1)..p(n+4) a sequence
payload packets
The use of this approach does not require signaling at the
setup. In other words, the speech sender can choose to use
scheme without consulting the receiver. This is because a
containing redundant frames will not look different from a
with only new frames. The receiver may receive multiple copies
versions (encoded with different modes) of a frame for a
timestamp if no packet is lost. If multiple versions of the
speech frame are received, it is recommended that the mode with
highest rate be used by the speech decoder
This redundancy scheme provides the same functionality as the
described in RFC 2198 "RTP Payload for Redundant Audio Data" [24].
In most cases the mechanism in this payload format is more
and simpler than requiring both endpoints to support RFC 2198
addition. There are two situations in which use of RFC 2198
indicated: if the spread in time required between the primary
redundant encodings is larger than 5 frame times, the
overhead of RFC 2198 will be lower; or, if a non-AMR codec is
for the redundant encoding, the AMR payload format won't be able
carry it
The sender is responsible for selecting an appropriate amount
redundancy based on feedback about the channel, e.g., in
receiver reports. A sender should not base selection of FEC on
CMR, as this parameter most probably was set based on none-
Sjoberg, et. al. Standards Track [Page 10]
RFC 3267 RTP Payload Format for AMR and AMR-WB June 2002
information, e.g., radio link performance measures. The sender
also responsible for avoiding congestion, which may be exacerbated
redundancy (see Section 6 for more details).
3.7.2. Use of Frame
To decrease protocol overhead, the payload design allows
speech frame-blocks be encapsulated into a single RTP packet. One
the drawbacks of such an approach is that in case of packet loss
means loss of several consecutive speech frame-blocks, which
causes clearly audible distortion in the reconstructed speech
Interleaving of frame-blocks can improve the speech quality in
cases by distributing the consecutive losses into a series of
frame-block losses. However, interleaving and bundling
frame-blocks per payload will also increase end-to-end delay and
therefore not appropriate for all types of applications.
applications will most likely be able to exploit interleaving
improve speech quality in lossy transmission conditions
This payload design supports the use of frame interleaving as
option. For the encoder (speech sender) to use frame interleaving
its outbound RTP packets for a given session, the decoder (
receiver) needs to indicate its support via out-of-band means (
Section 8).
3.8. Bandwidth Efficient or Octet-aligned
For a given session, the payload format can be either
efficient or octet aligned, depending on the mode of operation
is established for the session via out-of-band means
In the octet-aligned format, all the fields in a payload,
payload header, table of contents entries, and speech
themselves, are individually aligned to octet boundaries to
implementations efficient. In the bandwidth efficient format
the full payload is octet aligned, so fewer padding bits are added
Note, octet alignment of a field or payload means that the
octet is padded with zeroes in the least significant bits to
the octet. Also note that this padding is separate from
indicated by the P bit in the RTP header
Between the two operation modes, only the octet-aligned mode has
capability to use the robust sorting, interleaving, and frame CRC
make the speech transport robust to packet loss and bit errors
Sjoberg, et. al. Standards Track [Page 11]
RFC 3267 RTP Payload Format for AMR and AMR-WB June 2002
3.9. AMR or AMR-WB Speech over IP
The primary scenario for this payload format is IP end-to-end
two terminals, as shown in Figure 2. This payload format is
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
A conversational service puts requirements on the payload format
Low delay is one very important factor, i.e., few speech frame-
per payload packet. Low overhead is also required when the
format traverses low bandwidth links, especially as the frequency
packets will be high. For low bandwidth links it also an
to support UED which allows a link provider to reduce delay
packet loss or to reduce the utilization of link resources
Streaming service has less strict real-time requirements
therefore can use a larger number of frame-blocks per packet
conversational service. This reduces the overhead from IP, UDP,
RTP headers. However, including several frame-blocks per
makes the transmission more vulnerable to packet loss,
interleaving may be used to reduce the effect packet loss will
on speech quality. A streaming server handling a large number
clients also needs a payload format that requires as few resources
possible when doing packetization. The octet-aligned
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
transmitted from a non-IP system (e.g., a GSM or 3GPP network) to
IP/UDP/RTP VoIP terminal, and/or vice versa, as depicted in Figure 3.
Sjoberg, et. al. Standards Track [Page 12]
RFC 3267 RTP Payload Format for AMR and AMR-WB June 2002
AMR or AMR-
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
|
Figure 3: GW to VoIP terminal
In such a case, it is likely that the AMR or AMR-WB frame
packetized in a different way in the non-IP network and will need
be re-packetized into RTP at the gateway. Also, speech frames
the non-IP network may come with some UEP/UED information (e.g.,
frame quality indicator) that will need to be preserved and
on to the decoder along with the speech bits. This is specified
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
functionality in scenarios including a gateway to an IP network,
codec mode request (CMR) field is needed. The gateway will
responsible for forwarding the CMR between the non-IP and IP parts
both directions. The IP terminal should follow the CMR forwarded
the gateway to optimize speech quality going to the non-IP decoder
The mode control algorithm in the gateway must accommodate the
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
gateway can set the CMR value on frames going toward the encoder
the non-IP part to optimize speech quality from that encoder to
gateway. The gateway can alternatively set a lower CMR value,
desired, as one means to control congestion on the IP network
Sjoberg, et. al. Standards Track [Page 13]
RFC 3267 RTP Payload Format for AMR and AMR-WB June 2002
A third likely scenario is that IP/UDP/RTP is used as
between two non-IP systems, i.e., IP is originated and terminated
gateways on both sides of the IP transport, as illustrated in
4 below
AMR or AMR-WB AMR or AMR-
over
I.366.{2,3} or +------+ +------+ I.366.{2,3}
3G Iu or | | IP/UDP/RTP/AMR or | | 3G Iu
<------------->| GW |<------------------->| GW |<------------->
GSM Abis | | IP/UDP/RTP/AMR-WB | | GSM
etc. +------+ +------+ etc
| |
GSM/3GPP network | IP network | GSM/3GPP
| |
Figure 4: GW to GW
This scenario requires the same mechanisms for preserving UED/UEP
CMR information as in the single gateway scenario. In addition,
CMR value may be set in packets received by the gateways on the
network side. The gateway should forward to the non-IP side a
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
the non-IP side;
- a CMR value it may choose for congestion control of
on the IP side
The details of the control algorithm are left to the implementation
4. AMR and AMR-WB RTP Payload
The AMR and AMR-WB payload formats have identical structure, so
are specified together. The only differences are in the types
codec frames contained in the payload. The payload format
of the RTP header, payload header and payload data
4.1. RTP Header
The format of the RTP header is specified in [8]. This
format uses the fields of the header in a manner consistent with
specification
Sjoberg, et. al. Standards Track [Page 14]
RFC 3267 RTP Payload Format for AMR and AMR-WB June 2002
The RTP timestamp corresponds to the sampling instant of the
sample encoded for the first frame-block in the packet.
timestamp clock frequency is the same as the sampling frequency,
the timestamp unit is in samples
The duration of one speech frame-block is 20 ms for both AMR
AMR-WB. For AMR, the sampling frequency is 8 kHz, corresponding
160 encoded speech samples per frame from each channel. For AMR-WB
the sampling frequency is 16 kHz, corresponding to 320 samples
frame from each channel. Thus, the timestamp is increased by 160
AMR and 320 for AMR-WB for each consecutive frame-block
A packet may contain multiple frame-blocks of encoded speech
comfort noise parameters. If interleaving is employed, the frame
blocks encapsulated into a payload are picked according to
interleaving rules as defined in Section 4.4.1. Otherwise,
packet covers a period of one or more contiguous 20 ms frame-
intervals. In case the data from all the channels for a
frame-block in the period is missing, for example at a gateway
some other transport format, it is possible to indicate that no
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,
periods covered by multiple packets MAY overlap in time. A
MUST be prepared to receive any speech frame multiple times,
in exact duplicates, or in different AMR rate modes, or with
present in one packet and not present in another. If
versions of the same speech frame are received, it is
that the mode with the highest rate be used by the speech decoder.
given frame MUST NOT be encoded as speech in one packet and
noise parameters in another
The payload is always made an integral number of octets long
padding with zero bits if necessary. If additional padding
required to bring the payload length to a larger multiple of
or for some other purpose, then the P bit in the RTP in the
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
first in a talkspurt. For all other packets the marker bit SHALL
set to zero (M=0).
Sjoberg, et. al. Standards Track [Page 15]
RFC 3267 RTP Payload Format for AMR and AMR-WB June 2002
The assignment of an RTP payload type for this new packet format
outside the scope of this document, and will not be specified here
It is expected that the RTP profile under which this payload
is being used will assign a payload type for this encoding or
that the payload type is to be bound dynamically
4.2. Payload
The complete payload consists of a payload header, a payload table
contents, and speech data representing one or more speech frame
blocks. The following diagram shows the general payload
layout
+----------------+-------------------+----------------
| payload header | table of contents | speech data ...
+----------------+-------------------+----------------
Payloads containing more than one speech frame-block are
compound payloads
The following sections describe the variations taken by the
format depending on whether the AMR session is set up to use
bandwidth-efficient mode or octet-aligned mode and any of
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
4.3.1. The Payload
In bandwidth-efficient mode, the payload header simply consists of
4 bit codec mode request
0 1 2 3
+-+-+-+-+
| CMR |
+-+-+-+-+
CMR (4 bits): Indicates a codec mode request sent to the
encoder at the site of the receiver of this payload. The value
the CMR field is set to the frame type index of the
speech mode being requested. The frame type index may be 0-7
AMR, as defined in Table 1a in [2], or 0-8 for AMR-WB, as
in Table 1a in [4]. CMR value 15 indicates that no mode
is present, and other values are for future use
Sjoberg, et. al. Standards Track [Page 16]
RFC 3267 RTP Payload Format for AMR and AMR-WB June 2002
The mode request received in the CMR field is valid until the
CMR is received, i.e., a newly received CMR value overrides
previous one. Therefore, if a terminal continuously wishes
receive frames in the same mode X, it needs to set CMR=X for all
outbound payloads, and if a terminal has no preference in which
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
NO_DATA, the CMR MUST be ignored by the receiver
In a multi-channel session, CMR SHOULD be interpreted by the
of the payload as the desired encoding mode for all the channels
the session
An IP end-point SHOULD NOT set the CMR based on packet losses
other congestion indications, for several reasons
- The other end of the IP path may be a gateway to a non-
network (such as a radio link) that needs to set the CMR
to optimize performance on that network
- Congestion on the IP network is managed by the IP sender,
this case at the other end of the IP path. Feedback
congestion SHOULD be provided to that IP sender through RTCP
other means, and then the sender can choose to avoid
using the most appropriate mechanism. That may
adjusting the codec mode, but also includes adjusting the
of redundancy or number of frames per packet
The encoder SHOULD follow a received mode request, but MAY change
a lower-numbered mode if it so chooses, for example to
congestion
The CMR field MUST be set to 15 for packets sent to a
group. The encoder in the speech sender SHOULD ignore mode
when sending speech to a multicast session but MAY use RTCP
information as a hint that a mode change is needed
The codec mode selection MAY be restricted by a session parameter
a subset of the available modes. If so, the requested mode MUST
among the signalled subset (see Section 8).
4.3.2. The Payload Table of
The table of contents (ToC) consists of a list of ToC entries,
representing a speech frame
Sjoberg, et. al. Standards Track [Page 17]
RFC 3267 RTP Payload Format for AMR and AMR-WB June 2002
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
another speech frame in this payload; if set to 0, indicates
this frame is the last frame in this payload
FT (4 bits): Frame type index, indicating either the AMR or AMR-
speech coding mode or comfort noise (SID) mode of
corresponding frame carried in this payload
The value of FT is defined in Table 1a in [2] for AMR and in Table 1
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
or not being transmitted in this payload, respectively
NO_DATA (FT=15) frame could mean either that there is no
produced by the speech encoder for that frame or that no data
that frame is transmitted in the current payload (i.e., valid
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
10-13 for AMR-WB the whole packet SHOULD be discarded. This is
avoid the loss of data synchronization in the
process, which can result in a huge degradation in speech quality
Note that packets containing only NO_DATA frames SHOULD NOT
transmitted. Also, frame-blocks containing only NO_DATA frames
the end of a packet SHOULD NOT be transmitted, except in the case
interleaving. The AMR SCR/DTX is described in [6] and AMR-WB SCR/
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
this payload format because the standardized AMR codec is
required to implement the general AMR SID frame type and not
that are native to the incorporated encodings
Q (1 bit): Frame quality indicator. If set to 0, indicates
corresponding frame is severely damaged and the receiver
set the RX_TYPE (see [6]) to either SPEECH_BAD or SID_
depending on the frame type (FT).
Sjoberg, et. al. Standards Track [Page 18]
RFC 3267 RTP Payload Format for AMR and AMR-WB June 2002
The frame quality indicator is included for interoperability with
ATM payload format described in ITU-T I.366.2, the UMTS Iu
[16], as well as other transport formats. The frame
indicator enables damaged frames to be forwarded to the
decoder for error concealment. This can improve the speech
comparing to dropping the damaged frames. See Section 4.4.2.1
more details
For multi-channel sessions, the ToC entries of all frames from
frame-block are placed in the ToC in consecutive order as defined
Section 4.1 in [24]. When multiple frame-blocks are present in
packet in bandwidth-efficient mode, they will be placed in the
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
from the first frame-block, the second N entries will be from
second frame-block, and so on
The following figure shows an example of a ToC of three entries in
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
a packet carrying 3 consecutive frame-blocks in a session with
channels (L and R).
+----+----+----+----+----+----+
| 1L | 1R | 2L | 2R | 3L | 3R |
+----+----+----+----+----+----+
|<------->|<------->|<------->|
Frame- Frame- Frame
Block 1 Block 2 Block 3
4.3.3. Speech
Speech data of a payload contains one or more speech frames
comfort noise frames, as described in the ToC of the payload
Note, for ToC entries with FT=14 or 15, there will be
corresponding speech frame present in the speech data
Sjoberg, et. al. Standards Track [Page 19]
RFC 3267 RTP Payload Format for AMR and AMR-WB June 2002
Each speech frame represents 20 ms of speech encoded with the
indicated in the FT field of the corresponding ToC entry. The
of the speech frame is implicitly defined by the mode indicated
the FT field. The order and numbering notation of the bits are
specified for Interface Format 1 (IF1) in [2] for AMR and [4]
AMR-WB. As specified there, the bits of speech frames have
rearranged in order of decreasing sensitivity, while the bits
comfort noise frames are in the order produced by the encoder.
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
The complete RTP payload in bandwidth-efficient mode is formed
packing bits from the payload header, table of contents, and
frames, in order as defined by their corresponding ToC entries in
ToC list, contiguously into octets beginning with the
significant bits of the fields and the octets
To be precise, the four-bit payload header is packed into the
octet of the payload with bit 0 of the payload header in the
significant bit of the octet. The four most significant
(numbered 0-3) of the first ToC entry are packed into the
significant bits of the octet, ending with bit 3 in the
significant bit. Packing continues in the second octet with bit 4
the first ToC entry in the most significant bit of the octet.
more than one frame is contained in the payload, then
continues with the second and successive ToC entries. Bit 0 of
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
order for each frame and in consecutive order of the frames
If speech data is missing for one or more speech frame within
sequence, because of, for example, DTX, a ToC entry with FT set
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
(see Section 4.3.5.2 for an example).
Sjoberg, et. al. Standards Track [Page 20]
RFC 3267 RTP Payload Format for AMR and AMR-WB June 2002
4.3.5 Payload
4.3.5.1. Single Channel Payload Carrying a Single
The following diagram shows a bandwidth-efficient AMR payload from
single channel session carrying a single speech frame-block
In the payload, no specific mode is requested (CMR=15), the
frame is not damaged at the IP origin (Q=1), and the coding mode
AMR 7.4 kbps (FT=4). The encoded speech bits, d(0) to d(147),
arranged in descending sensitivity order according to [2]. Finally
two zero bits are added to the end as padding to make the
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sjoberg, et. al. Standards Track [Page 21]
RFC 3267 RTP Payload Format for AMR and AMR-WB June 2002
4.3.5.2. Single Channel Payload Carrying Multiple
The following diagram shows a single channel, bandwidth
compound AMR-WB payload that contains four frames, of which one
no speech data. The first frame is a speech frame at 6.6 kbps
(FT=0) that is composed of speech bits d(0) to d(131). The
frame is an AMR-WB SID frame (FT=9), consisting of bits g(0)
g(39). The third frame is NO_DATA frame and does not carry
speech information, it is represented in the payload by its
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
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).
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
order according to [4]. (Note, no speech bits are present for
third frame). Finally, seven 0s are padded to the end to make
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sjoberg, et. al. Standards Track [Page 22]
RFC 3267 RTP Payload Format for AMR and AMR-WB June 2002
4.3.5.3. Multi-Channel Payload Carrying Multiple
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/
(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
(L) and right (R) in that order. The encoded speech bits
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
as d1L(0) to d1L(147).
Sjoberg, et. al. Standards Track [Page 23]
RFC 3267 RTP Payload Format for AMR and AMR-WB June 2002
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| d3R(147)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sjoberg, et. al. Standards Track [Page 24]
RFC 3267 RTP Payload Format for AMR and AMR-WB June 2002
4.4. Octet-aligned
4.4.1. The Payload
In octet-aligned mode, the payload header consists of a 4 bit CMR, 4
reserved bits, and optionally, an 8 bit interleaving header, as
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
ignored by the receiver
ILL (4 bits, unsigned integer): This is an OPTIONAL field that
present only if interleaving is signalled out-of-band for
session. ILL=L indicates to the receiver that the
length is L+1, in number of frame-blocks
ILP (4 bits, unsigned integer): This is an OPTIONAL field that
present only if interleaving is signalled. ILP MUST take a
between 0 and ILL, inclusive, indicating the interleaving
for frame-blocks in this payload in the interleave group. If
value of ILP is found greater than ILL, the payload SHOULD
discarded
ILL and ILP fields MUST be present in each packet in a session
interleaving is signalled for the session. Interleaving MUST
performed on a frame-block basis (i.e., NOT on a frame basis) in
multi-channel session
The following example illustrates the arrangement of speech frame
blocks in an interleave group during an interleave session. Here
assume ILL=L for the interleave group that starts at speech frame
block n. We also assume that the first payload packet of
interleave group is s and the number of speech frame-blocks
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):
Sjoberg, et. al. Standards Track [Page 25]
RFC 3267 RTP Payload Format for AMR and AMR-WB June 2002
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
inside an interleave group. In other words, all payloads in
interleave group MUST have the same ILL and MUST contain the
number of speech frame-blocks
The sender of the payload MUST only apply interleaving if
receiver has signalled its use through out-of-band means.
interleaving will increase buffering requirements at the receiver
the receiver uses MIME parameter "interleaving=I" to set the
number of frame-blocks allowed in an interleaving group to I
When performing interleaving the sender MUST use a proper number
frame-blocks per payload (N) and ILL so that the resulting size of
interleave group is less or equal to I, i.e., N*(L+1)<=I
4.4.2. The Payload Table of Contents and Frame
The table of contents (ToC) in octet-aligned mode consists of a
of ToC entries where each entry corresponds to a speech frame
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
corresponding speech frame or frame CRC present in the payload
The list of ToC entries is organized in the same way as described
bandwidth-efficient mode in 4.3.2, with the following exception;
interleaving is used the frame-blocks in the ToC will almost never
placed consecutive in time. Instead, the presence and order of
frame-blocks in a packet will follow the pattern described in 4.4.1.
Sjoberg, et. al. Standards Track [Page 26]
RFC 3267 RTP Payload Format for AMR and AMR-WB June 2002
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
before R, and the interleaving length is 3 (i.e., ILL=2). This
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.
Sjoberg, et. al. Standards Track [Page 27]
RFC 3267 RTP Payload Format for AMR and AMR-WB June 2002
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
signalled out-of-band for the session. When present, each CRC in
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
specified in the next section
4.4.2.1. Use of Frame CRC for UED over
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
octet-aligned payload header together with a partial transport
checksum to achieve UED
To achieve UED, one SHOULD use a transport layer checksum,
example, the one defined in UDP-Lite [15], to protect the RTP header
payload header, and table of contents bits in a payload. The
CRC, when used, MUST be calculated only over all class A bits in
frame. Class B and C bits in the frame MUST NOT be included in
CRC calculation and SHOULD NOT be covered by the transport checksum
Note, the number of class A bits for various coding modes in
codec is specified as informative in [2] and is therefore
into Table 1 in Section 3.6 to make it normative for this
format. The number of class A bits for various coding modes
AMR-WB codec is specified as normative in table 2 in [4], and
SID frame (FT=9) has 40 class A bits. These definitions of
A bits MUST be used for this payload format
Packets SHOULD be discarded if the transport layer checksum
errors
The receiver of the payload SHOULD examine the data integrity of
received class A bits by re-calculating the CRC over the
class A bits and comparing the result to the value found in
received payload header. If the two values mismatch, the
SHALL consider the class A bits in the receiver frame damaged
MUST clear the Q flag of the frame (i.e., set it to 0). This
subsequently cause the frame to be marked as SPEECH_BAD, if the FT
the frame is 0..7 for AMR or 0..8 for AMR-WB, or SID_BAD if the FT
the frame is 8 for AMR or 9 for AMR-WB, before it is passed to
speech decoder. See [6] and [7] more details
Sjoberg, et. al. Standards Track [Page 28]
RFC 3267 RTP Payload Format for AMR and AMR-WB June 2002
The following example shows an octet-aligned ToC with a CRC list
a payload containing 3 speech frames from a single channel
(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
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
the CRC shall be calculated, an XOR operation is made between
rightmost bit of the CRC register and the bit. The CRC register
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.
operation is repeated for each bit that the CRC should cover.
this case, the first bit would be d(0) for the speech frame for
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
calculation, the contents in CRC register should simply be copied
the corresponding field in the list of CRC's
Fast calculation of the CRC on a general-purpose CPU is
using a table-driven algorithm
Sjoberg, et. al. Standards Track [Page 29]
RFC 3267 RTP Payload Format for AMR and AMR-WB June 2002
4.4.3. Speech
In octet-aligned mode, speech data is carried in a similar way
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
at the end if not all bits in the octet are used. In
words, each speech frame MUST be octet-aligned
- When multiple speech frames are present in the speech
(i.e., compound payload), the speech frames can be
either one whole frame after another as usual, or with
octets of all frames interleaved together at the octet level
Since the bits within each frame are ordered with the
error-sensitive bits first, interleaving the octets
those sensitive bits from all frames to be nearer the
of the packet. This is called "robust sorting order"
allows the application of UED (such as UDP-Lite [15]) or
(such as the ULP [18]) mechanisms to the payload data.
details of assembling the payload are given in the
section
The use of robust sorting order for a session MUST be agreed
out-of-band means. Section 8 specifies a MIME parameter for
purpose
Note, robust sorting order MUST only be performed on the frame
and thus is independent of interleaving which is at the frame-
level, as described in Section 4.4.1. In other words, robust
can be applied to either non-interleaved or interleaved sessions
4.4.4. Methods for Forming the
Two different packetization methods, namely normal order and
sorting order, exist for forming a payload in octet-aligned mode.
both cases, the payload header and table of contents are packed
the payload the same way; the difference is in the packing of
speech frames
The payload begins with the payload header of one octet or two
frame interleaving is selected. The payload header is followed
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
with one 8-bit CRC filling each octet. Note that if a given
has a ToC entry with FT=14 or 15, there will be no CRC present
Sjoberg, et. al. Standards Track [Page 30]
RFC 3267 RTP Payload Format for AMR and AMR-WB June 2002
The speech data follows the table of contents, or the CRCs
present. For packetization in the normal order, all of the
comprising a speech frame are appended to the payload as a unit.
speech frames are packed in the same order as their corresponding
entries are arranged in the ToC list, with the exception that if
given frame has a ToC entry with FT=14 or 15, there will be no
octets present for that frame
For packetization in robust sorting order, the octets of all
frames are interleaved together at the octet level. That is,
data portion of the payload begins with the first octet of the
frame, followed by the first octet of the second frame, then
first octet of the third frame, and so on. After the first octet
the last frame has been appended, the cycle repeats with the
octet of each frame. The process continues for as many octets as
present in the longest frame. If the frames are not all the
octet length, a shorter frame is skipped once all octets in it
been appended. The order of the frames in the cycle will
sequential if frame interleaving is not in use, or according to
interleave pattern specified in the payload header if
interleaving is in use. Note that if a given frame has a ToC
with FT=14 or 15, there will be no data octets present for that
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
payload. Exactly how many octets need to be covered depends on
network and application. If CRCs are used together with
sorting, only the RTP header, the payload header, and the ToC
be covered by UED/UEP. The means to communicate to other
performing UED/UEP the number of octets to be covered is beyond
scope of this specification
Sjoberg, et. al. Standards Track [Page 31]
RFC 3267 RTP Payload Format for AMR and AMR-WB June 2002
4.4.5. Payload
4.4.5.1. Basic Single Channel Payload Carrying Multiple
The following diagram shows an octet aligned payload from a
channel session that carries two AMR frames of 7.95 kbps coding
(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
coding mode. No frame CRC, interleaving, or robust-sorting is
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
with one 0 to make it octet-aligned
4.4.5.2. Two Channel Payload with CRC, Interleaving, and Robust-
This example shows an octet aligned payload from a two
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),
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
the session. The interleaving length is 2 (ILL=1) and this
is the first one in an interleave group (ILP=0).
The first two frames in the payload are the L and R channel
frames of frame-block #1, consisting of bits f1L(0..158)
Sjoberg, et. al. Standards Track [Page 32]
RFC 3267 RTP Payload Format for AMR and AMR-WB June 2002
f1R(0..158), respectively. The next two frames are the L and
channel frames of frame-block #3, consisting of bits f3L(0..158)
f3R(0..158), respectively, due to interleaving. For each of the
speech frames a CRC is calculated as CRC1L(0..7), CRC1R(0..7),
CRC3L(0..7), and CRC3R(0..7), respectively. Finally, the payload
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
is padded with one zero bit to make it octet-aligned
4.5. Implementation
An application implementing this payload format MUST understand
the payload parameters in the out-of-band signaling used.
example, if an application uses SDP, all the SDP and MIME
in this document MUST be understood. This requirement ensures
an implementation always can decide if it is capable or not
communicating
No operation mode of the payload format is mandatory to implement
The requirements of the application using the payload format
be used to determine what to implement. To achieve
interoperability an implementation SHOULD at least implement
bandwidth-efficient and octet-aligned mode for single channel.
other operations mode: interleaving, robust sorting, frame-wise
in both single and multi-channel is OPTIONAL to implement
Sjoberg, et. al. Standards Track [Page 33]
RFC 3267 RTP Payload Format for AMR and AMR-WB June 2002
5. AMR and AMR-WB Storage
The storage format is used for storing AMR or AMR-WB speech frames
a file or as an e-mail attachment. Multiple channel content
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
implementations, single channel content uses a file header
