RTP Retransmission Payload Format
Extracted elements (27)
Both session-multiplexing and SSRC-multiplexing are defined. Session-multiplexing allows multicast receivers to subscribe selectively to the retransmission session and enables differential network treatment; SSRC-multiplexing minimizes port usage for servers handling many concurrent sessions.
Retransmitting with the original sequence number in the same RTP stream was rejected because it corrupts RTCP statistics, which require each packet in a stream to increment the sequence number by one. Payload-type multiplexing in the same stream was also rejected because it violates sequence number preservation: receivers cannot infer which original packets were lost when original and retransmission packets share a sequence number space.
The retransmission stream is sent separately from the original stream and includes the original sequence number (OSN) in a 2-octet payload header. This design satisfies all six requirements: compatibility with RTCP, support for unicast and small multicast, interoperability with mixers/translators, support for all payload types, multiple payload types per session, and sequence number preservation.
For RTSP with session-multiplexing, the presentation SHOULD support aggregate control with a session-level RTSP URL, and the receiver SHOULD use aggregate control for the original and retransmission sessions together. Without this, two separate session-id values would prevent the sender from associating them.
For session-multiplexing, a receiver associates the two streams sharing the same SSRC across the two sessions (sessions are associated out-of-band via SDP FID grouping). For SSRC-multiplexing, the receiver uses CNAME matching and correlates retransmission packets against outstanding NACK requests to determine the SSRC-to-original-stream mapping.
For session-multiplexing, SDP MUST use FID (Flow Identification) semantics from RFC 3388 to group the original and retransmission session "m" lines. The exception is when there is exactly one original/retransmission pair, in which case FID grouping MAY be omitted.
A sender MUST use the same RTCP CNAME for an original stream and its associated retransmission stream, in both session-multiplexing and SSRC-multiplexing cases.
Both session-multiplexing and SSRC-multiplexing SHOULD be supported by senders and receivers in unicast sessions to maximize interoperability. For multicast sessions, session-multiplexing MUST be used because SSRC-multiplexing creates an unresolvable association ambiguity when multiple receivers may request the same sequence number from different streams.
If the original RTP header carried profile-specific extensions or an RTP header extension, the retransmission packet SHOULD include the same extensions immediately after the fixed RTP header. The retransmission payload header MUST be placed after any such extensions.
If the original RTP packet contained RTP padding, that padding MUST be removed before constructing the retransmission packet. If padding of the retransmission packet is needed, it MUST be applied fresh and the padding bit MUST be set. The marker bit (M), CSRC count (CC), and CSRC list MUST be copied as-is from the original RTP header.
In a best-effort network, the sender SHOULD NOT send retransmission packets without reducing the packet rate and bitrate of the original stream (e.g., by encoding at a lower rate), ensuring that total bitrate including retransmissions does not exceed the fair share a TCP flow would achieve. If congestion cannot be controlled, retransmission SHOULD NOT be used.
In session-multiplexing, a retransmission session MUST map to exactly one original session; the same retransmission session MUST NOT be used for multiple original sessions, as receivers would otherwise receive retransmissions for sessions they did not join.
In session-multiplexing, the same SSRC value MUST be used for the original stream and the retransmission stream. In the event of SSRC collision, an RTCP BYE MUST be sent in the colliding session and also for the associated stream in its own session; both streams MUST then adopt the new SSRC.
In SSRC-multiplexing, the receiver MUST NOT have two outstanding NACK requests for the same packet sequence number in two different original streams before the SSRC association is resolved, to avoid ambiguity. SSRC-multiplexing MUST NOT be used in multicast sessions for the same reason.
In SSRC-multiplexing, two different SSRC values MUST be used for the original and retransmission streams. On collision, an RTCP BYE MUST be sent only for the affected stream; MUST NOT be sent for the associated stream.
NACKs (retransmission requests) MUST be sent only for the original RTP stream, not for the retransmission stream, because the receiver cannot determine the original sequence number or estimate the timestamp for a packet lost in the retransmission stream.
The retransmission packet timestamp MUST be set to the original timestamp of the associated original RTP packet, not a new or random value. Consequently, the initial RTP timestamp of the retransmission stream equals the original timestamp of the first retransmitted packet.
The timestamp clockrate used by the retransmission payload type MUST be the same as that used by the associated original payload type, since the retransmission timestamp carries the original media timestamp.
OSN (Original Sequence Number) is a 16-bit field occupying the first 2 octets of the retransmission payload header. It MUST be set to the RTP sequence number of the associated original packet, enabling the receiver to identify and reconstruct the original packet sequence.
The "apt" (associated payload type) parameter is a REQUIRED SDP/MIME parameter that maps a retransmission payload type number to the corresponding original stream payload type. Multiple "apt" parameters MUST be included when the original stream uses multiple payload types.
The "rtx-time" parameter is an OPTIONAL SDP/MIME parameter specifying in milliseconds (from first transmission) how long a sender keeps an original RTP packet in its retransmission buffer. Absence of this parameter means the maximum retransmission time is undefined.
RFC 4588 registers the MIME subtype "rtx" for four media types: audio/rtx, video/rtx, text/rtx, and application/rtx. Each registration defines a required "apt" parameter and an optional "rtx-time" parameter. The MIME subtype name "rtx" is used in SDP rtpmap attributes to bind retransmission payload type numbers.
Absence of authentication enables man-in-the-middle and replay attacks with severe consequences: tampered RTCP packets can trigger inappropriate retransmissions that starve the original stream, tampered retransmission packets can crash decoders, tampered NACK requests can invalidate SSRC association, and replayed packets can cause false RTT measurements and receiver buffer overflow.
If cryptography is used to provide security on the original RTP stream, the same security services with equivalent cryptographic strength MUST be provided on the retransmission stream.
The retransmission stream's initial RTP timestamp is not random (it equals the original media timestamp of the first retransmitted packet), deviating from the RTP recommendation to use a random initial timestamp. However, if the original stream is encrypted, the first retransmitted packet's timestamp is still effectively random to an attacker, so confidentiality is not compromised.
Using the same encryption key for both the original and retransmission streams risks two-time pad attacks, since the same plaintext media payload appears in both streams. Implementers are referred to SRTP (RFC 3711) Section 9.1 for mitigations. At time of publication, SRTP did not fully support this payload format due to two-time pad issues and its lack of support for the RTP/AVPF profile.
A retransmission packet consists of a standard RTP header, followed by a 2-octet retransmission payload header containing the OSN (original sequence number) field, followed by the payload of the original RTP packet (including any original payload-specific headers).