A Real-time Transport Protocol (RTP) Header Extension for Client-to-Mixer Audio Level Indication
Extracted elements (20)
Audio level is expressed in -dBov (relative to the overload point of the system) rather than an absolute level because digital implementations do not need to know the relative calibration of the analog circuitry. This makes the representation self-contained and codec-independent.
Mixers and forwarders ought not base forwarding decisions directly on per-packet audio levels; instead they should apply smoothing (e.g., low-pass filtering) to avoid false positives from transient sounds such as coughs, while balancing this against clipping the beginning of speech. Automatic gain control may also help normalize per-participant input levels.
The audio level parameter is defined identically to the comfort noise payload noise-level byte in RFC 3389, enabling consistent interpretation across RTP audio mechanisms that carry noise or signal levels.
The vad attribute controls only the semantics of the V bit in this header extension and makes no statement about whether the sender uses any other VAD features (such as discontinuous transmission, comfort noise, or silence suppression), keeping the two concerns decoupled.
This extension is complementary to RFC 6465, which defines a mixer-to-client direction header extension allowing audio mixers to indicate to clients the levels of contributing sources. The two extensions serve opposite directions of the same use case.
When used with RTP Payload for Redundant Audio Data (RFC 2198), the header extension's audio level data describes the contents of the primary encoding only, not any redundant encodings.
An endpoint MAY signal multiple instances of the header extension element with different values of the vad attribute, provided each instance uses a different extension identifier value.
If the header extension element is signaled with 'vad=off', the V bit MUST be ignored by receivers.
If the V bit is not in use (i.e., vad=off is signaled), its value is unspecified and MUST be ignored by receivers.
The audio level for digital silence (e.g., a muted audio source) MUST be represented as 127 (-127 dBov), regardless of the dynamic range of the encoded audio format.
The semantics chosen for a header extension element, including its vad setting, for a particular extension identifier value MUST NOT be changed within an RTP session.
The audio level carried in the extension reflects the RMS of all samples in the audio encoded by the packet, with no long-term averaging or smoothing. For payloads with error-correction bits, the level corresponds only to the data produced by normal decoding, not error concealment.
The audio level magnitude is packed into the 7 least significant bits of the extension byte, expressed in -dBov. Values 0 to 127 represent 0 to -127 dBov, where dBov is the level relative to the overload point of the system (the highest-intensity encodable signal).
The most significant bit of the extension byte is the V flag, indicating whether the encoder believes the audio packet contains voice activity. Value 1 means voice activity detected; value 0 means none. The voice activity detection algorithm is unspecified and implementation-specific.
The SDP extension URI for declaring this header extension is 'urn:ietf:params:rtp-hdrext:ssrc-audio-level'. It has a single extension attribute 'vad' taking values 'vad=on' or 'vad=off', controlling whether the V bit is in use. The default when vad is not specified is 'vad=on'.
This document registers the extension URI 'urn:ietf:params:rtp-hdrext:ssrc-audio-level' with description 'Audio Level' in the RTP Compact Header Extensions subregistry of the Real-Time Transport Protocol (RTP) Parameters registry.
A malicious endpoint could falsely inflate reported audio levels to dominate speaker-selection algorithms or send silence to suppress other participants. If a device relies on audio level data from untrusted endpoints, it SHOULD periodically audit the transmitted level information and take corrective action against endpoints sending incorrect data.
In SRTP, RTP header extensions are authenticated but not encrypted. The audio level extension therefore exposes per-packet audio levels to passive observers, who may be able to infer conversation content with phoneme-level resolution. In scenarios where this is a concern, additional mechanisms MUST be used to protect header extension confidentiality, such as header extension encryption or IPsec.
One-byte header format encodes the audio level extension as: 4-bit ID, 4-bit length field (value 0 meaning 1 byte follows), 1-bit V flag, and 7-bit audio level magnitude, totaling 2 bytes.
Two-byte header format encodes the audio level extension as: 8-bit ID, 8-bit length field (value 1), 1-bit V flag, 7-bit audio level, and 8-bit padding byte, totaling 4 bytes.