RFC 3558
RTP Payload Format for Enhanced Variable Rate Codecs (EVRC) and Selectable Mode Vocoders (SMV)
RFC 3558: RTP Payload Format for Enhanced Variable Rate Codecs (EVRC) and Selectable Mode Vocoders (SMV) 💖
Network Working Group 🌸 Author: A. Li, UCLA 🎀 Category: Standards Track 🦋 Date: July 2003 ✨
Okay bestie, this is the RFC that explains how two speech codecs from the 3GPP2 world, EVRC and SMV, get packed into RTP packets so your voice can travel across the internet. It's a Standards Track doc, so people are actually meant to implement it. Let's go 💅
Status of This Memo 📋
This document specifies an Internet standards track protocol for the Internet community, and it's asking 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, so share it with everyone 💜
Copyright Notice ©️
Copyright (C) The Internet Society (2003). All Rights Reserved. 🔒
Abstract ✨
This document describes the RTP payload format for Enhanced Variable Rate Codec (EVRC) Speech and Selectable Mode Vocoder (SMV) Speech. Two sub-formats are specified for different application scenarios, and it's giving versatility 🦋 The first is a bundled/interleaved format, which reduces the effect of packet loss on speech quality and also spreads the RTP header overhead across more than one speech frame. The second is a non-bundled format, which is also supported for conversational applications 💬
Table of Contents 🗂️
1. Introduction ................................................... 2
2. Background ..................................................... 2
3. The Codecs Supported ........................................... 3
3.1. EVRC ...................................................... 3
3.2. SMV ....................................................... 3
3.3. Other Frame-Based Vocoders ................................ 4
4. RTP/Vocoder Packet Format ...................................... 4
4.1. Interleaved/Bundled Packet Format ......................... 5
4.2. Header-Free Packet Format ................................. 6
4.3. Determining the Format of Packets ......................... 7
5. Packet Table of Contents Entries and Codec Data Frame Format ... 7
5.1. Packet Table of Contents entries .......................... 7
5.2. Codec Data Frames ......................................... 8
6. Interleaving Codec Data Frames ................................. 9
7. Bundling Codec Data Frames .................................... 12
8. Handling Missing Codec Data Frames ............................ 12
9. Implementation Issues ......................................... 12
9.1. Interleaving Length .......................................12
9.2. Validation of Received Packets ............................13
9.3. Processing the Late Packets ...............................13
10. Mode Request ................................................. 13
11. Storage Format ............................................... 14
12. IANA Considerations .......................................... 15
12.1. Registration of Media Type EVRC ..........................15
12.2. Registration of Media Type EVRC0 .........................16
12.3. Registration of Media Type SMV ...........................17
12.4. Registration of Media Type SMV0 ..........................18
13. Mapping to SDP Parameters .................................... 19
14. Security Considerations ...................................... 20
15. Adding Support of Other Frame-Based Vocoders ................. 20
16. Acknowledgements ............................................. 21
17. References ................................................... 21
17.1 Normative ................................................ 21
17.2 Informative .............................................. 22
18. Author's Address ............................................. 22
19. Full Copyright Statement ..................................... 231. Introduction 🌷
Okay so this section sets the scene. It describes how speech compressed with EVRC [1] or SMV [2] can be formatted to be used as an RTP payload type 🎧 The format is also extensible, so other codecs that spit out a similar set of frame types can use it too. There are two ways to packetize the codec data frames into RTP packets: an interleaved/bundled format and a zero-header format. The sender gets to pick the best one for each application scenario, based on network conditions, bandwidth availability, delay requirements, and packet-loss tolerance. Main character energy for the sender 👑
Now for the important bit 🚨 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 [3]. So those capitalized words are the rules, and they're not just vibes 😤
2. Background 📚
Let's get the history. The 3rd Generation Partnership Project 2 (3GPP2) has published two standards that define speech compression algorithms for CDMA applications: EVRC [1] and SMV [2]. EVRC is already deployed in millions of first and second generation CDMA handsets, which is honestly iconic 📱 SMV is the preferred speech codec standard for CDMA2000, and it will be deployed in third generation handsets alongside EVRC. New codecs and improvements will keep showing up as technology gets better, and future handsets will likely support multiple codecs 🚀
The EVRC and SMV codec frames are very similar to each other. Lots of other vocoders share common characteristics and similar application scenarios too 🫶 Because of that parallelism, an RTP payload format can be designed for EVRC and SMV that also supports other similar vocoders with minimal extra specification work. The payoff is a simpler protocol for moving vocoder data frames through RTP, and less complicated implementations overall ✨
3. The Codecs Supported 🎙️
3.1. EVRC 🎶
The Enhanced Variable Rate Codec (EVRC) [1] takes every 20 milliseconds of 8000 Hz, 16-bit sampled speech input and turns it into an output frame in one of three sizes: Rate 1 (171 bits), Rate 1/2 (80 bits), or Rate 1/8 (16 bits). There are also two zero bit codec frame types, and they're a little bit iconic 🙈 The first is the null frame, which is produced when the vocoder runs at rate 0. Null frames are zero bits long and are normally not transmitted. The second is the erasure frame, which the receiver substitutes for the codec when frames are lost or damaged. Erasure frames are also zero bits long and are normally not transmitted either 🫥
The codec picks the output frame rate by analyzing the input speech and the current operating mode, which is either normal or one of several reduced rate modes. For typical speech patterns, this works out to an average output of 4.2 kilobits/second for normal mode, with a lower average for the reduced rate modes 💜
3.2. SMV 🌈
The Selectable Mode Vocoder (SMV) [2] also takes every 20 milliseconds of 8000 Hz, 16-bit sampled speech input, and it outputs frames in one of four sizes: Rate 1 (171 bits), Rate 1/2 (80 bits), Rate 1/4 (40 bits), or Rate 1/8 (16 bits). Same as EVRC, there are two zero bit codec frame types: null frames and erasure frames. Null frames come from the vocoder running at rate 0, are zero bits long, and are normally not transmitted. Erasure frames are substituted by the receiver for lost or damaged frames, are also zero bits long, and are normally not transmitted 🫶
SMV can operate in six modes. Each mode may produce frames at any of the rates (full rate down to 1/8 rate) for varying percentages of time, depending on the characteristics of the speech samples and the selected mode. The SMV mode can change on a frame-by-frame basis, which is so flexible 🦋 The SMV codec doesn't need any extra information besides the codec data frames to decode the data of the various modes correctly. That means the encoder's mode doesn't need to be sent along with the encoded frames. Less data, more slay 🍓
The SMV codec chooses the output frame rate by analyzing the input speech and the current operating mode. For typical speech patterns, that gives an average output of 4.2 kilobits/second for Mode 0 in two-way conversation (roughly 50% active speech time and 50% at eighth rate while listening), and a lower average for the other reduced rate modes. SMV is more bandwidth efficient than EVRC, and EVRC is equivalent in performance to SMV mode 1 💅
3.3. Other Frame-Based Vocoders 🧚
Other frame-based vocoders can be carried in the packet format defined in this document, as long as they have all of the following properties:
- The codec is frame-based;
- blank and erasure frames are supported;
- the total number of rates is less than 17;
- the maximum full rate frame can be transported in a single RTP packet using this specific format.
Vocoders with the characteristics listed above can be transported using the packet format specified in this document, but with some additional specification work. The pieces that must be defined are listed in Section 15 🌸
4. RTP/Vocoder Packet Format 📦
The vocoder speech data may be transmitted in either of the two RTP packet formats specified in the following two subsections, depending on what the application scenario needs 🎀 In the packet format diagrams in this document, bit 0 is the most significant bit, so start counting from the left and don't mix it up 🙈
4.1. Interleaved/Bundled Packet Format 🎀
okay so this format lets you shove one or more vocoder frames into a single packet 📦✨ interleaving or bundling MAY be used, so you get to pick your vibe. here's what the RTP packet looks like:
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 [4] |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
|R|R| LLL | NNN | MMM | Count | TOC | ... | TOC |padding|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| one or more codec data frames, one per TOC entry |
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+the RTP header follows the expected values from the RTP specification [4] (no surprises there 💅). the RTP timestamp is in 1/8000 of a second units for EVRC and SMV 🕰️. any other vocoders using this packet format need to define the timestamp unit explicitly, so don't assume 🙈 the M bit should be set as specified in the applicable RTP profile, for example, RFC 3551 [5]. ngl this is important: RFC 3551 [5] says that if the sender does not suppress silence, the M bit will always be zero 🤍 when multiple codec data frames live in one RTP packet, the timestamp is that of the oldest data represented in the packet ⏳ and the assignment of an RTP payload type for this packet format is outside the scope of this document. it gets specified by the RTP profile you're using, so that's a whole other group chat 🧚
the first octet of an Interleaved/Bundled format packet is the Interleave Octet 🌸 the second octet holds the Mode Request and Frame Count fields, and then the Table of Contents (ToC) field comes after that. here's the breakdown:
- Reserved (RR): 2 bits: reserved bits. MUST be set to zero by sender, SHOULD be ignored by receiver. (the sender has to be neat, the receiver can chill 🫶)
- Interleave Length (LLL): 3 bits: tells you the length of the interleave. a value of 0 means bundling, which is basically a special case of interleaving 🧶 check out Section 6 and Section 7 for the full tea.
- Interleave Index (NNN): 3 bits: the index within an interleave group. MUST have a value less than or equal to the value of LLL. values of NNN greater than LLL are invalid, and packets with invalid NNN values SHOULD be ignored by the receiver 🚫
- Mode Request (MMM): 3 bits: carries Mode Request information. see Section 10 for details 🎛️
- Frame Count (Count): 5 bits: the number of ToC fields (and vocoder frames) in the packet is the frame count value plus one ✨ a value of zero means one ToC field, and a value of 31 means 32 ToC fields. big brain math 🧠
- Padding (padding): 0 or 4 bits: this padding makes sure codec data frames start on an octet boundary 🧩 when the frame count is odd, the sender MUST add 4 bits of padding following the last TOC. when the frame count is even, the sender MUST NOT add padding bits. if padding is present, the padding bits MUST be set to zero by sender, and SHOULD be ignored by receiver 💖
the Table of Contents field (ToC) gives info on the codec data frame(s) in the packet. there's one ToC entry for each codec data frame, and the detailed formats of the ToC field and the codec data frames are in Section 5 📖 you can stack multiple data frames in one Interleaved/Bundled packet using interleaving or bundling, as described in Section 6 and Section 7 🦋
4.2. Header-Free Packet Format 🍓
the Header-Free Packet Format is built for maximum bandwidth efficiency and low latency 🏎️💨 only one codec data frame can go in each Header-Free packet. none of the payload header fields (LLL, NNN, MMM, Count) and no ToC entries are present, which is very minimalist of it 🤍 the codec rate can be figured out from the length of the codec data frame, since there's only one frame per Header-Free packet. iconic.
using the RTP header fields for the Header-Free RTP/Vocoder Packet Format is the same as in Section 4.1 for the Interleaved/Bundled format 🔁 the detailed format of the codec data frame is in Section 5.
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 [4] |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| |
+ ONLY one codec data frame +-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+4.3. Determining the Format of Packets 🔍
okay, so all receivers SHOULD be able to process both packet formats 🙌 the sender MAY choose to use one or both.
a receiver MUST have prior knowledge of the packet format to decode the RTP packets correctly 🗝️ when packets of both formats are used in the same session, different RTP payload type values MUST be used for each format so they can be told apart 💜 the association between payload type number and packet format happens out-of-band, for example through SDP during session setup 📨
5. Packet Table of Contents Entries and Codec Data Frame Format 📚✨
5.1. Packet Table of Contents entries 🧾
each codec data frame in an Interleaved/Bundled packet has a matching Table of Contents (ToC) entry 💅 the ToC entry tells you the rate of the codec frame. (Header-Free packets MUST NOT have a ToC field. no ToC for you, Header-Free girlies 🙅♀️)
each ToC entry takes up four bits 🔢 here's the layout:
0 1 2 3
+-+-+-+-+
|fr type|
+-+-+-+-+- Frame Type: 4 bits: the frame type tells you what kind of codec data frame is in the RTP packet 🎞️
for EVRC and SMV codecs, the frame type values and the size of the matching codec data frame are in this table:
Value Rate Total codec data frame size (in octets)
---------------------------------------------------------
0 Blank 0 (0 bit)
1 1/8 2 (16 bits)
2 1/4 5 (40 bits; not valid for EVRC)
3 1/2 10 (80 bits)
4 1 22 (171 bits; 5 padded at end with zeros)
5 Erasure 0 (SHOULD NOT be transmitted by sender)all values not listed in the table above MUST be considered reserved 🚧 a ToC entry with a reserved Frame Type value SHOULD be considered invalid 🚫 heads up: the EVRC codec doesn't have 1/4 rate frames, so frame type value 2 MUST be considered a reserved value when EVRC is in use 🙈
other vocoders using this packet format need to specify their own table of frame types and matching codec data frames 🌈
5.2. Codec Data Frames 🎀
the output of the vocoder MUST be converted into codec data frames before it goes into the RTP payload 📦 the conversions for EVRC and SMV are below. (quick note: because EVRC doesn't have Rate 1/4 frames, the 1/4 frame specs don't apply to EVRC codec data frames 💀) other vocoders using this packet format need to spell out how to turn their output into frames too.
the codec output data bits, numbered as in EVRC and SMV, get packed into octets 🧩 the lowest numbered bit (bit 1 for Rate 1, Rate 1/2, Rate 1/4 and Rate 1/8) goes into the most significant bit (internet bit 0) of octet 1 of the codec data frame. the second lowest bit goes into the second most significant bit of the first octet, the third lowest into the third most significant bit of the first octet, and so on 🌊 this keeps going until every bit has been placed in the codec data frame.
the remaining unused bits of the last octet of the codec data frame MUST be set to zero 🫧 in EVRC and SMV this only matters for Rate 1 frames (171 bits), since Rate 1/2 (80 bits), Rate 1/4 (40 bits, SMV only) and Rate 1/8 frames (16 bits) fit exactly into a whole number of octets 🥹
here's a detailed look at a Rate 1 EVRC/SMV codec output frame converted into a codec data frame ✨
the codec data frame for an EVRC/SMV codec Rate 1 frame is 22 octets long 📏 bits 1 through 171 from the EVRC/SMV codec Rate 1 frame are placed as shown, with bits marked "Z" set to zero. EVRC/SMV codec Rate 1/8, Rate 1/4 and Rate 1/2 frames are converted similarly, but they don't need zero padding because they line up on octet boundaries 💖
Rate 1 codec data frame
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|
|0|0|0|0|0|0|0|0|0|1|1|1|1|1|1|1|1|1|1|2|2|2|2|2|2|2|2|2|2|3|3|3|
|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|2|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|1|1|1|1|1|1|1|1|1|1|1|1|1|1|1|1|1|1|1|1|1|1|1|1|1|1| | | | | |
|4|4|4|4|4|5|5|5|5|5|5|5|5|5|5|6|6|6|6|6|6|6|6|6|6|7|7|Z|Z|Z|Z|Z|
|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| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+6. Interleaving Codec Data Frames ✨
okay so, as we saw in Section 4.1, a sender MAY pack more than one codec data frame into a single Interleaved/Bundled packet 📦. There are two ways to do this, interleaving and bundling. 🫶
Bundling spreads the transmission overhead of the RTP and payload headers across several vocoder frames, so each frame carries less header baggage 💅. Interleaving goes a step further and makes listeners less likely to notice lost data, because the loss gets spread across frames that aren't next to each other 🦋. EVRC, SMV, and similar vocoders can cover for an occasional lost frame, but the speech quality falls off exponentially when frames are lost back to back 😭.
Bundling is signaled by setting the LLL field to zero and the Count field to a value greater than zero. Interleaving is signaled by setting the LLL field to a value greater than zero 🎀.
The general interleaving rules also apply to bundling, which you can think of as a simpler special case of interleaving with less complexity 🧚. Bundling gets its own detailed walkthrough in Section 7.
Senders MAY support interleaving and/or bundling. Any receiver that supports the Interleaved/Bundled packet format MUST support both interleaving and bundling 🌈.
Now, the placement. Imagine a time-ordered sequence of codec output frames numbered 0..n, a bundling value B (that's the Count field plus one), and an interleave length L, where n = B * (L+1) - 1. The frames get put into RTP packets like this, with the LLL and NNN values noted for each packet 👑:
First RTP Packet in Interleave group:
LLL=L, NNN=0
Frame 0, Frame L+1, Frame 2(L+1), Frame 3(L+1), ... for a total of
B frames
Second RTP Packet in Interleave group:
LLL=L, NNN=1
Frame 1, Frame 1+L+1, Frame 1+2(L+1), Frame 1+3(L+1), ... for a
total of B framesIt keeps going like that until the last packet in the group:
L+1 RTP Packet in Interleave group:
LLL=L, NNN=L
Frame L, Frame L+L+1, Frame L+2(L+1), Frame L+3(L+1), ... for a
total of B framesInside each interleave group, the packets MUST be sent in increasing order of the NNN field 🔥. Sending in that order doesn't guarantee lower end-to-end delay on the receiving side, but if the underlying transport delivers packets in order, the delay gets as low as it can possibly go 💖.
Receivers MAY tell the sender the largest number of codec data frames (the largest bundling value B) they can handle in one RTP packet, using the OPTIONAL maxptime RTP mode parameter from Section 12 🍓.
Receivers MAY also tell the sender the largest interleave length they'll accept (the biggest LLL value in the Interleaving Octet), using the OPTIONAL maxinterleave RTP mode parameter from Section 12 🌸.
Both maxptime and maxinterleave get exchanged when the session is set up. In one-to-one sessions, the sender MUST respect the values the receiver sets, and MUST NOT interleave or bundle more packets than the receiver says it can handle ⭐. Why? So the receiver can reserve a known amount of buffer space that's enough for every bit of interleaving and bundling in that session 🧠. During the session, the sender MAY lower the bundling value or the interleave length (which means the receiver needs less buffer space), but it can never go above the maximum the receiver set 🙈. That way, the receiver never ends up needing more buffer space halfway through a session and having no way to get it 😭.
Senders also have a few more restrictions to keep in mind 💅:
- MUST NOT bundle more codec data frames in a single RTP packet than indicated by maxptime (see Section 12), if it is signaled.
- SHOULD NOT bundle more codec data frames in a single RTP packet than will fit in the MTU of the underlying network.
- Once a session has started with a given maximum interleaving value set by maxinterleave in Section 12, the sender MUST NOT increase the interleaving value (LLL) past the maximum interleaving value that was signaled.
- The sender MAY change the interleaving value, but MUST only do so between interleave groups.
- Silence suppression MUST only be used between interleave groups. If the codec outputs a blank frame, a ToC with Frame Type 0 (Blank Frame, Section 5.1) MUST be used within interleaving groups. The M bit in the RTP header is not set for these blank frames, because the stream is continuous in time. Since there is only one time stamp per RTP packet, silence suppression inside an interleave group would cause ambiguities when the receiver rebuilds the speech, so it's prohibited 🚫.
Here's how an interleave group is put together. Take an RTP packet with sequence number S, interleave length (field LLL) L, interleave index value (field NNN) N, and bundling value B. The interleave group is that packet plus the other RTP packets with sequence numbers from S-N mod 65536 to S-N+L mod 65536, inclusive. Put simply, an interleave group always has L+1 RTP packets with sequential sequence numbers 🦋. Every RTP packet in an interleave group MUST have the same bundling value 🎀.
The receiver figures out the expected bundling value for the whole interleave group by counting the codec data frames bundled in the first RTP packet of the group that it receives. That might not be the first packet of the group, though, if the underlying transport delivers packets out of order 🫠.
7. Bundling Codec Data Frames 🎀
As we covered in Section 6, bundling is a special, reduced case of interleaving where the LLL value in the Interleave Octet is set to 0 🧁.
When LLL is 0, the codec data frames are included back to back in one packet. The interleave group shrinks down to a single RTP packet, so rebuilding the codec data frames from the RTP packets is way simpler 💖.
Because bundling is simpler, the extra restrictions on senders are reduced to just these two 🌷:
- MUST NOT bundle more codec data frames in a single RTP packet than indicated by maxptime (see Section 12), if it is signaled.
- SHOULD NOT bundle more codec data frames in a single RTP packet than will fit in the MTU of the underlying network.
8. Handling Missing Codec Data Frames 🙈
The vocoders covered by this payload format support erasure frames, which are how you indicate that a frame isn't available 🌙. A receiver normally uses erasure frames internally to move the voice decoder's state forward by exactly one frame time for each missing frame 🧚.
The receiver can use the packet sequence number, the time stamp, and the M bit to spot missing codec data frames, whether they went missing because of RTP packet loss or silence suppression. Then it can generate matching erasure frames 🔍. Erasure frames MUST also be used in storage format to record missing frames 💾.
9. Implementation Issues 🛠️
9.1. Interleaving Length 🌸
The vocoder fills in missing speech when it gets an erasure frame. Listeners sound best, though, when erasure frames aren't back to back 🦋. That's why interleaving is worth it: it boosts speech quality when packets get lost 💅.
The catch is that interleaving can really pile on end-to-end delay 😬. So for interactive sessions, either the Interleaved/Bundled packet format with interleaving length (field LLL) 0, or the Header-Free packet format, is RECOMMENDED 🫶.
When end-to-end delay isn't the main concern, an interleaving length (field LLL) of 4 or 5 is RECOMMENDED. It's a solid middle ground between robustness and latency 👑.
9.2. Validation of Received Packets 🔍
When a receiver gets an RTP packet, it SHOULD check that the ToC fields are valid and that the packet's length matches what the ToC fields say 📏. If it finds anything invalid or any mismatch, it is RECOMMENDED to throw the packet away, so the speech doesn't take a serious hit in quality 😭. The discarded packet gets treated just like a lost packet, and the discarded data gets replaced with erasure frames 🎀.
If a receiver gets an RTP packet with an invalid LLL or NNN value, the packet SHOULD be treated as lost, so the receiver can generate erasure frames the way Section 8 describes 🙅♀️.
If a receiver gets an RTP packet in an interleave group with a frame count that isn't the expected value, it MAY drop codec data frames off the end of the packet, or add erasure codec data frames to the end, to build a substitute packet with the expected bundling value 🧩. It MAY also choose to throw out the whole interleave group instead 🗑️.
9.3. Processing the Late Packets ⏰
Say the receiver has started playing frames from an interleave group, and it's time to play frame x from packet n of that group. Packet n hasn't arrived yet. Like Section 8 explains, an erasure frame gets sent to the vocoder 🫠.
Now say packet n shows up before frame x+1 of that packet is needed. Receivers should use frame x+1 from the newly arrived packet n instead of substituting an erasure frame 🙌. Just because packet n wasn't there the first time it was needed doesn't mean the receiver should assume it's unavailable when it's needed later for interleaved speech reconstruction 💜.
10. Mode Request 🎛️
The Mode Request signal asks for a particular encoding mode for the speech encoding in the reverse direction 🔁. All implementations are RECOMMENDED to honor the Mode Request signal 🫶. The Mode Request signal SHOULD only be used in one-to-one sessions. In multi-party sessions, any Mode Request signals that get received SHOULD be ignored 🙈.
The Mode Request signal MAY also be sent through non-RTP means, which is out of the scope of this specification 🧚.
The three-bit Mode Request field tells the receiver to set a particular encoding mode on its audio encoder. If the Mode Request field has a valid value in RTP packets going from node A to node B, that's node B being asked to switch to the requested encoding mode for its audio encoder, which changes the bit rate of the RTP stream going from node B to node A 💫. Once a node sets this field to a value, it SHOULD keep setting the same value in later packets until the requested mode changes 🔒. This helps avoid the codec getting stuck in an unintended state if one of the packets carrying the Mode Request gets lost 🛟. A node that's otherwise silent MAY send an RTP packet containing a blank frame in order to send a Mode Request 🌈.
Each codec type using this format SHOULD define its own interpretation of the Mode Request field 🎀. Codecs SHOULD follow the convention that higher values of the three-bit field correspond to an equal or lower average output bit rate 💅.
For the EVRC codec, the Mode Request field MUST be interpreted according to Tables 2.2.1.2-1 and 2.2.1.2-2 of the EVRC codec specifications [1] 📚.
For the SMV codec, the Mode Request field MUST be interpreted according to Table 2.2-2 of the SMV codec specifications [2] 🦋.
11. Storage Format ✨
Okay so the storage format is for when you want to save speech frames somewhere, like a file or an email attachment 📎💜
Every file starts with a magic number so everyone knows which vocoder made it 🔥 For EVRC, the magic number is the ASCII string "#!EVRC\n", which is the bytes 0x23 0x21 0x45 0x56 0x52 0x43 0x0A. For SMV, it's the ASCII string "#!SMV\n", which is 0x23 0x21 0x53 0x4d 0x56 0x0a 🎀
Then the codec data frames get stored back to back in consecutive order 🧚 Each one gets a single TOC entry field in front of it, extended to one octet. You extend the ToC field by setting the four most significant bits of the octet to zero. So a ToC value of 4 (a full-rate frame) gets stored as 0x04 🍓
This part is a MUST, bestie 🫶 Speech frames lost in transmission and non-received frames MUST be stored as erasure frames (frame type 5, see definition in Section 5.1) so everything stays in sync with the original media 💅
12. IANA Considerations 🌈
Four new MIME sub-types were registered by the IANA, and they're all described in this section, so let's go ✨
The MIME-names for the EVRC and SMV codecs were allocated from the IETF tree, because all the vocoders covered here are expected to be widely used for Voice-over-IP applications. Main character energy 👑
12.1. Registration of Media Type EVRC
Here's the full registration for EVRC. The template is kept exactly as written because registry entries have to be precise 💖
Media Type Name: audio
Media Subtype Name: EVRC
Required Parameter: none
Optional parameters:
The following parameters apply to RTP transfer only.
ptime: Defined as usual for RTP audio (see RFC 2327).
maxptime: The maximum amount of media which can be encapsulated in
each packet, expressed as time in milliseconds. The time SHALL
be calculated as the sum of the time the media present in the
packet represents. The time SHOULD be a multiple of the
duration of a single codec data frame (20 msec). If not
signaled, the default maxptime value SHALL be 200 milliseconds.
maxinterleave: Maximum number for interleaving length (field LLL
in the Interleaving Octet). The interleaving lengths used in
the entire session MUST NOT exceed this maximum value. If not
signaled, the maxinterleave length SHALL be 5.
Encoding considerations:
This type is defined for transfer of EVRC-encoded data via RTP
using the Interleaved/Bundled packet format specified in Sections
4.1, 6, and 7 of RFC 3558. It is also defined for other transfer
methods using the storage format specified in Section 11 of RFC
3558.
Security considerations:
See Section 14 "Security Considerations" of RFC 3558.
Public specification:
The EVRC vocoder is specified in 3GPP2 C.S0014. Transfer methods
are specified in RFC 3558.
Additional information:
The following information applies for storage format only.
Magic number: #!EVRC\n (see Section 11 of RFC 3558)
File extensions: evc, EVC
Macintosh file type code: none
Object identifier or OID: none
Intended usage:
COMMON. It is expected that many VoIP applications (as well as
mobile applications) will use this type.
Person & email address to contact for further information:
Adam Li
adamli@icsl.ucla.edu
Author/Change controller:
Adam Li
adamli@icsl.ucla.edu
IETF Audio/Video Transport Working Group12.2. Registration of Media Type EVRC0
Next up is EVRC0, which is the header-free version 🦋 Here's the template, verbatim:
Media Type Name: audio
Media Subtype Name: EVRC0
Required Parameters: none
Optional parameters: none
Encoding considerations: none
This type is only defined for transfer of EVRC-encoded data via
RTP using the Header-Free packet format specified in Section 4.2
of RFC 3558.
Security considerations:
See Section 14 "Security Considerations" of RFC 3558.
Public specification:
The EVRC vocoder is specified in 3GPP2 C.S0014. Transfer methods
are specified in RFC 3558.
Additional information: none
Intended usage:
COMMON. It is expected that many VoIP applications (as well as
mobile applications) will use this type.
Person & email address to contact for further information:
Adam Li
adamli@icsl.ucla.edu
Author/Change controller:
Adam Li
adamli@icsl.ucla.edu
IETF Audio/Video Transport Working Group12.3. Registration of Media Type SMV
Now SMV 🎶 Same vibe as EVRC, with its own vocoder spec. Here's the template:
Media Type Name: audio
Media Subtype Name: SMV
Required Parameter: none
Optional parameters:
The following parameters apply to RTP transfer only.
ptime: Defined as usual for RTP audio (see RFC 2327).
maxptime: The maximum amount of media which can be encapsulated
in each packet, expressed as time in milliseconds. The time
SHALL be calculated as the sum of the time the media present
in the packet represents. The time SHOULD be a multiple of the
duration of a single codec data frame (20 msec). If not
signaled, the default maxptime value SHALL be 200
milliseconds.
maxinterleave: Maximum number for interleaving length (field LLL
in the Interleaving Octet). The interleaving lengths used in
the entire session MUST NOT exceed this maximum value. If not
signaled, the maxinterleave length SHALL be 5.
Encoding considerations:
This type is defined for transfer of SMV-encoded data via RTP
using the Interleaved/Bundled packet format specified in Section
4.1, 6, and 7 of RFC 3558. It is also defined for other transfer
methods using the storage format specified in Section 11 of RFC
3558.
Security considerations:
See Section 14 "Security Considerations" of RFC 3558.
Public specification:
The SMV vocoder is specified in 3GPP2 C.S0030-0 v2.0.
Transfer methods are specified in RFC 3558.
Additional information:
The following information applies to storage format only.
Magic number: #!SMV\n (see Section 11 of RFC 3558)
File extensions: smv, SMV
Macintosh file type code: none
Object identifier or OID: none
Intended usage:
COMMON. It is expected that many VoIP applications (as well as
mobile applications) will use this type.
Person & email address to contact for further information:
Adam Li
adamli@icsl.ucla.edu
Author/Change controller:
Adam Li
adamli@icsl.ucla.edu
IETF Audio/Video Transport Working Group12.4. Registration of Media Type SMV0
Last one, the header-free SMV version 🌸 Here's the template:
Media Type Name: audio
Media Subtype Name: SMV0
Required Parameter: none
Optional parameters: none
Encoding considerations: none
This type is only defined for transfer of SMV-encoded data via RTP
using the Header-Free packet format specified in Section 4.2 of
RFC 3558.
Security considerations:
See Section 14 "Security Considerations" of RFC 3558.
Public specification:
The SMV vocoder is specified in 3GPP2 C.S0030-0 v2.0. Transfer
methods are specified in RFC 3558.
Additional information: none
Intended usage:
COMMON. It is expected that many VoIP applications (as well as
mobile applications) will use this type.
Person & email address to contact for further information:
Adam Li
adamli@icsl.ucla.edu
Author/Change controller:
Adam Li
adamli@icsl.ucla.edu
IETF Audio/Video Transport Working Group13. Mapping to SDP Parameters 🎀
Heads up, this section only applies to RTP transfer 💅
The info in the MIME media type spec maps neatly onto fields in the Session Description Protocol (SDP) [6], which is what people usually use to describe RTP sessions. When SDP describes sessions using the EVRC or EMV codec, the mapping goes like this:
- The MIME type ("audio") goes in SDP "m=" as the media name.
- The MIME subtype (payload format name) goes in SDP "a=rtpmap" as the encoding name.
- The parameters "ptime" and "maxptime" go in the SDP "a=ptime" and "a=maxptime" attributes, respectively.
- The parameter "maxinterleave" goes in the SDP "a=fmtp" attribute by copying it directly from the MIME media type string as "maxinterleave=value".
Here are some SDP examples for EVRC and SMV, so you can see it in action 🦋
Example of usage of EVRC:
m=audio 49120 RTP/AVP 97
a=rtpmap:97 EVRC/8000
a=fmtp:97 maxinterleave=2
a=maxptime:80Example of usage of SMV
m=audio 49122 RTP/AVP 99
a=rtpmap:99 SMV0/8000
a=fmtp:99One tiny detail 🙈 The payload format (encoding) names are commonly shown in upper case, and MIME subtypes are commonly shown in lower case. Both are case-insensitive. Parameter names are case-insensitive too, both in MIME types and in the default mapping to the SDP a=fmtp attribute.
14. Security Considerations 💀
Okay bestie, this one is serious, so read it closely 🔥
RTP packets using the payload format from this spec are subject to the security considerations in the RTP spec [4] and any appropriate profile (for example [5]). That means confidentiality of the media streams is achieved by encryption. The compression used with this payload format is applied end-to-end, so encryption can happen after compression with no conflict between the two 🔐
There's a potential denial-of-service threat for data encoding that uses compression techniques with non-uniform receiver-end computational load. An attacker can inject pathological datagrams into the stream that are complex to decode and overload the receiver. However, the encodings covered in this document don't show any significant non-uniformity, so we're safe on that front 🙌
As with any IP-based protocol, a receiver can sometimes get overloaded just from receiving too many packets, whether they're wanted or not. Network-layer authentication can be used to discard packets from unwanted sources, but the processing cost of the authentication itself might be too high 😭 In a multicast environment, pruning of specific sources may be implemented in future versions of IGMP [7] and in multicast routing protocols, so a receiver can pick which sources are allowed to reach it.
Interleaving may affect encryption. Depending on the encryption scheme, there may be restrictions on things like when keys can be changed. Specifically, the key change may need to happen at the boundary between interleave groups 🧚
15. Adding Support of Other Frame-Based Vocoders 👑
As we covered above, the RTP packet format in this document is super flexible and designed to be usable by other frame-based vocoders 🌈
Any additional vocoder using this format MUST have the properties described in Section 3.3. Non-negotiable, bestie 💅
For an eligible vocoder to use the payload format mechanisms defined here, a new RTP payload format document needs to be published as a standards track RFC. That document can simply refer to this one and then specify the following parameters:
- Define the unit used for RTP time stamp;
- Define the meaning of the Mode Request bits;
- Define corresponding codec data frame type values for ToC;
- Define the conversion procedure for vocoders output data frame;
- Define a magic number for storage format, and complete the corresponding MIME registration.
16. Acknowledgements ✨
okay bestie, the people who helped shape this doc deserve a big group hug 🫶 The following authors made significant contributions to this document: Adam H. Li, John D. Villasenor, Dong-Seek Park, Jeong-Hoon Park, Keith Miller, S. Craig Greer, David Leon, Nikolai Leung, Marcello Lioy, Kyle J. McKay, Magdalena L. Espelien, Randall Gellens, Tom Hiller, Peter J. McCann, Stinson S. Mathai, Michael D. Turner, Ajay Rajkumar, Dan Gal, Magnus Westerlund, Lars-Erik Jonsson, Greg Sherwood, and Thomas Zeng. 💅🌈
17. References 📚
17.1 Normative 💜
- [1] 3GPP2 C.S0014, "Enhanced Variable Rate Codec, Speech Service Option 3 for Wideband Spread Spectrum Digital Systems", January 1997. 🎀
- [2] 3GPP2 C.S0030-0 v2.0, "Selectable Mode Vocoder, Service Option for Wideband Spread Spectrum Communication Systems", May 2002. 🦋
- [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 🔥
- [4] Schulzrinne, H., Casner, S., Jacobson, V. and R. Frederick, "RTP: A Transport Protocol for Real-Time Applications", RFC 3550, July 2003. ✨
- [5] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", RFC 3551, July 2003. 🌸
- [6] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998. 🧚
17.2 Informative 🍓
- [7] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC 1112, August 1989. 💖
18. Author's Address 📬
Adam H. Li Image Communication Lab Electrical Engineering Department University of California Los Angeles, CA 90095 USA
Phone: +1 310 825 5178 EMail: adamli@icsl.ucla.edu
19. Full Copyright Statement ⭐
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 🩷
Acknowledgement 🌷
Funding for the RFC Editor function is currently provided by the Internet Society. 🎀
📦 where this page comes from
- ietf: rfc3558 2003-07
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms