RTP Control Protocol (RTCP) Extension for a Third-Party Loss Report
Extracted elements (20)
In the SSM Distribution Source Feedback Summary Model, the distribution source does not redistribute NACKs (e.g., to prevent revealing the identity of NACK senders) and instead sends RTCP TPLR to suppress redundant feedback from other receivers unaware of the reported loss.
RTCP feedback storms ('NACK storms') occur when many receivers simultaneously lose synchronization and send duplicate feedback to the same media source. The TPLR message was designed to allow intermediaries to signal receivers to suppress redundant feedback, addressing transient overload of media sources and networks.
Nodes that do not understand the RTCP TPLR message will ignore it and may still send feedback per the AVPF scheduling algorithm of RFC 4585; media sources and intermediaries cannot be certain that TPLR actually reduces the feedback they receive.
Applications employing loss-repair methods MAY use RTCP TPLR together with their existing loss-repair methods, either for every expected packet or for an application-specific subset of RTP packets in a session.
Further feedback messages for sequence numbers already covered by a received RTCP TPLR SHOULD be suppressed, even if the receiver had already sent feedback before receiving the TPLR.
If an additional TPLR retransmission arrives, the receiver SHOULD treat it the same as receiving the first TPLR for the same packet, with no additional behavior required.
Intermediaries that receive an RTCP TPLR MUST NOT send their own additional Third-Party Loss Report messages for the same packet sequence numbers; they SHOULD simply forward the received RTCP TPLR message to downstream receivers.
The FCI field MUST contain one or more TLLEI entries, and the length field in the TLLEI feedback message MUST be set to N+2, where N is the number of FCI entries.
The length field in the PSLEI feedback message MUST be set to N+2, where N is the number of FCI entries, with each entry applying to a different media source identified by its SSRC.
When a receiver gets an RTCP TPLR message, it MUST follow the rules for NACK suppression in RFC 4585 and refrain from sending feedback requests (e.g., NACK or FIR) for the missing packets reported in the TPLR message.
SDP signaling is extended via the rtcp-fb attribute with two new 'nack' parameters: 'tllei' for Transport-Layer Third-Party Loss Early Indication support, and 'pslei' for Payload-Specific Third-Party Loss Early Indication support.
The Payload-Specific Third-Party Loss Report (PSLEI) is identified by PT=PSFB and FMT=8, used to suppress FIR and PLI feedback messages. The 'SSRC of media source' field is not used and SHALL be set to 0; the relevant media source SSRCs are in FCI entries.
The Third-Party Loss Report (TPLR) is a new RTCP feedback message that intermediaries send to inform receivers that the feedback target is already aware of specific packet losses, instructing receivers to suppress their own feedback for those packets.
The Transport-Layer Third-Party Loss Report (TLLEI) is identified by RTCP packet type PT=RTPFB and FMT=7. The 'SSRC of packet sender' indicates the source of the request and 'SSRC of media source' identifies the flow for which losses are suppressed.
IANA added two values ('tllei' and 'pslei') to the '"ack" and "nack" Attribute Values' sub-registry of the 'Session Description Protocol (SDP) Parameters' registry, both usable with 'nack'.
IANA registered two new FMT values: TLLEI (value 7) in the 'FMT Values for RTPFB Payload Types' registry, and PSLEI (value 8) in the 'FMT Values for PSFB Payload Types' registry, per this document.
Intermediaries not visible at the RTP layer wishing to send TPLR on behalf of a media source must spoof the media source's SSRC, which is difficult when SRTP is in use. If the intermediary is visible at the RTP layer and is part of the security context, this is not an issue.
Spoofed or maliciously created TPLR messages can cause missing RTP packets to not be repaired in a timely fashion and suppress legitimate feedback at receivers. Mitigation requires authentication and integrity protection using SAVPF (RFC 5124), which combines SRTP and AVPF.
Each PSLEI FCI entry is 32 bits containing the SSRC of the media source that is already aware (or being made aware) of receiver loss of synchronization, for which the PSLEI receiver's response is suppressed.
Each TLLEI FCI entry is 32 bits: a 16-bit Packet ID (PID) field referencing the RTP sequence number of the lost packet, followed by a 16-bit Bitmask of Lost Packets (BLP) indicating losses among the 16 RTP packets immediately following the PID.