RTP Payload for Redundant Audio Data
updated by
- rfc-6354 — Forward-Shifted RTP Redundancy Payload Support
Extracted elements (20)
Assigning a distinct dynamic payload type per primary/secondary combination was rejected because supporting multiple blocks of redundancy causes a combinatorial explosion that makes the approach unviable.
The block length field is 10 bits (not the 'obvious' 8 bits) because an 8-bit field cannot encode lengths above 255 bytes, which is insufficient for encodings such as 80ms PCM or DVI. The 10-bit/14-bit split balances block-length range against timestamp-offset range.
The primary encoding block header is placed last in the packet so its timestamp and length fields can be omitted, since both are derivable from the RTP header and overall packet length, saving bytes.
The timestamp offset is unsigned (14 bits), which means redundant data must always be sent after the primary and the offset is subtracted from the current timestamp to recover the redundant block's timestamp. Adding a sign bit would unacceptably halve the offset range.
There is no padding or delimiter between data blocks; they are not 32-bit aligned. This choice reduces bandwidth overhead at the expense of additional decoding complexity.
Using a single fixed payload type ('red') as a container for multiple encodings was chosen over a header extension approach or per-combination dynamic payload types because it is flexible, extensible, and has relatively low overhead. Header extension was rejected due to 4-byte overhead, potential 3-byte padding, and a limit of one redundant encoding.
CSRC information in the RTP header of a redundant packet relates to the primary only; CSRC is not preserved per redundant block. Since CSRC is expected to change infrequently, applications may apply the header CSRC to reconstructed redundant data.
The RTP marker bit is not preserved for redundant data blocks. If the primary packet carrying the marker is lost, that marker is lost; applications must be designed to tolerate this.
Applications that require CSRC information from redundant data are RECOMMENDED to assume the CSRC data in the RTP header applies to the reconstructed redundant data, since CSRC is not preserved per-block.
If multiple redundant encodings are carried in a packet, they should correspond to different time intervals; there is no reason to include multiple copies of data for a single time interval within a packet.
The redundant encoding MUST be sampled at the same rate as the primary encoding, because the timestamp offset is measured in the same units as the primary timestamp.
The redundant encoding MUST NOT be higher bandwidth than the primary encoding.
When the primary is very low-bandwidth and has high processing requirements, a copy of the primary MAY be used as the redundancy.
A redundant audio RTP packet comprises a standard RTP header (with payload type indicating redundancy), followed by one or more block headers describing each encoding, followed by the data blocks in the same order. All block headers are 32-bit aligned; data blocks are typically not aligned.
SDP binds the redundancy payload type using 'rtpmap' with codec name 'red' (e.g., 'a=rtpmap:121 red/8000/1'). Additional payload types listed on the 'm=' line indicate the set of codecs that may appear in the redundant encodings.
The SDP 'fmtp' attribute for the 'red' payload type carries a slash-separated list of RTP payload types specifying the recommended encoding order for primary and secondary (and tertiary, etc.) encodings (e.g., 'a=fmtp:121 0/5'). Only codecs listed on the 'm=' line may appear in fmtp.
Adding large amounts of redundancy increases network congestion and therefore packet loss, worsening the very problem redundancy was meant to solve; at its worst this can constitute a denial-of-service attack. Application designers should keep redundancy bandwidth low.
When a portion of a redundant stream must be encrypted with a different key, a redundant copy of the last packet of that portion cannot be sent, because no subsequent packet encrypted with the correct key exists to carry it. Similar constraints arise when enabling or disabling encryption mid-stream.
Each non-final block header is 32 bits: F (1 bit, 1=more headers follow), block PT (7 bits), timestamp offset (14 bits, unsigned, relative to primary), and block length (10 bits, in bytes, excluding header).
The primary (final) block header is 8 bits only: F=0 (1 bit) followed by block PT (7 bits). Timestamp and length fields are omitted because they are derivable from the RTP header and overall packet length.