RTP Payload Format for the Speex Codec
Extracted elements (22)
Bit-rate changes are signaled in-band within the Speex bit stream at any 20 msec frame boundary. Each frame contains both sampling rate and mode (bit-rate) information, so no out-of-band notification is required for the decoder to process bit-rate changes.
The ptime SDP attribute denotes the packetization interval. Since Speex uses 20 msec frames, ptime values should be multiples of 20. Non-multiple values should be rounded up to the nearest multiple of 20 before calculating the number of frames per packet.
The Speex parameters in an SDP Offer/Answer exchange are completely orthogonal — there is no relationship between the SDP Offer and the Answer. Multiple Speex parameters may appear on a single a=fmtp line separated by semicolons.
An application MUST be able to decode any Speex frame unless the SDP clearly specifies that some modes are not supported (e.g., by not including 'mode="any"'). Indicating support for a set of decoding modes also implies support for the same encoding modes.
An RTP packet MAY contain Speex frames of the same or varying bit-rates, since bit-rate is conveyed in-band. Frames must be placed starting with the oldest frame and continue consecutively in time.
Implementations MUST support at least narrowband (8 kHz) encoding and decoding at 8 kbit/s (narrowband mode 3). Support for narrowband at 15 kbit/s (mode 5) is RECOMMENDED, and wideband at 27.8 kbit/s (mode 8) is also RECOMMENDED.
Speex frames MUST NOT be fragmented across multiple RTP packets. The total number of Speex frames SHOULD be kept less than the path MTU to prevent fragmentation.
The 'mode' and 'ptime' values proposed in SDP contents MUST NOT be used for decoding: those values are not needed to properly decode an RTP Speex stream, as each Speex frame contains all needed information to decode itself.
The 'mode' parameter value MUST always be quoted. If not provided, the default is equivalent to 'mode="3,any"' for narrowband and 'mode="8,any"' for wideband and ultra-wideband.
The RTP payload MUST be padded to provide an integer number of octets. Padding bits are LSB-aligned in network octet order and consist of a 0 followed by all ones (until end of octet), and are only required for the last frame.
The sampling rate MUST be 8, 16, or 32 kHz. This specification defines only single channel audio (mono).
When the remote party SHOULD configure its encoder using the first supported mode from the 'mode' list. If an offer specifies only specific modes without 'any', the remote party MUST NOT configure its encoder using another Speex mode.
The 'cng' parameter controls comfort noise generation: 'off' (default, silence frames are silent) or 'on' (silence frames filled with comfort noise). This is a preference to the encoder.
The 'mode' parameter is a comma-separated list of supported Speex decoding modes in order of preference. Valid modes are {1–8, any} for narrowband and {0–10, any} for wideband/ultra-wideband. The first listed mode is most preferred.
The RTP Marker (M) bit is set to one on the first packet sent after a silence period during which packets have not been transmitted contiguously. The Timestamp is a 32-bit word corresponding to the sampling instant for the first frame in the RTP packet.
The 'vbr' parameter controls variable bit-rate: values are 'on' (VBR enabled), 'off' (disabled, default), or 'vad' (constant bit-rate with special short silence frames). This is a preference to the encoder.
This document registers the audio/speex media type. Required parameter: 'rate' (RTP timestamp clock rate equal to sampling rate; must be 8000, 16000, or 32000 Hz). Optional parameters: ptime, maxptime, vbr, cng, and mode.
A potential DoS threat exists where an attacker injects pathological datagrams that are complex to decode, overloading the receiver. The document notes that Speex does not exhibit significant non-uniformity in computational load, mitigating this risk.
A receiver may be overloaded by receipt of too many packets from undesired sources. Network-layer authentication may be used to discard such packets, though the processing cost of authentication itself may be too high.
Confidentiality of Speex RTP streams is achieved by encryption. Since compression is applied end-to-end, encryption may be performed after compression with no conflict between the two operations.
Padding for the last Speex frame is LSB-aligned in network octet order and consists of a 0 bit followed by all ones until the end of the octet, ensuring the packet contents end on an octet boundary.
The RTP payload for Speex consists of the standard RTP header followed by one or more Speex payload data blocks, with an optional padding terminator. No additional header fields specific to this payload format are required.