A Real-time Transport Protocol (RTP) Header Extension for Mixer-to-Client Audio Level Indication
Extracted elements (18)
Audio levels are defined identically to the noise level byte in the RTP Payload Comfort Noise specification (RFC 3389), reusing a well-established encoding. The level is measured as a root mean square of all samples in the measured range with no long-term averaging or smoothing.
dBov is chosen as the reference because representation relative to the overload point of a system is particularly useful for digital implementations — one does not need to know the relative calibration of the analog circuitry.
In multi-mixer conferences, each mixer MAY relay CSRC lists and audio level information from peer mixers (provided total CSRC count stays below 16), but average audio levels may be perceptibly different across mixer boundaries since this specification does not precisely define maximum audio level normalization.
This header extension is complementary to RFC 6464 (client-to-mixer audio level indication). RFC 6464 carries levels from clients to mixers; this document (RFC 6465) carries levels from mixers back to clients.
A mixer SHOULD include in a packet information that corresponds to the audio data being transported in that same packet, and SHOULD calculate values after the contributing stream has undergone processing such as level normalization and noise reduction.
Implementations MUST NOT include more than 15 audio level values, matching RTP's maximum of 15 CSRC IDs. The maximum len field value is therefore 14 for the one-byte header format and 15 for the two-byte header format.
The audio level extension MUST NOT be advertised with non-audio media types such as video or text.
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 number and order of audio level values MUST match the number and order of the CSRC IDs present in the same packet.
Clients with no mixing capabilities MUST use direction parameter 'recvonly' in the extmap attribute. Conference focus entities with mixing capabilities may omit direction or use 'sendrecv' in SDP offers, and MUST use 'sendonly' in answers to 'recvonly' offers.
The RTP header extension carries a list of one-octet audio levels expressed in -dBov, with one level value per CSRC ID present in the packet. Each value corresponds to the CSRC identifier at the same position in the CSRC list.
The SDP URI for declaring the audio level header extension is 'urn:ietf:params:rtp-hdrext:csrc-audio-level', declared via the SDP extmap attribute. No additional setup information or extension attributes are needed.
This document registers a new extension URI 'urn:ietf:params:rtp-hdrext:csrc-audio-level' in the RTP Compact Header Extensions subregistry of the RTP Parameters registry, described as 'Mixer-to-client audio level indicators'.
An attacker may modify RTP packet contents to make audio activity from one participant appear to come from another, enabling identity spoofing within a conference.
Audio level values are not protected even in an SRTP session, potentially revealing participant activity confidentiality. An attacker may also infer conversation content, possibly with phoneme-level resolution, as discussed in SRTP-VBR-AUDIO.
Implementors and deployers should consider header extension encryption (SRTP-ENCR-HDR) or lower-level mechanisms such as IPsec to mitigate audio level exposure, depending on the confidentiality requirements of the scenario.
Each audio level value is encoded as a single byte: the most significant bit is unused and always set to 0, and the seven least significant bits carry the audio level magnitude in -dBov (0–127 representing 0 to -127 dBov).
Using the one-byte header format (RFC 5285), the 4-bit len field is the number minus one of audio level bytes following the header, so len=2 means three levels. Using the two-byte header format, the 8-bit len field contains the exact number of audio levels.