RTP Payload Format for G.711.0
Extracted elements (29)
Because G.711.0 is both lossless and stateless, it can be applied transparently multiple times on individual hops between G.711 endpoints; multiple lossless transcodes do not degrade voice quality, unlike lossy codec transcodes.
G.711.0 frames are self-describing: the Prefix Code octet encodes the number of source G.711 symbols, so a decoder does not need external signaling (such as SDP ptime) to decompress a frame. This enables transparent in-path compression between G.711 endpoints.
G.711.0 was designed to be stateless (compression of a frame depends only on that frame, not on prior frames) to completely eliminate error propagation. A lost G.711.0 packet has the same effect as a lost G.711 packet, allowing existing G.711 PLC mechanisms to be reused directly.
G.711.0 was designed with bounded expansion: an uncompressible G.711 payload of X octets expands to at most X+1 octets, ensuring that worst-case overhead is one octet. This makes G.711.0 safe to deploy even over modem/FAX channels that resist compression.
Converting a G.711 RTP packet to G.711.0 requires only compressing the payload, changing the PT to the negotiated dynamic value, and copying all other RTP header fields unchanged; the reverse restores the original G.711 packet bit-for-bit, enabling invisible in-path compression.
The 'complaw' format-specific SDP parameter (required, values 'al' or 'mu') MUST be conveyed to communicate the G.711 companding law (A-law or mu-law) used, because G.711.0 encoding and decoding require knowledge of the companding law.
All G.711.0 RTP decoders MUST support the general case of one or more G.711.0 frames per RTP payload; no SDP or other negotiation is required to signal this capability.
Applications using G.711.0 SHOULD use one or more appropriate strong security mechanisms, per RFC 7201 guidance on securing RTP sessions.
For the G.711.0 storage mode defined in this RFC, the version octet MUST be set to 0x00. If the version octet is non-zero, the remainder of the payload MUST NOT be passed to the G.711.0 decoder.
If ptime is signaled via SDP and the number of G.711 symbols decoded from the RTP payload does not match ptime, the packet MUST be discarded unless system design knowledge (e.g., 5 ms clock slips) allows otherwise.
If VAD is employed with G.711.0, the Marker bit (M) MUST be set in the first packet of a talkspurt (the first packet after a silence period), consistent with G.711 RTP VAD rules in RFC 3551.
In a multichannel G.711.0 RTP payload, the underlying G.711 data for all channels MUST span the same time interval. If the total decoded G.711 symbols (M) is not an integer multiple of the number of channels (N), the packet SHOULD be discarded.
In SDP offer/answer negotiation, if the offerer specifies a 'channels' value greater than one and the answerer cannot support it, the answer MUST contain the 'channels' parameter set to the highest value it can support.
The 'channels' parameter MUST be present in SDP if the number of channels is greater than one; it defaults to 1 if absent.
The G.711 input frame to a G.711.0 encoder MUST be 40, 80, 160, 240, or 320 octets (corresponding to 5, 10, 20, 30, or 40 ms at 8000 samples/second).
The RTP payload type (PT) field MUST have a value corresponding to the dynamic payload type assigned to the G.711.0 flow. The existing G.711 PT values of 0 (PCMU) and 8 (PCMA) MUST NOT be used for G.711.0, except in rare PT exhaustion cases.
The total time represented by all G.711.0 frames in an RTP payload MUST correspond to the ptime signaled via SDP when SDP is used.
Voice Activity Detection (VAD) SHOULD NOT be used when G.711.0 is negotiated, because G.711.0 already achieves high compression during silence intervals and avoids VAD-induced artifacts.
A G.711.0 Erasure Frame is defined as any G.711.0 frame whose corresponding G.711 sample values are entirely the level 0++ or 0-- (one step above or below analog zero); it is used in storage mode to represent time spans that were not received or not transmitted.
A G.711.0 PLC Frame is a G.711.0-compressed version of G.711 symbols produced by a Packet Loss Concealment (PLC) algorithm to fill time spans with no received data; it is stored as a normal G.711.0 frame in storage mode.
The G.711.0 Prefix Code octet is the first octet of every G.711.0 frame. It conveys how many G.711 symbols (0, 40, 80, 160, 240, or 320) the decoder must produce; the value 0x00 denotes zero symbols and also serves as the RTP payload padding sentinel.
This document registers the media type audio/G711-0 in the IANA 'Media Types' registry. Required parameters: clock rate and complaw (values 'al' or 'mu'). Optional parameters: channels, ptime, maxptime. Magic numbers for storage files: '#!G7110A\n' (A-law) and '#!G7110M\n' (mu-law).
Because G.711.0 compression is applied end-to-end, any encryption must be performed after compression. End-to-end security prevents intermediate network elements from performing media-aware operations unless they are included in the security context.
G.711.0 has no known denial-of-service vulnerability from decoding: the decompression algorithm has a finite worst-case path (no infinite loops), and internal buffer reads are bounded to at most 321 octets per decode request, preventing buffer overruns from malformed payloads.
G.711.0 is a VBR codec; very short G.711.0 frames reveal silence or near-silence conditions even when the payload is encrypted. The RFC recommends adding statistically variable 0x00 padding to G.711.0 frames that compress to less than about 20% of the original G.711 frame size to mitigate silence/non-silence traffic analysis.
The RTP payload decoding heuristic (H1–H5) processes the payload iteratively: initialize counters (H1); read up to 321 octets into the internal buffer (H2); if the first octet is 0x00, skip it as padding (H3–H4); otherwise decode the G.711.0 frame and advance the processed-octet pointer (H5); STOP when all payload octets are consumed.
For multichannel payloads, each G.711 channel is independently encoded as a 'G.711.0 channel superframe' (one or more G.711.0 frames); superframes are concatenated in channel order, optionally followed by 0x00 padding octets.
The G.711.0 RTP payload consists of one or more concatenated G.711.0 frames followed by zero or more 0x00 padding octets. Each G.711.0 frame is self-describing; its first 'Prefix Code' octet encodes the count of source G.711 symbols (0, 40, 80, 160, 240, or 320).
The G.711.0 storage mode file format is: magic number (9 bytes: '#!G7110A\n' for A-law or '#!G7110M\n' for mu-law), followed by one version octet (0x00 for Version 0), followed by concatenated G.711.0 frames.