RFC 3267
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
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 ✨
Okay bestie, let's start with the basics 🎀. This is RFC 3267, published in June 2002 by the Network Working Group. It's a Standards Track doc, so it's an actual official protocol spec, not just a vibe. The authors are J. Sjoberg and M. Westerlund from Ericsson, A. Lakaniemi from Nokia, and Q. Xie from Motorola. It doesn't list anything it obsoletes or updates in its header 🧚.
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 💖
So this doc is all about getting AMR and AMR-WB speech (the codecs that handle voice) into RTP, which is the real-time transport protocol that carries audio and video. The payload format is built to play nicely with the existing AMR and AMR-WB transport formats on non-IP networks 🦋. It also specifies a file format for storing AMR and AMR-WB speech in storage mode apps like email 💌. Last but not least, there are two separate MIME type registrations, one for AMR and one for AMR-WB, covering 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.......................................491. Introduction 🌸
So this doc specifies how AMR and AMR-WB encoded speech gets packed up for the Real-time Transport Protocol (RTP) [8] 📦. The payload format supports multiple channels, multiple frames per payload, fast codec mode adaptation, robustness against packet loss and bit errors, and interop with existing AMR and AMR-WB transport formats on non-IP networks, which is explained in Section 3 🧠.
The payload format itself is in Section 4 💅. There's also a related file format in Section 5 for storing AMR and AMR-WB speech in storage mode apps like email. And in Section 8 you'll find the two separate MIME type registrations, one for AMR and one for AMR-WB 🎀.
Even though this one RTP payload format handles both AMR and AMR-WB speech, they are literally two different codecs 🙈. They are always handled as different payload types in RTP, so don't mix them up, bestie 🫶.
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] ✨.
Here are the acronyms you'll see around the doc 🍓:
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 ProtectionNow the term "frame-block" is the important one here 👑. It describes the time-synchronized set of speech frames in a multi-channel AMR or AMR-WB session. In an N-channel session, a frame-block has N speech frames, one from each channel, and all N frames cover exactly the same time period 🦋. Frame-blocks are how the channels stay in sync, so keep them in your mental stash 💜.
3. Background on AMR/AMR-WB and Design Principles 🌈
AMR and AMR-WB were originally designed for circuit-switched mobile radio systems 📱. Because they're so flexible and robust, they're also a great fit for other real-time speech services over packet-switched networks like the Internet ⭐.
These codecs are super flexible, so how they behave in a given application depends on a bunch of parameters. Those parameters pick options or set acceptable values for variables 🎛️. They're described in general terms throughout the text as parameters to be established through out-of-band means 🧚. In Section 8, all of the parameters show up as MIME subtype registrations for the AMR and AMR-WB encodings 💖.
How you signal those parameters at session setup, or agree on them ahead of time, is outside the scope of this document 🙈. That said, Section 8.3 maps the parameters into the Session Description Protocol (SDP) [11] for apps that use SDP 🫶.
3.1. The Adaptive Multi-Rate (AMR) Speech Codec 🎤
The AMR codec was originally developed and standardized by the European Telecommunications Standards Institute (ETSI) for GSM cellular systems. These days the Third Generation Partnership Project (3GPP) has picked it as the mandatory codec for third generation (3G) cellular systems [1] 📡.
AMR is a multi-mode codec with 8 narrowband speech encoding modes, with bit rates between 4.75 and 12.2 kbps 🔥. It samples at 8000 Hz and encodes speech in 20 ms frames. So each encoded AMR speech frame represents 160 samples of the original speech ✨.
Three of the 8 AMR encoding modes have already been adopted as standards of their own 👑. The 6.7 kbps mode became PDC-EFR [14], the 7.4 kbps mode became the IS-641 codec in TDMA [13], and the 12.2 kbps mode became 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 for use in GSM and 3G cellular systems 📶.
Just like AMR, AMR-WB is also a multi-mode speech codec 🦋. It supports 9 wideband speech coding modes, with bit rates from 6.6 to 23.85 kbps 💜. It samples at 16000 Hz and processes speech in 20 ms frames, which means each AMR-WB encoded frame represents 320 speech samples 🎀.
part 1 of 10 done 🫶 more parts coming, bestie!
3.3. Multi-rate Encoding and Mode Adaptation ✨
okay bestie, this is the multi-mode glow-up 💖 The multi-rate encoding (i.e., multi-mode) thing in AMR and AMR-WB exists to keep speech sounding amazing no matter what the network is doing 🦋
With AMR or AMR-WB, mobile radio systems can use the available bandwidth as efficiently as possible 🔥 For example, in GSM the speech encoding rate can change mid-session to keep up with shifting transmission conditions. The fixed overall bandwidth gets split between speech data and error protection coding, so you get the best possible balance between compression and error tolerance. To make the mode adaptation happen, the decoder (the speech receiver) has to tell the encoder (the speech sender) which new mode it prefers. That mode change signal is called Codec Mode Request, or CMR 💅
Most sessions have speech flowing both ways, so the mode requests from the decoder at one end to the encoder at the other end get piggy-backed onto the speech frames going the reverse direction 🎀 Which means there's no out-of-band signaling needed for sending CMRs. Iconic efficiency, no cap 😭
Every AMR or AMR-WB codec implementation is required to support all the respective speech coding modes defined by the codec, and it must be able to handle switching to any of those modes at any time 👑 BUT some transport systems come with limits on how many modes they can support and how often the mode is allowed to change, because of bandwidth limitations or other constraints 💀 So the decoder is allowed to indicate, using out-of-band means, that it accepts a particular mode or a subset of the defined modes for the session 🧚
For example, the GSM radio link can only use a subset of at most four different modes in a given session. That 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 🌸
Also, 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 mode changes to 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 the generation of comfort noise (CN) parameters during silence periods 🤫 So the codecs can cut the number of transmitted bits and packets during silence down to a minimum. Sending CN parameters at regular intervals during silence is usually called discontinuous transmission (DTX) or source controlled rate (SCR) operation ⭐ The AMR or AMR-WB frames that carry CN parameters are called Silence Indicator (SID) frames 🍓 For more on how VAD and DTX work, check [9] and [10].
3.5. Support for Multi-Channel Session 🎶
The RTP payload format and the storage format defined in this document both support multi-channel audio content, like a stereophonic speech session 🎧
Here's the tea: AMR and AMR-WB don't encode multi-channel audio into a single bit stream by themselves. But you can use them to separately encode and decode each individual channel, which is giving teamwork 🤝
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 get logically collected into a frame-block 🧩
At 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 the different channels in each frame-block. When SDP is used for signaling, the number of channels is specified in the rtpmap attribute, and the order of the 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 in each AMR or AMR-WB frame have different perceptual sensitivity to bit errors. Cellular systems have already exploited this to get better voice quality, using unequal error protection and detection (UEP and UED) mechanisms 🔥
UEP/UED focuses protection and detection on the perceptually most sensitive bits in an AMR or AMR-WB frame. The speech bits get divided into class A, B, and C, where class A bits are the most sensitive and class C bits are the least sensitive (see Table 1 below for AMR, and [4] for AMR-WB) 👑 A frame only gets declared damaged if bit errors are found in the most sensitive bits, the class A bits. Meanwhile, it's totally acceptable to have some bit errors in the 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.And a damaged frame is still useful for error concealment at the decoder, since some of the less sensitive bits can still be used. This can improve speech quality compared to just throwing the damaged frame away 🧚♀️
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 codecs, the RTP payload format is designed to make UEP/UED easier in an IP network. Just so you know, using UEP and UED as discussed below is OPTIONAL 🎀
UEP/UED in an IP network can be achieved by detecting bit errors in the class A bits, and tolerating bit errors in the class B/C bits of the AMR or AMR-WB frame(s) in each RTP payload 💖
Some link layers today don't discard packets with bit errors, like SLIP and some wireless links 📡 As Internet traffic shifts toward a more multimedia-centric pattern, more link layers like this may show up in the future 🌟 With transport layer support for partial checksums, such as the ones supported by UDP-Lite [15], bit error tolerant AMR and AMR-WB traffic could get better performance over these kinds of links 🦋
There are at least two basic approaches for carrying AMR and AMR-WB traffic over bit error tolerant IP networks:
- 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.
- 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 that's how 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 😬 So it's on the designer of a node with this type of link interface to choose a residual bit error rate that's 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, but it 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's the possibility that a single bit error in protected bits will cause all the frames to be discarded 🥲
Good news: these disadvantages can be avoided, if needed, with some overhead in the form of a frame-wise CRC (Approach 2) ✨ For 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 two approaches above must be made based on the available bandwidth and the desired tolerance to bit errors. Neither solution is appropriate for 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 to increase robustness against packet loss, including forward error correction (FEC) and frame interleaving 🦋
3.7.1. Use of Forward Error Correction (FEC) 🛡️
okay so the simplest FEC move is just repeating stuff you already sent, bestie 💖 but there's a more bandwidth efficient way too: payload external FEC, like RFC2733 [19], which makes extra packets full of repair data 🔧. You can also sort the whole payload by sensitivity so external FEC schemes can use UEP 👑. And there's a work in progress on a generic version of that scheme [18] that can be applied to AMR or AMR-WB payload transport 🌸
with AMR or AMR-WB, the codec's multi-rate thing lets you send redundant copies of the same mode, or of a different mode, like one with lower bandwidth 🦋 we're about to break that down, no cap ✨
so the idea is to retransmit previously sent frame-blocks together with the current frame-block(s) 🔁 the trick is a sliding window that groups the speech frame-blocks going into each payload. here's the vibe:
--+--------+--------+--------+--------+--------+--------+--------+--
| 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, every frame-block gets retransmitted one time in the next RTP payload packet 💅 f(n-2)..f(n+4) is the sequence of speech frame-blocks and p(n-1)..p(n+4) is the sequence of payload packets 🧚
the best part? this doesn't need any signaling at session setup 🙌 the speech sender can just start doing it without asking the receiver first, because a packet with redundant frames looks exactly like a packet with only new frames 🫶 the receiver might get multiple copies or versions of a frame for the same timestamp, encoded with different modes, if nothing got lost 😭 and if multiple versions of the same speech frame show up, the speech decoder should use the mode with the highest rate 🔥
this redundancy scheme does the same job as RFC 2198 "RTP Payload for Redundant Audio Data" [24] 💜 but in most cases this payload format's version is more efficient and simpler, because you don't need both endpoints supporting RFC 2198 on top of it 🌈 there are two situations where RFC 2198 is the move: if the time spread between the primary and redundant encodings is larger than 5 frame times, RFC 2198 has lower bandwidth overhead ⏱️ or, if you want a non-AMR codec for the redundant encoding, the AMR payload format can't carry it 🙈
the sender is responsible for picking the right amount of redundancy based on feedback about the channel, like RTCP receiver reports 📊 a sender should not base its FEC choice on the CMR, because that parameter was most probably set using non-IP info, like radio link performance measures 📡 and the sender is also responsible for avoiding congestion, which redundancy can make worse (see Section 6 for more details) 🚦
3.7.2. Use of Frame Interleaving 🧶
to cut protocol overhead, the payload design lets several speech frame-blocks get packed into a single RTP packet 📦 the catch is that if that packet gets lost, you lose several consecutive frame-blocks at once, which usually causes clearly audible distortion in the reconstructed speech 😩 interleaving fixes this by spreading consecutive losses out into a series of single frame-block losses ✨ but interleaving and bundling several frame-blocks per payload also bumps up end-to-end delay, so it's not right for every app 🐢 streaming apps will most likely be able to use interleaving to improve speech quality on lossy connections 🎬
this payload design supports frame interleaving as an option 🫧 for the encoder (the speech sender) to use it in its outbound RTP packets for a session, the decoder (the speech receiver) has to say it supports it through 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 gets set up for the session through out-of-band means 💫
in the octet-aligned format, every field in a payload gets individually aligned to octet boundaries (the payload header, the table of contents entries, and the speech frames themselves) so implementations stay efficient 🧩 in the bandwidth efficient format, only the full payload is octet aligned, so fewer padding bits get 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 can use 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 main 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 🦋
conversational services are picky 🥺 low delay is super important, which means few speech frame-blocks per payload packet ⚡ low overhead matters too, especially on low bandwidth links, since packets come in fast 📈 on those links, supporting UED is a big win, because it lets a link provider reduce delay and packet loss or cut down on link resource use 👑
streaming has less strict real-time needs, so it can fit more frame-blocks per packet than conversational does 🎬 that cuts down the overhead from IP, UDP, and RTP headers 💜 but packing several frame-blocks into one packet makes things more vulnerable to packet loss, so interleaving may be used to reduce how much that loss hurts speech quality 🧶 a streaming server handling tons of clients also needs a payload format that uses as few resources as possible during packetization 🖥️ the octet-aligned and interleaving modes need the least resources, while CRC, robust sorting, and bandwidth efficient modes have higher demands 📊
another scenario is when AMR or AMR-WB encoded speech gets sent from a non-IP system (like a GSM or 3GPP network) to an IP/UDP/RTP VoIP terminal, and/or the other way around, as 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 this case, the AMR or AMR-WB frame is probably packetized differently in the non-IP network, so it'll need to be re-packetized into RTP at the gateway 📦 also, speech frames coming from the non-IP network may carry some UEP/UED information (like a frame quality indicator) that needs to be kept and forwarded to the decoder along with the speech bits 🫶 this is specified in Section 4.3.2 📝
AMR's fast mode switching is used in some non-IP networks to make speech quality better ⚡ to keep that working in scenarios with a gateway to an IP network, a codec mode request (CMR) field is needed 🙌 the gateway is responsible for forwarding the CMR between the non-IP and IP parts, in both directions 🔁 the IP terminal should follow the CMR the gateway forwards, so speech quality going to the non-IP decoder gets optimized 🎯 the mode control algorithm in the gateway has to handle the delay the IP network adds to the IP terminal's response to CMR ⏳
the IP terminal should not set the CMR (see Section 4.3.1) 🙅♀️ but the gateway can set the CMR value on frames heading toward the encoder in the non-IP part, to optimize speech quality from that encoder to the gateway 🧚 or the gateway can set a lower CMR value if it wants, as one way to control congestion on the IP network 🚦
the third likely scenario is that IP/UDP/RTP is used as transport between two non-IP systems, so IP gets originated and terminated in gateways on both sides of the IP transport, as 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 needs the same mechanisms for keeping UED/UEP and CMR info as the single gateway scenario does 💅 on top of that, the CMR value may be set in packets the gateways receive on the IP network side 👀 the gateway should forward a CMR value to the non-IP side 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 up to the implementation 🛠️
4. AMR and AMR-WB RTP Payload Formats 🎀
the AMR and AMR-WB payload formats have identical structure, so they get specified together 👯♀️ the only differences are in the types of codec frames the payload carries 💜 the payload format is made up of the RTP header, payload header, and payload data 🧁
4.1. RTP Header Usage 💖
okay so the RTP header format is specified in [8], and this payload format uses the header fields in a way that matches that spec 🎀
The RTP timestamp is the sampling instant of the first sample encoded for the first frame-block in the packet. The timestamp clock runs at the same rate as the sampling frequency, so the timestamp counts in samples ✨
Each speech frame-block is 20 ms long for both AMR and AMR-WB. For AMR the sampling frequency is 8 kHz, so that's 160 encoded speech samples per frame from each channel. For AMR-WB it's 16 kHz, so 320 samples per frame from each channel. That means the timestamp goes up by 160 for AMR and 320 for AMR-WB with each consecutive frame-block 🦋
A packet can hold multiple frame-blocks of encoded speech or comfort noise parameters. If interleaving is in use, the frame-blocks put into a payload are picked by the interleaving rules in Section 4.4.1. Otherwise, each packet covers one or more contiguous 20 ms frame-block intervals. If the data from every channel for a particular frame-block is missing (for example at a gateway that's coming from some other transport format), you can say that no data is present for that frame-block, instead of splitting a multi-frame-block packet into two, as explained in Section 4.3.2 🌸
For error resiliency through redundant transmission, the periods covered by multiple packets MAY overlap in time. A receiver MUST be prepared to get any speech frame more than once, either as exact duplicates, in different AMR rate modes, or with data in one packet and not in another. If you get multiple versions of the same speech frame, it is RECOMMENDED that the speech decoder uses the mode with the highest rate. A given frame MUST NOT be encoded as speech in one packet and as comfort noise parameters in another 🫶
The payload is always made a whole number of octets by padding with zero bits if needed. If you need extra padding to get the payload length to a bigger multiple of octets, or for some other reason, the P bit in the RTP 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 in the packet has a speech frame that's the first in a talkspurt. For all other packets the marker bit SHALL be set to zero (M=0) 👑
Assigning an RTP payload type for this new packet format is outside the scope of this document, so it won't be specified here. The RTP profile this payload format is used under is expected to assign a payload type for this encoding, or to say the payload type gets bound dynamically 💅
4.2. Payload Structure 🧚
The full payload has a payload header, a payload table of contents, and speech data for one or more speech frame-blocks. Here's the general layout:
+----------------+-------------------+----------------
| payload header | table of contents | speech data ...
+----------------+-------------------+----------------Payloads with more than one speech frame-block are called compound payloads 💜
The next sections cover how the payload format changes depending on whether the AMR session is set up for bandwidth-efficient mode or octet-aligned mode, and on any of the OPTIONAL functions for robust sorting, interleaving, and frame CRCs. Implementations SHOULD support both bandwidth-efficient and octet-aligned operation to get better interoperability 🌈
4.3. Bandwidth-Efficient Mode ✨
4.3.1. The Payload Header 🎀
In bandwidth-efficient mode the payload header is just a 4 bit codec mode request:
0 1 2 3
+-+-+-+-+
| CMR |
+-+-+-+-+CMR (4 bits) is a codec mode request sent to the speech encoder at the receiver's site. The CMR value is set to the frame type index of the speech mode being requested. The frame type index can 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 means no mode request is present, and other values are reserved for future use 🦋
The mode request in the CMR field stays valid until the next CMR arrives, so a newer CMR value just overrides the old one. That means if a terminal wants to keep receiving frames in the same mode X, it has to set CMR=X in all its outbound payloads. And if a terminal doesn't care which mode it gets, it SHOULD set CMR=15 in all its outbound payloads 💖
If a receiver gets a payload with a CMR value that isn't a speech mode or NO_DATA, the receiver MUST ignore that CMR 🙈
In a multi-channel session, the receiver of the payload SHOULD read CMR 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, and here's why 😭
- The other end of the IP path might be a gateway to a non-IP network (like a radio link), and that network might need to set the CMR field to get the best performance on it.
- Congestion on the IP network is managed by the IP sender, which in this case is at the other end of the IP path. Congestion feedback SHOULD be given to that IP sender through RTCP or some other means. Then the sender can pick the most suitable way to avoid congestion. That could mean changing the codec mode, but it could also mean changing the amount of redundancy or the number of frames per packet 💅
The encoder SHOULD follow a received mode request, but it MAY switch to a lower-numbered mode if it wants to, 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 it's sending speech to a multicast session, but it MAY use RTCP feedback 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 it is, 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) is a list of ToC entries, and each entry represents one speech frame 🧚
In bandwidth-efficient mode, a ToC entry looks like this:
0 1 2 3 4 5
+-+-+-+-+-+-+
|F| FT |Q|
+-+-+-+-+-+-+F (1 bit): If it's set to 1, the frame is followed by another speech frame in this payload. If it's set to 0, this frame is the last frame in the payload 💜
FT (4 bits): The frame type index. It tells you the AMR or AMR-WB speech coding mode, or the comfort noise (SID) mode, of the frame carried in this payload 🌈
The FT value is defined in Table 1a in [2] for AMR, and in Table 1a in [4] for AMR-WB. FT=14 (SPEECH_LOST, only for AMR-WB) and FT=15 (NO_DATA) mean the frame is either lost or not being sent in this payload, respectively ✨
NO_DATA (FT=15) could mean either that the speech encoder didn't produce any data for that frame, or that no data for that frame is sent in the current payload. In the second case, valid data for that frame could show up in an earlier or later packet 🎀
If a receiver gets a ToC entry with an FT value in the range 9-14 for AMR, or 10-13 for AMR-WB, it SHOULD discard the whole packet. This keeps the depacketization process from losing data synchronization, which could cause a massive hit to speech quality 😭
Packets with only NO_DATA frames SHOULD NOT be transmitted. Frame-blocks with only NO_DATA frames at the end of a packet SHOULD NOT be transmitted either, except when interleaving is used. The AMR SCR/DTX is described in [6], and the AMR-WB SCR/DTX is described in [7] 🦋
The extra comfort noise frame types in Table 1a in [2] (that's GSM-EFR CN, IS-641 CN, and PDC-EFR CN) MUST NOT be used in this payload format. The reason is that the standardized AMR codec only has to implement the general AMR SID frame type, not the ones that come from the encodings it was built from 💅
Q (1 bit) is the frame quality indicator. If it's set to 0, the frame is severely damaged, and the receiver should set RX_TYPE (see [6]) to either SPEECH_BAD or SID_BAD, depending on the frame type (FT) 💀
The frame quality indicator is in there for interoperability with the ATM payload format described in ITU-T I.366.2, the UMTS Iu interface [16], and other transport formats. It lets damaged frames get passed to the speech decoder for error concealment, which can make speech quality better than just dropping those frames. See Section 4.4.2.1 for more details 🌸
For multi-channel sessions, the ToC entries for all frames in a frame-block go into the ToC in consecutive order, as defined in Section 4.1 in [24]. When a packet in bandwidth-efficient mode has multiple frame-blocks, they go into the packet in the order they were created 🫶
So with N channels and K speech frame-blocks in a packet, the ToC MUST have N*K entries. The first N entries come from the first frame-block, the next N entries come from the second frame-block, and so on 👑
Here's a ToC with 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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+And here's how the ToC entries show up in a packet carrying 3 consecutive frame-blocks in a two-channel session (L and R) 🍓
+----+----+----+----+----+----+
| 1L | 1R | 2L | 2R | 3L | 3R |
+----+----+----+----+----+----+
|<------->|<------->|<------->|
Frame- Frame- Frame-
Block 1 Block 2 Block 34.3.3. Speech Data 🧚
The speech data in a payload has one or more speech frames or comfort noise frames, as the payload's ToC describes 💖
Note, for ToC entries with FT=14 or 15, there's no matching speech frame in the speech data. 🙈
Each speech frame is 20 ms of speech encoded in the mode that the FT field of its ToC entry names. The frame's length is implied by that mode. The bit order and numbering are the same as Interface Format 1 (IF1) in [2] for AMR, and [4] for AMR-WB. As those specs say, the bits of speech frames are rearranged in order of decreasing sensitivity, while the bits of comfort noise frames stay in the order the encoder made them. The bit sequence for a frame of K bits is written d(0), d(1), ..., d(K-1) ✨
4.3.4. Algorithm for Forming the Payload ✨
okay so this is where the payload actually gets built, and it's giving precision 💅. In bandwidth-efficient mode, you take bits from the payload header, the table of contents, and the speech frames, and pack them in order (the order their ToC entries list them) into octets, back to back, starting with the most significant bits of each field and each octet 🫶.
Here's the exact bit-by-bit vibe 🔥. The four-bit payload header goes into the first octet, with bit 0 of the header sitting in the most significant bit of that octet. Then the four most significant bits (numbered 0-3) of the first ToC entry fill the least significant bits of that same octet, ending with bit 3 in the least significant bit. The packing carries on into the second octet, starting with bit 4 of the first ToC entry in its most significant bit. If there's more than one frame in the payload, the second and later ToC entries keep going the same way 🦋. Then bit 0 of the first data frame comes right after the last ToC bit, and the frame's bits go through in numerical order. Any later frames just follow on contiguously, in numerical order for each frame and in consecutive order of the frames ✨.
Now the plot twist 🙈. If speech data is missing for one or more speech frames in the sequence (because of DTX, for example), a ToC entry with FT set to NO_DATA SHALL be included in the ToC for each missing frame. But no data bits go into the payload for that 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 🦋
okay this one's the simplest. It shows a bandwidth-efficient AMR payload from a single channel session carrying one speech frame-block 🌸.
In this payload, no specific mode is requested (CMR=15), the speech frame isn't 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 get tacked on at the end as padding so the payload is 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 💖
this one is giving main character energy 👑. It's a single channel, bandwidth-efficient compound AMR-WB payload with four frames, and one of them has no speech data at all 💀.
Here's the breakdown. Frame one is a speech frame in 6.6 kbps mode (FT=0), made of speech bits d(0) to d(131). Frame two is an AMR-WB SID frame (FT=9), made of bits g(0) to g(39). Frame three is a NO_DATA frame, so it doesn't carry any speech info and is only represented by its ToC entry. Frame four is a speech frame in 8.85 kbps mode (FT=1), made of speech bits h(0) to h(176) 🍓.
The payload also asks the encoder on the receiver's side to switch 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]. Quick note: the third frame has no speech bits at all. Finally, seven 0s get padded onto 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 🧚♀️
this is the big one 🔥. It's a two channel payload carrying 3 frame-blocks, so the payload holds 6 speech frames total 🫶.
Every speech frame here uses the same mode, 7.4 kbit/s (FT=4), and none is damaged at IP origin. The CMR is 15, meaning no specific mode is requested. The two channels are defined as left (L) and right (R), in that order 🦋. The encoded speech bits are written as dXY(0)..dXY(K-1), where X is the block number, Y is the channel, and K is the number of speech bits for that mode. So for frame-block 1 on the left channel, the encoded bits are 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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| d3R(147)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+4.4. Octet-aligned Mode 🌸
4.4.1. The Payload Header ✨
Okay bestie, in octet-aligned mode the payload header is a 4 bit CMR, then 4 reserved bits, and then optionally an 8 bit interleaving header 🎀. It looks like this:
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 |
+-+-+-+-+-+-+-+-+- - - - - - - -Here's the breakdown 💅:
CMR (4 bits): same as defined in section 4.3.1 🌸R: is a reserved bit that MUST be set to zero. All R bits MUST be ignored by the receiver. Like, the receiver just ignores them, no drama 🙈ILL (4 bits, unsigned integer): this is an OPTIONAL field that is present only if interleaving is signalled out-of-band for the session.ILL=Ltells the receiver that the interleaving length is L+1, in number of frame-blocks 🧚ILP (4 bits, unsigned integer): this is also an OPTIONAL field, present only if interleaving is signalled. ILP MUST take a value between 0 and ILL, inclusive, and it tells you the interleaving index for frame-blocks in this payload in the interleave group. If the value of ILP is found greater than ILL, the payload SHOULD be discarded 💀
ILL and ILP fields MUST be present in each packet in a session if interleaving is signalled for the session. Interleaving MUST be performed on a frame-block basis (i.e., not on a frame basis) in a multi-channel session. Not frames, frame-blocks, periodt 👑
Now let's look at how the speech frame-blocks sit in an interleave group during an interleave session. We assume ILL=L for the interleave group that starts at speech frame-block n. We also assume that the first payload packet of the interleave group is s, and the number of speech frame-blocks carried in each payload is N. Then we get:
Payload s (the first packet of this interleave group):
ILL=L, ILP=0,
Carry frame-blocks: n, n+(L+1), n+2*(L+1), ..., n+(N-1)*(L+1)
Payload s+1 (the second packet of this interleave group):
ILL=L, ILP=1,
frame-blocks: n+1, n+1+(L+1), n+1+2*(L+1), ..., n+1+(N-1)*(L+1)
...
Payload s+L (the last packet of this interleave group):
ILL=L, ILP=L,
frame-blocks: n+L, n+L+(L+1), n+L+2*(L+1), ..., n+L+(N-1)*(L+1)The next interleave group will start at frame-block n+N*(L+1). Iykyk 🫶
There will be no interleaving effect unless the number of frame-blocks per packet (N) is at least 2. Moreover, the number of frame-blocks per payload (N) and the value of ILL MUST NOT be changed inside an interleave group. In other words, all payloads in an interleave group MUST have the same ILL and MUST contain the same number of speech frame-blocks. Consistency is everything 💖
The sender of the payload MUST only apply interleaving if the receiver has signalled its use through out-of-band means. Since interleaving will increase buffering requirements at the receiver, the receiver uses the MIME parameter "interleaving=I" to set the maximum number of frame-blocks allowed in an interleaving group to I. So the receiver is basically in control of its own buffer, obsessed 🙌
When performing interleaving, the sender MUST use a proper number of frame-blocks per payload (N) and ILL so that the resulting size of an interleave group is less or equal to I, i.e., N*(L+1)<=I. Math check passed ✨
4.4.2. The Payload Table of Contents and Frame CRCs 🦋
In octet-aligned mode, the table of contents (ToC) is a list of ToC entries, where each entry corresponds to a speech frame carried in the payload. Optionally, there's also a list of speech frame CRCs. It's stacked like this:
+---------------------+
| list of ToC entries |
+---------------------+
| list of frame CRCs | (optional)
- - - - - - - - - - -Note, for ToC entries with FT=14 or 15, there will be no corresponding speech frame or frame CRC present in the payload. Those ones are basically ghosts 👻
The list of ToC entries is organized in the same way as described for bandwidth-efficient mode in 4.3.2, with one exception: when interleaving is used, the frame-blocks in the ToC will almost never be placed consecutive in time. Instead, the presence and order of the frame-blocks in a packet will follow the pattern described in 4.4.1. Scattered but make it intentional 🌈
Here's the ToC of three consecutive packets, each carrying 3 frame-blocks, in an interleaved two-channel session. The two channels are left (L) and right (R), with L coming before R, and the interleaving length is 3 (i.e., ILL=2). That makes the interleave group 9 frame-blocks large 🍓
Packet #1
---------
ILL=2, ILP=0:
+----+----+----+----+----+----+
| 1L | 1R | 4L | 4R | 7L | 7R |
+----+----+----+----+----+----+
|<------->|<------->|<------->|
Frame- Frame- Frame-
Block 1 Block 4 Block 7
Packet #2
---------
ILL=2, ILP=1:
+----+----+----+----+----+----+
| 2L | 2R | 5L | 5R | 8L | 8R |
+----+----+----+----+----+----+
|<------->|<------->|<------->|
Frame- Frame- Frame-
Block 2 Block 5 Block 8
Packet #3
---------
ILL=2, ILP=2:
+----+----+----+----+----+----+
| 3L | 3R | 6L | 6R | 9L | 9R |
+----+----+----+----+----+----+
|<------->|<------->|<------->|
Frame- Frame- Frame-
Block 3 Block 6 Block 9A ToC entry takes the following format in octet-aligned mode:
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|F| FT |Q|P|P|
+-+-+-+-+-+-+-+-+F (1 bit): see definition in Section 4.3.2 💅FT (4 bits unsigned integer): see definition in Section 4.3.2 💅Q (1 bit): see definition in Section 4.3.2 💅P bits: padding bits, MUST be set to zero 🧸
The list of CRCs is OPTIONAL. It only exists if the use of CRC is signalled out-of-band for the session. When present, each CRC in the list is 8 bit long and corresponds to a speech frame (not a frame-block) carried in the payload. How the CRC gets calculated and used is specified in the next section, so keep reading bestie 🔥
4.4.2.1. Use of Frame CRC for UED over IP 🛡️
The general concept of UED/UEP over IP is discussed in Section 3.6. This section gives you more details on how to use the frame CRC in the octet-aligned payload header, together with a partial transport layer checksum, to achieve UED. Two tools, one goal 🎯
To achieve UED, one SHOULD use a transport layer checksum, for example the one defined in UDP-Lite [15], to protect the RTP header, payload header, and table of contents bits in a payload. The frame CRC, when used, MUST be calculated only over all class A bits in the frame. Class B and C bits in the frame MUST NOT be included in the CRC calculation, and they SHOULD NOT be covered by the transport checksum. Only class A gets the CRC spotlight ✨
Note, the number of class A bits for various coding modes in the AMR codec is specified as informative in [2], and is therefore copied into Table 1 in Section 3.6 to make it normative for this payload format. The number of class A bits for various coding modes in the AMR-WB codec is specified as normative in table 2 in [4], and the SID frame (FT=9) has 40 class A bits. These definitions of class A bits MUST be used for this payload format. Receipts, please 🧾
Packets SHOULD be discarded if the transport layer checksum detects errors. Fair and simple 🙅♀️
The receiver of the payload SHOULD examine the data integrity of the received class A bits by re-calculating the CRC over the received class A bits and comparing the result to the value found in the received payload header. If the two values mismatch, the receiver SHALL consider the class A bits in the receiver frame damaged, and MUST clear the Q flag of the frame (i.e., set it to 0). This will subsequently cause the frame to be marked as SPEECH_BAD, if the FT of the frame is 0..7 for AMR or 0..8 for AMR-WB, or as SID_BAD if the FT of the frame is 8 for AMR or 9 for AMR-WB, before it is passed to the speech decoder. See [6] and [7] for more details. Damaged frames get flagged, not hidden 😭
Here's an octet-aligned ToC with a CRC list for a payload containing 3 speech frames from a single channel session (assuming none of the FTs is equal to 14 or 15):
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| FT#1 |Q|P|P|1| FT#2 |Q|P|P|0| FT#3 |Q|P|P| CRC#1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CRC#2 | CRC#3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Each of the CRCs takes 8 bits:
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| c0| c1| c2| c3| c4| c5| c6| c7|
+---+---+---+---+---+---+---+---+and it's calculated using the cyclic generator polynomial:
C(x) = 1 + x^2 + x^3 + x^4 + x^8where ^ is the exponentiation operator. In binary form the polynomial looks like this: 101110001 (MSB..LSB). Math is giving main character energy 🧮
Now the actual calculation, step by step 🎀. First, an 8-bit CRC register is reset to zero: 00000000. For each bit over which the CRC shall be calculated, an XOR operation is made between the rightmost bit of the CRC register and the bit. Then the CRC register is right shifted one step, inputting a "0" as the leftmost bit. If the result of the XOR operation mentioned above is a "1", then "10111000" is bit-wise XOR-ed into the CRC register. You repeat this for each bit the CRC should cover. The first bit is d(0) for the speech frame the CRC covers. When the last bit (e.g., d(54) for AMR 5.9 according to Table 1 in Section 3.6) has been used in this CRC calculation, the contents of the CRC register should simply be copied to the corresponding field in the list of CRCs. Copy, paste, done 💖
Fast calculation of the CRC on a general-purpose CPU is possible using a table-driven algorithm. CPUs said "lookup tables are the move" 🧚
4.4.3. Speech Data 🎶
In octet-aligned mode, speech data is carried in a similar way to bandwidth-efficient mode, as discussed in Section 4.3.3, with the following exceptions:
- The last octet of each speech frame MUST be padded with zeroes at the end if not all bits in the octet are used. In other words, each speech frame MUST be octet-aligned. Every frame gets its octet-aligned glow-up 🌸
- When multiple speech frames are present in the speech data (i.e., a compound payload), the speech frames can be arranged either one whole frame after another as usual, or with the octets of all frames interleaved together at the octet level. Since the bits within each frame are ordered with the most error-sensitive bits first, interleaving the octets collects those sensitive bits from all frames to be nearer the beginning of the packet. This is called "robust sorting order," which allows the application of UED (such as UDP-Lite [15]) or UEP (such as the ULP [18]) mechanisms to the payload data. The details of assembling the payload are given in the next section. Sensitive bits up front, the protective squad is ready 🛡️
The use of robust sorting order for a session MUST be agreed via out-of-band means. Section 8 specifies a MIME parameter for this purpose 🔑
Note, robust sorting order MUST only be performed on the frame level, and thus is independent of interleaving, which is at the frame-block level, as described in Section 4.4.1. In other words, robust sorting can be applied to either non-interleaved or interleaved sessions. Two separate features, zero drama between them 💅
4.4.4. Methods for Forming the Payload
okay bestie, so octet-aligned mode has two packetization methods 🌸: normal order and robust sorting order 🦋. both of them pack the payload header and table of contents the exact same way. the only difference is how the speech frames get packed 💅
the payload starts with the payload header, which is one octet, or two if frame interleaving is selected ✨. after that comes the table of contents, a list of one-octet ToC entries 🎀. if frame CRCs are included, they sit right after the table of contents, with one 8-bit CRC per octet 💖. quick heads up: if a frame has a ToC entry with FT=14 or 15, there's no CRC for it 🙈
the speech data comes after the table of contents (or after the CRCs, if they're there) 🧚. in normal order, all the octets of a speech frame get appended as one chunk 🍓. the frames go in the same order as their ToC entries, except if a frame has FT=14 or 15, it gets no data octets at all 💀
robust sorting order is where it gets iconic 🔥. here, the octets of all the speech frames get interleaved at the octet level. so the data portion starts with the first octet of the first frame, then the first octet of the second frame, then the first octet of the third frame, and so on 🌈. once the first octet of the last frame is in, the cycle starts over with the second octet of each frame. this keeps going for as many octets as the longest frame has 💜. if the frames aren't all the same length, a shorter frame just gets skipped once all of its octets are in ⭐. the order of frames in the cycle is sequential when frame interleaving isn't used, and follows the interleave pattern in the payload header when it is 👑. same deal as before: an FT=14 or 15 frame has no data octets, so it gets skipped in the robust sorting cycle too 🫶
okay the important bit 🌈 UED and/or UEP is RECOMMENDED to cover at least the RTP header, payload header, table of contents, and class A bits of a sorted payload 🎀. how many octets actually need covering depends on the network and the application 🦋. if CRCs are used together with robust sorting, then only the RTP header, the payload header, and the ToC SHOULD be covered by UED/UEP 💅. how the other layers doing UED/UEP get told how many octets to cover is outside the scope of this spec 🙈
4.4.5. Payload Examples
4.4.5.1. Basic Single Channel Payload Carrying Multiple Frames
this diagram shows an octet-aligned payload from a single channel session carrying two AMR frames in the 7.95 kbps coding mode (FT=5) 🌸. the payload has a codec mode request (CMR=6), asking the encoder on the receiver's side to switch to the AMR 10.2 kbps coding mode 💖. no frame CRC, interleaving, or robust sorting is in use here ✨
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 the example above, the last octet of both speech frames is padded with one 0 so it's octet-aligned 🫶
4.4.5.2. Two Channel Payload with CRC, Interleaving, and Robust-sorting
this one is a whole vibe 🦋. it shows an octet-aligned payload from a two channel session with two frame-blocks, each holding 2 speech frames in the 7.95 kbps coding mode (FT=5) 💅
the channels are left (L) and right (R), and L always comes before R 🎀. the payload also has a codec mode request (CMR=6), asking the encoder on the receiver's side to use AMR 10.2 kbps coding mode 🌈
on top of that, frame CRC and frame-block interleaving are both turned on for this session 🔥. the interleaving length is 2 (ILL=1), and this payload is the first one in its interleave group (ILP=0) 👑
the first two frames in the payload are the L and R channel speech frames of frame-block #1, made of bits f1L(0..158) and f1R(0..158) 🧚. the next two frames are the L and R channel frames of frame-block #3, made of bits f3L(0..158) and f3R(0..158), because of the interleaving 💜. each of the four speech frames gets a CRC, called CRC1L(0..7), CRC1R(0..7), CRC3L(0..7), and CRC3R(0..7) respectively 🍓. last step: the payload gets 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 this example, the last octet of all four speech frames is padded with one zero bit so it's octet-aligned 💖
4.5. Implementation Considerations
okay this part is the real talk 🫶. any app implementing this payload format MUST understand all the payload parameters in the out-of-band signaling it uses 🔥. for example, if the app uses SDP, then all the SDP and MIME parameters in this document MUST be understood 👑. this is what makes sure an implementation can always tell whether it's capable of communicating or not 💅
no operation mode of the payload format is mandatory to implement 🌈. the requirements of the app using the payload format are what decide what you implement 🧚. for basic interoperability, an implementation SHOULD at least implement both bandwidth-efficient and octet-aligned mode for single channel 🎀. the other operation modes, which are interleaving, robust sorting, and frame-wise CRC in both single and multi-channel, are OPTIONAL to implement 🦋
5. AMR and AMR-WB Storage Format
the storage format is for keeping AMR or AMR-WB speech frames in a file or as an e-mail attachment 📎🌸. multiple channel content is supported ✨
generally, an AMR or AMR-WB file has this structure 💖:
+------------------+
| Header |
+------------------+
| Speech frame 1 |
+------------------+
: ... :
+------------------+
| Speech frame n |
+------------------+note 📝 single channel content uses a different file header format from multi-channel content, and that's on purpose, so it stays interoperable with implementations already out there 🫶
5.1. Single channel Header
a single channel AMR or AMR-WB file header has only a magic number 🧚, and different magic numbers tell AMR apart from AMR-WB 💜
the magic number for single channel AMR files MUST consist of this ASCII string 🍓:
"#!AMR\n"(or 0x2321414d520a in hexadecimal)
the magic number for single channel AMR-WB files MUST consist of this ASCII string 🌈:
"#!AMR-WB\n"(or 0x2321414d522d57420a in hexadecimal)
note 📝 the "\n" is a super important part of the magic numbers and it MUST be included in the comparison 🙈. without it, the single channel magic numbers would be totally indistinguishable from the multi-channel files in the next section 💀
5.2. Multi-channel Header
the multi-channel header is a magic number followed by a 32 bit channel description field 🎀, so it looks like this 🦋:
+------------------+
| magic number |
+------------------+
| chan-desc field |
+------------------+the magic number for multi-channel AMR files MUST consist of this ASCII string 💅:
"#!AMR_MC1.0\n"(or 0x2321414d525F4D43312E300a in hexadecimal)
the magic number for multi-channel AMR-WB files MUST consist of this ASCII string 👑:
"#!AMR-WB_MC1.0\n"(or 0x2321414d522d57425F4D43312E300a in hexadecimal)
the version number in these magic numbers refers to the version of the file format 🧚
the 32 bit channel description field is laid out like this ✨:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved bits | CHAN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Reserved bits: MUST be set to 0 when written, and a reader MUST ignore them 🙈
CHAN (4 bit unsigned integer): this tells you how many audio channels are in this storage file 🌸. the valid values and the order of the channels inside a frame block are specified in Section 4.1 in [24] 💖
5.3. Speech Frames 🎀
okay so after the file header, the speech frame-blocks get stored one after another in time order 💖 each frame-block is a bundle of octet-aligned speech frames, one for every channel, stored in increasing order starting with channel 1 🫶
every stored speech frame opens with a one-octet frame header, and it looks like this:
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|P| FT |Q|P|P|
+-+-+-+-+-+-+-+-+the FT field and the Q bit work exactly the way they do in Section 4.1.2 🦋 the P bits are padding and they MUST be set to 0, no exceptions bestie 💅
after that one-octet header come the speech bits from 4.3.3 ✨ if the last octet needs it, it gets padded with zeroes so everything stays octet-aligned 🌸
here's an example of an AMR frame in the 5.9 kbit coding mode (with 118 speech bits) in storage format 🧚
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|P| FT=2 |Q|P|P| |
+-+-+-+-+-+-+-+-+ +
| |
+ Speech bits for frame-block n, channel k +
| |
+ +-+-+
| |P|P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+now the important bit 😭 frame-blocks or speech frames that get lost in transmission, plus the non-received frame-blocks between SID updates during non-speech periods, MUST be stored as NO_DATA frames (frame type 15, as defined in [2] and [4]) or SPEECH_LOST (frame type 14, only available for AMR-WB) in complete frame-blocks. that's how the storage stays in sync with the original media 🔥
6. Congestion Control 🌈
the general congestion control stuff for sending RTP data totally applies to AMR or AMR-WB speech over RTP too 💜 but here's the lowkey superpower: the multi-rate thing in AMR and AMR-WB speech coding can help you manage congestion better than other payload formats, because you can change the bandwidth demand just by picking a different coding mode 🦋
another knob is how many frame-blocks get packed into each RTP payload ✨ packing more frame-blocks into each payload means fewer packets, so less overhead from the IP/UDP/RTP headers, but the trade-off is more delay 🍓
if you use forward error correction (FEC) to fight packet loss, the redundancy FEC adds has to be regulated so that FEC itself doesn't become a congestion problem 💀
it is RECOMMENDED that AMR or AMR-WB applications using this payload format employ congestion control 👑 the spec doesn't pin down the actual mechanism, but it should be suitable for real-time flows, e.g., "Equation-Based Congestion Control for Unicast Applications" [17] 🫶
7. Security Considerations 🔒
RTP packets using the payload format defined here are subject to the general security considerations discussed in [8] 💅
since this format carries encoded speech, the main security issues are the confidentiality and authentication of the speech itself 😭 the payload format doesn't have any built-in security mechanisms of its own. external mechanisms, such as SRTP [22], MAY be used 🧚
the receiver-side computational complexity for packet processing doesn't show any significant non-uniformity with this payload format, so it's unlikely to be a denial-of-service threat from receiving pathological data 🌸
7.1. Confidentiality 🤫
to get confidentiality for the encoded AMR or AMR-WB speech, all the speech data bits will need to be encrypted 🔐 the payload header and the table of contents don't need encrypting as much, because 1) they only carry information about the requested speech mode, frame type, and frame quality, and 2) that info could be useful to some third party, e.g., for quality monitoring 🦋
as long as the AMR or AMR-WB payload only gets packed and unpacked at either end, encryption can happen after packet encapsulation, so the two operations don't clash 💖
interleaving can affect encryption ✨ depending on the encryption scheme, there may be restrictions on things like when keys can be changed. specifically, the key change may need to happen at the boundary between interleave groups 🎀
the encryption method you pick can also affect how robust the payload data is to errors 💀 error robustness can get severely reduced when the data is encrypted, unless you use an encryption method without error-propagation, e.g., a stream cipher. so UED/UEP based on robust sorting may be difficult to apply when the payload data is encrypted 🙈
7.2. Authentication 🔑
to authenticate the sender of the speech, you have to use an external mechanism 🫶 it is RECOMMENDED that such a mechanism protects all the speech data bits. heads up that using UED/UEP may be difficult to combine with authentication, because any bit errors will make authentication fail 😭
data tampering by a man-in-the-middle attacker could lead to erroneous depacketization/decoding, which could lower the speech quality 💀 tampering with the CMR field may result in speech at a different quality than you wanted 🙈
to stop a man-in-the-middle attacker from tampering with the payload packets, some extra info besides the speech bits SHOULD be protected 🛡️ this can include the payload header, ToC, frame CRCs, RTP timestamp, RTP sequence number, and the RTP marker bit 👑
7.3. Decoding Validation ✅
when a receiver processes a payload packet, it checks whether the calculated payload length (based on the session info and the values in the payload header fields) matches the size of the received packet 👀 if it doesn't match, the receiver SHOULD discard the packet, because decoding a packet with errors in its length field could seriously degrade the speech quality 🥲
8. Payload Format Parameters 🎀
this section defines the parameters that can be used to pick optional features of the AMR and AMR-WB payload formats 🦋 the parameters are defined here as part of the MIME subtype registrations for the AMR and AMR-WB speech codecs. there's also a mapping of the parameters into the Session Description Protocol (SDP) [11] for apps that use SDP ✨ equivalent parameters could be defined somewhere else for use with control protocols that don't use MIME or SDP 🌸
two separate MIME registrations are made, one for AMR and one for AMR-WB, because they're distinct encodings that must be told apart by the MIME subtype 💅
the data format and parameters are specified for both real-time transport in RTP and for storage-type applications, like e-mail attachments 💜
8.1. AMR MIME Registration ✨
okay so the MIME subtype for the Adaptive Multi-Rate (AMR) codec comes from the IETF tree 🌳, because AMR is expected to be a super popular speech codec for general VoIP apps 🎧. This registration covers both real-time transfer over RTP and non-real-time transfer via stored files 💅.
Note, any unspecified parameter MUST be ignored by the receiver. 🙅♀️
Media Type name: audio 🎀
Media subtype name: AMR 🦋
Required parameters: none 🌸
Optional parameters:
These parameters only apply to RTP transfer 📡.
octet-align🧩: the only allowed values are 0 and 1. If it's 1, octet-aligned operation SHALL be used. If it's 0 or not there at all, bandwidth efficient operation is employed.mode-set👑: this is the requested AMR mode set, basically the decoder's VIP list of modes. It restricts the active codec mode set to a subset of all modes. Possible values are a comma separated list of modes from the set: 0,...,7 (see Table 1a [2]). If the decoder specifies a mode set like this, the encoder MUST abide by the request and MUST NOT use modes outside of the subset 🚫. If it's not present, all codec modes are allowed for the session.mode-change-period⏰: specifies a number of frame-blocks, N, which is the interval at which codec mode changes are allowed. The initial phase of the interval is arbitrary, but changes must be separated by multiples of N frame-blocks. If this parameter isn't present, mode changes are allowed at any time during the session 🌈.mode-change-neighbor🏠: the allowed values are 0 and 1. If it's 1, mode changes SHALL only be made to the neighboring modes in the active codec mode set. Neighbors are the modes closest in bit rate to the current mode, either the next higher or next lower rate. If it's 0 or not present, changing between any two modes in the active codec mode set is allowed 🔁.maxptime📦: the maximum amount of media that can be packed into one payload packet, written as time in milliseconds. The time is the sum of the time the media in the packet represents. The time SHOULD be a multiple of the frame size. If this parameter isn't present, the sender MAY pack any number of speech frames into one RTP packet 💫.crc🔐: the allowed values are 0 and 1. If it's 1, frame CRCs SHALL be included in the payload, otherwise they're not. Ifcrc=1, octet-aligned operation SHALL automatically be used for the session too 🧠.robust-sorting🪄: the allowed values are 0 and 1. If it's 1, the payload SHALL employ robust payload sorting. If it's 0 or not present, simple payload sorting SHALL be used. Ifrobust-sorting=1, octet-aligned operation SHALL automatically be used for the session as well ✨.interleaving🧵: indicates that frame-block level interleaving SHALL be used for the session, and its value sets the maximum number of frame-blocks allowed in an interleaving group (see Section 4.4.1). If this parameter isn't present, interleaving SHALL not be used. Having this parameter also automatically means octet-aligned operation SHALL be used 💖.ptime⏱️: see RFC2327 [11].channels🎶: the number of audio channels. The possible values and their channel order are specified in section 4.1 in [24]. If it's omitted, the default value is 1.
Encoding considerations: this type is defined for transfer via both RTP (RFC 1889) and stored-file methods, as described in Sections 4 and 5, respectively, of RFC 3267. Audio data is binary data, so it has to be encoded for non-binary transport, and Base64 encoding is suitable for Email 📧.
Security considerations: see Section 7 of RFC 3267 🔒.
Public specification: please refer to Section 11 of RFC 3267 📖.
Additional information:
The following applies to stored-file transfer methods 🗂️:
Magic numbers:
single channel:
ASCII character string "#!AMR\n"
(or 0x2321414d520a in hexadecimal)
multi-channel:
ASCII character string "#!AMR_MC1.0\n"
(or 0x2321414d525F4D43312E300a in hexadecimal)File extensions: amr, AMR 🎵
Macintosh file type code: none
Object identifier or OID: none
Person & email address to contact for further information:
johan.sjoberg@ericsson.com
ari.lakaniemi@nokia.comIntended usage: COMMON. It's expected that many VoIP applications (as well as mobile applications) will use this type 📱💕.
Author/Change controller:
johan.sjoberg@ericsson.com
ari.lakaniemi@nokia.com
IETF Audio/Video transport working group8.2. AMR-WB MIME Registration 🌷
the MIME subtype for the Adaptive Multi-Rate Wideband (AMR-WB) codec is also allocated from the IETF tree 🌳, since AMR-WB is expected to be a widely used speech codec in general VoIP apps too 🎧. This registration covers both real-time transfer over RTP and non-real-time transfer via stored files 🫶.
Note, any unspecified parameter MUST be ignored by the receiver. 🙅♀️
Media Type name: audio 🎀
Media subtype name: AMR-WB 🦋
Required parameters: none 🌸
Optional parameters:
These parameters only apply to RTP transfer 📡.
octet-align🧩: the allowed values are 0 and 1. If it's 1, octet-aligned operation SHALL be used. If it's 0 or not there at all, bandwidth efficient operation is employed.mode-set👑: this is the requested AMR-WB mode set, the decoder's VIP list of modes again 💅. It restricts the active codec mode set to a subset of all modes. Possible values are a comma separated list of modes from the set: 0,...,8 (see Table 1a [4]). If the decoder specifies a mode set like this, the encoder MUST abide by the request and MUST NOT use modes outside of the subset 🚫. If it's not present, all codec modes are allowed for the session.mode-change-period⏰: specifies a number of frame-blocks, N, which is the interval at which codec mode changes are allowed. The initial phase of the interval is arbitrary, but changes must be separated by multiples of N frame-blocks. If this parameter isn't present, mode changes are allowed at any time during the session 🌈.mode-change-neighbor🏠: the allowed values are 0 and 1. If it's 1, mode changes SHALL only be made to the neighboring modes in the active codec mode set. Neighbors are the modes closest in bit rate to the current mode, either the next higher or next lower rate. If it's 0 or not present, changing between any two modes in the active codec mode set is allowed 🔁.maxptime📦: the maximum amount of media that can be packed into one payload packet, written as time in milliseconds. The time is the sum of the time the media in the packet represents. The time SHOULD be a multiple of the frame size. If this parameter isn't present, the sender MAY pack any number of speech frames into one RTP packet 💫.crc🔐: the allowed values are 0 and 1. If it's 1, frame CRCs SHALL be included in the payload, otherwise they're not. Ifcrc=1, octet-aligned operation SHALL automatically be used for the session too 🧠.robust-sorting🪄: the allowed values are 0 and 1. If it's 1, the payload SHALL employ robust payload sorting. If it's 0 or not present, simple payload sorting SHALL be used. Ifrobust-sorting=1, octet-aligned operation SHALL automatically be used for the session as well ✨.interleaving🧵: indicates that frame-block level interleaving SHALL be used for the session, and its value sets the maximum number of frame-blocks allowed in an interleaving group (see Section 4.4.1). If this parameter isn't present, interleaving SHALL not be used. Having this parameter also automatically means octet-aligned operation SHALL be used 💖.ptime⏱️: see RFC2327 [11].channels🎶: the number of audio channels. The possible values and their channel order are specified in section 4.1 in [24]. If it's omitted, the default value is 1.
Encoding considerations: this type is defined for transfer via both RTP (RFC 1889) and stored-file methods, as described in Sections 4 and 5, respectively, of RFC 3267. Audio data is binary data, so it has to be encoded for non-binary transport, and Base64 encoding is suitable for Email 📧.
Security considerations: see Section 7 of RFC 3267 🔒.
Public specification: please refer to Section 11 of RFC 3267 📖.
Additional information:
The following applies to stored-file transfer methods 🗂️:
Magic numbers:
single channel:
ASCII character string "#!AMR-WB\n"
(or 0x2321414d522d57420a in hexadecimal)
multi-channel:
ASCII character string "#!AMR-WB_MC1.0\n"
(or 0x2321414d522d57425F4D43312E300a in hexadecimal)File extensions: awb, AWB 🎵
Macintosh file type code: none
Object identifier or OID: none
Person & email address to contact for further information:
johan.sjoberg@ericsson.com
ari.lakaniemi@nokia.comIntended usage: COMMON. It's expected that many VoIP applications (as well as mobile applications) will use this type 📱💕.
Author/Change controller:
johan.sjoberg@ericsson.com
ari.lakaniemi@nokia.com
IETF Audio/Video transport working group8.3. Mapping MIME Parameters into SDP 🎀
Okay so the MIME media type info has a specific mapping onto SDP fields [11], which is the Session Description Protocol that people use to describe RTP sessions 🦋. When SDP sets up an AMR or AMR-WB session, it goes like this:
- The MIME type ("audio") goes in SDP "m=" as the media name. 💖
- The MIME subtype (payload format name) goes in SDP "a=rtpmap" as the encoding name. The RTP clock rate in "a=rtpmap" MUST be 8000 for AMR and 16000 for AMR-WB, and the encoding parameters (number of channels) MUST either be explicitly set to N or omitted, implying a default value of 1. The values of N that are allowed is specified in Section 4.1 in [24]. 🌸
- The parameters "ptime" and "maxptime" go in the SDP "a=ptime" and "a=maxptime" attributes, respectively. ✨
- Any remaining parameters go in the SDP "a=fmtp" attribute by copying them straight from the MIME media type string as a semicolon separated list of parameter=value pairs. 🧚
Here are some example SDP session descriptions using AMR and AMR-WB encodings. In these examples, the long a=fmtp lines are folded to fit the column width of this document. The backslash ("") at the end of a line, and the carriage return that follows it, should be ignored. 🙈
Example of AMR in a possible GSM gateway scenario:
m=audio 49120 RTP/AVP 97
a=rtpmap:97 AMR/8000/1
a=fmtp:97 mode-set=0,2,5,7; mode-change-period=2; \
mode-change-neighbor=1
a=maxptime:20Example of AMR-WB in a possible VoIP scenario:
m=audio 49120 RTP/AVP 98
a=rtpmap:98 AMR-WB/16000
a=fmtp:98 octet-align=1Example of AMR-WB in a possible streaming scenario (two channel stereo):
m=audio 49120 RTP/AVP 99
a=rtpmap:99 AMR-WB/16000/2
a=fmtp:99 interleaving=30
a=maxptime:100Note that payload format (encoding) names are usually shown in upper case, and MIME subtypes are usually shown in lower case. These names are case-insensitive in both places. Parameter names are also case-insensitive, both in MIME types and in the default mapping to the SDP a=fmtp attribute. 💅
9. IANA Considerations 🌈
Two new MIME subtypes have been registered, see Section 8. A new SDP attribute "maxptime", defined in Section 8, has also been registered. The "maxptime" attribute is expected to be defined in the revision of RFC 2327 [11], and it's added here with a consistent definition. 📝
10. Acknowledgements 🫶
The authors would like to thank Petri Koskelainen, Bernhard Wimmer, Tim Fingscheidt, Sanjay Gupta, Stephen Casner, and Colin Perkins for their significant contributions made throughout the writing and reviewing of this document. Iconic squad 👑✨
11. References 📚
- [1] 3GPP TS 26.090, "Adaptive Multi-Rate (AMR) speech transcoding", version 4.0.0 (2001-03), 3rd Generation Partnership Project (3GPP).
- [2] 3GPP TS 26.101, "AMR Speech Codec Frame Structure", version 4.1.0 (2001-06), 3rd Generation Partnership Project (3GPP).
- [3] 3GPP TS 26.190 "AMR Wideband speech codec; Transcoding functions", version 5.0.0 (2001-03), 3rd Generation Partnership Project (3GPP).
- [4] 3GPP TS 26.201 "AMR Wideband speech codec; Frame Structure", version 5.0.0 (2001-03), 3rd Generation Partnership Project (3GPP).
- [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [6] 3GPP TS 26.093, "AMR Speech Codec; Source Controlled Rate operation", version 4.0.0 (2000-12), 3rd Generation Partnership Project (3GPP).
- [7] 3GPP TS 26.193 "AMR Wideband Speech Codec; Source Controlled Rate operation", version 5.0.0 (2001-03), 3rd Generation Partnership Project (3GPP).
- [8] Schulzrinne, H, Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996.
- [9] 3GPP TS 26.092, "AMR Speech Codec; Comfort noise aspects", version 4.0.0 (2001-03), 3rd Generation Partnership Project (3GPP).
- [10] 3GPP TS 26.192 "AMR Wideband speech codec; Comfort Noise aspects", version 5.0.0 (2001-03), 3rd Generation Partnership Project (3GPP).
- [11] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
- [24] Schulzrinne, H., "RTP Profile for Audio and Video Conferences with Minimal Control" RFC 1890, January 1996.
11.1 Informative References 🧐
- [12] GSM 06.60, "Enhanced Full Rate (EFR) speech transcoding", version 8.0.1 (2000-11), European Telecommunications Standards Institute (ETSI).
- [13] ANSI/TIA/EIA-136-Rev.C, part 410 - "TDMA Cellular/PCS - Radio Interface, Enhanced Full Rate Voice Codec (ACELP)." Formerly IS-641. TIA published standard, June 1 2001.
- [14] ARIB, RCR STD-27H, "Personal Digital Cellular Telecommunication System RCR Standard", Association of Radio Industries and Businesses (ARIB).
- [15] Larzon, L., Degermark, M. and S. Pink, "The UDP Lite Protocol", Work in Progress.
- [16] 3GPP TS 25.415 "UTRAN Iu Interface User Plane Protocols", version 4.2.0 (2001-09), 3rd Generation Partnership Project (3GPP).
- [17] S. Floyd, M. Handley, J. Padhye, J. Widmer, "Equation-Based Congestion Control for Unicast Applications", ACM SIGCOMM 2000, Stockholm, Sweden .
- [18] Li, A., et. al., "An RTP Payload Format for Generic FEC with Uneven Level Protection", Work in Progress.
- [19] Rosenberg, J. and H. Schulzrinne, "An RTP Payload Format for Generic Forward Error Correction", RFC 2733, December 1999.
- [20] 3GPP TS 26.102, "AMR speech codec interface to Iu and Uu", version 4.0.0 (2001-03), 3rd Generation Partnership Project (3GPP).
- [21] 3GPP TS 26.202 "AMR Wideband speech codec; Interface to Iu and Uu", version 5.0.0 (2001-03), 3rd Generation Partnership Project (3GPP).
- [22] Baugher, et. al., "The Secure Real Time Transport Protocol", Work in Progress.
- [23] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., Handley, M., Bolot, J., Vega-Garcia, A. and S. Fosse-Parisis, "RTP Payload for Redundant Audio Data", RFC 2198, September 1997.
ETSI documents can be downloaded from the ETSI web server, "http://www.etsi.org/". Any 3GPP document can be downloaded from the 3GPP webserver, "http://www.3gpp.org/", see specifications. TIA documents can be obtained from "www.tiaonline.org".
12. Authors' Addresses 💌
Johan Sjoberg
Ericsson Research
Ericsson AB
SE-164 80 Stockholm, SWEDEN
Phone: +46 8 50878230
EMail: Johan.Sjoberg@ericsson.com
Magnus Westerlund
Ericsson Research
Ericsson AB
SE-164 80 Stockholm, SWEDEN
Phone: +46 8 4048287
EMail: Magnus.Westerlund@ericsson.com
Ari Lakaniemi
Nokia Research Center
P.O.Box 407
FIN-00045 Nokia Group, FINLAND
Phone: +358-71-8008000
EMail: ari.lakaniemi@nokia.com
Qiaobing Xie
Motorola, Inc.
1501 W. Shure Drive, 2-B8
Arlington Heights, IL 60004, USA
Phone: +1-847-632-3028
EMail: qxie1@email.mot.com13. Full Copyright Statement ⚖️
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement 🌷
Funding for the RFC Editor function is currently provided by the Internet Society. That's the whole RFC, bestie! 🦄💜
📦 where this page comes from
- ietf: rfc3267 2002-07
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms