One document matched: draft-ietf-xrblock-rtcp-xr-pdv-08.xml
<?xml version="1.0" encoding="UTF-8"?>
<!-- edited with XMLSPY v5 rel. 3 U (http://www.xmlspy.com)
by Daniel M Kohn (private) -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
]>
<rfc category="std" docName="draft-ietf-xrblock-rtcp-xr-pdv-08.txt"
ipr="trust200902">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<front>
<title abbrev="RTCP XR Packet Delay Variation">RTP Control Protocol (RTCP)
Extended Report (XR) Block for Packet Delay Variation Metric
Reporting</title>
<author fullname="Alan Clark" initials="A." surname="Clark">
<organization abbrev="Telchemy">Telchemy Incorporated</organization>
<address>
<postal>
<street>2905 Premiere Parkway, Suite 280</street>
<city>Duluth</city>
<region>GA</region>
<code>30097</code>
<country>USA</country>
</postal>
<email>alan.d.clark@telchemy.com</email>
</address>
</author>
<author fullname="Qin Wu" initials="Q." surname="Wu">
<organization>Huawei</organization>
<address>
<postal>
<street>101 Software Avenue, Yuhua District</street>
<city>Nanjing</city>
<region>Jiangsu</region>
<code>210012</code>
<country>China</country>
</postal>
<email>sunseawq@huawei.com</email>
</address>
</author>
<date year="2012" />
<area>Real-time Applications and Infrastructure Area</area>
<workgroup>Audio/Video Transport Working Group</workgroup>
<keyword>RFC</keyword>
<keyword>Request for Comments</keyword>
<keyword>I-D</keyword>
<keyword>Internet-Draft</keyword>
<keyword>Real Time Control Protocol</keyword>
<abstract>
<t>This document defines an RTP Control Protocol (RTCP) Extended Report
(XR) block that allows the reporting of Packet Delay Variation metrics
for a range of RTP applications.</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<section title="Packet Delay Variation Metrics Block">
<t>This draft defines a new block type to augment those defined in
<xref target="RFC3611"></xref>, for use in a range of RTP
applications.</t>
<t>The new block type provides information on Packet Delay Variation
(PDV) using one of several standard metrics,, for example, Mean
Absolute Packet Delay Variation 2 (MAPDV2) (Clause 6.2.3.2 of <xref
target="G.1020"></xref>), or 2-point PDV (Clause 6.2.4 of <xref
target="Y.1540"></xref>).</t>
<t>The metrics belong to the class of transport metrics defined in
<xref target="MONARCH"></xref>.</t>
</section>
<section title="RTCP and RTCP XR Reports">
<t>The use of RTCP for reporting is defined in <xref
target="RFC3550"></xref>. <xref target="RFC3611"></xref> defined an
extensible structure for reporting using an RTCP Extended Report (XR).
This draft defines a new Extended Report block for use with <xref
target="RFC3550"></xref> and <xref target="RFC3611"></xref>.</t>
</section>
<section title="Performance Metrics Framework">
<t>The Performance Metrics Framework <xref target="RFC6390"></xref>
provides guidance on the definition and specification of performance
metrics. The RTP Monitoring Architectures <xref
target="MONARCH"></xref> provides guideline for reporting block format
using RTCP XR. The XR Block described in this document are in
accordance with the guidelines in <xref target="RFC6390"></xref> and
<xref target="MONARCH"></xref>.</t>
</section>
<section title="Applicability">
<t>These metrics are applicable to a wide range of RTP applications in
which the application streams are sensitive to delay variation<xref
target="RFC5481"></xref>. For example, applications could use the
measurements of these metrics to help adjust the size of adaptive
jitter buffers to improve performance. Network managers can use these
metrics to compare actual delay variation to targets (i.e., a
numerical objective or Service Level Agreement) to help ensure the
quality of real-time application performance.</t>
</section>
</section>
<section title="Terminology">
<section title="Standards Language">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 <xref
target="RFC2119"></xref>.</t>
</section>
<section title="Notations">
<t>This report block makes use of binary fractions. The terminology
used is <list>
<t>Numeric formats S X:Y<list>
<t>where S indicates a two's complement signed representation,
X the number of bits prior to the decimal place and Y the
number of bits after the decimal place.</t>
<t>Hence 8:8 represents an unsigned number in the range 0.0 to
255.996 with a granularity of 0.0039. S7:8 would represent the
range -127.996 to +127.996. 0:16 represents a proper binary
fraction with range</t>
<t>0.0 to 1 - 1/65536 = 0.9999847</t>
<t>though note that use of flag values at the top of the
numeric range slightly reduces this upper limit. For example,
if the 16- bit values 0xfffe and 0xffff are used as flags for
"over-range" and "unavailable" conditions, a 0:16 quantity has
range</t>
<t>0.0 to 1 - 3/65536 = 0.9999542</t>
</list></t>
</list></t>
</section>
</section>
<section title="Packet Delay Variation Metrics Block">
<t>Metrics in this block report on packet delay variation in the stream
arriving at the RTP system. The measurement of these metrics are made at
the receiving end of the RTP stream. Instances of this metric block
refer by Synchronization Source (SSRC) to the separate auxiliary
Measurement Information Block <xref target="MEASI"></xref> which
contains measurement intervals. This metric block relies on the
measurement interval given by the value of the "Measurement Duration
(Interval)" field in the Measurement Information Block to indicate the
span of the report and MUST be sent in the same compound RTCP packet as
the Measurement Information Block. If the measurement interval is not
received for this metric block, this metric block MUST be discarded.
</t>
<section title="Report Block Structure">
<t>PDV metrics block<figure title="Figure 1: Report Block Structure">
<artwork>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BT=NPDV | I |pdvtyp |Rsv| block length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of Source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pos PDV Threshold/Peak | Pos PDV Percentile |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neg PDV Threshold/Peak | Neg PDV Percentile |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mean PDV | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure></t>
</section>
<section title="Definition of Fields in PDV Metrics Block">
<t><list style="hanging">
<t hangText="Block type (BT): 8 bits"><vspace blankLines="1" /> A
Packet Delay Variation Metrics Report Block is identified by the
constant NPDV.<vspace blankLines="1" />[Note to RFC Editor: please
replace NPDV with the IANA provided RTCP XR block type for this
block.]<vspace blankLines="1" /></t>
<t hangText="Interval Metric flag (I): 2 bit"><vspace
blankLines="1" />This field is used to indicate whether the Packet
Delay variation metrics are Sampled, Interval or Cumulative
metrics <xref target="MONARCH"></xref>, that is, whether the
reported values applies to the most recent measurement interval
duration between successive metrics reports (I=10) (the Interval
Duration) or to the accumulation period characteristic of
cumulative measurements (I=11) (the Cumulative Duration) or is a
sampled instantaneous value (I=01) (Sampled Value). The value I=00
is reserved, and MUST NOT be used. If the value I=00 is received,
then the XR block MUST be ignored by the receiver. <vspace
blankLines="1" /></t>
<t
hangText="Packet Delay Variation Metric Type (pdvtyp): 4 bits"><vspace
blankLines="1" />Packet Delay Variation Metric Type is of type
enumerated and is interpreted as an unsigned, 4-bit integer. This
field is used to identify the Packet Delay Variation Metric Type
used in this report block, according to the following code:<vspace
blankLines="1" /><list>
<t>bits 014-011<list>
<t>0: MAPDV2, Clause 6.2.3.2 of <xref
target="G.1020"></xref>,</t>
<t>1: 2-point PDV, Clause 6.2.4 of <xref
target="Y.1540"></xref>.</t>
</list></t>
</list><vspace blankLines="1" /></t>
<t hangText="Rsv.: 2 bits"><vspace blankLines="1" />This field is
reserved for future definition. In the absence of such a
definition, the bits in this field MUST be set to zero and ignored
by the receiver. <vspace blankLines="1" /></t>
<t hangText="Block Length: 16 bits"><vspace blankLines="1" />The
length of this report block in 32-bit words, minus one. For the
Packet Delay Variation Metrics block, the block length is equal to
4.<vspace blankLines="1" /></t>
<t hangText="SSRC of source: 32 bits"><vspace blankLines="1" /> As
defined in Section 4.1 of <xref target="RFC3611"></xref>. <vspace
blankLines="1" /></t>
<t hangText="Positive PDV Threshold/Peak: 16 bits"><vspace
blankLines="1" />This field is associated with the Positive PDV
percentile and expressed in Milliseconds with numeric format
S11:4. The term Positive represents that the packets are arriving
later than the expected time. <vspace blankLines="1" />If the
measured value is less than -2047.9375 (the value which would be
coded as 0x8001), the value 0x8000 SHOULD be reported to indicate
an over-range negative measurement. If the measured value is
greater than +2047.8125 (the value which would be coded as
0x7FFD), the value 0x7FFE SHOULD be reported to indicate an
over-range positive measurement. If the measurement is
unavailable, the value 0x7FFF MUST be reported. <vspace
blankLines="1" /></t>
<t hangText="Positive PDV Percentile: 16 bits"><vspace
blankLines="1" />The percentages of packets in the RTP stream for
which individual packet delays were less than the Positive PDV
Threshold. It is expressed in numeric format 8:8 with values from
0 to 100th percentile. <vspace blankLines="1" /> If the
measurement is unavailable, the value 0xFFFF MUST be
reported.<vspace blankLines="1" /></t>
<t hangText="Negative PDV Threshold/Peak: 16 bits"><vspace
blankLines="1" />This field is associated with the Negative PDV
percentile and expressed in Milliseconds with numeric format
S11:4. The term Negative represents that the packets are arriving
earlier than the expected time. <vspace blankLines="1" />If the
measured value is more negative than -2047.9375 (the value which
would be coded as 0x8001), the value 0x8000 SHOULD be reported to
indicate an over-range negative measurement. If the measured value
is more positive than +2047.8125 (the value which would be coded
as 0x7FFD), the value 0x7FFE SHOULD be reported to indicate an
over-range positive measurement. If the measurement is
unavailable, the value 0x7FFF MUST be reported.<vspace
blankLines="1" /></t>
<t hangText="Negative PDV Percentile: 16 bits"><vspace
blankLines="1" />The percentages of packets in the RTP stream for
which individual packet delays were more than the Negative PDV
Threshold. It is expressed in numeric format 8:8 with values from
0 to 100th percentile. <vspace blankLines="1" /> If the
measurement is unavailable, the value 0xFFFF MUST be
reported.<vspace blankLines="1" />If the PDV Type indicated is
2-point PDV and the Positive and Negative PDV Percentiles are set
to 100.0 then the Positive and Negative Threshold/Peak PDV values
are the peak values measured during the reporting interval (which
may be from the start of the call for cumulative reports). In this
case, the difference between the Positive and Negative
Threshold/Peak values defines the range of 2-point PDV.<vspace
blankLines="1" /></t>
<t hangText="Mean PDV: 16 bits"><vspace blankLines="1" />The mean
PDV value of data packets is expressed in milliseconds with
Numeric format S11:4 format.<vspace blankLines="1" /> For MAPDV2
this value is generated according to Clause 6.2.3.2 of [G.1020].
For interval reports the MAPDV2 value is reset at the start of the
interval.<vspace blankLines="1" /> For 2-point PDV, the value
reported is the mean of per-packet 2-point PDV values. This metric
indicates the arrival time of the first media packet of the
session with respect to the mean of the arrival times of every
packet of the session. A single value of the metric (for a single
session) may not be useful by itself, but its average over a
number of sessions may be useful in diagnosing media delay at
session startup. For example, this might occur if media packets
are often delayed behind signalling packets due to head-of-line
blocking.<vspace blankLines="1" /> If the measured value is more
negative than -2047.9375 (the value which would be coded as
0x8001), the value 0x8000 SHOULD be reported to indicate an
over-range negative measurement. If the measured value is more
positive than +2047.8125 (the value which would be coded as
0x7FFD), the value 0x7FFE SHOULD be reported to indicate an
over-range positive measurement. If the measurement is
unavailable, the value 0x7FFF MUST be reported.<vspace
blankLines="1" /></t>
<t hangText="Reserved: 16 bits"><vspace blankLines="1" />These
bits are reserved for future definition. They MUST be set to zero
by the sender and ignored by the receiver. <vspace
blankLines="1" /></t>
</list></t>
</section>
<section title="Guidance on use of PDV metrics">
<t>This subsection provides informative guidance on when it might be
appropriate to use each of the PDV metric types.</t>
<t>MAPDV2 (Clause 6.2.3.2 of <xref target="G.1020"></xref>) is the
envelope of instantaneous (per-packet) delay when compared to the
short term moving average delay. This metric could be useful in
determining residual impairment when an RTP end system uses an
adaptive de-jitter buffer which tracks the average delay variation,
provided that the averaging behavior of the adaptive algorithm is
similar to that of the MAPDV2 algorithm.</t>
<t>2-point PDV (Clause 6.2.4 of <xref target="Y.1540"></xref>) reports
absolute packet delay variation with respect to a defined reference
packet transfer delay . Note that the reference packet is generally
selected as the packet with minimum delay based on the most common
criterion (See section 1 and section 5.1 of <xref
target="RFC5481"></xref> ). In an RTP context, the two "points" are at
the sender (the synchronization source which applies RTP timestamps)
and at the receiver. The value of this metric for the packet with
index j is identical to the quantity D(i,j) defined in Section 6.4.1
of <xref target="RFC3550"></xref> and the packet index i should be set
equal to the index of the reference packet for the metric in practice.
The metric includes the effect of the frequency offsets of clocks in
both the sender and receiver end systems, so it is useful mainly in
network where synchronization is distributed. As well as measuring
packet delay variation in such networks, it may be used to ensure that
synchronization is effective, for example where the network carries
ISDN data traffic over RTP <xref target="RFC4040"></xref>. The metric
is likely to be useful in networks which use fixed de-jitter
buffering, because it may be used to determine the length of the
required de-jitter buffer, or to determine if network performance has
deteriorated such that existing de-jitter buffers are too small to
accommodate the observed delay variation.</t>
</section>
<section title="Examples of use">
<t><list>
<t>(b) To report MAPDV2 <xref target="G.1020"></xref>:<list>
<t>Pos PDV Threshold = 50.0; Pos PDV Percentile = 95.3; Neg
PDV Threshold = 50.0 (note this implies -50ms); Neg PDV
Percentile = 98.4; PDV type = 0 (MAPDV2)</t>
<t>causes average MAPDV2 to be reported in the Mean PDV
field.</t>
<t>Note that implementations may either fix the reported
percentile and calculate the associated PDV level or may fix a
threshold PDV level and calculate the associated percentile.
From a practical implementation perspective it is simpler to
use the second of these approaches (except of course in the
extreme case of a 100% percentile).</t>
</list></t>
<t>(b) To report 2-point PDV <xref target="Y.1540"></xref>:<list>
<t>Pos PDV Threshold = 60 (note this implies +60ms); Pos PDV
Percentile = 96.3; Neg PDV Threshold = 0; Neg PDV Percentile =
0; PDV type = 1 (2-point PDV)</t>
<t>causes 2-point PDV to be reported in the Mean PDV
field.</t>
<t>2-point PDV, according to <xref target="Y.1540"></xref> is
the difference in delay between the current packet and the
referenced packet of the stream. If the sending and receiving
clocks are not synchronized, this metric includes the effect
of relative timing drift.</t>
</list></t>
</list></t>
</section>
</section>
<section title="SDP Signaling">
<t>[RFC3611] defines the use of SDP (Session Description Protocol) <xref
target="RFC4566"></xref> for signaling the use of XR blocks. XR blocks
MAY be used without prior signaling.</t>
<t>This section augments the SDP <xref target="RFC4566"></xref>
attribute "rtcp-xr" defined in <xref target="RFC3611"></xref> by
providing an additional value of "xr-format" to signal the use of the
report block defined in this document.<figure>
<artwork>
xr-format =/ xr-pdv-block
xr-pdv-block = "pkt-dly-var" [ "," pdvtype ] [ "," nspec "," pspec ]
pdvtype = "pdv=" ( "0" ; MAPDV2 ITU-T G.1020
/ "1" ; 2-point PDV ITU-T Y.1540
/ 1*2DIGIT ) ;Value 2~15 are valid and
;reserved for future use
nspec = ("nthr=" fixpoint) ; negative PDV threshold (ms)
/ ("npc=" fixpoint ) ; negative PDV percentile
pspec = ("pthr=" fixpoint) ; positive PDV threshold (ms)
/ ("ppc=" fixpoint) ; positive PDV percentile
fixpoint = 1*DIGIT "." 1*DIGIT ; fixed point decimal
DIGIT = <as defined in Section 3.4 of [RFC5234]>
</artwork>
</figure></t>
<t>When SDP is used in offer-answer, a system sending SDP may request a
specific type of PDV measurement. In addition, they may state a specific
percentile or threshold value, and expect to receive the corresponding
threshold or percentile metric, respectively. The system receiving the
SDP SHOULD send the PDV metrics requested, but if the metric is not
available, the system receiving the SDP MUST send the metric block with
the flag value indicating that the metric is unavailable.</t>
</section>
<section title="IANA Considerations">
<t>New block types for RTCP XR are subject to IANA registration. For
general guidelines on IANA considerations for RTCP XR, refer to <xref
target="RFC3611"></xref>.</t>
<section title="New RTCP XR Block Type value">
<t>This document assigns the block type value NPDV in the IANA "RTCP
XR Block Type Registry" to the "Packet Delay Variation Metrics
Block".</t>
<t>[Note to RFC Editor: please replace NPDV with the IANA provided
RTCP XR block type for this block.]</t>
</section>
<section title="New RTCP XR SDP Parameter">
<t>This document also registers a new parameter "pkt-dly-var" in the
"RTCP XR SDP Parameters Registry".</t>
</section>
<section title="Contact information for registrations">
<t><figure>
<artwork>
The contact information for the registrations is:
Qin Wu (sunseawq@huawei.com)
101 Software Avenue, Yuhua District
Nanjing, Jiangsu 210012
China
</artwork>
</figure><vspace blankLines="1" /></t>
</section>
<section title="New registry of PDV types">
<t>This document creates a new registry to be called "RTCP XR PDV
block - PDV type" as a sub-registry of the "RTP Control Protocol
Extended Reports (RTCP XR) Block Type Registry". Policies for this new
registry are as follows:<list style="symbols">
<t>The information required to support an assignment is an
unambiguous definition of the new metric, covering the base
measurements and how they are processed to generate the reported
metric. This should include the units of measurement, how values
of the metric are reported in the three 16-bit fields "Pos PDV
Threshold/Peak", "Neg PDV Threshold/Peak" and "Mean PDV" within
the report block, and how the metric uses the two 16-bit fields
"Pos PDV Percentile" and "Neg PDV Percentile".</t>
<t>The review process for the registry is "Specification Required"
as described in Section 4.1 of <xref target="RFC5226"></xref>.</t>
<t>Entries in the registry are unsigned 4-bit integers. The valid
range is 0 to 15 corresponding to the 4-bit field "pdvtyp" in the
block. Values are to be recorded in decimal.</t>
<t>Initial assignments are as follows:<list>
<t>0: MAPDV2, Clause 6.2.3.2 of <xref
target="G.1020"></xref>,</t>
<t>1: 2-point PDV, Clause 6.2.4 of <xref
target="Y.1540"></xref>,</t>
<t>2-15: Reserved for future use.</t>
</list></t>
</list></t>
</section>
</section>
<section title="Security Considerations">
<t>It is believed that this proposed RTCP XR report block introduces no
new security considerations beyond those described in <xref
target="RFC3611"></xref>. This block does not provide per-packet
statistics so the risk to confidentiality documented in Section 7,
paragraph 3 of <xref target="RFC3611"></xref> does not apply.</t>
</section>
<section title="Contributors">
<t>Geoff Hunt wrote the initial version of this document.</t>
</section>
<section title="Acknowledgments">
<t>The authors gratefully acknowledge reviews and feedback provided by
Bruce Adams, Philip Arden, Amit Arora, Bob Biskner, Kevin Connor, Claus
Dahm, Randy Ethier, Roni Even, Jim Frauenthal, Albert Higashi, Tom Hock,
Shane Holthaus, Paul Jones, Rajesh Kumar, Keith Lantz, Mohamed Mostafa,
Amy Pendleton, Colin Perkins, Mike Ramalho, Ravi Raviraj, Albrecht
Schwarz, Tom Taylor, Hideaki Yamada, Jing Zhao, Kevin Gross, Colin
Perkins, Charles Eckel, Glen Zorn, Shida Schubert, Benoit Claise, Adrian
Farrel and Pete Resnick. </t>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor="RFC2119">
<front>
<title abbrev="RFC Key Words">Key words for use in RFCs to Indicate
Requirement Levels</title>
<author fullname="Scott Bradner" initials="S." surname="Bradner">
<organization>Harvard University</organization>
<address>
<postal>
<street>1350 Mass. Ave.</street>
<street>Cambridge</street>
<street>MA 02138</street>
</postal>
<phone>- +1 617 495 3864</phone>
<email>sob@harvard.edu</email>
</address>
</author>
<date month="March" year="1997" />
<area>General</area>
<keyword>keyword</keyword>
<abstract>
<t>In many standards track documents several words are used to
signify the requirements in the specification. These words are
often capitalized. This document defines these words as they
should be interpreted in IETF documents. Authors who follow these
guidelines should incorporate this phrase near the beginning of
their document: <list>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described
in RFC 2119.</t>
</list></t>
<t>Note that the force of these words is modified by the
requirement level of the document in which they are used.</t>
</abstract>
</front>
</reference>
<reference anchor="G.1020">
<front>
<title>ITU-T Rec. G.1020, Performance parameter definitions for
quality of speech and other voiceband applications utilizing IP
networks</title>
<author initials="" surname="">
<organization>ITU-T</organization>
</author>
<date month="July" year="2006" />
</front>
</reference>
<reference anchor="RFC3611">
<front>
<title>RTP Control Protocol Extended Reports (RTCP XR)</title>
<author fullname="T. Friedman" initials="T." surname="Friedman">
<organization></organization>
</author>
<author fullname="R. Caceres" initials="R." surname="Caceres">
<organization></organization>
</author>
<author fullname="A. Clark" initials="A." surname="Clark">
<organization></organization>
</author>
<date month="November" year="2003" />
<abstract>
<t>This document defines the Extended Report (XR) packet type for
the RTP Control Protocol (RTCP), and defines how the use of XR
packets can be signaled by an application if it employs the
Session Description Protocol (SDP). XR packets are composed of
report blocks, and seven block types are defined here. The purpose
of the extended reporting format is to convey information that
supplements the six statistics that are contained in the report
blocks used by RTCP's Sender Report (SR) and Receiver Report (RR)
packets. Some applications, such as multicast inference of network
characteristics (MINC) or voice over IP (VoIP) monitoring, require
other and more detailed statistics. In addition to the block types
defined here, additional block types may be defined in the future
by adhering to the framework that this document provides.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC4566">
<front>
<title>SDP: Session Description Protocol</title>
<author fullname="M. Handley" initials="M." surname="Handley">
<organization></organization>
</author>
<author fullname="V. Jacobson" initials="V." surname="Jacobson">
<organization></organization>
</author>
<author fullname="C. Perkins" initials="C." surname="Perkins">
<organization></organization>
</author>
<date month="July" year="2006" />
<abstract>
<t>This memo defines the Session Description Protocol (SDP). SDP
is intended for describing multimedia sessions for the purposes of
session announcement, session invitation, and other forms of
multimedia session initiation. [STANDARDS-TRACK]</t>
</abstract>
</front>
</reference>
<reference anchor="RFC5234">
<front>
<title>Augmented BNF for Syntax Specifications: ABNF</title>
<author fullname="D.Crocker" initials="D." surname="Crocker">
<organization></organization>
</author>
<author fullname="P.Overell" initials="P." surname="Overell">
<organization></organization>
</author>
<date month="January" year="2008" />
<abstract>
<t>Internet technical specifications often need to define a formal
syntax. Over the years, a modified version of Backus-Naur Form
(BNF), called Augmented BNF (ABNF), has been popular among many
Internet specifications. The current specification documents ABNF.
It balances compactness and simplicity with reasonable
representational power. The differences between standard BNF and
ABNF involve naming rules, repetition, alternatives, order-
independence, and value ranges. This specification also supplies
additional rule definitions and encoding for a core lexical
analyzer of the type common to several Internet
specifications.</t>
</abstract>
</front>
</reference>
<reference anchor="MEASI">
<front>
<title>Measurement Identity and information Reporting using SDES
item and XR Block</title>
<author fullname="Geoff Hunt" initials="G." surname="Hunt">
<organization></organization>
</author>
<date day="" month="August" year="2012" />
</front>
<seriesInfo name="ID"
value="draft-ietf-xrblock-rtcp-xr-meas-identity-10" />
<format type="TXT" />
</reference>
<reference anchor="RFC3550">
<front>
<title>RTP: A Transport Protocol for Real-Time Applications</title>
<author fullname="Henning Schulzrinne" initials="H."
surname="Schulzrinne">
<organization>Columbia University</organization>
</author>
<date month="July" year="2003" />
</front>
<seriesInfo name="RFC" value="3550" />
<format type="TXT" />
</reference>
<reference anchor="RFC4040">
<front>
<title>RTP Payload Format for a 64 kbit/s Transparent Call</title>
<author fullname="R.,Kreuter" initials="R." surname="Kreuter">
<organization></organization>
</author>
<date month="April" year="2005" />
</front>
</reference>
<reference anchor="RFC5226">
<front>
<title>Guidelines for Writing an IANA Considerations Section in
RFCs</title>
<author fullname="T.,Narten" initials="T." surname="Narten">
<organization></organization>
</author>
<date month="May" year="2008" />
</front>
<annotation>BCP 26</annotation>
</reference>
<reference anchor="Y.1540">
<front>
<title>ITU-T Rec. Y.1540, IP packet transfer and availability
performance parameters</title>
<author fullname="" initials="" surname="">
<organization>ITU-T</organization>
</author>
<date month="November" year="2007" />
</front>
</reference>
</references>
<references title="Informative References">
<reference anchor="MONARCH">
<front>
<title>Monitoring Architectures for RTP</title>
<author fullname="Geoff Hunt" initials="G." surname="Hunt">
<organization></organization>
</author>
<date month="September" year="2012" />
</front>
<seriesInfo name="ID" value="draft-ietf-avtcore-monarch-22" />
<format type="TXT" />
</reference>
<reference anchor="RFC6390">
<front>
<title>Framework for Performance Metric Development</title>
<author fullname="Alan Clark" initials="A." surname="Clark">
<organization></organization>
</author>
<author fullname="Benoit Claise " initials="B." surname="Claise">
<organization></organization>
</author>
<date month="October" year="2011" />
</front>
<seriesInfo name="RFC" value="6390" />
</reference>
<reference anchor="RFC5481">
<front>
<title>Packet Delay Variation Applicability Statement</title>
<author fullname="A. Morton" initials="A." surname="Morton">
<organization></organization>
</author>
<author fullname="Benoit Claise " initials="B." surname="Claise">
<organization></organization>
</author>
<date month="March" year="2009" />
</front>
<seriesInfo name="RFC" value="5481" />
</reference>
</references>
<section title="Change Log">
<t>Note to the RFC-Editor: please remove this section prior to
publication as an RFC.</t>
<section title="draft-ietf-xrblock-rtcp-xr-pdv-08">
<t>The following are the major changes to previous version
draft-ietf-xrblock-rtcp-xr-pdv-07,6: <list style="symbols">
<t>Editorial change based on IESG Review.</t>
</list></t>
</section>
<section title="draft-ietf-xrblock-rtcp-xr-pdv-06">
<t>The following are the major changes to previous version
draft-ietf-xrblock-rtcp-xr-pdv-05: <list style="symbols">
<t>Editorial change based on IESG Review.</t>
<t>SDP element update based on pete's suggestion.</t>
<t>Clarify the value of PDV in the applicability section.</t>
<t>Clarify measurement point and timing in section 3.</t>
</list></t>
</section>
<section title="draft-ietf-xrblock-rtcp-xr-pdv-05">
<t>The following are the major changes to previous version
draft-ietf-xrblock-rtcp-xr-pdv-04: <list style="symbols">
<t>Move Geoff Hunt from author list to Contributors section based
on his suggestion.</t>
</list></t>
</section>
<section title="draft-ietf-xrblock-rtcp-xr-pdv-04">
<t>The following are the major changes to previous version
draft-ietf-xrblock-rtcp-xr-pdv-03: <list style="symbols">
<t>Editorial changes based on Gen-Art Review and Secdir
Review.</t>
</list></t>
</section>
<section title="draft-ietf-xrblock-rtcp-xr-pdv-03">
<t>The following are the major changes to previous version
draft-ietf-xrblock-rtcp-xr-pdv-02: <list style="symbols">
<t>Make definition of pdvtype get alignment with IANA section.</t>
<t>Make Guidance on use of PDV metrics get alignment with
RFC5481.</t>
<t>Other Editorial changes.</t>
</list></t>
</section>
<section title="draft-ietf-xrblock-rtcp-xr-pdv-02">
<t>The following are the major changes to previous version
draft-ietf-xrblock-rtcp-xr-pdv-01: <list style="symbols">
<t>Updated references.</t>
<t>Allocate one more bit for Interval metric flag to indicate
sampled metric can be used.</t>
<t>Add a few clarification text for failure mode.</t>
</list></t>
</section>
<section title="draft-ietf-xrblock-rtcp-xr-pdv-01">
<t>The following are the major changes to previous version
draft-ietf-xrblock-rtcp-xr-pdv-00: <list style="symbols">
<t>Fix typos or nits in the definition of Negative PDV
Threshold/Peak.</t>
<t>Fix nits in Numeric format S7:8.</t>
<t>remove the text that is relevant to tag field.</t>
<t>Add text in SDP signaling section to clarify indicationof
metric unavailable.</t>
</list></t>
</section>
<section title="draft-ietf-xrblock-rtcp-xr-pdv-00">
<t>The following are the major changes to previous version
draft-ietf-avt-rtcp-xr-pdv-03: <list style="symbols">
<t>Updated references.</t>
</list></t>
</section>
<section title="draft-ietf-avt-rtcp-xr-pdv-03">
<t>The following are the major changes to previous version : <list
style="symbols">
<t>Changed BNF for SDP following Christian Groves' and Tom
Taylor's comments (4th and 5th May 2009).</t>
<t>Updated references.</t>
</list></t>
</section>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 01:42:22 |