Duplicating RTP Streams
Extracted elements (22)
SRTP encryption does not affect stream de-duplication middleboxes because RTP headers (including SSRC and sequence number fields needed for duplicate identification) are sent in the clear, allowing middleboxes to perform de-duplication without requiring decryption keys.
Stream duplication has a comparatively high overhead in terms of bandwidth (everything sent twice) but low processing overhead and very predictable cost proportional to minimum session bandwidth, independent of the number of receivers experiencing loss. Retransmission-based recovery (RFC 4588) and FEC (RFC 6363) are identified as alternatives for other scenarios.
Temporal redundancy interleaves duplicate packets with a delay so that if a packet is lost in transit, the duplicate (sent later) still arrives; the probability that the same packet is lost twice under non-congestive conditions is small. Spatial redundancy routes the two streams over physically diverse paths, making unrecoverable loss possible only when both paths fail simultaneously.
The capacity requirement for duplication restricts its use to managed networks and makes it unsuitable for unmanaged public networks. Duplication and de-duplication nodes must track the original stream's adaptation state (e.g., bitrate changes) and apply the same adaptation to the duplicate stream.
The SSRC listed first in 'a=ssrc-group:DUP' is advisably sent first as the primary stream, but a receiver should size its playout buffer based on the 'duplication-delay' attribute and play whichever stream arrives first, treating the other as a repair stream, regardless of signaling order.
Duplication is RECOMMENDED only to protect against network outages due to temporary link or network element failure, and only where it is known (e.g., through explicit operator configuration) that sufficient network capacity exists to carry the duplicated traffic.
For spatial redundancy, SSRCs for both main and duplicate streams MUST be chosen randomly following RFC 3550 Section 8 and will almost certainly not match. The sender MUST use the same RTCP CNAME for both streams. Duplication is signaled using 'a=group:DUP' or 'a=ssrc-group:DUP'.
For temporal redundancy, the main and duplicate RTP streams SHOULD be sent using the same 5-tuple (transport protocol, source/destination IP addresses, source/destination ports). Use of anything other than an identical 5-tuple and flow label is NOT RECOMMENDED unless the path is known to be free of NAPT devices, load balancers, or other middleboxes, since non-identical 5-tuples may introduce unintended spatial redundancy and additional path-delay delta.
If de-duplication takes place at the ultimate endpoint rather than inside the network, that endpoint MUST consider the aggregate of the original and duplicated RTP streams in any congestion control it applies.
If RTCP is being sent for the main RTP stream, the sender MUST also generate RTCP for the duplicate stream as if it were a regular media stream. The sender MUST NOT copy the RTCP packets from the main stream; it MUST generate new, independent RTCP reports for the duplicate stream.
If RTCP is used, receivers MUST generate RTCP reports for both the main and duplicate RTP streams in the usual way, treating them as entirely separate media streams.
One of two conditions is REQUIRED: the original and duplicate RTP streams are carried with their own SSRCs in the same 'm' line, or they are in separate 'm' lines with no other RTP stream listed in either. When streams are in separate 'm' lines alongside other streams, further signaling beyond this specification is needed.
RTP duplication MUST NOT be used when the primary cause of packet loss is congestion, since duplication worsens congestion. Duplication SHOULD NOT be used where there is a risk of congestion upon duplicating an RTP stream.
RTP timestamps and sequence numbers MUST be identical in the main and duplicate streams. This makes timeline synchronization via RTCP Sender Reports trivial, since the two timelines are already aligned.
The sender MUST choose a different SSRC for the duplicate RTP stream than for the main RTP stream, following the SSRC selection rules in Section 8 of RFC 3550.
The sender MUST use the same RTCP CNAME in the RTCP reports for both the main and duplicate streams, so that receivers can synchronize them.
Dual streaming transmits two redundant RTP streams (original plus its duplicate) of the same content, each with a unique SSRC, so that either stream alone can support playback. All redundant streams are transmitted in the same RTP session when using temporal redundancy.
For spatial redundancy, the duplicate RTP stream is sent using a different source and/or destination address/port pair, forming a separate RTP session. If source-specific multicast (SSM) is used, receivers must join each SSM session separately since the streams originate from different IP addresses.
SDP signaling for temporal redundancy uses 'a=ssrc-group:DUP' to associate the SSRCs of the main and duplicate streams, 'a=duplication-delay' (from RFC 7197) for the delay value, and identical CNAME values on both SSRCs. The DUP grouping semantics are defined in RFC 7104.
In-network duplication middleboxes can act as denial-of-service amplifiers if an attacker can cause attack traffic to be duplicated. Middleboxes providing duplication must authenticate traffic as being from a legitimate source (e.g., using SRTP), requiring the middlebox to be part of the security context with access to keying material via session setup signaling.
To prevent packet injection attacks, a de-duplication middlebox must authenticate both original and duplicate streams and ought not use non-authenticated packets. This requires the middlebox to be part of the security context and have access to appropriate signaling and keying material.
When the original RTP stream is authenticated (e.g., using SRTP), the duplicate stream must also be authenticated, and duplicate packets that fail authentication must be discarded.