One document matched: draft-ietf-xrblock-rtcp-xr-pdv-02.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-02.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">RTCP XR Report Block for
Packet Delay Variation Metric Reporting</title>
<author fullname="Geoff Hunt" initials="G." surname="Hunt">
<organization>Unaffiliated</organization>
<address>
<email>r.geoff.hunt@gmail.com</email>
</address>
</author>
<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 month="December" year="2011" />
<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 RTCP XR Report 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
using one of several standard metrics.</t>
<t>The metrics belong to the class of transport metrics defined in
<xref target="MONARCH"></xref> (work in progress).</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 that MUST be used in
accordance 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. Metrics described in this draft either reference external
definitions or define metrics generally in accordance with the
guidelines in <xref target="RFC6390"></xref>.</t>
</section>
<section title="Applicability">
<t>These metrics are applicable to a range of RTP applications.</t>
</section>
</section>
<section title="Definitions">
<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 title="Packet Delay Variation Metrics Block">
<t>Metrics in this block report on packet delay variation in the stream
arriving at the RTP system. Instances of this Metrics Block refer by
SSRC to the separate auxiliary Measurement Information block <xref
target="MEASI"></xref> which contains measurement intervals. This metric
block relies on the measurement interval in the Measurement Information
block indicating the span of the report. If the measurement interval is
not received for this metric block, this metric block should 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 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BT=NPDV | I |pdvtyp |Rsv| block length=3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of Source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pos PDV Threshold/Peak | Pos PDV Percentile |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neg PDV Threshold/Peak | Neg PDV Percentile |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mean PDV | unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</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 Basic
Loss/Discard metrics are Sampled, Interval or Cumulative metrics,
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 to the value of a continuously measured or calculated
that has been sampled at end of the interval (I=01) (Sampled
Value). <vspace blankLines="1" /></t>
<t
hangText="Packet Delay Variation Metric Type (pdvtyp): 4 bits"><vspace
blankLines="1" />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-017<list>
<t>0: interarrival jitter, Section 6.4.1 of <xref
target="RFC3550"></xref>,</t>
<t>1: MAPDV2, Clause 6.2.3.2 of <xref
target="G.1020"></xref>,</t>
<t>2: 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 MUST be
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
3.<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 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 SHOULD 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 SHOULD 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 SHOULD 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 SHOULD 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 interarrival jitter, the
value reported is the value of J(i) calculated according to
[RFC3550] at the time the report is generated.<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
SHOULD be reported.<vspace blankLines="1" /></t>
<t hangText="Unused: 16 bits"><vspace blankLines="1" /> These bits
are unused. They SHOULD be set to zero by the sender and MUST be
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>Interarrival jitter (Section 6.4.1 of <xref
target="RFC3550"></xref>) allows comparison of results with those from
RTP end systems which support only RTCP as defined in <xref
target="RFC3550"></xref>.</t>
<t>MAPDV2 (Clause 6.2.3.2 of <xref target="G.1020"></xref>) compares
instantaneous (per- packet) delay variation against a moving average
delay variation. 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 the adaptive
de-jitter buffer have similar averaging behaviour as 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 the time of arrival of
the first packet of the connection. 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> if the packet index i
is set equal to 1, that is, the reference packet for the metric is the
first packet of the connection. 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 synchronisation is
distributed. As well as measuring packet delay variation in such
networks, it may be used to ensure that synchronisation 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>(a) To report interarrival jitter <xref
target="RFC3550"></xref>:<list>
<t>PDV Threshold = FFFF (Undefined); PDV Percentile = FFFF
(Undefined); PDV type = 0 (interarrival jitter)</t>
<t>causes interarrival jitter to be reported in the Mean PDV
field.</t>
</list></t>
<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 = 1 (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>
<t>2-point PDV, according to <xref target="Y.1540"></xref> is
the difference in delay between the current packet and the
first 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>
rtcp-xr-attrib = "a=" "rtcp-xr" ":" [xr-format *(SP xr-format)] CRLF
(defined in [RFC3611])
xr-format =/ xr-pdv-block
xr-pdv-block = "pkt-dly-var" [ "," pdvtype ] [ "," nspec "," pspec ]
pdvtype = "pdv=" 0 ; interarrival jitter RFC 3550
/ 1 ; MAPDV2 ITU-T G.1020
/ 2 ; 2-point PDV ITU-T Y.1540
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 = %x30-39
</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 SHOULD 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 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 style="numbers">
<t>interarrival jitter, Section 6.4.1 of <xref
target="RFC3550"></xref>,</t>
<t>MAPDV2, Clause 6.2.3.2 of <xref
target="G.1020"></xref>,</t>
<t>2-point PDV, Clause 6.2.4 of <xref
target="Y.1540"></xref></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>
</middle>
<back>
<references title="Normative References">
<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="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="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="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="August" year="2011" />
</front>
<seriesInfo name="ID" value="draft-ietf-avtcore-monarch-04" />
<format type="TXT" />
</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 month="October" year="2011" />
</front>
<seriesInfo name="ID"
value="draft-ietf-xrblock-rtcp-xr-measu-identity-01" />
<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>
</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-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 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-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-02">
<t>The following are the major changes to previous version
draft-ietf-xrblock-rtcp-xr-pdv-00 : <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>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 05:52:13 |