RFC 4348
Real-Time Transport Protocol (RTP) Payload Format for the Variable-Rate Multimode Wideband (VMR-WB) Audio Codec
RFC 4348 🎀
Real-Time Transport Protocol (RTP) Payload Format for the Variable-Rate Multimode Wideband (VMR-WB) Audio Codec 🌈
- Author: S. Ahmadi 💖
- Category: Standards Track ✨
- Date: January 2006 📅
- Obsoletes / Updates: the title block doesn't list anything this one obsoletes or updates 🙈
Status of This Memo 📜
okay so this document is an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 🫶 If you want the current standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1) 🧐 Distribution of this memo is unlimited, so share away 💅
Copyright Notice ©️
Copyright (C) The Internet Society (2006). 🔥
Abstract 🦋
okay so this doc defines a real-time transport protocol (RTP) payload format for the Variable-Rate Multimode Wideband (VMR-WB) speech codec 🎤 The payload format is designed to interoperate with existing VMR-WB transport formats on non-IP networks ✨ It also includes a media type registration for the VMR-WB RTP payload format 💜
VMR-WB is a variable-rate multimode wideband speech codec with several operating modes 🌸 One of those modes is interoperable with the AMR-WB (RFC 3267) audio codec at certain rates 👑 So this document has provisions that make it easier and simpler to exchange data packets between VMR-WB and AMR-WB in that interoperable mode, with no transcoding function involved 🙌
Table of Contents 🗂️
1. Introduction ....................................................3
2. Conventions and Acronyms ........................................3
3. The Variable-Rate Multimode Wideband (VMR-WB) Speech Codec ......4
3.1. Narrowband Speech Processing ...............................5
3.2. Continuous vs. Discontinuous Transmission ..................6
3.3. Support for Multi-Channel Session ..........................6
4. Robustness against Packet Loss ..................................7
4.1. Forward Error Correction (FEC) .............................7
4.2. Frame Interleaving and Multi-Frame Encapsulation ...........8
5. VMR-WB Voice over IP Scenarios ..................................9
5.1. IP Terminal to IP Terminal .................................9
5.2. GW to IP Terminal .........................................10
5.3. GW to GW (between VMR-WB- and AMR-WB-Enabled Terminals) ...10
5.4. GW to GW (between Two VMR-WB-Enabled Terminals) ...........11
6. VMR-WB RTP Payload Formats .....................................12
6.1. RTP Header Usage ..........................................13
6.2. Header-Free Payload Format ................................14
6.3. Octet-Aligned Payload Format ..............................15
6.3.1. Payload Structure ..................................15
6.3.2. The Payload Header .................................15
6.3.3. The Payload Table of Contents ......................18
6.3.4. Speech Data ........................................20
6.3.5. Payload Example: Basic Single Channel
Payload Carrying Multiple Frames ...................21
6.4. Implementation Considerations .............................22
6.4.1. Decoding Validation and Provision for Lost
or Late Packets ....................................22
7. Congestion Control .............................................23
8. Security Considerations ........................................23
8.1. Confidentiality ...........................................24
8.2. Authentication and Integrity ..............................24
9. Payload Format Parameters ......................................24
9.1. VMR-WB RTP Payload MIME Registration ......................25
9.2. Mapping MIME Parameters into SDP ..........................27
9.3. Offer-Answer Model Considerations .........................28
10. IANA Considerations ...........................................29
11. Acknowledgements ..............................................29
12. References ....................................................30
12.1. Normative References .....................................30
12.2. Informative References ...................................301. Introduction ✨
okay so this document is all about the payload format for packing VMR-WB-encoded speech signals into the Real-time Transport Protocol (RTP) [3] 🎧 The VMR-WB payload formats support a bunch of stuff: single and multiple channels, frame interleaving, multiple frames per payload, header-free payload, mode switching, and interoperation with existing VMR-WB transport formats on non-IP networks, all described in Section 3 🧚
The payload format itself lives in Section 6 🎀 The VMR-WB file format (for carrying VMR-WB speech data in storage mode applications like email) is specified in [7] 💌 And in Section 9 you'll find a media type registration for the VMR-WB RTP payload format 🌸
Since VMR-WB is interoperable with AMR-WB at certain rates, the whole document tries to stay as close as possible to RFC 3267 🫶 At the same time, it's optimized for the non-interoperable modes of the VMR-WB codec 💅
2. Conventions and Acronyms 📖
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119 [2] 🔥
Here are the acronyms used in this document 🍓
3GPP - The Third Generation Partnership Project
3GPP2 - The Third Generation Partnership Project 2
CDMA - Code Division Multiple Access
WCDMA - Wideband Code Division Multiple Access
GSM - Global System for Mobile Communications
AMR-WB - Adaptive Multi-Rate Wideband Codec
VMR-WB - Variable-Rate Multimode Wideband Codec
CMR - Codec Mode Request
GW - Gateway
DTX - Discontinuous Transmission
FEC - Forward Error Correction
SID - Silence Descriptor
TrFO - Transcoder-Free Operation
UDP - User Datagram Protocol
RTP - Real-Time Transport Protocol
RTCP - RTP Control Protocol
MIME - Multipurpose Internet Mail Extension
SDP - Session Description Protocol
VoIP - Voice-over-IPThe term "interoperable mode" in this document refers to VMR-WB mode 3, which is interoperable with AMR-WB codec modes 0, 1, and 2 🦋
The term "non-interoperable modes" in this document refers to VMR-WB modes 0, 1, and 2 🌙
The term "frame-block" is used here to describe the time-synchronized set of speech frames in a multi-channel VMR-WB session ⏱️ In particular, in an N-channel session, a frame-block contains N speech frames, one from each channel, and all N speech frames represent exactly the same time period 💜
3. The Variable-Rate Multimode Wideband (VMR-WB) Speech Codec 🎙️
okay so VMR-WB is the wideband speech-coding standard developed by Third Generation Partnership Project 2 (3GPP2) 🌍 It encodes and decodes wideband and narrowband speech for multimedia services in 3G CDMA cellular systems [1] 📱 It's a source-controlled variable-rate multimode wideband speech codec, which means it has several operating modes, and each mode is a tradeoff between voice quality and average data rate 🎀
The operating mode (as shown in Table 2) gets picked based on the traffic condition of the network and the quality of service you want 🧠 The desired average data rate (ADR) in each mode comes from encoding speech frames at permissible rates (as shown in Tables 1 and 3) that comply with the CDMA2000 system ✨ That depends on the instantaneous characteristics of the input speech, plus the maximum and minimum rate constraints the network operator puts in place 🫶
Now the main character moment: VMR-WB is a native CDMA codec that complies with all CDMA system requirements 👑 It's also interoperable with AMR-WB [4,12] at 12.65, 8.85, and 6.60 kbps 🔥 That's because VMR-WB and AMR-WB share the same core technology 🧚 This lets you do Transcoder-Free (TrFO) interconnections between VMR-WB and AMR-WB across different wireless and wireline systems (for example GSM/WCDMA and CDMA2000) without any unnecessary complex media format conversion 🙌
Note that the idea of "mode" in VMR-WB is different from AMR-WB 💭 In AMR-WB, each fixed-rate codec mode gets adapted to prevailing channel conditions by trading off the total number of source-coding and channel-coding bits 🍓
VMR-WB can switch between modes with no voice quality degradation that's caused by the mode switching itself 🦋 The operating mode of the VMR-WB encoder may be switched seamlessly without prior knowledge of the decoder 💅 Any non-interoperable mode (VMR-WB modes 0, 1, or 2) can be chosen depending on traffic conditions, like network congestion, and the quality of service you want 🌸
While in the interoperable mode (VMR-WB mode 3), mode switching between VMR-WB modes is not allowed, because there's only one AMR-WB interoperable mode in VMR-WB 🙈 Since the AMR-WB codec may request a mode change depending on channel conditions, the in-band data included in the VMR-WB frame structure (see Section 8 of [1] for more details) is used during an interoperable interconnection to switch between VMR-WB frame types 0, 1, and 2 in VMR-WB mode 3 (corresponding to AMR-WB codec modes 0, 1, or 2) 💀
As mentioned earlier, VMR-WB complies with CDMA2000 with the permissible encoding rates shown in Table 1 💖
+---------------------------+-----------------+---------------+
| Frame Type | Bits per Packet | Encoding Rate |
| | (Frame Size) | (kbps) |
+---------------------------+-----------------+---------------+
| Full-Rate | 266 | 13.3 |
| Half-Rate | 124 | 6.2 |
| Quarter-Rate | 54 | 2.7 |
| Eighth-Rate | 20 | 1.0 |
| Blank | 0 | 0 |
| Erasure | 0 | 0 |
+---------------------------+-----------------+---------------+
Table 1: CDMA2000 system permissible frame types and their
associated encoding ratesVMR-WB is robust to a high percentage of frame loss and to frames with corrupted rate information 🛡️ Receiving an Erasure (SPEECH_LOST) frame type at the decoder invokes the built-in frame error concealment mechanism ✨ That mechanism hides the effect of lost frames by using in-band data and the information from the previous frames 🫶 it's giving resilience 🌈
3.1. Narrowband Speech Processing 🎀
okay so VMR-WB can run on either 16000-Hz or 8000-Hz sampled input/output speech in all modes 🎧✨ the decoder doesn't need to know ahead of time whether the original media was sampled at 8 or 16 kHz, which is so chill of it 💅 by default the decoder spits out 16000-Hz wideband output no matter what the encoder got, but depending on the app you can set it to give you 8000-Hz output too 🦋
so yeah, this spec defines a 16000-Hz RTP clock rate for VMR-WB, and injecting and processing 8000-Hz narrowband media during a session is totally allowed 🌸 BUT the 16000-Hz RTP clock rate MUST always be used, no exceptions bestie 👑
which output sampling frequency you actually get depends on the implementation and what the receiving side's audio can handle 🔊🌈
3.2. Continuous vs. Discontinuous Transmission 🌊
the circuit-switched VMR-WB inside a CDMA network needs continuous transmission of speech data during a call 📞 the source-controlled variable-rate thing that CDMA speech codecs already do is required for the system to run well and keep interference under control 💜
BUT VMR-WB can also do discontinuous transmission (DTX) for some packet-switched stuff over IP networks, like VoIP 🧚 in DTX mode, the number of bits and packets sent during silence gets cut down to a minimum, which is giving efficiency ✨ the VMR-WB DTX operation is similar to AMR-WB's [4,12] 🫶
3.3. Support for Multi-Channel Session 🎶
the octet-aligned RTP payload format in this doc supports multi-channel audio, like a stereo speech session 🎧💖 VMR-WB itself can't encode multi-channel audio into one bit stream, but you can encode and decode each channel on its own 🍓
so to send the separately encoded channels, the speech frames for all channels that are framed and encoded for the same 20 ms period get logically grouped into one frame-block 🧩
at session setup, out-of-band signaling must be used to tell the other side how many channels there are and what order the speech frames from each channel show up in each frame-block 📣 if you're using SDP for signaling (see Section 9.2 for more details), the channel count goes in the rtpmap attribute, and the channel order in each frame-block is implied by that count, as described in Section 4.1 in [6] 💅
4. Robustness against Packet Loss 🛡️
the octet-aligned payload format (see Section 6 for more details) has a few features to help it survive lost packets, including forward error correction (FEC) and frame interleaving 🩷✨
4.1. Forward Error Correction (FEC) 🔁
repeating data you already sent is one way to do FEC 🌸 another option, which is more bandwidth efficient, is payload-external FEC, like RFC2733 [8], which sends extra packets with repair data 🎁
the repetition method is basically re-sending previously sent frame-blocks alongside the current frame-block(s) 🥹 it uses a sliding window to group the speech frame-blocks that go into each payload 🪟 Figure 1 shows an example:
--+--------+--------+--------+--------+--------+--------+--------+--
| f(n-2) | f(n-1) | f(n) | f(n+1) | f(n+2) | f(n+3) | f(n+4) |
--+--------+--------+--------+--------+--------+--------+--------+--
<---- p(n-1) ---->
<----- p(n) ----->
<---- p(n+1) ---->
<---- p(n+2) ---->
<---- p(n+3) ---->
<---- p(n+4) ---->
Figure 1: An example of redundant transmissionin this example, every frame-block gets re-sent once in the next RTP payload packet 💫 f(n-2)..f(n+4) are the speech frame-blocks and p(n-1)..p(n+4) are the payload packets 🦋
this approach doesn't need any signaling at session setup 🙌 the sender can just use it without checking with the receiver, because a packet with redundant frames looks exactly the same as a packet with only new frames 🫧 the receiver might get multiple copies or versions of a frame for the same timestamp if nothing got lost 👀 and if multiple versions of the same speech frame show up, it is RECOMMENDED that the speech decoder use the highest rate 🔥
this redundancy scheme does the same job as RFC 2198, "RTP Payload for Redundant Audio Data" [10] 💜 most of the time, this payload format is more efficient and simpler, since you wouldn't need both endpoints to support RFC 2198 😌 if the time spread between the primary and redundant encodings is bigger than 5 frame times, though, RFC 2198 will have lower bandwidth overhead 🍒
the sender is responsible for picking the right amount of redundancy based on channel feedback (like RTCP receiver reports) or network traffic 📊 a sender SHOULD NOT base its FEC selection on the CMR, since that parameter was most probably set based on non-IP information 🙅♀️ the sender also has to avoid congestion, which redundant transmission can make worse (see Section 7) 🚦
4.2. Frame Interleaving and Multi-Frame Encapsulation 🧶
to cut down on protocol overhead, the octet-aligned payload format (described in Section 6) lets several speech frame-blocks get packed into one RTP packet 📦 the catch is that if a packet is lost, several consecutive speech frame-blocks go with it, which usually causes clearly audible distortion in the reconstructed speech 😭
interleaving frame-blocks can make speech quality better in those cases, because it spreads consecutive losses out into a bunch of single frame-block losses 🪄 but interleaving and bundling several frame-blocks per payload also adds end-to-end delay, so it isn't right for every app 🙈 streaming apps will most likely be able to use interleaving to keep speech quality up on lossy connections 🌈
the octet-aligned payload format supports frame interleaving as an option ✨ for the encoder (speech sender) to use frame interleaving in its outbound RTP packets for a given session, the decoder (speech receiver) has to say it supports it through out-of-band means (see Section 9) 📣
5. VMR-WB Voice over IP Scenarios 📞
5.1. IP Terminal to IP Terminal 💻
the main scenario for this payload format is IP end-to-end between two terminals that have the VMR-WB codec, as shown in Figure 2 🫶 this can also be extended to an interoperable link between VMR-WB-enabled and AMR-WB-enabled IP terminals using the offer-answer model in Section 9.3 🤝 this payload format should be handy for both conversational and streaming services 🎀
+----------+ +----------+
| | | |
| TERMINAL |<----------------------->| TERMINAL |
| | VMR-WB/RTP/UDP/IP | |
+----------+ +----------+
(or AMR-WB/RTP/UDP/IP)
Figure 2: IP terminal to IP terminalconversational services are picky about the payload format 🥺 low delay is super important, so you want fewer speech frame-blocks per payload packet ⏱️ low overhead matters too, especially on low-bandwidth links where packets are sent a lot 📉
streaming services are way more relaxed about real-time stuff, so they can fit more frame-blocks per packet than conversational ones do 🍿 that cuts down on IP, UDP, and RTP header overhead 💅 but packing lots of frame-blocks in one packet makes it more vulnerable to packet loss, so interleaving can help 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 🖥️✨
for VMR-WB-enabled IP terminals at both ends, all VMR-WB modes can be used in this scenario, depending on the implementation 🌟 both the header-free and octet-aligned payload formats (see Section 6 for details) can be used too 🧚 for the interoperable link between VMR-WB and AMR-WB, only VMR-WB mode 3 is used, and every restriction in Section 9.3 applies 🚨
5.2. GW to IP Terminal 🌉
another scenario is when VMR-WB-encoded speech goes from a non-IP system (like a 3GPP2/CDMA2000 network) to an IP terminal, and/or the other way around, as shown in Figure 3 🔄
VMR-WB over
3GPP2/CDMA2000 network
+------+ +----------+
| | | |
<-------------->| GW |<---------------------->| TERMINAL |
| | VMR-WB/RTP/UDP/IP | |
+------+ +----------+
|
| IP network
|
Figure 3: GW to VoIP terminal scenarioVMR-WB can switch seamlessly between operational modes, and that's exploited in CDMA (non-IP) networks to make speech quality as good as possible for a given traffic condition 🎚️✨ to keep this working when there's a gateway to an IP network using the octet-aligned payload format, a codec mode request (CMR) field is considered 💖 the gateway is responsible for forwarding the CMR between the non-IP and IP sides in both directions 🫶
the IP terminal SHOULD follow the CMR that the gateway forwards, so speech quality going to the non-IP decoder gets optimized 🥰 and the mode control algorithm in the gateway SHOULD accommodate the delay the IP network adds to the IP terminal's response to CMR ⏳ the IP terminal SHOULD NOT set the CMR (see Section 6.3.2) 🙅♀️ 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 and to do congestion control on the IP network 👑💜
5.3. GW to GW (between VMR-WB- and AMR-WB-Enabled Terminals)
okay so scenario number three is where RTP/UDP/IP is the transport between two non-IP systems 🦋. IP starts and ends in gateways on both sides of the IP part, see Figure 4. This is literally the most likely way to get an interoperable connection between 3GPP/(GSM-WCDMA)/AMR-WB and 3GPP2/CDMA2000/VMR-WB mobile stations 📱✨. Here the VMR-WB-enabled terminal also says it can do AMR-WB with restricted mode set, which is in Section 9.3 💜. The CMR value may be set in packets that the gateways receive on the IP network side. The gateway should forward a CMR value to the non-IP side that is the minimum of three values: (1) the CMR value it gets on the IP side, (2) a CMR value it may pick for congestion control on the IP side, and (3) the CMR value based on its estimate of reception quality on the non-IP side. The details of the traffic control algorithm are left up to the implementation 🧠.
VMR-WB over AMR-WB over
3GPP2/CDMA2000 network 3GPP/(GSM-WCDMA) network
+------+ +------+
(AMR-WB Payload) | | AMR-WB/RTP/UDP/IP| |(AMR-WB Payload)
<---------------->| GW |<---------------->| GW |<--------------->
| | | |
+------+ +------+
| IP network |
| |
Figure 4: GW to GW scenario (AMR-WB <-> VMR-WB
interoperable interconnection)During and right when an interoperable interconnection between VMR-WB and AMR-WB starts up, only VMR-WB mode 3 can be used 🎀. Within this mode there are three Frame Types (i.e., FT=0, 1, or 2; see Table 3) that are compatible with AMR-WB codec modes 0, 1, and 2, respectively. If the AMR-WB codec is part of an interoperable interconnection with VMR-WB, the active AMR-WB codec mode set needs to be limited to 0, 1, and 2 🌸.
5.4. GW to GW (between Two VMR-WB-Enabled Terminals)
the fourth VoIP scenario is also RTP/UDP/IP transport between two non-IP systems 🌈. IP is originated and terminated in gateways on both sides of the IP transport, see Figure 5. This is the most likely setup for Mobile-Station-to-Mobile-Station (MS-to-MS) Transcoder-Free (TrFO) interconnection between two 3GPP2/CDMA2000 terminals that both use the VMR-WB codec 🫶.
VMR-WB over VMR-WB over
3GPP2/CDMA2000 network 3GPP2/CDMA2000 network
+------+ +------+
| | | |
<------------>| GW |<----------------->| GW |<------------>
| | VMR-WB/RTP/UDP/IP | |
+------+ +------+
| IP network |
| |
Figure 5: GW to GW scenario (a CDMA2000 MS-to-MS VoIP scenario)6. VMR-WB RTP Payload Formats
for any given session, the payload format can be either header free or octet aligned 🧚. Which one you get depends on the mode of operation set up for the session through out-of-band means and the application 💅.
The header-free payload format is built for maximum bandwidth efficiency, simplicity, and low latency ✨. Only one codec data frame can be sent in each header-free payload format packet. None of the payload header fields or table of contents (ToC) entries is present, same as the idea in [11] 🙈.
In the octet-aligned payload format, every field in a payload is lined up on octet boundaries, including the payload header, the table of contents entries, and the speech frames themselves. That's how it stays efficient to implement 💖.
Note that octet alignment of a field or payload means the last octet gets padded with zeroes in the least significant bits to fill it up. Also note that this padding is separate from the padding indicated by the P bit in the RTP header 👑.
Between the two payload formats, only the octet-aligned one can use interleaving to make the speech transport robust to packet loss 🔥.
The VMR-WB octet-aligned payload format in the interoperable mode is identical to the one for AMR-WB (i.e., RFC 3267) 🍓.
6.1. RTP Header Usage
the format of the RTP header is specified in [3]. This payload format uses the header fields in a way that's consistent with that specification 💜.
The RTP timestamp matches the sampling instant of the first sample encoded for the first frame-block in the packet. The timestamp clock frequency is the same as the default sampling frequency (i.e., 16 kHz), so the timestamp unit is in samples ⭐.
One speech frame-block lasts 20 ms for VMR-WB. For normal wideband operation of VMR-WB, the input/output media sampling frequency is 16 kHz, which works out to 320 samples per frame from each channel. So the timestamp goes up by 320 for VMR-WB for each consecutive frame-block 🦋.
The VMR-WB codec can process speech/audio signals sampled at 8 kHz. By default, the VMR-WB decoder output sampling frequency is 16 kHz, but depending on the application, the decoder can be configured to make 8-kHz output sampling frequency too 🎀. The VMR-WB RTP payload formats for 8- and 16-kHz sampled media are identical, and the VMR-WB decoder doesn't need to know ahead of time what the encoder input sampling frequency is. That's why a fixed RTP clock rate of 16000 Hz is defined for the VMR-WB codec. It lets 8-kHz sampled speech/audio media get injected or processed without changing the RTP clock rate during a session 😭. Note that the timestamp is still incremented by 320 per frame-block for 8-kHz sampled media too 🌈.
A packet may contain multiple frame-blocks of encoded speech or comfort noise parameters. If interleaving is used, the frame-blocks put into a payload are picked according to the interleaving rules in Section 6.3.2. Otherwise, each packet covers a period of one or more contiguous 20-ms frame-block intervals. If the data from all the channels for a particular frame-block in that period is missing (for example, at a gateway coming from some other transport format), it's possible to say that no data is present for that frame-block, instead of splitting a multi-frame-block packet into two, as explained in Section 6.3.2 🙈.
No matter which payload format is used, the RTP payload is always made an integral number of octets long by padding with zero bits if needed. If extra padding is required to bring the payload length to a larger multiple of octets, or for some other purpose, then the P bit in the RTP header MAY be set, and padding appended, as specified in [3] 💅.
The RTP header marker bit (M) SHALL be always set to 0 if the VMR-WB codec operates in continuous transmission. When operating in discontinuous transmission (DTX), the RTP header marker bit SHALL be set to 1 if the first frame-block carried in the packet contains a speech frame that's the first in a talkspurt. For all other packets, the marker bit SHALL be set to zero (M=0) 🫶.
Assigning an RTP payload type for this payload format is outside the scope of this document, so it won't be specified here. It's expected that the RTP profile this payload format is used under will assign a payload type for this encoding, or specify that the payload type is to be bound dynamically (see Section 9) 🧚.
6.2. Header-Free Payload Format
the header-free payload format is built for maximum bandwidth efficiency, simplicity, and minimum delay 🌸. Only one speech data frame is in each header-free payload format packet. None of the payload header fields or ToC entries is present. The encoding rate for the speech frame can be worked out from the length of the speech data frame, since there's only one speech data frame in each header-free payload format ✨.
The RTP header fields are used the same way for the header-free payload format as for the corresponding octet-aligned payload format. The detailed bit mapping of speech data packets allowed for this payload format is described in Section 8 of [1]. Because the header-free payload format isn't compatible with the AMR-WB RTP payload, only non-interoperable modes of VMR-WB SHALL be used with this payload format. That means FT=0, 1, 2, and 9 SHALL NOT be used with the header-free payload 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP Header [3] |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| |
+ ONLY one speech data frame +-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Note that the encoder (transmitting) site decides the mode of operation when using this payload format. The default mode of operation for the VMR-WB encoder is mode 0 [1]. The mode change request MAY also be sent through non-RTP means, which is out of the scope of this specification 🦋.
6.3. Octet-Aligned Payload Format
6.3.1. Payload Structure
the complete payload is made up of a payload header, a payload table of contents, and speech data representing one or more speech frame-blocks 💜. Here's the general layout of the payload format 👇:
+----------------+-------------------+----------------
| Payload header | Table of contents | Speech data ...
+----------------+-------------------+----------------6.3.2. The Payload Header ✨
okay so in the octet-aligned format, the payload header is a 4-bit CMR, then 4 reserved bits, and then optionally an 8-bit interleaving header 🎀 here's the layout:
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): this is a codec mode request sent to the speech encoder at the receiver's site 🦋 CMR value 15 means no mode request is present, and the other unused values are reserved for later 💅
The CMR field gets set based on this table:
+-------+----------------------------------------------------------+
| CMR | VMR-WB Operating Modes |
+-------+----------------------------------------------------------+
| 0 | VMR-WB mode 3 (AMR-WB interoperable mode at 6.60 kbps) |
| 1 | VMR-WB mode 3 (AMR-WB interoperable mode at 8.85 kbps) |
| 2 | VMR-WB mode 3 (AMR-WB interoperable mode at 12.65 kbps) |
| 3 | VMR-WB mode 2 |
| 4 | VMR-WB mode 1 |
| 5 | VMR-WB mode 0 |
| 6 | VMR-WB mode 2 with maximum half-rate encoding |
| 7-14 | (reserved) |
| 15 | No Preference (no mode request is present) |
+-------+----------------------------------------------------------+
Table 2: List of valid CMR values and their associated VMR-WB
operating modesR: this is a reserved bit that MUST be set to zero 🍓 The receiver MUST ignore all R bits, so don't you dare read into them 😤
ILL (4 bits, unsigned integer): this is an OPTIONAL field that only shows up if interleaving is signaled 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): this is also an OPTIONAL field, and it only shows up if interleaving is signaled. 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 interleave group. If the value of ILP turns out to be greater than ILL, the payload SHOULD be discarded 🙈
The ILL and ILP fields MUST be present in every packet in a session if interleaving is signaled for that session. no skipping, bestie 💜
The mode request in the CMR field stays valid until the next CMR shows up. In other words, a newly received CMR overrides the previous one 🔥 So if a terminal wants to keep getting frames in the same mode, x, it has to set CMR=x on all of its outbound payloads. And if a terminal doesn't care which mode it gets, it SHOULD set CMR=15 in all of its outbound payloads 🌸
If a payload comes in with a CMR value that isn't valid, the CMR MUST be ignored by the receiver 💀
In a multi-channel session, the receiver of the payload SHOULD interpret CMR as the desired encoding mode for all the channels in the session, if the network allows it ✨
Two things affect VMR-WB mode selection, and they're kind of a lot 😭 First, there's the performance of any CDMA link connected through a gateway (for example, in a GW to IP terminal scenario). Second, there's the congestion state of the IP network. The CDMA link performance gets signaled through the CMR field, which IP-only end-points don't use. The IP network state gets monitored using, for example, RTCP. The sender has to pick an operating mode that satisfies both of these constraints (see Section 7) 👑
The encoder SHOULD follow a received mode request, but it MAY switch to a different mode if the network needs it, for example, to control congestion 🌈
The CMR field MUST be set to 15 for packets sent to a multicast group 🦋 The encoder in the speech sender SHOULD ignore mode requests when it's sending speech to a multicast session, but it MAY use RTCP feedback information as a hint that a mode change is needed. (main character energy in a multicast room, lol 🙈)
If the interleaving option is used, interleaving MUST be done on a frame-block basis, not a frame basis, in a multi-channel session 🎀
The example below shows how speech frame-blocks get arranged in an interleave group during an interleave session. We're assuming ILL=L for the interleave group that starts at speech frame-block n. We're also assuming that the first payload packet of the interleave group is s, and that the number of speech frame-blocks carried in each payload is N. Then we get:
Payload s (the first packet of this interleave group):
ILL=L, ILP=0,
Carry frame-blocks: n, n+(L+1), n+2*(L+1),..., n+(N-1)*(L+1)
Payload s+1 (the second packet of this interleave group):
ILL=L, ILP=1,
Carry frame-blocks: n+1, n+1+(L+1), n+1+2*(L+1),..., n+1+
(N-1)*(L+1)
...
Payload s+L (the last packet of this interleave group):
ILL=L, ILP=L,
Carry frame-blocks: n+L, n+L+(L+1), n+L+2*(L+1), ..., n+L+
(N-1)*(L+1)The next interleave group starts at frame-block n+N*(L+1) 🧚 There's no interleaving effect unless N is at least 2. Also, N and ILL MUST NOT be changed inside an interleave group. In other words, every payload in an interleave group MUST have the same ILL and MUST carry the same number of speech frame-blocks 🔥
The sender of the payload MUST only apply interleaving if the receiver has signaled that it wants it through out-of-band means. Interleaving bumps up the buffering requirements at the receiver, so the receiver uses the MIME parameter "interleaving=I" to set the maximum number of frame-blocks allowed in an interleaving group to I 😤
When interleaving, the sender MUST use a proper number of frame-blocks per payload (N) and ILL so that the resulting interleave group size is less than or equal to I, meaning N*(L+1)<=I 💅
Here's a two-channel session example with three consecutive packets, each carrying 3 frame-blocks. The two channels are left (L) and right (R), with L coming before R, and the interleaving length is 3 (so ILL=2). That makes the interleave group 9 frame-blocks large 🦋
Packet #1
---------
ILL=2, ILP=0:
+----+----+----+----+----+----+
| 1L | 1R | 4L | 4R | 7L | 7R |
+----+----+----+----+----+----+
|<------->|<------->|<------->|
Frame Frame Frame
Block 1 Block 4 Block 7
Packet #2
---------
ILL=2, ILP=1:
+----+----+----+----+----+----+
| 2L | 2R | 5L | 5R | 8L | 8R |
+----+----+----+----+----+----+
|<------->|<------->|<------->|
Frame Frame Frame
Block 2 Block 5 Block 8
Packet #3
---------
ILL=2, ILP=2:
+----+----+----+----+----+----+
| 3L | 3R | 6L | 6R | 9L | 9R |
+----+----+----+----+----+----+
|<------->|<------->|<------->|
Frame Frame Frame
Block 3 Block 6 Block 96.3.3. The Payload Table of Contents 🌸
The table of contents (ToC) in octet-aligned payload format is a list of ToC entries, and each entry matches one speech frame in the payload. So when interleaving is used, the frame-blocks in the ToC will almost never sit next to each other in time 🙃 Instead, the presence and order of the frame-blocks in a packet follows the pattern from 6.3.2. iykyk 💜
+---------------------+
| list of ToC entries |
+---------------------+A ToC entry for the octet-aligned payload format looks like this:
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|F| FT |Q|P|P|
+-+-+-+-+-+-+-+-+The ToC is a list of ToC entries, and each one represents a speech frame ✨
F (1 bit): if this is set to 1, it means another speech frame follows this one in the payload. If it's set to 0, this frame is the last one in the payload 🎀
FT (4 bits): this is the frame type index, and its value gets picked from Table 3 🦋 During the interoperable mode, FT=14 (SPEECH_LOST) and FT=15 (NO_DATA) are used to flag frames that are either lost or not being sent in this payload, respectively. FT=14 or 15 MAY be used in the non-interoperable modes to indicate frame erasure or a blank frame, respectively (see Section 2.1 of [1]).
If a payload with an invalid FT value is received, the payload MUST be discarded. Heads up: for ToC entries with FT=14 or 15, there won't be a matching speech frame in the payload 💀
Depending on the application and the mode of operation of VMR-WB, any combination of the permissible frame types (FT) shown in Table 3 MAY be used. mix and match, bestie 🌈
Q (1 bit): this is the frame quality indicator. If it's set to 0, the frame is corrupted 😭 During the interoperable mode, the receiver side (with AMR-WB codec) should set the RX_TYPE to either SPEECH_BAD or SID_BAD depending on the frame type (FT), if Q=0. The VMR-WB encoder always sets the Q bit to 1, and the VMR-WB decoder may ignore the Q bit 🫶
P bits: padding bits MUST be set to zero and MUST be ignored by a receiver 🙈
Here's Table 3, the full list of frame types:
+----+--------------------------------------------+-----------------+
| FT | Encoding Rate |Frame Size (Bits)|
+----+--------------------------------------------+-----------------+
| 0 | Interoperable Full-Rate (AMR-WB 6.60 kbps) | 132 |
| 1 | Interoperable Full-Rate (AMR-WB 8.85 kbps) | 177 |
| 2 | Interoperable Full-Rate (AMR-WB 12.65 kbps)| 253 |
| 3 | Full-Rate 13.3 kbps | 266 |
| 4 | Half-Rate 6.2 kbps | 124 |
| 5 | Quarter-Rate 2.7 kbps | 54 |
| 6 | Eighth-Rate 1.0 kbps | 20 |
| 7 | (reserved) | - |
| 8 | (reserved) | - |
| 9 | CNG (AMR-WB SID) | 40 |
| 10 | (reserved) | - |
| 11 | (reserved) | - |
| 12 | (reserved) | - |
| 13 | (reserved) | - |
| 14 | Erasure (AMR-WB SPEECH_LOST) | 0 |
| 15 | Blank (AMR-WB NO_DATA) | 0 |
+----+--------------------------------------------+-----------------+
Table 3: VMR-WB payload frame types for real-time transportFor multi-channel sessions, the ToC entries for all the frames from one frame-block get placed in the ToC in consecutive order. 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 entries come from the second frame-block, and so on 🧚✨
6.3.4. Speech Data 🎀
Okay so the speech data is where the actual audio lives 🎧 Each payload carries one or more speech frames, and the ToC tells you what's in there.
Every speech frame is 20 ms of speech, encoded at whichever rate fits the operation mode. The frame type in the FT field tells you how long the frame is, and there are a few rules to keep in mind:
- The last octet of each speech frame MUST be padded with zeroes at the end if not all bits in the octet are used. In other words, each speech frame MUST be octet-aligned. 🫶
- When multiple speech frames are present in the speech data, the speech frames MUST be arranged one whole frame after another. 🧚
The bit order and numbering for the speech data are the same as the ones in the VMR-WB standard specification [1]. Bestie, that's the one you want to check if you're ever confused about bit positions 💅
The payload starts with a payload header that's one octet long, or two octets if frame interleaving is selected. After that comes the table of contents, which is a list of one-octet ToC entries 📝
The speech data comes right after the table of contents. For 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 is a frame with a ToC entry of FT=14 or 15. For those, there are no data octets at all 🙈
6.3.5. Payload Example: Basic Single Channel Payload Carrying Multiple Frames ✨
Here's a visual of an octet-aligned payload from a single channel session carrying two VMR-WB Full-Rate frames (FT=3). The payload also includes a codec mode request (CMR=4), which asks the encoder on the receiving side to use VMR-WB mode 1. No interleaving here. Notice that the last octet of both speech frames is padded with zeros so they stay octet aligned. Iconic 🌈
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=4 |R|R|R|R|1|FT#1=3 |Q|P|P|0|FT#2=3 |Q|P|P| f1(0..7) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| f1(8..15) | f1(16..23) | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| r |P|P|P|P|P|P| f2(0..7) | f2(8..15) | f2(16..23) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | l |P|P|P|P|P|P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
r= f1(264,265)
l= f2(264,265)6.4. Implementation Considerations 💖
An app implementing this payload format MUST understand all the payload parameters. Any mapping of the parameters to a signaling protocol MUST support all parameters. So if you're using SDP, your implementation is required to understand all the payload parameters in their SDP-mapped form. The point is that an implementation can always figure out whether it can communicate, which is so important 😭
To get efficient, interoperable interconnection with AMR-WB, and to make sure a VMR-WB terminal properly declares itself as an AMR-WB-capable terminal (see Section 9.3), it is also RECOMMENDED that a VMR-WB RTP payload implementation understand relevant AMR-WB signaling 🦋
To help VMR-WB implementations work together, implementations SHALL support both header-free and octet-aligned payload formats. Interleaving support is optional 🌸
6.4.1. Decoding Validation and Provision for Lost or Late Packets 🙈
When a receiver processes a payload packet, it works out the payload length from the session info and the values in the payload header fields. If that calculated length doesn't match the size of the received packet, the receiver SHOULD discard the packet. That helps avoid speech quality getting worse, and it lets the VMR-WB built-in frame error concealment mechanism do its thing. So invalid packets SHALL be treated as lost packets 💀
Late packets (meaning a packet isn't available when the receiver needs it for decoding) should be treated as lost packets. And if a late packet belongs to an interleave group, decoding should resume from the next available frame in sequential order, depending on whether the other packets in that group are around. Basically, one packet being missing at a given time shouldn't ruin the other packets in that interleave group that show up later 🧚
7. Congestion Control 🔥
The general congestion control rules for transporting RTP data also apply to VMR-WB speech over RTP. But VMR-WB has multiple modes, which gives it a bonus for managing congestion, since you can change the bandwidth demand just by picking a different operating mode 👑
Another thing that can change the bandwidth demand is how many frame-blocks get packed into each RTP payload. Packing more frame-blocks per payload means fewer packets get sent, which cuts down on RTP/UDP/IP header overhead. The tradeoff is more delay ⏳
If forward error correction (FEC) is used to deal with packet loss, the redundancy it adds has to be regulated so FEC doesn't end up causing a congestion problem itself 🫠
Congestion control for RTP SHALL be used in accordance with RFC 3550 [3] and any applicable RTP profile, for example, RFC 3551 [6]. This means congestion control is required for any transmission over unmanaged best-effort networks 🌐
On the IP network, the IP sender is the one managing congestion. Feedback about congestion SHOULD be provided to that IP sender through RTCP or other means. Then the sender can pick the best mechanism to avoid congestion. That could mean choosing an appropriate operating mode, or adjusting the level of redundancy or the number of frames per packet ✨
8. Security Considerations 🔒
RTP packets using the payload format in this specification are subject to the general security considerations discussed in RTP [3] and any applicable profile, such as AVP [9] or SAVP [10].
Since this format carries encoded audio, the main security issues are confidentiality, integrity protection, and data origin authentication of the audio itself. The payload format doesn't have any built-in security mechanisms. Any suitable external mechanisms, such as SRTP [10], MAY be used 🛡️
This payload format and the VMR-WB decoder don't show any significant non-uniformity in receiver-side computational complexity for packet processing. So they're unlikely to be a denial-of-service threat from receiving pathological data 💅
8.1. Confidentiality 🔐
To keep the encoded audio confidential, all audio data bits MUST be encrypted. The payload header and the table of contents don't need as much encryption, since they only carry frame type information. That info could still be useful to a third party, for example for quality monitoring 👀
Heads up: interleaving combined with encryption can hurt confidentiality for a short period of time. Imagine these packets (in brackets) containing frame numbers:{10, 14, 18},{13, 17, 21},{16, 20, 24}, which is a typical continuous diagonal interleaving pattern. Say the originator wants to stop some participants from hearing material starting at time 16. Just changing the key on the packet with a timestamp at or after 16, and withholding the new key from those participants, does NOT do it. Frames 17, 18, and 21 were already sent in earlier packets under the old key, and error concealment might make the audio intelligible at least as far as frame 18 or 19, and possibly further 😱
8.2. Authentication and Integrity 🧐
To authenticate the sender of the speech, an external mechanism MUST be used. It is RECOMMENDED that such a mechanism protects both the complete RTP header and the payload (speech and data bits) 🔑
Data tampering by a man-in-the-middle attacker could replace audio content, and it could also lead to erroneous depacketization and decoding that lowers audio quality. For example, tampering with the CMR field might give you speech with a different quality than you wanted 🙃
9. Payload Format Parameters 🎀
This section defines the parameters that can be used to pick optional features in the VMR-WB RTP payload formats.
The parameters are defined here as part of the MIME subtype registration for the VMR-WB speech codec. A mapping of the parameters into the Session Description Protocol (SDP) [5] is also included, for apps that use SDP. In control protocols that don't use MIME or SDP, the media type parameters have to be mapped to whatever format that control protocol uses 🧩
9.1. VMR-WB RTP Payload MIME Registration 🌈
The MIME subtype for the Variable-Rate Multimode Wideband (VMR-WB) audio codec comes from the IETF tree, since VMR-WB is expected to be a widely used speech codec in multimedia streaming and messaging, as well as in VoIP applications. This MIME registration only covers real-time transfers via RTP ✨
Note: the receiver MUST ignore any unspecified parameter and use the default values instead. Also, if no input parameters are defined, the default values will be used 💜
Media Type name: audio
Media subtype name: VMR-WB
Required parameters: noneAlso, if the interleaving parameter is present, the parameter "octet-align=1" MUST also be present. No skipping that one, bestie 🫶
OPTIONAL parameters 🎀 these are the extras you can add, and none of them are required:
mode-set: this is the requested VMR-WB operating mode set, and it's giving restriction 💅 It limits the active operating modes to a subset of all modes. The possible values are a comma-separated list of integer values. Right now the list includes modes 0, 1, 2, and 3 [1], but it MAY be extended in the future 🔮 If a mode-set is specified during session initiation, the encoder MUST NOT use modes outside of the subset. If it's not present, all operating modes in the set 0 to 3 are allowed for the session.channels: the number of audio channels 🎧 The possible values and their respective channel order are specified in Section 4.1 in [6]. If it's omitted, the default value is 1.octet-align: this is the RTP payload format, and the permissible values are 0 and 1. If it's 1, the octet-aligned payload format SHALL be used. If it's 0 or not present, the header-free payload format is employed (that's the default) ✨maxptime: see RFC 3267 [4] 🙈interleaving: this one is lowkey intense 🌀 It 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 6.3.1). If this parameter is not present, interleaving SHALL NOT be used. The presence of this parameter also automatically implies that octet-aligned operation SHALL be used.ptime: see RFC2327 [5]. It SHALL be at least one frame size for VMR-WB ⏱️dtx: permissible values are 0 and 1. The default is 0 (aka No DTX), which is where VMR-WB normally operates as a continuous variable-rate codec. Ifdtx=1, the VMR-WB codec operates in discontinuous transmission mode, where silence descriptor (SID) frames are sent by the VMR-WB encoder during silence intervals with an adjustable update frequency. The SID update-rate depends on the implementation and other network considerations that are beyond the scope of this specification 🫶
Now the MIME registration template, bestie 📝
Encoding considerations: This type is only defined for transfer of VMR-WB-encoded data via RTP (RFC 3550) using the payload formats specified in Section 6 of RFC 4348.
Security considerations: See Section 8 of RFC 4348. 🔐
Public specification: The VMR-WB speech codec is specified in 3GPP2 specifications C.S0052-0 version 1.0. Transfer methods are specified in RFC 4348.
Additional information:
Person & email address to contact for further information: Sassan Ahmadi, Ph.D., sassan.ahmadi@ieee.org 💌
Intended usage: COMMON
It is expected that many VoIP, multimedia messaging and streaming applications (as well as mobile applications) will use this type 📱
Author/Change controller: IETF Audio/Video Transport working group delegated from the IESG 👑
9.2. Mapping MIME Parameters into SDP 🗺️
The information carried in the MIME media type specification has a specific mapping to fields in the Session Description Protocol (SDP) [5], which is commonly used to describe RTP sessions. When SDP is used to specify sessions employing the VMR-WB codec, the mapping is as follows:
- The media type ("audio") goes in SDP "m=" as the media name.
- The media subtype (payload format name) goes in SDP "a=rtpmap" as the encoding name. The RTP clock rate in "a=rtpmap" MUST be 16000 for VMR-WB.
- The parameter "channels" (number of channels) MUST be either explicitly set to N or omitted, implying a default value of 1. The values of N that are allowed are specified in Section 4.1 in [6]. The parameter "channels", if present, is specified subsequent to the MIME subtype and RTP clock rate as an encoding parameter in the "a=rtpmap" attribute.
- The parameters "ptime" and "maxptime" go in the SDP "a=ptime" and "a=maxptime" attributes, respectively.
- Any remaining parameters go in the SDP "a=fmtp" attribute by copying them directly from the MIME media type string as a semicolon-separated list of parameter=value pairs.
Some examples of SDP session descriptions utilizing VMR-WB encodings follow 🦋
Example of usage of VMR-WB in a possible VoIP scenario (wideband audio):
m=audio 49120 RTP/AVP 98
a=rtpmap:98 VMR-WB/16000
a=fmtp:98 octet-align=1Example of usage of VMR-WB in a possible streaming scenario (two channel stereo):
m=audio 49120 RTP/AVP 99
a=rtpmap:99 VMR-WB/16000/2
a=fmtp:99 octet-align=1; interleaving=30
a=maxptime:1009.3. Offer-Answer Model Considerations 🤝
To achieve good interoperability for the VMR-WB RTP payload in an Offer-Answer negotiation usage in SDP [13], the following considerations are made:
- The rate, channel, and payload configuration parameters (octet-align and interleaving) SHALL be used symmetrically, i.e., offer and answer must use the same values. The maximum size of the interleaving buffer is, however, declarative, and each agent specifies the value it supports to receive for recvonly and sendrecv streams. For sendonly streams, the value indicates what the agent desires to use.
- To maintain interoperability among all implementations of VMR-WB that may or may not support all the codec's modes of operation, the operational modes that are supported by an implementation MAY be identified at session initiation. The mode-set parameter is declarative, and only operating modes that have been indicated to be supported by both ends SHALL be used. If the answerer is not supporting any of the operating modes provided in the offer, the complete payload type declaration SHOULD be rejected by removing it from the answer.
- The remaining parameters are all declarative; i.e., for sendonly streams they provide parameters that the agent desires to use, while for recvonly and sendrecv streams they declare the parameters that it accepts to receive. The dtx parameter is used to indicate DTX support and capability, while the media sender is only RECOMMENDED to send using the DTX in these cases. If DTX is not supported by the media sender, it will send media without DTX; this will not affect interoperability, only the resource consumption.
- Both header-free and octet-aligned payload format configurations MAY be offered by a VMR-WB enabled terminal. However, for an interoperable interconnection with AMR-WB, only octet-aligned
🙈 The original sentence just trails off right there, so I'm keeping it exactly like that.
- The parameters "maxptime" and "ptime" should in most cases not affect the interoperability; however, the setting of the parameters can affect the performance of the application.
- To maintain interoperability with AMR-WB in cases where negotiation is possible using the VMR-WB interoperable mode, a VMR-WB-enabled terminal SHOULD also declare itself capable of AMR-WB with limited mode set (i.e., only AMR-WB codec modes 0, 1, and 2 are allowed) and of octet-align mode of operation.
Example:
m=audio 49120 RTP/AVP 98 99
a=rtpmap:98 VMR-WB/16000
a=rtpmap:99 AMR-WB/16000
a=fmtp:99 octet-align=1; mode-set=0,1,2An example of offer-answer exchange for the VoIP scenario described in Section 5.3 is as follows 📞
CDMA2000 terminal -> WCDMA terminal Offer:
m=audio 49120 RTP/AVP 98 97
a=rtpmap:98 VMR-WB/16000
a=fmtp:98 octet-align=1
a=rtpmap:97 AMR-WB/16000
a=fmtp:97 mode-set=0,1,2; octet-align=1
WCDMA terminal -> CDMA2000 terminal Answer:
m=audio 49120 RTP/AVP 97
a=rtpmap:97 AMR-WB/16000
a=fmtp:97 mode-set=0,1,2; octet-align=1;For declarative use of SDP, such as in SAP [14] and RTSP [15], all parameters are declarative and provide the parameters that SHALL be used when receiving and/or sending the configured stream 📡
10. IANA Considerations 🏷️
The IANA has registered one new MIME subtype (audio/VMR-WB); see Section 9.
11. Acknowledgements 🫶
The author would like to thank Redwan Salami of VoiceAge Corporation, Ari Lakaniemi of Nokia Inc., and IETF/AVT chairs Colin Perkins and Magnus Westerlund for their technical comments to improve this document 💖
Also, the author would like to acknowledge that some parts of RFC 3267 [4] and RFC 3558 [11] have been used in this document ✨
12. References 📚
12.1. Normative References
- [1] 3GPP2 C.S0052-0 v1.0 "Source-Controlled Variable-Rate Multimode Wideband Speech Codec (VMR-WB) Service Option 62 for Spread Spectrum Systems", 3GPP2 Technical Specification, July 2004.
- [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [3] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
- [4] Sjoberg, J., Westerlund, M., Lakaniemi, A., and Q. Xie, "Real-Time Transport Protocol (RTP) Payload Format and File Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs", RFC 3267, June 2002.
- [5] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
- [6] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
12.2. Informative References
- [7] 3GPP2 C.S0050-A v1.0 "3GPP2 File Formats for Multimedia Services", 3GPP2 Technical Specification, September 2005.
- [8] Rosenberg, J. and H. Schulzrinne, "An RTP Payload Format for Generic Forward Error Correction", RFC 2733, December 1999.
- [9] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
- [10] 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.
- [11] Li, A., "RTP Payload Format for Enhanced Variable Rate Codecs (EVRC) and Selectable Mode Vocoders (SMV)", RFC 3558, July 2003.
- [12] 3GPP TS 26.193 "AMR Wideband Speech Codec; Source Controlled Rate operation", version 5.0.0 (2001-03), 3rd Generation Partnership Project (3GPP).
- [13] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
- [14] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.
- [15] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998.
Any 3GPP2 document can be downloaded from the 3GPP2 web server, "http://www.3gpp2.org/", see specifications 🌐
Author's Address 💌
Dr. Sassan Ahmadi EMail: sassan.ahmadi@ieee.org
Full Copyright Statement ✨
okay so bestie, this part is the legal stuff, but it's still important so I'm keeping all of it 🫶 Copyright (C) The Internet Society (2006) 💅
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 🌸
ngl the next bit is very serious 😭 This document and the information in it are provided on an "AS IS" basis, and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY 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 on whether any Intellectual Property Rights (or other rights) that might be claimed to apply to the technology in this document are valid or how far they reach. It also doesn't say whether any license under those rights might or might not be available, and it doesn't claim to have done any independent digging to find such rights 🔍 If you want to know how rights in RFC documents work, the info lives in BCP 78 and BCP 79 📚
Copies of IPR disclosures sent to the IETF Secretariat, plus any assurances that licenses will be available, or the results of anyone trying to get a general license or permission to use those proprietary rights, can be found through the IETF's online IPR repository at http://www.ietf.org/ipr 🧚
The IETF also invites anyone to tell it about any copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to implement this standard. Send that info to the IETF at ietf-ipr@ietf.org 🎀
Acknowledgement 🌈
Funding for the RFC Editor function comes from the IETF Administrative Support Activity (IASA) 💖
📦 where this page comes from
- ietf: rfc4348 2006-01
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms