RFC 4867
RTP Payload Format and File Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs
RFC 4867: The Speech Codec Gossip File 🎙️🦋
okay bestie, grab a seat, because this one is a whole vibe. RFC 4867 was published in April 2007 by the IETF's Network Working Group. The authors are J. Sjoberg and M. Westerlund from Ericsson, A. Lakaniemi from Nokia, and Q. Xie from Motorola. It's on the Standards Track 🔥, and it obsoletes RFC 3267. It doesn't update anything else. It's all about RTP payload formats and a file storage format for the AMR and AMR-WB audio codecs 🎀
Status of This Memo ✨
This document is an Internet standards track protocol for the Internet community, and it asks for discussion and suggestions for improvements. If you want to know where this protocol stands in standardization, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 💅
Copyright Notice 📜
Copyright (C) The IETF Trust (2007).
Abstract 🌸
So the big picture is this: the RFC defines a Real-time Transport Protocol (RTP) payload format for AMR and AMR-WB encoded speech signals 🎤 The payload format is built to interoperate with existing AMR and AMR-WB transport formats on non-IP networks, which is honestly so thoughtful 🥹 It also specifies a file format for moving AMR and AMR-WB speech data around in storage mode apps, like email 📧 There are two separate media type registrations, one for AMR and one for AMR-WB, and each covers both the RTP payload format and the storage format. And yes, this document obsoletes RFC 3267 💖
Table of Contents
1. Introduction ....................................................4
2. Conventions and Acronyms ........................................4
3. Background on AMR/AMR-WB and Design Principles ..................5
3.1. The Adaptive Multi-Rate (AMR) Speech Codec .................5
3.2. The Adaptive Multi-Rate Wideband (AMR-WB) Speech Codec .....6
3.3. Multi-Rate Encoding and Mode Adaptation ....................6
3.4. Voice Activity Detection and Discontinuous Transmission ....7
3.5. Support for Multi-Channel Session ..........................7
3.6. Unequal Bit-Error Detection and Protection .................8
3.6.1. Applying UEP and UED in an IP Network ...............8
3.7. Robustness against Packet Loss ............................10
3.7.1. Use of Forward Error Correction (FEC) ..............10
3.7.2. Use of Frame Interleaving ..........................12
3.8. Bandwidth-Efficient or Octet-Aligned Mode .................12
3.9. AMR or AMR-WB Speech over IP Scenarios ....................13
4. AMR and AMR-WB RTP Payload Formats .............................15
4.1. RTP Header Usage ..........................................15
4.2. Payload Structure .........................................17
4.3. Bandwidth-Efficient Mode ..................................17
4.3.1. The Payload Header .................................17
4.3.2. The Payload Table of Contents ......................18
4.3.3. Speech Data ........................................20
4.3.4. Algorithm for Forming the Payload ..................21
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 ....................31
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
4.5.1. Decoding Validation ................................34
5. AMR and AMR-WB Storage Format ..................................35
5.1. Single-Channel Header .....................................35
5.2. Multi-Channel Header ......................................36
5.3. Speech Frames .............................................37
6. Congestion Control .............................................38
7. Security Considerations ........................................38
7.1. Confidentiality ...........................................39
7.2. Authentication and Integrity ..............................39
8. Payload Format Parameters ......................................39
8.1. AMR Media Type Registration ...............................40
8.2. AMR-WB Media Type Registration ............................44
8.3. Mapping Media Type Parameters into SDP ....................47
8.3.1. Offer-Answer Model Considerations ..................48
8.3.2. Usage of Declarative SDP ...........................50
8.3.3. Examples ...........................................51
9. IANA Considerations ............................................53
10. Changes from RFC 3267 .........................................53
11. Acknowledgements ..............................................55
12. References ....................................................55
12.1. Normative References .....................................55
12.2. Informative References ...................................561. Introduction 🦋
Okay so first things first: this document obsoletes RFC 3267, and it also extends that spec with offer/answer rules 🙌 If you want to see what changed compared to RFC 3267, check out Section 10. Iconic behavior from the authors, honestly.
This document is the payload format for packing AMR and AMR-WB encoded speech signals into the Real-time Transport Protocol (RTP) [8] 🎧 It supports transmission of multiple channels, multiple frames per payload, fast codec mode adaptation, robustness against packet loss and bit errors, and interoperation with existing AMR and AMR-WB transport formats on non-IP networks. All of that is covered in Section 3 ✨
The payload format itself lives in Section 4. Section 5 has the related file format for moving AMR and AMR-WB speech data around in storage mode apps like email 📧 And in Section 8 you'll find two separate media type registrations, one for AMR and one for AMR-WB 💜
Now the important bit 👑 Even though this RTP payload format handles both AMR and AMR-WB speech, AMR and AMR-WB are two different codecs. They are always handled as different payload types in RTP. Never 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 RFC 2119 [5]. That's the official rulebook for how these words hit in a spec, so it's worth knowing 🤓
Here are the acronyms the document uses:
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 here's a term you'll see everywhere 💅 A "frame-block" is 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 of them represent exactly the same time period. Basically they're besties who always show up at the same moment 👯♀️
Quick note on bit and byte order, because it matters for reading the figures. The byte order is network byte order, which means the most significant byte goes first. The bit order is also most significant bit first. In all figures, the most significant bit sits leftmost on a line and has the lowest number. Some bit fields wrap across multiple lines, and in that case the bits on the first line are more significant than the bits on the next line. Read those diagrams carefully 🧚
3. Background on AMR/AMR-WB and Design Principles 🎀
Let's talk history, because it's actually kinda fascinating. AMR and AMR-WB were originally designed for circuit-switched mobile radio systems 📱 Thanks to their flexibility and robustness, they're also suitable for other real-time speech communication services over packet-switched networks, like the Internet 🌐
Because these codecs are so flexible, the behavior in a given application is controlled by several parameters. Those parameters select options or specify acceptable values for a variable. They're described in general terms at the right points in the text as parameters to be established through out-of-band means. In Section 8, all of the parameters appear in the form of media subtype registrations for the AMR and AMR-WB encodings 📝 How you signal these parameters at session setup, or how participants agree on them ahead of time, is out of scope for this document. However, Section 8.3 maps the parameters into the Session Description Protocol (SDP) [11] for applications 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. Then the Third Generation Partnership Project (3GPP) chose it as the mandatory codec for third generation (3G) cellular systems [1]. Main character origin story energy 👑
The AMR codec is a multi-mode codec. It supports eight narrow band speech encoding modes with bit rates between 4.75 and 12.2 kbps 🌈 The sampling frequency is 8000 Hz, and speech encoding is performed on 20 ms speech frames. So each encoded AMR speech frame represents 160 samples of the original speech. Math that slaps 🧮
Three of the eight AMR encoding modes are already adopted as standards of their own, and they're iconic in their own right ✨ The 6.7 kbps mode is adopted as PDC-EFR [18]. The 7.4 kbps mode is adopted as the IS-641 codec in TDMA [17]. And the 12.2 kbps mode is adopted as GSM-EFR [16]. Three legends, three standards 🔥
3.2. The Adaptive Multi-Rate Wideband (AMR-WB) Speech Codec 🎀
Okay so the Adaptive Multi-Rate Wideband (AMR-WB) speech codec [3] was originally developed by 3GPP for GSM and 3G cellular systems. Iconic origin story 🌸
Just like AMR, AMR-WB is also a multi-mode speech codec, so it's giving the same flexible energy 💅. It supports nine wideband speech coding modes, with bit rates ranging from 6.6 to 23.85 kbps. The sampling frequency is 16000 Hz, and the speech processing happens on 20 ms frames. So each AMR-WB encoded frame represents 320 speech samples 🧚
3.3. Multi-Rate Encoding and Mode Adaptation 🦋
The multi-rate encoding (aka multi-mode) capability of AMR and AMR-WB is built for keeping high speech quality no matter how rough the transmission conditions get. Main character resilience 👑
With AMR or AMR-WB, mobile radio systems can use the available bandwidth as efficiently as possible. For example, in GSM you can dynamically adjust the speech encoding rate during a session so it keeps adapting to changing transmission conditions, by splitting the fixed overall bandwidth between speech data and error protective coding. This gives the best possible trade-off between speech compression rate and error tolerance 🔥. To do mode adaptation, the decoder (the speech receiver) needs to signal the encoder (the speech sender) the new mode it prefers. This mode change signal is called Codec Mode Request, or CMR 💜.
Since speech usually goes both ways in most sessions, the mode requests from the decoder at one end to the encoder at the other end are piggy-backed over the speech frames travelling in the reverse direction. In other words, there's no out-of-band signaling needed for sending CMRs. No extra channel, no drama 🙈
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. However, some transport systems may impose limits on how many modes are supported and how often the mode can change, because of bandwidth limitations or other constraints. For this reason, the decoder is allowed to indicate its acceptance of a particular mode, or a subset of the defined modes, for the session using out-of-band means 🫶
For example, the GSM radio link can only use a subset of at most four different modes in a given session. That subset can be any combination of the eight AMR modes for an AMR session, or any combination of the nine AMR-WB modes for an AMR-WB session 🍓
Moreover, for better interoperability with GSM through a gateway, the decoder is allowed to use out-of-band means to set the minimum number of frames between two mode changes, and to limit mode changes to neighboring modes only ✨
Section 8 specifies a set of media type parameters that MAY be used to signal these mode adaptation controls at session setup. Settings up front, bestie 💖
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 🤫. The operation of sending CN parameters at regular intervals during silence periods is usually called discontinuous transmission (DTX), or source controlled rate (SCR) operation. The AMR or AMR-WB frames that contain CN parameters are called Silence Indicator (SID) frames. For more on the VAD and DTX functionality, see [9] and [10] 📚
3.5. Support for Multi-Channel Session 🎶
Both the RTP payload format and the storage format defined in this document support multi-channel audio content (e.g., a stereophonic speech session) 🎧
Although the AMR and AMR-WB codecs themselves don't support encoding multi-channel audio into a single bit stream, they can be used to encode and decode each individual channel separately. Workaround energy ✨
To transport (or store) the separately encoded multi-channel content, the speech frames for all channels that are framed and encoded for the same 20 ms periods are logically collected 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 [12] 📝
3.6. Unequal Bit-Error Detection and Protection 💅
The speech bits encoded in each AMR or AMR-WB frame have different perceptual sensitivity to bit errors. Cellular systems have exploited this property to get better voice quality, using unequal error protection and detection (UEP and UED) mechanisms 🔐
The UEP/UED mechanisms focus protection and detection of corrupted bits on the perceptually most sensitive bits in an AMR or AMR-WB frame. Specifically, speech bits in an AMR or AMR-WB frame are divided into class A, B, and C, where class A bits are the most sensitive and class C bits the least sensitive (see Table 1 below for AMR and [4] for AMR-WB). An AMR or AMR-WB frame is only declared damaged if bit errors are found in the most sensitive bits, i.e., the class A bits. On the other hand, it's acceptable to have some bit errors in the other bits, i.e., class B and C bits 🙌
Class A Total speech
Index Mode bits bits
----------------------------------------
0 AMR 4.75 42 95
1 AMR 5.15 49 103
2 AMR 5.9 55 118
3 AMR 6.7 58 134
4 AMR 7.4 61 148
5 AMR 7.95 75 159
6 AMR 10.2 65 204
7 AMR 12.2 81 244
8 AMR SID 39 39
Table 1. The number of class A bits for the AMR codecMoreover, a damaged frame is still useful for error concealment at the decoder, since some of the less sensitive bits can still be used. This approach can improve speech quality compared to discarding the damaged frame 🌸
3.6.1. Applying UEP and UED in an IP Network 🌐
To take full advantage of the bit-error robustness of the AMR and AMR-WB codecs, the RTP payload format is designed to make UEP/UED possible in an IP network. It should be noted, however, that using the UEP and UED 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-layer protocols don't discard packets containing bit errors, e.g., SLIP and some wireless links. As internet traffic shifts toward a more multimedia-centric pattern, more link layers of this nature may emerge in the future 🚀. With transport layer support for partial checksums (for example, the ones supported by UDP-Lite [19]), bit-error-tolerant AMR and AMR-WB traffic could achieve better performance over these types of links. The relationship between UDP-Lite's partial checksum at the transport layer and the checksum coverage provided by the link-layer frame is described in the UDP-Lite specification [19] 🧠
There are at least two basic approaches for carrying AMR and AMR-WB traffic over bit-error-tolerant IP networks:
a) Utilizing a partial checksum to cover the IP, transport protocol (e.g., UDP-Lite), RTP and payload headers, and the most important speech bits of the payload. The IP, UDP and RTP headers need to be protected, and it is RECOMMENDED that at least all class A bits are covered by the checksum 🛡️
b) Utilizing a partial checksum to only cover the IP, transport protocol, RTP and payload headers, but an AMR or AMR-WB 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 so bit error tolerance is achieved ✨
Note, it is still important that the network designer pays 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 the Universal Mobile Telecommunications System (UMTS) can be found in [24], and for AMR-WB in [25] 🚨
The application interface to the UEP/UED transport protocol (e.g., UDP-Lite) may not provide any control over the link error rate, especially in a gateway scenario. Therefore, it is incumbent upon the designer of a node with a link interface of this type to choose a residual bit error rate that is low enough to support applications such as AMR encoding when transmitting packets of a UEP/UED transport protocol 🙏
Approach 1 is 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 AMR or AMR-WB frames in an RTP payload, there is the possibility that a single bit error in protected bits will cause all the frames to be discarded 😭
These disadvantages can be avoided, if needed, with some overhead in the form of a frame-wise CRC (Approach 2). 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 improves speech quality when transporting multiple AMR or AMR-WB frames over links subject to bit errors 💜
The choice between the above two approaches 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 choose between these approaches 🦋
3.7. Robustness against Packet Loss 🌧️
The payload format supports several means, including forward error correction (FEC) and frame interleaving, to increase robustness against packet loss 🛟
3.7.1. Use of Forward Error Correction (FEC) 🦋
okay so the simplest FEC trick ever is just sending stuff you already sent again 🥹 but there's a cuter way that's way more bandwidth efficient: payload-external FEC, like RFC 2733 [23], 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 [22] that can be applied to AMR or AMR-WB payload transport ✨
ok but here's the main character move 👑 With AMR or AMR-WB, you can use the multi-rate feature of the codec to send redundant copies of a frame, either in the same mode or in another mode, like a lower-bandwidth one 🌸 We'll get into how that works next 🫶
So this involves simply retransmitting previously sent frame-blocks along with the current frame-block(s) 💖 It's done with a sliding window that groups the speech frame-blocks going into each payload 🧚 Figure 1 shows an example, and it's giving very clear vibes 🍓
--+--------+--------+--------+--------+--------+--------+--------+--
| 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 transmissionIn this example, every frame-block gets retransmitted one time in the next RTP payload packet 🦋 Here f(n-2)..f(n+4) is a run of speech frame-blocks, and p(n-1)..p(n+4) is a run of payload packets 💜
Here's the best part 🙌 This approach doesn't need any signaling at session setup! The maximum delay allowed for sending any redundant frame lives in Section 8, though 📌 So a speech sender can totally use this scheme without checking with the receiver first 😭 A packet with redundant frames looks exactly like a packet with only new frames, so nobody can tell the difference 🙈 If no packets get lost, the receiver might get multiple copies or versions of a frame for the same timestamp (encoded with different modes) ✨ If it does get multiple versions of the same speech frame, it's recommended that the decoder use the mode with the highest rate 🔥
This redundancy scheme gives you the same functionality as RFC 2198, "RTP Payload for Redundant Audio Data" [27] 💅 But in most cases, this payload format's mechanism is more efficient and simpler than making both endpoints support RFC 2198 as well 🌈 There are two situations where RFC 2198 is the better pick 🫶 First, if the time spread needed between the primary and redundant encodings is more than the duration of 5 frames, RFC 2198's bandwidth overhead will be lower ⭐ Second, 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 an appropriate 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 based on non-IP information, like radio link performance measures 🙅♀️ 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 down on protocol overhead, the payload design lets several speech frame-blocks get packed into a single RTP packet 🎀 The catch is that if one packet gets lost, you can lose several consecutive speech frame-blocks at once, and that usually causes clearly audible distortion in the reconstructed speech 😭 Interleaving fixes this by spreading those 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 application 🙃 Streaming apps are the most likely to use interleaving well to improve speech quality in lossy conditions 🌊
This payload design supports frame interleaving as an option 💜 If the encoder (speech sender) wants to use frame interleaving in its outbound RTP packets for a given session, the decoder (speech receiver) has to say it supports that 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 set up for that session through out-of-band means 💅
In the octet-aligned format, the payload header, table of contents entries, and speech frames themselves are all individually aligned to octet boundaries, which makes implementations 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 modes, only the octet-aligned mode can use robust sorting, interleaving, and frame CRC to make speech transport more robust against 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 scenarioA conversational service has some strict requirements on the payload format 📞 Low delay is super important, which means few speech frame-blocks per payload packet ⏱️ Low overhead also matters when the payload format crosses low bandwidth links, especially since packets come thick and fast 💨 For low bandwidth links, supporting UED is a real perk too, because it lets a link provider reduce delay and packet loss, or cut back on link resource usage 🌷
A streaming service has way less strict real-time needs, so it can put more frame-blocks in each packet than a conversational service can 🎬 That cuts the overhead from IP, UDP, and RTP headers 🧁 BUT stuffing several frame-blocks into one packet makes transmission more vulnerable to packet loss, so interleaving can be used to soften the hit to speech quality 🫠 A streaming server handling tons of clients also needs a payload format that uses as few resources as possible when packetizing 🖥️ The octet-aligned and interleaving modes need the least resources, while CRC, robust sorting, and bandwidth-efficient modes are more demanding 💪
Another scenario is when AMR or AMR-WB encoded speech gets sent from a non-IP system (like a GSM or 3GPP UMTS network) to an IP/UDP/RTP VoIP terminal, and/or the other way around, as shown 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/ | IP network
3GPP UMTS network |
Figure 3: GW to VoIP terminal scenarioIn 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 from the non-IP network might come with some UEP/UED information (like a frame quality indicator) that needs to be preserved 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 optimize speech quality 🏎️ To keep that working when there's 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 forwarded by the gateway to optimize speech quality going to the non-IP decoder 🎯 The mode control algorithm in the gateway has to account for 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 to the encoder in the non-IP part, to optimize speech quality from that encoder to the gateway ✨ The gateway can also set a lower CMR value, if it wants, as one way to control congestion on the IP network 🚦
A third likely scenario is IP/UDP/RTP being used as transport between two non-IP systems, meaning IP is originated and terminated in gateways on both sides of the IP transport, as drawn 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/ | IP network | GSM/
3GPP UMTS network | | 3GPP UMTS network
Figure 4: GW to GW scenarioThis scenario needs the same mechanisms for keeping UED/UEP and CMR information as the single gateway scenario does 🔐 On top of that, the CMR value may be set in packets that the gateways receive on the IP network side 📦 The gateway should forward to the non-IP side a CMR value that is the minimum of three values 🧮:
- the CMR value it receives on the IP side;
- the CMR value it calculates based on its reception quality on the non-IP side; and
- a CMR value it may choose for congestion control of transmission on the IP side.
The details of the control algorithm are left 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 🎀 Bestie, you already know the drill.
The RTP timestamp matches 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 unit is samples. Iconic.
One speech frame-block is 20 ms long for both AMR and AMR-WB 🦋 For AMR the sampling frequency is 8 kHz, which means 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. The math is literally so clean 😭
A packet can hold multiple frame-blocks of encoded speech or comfort noise parameters 🧚 If interleaving is in use, the frame-blocks in a payload get picked according to the interleaving rules in Section 4.4.1. Otherwise, each packet covers one or more contiguous 20 ms frame-block intervals. Now, if the data from all the channels for a particular frame-block is missing (like at a gateway 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. More on that 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 ready to get any speech frame more than once: as exact duplicates, in different AMR rate modes, or with data in one packet and not in another. If multiple versions of the same speech frame show up, it is RECOMMENDED that the speech decoder use the mode with the highest rate 👑 And a given frame MUST NOT be encoded as speech in one packet and as comfort noise parameters in another. Not allowed, periodt 🙅♀️
The payload length is always an integral number of octets, padded with zero bits if needed 💜 If you need extra padding to hit a bigger multiple of octets or for some other reason, you can set the P bit in the RTP header and append padding as specified in [8]. Simple.
The RTP header marker bit (M) SHALL be set to 1 if the first frame-block in the packet contains a speech frame that is the first in a talkspurt ✨ For all other packets, the marker bit SHALL be set to zero (M=0). Strict, but make it make sense 🫶
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 specify that the payload type gets bound dynamically. Not our problem, bestie, it's the profile's job 💅
4.2. Payload Structure 🌈
The complete payload is 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 describe how the payload format changes depending on whether the AMR session is set up for bandwidth-efficient mode or octet-aligned mode, plus any OPTIONAL functions for robust sorting, interleaving, and frame CRCs 💖 Implementations SHOULD support both bandwidth-efficient and octet-aligned operation to boost interoperability. Team player energy 🫶
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 the codec mode request sent to the speech encoder at the receiver's site 🎯 Its 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 the other values are reserved for future use 🌙
The codec mode request in the CMR field stays valid until the next one arrives. That means a newly received CMR value for a speech mode, or NO_DATA, overrides the previously received CMR value for a speech mode or NO_DATA 🔄 So if a terminal keeps wanting to receive frames in the same mode X, it needs to set CMR=X on every outbound payload. And if a terminal doesn't care which mode it gets, it SHOULD set CMR=15 in all its outbound payloads. No preference, no problem 🍓
If a payload comes in with a CMR value that isn't a speech mode or NO_DATA, the receiver MUST ignore the CMR 🙈
In a multi-channel session, the receiver of the payload SHOULD interpret the codec mode request as the desired encoding mode for all the channels in the session 🎶
An IP end-point SHOULD NOT set the codec mode request based on packet losses or other congestion indications, and there are a few reasons why 😤
- The other end of the IP path might be a gateway to a non-IP network (like a radio link) that needs to set the CMR field to optimize performance on that network 📡
- Congestion on the IP network is managed by the IP sender, which in this case is at the other end of the IP path 🌊 Feedback about congestion SHOULD be sent to that IP sender through RTCP or other means, and then the sender can pick the most appropriate way to avoid congestion. That might mean adjusting the codec mode, but it can also mean adjusting the level of redundancy or the number of frames per packet 💜
The encoder SHOULD follow a received codec 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 codec mode requests when sending speech to a multicast session, but it MAY use RTCP feedback information as a hint that a codec mode change is needed. Multicast is its own vibe 🦋
The codec mode selection MAY be restricted by a session parameter to a subset of the available modes 🎀 If that happens, the requested mode MUST be among the signalled subset (see Section 8). And if the received CMR value is outside the signalled subset of modes, it MUST be ignored 🙅♀️
4.3.2. The Payload Table of Contents 📜
The table of contents (ToC) is a list of ToC entries, and each one represents a 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 this payload 🏁
FT (4 bits): The frame type index, which tells you either the AMR or AMR-WB speech coding mode, or the comfort noise (SID) mode, of the matching frame carried in this payload 🎵
The value of FT is defined in Table 1a in [2] for AMR and in Table 1a in [4] for AMR-WB. FT=14 (SPEECH_LOST, only available for AMR-WB) and FT=15 (NO_DATA) are used to flag frames that are either lost or not being transmitted in this payload, respectively 💀
NO_DATA (FT=15) could mean one of two things: either the speech encoder didn't produce any data for that frame, or the data for that frame isn't being sent in the current payload. In the second case, valid data for that frame could show up in an earlier or later packet 🔍
If you receive a ToC entry with an FT value in the range 9-14 for AMR or 10-13 for AMR-WB, the whole packet SHOULD be discarded 🚫 This keeps the depacketization process from losing data synchronization, which could cause a huge drop in speech quality 😱
Note that packets with only NO_DATA frames SHOULD NOT be transmitted in any payload format configuration, except when interleaving 🙅♀️ Also, frame-blocks with only NO_DATA frames at the end of a packet SHOULD NOT be transmitted in any payload format configuration, except when interleaving. 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] (GSM-EFR CN, IS-641 CN, and PDC-EFR CN) MUST NOT be used in this payload format. The standardized AMR codec is only required to implement the general AMR SID frame type, not the ones native to the incorporated encodings 🙃
Q (1 bit): The frame quality indicator. If it's set to 0, the corresponding frame is severely damaged, and the receiver should set the RX_TYPE (see [6]) to either SPEECH_BAD or SID_BAD, depending on the frame type (FT) 💔
The frame quality indicator is there for interoperability with the ATM payload format described in ITU-T I.366.2, the UMTS Iu interface [20], and other transport formats 🌐 It lets damaged frames get forwarded to the speech decoder for error concealment, which can improve speech quality more than dropping the damaged frames would. See Section 4.4.2.1 for more details ✨
For multi-channel sessions, the ToC entries of all frames from one frame-block are placed in the ToC in consecutive order, as defined in Section 4.1 in [12] 🎶 When multiple frame-blocks are in a packet in bandwidth-efficient mode, they get placed in order of their creation time ⏰
So with N channels and K speech frame-blocks in a packet, there MUST be N*K entries in the ToC. The first N entries come from the first frame-block, the next N from the second frame-block, and so on 🧮
Here's an example of 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 look in a packet carrying three 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 ✨
okay so speech data is the part of a payload that holds zero or more speech frames or comfort noise frames, and the ToC tells you which is which 🎀
ngl this is the one to remember: for ToC entries with FT=14 or 15, there's NO speech frame in the speech data at all 💀
each speech frame is 20 ms of speech encoded in whatever mode the FT field of its ToC entry says. the length of the frame is implied by that mode, so you don't need to store it separately 🧚 the bits follow Interface Format 1 (IF1) from [2] for AMR and [4] for AMR-WB. the bits in speech frames have been shuffled into decreasing sensitivity (the important stuff goes first, iykyk), but comfort noise frames keep the order the encoder made them in. for a frame of K bits, the bit sequence is written as d(0), d(1), ..., d(K-1) 💜
4.3.4. Algorithm for Forming the Payload 💅
the whole RTP payload in bandwidth-efficient mode gets built by packing bits in order: the payload header, then the table of contents, then the speech frames (in the order their ToC entries list them). then you add 0 to 7 padding bits so the payload lands on an octet boundary 🫶 the padding bits MUST be set to zero and MUST be ignored on reception. they're packed back to back, starting from the most significant bits of the fields and octets.
here's the precise version, because it's giving detail: the four-bit payload header goes in the first octet, with bit 0 of the header in the most significant bit of that octet. the four most significant bits (numbered 0-3) of the first ToC entry go into the least significant bits of that same octet, ending with bit 3 in the least significant bit. then the second octet picks up at bit 4 of the first ToC entry, sitting in its most significant bit. if there's more than one frame, the second and later ToC entries keep going the same way. bit 0 of the first data frame comes right after the last ToC bit, and then it walks through every bit of the frame in numerical order. the bits of any later frames follow on contiguously, numbered in order for each frame and taken in consecutive frame order 🌈
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. no data bits go into the payload for those missing frames. 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
this diagram shows a bandwidth-efficient AMR payload from a single-channel session with one speech frame-block 🦋
in this one, 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 in descending sensitivity order according to [2]. last but not least, two padding bits (P) go on 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=15|0| FT=4 |1|d(0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| d(147)|P|P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+4.3.5.2. Single-Channel Payload Carrying Multiple Frames
this one is a single-channel, bandwidth-efficient compound AMR-WB payload with four frames, and one of them has no speech data 👑 the first frame is a speech frame at the 6.6 kbps mode (FT=0), made of speech bits d(0) to d(131). the second is an AMR-WB SID frame (FT=9), made of bits g(0) to g(39). the third is a NO_DATA frame, so it has no speech info and only shows up in the payload as its ToC entry. the fourth is a speech frame at the 8.85 kbps mode (FT=1), with speech bits h(0) to h(176) 🧚
the payload also carries a mode request, asking 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 are damaged at the 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), go into the payload in descending sensitivity order according to [4]. (note: there are no speech bits for the third frame, obviously.) finally, seven zero bits 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 diagram is a two-channel payload carrying 3 frame-blocks, which means the payload holds 6 speech frames in total 🌸
every speech frame here uses the same 7.4 kbps mode (FT=4) and none of them are damaged at the IP origin. the CMR is set to 15, so again no specific mode is requested. the two channels are left (L) and right (R), in that order. the encoded speech bits are written 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 of 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 so in octet-aligned mode, the payload header is a 4-bit CMR, then 4 reserved bits, and optionally an 8-bit interleaving header 🦋 Here's how it's laid out:
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 what we defined in
Section 4.3.1💖 - R: a reserved bit that MUST be set to zero. All R bits MUST be ignored by the receiver 🙈
- ILL (4 bits, unsigned integer): this is OPTIONAL and only shows up if interleaving is signalled out-of-band for the session. ILL=L tells the receiver that the interleaving length is L+1, counted in frame-blocks ✨
- ILP (4 bits, unsigned integer): also OPTIONAL, and only present if interleaving is signalled. ILP MUST take a value between 0 and ILL, inclusive, and it tells you the interleaving index for the frame-blocks in this payload within the interleaving group. If ILP turns out to be 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. It's giving very specific energy, and it has to be exact 🔥
Here's an example so you can see how speech frame-blocks get arranged in an interleaving group during an interleaving session. We're assuming ILL=L for the interleaving group that starts at speech frame-block n. We're also assuming that the first payload packet of the group is s, and that each payload carries N speech frame-blocks. Then we get:
Payload s (the first packet of this interleaving 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 interleaving 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 interleaving 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 interleaving group will start at frame-block n+N*(L+1) 🌸
There won't be any interleaving effect unless the number of frame-blocks per packet (N) is at least 2. Also, the number of frame-blocks per payload (N) and the value of ILL MUST NOT be changed inside an interleaving group. In other words, all payloads in an interleaving group MUST have the same ILL and MUST contain the same number of speech frame-blocks. Literally no switching mid-group, bestie 🙅♀️
The sender of the payload MUST only apply interleaving if the receiver has signalled its use through out-of-band means. Since interleaving bumps up the buffering requirements at the receiver, the receiver uses the media type parameter interleaving=I to set the maximum number of frame-blocks allowed in an interleaving group to I 🧚
When the sender is performing interleaving, it MUST use a proper number of frame-blocks per payload (N) and ILL so that the resulting size of an interleaving group is less than or equal to I, that is, N*(L+1)<=I 💜
4.4.2. The Payload Table of Contents and Frame CRCs 🦋
okay the table of contents (ToC) in octet-aligned mode is a list of ToC entries, where each entry corresponds to a speech frame carried in the payload. It can also optionally have a list of speech frame CRCs. So the ToC looks 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. Don't go looking for data that isn't there 👀
The list of ToC entries is organized the same way as it is 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 consecutively in time. Instead, the presence and order of the frame-blocks in a packet follow the pattern described in 4.4.1 ✨
This example shows the ToC of three consecutive packets. Each packet carries three 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 gives an interleaving group size of 9 frame-blocks 🍓
Packet #1
---------
ILL=2, ILP=0:
+----+----+----+----+----+----+
| 1L | 1R | 4L | 4R | 7L | 7R |
+----+----+----+----+----+----+
|<------->|<------->|<------->|
Frame- Frame- Frame-
Block 1 Block 4 Block 7Packet #2
---------
ILL=2, ILP=1:
+----+----+----+----+----+----+
| 2L | 2R | 5L | 5R | 8L | 8R |
+----+----+----+----+----+----+
|<------->|<------->|<------->|
Frame- Frame- Frame-
Block 2 Block 5 Block 8Packet #3
---------
ILL=2, ILP=2:
+----+----+----+----+----+----+
| 3L | 3R | 6L | 6R | 9L | 9R |
+----+----+----+----+----+----+
|<------->|<------->|<------->|
Frame- Frame- Frame-
Block 3 Block 6 Block 9A ToC entry takes this format in octet-aligned mode:
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|F| FT |Q|P|P|
+-+-+-+-+-+-+-+-+- F (1 bit): see the definition in
Section 4.3.2🌈 - FT (4 bits, unsigned integer): see the definition in
Section 4.3.2🌈 - Q (1 bit): see the definition in
Section 4.3.2🌈 - P bits: padding bits. They MUST be set to zero, and MUST be ignored on reception 🫶
The list of CRCs is OPTIONAL. It only exists if the use of CRC is signalled out-of-band for the session. When it's there, each CRC in the list is 8 bits 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 👑
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 get UED. Main character energy 😭
To get UED, one SHOULD use a transport layer checksum (for example, the one defined in UDP-Lite [19]) to protect the IP, transport protocol (e.g., UDP-Lite), and RTP headers, as well as the payload header and the table of contents in the payload. The frame CRC, when it's used, MUST be calculated only over all class A bits in the AMR or AMR-WB frame. Class B and C bits in the AMR or AMR-WB frame MUST NOT be included in the CRC calculation, and they SHOULD NOT be covered by the transport checksum 🔥
Note, the number of class A bits for the various coding modes in the AMR codec is specified as informative in [2], so it's copied into Table 1 in Section 3.6 to make it normative for this payload format. The number of class A bits for the 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. Please don't freelance on this one 🙈
If the transport layer checksum or link layer checksum detects any errors within the protected (sensitive) part, it is assumed that the complete packet will be discarded, as defined by UDP-Lite [19] 🥺
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). That will then 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 gets passed to the speech decoder. See [6] and [7] for more details 🎀
The following example shows an octet-aligned ToC with a CRC list for a payload containing 3 speech frames from a single-channel session (assuming none of the FTs is equal to 14 or 15):
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| FT#1 |Q|P|P|1| FT#2 |Q|P|P|0| FT#3 |Q|P|P| CRC#1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CRC#2 | CRC#3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Each of the CRCs takes 8 bits 🦋
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| c0| c1| c2| c3| c4| c5| c6| c7|
+---+---+---+---+---+---+---+---+
(MSB) (LSB)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).
Now for the actual calculation. First, an 8-bit CRC register gets reset to zero: 00000000. For each bit that the CRC covers, an XOR operation is made between the rightmost (LSB) bit of the CRC register and that bit. Then the CRC register is right-shifted one step (each bit's significance is reduced by one), with a "0" put in as the leftmost bit (MSB). If the result of the XOR operation is a "1", then 10111000 is bit-wise XOR-ed into the CRC register. You repeat this for each bit the CRC should cover. In this case, the first bit is d(0) for the speech frame that the CRC covers. Once the last bit has gone through the calculation (e.g., d(54) for AMR 5.9 according to Table 1 in Section 3.6), the contents of the CRC register just get copied to the corresponding field in the list of CRCs 💖
Fast calculation of the CRC on a general-purpose CPU is possible using a table-driven algorithm ⚡
4.4.3. Speech Data ✨
okay so in octet-aligned mode, the speech data is packed a lot like it is in bandwidth-efficient mode (check out Section 4.3.3 if you want the refresher 🧚), but there are a few plot twists 👀
- the last octet of each speech frame MUST be padded with zero bits at the end if not all the bits in that octet get used 🫶 the padding bits MUST be ignored on reception, and basically every speech frame MUST be octet-aligned. no exceptions, bestie 💅
- when there are multiple speech frames in the speech data (aka a compound payload), they can either go one whole frame after another like normal, OR the octets of all the frames get interleaved together at the octet level. which one you get depends on the media type parameters negotiated for the payload type 🦋 the interleaved version is called "robust sorting order" and it's giving main character energy. here's why it's iconic: the bits in each frame are ordered with the most error-sensitive bits first, so interleaving pulls those sensitive bits from every frame up toward the front of the packet ✨ that makes it way easier to apply UED (like UDP-Lite [19]) or UEP (like the ULP [22]) mechanisms to the payload data 🔥 we'll get into how to assemble the payload in the next section 🎀
the use of robust sorting order for a payload type MUST be agreed via out-of-band means 🌸 Section 8 defines a media type parameter for exactly this purpose 💖
note, robust sorting order MUST only be performed on the frame level 🙈 that means it's totally independent of interleaving, which happens at the frame-block level (see Section 4.4.1). in other words, robust sorting can be applied to either non-interleaved or interleaved payload types. two separate features, no mixing them up 😭
4.4.4. Methods for Forming the Payload
there are two packetization methods for forming a payload in octet-aligned mode: normal order and robust sorting order 🍓 in both cases the payload header and the table of contents get packed in the exact same way. the only difference is how the speech frames are packed 💜
the payload starts with the payload header, which is one octet (or two octets 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 come right after the table of contents, with one 8-bit CRC filling each octet. quick heads up: if a given frame has a ToC entry with FT=14 or 15, there is NO CRC for that frame 🙈
the speech data comes after the table of contents (or after the CRCs, if they're there). for normal order packetization, all the octets of a speech frame get appended to the payload as one unit 🌈 the frames are packed in the same order as their ToC entries show up in the ToC list. the one exception: if a frame has a ToC entry with FT=14 or 15, there are no data octets for that frame at all 💀
for robust sorting order packetization, the octets of all the speech frames get interleaved together 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 has been appended, the cycle repeats 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 octet 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 in use, or follows the interleave pattern from the payload header when it is 💅 and if a frame has a ToC entry with FT=14 or 15, it has no data octets, so it gets skipped in the robust sorting cycle 🫶
the UED and/or UEP is RECOMMENDED to cover at least the RTP header, the payload header, the table of contents, and the class A bits of a sorted payload 🎀 how many octets actually need covering depends on the network and the application, so it's a vibe check 🌸 if CRCs are used together with robust sorting, only the RTP header, the payload header, and the ToC SHOULD be covered by UED/UEP 💖 and the way you tell other layers doing UED/UEP how many octets to cover is beyond the scope of this specification 🙌
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 payload type carrying two AMR frames at the 7.95 kbps coding mode (FT=5) 💅 there's a codec mode request in the payload too (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, so it's a pretty chill example 🌸
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 in both speech frames is padded with one zero bit to make it octet-aligned 🙈✨
4.4.5.2. Two-Channel Payload with CRC, Interleaving, and Robust Sorting
this example shows an octet-aligned payload from a two-channel payload type 🎀 two frame-blocks, each with two speech frames at the 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 🌈 there's also a codec mode request in the payload (CMR=6), asking the encoder on the receiver's side to use AMR 10.2 kbps coding mode 🔥
on top of that, frame CRC, robust sorting, and frame-block interleaving are all enabled for this payload type 🧚 the interleaving length is 2 (ILL=1), and this payload is the first one in its interleaving group (ILP=0) 💅
the first two frames in the payload are the L and R channel speech frames of frame-block #1, made of the 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 f3L(0..158) and f3R(0..158), because of 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 💖 finally, 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 the example above, the last octet in all four speech frames is padded with one zero bit to make it octet-aligned 🫶💖
4.5. Implementation Considerations 🛠️
an application implementing this payload format MUST understand all the payload parameters in the out-of-band signaling it uses 👑 for example, if an application uses SDP, then all the SDP and media type parameters in this document MUST be understood 💅 this requirement makes sure an implementation can always figure out whether it's capable of communicating or not 🎀
no operating mode of the payload format is mandatory to implement 🌸 the requirements of the application using the payload format should be used to determine what to implement. to get basic interoperability, an implementation SHOULD at least implement both bandwidth-efficient and octet-aligned modes for a single audio channel ✨ the other operating modes (interleaving, robust sorting, and frame-wise CRC, in both single and multi-channel) are OPTIONAL to implement 🦋
the mode-change-period, mode-change-capability, and mode-change-neighbor parameters are meant for signaling with GSM endpoints 📱 when you want interoperability with GSM, encoders SHOULD only perform codec mode changes to neighboring modes, and only in integer multiples of 40 ms (two frame-blocks) 🧚 decoders SHOULD accept codec mode changes at any time, i.e., for every frame-block 💜 the encoder may arbitrarily select the initial phase (odd or even frame-block) where codec mode changes happen, but then SHOULD stick to that phase as far as possible 🌈 BUT, in rare cases, handovers or other events (like call forwarding) can shift this phase and can also cause mode changes to non-neighboring modes 😭 so the decoder SHALL therefore be prepared to accept changes in the other phase too, and to other modes 🫶 Section 8 specifies how the mode-change-period and mode-change-capability parameters are used to indicate the desired behavior in applications 🎀
see 3GPP TS 26.103 [28] for preferred AMR and AMR-WB configurations for operation in GSM and 3GPP UMTS networks 📶 in gateway scenarios, encoders can be asked, through the "mode-set" parameter, to use a limited mode-set that's supported by the link beyond the gateway 🌸 and to avoid congestion on that link, the encoder SHOULD limit the initial codec mode for a session to a lower mode, until at least one frame-block is received with rate control information 💖
4.5.1. Decoding Validation 🔍
when processing a received payload packet, if the receiver finds that the calculated payload length (based on the information for the payload type and the values in the payload header fields) does not match the size of the received packet, the receiver SHOULD discard the packet 🚫 this is because decoding a packet with errors in its length field could seriously tank the speech quality 😭💀
5. AMR and AMR-WB Storage Format ✨
okay bestie, this section is all about storing AMR or AMR-WB speech frames in a file or as an email attachment 📎 and yes, multiple channel content is supported 🎀
In general, an AMR or AMR-WB file has the following structure:
+------------------+
| Header |
+------------------+
| Speech frame 1 |
+------------------+
: ... :
+------------------+
| Speech frame n |
+------------------+heads up: to keep things interoperable with implementations that are already out there, single-channel content uses a different file header format than multi-channel content 🫶
There's also another storage format for AMR and AMR-WB that's built for fancier needs, like random access or syncing with video 🎬 It's the 3GPP-specified ISO-based multimedia file format 3GP [31], and its media type is specified by RFC 3839 [32]. ✨
5.1. Single-Channel Header
A single-channel AMR or AMR-WB file header only contains a magic number 🪄 Different magic numbers exist so AMR and AMR-WB can be told apart.
The magic number for single-channel AMR files MUST consist of the ASCII character string:
"#!AMR\n"
(or 0x2321414d520a in hexadecimal).The magic number for single-channel AMR-WB files MUST consist of the ASCII character string:
"#!AMR-WB\n"
(or 0x2321414d522d57420a in hexadecimal).Note, the "\n" is a super important part of these magic numbers 💅 It MUST be included in the comparison, because without it, the single-channel magic numbers above would be totally indistinguishable from the multi-channel files in the next section. not me almost making that mistake 💀
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 the ASCII character string:
"#!AMR_MC1.0\n"
(or 0x2321414d525F4D43312E300a in hexadecimal).The magic number for multi-channel AMR-WB files MUST consist of the ASCII character string:
"#!AMR-WB_MC1.0\n"
(or 0x2321414d522d57425F4D43312E300a in hexadecimal).The version number in the magic numbers refers to the version of the file format 🌈
The 32 bit channel description field is defined as:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved bits | CHAN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Reserved bits: MUST be set to 0 when written, and a reader MUST ignore them. 🙈
CHAN (4 bits, unsigned integer): indicates the number of audio channels contained in this storage file. The valid values and the order of the channels within a frame-block are specified in Section 4.1 in [12]. 🎧
5.3. Speech Frames
After the file header, speech frame-blocks that are consecutive in time get stored in the file 🎞️ Each frame-block contains a number of octet-aligned speech frames equal to the number of channels, stored in increasing order and starting with channel 1.
Each stored speech frame starts with a one-octet frame header that looks like this:
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|P| FT |Q|P|P|
+-+-+-+-+-+-+-+-+The FT field and the Q bit are defined in the same way as in Section 4.3.2. The P bits are padding, and they MUST be set to 0, and MUST be ignored. 🌸
Following this one octet header come the speech bits as defined in 4.4.3. The last octet of each frame gets padded with zeroes, if needed, to achieve octet alignment. 💜
The following example shows an AMR frame in 5.9 kbps coding mode (with 118 speech bits) in the storage format 🍓
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|P| FT=2 |Q|P|P| |
+-+-+-+-+-+-+-+-+ +
| |
+ Speech bits for frame-block n, channel k +
| |
+ +-+-+
| |P|P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Non-received speech frames, or 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]). Frames or frame-blocks lost in transmission MUST be stored as NO_DATA frames or SPEECH_LOST (frame type 14, only available for AMR-WB) in complete frame-blocks, so everything stays in sync with the original media 🔁
Comfort noise frames of other types than AMR SID (FT=8) (i.e., frame type 9, 10, and 11 for AMR) SHALL NOT be used in the AMR file format. Absolutely do not use these. 🚫
6. Congestion Control
The general congestion control considerations for transporting RTP data apply to AMR or AMR-WB speech over RTP too 🚦 However, the multi-rate capability of AMR and AMR-WB speech coding may give you an edge over other payload formats when it comes to controlling congestion, since the bandwidth demand can be adjusted by picking a different coding mode. 🎛️
Another parameter that can affect the bandwidth demand for AMR and AMR-WB is the number of frame-blocks encapsulated in each RTP payload. Packing more frame-blocks into each RTP payload can reduce the number of packets sent, and so reduce the overhead from IP/UDP/RTP headers, but it comes at the expense of increased delay ⏳
If forward error correction (FEC) is used to combat packet loss, the amount of redundancy that FEC adds will need to be regulated, so that FEC itself doesn't cause a congestion problem. 🧯
It is RECOMMENDED that AMR or AMR-WB applications using this payload format employ congestion control. The actual mechanism for congestion control is not specified, but it should be suitable for real-time flows, possibly "TCP Friendly Rate Control" [21]. 🦄
7. Security Considerations 🔐
RTP packets using the payload format defined in this specification are subject to the general security considerations discussed in [8] and in any used profile, like AVP [12] or SAVP [26].
As this format transports encoded speech, the main security issues include confidentiality, authentication, and integrity of the speech itself. The payload format itself doesn't have any built-in security mechanisms, so external mechanisms, such as SRTP [26], need to be used for this functionality. Note that the appropriate mechanism to provide security to RTP and to the payloads following this memo may vary. It depends on the application, the transport, and the signaling protocol employed. Therefore, a single mechanism is not sufficient, although if suitable, the usage of SRTP [26] is RECOMMENDED. Other known mechanisms that may be used are IPsec [33] and TLS [34] (RTP over TCP), but other alternatives may also exist. 🛡️
This payload format does not exhibit any significant non-uniformity in receiver side computational complexity for packet processing, and so it is unlikely to pose a denial-of-service threat due to the receipt of pathological data. 💪
7.1. Confidentiality
To achieve confidentiality of the encoded AMR or AMR-WB speech, all speech data bits will need to be encrypted 🤫 There's less of a need to encrypt the payload header or the table of contents, due to a) the fact that they only carry information about the requested speech mode, frame type, and frame quality, and b) the fact that this information could be useful to some third party, e.g., quality monitoring.
The packetization and unpacketization of the AMR and AMR-WB payload is done only at the endpoints. Therefore, encryption should be performed after packet encapsulation, and decryption should be performed before packet decapsulation. 🔑
Encryption may affect interleaving. Specifically, a change of keys should occur at the boundary between interleaving groups. If it is not done at that boundary on both endpoints, the speech quality will be degraded during the complete interleaving group for any receiver. 😭
The encryption mechanism may impact the robustness of the error correcting mechanism. This is discussed in Section 9.5 of SRTP [26]. From this, UED/UEP based on robust sorting may be difficult to apply when the payload data is encrypted. 🧩
7.2. Authentication and Integrity
To authenticate the sender and to protect the integrity of the RTP packets in transit, an external mechanism has to be used. As stated before, it is RECOMMENDED that SRTP [26] be used for common interoperability. Note that the use of UED/UEP may be difficult to combine with some integrity protection mechanisms, because any bit errors will cause the integrity check to fail. ❌
Data tampering by a man-in-the-middle attacker could result in erroneous depacketization/decoding that could lower the speech quality or produce unintelligible communications. Tampering with the CMR field may result in a different speech quality than desired. 👀
8. Payload Format Parameters 🎀
This section defines the parameters that may be used to select optional features of the AMR and AMR-WB payload formats. The parameters are defined here as part of the media type registrations for the AMR and AMR-WB speech codecs. The registrations are done following RFC 4855 [15] and the media registration rules [14].
A mapping of the parameters into the Session Description Protocol (SDP) [11] is also provided for those applications that use SDP. Equivalent parameters could be defined elsewhere for use with control protocols that don't use media types or SDP. 📋
Two separate media type registrations are made, one for AMR and one for AMR-WB, because they are distinct encodings that must be distinguished by their own media type. 🦋
Data formats are specified for both real-time transport in RTP and for storage type applications, such as email attachments. 💖
8.1. AMR Media Type Registration
Okay bestie, so the media type for the Adaptive Multi-Rate (AMR) codec gets allocated from the IETF tree 🎀 because AMR is literally everywhere in general VoIP and messaging apps 📞. This registration covers both real-time transfer over RTP and non-real-time transfers via stored files ✨ two for one, iykyk.
Heads up: any unspecified parameter MUST be ignored by the receiver 🙅♀️
Here's the core registration info:
Media Type name: audio
Media subtype name: AMR
Required parameters: noneNow the optional parameters 💖 these only apply to RTP transfer.
octet-align: Only0and1are permissible. If it's1, octet-aligned operation SHALL be used. If it's0, or it's not there at all, bandwidth-efficient operation is employed 🦋mode-set: This one restricts the active codec mode set to a subset of all the modes. It's useful for stuff like transport channels such as GSM networks in gateway use cases 🌐 The possible values are a comma separated list of modes from the set0,...,7(see Table 1a [2]). The SID frame type8and NO_DATA (frame type15) are never included in the mode set, but they can always be used 🍓 Ifmode-setis specified, it MUST be abided, and frames encoded with modes outside of the subset MUST NOT be sent in any RTP payload or used in codec mode requests 🚫 If it's not present, all codec modes are allowed for the payload type ✨mode-change-period: This specifies a number of frame-blocks, N (1 or 2), that is the frame-block period at which codec mode changes are allowed for the sender ⏱️ The initial phase of the interval is arbitrary, but changes must be separated by a period of N frame-blocks. So a value of 2 lets the sender change mode every second frame-block. The value of N SHALL be either 1 or 2 🔥 If this parameter isn't present, mode changes are allowed at any time during the session, so N=1 💅mode-change-capability: This says whether the client can transmit with a restricted mode change period 🧚 A value of 1 means the client is not capable of restricting the mode change period to 2, and the codec mode may be changed at any point. A value of 2 means the client can restrict the period to 2, so it can correctly interoperate with a receiver requiringmode-change-period=2👑 If this parameter isn't present, the restriction capability isn't supported, which is the same asmode-change-capability=1. To fully interoperate with gateways to circuit switched networks (like GSM networks), transmissions with restricted mode changes (mode-change-capability=2) are required. Thus, clients RECOMMENDED to have the capability to support transmission according tomode-change-capability=2🫶mode-change-neighbor: Permissible values are 0 and 1. If it's 1, the sender SHOULD only perform mode changes to the neighboring modes in the active codec mode set 🌸 Neighboring modes are the ones closest in bit rate to the current mode, either the next higher or next lower rate. If it's 0 or not present, changing between any two modes in the active set is allowed 🦋maxptime: This is the maximum amount of media that can be packed into one payload packet, measured as time in milliseconds ⏰ The time is calculated as the sum of the time that the media in the packet represents. The time SHOULD be an integer multiple of the frame size. If this parameter isn't present, the sender MAY encapsulate any number of speech frames into one RTP packet 🎀crc: Permissible values are 0 and 1. If it's 1, frame CRCs SHALL be included in the payload 🔐 If it's 0 or not present, CRCs SHALL NOT be used. And ifcrc=1, that also automatically means octet-aligned operation SHALL be used for the session 💜robust-sorting: Permissible 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, that also automatically implies octet-aligned operation SHALL be used for the session 🧚interleaving: This indicates that frame-block level interleaving SHALL be used for the session 🌈 Its value defines the maximum number of frame-blocks allowed in an interleaving group (see Section 4.4.1). If it's not present, interleaving SHALL NOT be used. The presence of this parameter also automatically implies that octet-aligned operation SHALL be used 🍓ptime: see RFC 4566 [11] 🕰️channels: The number of audio channels 🎶 The possible values (1-6) and their channel order are specified in Section 4.1 in [12]. If it's omitted, the default value is 1 🔥max-red: The maximum duration in milliseconds that can pass between the primary (first) transmission of a frame and any redundant transmission the sender will use 🕊️ This lets a receiver have a bounded delay when redundancy is used. Allowed values are between 0 (no redundancy will be used) and 65535. If it's omitted, there's no limitation on redundancy 💖
Next up, the encoding considerations 💜 The audio data is binary data, so it must be encoded for non-binary transport. Base64 encoding is suitable for email 📧 When it's used in an RTP context, the data is framed as defined in [14].
Security considerations 🔐 See Section 7 of RFC 4867. Go read it, it's serious stuff 😭
Public specification 📜 RFC 4867, and 3GPP TS 26.090, 26.092, 26.093, 26.101.
Applications that use this media type 📱 This one is used in tons of applications that need transport or storage of encoded voice. Some examples are Voice over IP, streaming media, voice messaging, and voice recording on digital cameras 📷
Additional information 🗂️ The following applies to stored-file transfer methods:
Magic numbers 🔮 For single-channel:
ASCII character string "#!AMR\n"
(or 0x2321414d520a in hexadecimal)And for multi-channel:
ASCII character string "#!AMR_MC1.0\n"
(or 0x2321414d525F4D43312E300a in hexadecimal)The file extensions are amr and AMR 📁 The Macintosh file type code is "amr ", where the fourth character is a space 🍎
AMR speech frames can also be stored in the "3GP" file format, defined in 3GPP TS 26.244 [31]. That one is identified using the media types audio/3GPP or video/3GPP, as registered by RFC 3839 [32] 🎬
Person & email address to contact for further information 💌
Magnus Westerlund <magnus.westerlund@ericsson.com>
Ari Lakaniemi <ari.lakaniemi@nokia.com>Intended usage 🌟 COMMON. This media type is widely used in streaming, VoIP, and messaging apps on tons of devices 📲
Restrictions on usage 🚧 When this media type is used for transfer over RTP, the RTP payload format specified in Section 4 SHALL be used. In all other contexts, the file format defined in Section 5 SHALL be used 🫶
Author ✍️
Magnus Westerlund <magnus.westerlund@ericsson.com>
Ari Lakaniemi <ari.lakaniemi@nokia.com>Change controller 👑 IETF Audio/Video Transport working group, delegated from the IESG.
8.2. AMR-WB Media Type Registration ✨
The media type for the Adaptive Multi-Rate Wideband (AMR-WB) codec comes from the IETF tree, because AMR-WB is a seriously popular speech codec in general VoIP and messaging 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-WB
- Required parameters: none
- Optional parameters:
These parameters apply to RTP transfer only. 🦋
octet-align: Permissible values are0and1. If1, octet-aligned operation SHALL be used. If0or if not present, bandwidth-efficient operation is employed.mode-set: This one restricts the active codec mode set to a subset of all the modes. It's useful for things like supporting transport channels such as GSM networks in gateway use cases 🌉. Possible values are a comma-separated list of modes from the set0,...,8(see Table 1a [4]). The SID frame type9, SPEECH_LOST (frame type14), and NO_DATA (frame type15) are never included in the mode set, but they can always be used 🫶. Ifmode-setis specified, it MUST be abided, and frames encoded with modes outside of the subset MUST NOT be sent in any RTP payload or used in codec mode requests 💅. If not present, all codec modes are allowed for the payload type.mode-change-period: This specifies a number of frame-blocks, N (1or2), that is the frame-block period at which codec mode changes are allowed for the sender ⏱️. The initial phase of the interval is arbitrary, but changes must be separated by multiples of N frame-blocks. So a value of2lets the sender change mode every second frame-block, and that's giving rhythm 🥁. The value of N SHALL be either1or2. If this parameter is not present, mode changes are allowed at any time during the session, i.e. N=1.mode-change-capability: This tells you whether the client can transmit with a restricted mode change period 🎀. The parameter may take the value1or2. A value of1means the client is not capable of restricting the mode change period to2, so the codec mode may be changed at any point. A value of2means the client can restrict the mode change period to2, which means it can correctly interoperate with a receiver requiring a mode-change-period=2🤝. If this parameter is not present, the mode-change restriction capability is not supported, i.e. mode-change-capability=1. To fully interoperate with gateways to circuit switched networks (for example, GSM networks), transmissions with restricted mode changes (mode-change-capability=2) are required. So clients are RECOMMENDED to have the capability to support transmission according to mode-change-capability=2👑.mode-change-neighbor: Permissible values are0and1. If1, the sender SHOULD only perform mode changes to the neighboring modes in the active codec mode set 🧚. Neighboring modes are the ones closest in bit rate to the current mode, either the next higher or the next lower rate. If0or if not present, changing between any two modes in the active codec mode set is allowed.maxptime: This is the maximum amount of media that can be encapsulated in a payload packet, expressed as time in milliseconds ⏳. The time is calculated as the sum of the time that the media present in the packet represents. The time SHOULD be an integer multiple of the frame size. If this parameter is not present, the sender MAY encapsulate any number of speech frames into one RTP packet 🌈.crc: Permissible values are0and1. If1, frame CRCs SHALL be included in the payload. If0or not present, CRCs SHALL NOT be used. Ifcrc=1, this also implies automatically that octet-aligned operation SHALL be used for the session 🔥.robust-sorting: Permissible values are0and1. If1, the payload SHALL employ robust payload sorting. If0or if not present, simple payload sorting SHALL be used. Ifrobust-sorting=1, this also implies automatically that octet-aligned operation SHALL be used for the session 🍓.interleaving: This indicates that frame-block level interleaving SHALL be used for the session, and its value defines the maximum number of frame-blocks allowed in an interleaving group (see Section 4.4.1) 🧶. If this parameter is not present, interleaving SHALL NOT be used. The presence of this parameter also implies automatically that octet-aligned operation SHALL be used.ptime: see RFC 2327 [11].channels: This is the number of audio channels 🎶. The possible values (1-6) and their respective channel order are specified in Section 4.1 in [12]. If omitted, it has the default value of1.max-red: This is the maximum duration in milliseconds that elapses between the primary (first) transmission of a frame and any redundant transmission that the sender will use 🛟. This parameter lets a receiver have a bounded delay when redundancy is used. Allowed values are between0(no redundancy will be used) and65535. If the parameter is omitted, there's no limitation on the use of redundancy.
- Encoding considerations:
The audio data is binary data, and it must be encoded for non-binary transport; Base64 encoding is suitable for email 📧. When used in an RTP context, the data is framed as defined in [14].
- Security considerations:
See Section 7 of RFC 4867. 🔐
- Public specification:
RFC 4867 3GPP TS 26.190, 26.192, 26.193, 26.201
- Applications that use this media type:
This media type is used in loads of applications that need transport or storage of encoded voice 🎙️. Some examples include Voice over IP, streaming media, voice messaging, and voice recording on digital cameras 📷.
- Additional information:
The following applies to stored-file transfer methods 🗂️:
- Magic numbers:
- single-channel: ASCII character string
"#!AMR-WB\n"(or0x2321414d522d57420ain hexadecimal) - multi-channel: ASCII character string
"#!AMR-WB_MC1.0\n"(or0x2321414d522d57425F4D43312E300ain hexadecimal)
- single-channel: ASCII character string
- File extensions:
awb,AWB - Macintosh file type code:
amrw - Object identifier or OID: none
AMR-WB speech frames may also be stored in the file format "3GP" defined in 3GPP TS 26.244 [31] and identified using the media type "audio/3GPP" or "video/3GPP" as registered by RFC 3839 [32] 🎬.
- Person & email address to contact for further information:
Magnus Westerlund <magnus.westerlund@ericsson.com> Ari Lakaniemi <ari.lakaniemi@nokia.com>
- Intended usage: COMMON.
This media type is widely used in streaming, VoIP, and messaging applications on many types of devices 📱.
- Restrictions on usage:
When this media type is used in the context of transfer over RTP, the RTP payload format specified in Section 4 SHALL be used. In all other contexts, the file format defined in Section 5 SHALL be used 🚦.
- Author:
Magnus Westerlund <magnus.westerlund@ericsson.com> Ari Lakaniemi <ari.lakaniemi@nokia.com>
- Change controller:
IETF Audio/Video Transport working group delegated from the IESG 🧑💻.
8.3. Mapping Media Type Parameters into SDP 🗺️
The information carried in the media type specification maps onto fields in the Session Description Protocol (SDP) [11], which is commonly used to describe RTP sessions 💜. When SDP is used to specify sessions employing the AMR or AMR-WB codec, the mapping works like this:
- The media type (
audio) goes in SDPm=as the media name. - The media subtype (payload format name) goes in SDP
a=rtpmapas the encoding name. The RTP clock rate ina=rtpmapMUST be8000for AMR and16000for AMR-WB, and the encoding parameters (number of channels) MUST either be explicitly set to N or omitted, implying a default value of1. The values of N that are allowed are specified in Section 4.1 in [12] ✨. - The parameters
ptimeandmaxptimego in the SDPa=ptimeanda=maxptimeattributes, respectively. - Any remaining parameters go in the SDP
a=fmtpattribute by copying them directly from the media type parameter string as a semicolon-separated list of parameter=value pairs 🎀.
8.3.1. Offer-Answer Model Considerations ✨
Okay bestie, offer-answer is where negotiating AMR and AMR-WB in RTP gets spicy 🌶️ Here's the tea when you're using SDP offer-answer:
- Every combo of the config params (
octet-align,crc,robust-sorting,interleaving, andchannels) has its own unique bit-pattern and is not compatible with any other combo 🫣 So if you're making an offer and want the fancy stuff (crc,robust-sorting,interleaving, or more than one channel), the offerer is RECOMMENDED to also offer a payload type with only the octet-aligned or bandwidth-efficient config and a single channel 💅 If you have several configs you care about, you can offer them all, but don't offer too many payload types 🙏 An SDP answerer MUST include, in the SDP answer for a payload type, these params unmodified from the SDP offer (unless it removes the payload type): "octet-align"; "crc"; "robust-sorting"; "interleaving"; and "channels" 🎀 The SDP offerer and answerer MUST generate AMR or AMR-WB packets as described by these params 🫶 - The
mode-setparam can restrict the set of active AMR/AMR-WB modes used in a session 🎛️ This is mainly for gateways into networks like GSM or 3GPP UMTS, where the access network might only support a subset of the modes. The 3GPP preferred codec configs are defined in 3GPP TS 26.103 [25], and it is RECOMMENDED that other networks that also need to restrict the mode set follow those preferred configs for the greatest interoperability 🌈
The param is bi-directional, so the restricted set applies to media both received and sent by the entity declaring it. If a mode set was supplied in the offer, the answerer SHALL return the mode-set unmodified or reject the payload type. The answerer is free to choose a mode-set in the answer only if no mode-set was supplied in the offer for a unicast two-peer session 🤝 The mode-set in the answer is binding for both offerer and answerer. So an offerer supporting all modes and subsets SHOULD NOT include the mode-set param. For any other offerer, it is RECOMMENDED to include each mode-set it can support as a separate payload type within the offer. For multicast sessions, the answerer SHALL only participate in the session if it supports the offered mode-set. So it is RECOMMENDED that any offer for a multicast session include only the mode-set the answerers will need to support, and that this mode-set is likely to be supported by all participants 📣
- The
mode-change-periodandmode-change-capabilityparams are for sessions with gateways, like when interoperating with GSM networks 📞 Both are declarative and work together so a session participant can figure out whether the payload type can be supported 🧩 The mode-change-period says what the offerer or answerer requires of data it receives, while mode-change-capability says what it can transmit.
A mode-change-period=2 in the offer means the answerer is required to send with a mode-change period of 2, i.e. support mode-change-capability=2. If the answerer requires mode-change-period=2, it SHALL only include it in the answer if the offerer has either indicated support with mode-change-capability=2 or indicated mode-change-period=2. Otherwise, the payload type SHALL be rejected 🚫 An offerer that supports mode-change-capability=2 SHALL include the param in all offers for the greatest possible interoperability, unless it includes mode-change-period=2 in the offer. The mode-change-capability SHOULD be included in answers 💁 It then indicates the answerer's capability to transmit with that mode-change-period for the provided payload format configuration. This info is super useful for future re-negotiation of the payload formats 🔁
- The
mode-change-neighborparam is a recommendation to restrict switching of codec modes to a neighbor, and it SHOULD be followed 🧭 It's meant for gateway scenarios (like GSM networks) where supporting this param and the operations it implies improves interoperability.
mode-change-neighbor is a declarative param. By including it, the offerer or answerer is saying it wants to receive streams with mode-change-neighbor restrictions.
- In most cases,
maxptimeandptimewon't affect interoperability, but their settings can affect how well the application performs ⏱️ The SDP offer-answer handling ofptimeis described in RFC 3264 [13]. Themaxptimeparam MUST be handled in the same way 💯 - The
max-redparam is a stream property param 🪢 For send-only or send-recv unicast media streams, it declares the limit on redundancy the stream sender will use. For recvonly streams, it indicates the desired value for the stream sent to the receiver. The answerer MAY change the value, but it is RECOMMENDED to use the same limitation the offer declares. In the case of multicast, the offerer MAY declare a limitation, and this SHALL be answered using the same value. A media sender using this payload format is RECOMMENDED to always includemax-red, since it helps simplify media stream handling at the receiver 🧠 That's especially true if no redundancy will be used, in which casemax-redis set to 0. Since this param wasn't defined originally, some senders won't declare it even if they'll limit or not send redundancy at all 😅 - Any unknown param in an offer SHALL be removed in the answer 🧹
8.3.2. Usage of Declarative SDP 📜
In declarative usage, like SDP in RTSP [29] or SAP [30], the parameters SHALL be interpreted as follows:
- The config params (
octet-align,crc,robust-sorting,interleaving, andchannels) are all declarative, and a participant MUST use the configuration(s) provided for the session. You can provide more than one config if needed by declaring multiple RTP payload types, but keep the number of types small 🤏 - Any restriction of the AMR or AMR-WB encoder mode-switching and mode usage through
mode-setandmode-change-periodMUST be followed by all participants of the session. The restriction indicated bymode-change-neighborSHOULD be followed. Please note these restrictions may be necessary if gateways to other transport systems like GSM participate in the session. Failing to consider them may result in a peer behind such a gateway failing to correctly receive all or parts of the session 😬 Also, if different restrictions are needed by different peers in the same session (unless a common subset of the restrictions exists), some peer will not be able to participate. Note thatmode-change-capabilityis meaningless when no negotiation exists, so it can be excluded from any declarations. - Any
maxptimeandptimevalues should be selected with care so the session's participants can achieve reasonable performance 🎯 - Using
max-redputs a global upper limit on redundancy that needs to be followed by everything that understands the param. However, because this param was added late, some implementations may ignore it 🫠
8.3.3. Examples 🍓
Some example SDP session descriptions using AMR and AMR-WB encodings follow. In these examples, long a=fmtp lines are folded to meet the column width constraints of this document. The backslash ("") at the end of a line and the carriage return that follows it should be ignored 🙈
In an example of AMR being used in a possible GSM gateway-to-gateway scenario, the offerer is capable of supporting three different mode-sets and needs the mode-change-period to be 2 in combination with mode-change-neighbor restrictions. The other gateway can only support two of these mode-sets, so it removes payload type 97 in the answer. If the offering GSM gateway only supports a single mode-set active at a time, it should consider doing the 1 out of N selection procedures described in Section 10.2 of [13]:
Offer:
m=audio 49120 RTP/AVP 97 98 99
a=rtpmap:97 AMR/8000/1
a=fmtp:97 mode-set=0,2,5,7; mode-change-period=2; \
mode-change-capability=2; mode-change-neighbor=1
a=rtpmap:98 AMR/8000/1
a=fmtp:98 mode-set=0,2,3,6; mode-change-period=2; \
mode-change-capability=2; mode-change-neighbor=1
a=rtpmap:99 AMR/8000/1
a=fmtp:99 mode-set=0,2,3,4; mode-change-period=2; \
mode-change-capability=2; mode-change-neighbor=1
a=maxptime:20Answer:
m=audio 49120 RTP/AVP 98 99
a=rtpmap:98 AMR/8000/1
a=fmtp:98 mode-set=0,2,3,6; mode-change-period=2; \<
mode-change-capability=2; mode-change-neighbor=1
a=rtpmap:99 AMR/8000/1
a=fmtp:99 mode-set=0,2,3,4; mode-change-period=2; \
mode-change-capability=2; mode-change-neighbor=1
a=maxptime:20The next example shows AMR being used between a non-GSM endpoint and a GSM gateway 🌉 The non-GSM offerer requires no restrictions on mode-change-period or mode-change-neighbor, but it has to signal its mode-change-capability in the offer and abide by those restrictions in the answer.
Offer:
m=audio 49120 RTP/AVP 97
a=rtpmap:97 AMR/8000/1
a=fmtp:97 mode-change-capability=2
a=maxptime:20Answer:
m=audio 49120 RTP/AVP 97
a=rtpmap:97 AMR/8000/1
a=fmtp:97 mode-set=0,2,4,7; mode-change-period=2; \
mode-change-capability=2; mode-change-neighbor=1
a=maxptime:20Here's an example of AMR-WB in a possible VoIP scenario, where UEP may be used (99) and a fallback declaration is included (98) 📞
m=audio 49120 RTP/AVP 99 98
a=rtpmap:98 AMR-WB/16000
a=fmtp:98 octet-align=1; mode-change-capability=2
a=rtpmap:99 AMR-WB/16000
a=fmtp:99 octet-align=1; crc=1; mode-change-capability=2And an example of AMR-WB in a possible streaming scenario, using two-channel stereo 🎶
m=audio 49120 RTP/AVP 99
a=rtpmap:99 AMR-WB/16000/2
a=fmtp:99 interleaving=30
a=maxptime:100Quick note: payload format (encoding) names are commonly shown in upper case, and MIME subtypes are commonly 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 media types (audio/AMR and audio/AMR-WB) have been updated; see Section 8. 🦋
10. Changes from RFC 3267 📝✨
Okay so here's the full glow-up list from RFC 3267 to this doc 💅 Every change is below, no cap.
- Added some clarification on how an IP client is expected to behave around the mode change period and the mode-change neighbor, so check out Section 4.5 🎀
- Glowed up maxptime: the sentence that used to say
The time SHOULD be a multiple of the frame size.now saysThe time SHOULD be an integer multiple of the frame size.This should have no impact on interoperability 🫶 - Clarified the definition of the mode-set parameter 🧚
- Restricted mode-change-period to 1 or 2, which are the values circuit-switched AMR systems already use 💜
- Added a new media type parameter, Mode-Change-Capability, that defaults to 1. That's the assumed behavior of any non-updated implementation, so it's what lets the offer-answer procedures work 🔥
- mode-change-neighbor now indicates a recommended behavior instead of a required one 🌸
- Added an Offer-Answer Section, see Section 8.3.1. Heads up: this can affect interop with implementations that guessed how to do offer/answer negotiation of the payload parameters 👀
- Clarified and aligned the unequal detection usage with the published UDP-Lite spec in Sections 3.6.1 and 4.4.2.1. A normative statement about packet handling got swapped for an informative paragraph that points to UDP-Lite 🦋
- Clarified the bit order in the CRC calculation in Section 4.4.2.1 🌈
- Corrected the reference in Section 5.3 for the Q and FT fields 🍓
- Changed the padding bit definition in Sections 4.4.2 and 5.3 so it's crystal clear they shall be ignored 🙈
- Added a clarification that comfort noise frames with frame type 9, 10, and 11 SHALL NOT be used in the AMR file format 💀
- Clarified in Section 4.3.2 that the rules about not sending NO_DATA frames apply to all payload format configurations except the interleaved mode ✨
- Updated the reference list to the now-published RFCs: RFC 3448, RFC 3550, RFC 3551, RFC 3711, RFC 3828, and RFC 4566. A reference to 3GPP TS 26.101 was added too 📚
- Added notes in the storage format section and the media type registration that AMR and AMR-WB frames can also be stored in the 3GP file format 🎬
- Added a media type parameter,
max-red, that lets the sender declare a bounded usage of redundancy. Receivers can optimize because they'll know whether redundancy is used. If it is, the maximum extra delay the sender introduces (the bit the receiver needs to account for to fully use the redundancy) will be known. Adding it should have no negative effects on older implementations, since they're mandated to ignore unknown parameters per RFC 3267. Older implementations are also required to operate as if the value ofmax-redis unknown and possibly infinite 🫧 - Updated the media type registration to comply with the new registration rules 📋
- Moved the section on decoding validation from Security Considerations to Implementation Considerations, where it makes way more sense 🧠
- Clarified the application of encryption, integrity protection, and the authentication mechanism to the payload 🔐
11. Acknowledgements 🫶
The authors want to thank Petri Koskelainen, Bernhard Wimmer, Tim Fingscheidt, Sanjay Gupta, Stephen Casner, and Colin Perkins for their significant contributions to writing and reviewing RFC 3267 and this replacement. They also want to thank Richard Ejzak, Thomas Belling, and Gorry Fairhurst for their input on this replacement of RFC 3267. Iconic teamwork, periodt 👑
12. References 📚
12.1. Normative 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", STD 64, RFC 3550, July 2003.
[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., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[12] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
[13] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[14] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005.
[15] Casner, S., "Media Type Registration of RTP Payload Formats", RFC 4855, February 2007.
12.2. Informative References
[16] GSM 06.60, "Enhanced Full Rate (EFR) speech transcoding", version 8.0.1 (2000-11), European Telecommunications Standards Institute (ETSI).
[17] 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.
[18] ARIB, RCR STD-27H, "Personal Digital Cellular Telecommunication System RCR Standard", Association of Radio Industries and Businesses (ARIB).
[19] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and G. Fairhurst, "The Lightweight User Datagram Protocol (UDP-Lite)", RFC 3828, July 2004.
[20] 3GPP TS 25.415 "UTRAN Iu Interface User Plane Protocols", version 4.2.0 (2001-09), 3rd Generation Partnership Project (3GPP).
[21] Handley, M., Floyd, S., Padhye, J., and J. Widmer, "TCP Friendly Rate Control (TFRC): Protocol Specification", RFC 3448, January 2003.
[22] Li, A., et al., "An RTP Payload Format for Generic FEC with Uneven Level Protection", Work in Progress.
[23] Rosenberg, J. and H. Schulzrinne, "An RTP Payload Format for Generic Forward Error Correction", RFC 2733, December 1999.
[24] 3GPP TS 26.102, "AMR speech codec interface to Iu and Uu", version 4.0.0 (2001-03), 3rd Generation Partnership Project (3GPP).
[25] 3GPP TS 26.202, "AMR Wideband speech codec; Interface to Iu and Uu", version 5.0.0 (2001-03), 3rd Generation Partnership Project (3GPP).
[26] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[27] 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.
[28] 3GPP TS 26.103, "Speech codec list for GSM and UMTS", version 5.5.0 (2004-09), 3rd Generation Partnership Project (3GPP).
[29] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998.
[30] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.
[31] 3GPP TS 26.244, "3GPP file format (3GP)", version 6.1.0 (2004-09), 3rd Generation Partnership Project (3GPP).
[32] Castagno, R. and D. Singer, "MIME Type Registrations for 3rd Generation Partnership Project (3GPP) Multimedia files", RFC 3839, July 2004.
[33] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[34] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
ETSI documents are available from <http://www.etsi.org/>.
3GPP documents are available from <http://www.3gpp.org/>.
TIA documents are available from <http://www.tiaonline.org/>.
Authors' Addresses 🌟
Johan Sjoberg
Ericsson AB
SE-164 80 Stockholm, SWEDEN
Phone: +46 8 7190000
EMail: Johan.Sjoberg@ericsson.com
Magnus Westerlund
Ericsson Research
Ericsson AB
SE-164 80 Stockholm, SWEDEN
Phone: +46 8 7190000
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: Qiaobing.Xie@motorola.comFull Copyright Statement ©️
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property 🔒
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at <%ietf-ipr@ietf.org.
Acknowledgement 💖
Funding for the RFC Editor function is currently provided by the Internet Society. 🌈
📦 where this page comes from
- ietf: rfc4867 2007-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms