RFC 7655

RTP Payload Format for G.711.0

📅 published November 2015, from ietf

RFC 7655: RTP Payload Format for G.711.0 🎀

okay bestie, this is the RFC that tells you how to shove G.711 voice packets through RTP in a compressed form, and the compression is lossless and stateless 🫶

  • Number: RFC 7655
  • Title: RTP Payload Format for G.711.0
  • Authors: M. Ramalho, Ed. (Editor), P. Jones (Cisco Systems), N. Harada (NTT), M. Perumal (Ericsson), L. Miao (Huawei Technologies) 👑
  • Category: Standards Track ✨
  • ISSN: 2070-1721
  • Date: November 2015
  • Stream: IETF, the Internet Engineering Task Force 🌸

Abstract

okay so the abstract is basically the whole vibe in four lines 💖 This doc spells out the RTP payload format for ITU-T Recommendation G.711.0. G.711.0 is a lossless and stateless compression for G.711 packet payloads, the kind you usually find running over IP networks. The doc also defines a storage mode format for G.711.0, plus a media type registration for the G.711.0 RTP payload format 🦋

Status of This Memo

this one's giving official paperwork energy but it matters 📋

This is an Internet Standards Track document.

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7655.

Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 🔒

Table of Contents 🧭

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   4
3.  G.711.0 Codec Background  . . . . . . . . . . . . . . . . . .   4
  3.1.  General Information and Use of the ITU-T G.711.0 Codec  .   4
  3.2.  Key Properties of G.711.0 Design  . . . . . . . . . . . .   6
  3.3.  G.711 Input Frames to G.711.0 Output Frames . . . . . . .   8
    3.3.1.  Multiple G.711.0 Output Frames per RTP Payload
            Considerations  . . . . . . . . . . . . . . . . . . .   9
4.  RTP Header and Payload  . . . . . . . . . . . . . . . . . . .  10
  4.1.  G.711.0 RTP Header  . . . . . . . . . . . . . . . . . . .  10
  4.2.  G.711.0 RTP Payload . . . . . . . . . . . . . . . . . . .  12
    4.2.1.  Single G.711.0 Frame per RTP Payload Example  . . . .  12
    4.2.2.  G.711.0 RTP Payload Definition  . . . . . . . . . . .  13
      4.2.2.1.  G.711.0 RTP Payload Encoding Process  . . . . . .  14
    4.2.3.  G.711.0 RTP Payload Decoding Process  . . . . . . . .  15
    4.2.4.  G.711.0 RTP Payload for Multiple Channels . . . . . .  17
5.  Payload Format Parameters . . . . . . . . . . . . . . . . . .  19
  5.1.  Media Type Registration . . . . . . . . . . . . . . . . .  20
  5.2.  Mapping to SDP Parameters . . . . . . . . . . . . . . . .  22
  5.3.  Offer/Answer Considerations . . . . . . . . . . . . . . .  22
  5.4.  SDP Examples  . . . . . . . . . . . . . . . . . . . . . .  23
    5.4.1.  SDP Example 1 . . . . . . . . . . . . . . . . . . . .  23
    5.4.2.  SDP Example 2 . . . . . . . . . . . . . . . . . . . .  23
6.  G.711.0 Storage Mode Conventions and Definition . . . . . . .  24
  6.1.  G.711.0 PLC Frame . . . . . . . . . . . . . . . . . . . .  24
  6.2.  G.711.0 Erasure Frame . . . . . . . . . . . . . . . . . .  25
  6.3.  G.711.0 Storage Mode Definition . . . . . . . . . . . . .  26
7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  27
8.  Security Considerations . . . . . . . . . . . . . . . . . . .  27
9.  Congestion Control  . . . . . . . . . . . . . . . . . . . . .  28
10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  29
  10.1.  Normative References . . . . . . . . . . . . . . . . . .  29
  10.2.  Informative References . . . . . . . . . . . . . . . . .  30
Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  31
Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  31
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  31

1. Introduction ✨

okay so the ITU-T Recommendation G.711.0 [G.711.0] is the one that specifies a stateless and lossless compression for G.711 packet payloads, which you'll usually see in Voice over IP (VoIP) networks 📞 This document is the part that defines the Real-time Transport Protocol (RTP) RFC 3550 [RFC3550] payload format and the storage modes for that compression 💜

2. Requirements Language 📜

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 [RFC2119]. 🎀

3. G.711.0 Codec Background 🎧

okay so G.711.0 [G.711.0] is a lossless and stateless compression mechanism for ITU-T Recommendation G.711 [G.711]. That means it isn't a "codec" in the "lossy" sense that RTP usually carries 🙈 When it's negotiated end-to-end, G.711.0 gets negotiated as if it were a codec, but the idea is that G.711.0 losslessly encoded the underlying (lossy) G.711 Pulse Code Modulation (PCM) sample representation of an audio signal. Because of that, G.711.0 gets called a "lossless data compression algorithm" or a "codec" in this doc, depending on the context 🦋 Inside this doc, individual G.711 PCM samples are called "G.711 symbols" or just "symbols" for brevity 💅

This section describes the ITU-T Recommendation G.711 [G.711] codec, its properties, typical uses cases, and its key design properties. 🌈

3.1. General Information and Use of the ITU-T G.711.0 Codec 💖

ITU-T Recommendation G.711 is the benchmark standard for narrowband telephony. It's been successful for many decades thanks to its proven voice quality, ubiquity, and utility 👑 A newer ITU-T recommendation, G.711.0, got established to define a stateless and lossless compression for G.711 packet payloads typically used in VoIP networks ✨ G.711.0 is also known as ITU-T Rec. G.711 Annex A [G.711-A1], because ITU-T Rec. G.711 Annex A is effectively a pointer to ITU-T Rec. G.711.0 🔥 From here on, ITU-T Rec. G.711.0 is just called "G.711.0" and ITU-T Rec. G.711 is just called "G.711" 🫶

G.711.0 may be employed end-to-end, and in that case the RTP payload format specification and use is nearly identical to the G.711 RTP specification found in RFC 3551 [RFC3551] 🍓 The only significant difference for G.711.0 is the required use of a dynamic payload type (the static PT of 0 or 8 is presently almost always used with G.711, even though dynamic assignment of other payload types is allowed) plus the recommendation not to use Voice Activity Detection (see Section 4.1) 🙈

Here's the lowkey genius part 🧚 G.711.0 is both lossless and stateless, so it can also be employed as a lossless compression mechanism for G.711 payloads anywhere between end systems that have negotiated use of G.711. The only significant difference between the G.711 RTP payload format header and the G.711.0 payload format header defined in this document is the payload type. So a G.711 RTP packet can be losslessly converted to a G.711.0 RTP packet by compressing the G.711 payload (creating a G.711.0 payload), changing the payload type to the dynamic value you want, and copying all the remaining G.711 RTP header fields into the matching G.711.0 RTP header 💜 Going the other way works the same: you losslessly decompress the G.711.0 payload back to the original source G.711 payload, change the payload type back to the one from the original G.711 RTP packet, and copy all the remaining G.711.0 RTP header fields into the matching G.711 RTP header 🌸 A packet made by that compression and decompression is indistinguishable in every detail from the source G.711 packet, so the compression can be totally invisible to the end systems 🤯 How systems on the path between the end systems discover each other and negotiate G.711.0 compression, like described in this paragraph, is outside the scope of this document 🙏

It's informative to note that G.711.0 is both lossless and stateless, so it can be employed multiple times (for example, on multiple individual hops or series of hops) on a given flow with no degradation of quality relative to end-to-end G.711 ✨ Put another way, multiple "lossless transcodes" from/to G.711.0/G.711 don't affect voice quality the way lossy transcodes to/from dissimilar codecs typically do 😭

Lastly, G.711.0 is expected to be used as an archival format for recorded G.711 streams 📼 That's why a G.711.0 Storage Mode Format is also included in this document 💅

3.2. Key Properties of G.711.0 Design ✨

okay so bestie, the whole design of G.711.0 came from one big goal 🎀: losslessly encode and compress frames of G.711 symbols NO MATTER what kind of signal is inside them 💅. The main use case is G.711 encoded, zero-mean, acoustic signals (like speech and music) 🎶.

Here are the G.711.0 attributes, lowkey the whole personality of this codec 🦋:

A1 Compression for zero-mean acoustic signals: G.711.0 was built for "speech" or other zero-mean acoustic signals as its main gig 🌸. It gets greater than 50% average compression in service provider environments [ICASSP] ✨. Ate and left no crumbs 💅.

A2 Lossless for any G.711 payload: G.711.0 is lossless for ANY valid G.711 payload 🔥, even if it's apparently random G.711 symbols (like a modem or FAX payload) 💀. So you could use it for "aggregate 64 kbps G.711 channels" carried over IP without stressing if some channels are carrying something other than voice or general audio 🫶. If a channel is carrying something that isn't voice or general audio, G.711.0 still makes sure it's carried losslessly, even if it doesn't compress much 🧚.

A3 Stateless: Compressing a frame of G.711 symbols only depends on that frame, not any frame before it 🌈. Yes, more compression is usually possible by looking at a longer history of past symbols, but the designers went stateless to completely kill error propagation, which is a big problem in many lossy codecs (like ITU-T Rec. G.729 [G.729] and ITU-T Rec. G.722 [G.722]) 😭. So the decoder doesn't need to worry about lost prior packets, because decompressing a G.711.0 frame doesn't depend on any earlier G.711.0 frames 💖. Because of this stateless property, the frames going into the G.711.0 encoder can change "on-the-fly" (a 5 ms encoding could be followed by a 20 ms encoding) 🦋.

A4 Self-describing: This means you can figure out how many source G.711 samples are in a G.711.0 frame using ONLY info inside that frame 👑. You do this by decoding the initial octets of the compressed G.711.0 frame (called "prefix codes" in the standard) 🎀. A G.711.0 decoder doesn't need to know how many symbols were in the original G.711 frame (for example, parameter ptime in the Session Description Protocol (SDP) [RFC4566]), because it can decompress the frame without any signaling knowledge 🙈✨.

A5 Accommodate G.711 payload sizes typically used in IP: G.711 input frames you usually see in VoIP apps represent SDP ptime values of 5 ms, 10 ms, 20 ms, 30 ms, or 40 ms 🌸. Since the dominant sampling frequency for G.711 is 8000 samples per second, G.711.0 was designed to compress G.711 input frames of 40, 80, 160, 240, or 320 samples 💅.

A6 Bounded expansion: Since A2 says G.711.0 must be lossless for any payload (which could be any combination of octets, each spanning the full 2^8 values), there has to be at least one G.711 payload that can't be compressed 😭. The quantum of compression is one octet, so the smallest expansion for such an uncompressible payload was designed to be just one octet 🫶. So G.711.0 "compressed" frames can be anywhere from one octet to X+1 octets, where X is the size of the input G.711 frame in octets 🌈. That makes G.711.0 a Variable Bit Rate (VBR) encoding, where the size of the output frame depends on the G.711 symbols you feed in 🦋.

A7 Algorithmic delay: G.711.0 was designed so its algorithmic delay equals the time represented by the number of samples in the G.711 input frame (no "look-ahead") ⭐.

A8 Low Complexity: Less than 1.0 Weighted Million Operations Per Second (WMOPS) on average, with a low memory footprint (~5k octets RAM, ~5.7k octets ROM, and ~3.6 basic operations) [ICASSP] [G.711.0] 💜. Low key a flex 💅.

A9 Both A-law and mu-law supported: G.711 has two operating laws, A-law and mu-law 🌸. In RTP applications these are also known as PCMA and PCMU [RFC3551] 🎀.

These attributes make it pretty trivial to compress a G.711 input frame of 40, 80, 160, 240, or 320 samples 🔥. After the input frame goes into a G.711.0 encoder, out comes a "self-describing" G.711.0 output frame ✨. The number of samples in that frame is easy to figure out at the G.711.0 decoder thanks to A4 👑. The decoder can turn the G.711.0 frame back into a G.711 frame using ONLY the data inside the G.711.0 frame 💖.

Lastly, losing a G.711.0 encoded packet is the same as losing a G.711 packet (when using RTP) 🥺, because a G.711.0 payload is stateless, just like the G.711 payload 🦋. So existing G.711 Packet Loss Concealment (PLC) mechanisms are expected to be used when a G.711.0 packet gets lost, and the MOS degradation will be identical to G.711 loss 🌈💅.

3.3. G.711 Input Frames to G.711.0 Output Frames 🎀

G.711.0 is a lossless and stateless compression of G.711 frames 💜. Figure 1 shows this, where "A" is G.711.0 encoding and "B" is G.711.0 decoding 🧚.

    |--------------------------|  A   |------------------------------|
    |    G.711 Input Frame     |----->|     G.711.0 Output Frame     |
    |       of X Octets        |      |  containing 1 to X+1 Octets  |
    | (where X MUST be 40, 80, |      | (precise value dependent on  |
    | 160, 240, or 320 octets) |<-----| G.711.0 ability to compress) |
    |__________________________|  B   |______________________________|

Figure 1: 1:1 Mapping from G.711 Input Frame to G.711.0 Output Frame

Note that the mapping is 1:1 (lossless) in both directions, with two constraints 🫶. First, the input frame given to the G.711.0 encoder ("process A") must have a specific number of input G.711 symbols consistent with A5 (40, 80, 160, 240, or 320 octets) 💅. Second, the companding law used to create the G.711 input frame (A-law or mu-law) MUST be known, consistent with A9 🔥.

Given those two constraints, the G.711.0 encoder ("process A") takes the input G.711 frame and produces a "self-describing" G.711.0 output frame, consistent with A4 ✨. Depending on the source G.711 symbols, the G.711.0 output frame can be anywhere from 1 to X+1 octets, where X is the number of input G.711 symbols 🌸. Compression results for virtually every zero-mean acoustic signal encoded by G.711.0 👑.

Since the G.711.0 output frame is "self-describing", a G.711.0 decoder ("process B") can losslessly reproduce the original G.711 input frame knowing ONLY which companding law was used (A-law or mu-law) 💖. The first octet of a G.711.0 frame is called the "Prefix Code" octet 🎀. The info in this octet tells the decoder how many G.711 symbols to create from a given G.711.0 input frame (0, 40, 80, 160, 240, or 320) 🦋. The Prefix Code value of 0x00 means zero G.711 source symbols, which lets 0x00 be used as a payload padding octet (described later in Section 3.3.1) 🧚🌈.

Since G.711.0 was designed around typical G.711 payload lengths (A5), this lossless encoding MUST only be performed with knowledge of the companding law being used 🔥. This info is expected to be signaled in SDP and is described later in this document 🙈.

If the original inputs were known to be from a zero-mean acoustic signal coded by G.711, an intelligent G.711.0 encoder could infer the G.711 companding law in use (via G.711 input signal amplitude histogram statistics) ✨. Likewise, an intelligent G.711.0 decoder producing G.711 from G.711.0 frames could also infer which encoding law is in use 💅. So G.711.0 could be designed for applications with limited stream signaling between G.711 endpoints (where they only know "G.711 at 8k sampling is being used" and nothing more) 🌸. That usage isn't described further in this document 🫶. Also, if the original inputs were known to come from zero-mean acoustic signals, an intelligent G.711.0 encoder could tell whether the G.711.0 payload had been encrypted, because the symbols wouldn't have the distribution expected under either companding law and would look random 👀💀. That determination isn't discussed further in this document either 🎀.

It is easily seen that this process is 1:1 and that lossless compression based on G.711.0 can be applied multiple times, because the original G.711 input symbols are always reproduced with 100% fidelity 💖👑.

3.3.1. Multiple G.711.0 Output Frames per RTP Payload Considerations ✨

Okay so as a general rule, G.711.0 frames that hold more source G.711 symbols (from a given channel) will typically compress better 🗜️, but there are exceptions, so don't get too comfy. An encoder can take 20 ms of input G.711 symbols and encode them as 1) one 20 ms G.711.0 frame, 2) two 10 ms G.711.0 frames, or 3) any other mix of 5 ms or 10 ms G.711.0 frames. Whichever one comes out with fewer bits wins 🏆. For example, an intelligent encoder might pick two 10 ms frames if the first 10 ms was "silence" and those two frames took fewer bits than any other possible combo of G.711.0 frame sizes. Iconic behavior, honestly 💅.

While G.711.0 was being standardized, people realized that sometimes it's worth encoding in whatever multiple-of-40-symbols format squishes the most (like we just said), but the simplest choice is to put the whole ptime's worth of input G.711 symbols into one G.711.0 frame (if the ptime supports that). This is especially true because more source symbols usually gave the best compression anyway, and searching through all those other multi-frame possibilities is extra complexity that was unlikely to produce a more bit-efficient result 🙈.

The G.711.0 design planned ahead for multiple input frames 🧠. The decoder was defined to decode what it calls an incoming "bit stream." For this spec, the bit stream is the G.711.0 RTP payload itself. So the decoder takes the whole G.711.0 RTP payload and produces an output frame with the original G.711 symbols, no matter how many G.711.0 frames were in it. Also, any number of 0x00 padding octets placed between the G.711.0 frames gets silently (and safely) ignored by the G.711.0 decoding process (see Section 4.2.3) 🫶.

To recap: a G.711.0 encoder can turn incoming G.711 symbols into one or more G.711.0 frames and put those frame(s) into the G.711.0 RTP payload. Zero or more 0x00 padding octets can also show up in the G.711.0 RTP payload. The G.711.0 decoder doesn't care how many G.711.0 frames are inside, so it decodes the whole G.711.0 RTP payload back into the source G.711 symbols 🦋. Single-frame and multi-frame cases are shown in Section 4.2, but the multiple G.711.0 frame cases MUST be supported, and there is no need for any negotiation (SDP or otherwise) for it 💖.

4. RTP Header and Payload 🎀

In this section we get into the precise format for G.711.0 frames carried via RTP 🌸. We start with an RTP header description relative to G.711, then go through two G.711.0 payload examples 🧚.

4.1. G.711.0 RTP Header

Compared to G.711 RTP headers, using G.711.0 doesn't create any special requirements for the contents of the RTP packet header 💅. The only big difference is that the payload type (PT) RTP header field MUST have a value that matches the dynamic payload type assigned to the flow. That's different from most current G.711 uses, which usually use the static payload assignments of PT = 0 (PCMU) or PT = 8 (PCMA) [RFC3551], even though dynamic payload types are allowed for G.711 too 🙃. Except in rare PT exhaustion cases, the existing G.711 PT values of 0 and 8 MUST NOT be used for G.711.0 (this helps avoid possible payload confusion with G.711 payloads) 🚫.

Voice Activity Detection (VAD) SHOULD NOT be used when G.711.0 is negotiated 🙅‍♀️. That's because G.711.0 gets high compression during "VAD silence intervals," and one of the perks of G.711.0 over G.711 with VAD is that there are no VAD-inducing artifacts in the received signal ✨. But if VAD is used anyway, the Marker bit (M) MUST be set in the first packet of a talkspurt. A talkspurt starts with the first packet after a silence period where packets weren't sent back-to-back, following the rules in [RFC3551] for G.711 payloads. This matches how G.711 RTP VAD already works, and it also allows lossless transcoding between G.711 RTP packets and G.711.0 RTP packets, as described in Section 3.1 🔁.

With that intro out of the way, here's how the RTP packet header fields are defined:

  • V - As per [RFC3550]
  • P - As per [RFC3550]
  • X - As per [RFC3550]
  • CC - As per [RFC3550]
  • M - As per [RFC3550] and [RFC3551]
  • PT - The assignment of an RTP payload type for the format defined in this memo is outside the scope of this document. The RTP profiles in use currently mandate binding the payload type dynamically for this payload format (e.g., see [RFC3550] and [RFC4585]).
  • SN - As per [RFC3550]
  • timestamp - As per [RFC3550]
  • SSRC - As per [RFC3550]
  • CSRC - As per [RFC3550]

So basically: V (version bits), P (padding bit), X (extension bit), CC (CSRC count), M (marker bit), PT (payload type), SN (sequence number), timestamp, SSRC (synchronizing source) and CSRC (contributing sources) are all as defined in [RFC3550] and are used the usual way with G.711 🥰. PT (payload type) is as defined in [RFC3551] 💜.

4.2. G.711.0 RTP Payload

This section defines the G.711.0 RTP payload and shows it off with two examples 🍓.

The first example, in Section 4.2.1, covers the case where you only want one G.711.0 frame in the RTP payload. This is expected to be the main use case, so it gets its own section for clarity 👑.

The second example, in Section 4.2.2, covers the general case, where you want one or more G.711.0 frames in the RTP payload. This is the actual definition of the G.711.0 RTP payload 🌈.

4.2.1. Single G.711.0 Frame per RTP Payload Example

This example shows a single G.711.0 frame in the RTP payload. It's expected to be the dominant RTP payload case for G.711.0, because the G.711.0 encoding process supports the SDP packet times (ptime and maxptime, see [RFC4566]) that are commonly used when G.711 is carried over RTP ⭐. Also, like we said before, larger G.711.0 frames usually compress better than a bunch of smaller ones 🗜️.

Here's the single G.711.0 frame per RTP payload case:

             |-------------------|-------------------|
             | One G.711.0 Frame | Zero or more 0x00 |
             |                   |   Padding Octets  |
             |___________________|___________________|

        Figure 2: Single G.711.0 Frame in RTP Payload Case

Encoding Process: A single G.711.0 frame is inserted into the RTP payload. The amount of time represented by the G.711 symbols compressed in the G.711.0 frame MUST correspond to the ptime signaled for applications using SDP. Padding after the G.711.0 frame MAY be created by placing one or more 0x00 octets after it. It's generally not desired, but it might be wanted based on the Security Considerations (see Section 8) 🔒.

Decoding Process: Passing the entire RTP payload to the G.711.0 decoder is enough for the decoder to create the source G.711 symbols 🎉. Any padding after the G.711.0 frame (i.e., the 0x00 octets) in the RTP payload is silently ignored by the G.711.0 decoding process. The decoding process is fully described in Section 4.2.3 🦋.

4.2.2. G.711.0 RTP Payload Definition

This section defines the G.711.0 RTP payload and covers the case where one or more G.711.0 frames go in the payload. All G.711.0 RTP decoders MUST support the general case described in this section (the reasoning was covered earlier in Section 3.3.1) 🫶.

Note that each G.711.0 frame is self-describing (see Attribute A4 in Section 3.2), so the individual G.711.0 frames in the RTP payload don't need to cover the same amount of time. For example, a 5 ms G.711.0 frame could be followed by a 20 ms G.711.0 frame 🧩. Because of that, the amount of time represented in the RTP payload MAY be any integer multiple of 5 ms, since 5 ms is the smallest interval of time that a G.711.0 frame can represent ⏱️.

Here's the one-or-more G.711.0 frames per RTP payload case, where N is the number of G.711.0 frames placed in the RTP payload. When N equals 1, this case is identical to the previous example 💅:

    |----------|---------|----------|---------|----------------|
    | First    | Second  |          | Nth     | Zero or more   |
    | G.711.0  | G.711.0 |   ...    | G.711.0 |     0x00       |
    | Frame    | Frame   |          | Frame   | Padding Octets |
    |__________|_________|__________|_________|________________|

      Figure 3: One or More G.711.0 Frames in RTP Payload Case

Here's the tea 🍵: when there are multiple G.711.0 frames, the individual frames can be (and usually are) different lengths. The decoding process described in Section 4.2.3 is used to figure out where the frame boundaries are 🔍.

Encoding Process: One or more G.711.0 frames are placed in the RTP payload simply by concatenating them together. The amount of time represented by the G.711 symbols compressed across all the G.711.0 frames in the RTP payload MUST correspond to the ptime signaled for applications using SDP. Padding in the RTP payload isn't usually wanted, but if it's there it SHOULD go after the last G.711.0 frame in the payload, and it MAY be created by placing one or more 0x00 octets after the last G.711.0 frame. Padding like this may be desired based on security considerations (see Section 8) 🛡️. More details about the encoding process and considerations come later in Section 4.2.2.1 ✨.

Decoding Process: Since G.711.0 frames can be different lengths, the payload decoding process described in Section 4.2.3 is used to find the individual G.711.0 frame boundaries 🗺️. Any padding octets inserted before or after any G.711.0 frame in the RTP payload are silently (and safely) ignored by the G.711.0 decoding process specified in Section 4.2.3 💖.

4.2.2.1. G.711.0 RTP Payload Encoding Process ✨

okay so ITU-T G.711.0 supports five possible input frame lengths: 40, 80, 160, 240, and 320 samples per frame 🎀. The reasoning behind those lengths was covered in property A5 in Section 3.2, so go check that if you're curious 🤓. At 8000 samples per second, those lengths work out to input frames of 5 ms, 10 ms, 20 ms, 30 ms, or 40 ms 🦋. The standard assumed the input "bit stream" was made of G.711 symbols in some integer multiple of 5 ms, but it never said which frame lengths to feed the G.711.0 encoder itself 🙈. This section is here to give you some guidance on picking them 💖.

Let's look at a super common IETF use case: 20 ms (160 octets) of G.711 input samples, carried in a G.711.0 payload and signaled with the SDP parameter ptime 💅. As Section 3.3.1 explains, the easiest move is to pass all 160 octets to the G.711.0 encoder in one go. That gives you exactly one G.711.0 compressed frame, and you drop that one frame into the G.711.0 RTP payload 🌸. But ngl, neither the ITU-T G.711.0 standard nor this IETF payload format makes you do it that way 🙌. Honestly, 20 ms of input G.711 symbols can be encoded as 1, 2, 3, or 4 G.711.0 frames, in any of six combinations:

{20ms}
{10ms:10ms}
{10ms:5ms:5ms}
{5ms:10ms:5ms}
{5ms:5ms:10ms}
{5ms:5ms:5ms:5ms}

Every one of those combos decompresses into the same source 160 G.711 octets, so they're all equally valid 🫶. Quick aside: the first octet of any G.711.0 frame is the prefix code octet, and the info in that octet tells you how many G.711 symbols live in that frame 🧚.

Anyway, implementers are expected to go with one of two approaches 👑. Option one is the simplest possible: a single 160-byte input to the G.711.0 encoder, which usually gives the highest compression. Option two is mixing and matching input frame combinations to get the highest compression for the payload 🔥. This is called out in this IETF document because the ITU-T G.711.0 standard says nothing on the topic, and people want it written down in a formal Standards Developing Organization (SDO) document (i.e., here) 📚.

4.2.3. G.711.0 RTP Payload Decoding Process 🧩

The G.711.0 decoding process is a standard part of G.711.0 bit stream decoding, and it lives in the ITU-T Rec. G.711.0 reference code 💜. The decoding algorithm in this section is a slightly souped-up version of that reference code, tweaked to handle RTP padding explicitly (like we talked about above) ✨.

Before we get into it, the biggest possible G.711.0 frame shows up when the most G.711 symbols get encoded (320, from Section 3.2, property A5), and all 320 of those symbols are "uncompressible" by the G.711.0 encoder 😭. In that case (thanks to property A6 in Section 3.2), the G.711.0 output frame is 321 octets long 🌈. Also, the value 0x00 used for the optional padding can't be the first octet of a valid ITU-T Rec. G.711.0 frame (see [G.711.0]) 🙈. And if there's more than one G.711.0 frame in the RTP payload, the decoding of each individual frame happens multiple times 💅.

Here's the vocab for the algorithm 🎀. N is the number of octets in the RTP payload, excluding any RTP padding but including any RTP payload padding. P is the number of RTP payload octets the G.711.0 decoding process has already handled. K is the number of G.711 symbols currently in the output buffer. Q is the number of octets in the G.711.0 frame being processed. And "!=" just means not equal to 💖. The keyword "STOP" marks the end of processing G.711.0 frames in the RTP payload 🛑. The algorithm assumes an output buffer big enough for the expected number of G.711 symbols, plus an input buffer that's 321 octets long 🦋.

Now the heuristic itself 👑:

G.711.0 RTP Payload Decoding Heuristic:

H1  Initialization of counters: Initialize P, the number of processed
      octets counter, to zero.  Initialize K, the counter for how
      many G.711 symbols are in the output buffer, to zero.
      Initialize N to the number of octets in the RTP payload
      (including any RTP payload padding).  Go to H2.

H2  Read internal buffer: Read min{320+1, (N-P)-1} octets into the
      internal buffer from the (P+1) octet of the RTP payload.  We
      note at this point, N-P octets have yet to be processed and
      that 320+1 octets is the largest possible G.711.0 frame.  Also
      note that in the common case of zero-based array indexing of a
      uint8 array of octets, that this operation will read octets
      from index P through index [min{320+1, (N-P)}] from the RTP
      payload.  Go to H3.

H3  Analyze the first octet in the internal buffer: If this octet is
      0x00 (a padding octet), go to H4; otherwise, go to H5 (process
      a G.711.0 frame).

H4  Process padding octet (no G.711 symbols generated): Increment the
      processed packets counter by one (set P = P + 1).  If the
      result of this increment results in P >= N, then STOP (as all
      RTP Payload octets have been processed); otherwise, go to H2.

H5  Process an individual G.711.0 frame (produce G.711 samples in the
      output frame): Pass the internal buffer to the G.711.0 decoder.
      The G.711.0 decoder will read the first octet (called the
      "prefix code" octet in ITU-T Rec. G.711.0 [G.711.0]) to
      determine the number of source G.711 samples M are contained in
      this G.711.0 frame.  The G.711.0 decoder will produce exactly M
      G.711 source symbols (M can only have values of 0, 40, 80, 160,
      240, or 320).  If K = 0, these M symbols will be the first in
      the output buffer and are placed at the beginning of the output
      buffer.  If K != 0, concatenate these M symbols with the prior
      symbols in the output buffer (there are K prior symbols in the
      buffer).  Set K = K + M (as there are now this many G.711
      source symbols in the output buffer).  The G.711.0 decoder will
      have consumed some number of octets, Q, in the internal buffer
      to produce the M G.711 symbols.  Increment the number of
      payload octets processed counter by this quantity (set P = P +
      Q).  If the result of this increment results in P >= N, then
      STOP (as all RTP Payload octets have been processed);
      otherwise, go to H2.

When you're done, the output buffer holds exactly K G.711 source symbols 🧁. Those should match the ptime you signaled in SDP, assuming the encoding went smoothly 🫶. Now here's the rule: if ptime was signaled via SDP and the number of G.711 symbols in the output buffer doesn't match it, the packet MUST be discarded 🚫. The exception is if other system design knowledge says otherwise, like occasional 5 ms clock slips that add or remove one G.711.0 frame from the payload 🕰️. And the safety net: the buffer reads in H2 are capped (at 321 octets or less), N is bounded by the size of the G.711.0 RTP payload, and M is bounded by the number of source G.711 symbols. So there's no buffer overrun risk 🛡️✨.

Quick aside: the algorithm above (and the ITU-T G.711.0 reference code) handles padding octets (0x00) anywhere between G.711.0 frames in the RTP payload, and also before or after any or all of them 🌷. The reference code doesn't have H3 and H4 as separate steps (H5 comes right after H2). That costs a bit of extra computation from passing buffers to and from the G.711.0 frame decoder functions 🐢. In other words, the reference decoder "silently ignores" 0x00 padding octets at the start of what it thinks is a G.711.0 frame boundary 🫣. So H3 and H4 are just an optimization on top of the reference code, included for clarity 💅.

If the decoder sits at a playout endpoint, this G.711 buffer SHOULD be handled the same way a received G.711 RTP payload would be (passed to a playout buffer, to a PLC implementation, and so on) 🎧.

One more important thing: a framing error happens whenever the buffer sent to a G.711.0 decoder doesn't start with a valid first G.711.0 frame octet (that means a valid G.711.0 prefix code or a 0x00 padding octet) 🚨. The decoder then won't produce the correct G.711 source symbols. Even so, the output from the G.711.0 decoder is capped (under 321 octets per G.711.0 decode request). And if you already know the number of (presumed) G.711 symbols produced is wrong, the decoded output MUST be discarded 💀.

4.2.4. G.711.0 RTP Payload for Multiple Channels ✨

okay bestie, this section is all about sending multiple "channels" of G.711 data through G.711.0 compression 🎧. The single-channel case is the one everyone uses, so for that you just follow the encoding and decoding process from above 💅. Multi-channel G.711.0 is a different beast though, because G.711.0 is frame-based while G.711 is sample-based, so it gets its own separate treatment here 🦋.

Section 4 of RFC 3551 [RFC3551] has the guidelines for encoding audio channels, and Section 4.1 of RFC 3551 [RFC3551] covers how the channels get ordered inside the RTP payload 🌸. The ordering guidelines in Section 4.1 of RFC 3551 SHOULD be used unless an application-specific channel ordering is more appropriate.

An assumption baked into RFC 3551 is that all the channel data multiplexed into one RTP payload MUST represent the same physical time span 🕰️. G.711.0 is no different. The underlying G.711 data for every channel in a G.711.0 RTP payload MUST span the same interval in time (for example, the same ptime for an SDP-negotiated codec).

Section 4.2 of RFC 3551 [RFC3551] gives guidance for sample-based encodings like G.711. Basically that's interleaving the individual samples, so they SHOULD be packed in consecutive octets 🧩.

RFC 3551 also has guidelines for frame-based encodings where the frames get interleaved. The catch is that this guidance depends on the assumption that "the frame size for the frame-oriented codecs is given". That assumption does NOT hold for G.711.0, because individual consecutive G.711.0 frames (as per Section 4.2.2 of this document) can:

  1. represent different time spans (for example, two 5 ms G.711.0 frames instead of one 10 ms G.711.0 frame), and
  2. be of different lengths in octets (and typically are).

So this RFC specifies a different approach, one that's still simple but based on concatenation 💖.

For the multiple channel G.711.0 case, each G.711 channel gets independently encoded into one or more G.711.0 frames. This group is defined here as a "G.711.0 channel superframe" 🎀. Each superframe matches the multiple G.711.0 frame case shown in Figure 3 of Section 4.2.2, where each superframe can hold one or more individual G.711.0 frames. Then each G.711.0 channel superframe gets concatenated, in channel order, into a G.711.0 RTP payload. If you want optional G.711.0 padding octets (0x00), it is RECOMMENDED that they go after the last G.711.0 channel superframe. As noted above, padding might be wanted because of the Security Considerations (see Section 8) 🔐. Here's the layout, shown in Figure 4:

        |----------|---------|----------|---------|---------|
        | First    | Second  |          | Nth     | Zero    |
        | G.711.0  | G.711.0 |   ...    | G.711.0 | or more |
        | Channel  | Channel |          | Channel | 0x00    |
        | Super-   | Super-  |          | Super   | Padding |
        | Frame    | Frame   |          | Frame   | Octets  |
        |__________|_________|__________|_________|_________|

Figure 4: Multiple G.711.0 Channel Superframes in RTP Payload

Something to vibe with: the individual superframes can be different lengths in octets (and usually are), but the number of G.711 source symbols represented in compressed form in each channel superframe is identical, because every channel covers the exact same time interval 🌈.

The G.711.0 decoder on the receiving end just decodes the whole multi-channel payload into individual G.711 symbols 🧠. If M such G.711 symbols come out and there were N channels, then the first M/N G.711 samples belong to the first channel, the next M/N samples belong to the second channel, and so on until you've found the Nth set of G.711 samples. If the number of channels isn't known but the payload ptime is, you can work out (knowing the sampling rate) how many G.711 symbols each channel holds. With that, you can figure out how many channels of data are in the payload. When SDP is used, the number of channels is known, because the optional parameter MUST be present when more than one channel is negotiated (see Section 5.1). And when SDP is used, the parameter ptime is a RECOMMENDED optional parameter too. If both channels and ptime are known, you can use one to check the other, and the converse. Whichever algorithm you use to find the number of channels, if the length of the source G.711 symbols in the payload (M) is not an integer multiple of the number of channels (N), then the packet SHOULD be discarded 🚫.

Last bit, and it's a good one 👀. Even though padding for the multiple channel G.711.0 payload is RECOMMENDED to go at the end, the G.711.0 decoding algorithm from Section 4.2.3 will still successfully decode the payload in Figure 4 if the 0x00 padding octet sits anywhere before or after any individual G.711.0 frame in the RTP payload. So the number of padding octets introduced at any G.711.0 frame boundary doesn't change the number M of source G.711 symbols produced. That means the decision to pad MAY be made on a per-superframe basis 🫶.

5. Payload Format Parameters 🎀

This section defines the parameters that may be used to set up optional features in the G.711.0 RTP transmission 💜.

These parameters are part of the media subtype registration for the G.711.0 codec. For apps that use SDP, RFC 4566 [RFC4566] mapping of the parameters into SDP is also provided 📋.

5.1. Media Type Registration

Here's the registration, bestie 📝:

  • Type name: audio
  • Subtype name: G711-0
  • Required parameters:
    • clock rate: The RTP timestamp clock rate, which equals the sampling rate. The typical rate used with G.711 encoding is 8000, but other rates may be specified. The default rate is 8000.
    • complaw: This format-specific parameter is specified on the "a=fmtp:" line and indicates the companding law (A-law or mu-law) in use. As per RFC 4566 [RFC4566], this format-specific parameter is passed unchanged to the media tool using this format. The case-insensitive values complaw=al and complaw=mu are used for A-law and mu-law, respectively.
  • Optional parameters:
    • channels: See RFC 4566 [RFC4566] for the definition. It specifies how many audio streams are represented in the G.711.0 payload, and it MUST be present if the number of channels is greater than one. This parameter defaults to 1 if not present (as per RFC 4566), and it's typically a non-zero, small-valued positive integer. Implementations that specify multiple channels are expected to also define a mechanism for mapping the channels appropriately within their system design. Otherwise, the channel order specified in Section 4.1 of RFC 3551 [RFC3551] will be assumed (for example, left, right, center). Similar to the usual interpretation in RFC 3551 [RFC3551], the number of channels SHALL be a non-zero, positive integer.
    • maxptime: See RFC 4566 [RFC4566] for the definition.
    • ptime: See RFC 4566 [RFC4566] for the definition. Including "ptime" is RECOMMENDED and it SHOULD be in the SDP, unless there's an application-specific reason not to include it (for example, an app with a variable ptime on a packet-by-packet basis). For constant ptime apps, it's considered good form to include "ptime" in the SDP for session diagnostic purposes. For the constant ptime multiple channel case described in Section 4.2.2, including "ptime" can provide a useful payload check 🔍.

Encoding considerations: this media type is framed binary data (see Section 4.8 in RFC 6838 [RFC6838]) compressed as per ITU-T Rec. G.711.0 📦.

Security considerations: see Section 8 🔐.

Interoperability considerations: none ✅

Published specification: ITU-T Rec. G.711.0 and RFC 7655 (this document) 📚.

Applications that use this media type: even though G.711.0 was first imagined for VoIP, it may find use in audio and video streaming and/or conferencing apps, for the audio portion of those apps, just like G.711 did before it 🎶.

Additional information: the following applies to stored-file transfer methods 🗂️.

  • Magic numbers: #!G7110A\n or #!G7110M\n (for A-law or MU-law encodings respectively, see Section 6).
  • File Extensions: None
  • Macintosh file type code: None
  • Object identifier or OIL: None

Person & email address to contact for further information: Michael A. Ramalho <mramalho@cisco.com> or <mar42@cornell.edu> 📧

Intended usage: COMMON

Restrictions on usage: this media type depends on RTP framing, so it's only defined for transfer via RTP [RFC3550]. Transport within other framing protocols is not defined at this time 🚧.

Author: Michael A. Ramalho

Change controller: IETF Payload working group delegated from the IESG 🤝.

5.2. Mapping to SDP Parameters

The info in the media type specification maps to specific fields in SDP, which is commonly used to describe an RTP session 🗺️. When SDP is used to specify sessions that employ G.711.0, the mapping goes like this:

  • The media type (audio) goes in SDP m= as the media name.
  • The media subtype (G711-0) goes in SDP a=rtpmap as the encoding name.
  • The required parameter rate also goes in a=rtpmap as the clock rate.
  • The parameters ptime and maxptime go in the SDP a=ptime and a=maxptime attributes, respectively.
  • The remaining parameters go in the SDP a=fmtp attribute, copied directly from the media type string as a semicolon-separated list of parameter=value pairs.

5.3. Offer/Answer Considerations

These considerations apply when you use the SDP offer/answer mechanism [RFC3264] to negotiate the "channels" attribute 🤝.

  • If the offering endpoint specifies a value for the optional channels parameter that is greater than one, and the answering endpoint both understands the parameter and cannot support that requested value, the answer MUST contain the optional channels parameter with the highest value it can support.
  • If the offering endpoint specifies a value for the optional channels parameter, the answer MUST contain the optional channels parameter unless the only value the answering endpoint can support is one. In that case, the answer MAY contain the optional channels parameter with a value of 1.
  • If the offering endpoint specifies a value for the ptime parameter that the answering endpoint cannot support, the answer MUST contain the optional ptime parameter.
  • If the offering endpoint specifies a value for the maxptime parameter that the answering endpoint cannot support, the answer MUST contain the optional maxptime parameter.

5.4. SDP Examples

Let's see how to signal G.711.0 via SDP 👀✨

5.4.1. SDP Example 1 ✨

m=audio RTP/AVP 98
a=rtpmap:98 G711-0/8000
a=fmtp:98 complaw=mu

okay so in this one, dynamic payload type 98 gets mapped to G.711.0 through the a=rtpmap line 💖 The "complaw" parameter is mandatory, so it shows up on the a=fmtp line 🎀 Neither ptime nor channels is here, since they're both optional 🦋 Still, it's generally good form to include ptime in your SDP if the session has a constant ptime, because it helps with diagnostics 🫶

5.4.2. SDP Example 2 💅

this one is giving a whole negotiation moment 😭 The offering endpoint wants 2 channels, but the answering endpoint can only support (or render) one channel 🙈

Offer:

m=audio RTP/AVP 98
a=rtpmap:98 G711-0/8000/2
a=ptime:20
a=fmtp:98 complaw=al

Answer:

m=audio RTP/AVP 98
a=rtpmap: 98 G711-0/8000/1
a=ptime: 20
a=fmtp:98 complaw=al

So the offer included the optional channels parameter 👑 The answer must have the optional channels parameter too, unless its value is one. Here the answer includes the channels parameter explicitly, even though it doesn't have to, and if it's left out it would be read as one channel 🌸 And again, ptime is a good idea to include for session diagnostics if the session is constant ptime 💜

6. G.711.0 Storage Mode Conventions and Definition 🧚

The G.711.0 storage mode definition in this section is pretty similar to a bunch of other IETF codecs, like iLBC [RFC3951] and EVRC-NW [RFC6884] 🌈 Basically, it's just a concatenation of individual G.711.0 frames, so iconic and simple 💖

We need to note that something has to be stored for any G.711.0 frames that the receiving endpoint doesn't get, no matter what caused it 😭 This section covers two mechanisms: a "G.711.0 PLC Frame" and a "G.711.0 Erasure Frame" ✨ They're explained before the storage mode definition, just so everything is clear and not confusing 🎀

6.1. G.711.0 PLC Frame 🦋

When G.711 RTP payloads don't arrive at a rendering endpoint, a PLC mechanism usually steps in to "fill in" the missing G.711 symbols with something that sounds good to the ear 🎧 That way, the listener might not even notice the gap 🙈 The PLC mechanism for G.711 is specified in ITU-T Rec. G.711 - Appendix 1 [G.711-AP1] 💅

Now here's the natural next step. When you're creating G.711.0 frames for storage, you can use that same PLC mechanism to generate G.711 symbols for the stretch of time where G.711.0 payloads never showed up 🔥 Then you compress those "G.711 PLC symbols" with G.711.0 compression 🧚 The G.711.0 frames made this way are called "G.711.0 PLC Frames" 🌸

PLC mechanisms are built to render missing audio with the best fidelity and intelligibility, so G.711.0 frames made this way are likely the best choice for most recording situations, like voicemail storage 💖 The exception is when there's a requirement not to fabricate (audio) data that was never actually received 🫶

Once the PLC G.711 symbols have been generated and encoded by a G.711.0 encoder, the resulting frames can be stored in G.711.0 frame format ✨ So there's nothing new to specify here: the G.711.0 PLC frames are stored as if the receiving endpoint had actually received them 💜 In other words, PLC-generated G.711.0 frames look like "normal" or "ordinary" G.711.0 frames in the storage mode file 🦋

6.2. G.711.0 Erasure Frame 🌈

"Erasure Frames", also known as "Null Frames", have been designed for lots of frame-based codecs since G.711 came out 👑 These null/erasure frames explicitly represent audio data that either didn't get received by the receiving system, or that a transmitting system decided not to send in the first place 😭 Transmitting systems have all kinds of reasons not to send data (like not enough wireless link capacity in radio-based systems), so they can send a "null frame" instead of the actual audio 🙈 Erasure frames are also expected to be used in storage mode applications for specific archival purposes, where there's a requirement not to fabricate audio data that was never actually received 💅

So a G.711.0 erasure frame is basically a representation of how much time in G.711.0 frames was not received or not encoded by the transmitting system 🧚

Before we define it, it helps to know what a lot of G.711 RTP systems send when the endpoint is "muted" 🔇 Many of them send an entire G.711 payload of either 0+ or 0- (one of the two levels closest to "analog zero" in either G.711 companding law) 🌸 Next, a desirable property for a G.711.0 erasure frame is that "non-G.711.0 Erasure Frame-aware" endpoints can still play it back with the existing G.711.0 ITU-T reference code 💖

A G.711.0 Erasure Frame is any G.711.0 frame where the corresponding G.711 sample values are either 0++ or 0-- for the entire frame 🫶 The levels 0++ and 0-- are defined as the two levels above or below analog zero, respectively ✨ An entire frame of 0++ or 0-- is expected to be extremely rare when the frame was actually generated from a natural signal, because analog inputs like speech and music are zero-mean and are typically acoustically coupled to digital sampling systems 💜 Playing back a G.711.0 frame marked as an erasure frame sounds auditorially equivalent to a muted signal (a very low value constant) 🎀

These G.711.0 erasure frames can reasonably be characterized as null or erasure frames while still meeting the goal of being decoded by the G.711.0 ITU-T reference code 🦋 So, just like G.711 PLC frames, G.711.0 erasure frames look like "normal" or "ordinary" G.711.0 frames in the storage mode format 👑

6.3. G.711.0 Storage Mode Definition 🌸

The storage format is used for storing G.711.0 encoded frames 💖 Here's the format for the G.711.0 storage mode file defined by this RFC:

          |---------------------------|----------|--------------|
          |       Magic Number        |          |              |
          |                           |  Version | Concatenated |
          | "#!G7110A\n" (for A-law)  |   Octet  |   G.711.0    |
          |            or             |          |    Frames    |
          | "#!G7110M\n" (for mu-law) |  "0x00"  |              |
          |___________________________|__________|______________|

Figure 5: G.711.0 Storage Mode Format ✨

The storage mode file is made up of a magic number and a version octet, followed by the individual G.711.0 frames concatenated together 🧚

The magic number for G.711.0 A-law is the ASCII character string "#!G7110A\n", i.e., "0x23 0x21 0x47 0x37 0x31 0x31 0x30 0x41 0x0A" 🎀 The magic number for G.711.0 MU-law is the ASCII character string "#!G7110M\n", i.e., "0x23 0x21 0x47 0x37 0x31 0x31 0x4E 0x4D 0x0A" 💜

The version number octet leaves room for future G.711.0 storage mode formats 🦋 Other storage mode formats might be desirable because G.711.0 frames are variable in length 🌈 A future format might include an indexing method, so you could jump far into a long G.711.0 recording without decoding every frame from the very beginning 👑 Other future formats could add support for multiple channels, metadata, and things like that 💅 For all these reasons, a versioning strategy was considered desirable for the G.711.0 storage mode definition in this RFC 🫶 This RFC only specifies Version 0, so the value "0x00" MUST be used for the storage mode defined by this RFC 🔥

The G.711.0 codec data frames, including any necessary erasure or PLC frames, are stored in consecutive order, concatenated together as shown in Section 4.2.2 🌸 Since Version 0 storage mode only supports a single channel, the RTP payload format supporting multiple channels defined in Section 4.2.4 is not supported in this storage mode definition 😭

To decode the individual G.711.0 frames, the algorithm presented in Section 4.2.2 may be used 🧚 If the version octet is determined not to be zero, the remainder of the payload MUST NOT be passed to the G.711.0 decoder 💀 That's because the ITU-T G.711.0 reference decoder can only decode concatenated G.711.0 frames, and it hasn't been designed to decode elements in future storage mode formats that haven't been specified yet 🙈

7. IANA Considerations 🦋

One media type (audio/G711-0) has been defined and registered in IANA's "Media Types" registry 💖 See Section 5.1 for details 🎀

8. Security Considerations ✨

okay bestie, security is where things get SERIOUS 🔒💅 RTP packets using this payload format are subject to the security considerations in the RTP specification [RFC3550] and any applicable RTP profile, like RTP/AVP [RFC3551], RTP/AVPF [RFC4585], RTP/SAVP [RFC3711], or RTP/SAVPF [RFC5124]. ngl, that's a whole list of stuff to read 📚 But here's the tea: as "Securing the RTP Protocol Framework: Why RTP Does Not Mandate a Single Media Security Solution" [RFC7202] explains, the payload format itself is NOT the one deciding how to get confidentiality, integrity, and source authenticity for RTP in general 🙅‍♀️ That job belongs to whoever is building the app that uses RTP. They can check out "Options for Securing RTP Sessions" [RFC7201] for guidance on security mechanisms and things to keep in mind 🧠

Applications SHOULD use one or more appropriate strong security mechanisms. 🔐 This is literally non-negotiable energy, the way that security is a must-have, not a nice-to-have 💖 The rest of this section is about the security-related properties of the payload format itself 🎀

Because the data compression used with this payload format is applied end-to-end, any encryption needs to be performed after compression. 🗜️➡️🔒 Compress first, THEN encrypt, always. Don't flip it, bestie 🙈

Note that end-to-end security with authentication, integrity, or confidentiality protection will stop a network element outside the security context from doing media-aware operations, other than discarding complete packets 🚧 So if an intermediate network element is supposed to do its thing, it is REQUIRED to be a trusted entity that's included in the security context establishment 🫶 No trust, no media-aware magic ✨

G.711.0 has no known denial-of-service (DoS) attacks due to decoding 🎉 Data pretending to be a legit G.711.0 payload still gets decoded into something, and that takes a finite amount of computation, since the decompression algorithm has a finite worst-case processing path. No infinite loops, no drama 🔁❌ We also want to point out that the data the G.711.0 decoder reads is controlled by the length of the individual encoded G.711.0 frame(s) in the RTP payload. The decoding algorithm from Section 4.2.3 makes sure the decoder won't read past the length of the internal buffer, which is capped at the largest possible G.711.0 frame of 321 octets 📏 So a G.711.0 payload does NOT carry "active content" that could cause malicious side effects on the receiver. Safe and sound 🦋

G.711.0 is a VBR audio codec 🎶 Recently there have been concerns about VBR speech codecs, where a passive observer can figure out phrases from a standard speech corpus just by looking at the encoded lengths, even when the payload is encrypted [IEEE]. 👀 That paper found that some Code-Excited Linear Prediction (CELP) codecs produce discrete packet lengths for some phonemes. With well-designed Hidden Markov Models (HMMs), a system could predict phrases with unexpected accuracy 😱 One CELP codec they studied, SPEEX, produced 21 different packet lengths in its wideband mode, and those lengths probabilistically mapped to phonemes an HMM system could be trained on 💀

The paper's suggested mitigation was to pad the encoder output with random padding lengths, so that 1) more discrete payload sizes result, and 2) the probabilistic mapping to phonemes becomes less clear 🌀 As G.711 is not a speech-model-based codec, neither is G.711.0 🌸 During talking periods, a G.711.0 encoding produces frames of varying lengths that are not likely to have a strong mapping to phonemes. So G.711.0 is not expected to have this same vulnerability 🙌

Now, "silence" (only one value of G.711 in the entire G.711 input frame) or "near silence" (only a few G.711 values) is easily detectable from G.711.0 frame lengths of one or a few octets 🤏 If you want to mitigate silence/non-silence detection, statistically variable padding SHOULD be added to G.711.0 frames that came out very small (less than about 20% of the symbols of the corresponding G.711 input frame) 🎯 Methods for adding padding to G.711.0 payloads are provided in the G.711.0 RTP payload definition in Section 4.2.2 💖

9. Congestion Control 🚦

okay so the G.711 codec is a Constant Bit Rate (CBR) codec, and it has no way to regulate its bitrate 🙃 The G.711.0 lossless compression algorithm usually squishes the G.711 CBR stream into a lower-bandwidth VBR stream 🪄 BUT since it's lossless, it can't reduce the bitrate any further than what G.711.0 compression already gives 😤 The G.711.0 RTP payloads can also be made arbitrarily large by adding optional padding bytes, though only up to MTU limits 📦

So, bestie, there are NO explicit ways to regulate the bit rate of transmissions in this RTP payload format, except by changing the number of optional padding bytes in the RTP payload 🎀 That's the only lever 🔧

10. References 📚

10.1. Normative References 🎀

10.2. Informative References 💜

  • [G.722]: ITU-T, "7 kHz audio-coding within 64 kbit/s", ITU-T Recommendation G.722, 1988.
  • [G.729]: ITU-T, "Coding of speech at 8 kbit/s using conjugate-structure algebraic-code-excited linear prediction (CS-ACELP)", ITU-T Recommendation G.729, 2007.
  • [ICASSP]: Harada, N., Yamamoto, Y., Moriya, T., Hiwasaki, Y., Ramalho, M., Netsch, L., Stachurski, J., Miao, L., Taddei, H., and F. Qi, "Emerging ITU-T Standard G.711.0 - Lossless Compression of G.711 Pulse Code Modulation, International Conference on Acoustics Speech and Signal Processing (ICASSP), 2010, ISBN 978-1-4244-4244-4295-9", March 2010.
  • [IEEE]: Wright, C., Ballard, L., Coull, S., Monrose, F., and G. Masson, "Spot Me if You Can: Uncovering Spoken Phrases in Encrypted VoIP Conversations, IEEE Symposium on Security and Privacy, 2008, ISBN: 978-0-7695-3168-7", May 2008.

Acknowledgements 🫶

There have been so many people contributing to G.711.0 during its development 🌈 The people listed here deserve special mention: Takehiro Moriya, Claude Lamblin, Herve Taddei, Simao Campos, Yusuke Hiwasaki, Jacek Stachurski, Lorin Netsch, Paul Coverdale, Patrick Luthi, Paul Barrett, Jari Hagqvist, Pengjun (Jeff) Huang, John Gibbs, Yutaka Kamamoto, and Csaba Kos 👑 Thank you to IETF Payload working group chairs Ali Begen and Roni Even for their review and oversight while this RFC was developed 🦋 Richard Barnes did a careful review, David Black did an extensive review, and the IESG reviews are also very much appreciated 💅

Contributors 🌸

The authors thank everyone who contributed to this document 💖 The people listed here deserve special mention: Ali Begen, Roni Even, and Hadriel Kaplan ✨

Authors' Addresses ✨

okay so this is where we meet the squad 🫶 the people who wrote this spec and kept it all together. here's where you can find each of them, verbatim, bestie 💅

Michael A. Ramalho is the editor, and he's giving very organised main character energy 👑

Michael A. Ramalho (editor)
Cisco Systems, Inc.
6310 Watercrest Way Unit 203
Lakewood Ranch, FL  34202
United States
Phone: +1 919 476 2038
Email: mramalho@cisco.com

next up is Paul E. Jones, also from Cisco, with his own address in Research Triangle Park 🎀

Paul E. Jones
Cisco Systems, Inc.
7025 Kit Creek Road
Research Triangle Park, NC  27709
United States

Phone: +1 919 476 2048
Email: paulej@packetizer.com

then we've got Noboru Harada over at NTT Communications Science Labs in Japan 🌸

Noboru Harada
NTT Communications Science Labs
3-1 Morinosato-Wakamiya
Atsugi, Kanagawa  243-0198
Japan

Phone: +81 46 240 3676
Email: harada.noboru@lab.ntt.co.jp

Muthu Arul Mozhi Perumal is from Ericsson in Bangalore, India, and he's definitely a whole mood 🦋

Muthu Arul Mozhi Perumal
Ericsson
Ferns Icon
Doddanekundi, Mahadevapura
Bangalore, Karnataka  560037
India

Phone: +91 9449288768
Email: muthu.arul@gmail.com

and last but absolutely not least, Lei Miao at Huawei Technologies Co. Ltd in Beijing, China 🧚✨

Lei Miao
Huawei Technologies Co. Ltd
Q22-2-A15R, Environment Protection Park
No. 156 Beiqing Road
HaiDian District
Beijing  100095
China

Phone: +86 1059728300
Email: lei.miao@huawei.com

that's the whole crew, bestie 🌈💜 five brilliant minds who made this happen, and you can always reach out to them if you're obsessed with the spec 🥹

📦 where this page comes from