rfc-6843

RTP Control Protocol (RTCP) Extended Report (XR) Block for Delay Metric Reporting

A. Clark, K. Gross, Q. Wu
date2013-01 streamIETF areaart wgxrblock statusPROPOSED STANDARD pages9 canonicalhttps://www.rfc-editor.org/rfc/rfc6843 doi10.17487/RFC6843
This document defines an RTP Control Protocol (RTCP) Extended Report (XR) block that allows the reporting of delay metrics for use in a range of Real-time Transport Protocol (RTP) applications. [STANDARDS-TRACK]

Extracted elements (21)

design-rationale §1.4

Delay metrics are applicable to multimedia conferencing and streaming audio/video because knowledge of round-trip delay and delay characteristics aids receivers in sizing receive buffers and selecting playout delay, and assists network managers in troubleshooting.

rtp, realtime, measurement

design-rationale §3.2

Round-trip delay values can be determined either via RTCP SR/RR (using NTP timestamp, LSR, and DLSR fields from RFC 3550) or via RTCP XR Receiver Reference Time and DLRR Report Blocks (using LRR and DLRR fields from RFC 3611), providing two equivalent measurement paths.

rtp, realtime, measurement

interoperability-note §4.2

When SDP is used in offer/answer context, the SDP Offer/Answer usage defined in RFC 3611 applies to the Delay Metrics Block signaling.

rtp, realtime

normative-requirement §3.2 MUST

If any delay measurement (mean, min, max, or end system delay) is unavailable, the value of the corresponding field with all bits set to 1 MUST be reported.

rtp, realtime, measurement

normative-requirement §3.2 SHOULD

If only one Round-Trip Delay measurement is available for the measurement period, this single value SHOULD be reported as the mean value.

rtp, realtime, measurement

normative-requirement §3 MUST

If the measurement period is not received in the same compound RTCP packet as the Delay Metrics Block, this metrics block MUST be discarded.

rtp, realtime

normative-requirement §3 SHOULD

The Delay Metrics Block SHOULD be sent in the same compound RTCP packet as the Measurement Information block, since it relies on the measurement period defined therein.

rtp, realtime

normative-requirement §3.2 MUST

The reserved (resv) 6-bit field MUST be set to zero by senders and ignored by receivers.

rtp, realtime

normative-requirement §4 MAY

XR blocks MAY be used without prior SDP signaling, per RFC 3611.

rtp, realtime

protocol-element §3

The Delay Metrics Block (BT=16) is a new RTCP XR block type that reports mean, minimum, and maximum network round-trip delay and end system delay for RTP streams. It references the Measurement Information block via SSRC and has a fixed block length of 6 (32-bit words minus one).

rtp, realtime, measurement

protocol-element §3.2

The End System Delay field captures the internal round-trip delay within the reporting endpoint, calculated as the nominal jitter buffer delay plus accumulation/encoding and decoding/playout delay associated with the codec in use.

rtp, realtime

protocol-element §3.2

The Interval Metric flag (I) is a 2-bit field indicating whether reported delay values are Interval Duration (I=10), Cumulative Duration (I=11), or Sampled Value (I=01).

rtp, realtime, measurement

protocol-element §4.1

The SDP attribute extension augments the "rtcp-xr" attribute with the new xr-format value "xr-delay-block" (token: "delay") to signal use of the Delay Metrics Block.

rtp, realtime

registry §5.1

This document assigns block type value 16 in the IANA "RTP Control Protocol Extended Reports (RTCP XR) Block Type Registry" to the "Delay Metrics Block".

rtp, realtime, registry

registry §5.2

This document registers the new SDP parameter "delay" in the "RTP Control Protocol Extended Reports (RTCP XR) Session Description Protocol (SDP) Parameters" registry.

rtp, realtime, registry

security-consideration §6

This RTCP XR block introduces no new security considerations beyond those described in RFC 3611. Because it does not provide per-packet statistics, the confidentiality risk documented in RFC 3611 Section 7 paragraph 3 does not apply.

rtp, realtime, security

wire-format §3.2

End System Delay is a 64-bit NTP-format timestamp (RFC 5905) representing the internal round-trip delay within the reporting endpoint, computed from jitter buffer delay plus codec encoding/decoding/playout delay.

rtp, realtime, measurement, ntp

wire-format §3.2

Max Network Round-Trip Delay is a 32-bit field expressing the maximum round-trip delay over the measurement period in units of 1/65536 seconds; when only one measurement exists it SHOULD be reported as the maximum.

rtp, realtime, measurement

wire-format §3.2

Mean Network Round-Trip Delay is a 32-bit field expressing the mean RTP-to-RTP interface round-trip delay over the measurement period in units of 1/65536 seconds, typically derived from NTP timestamp, LSR, and DLSR fields in RTCP SR/RR.

rtp, realtime, measurement

wire-format §3.2

Min Network Round-Trip Delay is a 32-bit field expressing the minimum round-trip delay over the measurement period in units of 1/65536 seconds; when only one measurement exists it SHOULD be reported as the minimum.

rtp, realtime, measurement

wire-format §3.1

The Delay Metrics Block header encodes Block Type (BT=16, 8 bits), Interval Metric flag (I, 2 bits), reserved (6 bits), and block length (16 bits, fixed value 6), followed by SSRC of Source (32 bits), Mean/Min/Max Network Round-Trip Delay (each 32 bits in units of 1/65536 seconds), and End System Delay (64 bits, NTP timestamp format).

rtp, realtime