Post-Repair Loss RLE Report Block Type for RTP Control Protocol (RTCP) Extended Reports (XRs)
Extracted elements (21)
Only the Loss RLE after all loss-repair methods have been applied is reported (rather than after each individual method), because quantifying the specific contribution of each method in hybrid systems where methods work collectively is a difficult task.
The Post-repair Loss RLE uses the same structure as the pre-repair Loss RLE Report Block from RFC 3611 to allow implementations to compare the two Loss RLEs very efficiently, avoiding the need for different parsing logic.
Post-repair Loss RLE reports may not be delayed arbitrarily because sequence-number wrapping in the primary source stream can create ambiguity. In case of ambiguity, it is the sender's or monitoring entity's responsibility to determine which packets the report relates to.
Sequence numbers in the Post-repair Loss RLE report refer to the primary source stream, not to any repair stream. This distinction is critical when loss-repair methods such as FEC or retransmission are used.
The bandwidth usage rules described in RFC 3611 apply to Post-repair Loss RLE reports as well; implementations must carefully consider the bandwidth consumed by detailed reports.
Applications employing one or more loss-repair methods MAY use Post-repair Loss RLE reports for every packet received or for a set of specific packets, meaning the coverage of post-repair Loss RLEs may or may not be contiguous.
Different thinning values MAY be used for Pre-repair and Post-repair Loss RLE reports based on the specific needs of the application or monitoring entity.
If the loss-repair method(s) may still recover one or more missing source packets, the post-repair Loss RLE SHOULD NOT be sent until the loss-recovery process has been completed.
If thinning is desired, it is RECOMMENDED to use the same thinning value in both Pre-repair and Post-repair Loss RLE reports to allow easier report processing and correlation.
It is RECOMMENDED that the post-repair Loss RLE be generated only for source packets that have no further chance of being repaired, to avoid ambiguity in evaluation.
Methods that can partially recover missing data SHOULD NOT be evaluated based on Post-repair Loss RLE reports, as such reports consider partially repaired packets as unrepaired and may underestimate the effectiveness of partial repair methods.
Post-repair Loss RLE reports MAY be protected using SRTP and SRTCP (RFC 3711).
The reserved (rsvd.) field in the Post-repair Loss RLE Report Block MUST be set to zero by the sender and MUST be ignored by the receiver.
The Post-repair Loss RLE Report Block (BT=10) is a new RTCP XR block type that conveys receipt/loss events for RTP packets after all loss-repair methods have been applied. It uses the same structure as the pre-repair Loss RLE Report Block defined in RFC 3611, enabling efficient comparison between pre- and post-repair states.
The SDP signaling parameter for Post-repair Loss RLE uses the syntax 'post-repair-loss-rle [= max-size]' within the 'rtcp-xr' attribute, where max-size specifies the maximum block size in octets. It is compatible with the 'format-ext' definition in RFC 3611.
The thinning field (T, 4 bits) controls the sequence-number space coverage: only packets with sequence numbers 0 mod 2^T are reported. A value of 0 means no thinning and all packets are reported; maximum thinning is one packet in every 32,768.
This document assigns block type value 10 in the RTCP XR Block Type Registry to 'Post-repair Loss RLE Report Block', and registers the SDP parameter 'post-repair-loss-rle' for the 'rtcp-xr' attribute in the RTCP XR SDP Parameters Registry.
An attacker interfering with the repair process for an RTP stream who can observe Post-repair Loss RLEs may use this feedback to determine whether their attack is effective and adapt accordingly; however, this is considered a low practical security risk.
An attacker may inject incorrect information in Pre-repair or Post-repair Loss RLE reports to influence proactive or reactive decisions made by the sender in the repair process. Sender applications should be aware of this risk and take precautions to minimize or eliminate such attacks.
An attacker monitoring Post-repair Loss RLE reports in addition to Pre-repair reports can infer the effectiveness of the repair process, but this does not enable new attacks beyond what an attacker could determine by observing RTP packets and performing the repair algorithms themselves.
The Post-repair Loss RLE Report Block format consists of: BT (8 bits, value=10), rsvd (4 bits, must be zero), T/thinning (4 bits), block length (16 bits, in 32-bit words minus one), SSRC of source (32 bits), begin_seq (16 bits), end_seq (16 bits), followed by 16-bit chunks (run length, bit vector, or terminating null).