RTP Control Protocol (RTCP) Extended Report (XR) for Post-Repair Loss Count Metrics
Extracted elements (20)
Metrics are defined at packet level rather than slice/picture level: partial recovery of a packet is not counted as a repaired packet. This maintains a clean, unambiguous definition of repair effectiveness.
The block uses explicit begin_seq and end_seq fields to define the reported sequence number range, avoiding ambiguity when comparing post-repair metrics against the cumulative loss in RTCP SR/RR, since some packets not repaired in one interval may be repaired later.
The Repaired loss count metric is included alongside Post-repair loss count so that a sender or third party can derive the pre-repair loss count for a sequence number range (pre-repair = post-repair loss count + repaired loss count), enabling evaluation of repair mechanism effectiveness without reference to cumulative RTCP RR data.
This block was created because the existing RFC 5725 post-repair RLE XR block incurs higher reporting overhead due to its packet-by-packet format. When applications use multiple XR blocks and require concise reporting to save bandwidth, this count-based block provides a more efficient alternative.
This block complements but does not replace the RFC 5725 post-repair loss RLE report block. RFC 5725 allows the sender to infer which specific packets were repaired, while this block provides only aggregate counts with lower overhead; implementations may use both.
Aligning begin_seq and end_seq with the highest sequence numbers of consecutive RTCP RRs (interval reporting) is NOT RECOMMENDED, as packets not yet repaired in the current interval but repaired in subsequent intervals will not be reported.
If implementations want packets repaired across RTCP interval boundaries to be reported, they MUST NOT align begin_seq and end_seq to the RTCP intervals.
The Block length field MUST be set to 4; the block MUST be discarded if the block length is set to a different value.
The Post-repair loss count field MUST NOT count lost packets for which repair might still be possible, and MUST measure only primary source RTP packets.
The Repaired loss count field MUST measure only primary source RTP packets (i.e., original packets sent for the first time, not repair packets).
The Reserved field (8 bits) MUST be set to zero by senders and ignored by receivers.
XR blocks MAY be used without prior SDP signaling, per Section 5 of RFC 3611.
The Post-Repair Loss Count Metrics Report Block (BT=33) reports the number of primary source RTP packets still lost after applying loss-repair mechanisms (e.g., FEC, retransmission) and the number fully repaired, over a sequence number range defined by begin_seq and end_seq. It complements the RFC 5725 post-repair RLE XR block with more concise reporting.
The SDP rtcp-xr attribute is extended with the parameter 'post-repair-loss-count' (xr-prlr-block) using ABNF syntax to signal use of this report block in a session.
Two usage modes are defined: cumulative (begin_seq fixed at session start, counts grow monotonically) and interval (begin_seq/end_seq aligned to RTCP intervals, though not recommended). Cumulative mode enables calculation of 'Still-to-be-repaired lost packets' = cumulative packets lost - cumulative post-repair loss count - cumulative repaired loss count.
Block type value 33 is assigned in the IANA 'RTP Control Protocol Extended Reports (RTCP XR) Block Type Registry' to the 'Post-Repair Loss Count Metrics Report Block'.
The parameter 'post-repair-loss-count' is registered in the 'RTP Control Protocol Extended Reports (RTCP XR) Session Description Protocol (SDP) Parameters Registry'.
An attacker may inject incorrect information into Post-Repair Loss Count reports, degrading the performance of loss-repair mechanisms. Implementations should apply encryption and authentication (e.g., SRTP/SAVPF per RFC 3711 and RFC 5124) where security is a concern.
This block does not provide per-packet statistics, so the confidentiality risk documented in Section 7, paragraph 3 of RFC 3611 does not apply. No new security considerations beyond RFC 3611 are introduced.
The block is 5 32-bit words (block length=4): BT=33 (8 bits), Reserved (8 bits), Block length (16 bits), SSRC of Source (32 bits), begin_seq (16 bits), end_seq (16 bits), Post-repair loss count (16 bits), Repaired loss count (16 bits).