pkt-loss-rle 1 Loss RLE Report Block
pkt-dup-rle 2 Duplicate RLE Report Block
pkt-rcpt-times 3 Packet Receipt Times Report Block
stat-summary 6 Statistics Summary Report Block
voip-metrics 7 VoIP Metrics Report Block
The "pkt-loss-rle", "pkt-dup-rle", and "pkt-rcpt-times" parameters
MAY specify an integer value. This value indicates the largest size
the whole report block SHOULD have in octets. This shall be seen as
an indication that thinning shall be applied if necessary to meet the
target size.
The "stat-summary" parameter contains a list indicating which fields
SHOULD be included in the Statistics Summary report blocks that are
sent. The list is a comma separated list, containing one or more
field indicators. The space character (0x20) SHALL NOT be present
within the list. Field indicators represent the flags defined in
Section 4.6. The field indicators and their respective flags are as
follows:
Indicator Flag
--------- ---------------------------
loss loss report flag (L)
dup duplicate report flag (D)
jitt jitter flag (J)
TTL TTL or Hop Limit flag (ToH)
HL TTL or Hop Limit flag (ToH)
For "loss", "dup", and "jitt", the presence of the indicator
indicates that the corresponding flag should be set to 1 in the
Statistics Summary report blocks that are sent. The presence of
"TTL" indicates that the corresponding flag should be set to 1. The
presence of "HL" indicates that the corresponding flag should be set
to 2. The indicators "TTL" and "HL" MUST NOT be signaled together.
Blocks in the collaborative category are classified as initiator
blocks or response blocks. Signaling SHOULD indicate which
participants are required to respond to the initiator block. A party
that wishes to receive response blocks from those participants can
trigger this by sending an initiator block.
The collaborative category currently consists only of one
functionality, namely the RTT measurement mechanism for RTP data
receivers. The collective functionality of the Receiver Reference
Time Report Block and DLRR Report Block is represented by the "rcvr-
rtt" parameter. This parameter takes as its arguments a mode value
and, optionally, a maximum size for the DLRR report block. The mode
value "all" indicates that both RTP data senders and data receivers
MAY send DLRR blocks, while the mode value "sender" indicates that
only active RTP senders MAY send DLRR blocks, i.e., non RTP senders
SHALL NOT send DLRR blocks. If a maximum size in octets is included,
any DLRR Report Blocks that are sent SHALL NOT exceed the specified
size. If size limitations mean that a DLRR Report Block sender
cannot report in one block upon all participants from which it has
received a Receiver Reference Time Report Block then it SHOULD report
on participants in a round robin fashion across several report
intervals.
The "rtcp-xr" attributes parameter list MAY be empty. This is useful
in cases in which an application needs to signal that it understands
the SDP signaling but does not wish to avail itself of XR
functionality. For example, an application in a SIP controlled
session could signal that it wishes to stop using all XR blocks by
removing all applicable SDP parameters in a re-INVITE message that it
sends. If XR blocks are not to be used at all from the beginning of
a session, it is RECOMMENDED that the "rtcp-xr" attribute not be
supplied at all.
When the "rtcp-xr" attribute is present, participants SHOULD NOT send
XR blocks other than the ones indicated by the parameters. This
means that inclusion of a "rtcp-xr" attribute without any parameters
tells a participant that it SHOULD NOT send any XR blocks at all.
The purpose is to conserve bandwidth. This is especially important
when collaborative parameters are applied to a large multicast group:
the sending of an initiator block could potentially trigger responses
from all participants. There are, however, contexts in which it
makes sense to send an XR block in the absence of a parameter
signaling its use. For instance, an application might be designed so
as to send certain report blocks without negotiation, while using SDP
signaling to negotiate the use of other blocks.
5.2. Usage in Offer/Answer
In the Offer/Answer context [8], the interpretation of SDP signaling
for XR packets depends upon the direction attribute that is signaled:
"recvonly", "sendrecv", or "sendonly" [4]. If no direction attribute
is supplied, then "sendrecv" is assumed. This section applies only
to unicast media streams, except where noted. Discussion of
unilateral parameters is followed by discussion of collaborative
parameters in this section.
For "sendonly" and "sendrecv" media stream offers that specify
unilateral "rtcp-xr" attribute parameters, the answerer SHOULD send
the corresponding XR blocks. For "sendrecv" offers, the answerer MAY
include the "rtcp-xr" attribute in its response, and specify any
unilateral parameters in order to request that the offerer send the
corresponding XR blocks. The offerer SHOULD send these blocks.
For "recvonly" media stream offers, the offerer’s use of the "rtcp-
xr" attribute in connection with unilateral parameters indicates that
the offerer is capable of sending the corresponding XR blocks. If
the answerer responds with an "rtcp-xr" attribute, the offerer SHOULD
send XR blocks for each specified unilateral parameter that was in
its offer.
For multicast media streams, the inclusion of an "rtcp-xr" attribute
with unilateral parameters means that every media recipient SHOULD
send the corresponding XR blocks.
An SDP offer with a collaborative parameter declares the offerer
capable of receiving the corresponding initiator and replying with
the appropriate responses. For example, an offer that specifies the
"rcvr-rtt" parameter means that the offerer is prepared to receive
Receiver Reference Time Report Blocks and to send DLRR Report Blocks.
An offer of a collaborative parameter means that the answerer MAY
send the initiator, and, having received the initiator, the offerer
SHOULD send the responses.
There are exceptions to the rule that an offerer of a collaborative
parameter should send responses. For instance, the collaborative
parameter might specify a mode that excludes the offerer; or
congestion control or maximum transmission unit considerations might
militate against the offerer’s response.
By including a collaborative parameter in its answer, the answerer
declares its ability to receive initiators and to send responses.
The offerer MAY then send initiators, to which the answerer SHOULD
reply with responses. As for the offer of a collaborative parameter,
there are exceptions to the rule that the answerer should reply.
When making an SDP offer of a collaborative parameter for a multicast
media stream, the offerer SHOULD specify which participants are to
respond to a received initiator. A participant that is not specified
SHOULD NOT send responses. Otherwise, undue bandwidth might be
consumed. The offer indicates that each participant that is
specified SHOULD respond if it receives an initiator. It also
indicates that a specified participant MAY send an initiator block.
An SDP answer for a multicast media stream SHOULD include all
collaborative parameters that are present in the offer and that are
supported by the answerer. It SHOULD NOT include any collaborative
parameter that is absent from the offer.
If a participant receives an SDP offer and understands the "rtcp-xr"
attribute but does not wish to implement XR functionality offered,
its answer SHOULD include an "rtcp-xr" attribute without parameters.
By doing so, the party declares that, at a minimum, is capable of
understanding the signaling.
5.3. Usage Outside of Offer/Answer
SDP can be employed outside of the Offer/Answer context, for instance
for multimedia sessions that are announced through the Session
Announcement Protocol (SAP) [15], or streamed through the Real Time
Streaming Protocol (RTSP) [17]. The signaling model is simpler, as
the sender does not negotiate parameters, but the functionality
expected from specifying the "rtcp-xr" attribute is the same as in
Offer/Answer.
When a unilateral parameter is specified for the "rtcp-xr" attribute
associated with a media stream, the receiver of that stream SHOULD
send the corresponding XR block. When a collaborative parameter is
specified, only the participants indicated by the mode value in the
collaborative parameter are concerned. Each such participant that
receives an initiator block SHOULD send the corresponding response
block. Each such participant MAY also send initiator blocks.
6. IANA Considerations
This document defines a new RTCP packet type, the Extended Report
(XR) type, within the existing Internet Assigned Numbers Authority
(IANA) registry of RTP RTCP Control Packet Types. This document also
defines a new IANA registry: the registry of RTCP XR Block Types.
Within this new registry, this document defines an initial set of
seven block types and describes how the remaining types are to be
allocated.
Further, this document defines a new SDP attribute, "rtcp-xr", within
the existing IANA registry of SDP Parameters. It defines a new IANA
registry, the registry of RTCP XR SDP Parameters, and an initial set
of six parameters, and describes how additional parameters are to be
allocated.
6.1. XR Packet Type
The XR packet type defined by this document is registered with the
IANA as packet type 207 in the registry of RTP RTCP Control Packet
types (PT).
6.2. RTCP XR Block Type Registry
This document creates an IANA registry called the RTCP XR Block Type
Registry to cover the name space of the Extended Report block type
(BT) field specified in Section 3. The BT field contains eight bits,
allowing 256 values. The RTCP XR Block Type Registry is to be
managed by the IANA according to the Specification Required policy of
RFC 2434 [7]. Future specifications SHOULD attribute block type
values in strict numeric order following the values attributed in
this document:
BT name
-- ----
1 Loss RLE Report Block
2 Duplicate RLE Report Block
3 Packet Receipt Times Report Block
4 Receiver Reference Time Report Block
5 DLRR Report Block
6 Statistics Summary Report Block
7 VoIP Metrics Report Block
The BT value 255 is reserved for future extensions.
Furthermore, future specifications SHOULD avoid the value 0. Doing
so facilitates packet validity checking, since an all-zeros field
might commonly be found in an ill-formed packet.
Any registration MUST contain the following information:
- Contact information of the one doing the registration, including
at least name, address, and email.
- The format of the block type being registered, consistent with the
extended report block format described in Section 3.
- A description of what the block type represents and how it shall
be interpreted, detailing this information for each of its fields.
6.3. The "rtcp-xr" SDP Attribute
The SDP attribute "rtcp-xr" defined by this document is registered
with the IANA registry of SDP Parameters as follows:
SDP Attribute ("att-field"):
Attribute name: rtcp-xr
Long form: RTP Control Protocol Extended Report Parameters
Type of name: att-field
Type of attribute: session and media level
Subject to charset: no
Purpose: see Section 5 of this document
Reference: this document
Values: see this document and registrations below
The attribute has an extensible parameter field and therefore a
registry for these parameters is required. This document creates an
IANA registry called the RTCP XR SDP Parameters Registry. It
contains the six parameters defined in Section 5.1: "pkt-loss-rle",
"pkt-dup-rle", "pkt-rcpt-times", "stat-summary", "voip-metrics", and
"recv-rtt".
Additional parameters are to be added to this registry in accordance
with the Specification Required policy of RFC 2434 [7]. Any
registration MUST contain the following information:
- Contact information of the one doing the registration, including
at least name, address, and email.
- An Augmented Backus-Naur Form (ABNF) [2] definition of the
parameter, in accordance with the "format-ext" definition of
Section 5.1.
- A description of what the parameter represents and how it shall be
interpreted, both normally and in Offer/Answer.
7. Security Considerations
This document extends the RTCP reporting mechanism. The security
considerations that apply to RTCP reports [9, Appendix B] also apply
to XR reports. This section details the additional security
considerations that apply to the extensions.
The extensions introduce heightened confidentiality concerns.
Standard RTCP reports contain a limited number of summary statistics.
The information contained in XR reports is both more detailed and
more extensive (covering a larger number of parameters). The per-
packet report blocks and the VoIP Metrics Report Block provide
examples.
The per-packet information contained in Loss RLE, Duplicate RLE, and
Packet Receipt Times Report Blocks facilitates multicast inference of
network characteristics (MINC) [11]. Such inference can reveal the
gross topology of a multicast distribution tree, as well as
parameters, such as the loss rates and delays, along paths between
branching points in that tree. Such information might be considered
sensitive to autonomous system administrators.
The VoIP Metrics Report Block provides information on the quality of
ongoing voice calls. Though such information might be carried in an
application specific format in standard RTP sessions, making it
available in a standard format here makes it more available to
potential eavesdroppers.
No new mechanisms are introduced in this document to ensure
confidentiality. Encryption procedures, such as those being
suggested for a Secure RTCP (SRTCP) [12] at the time that this
document was written, can be used when confidentiality is a concern
to end hosts. Given that RTCP traffic can be encrypted by the end
hosts, autonomous systems must be prepared for the fact that certain
aspects of their network topology can be revealed.
Any encryption or filtering of XR report blocks entails a loss of
monitoring information to third parties. For example, a network that
establishes a tunnel to encrypt VoIP Report Blocks denies that
information to the service providers traversed by the tunnel. The
service providers cannot then monitor or respond to the quality of
the VoIP calls that they carry, potentially creating problems for the
network’s users. As a default, XR packets should not be encrypted or
filtered.
The extensions also make certain denial of service attacks easier.
This is because of the potential to create RTCP packets much larger
than average with the per packet reporting capabilities of the Loss
RLE, Duplicate RLE, and Timestamp Report Blocks. Because of the
automatic bandwidth adjustment mechanisms in RTCP, if some session
participants are sending large RTCP packets, all participants will
see their RTCP reporting intervals lengthened, meaning they will be
able to report less frequently. To limit the effects of large
packets, even in the absence of denial of service attacks,
applications SHOULD place an upper limit on the size of the XR report
blocks they employ. The "thinning" techniques described in Section
4.1 permit the packet-by-packet report blocks to adhere to a
predefined size limit.
A. Algorithms
A.1. Sequence Number Interpretation
This is the algorithm suggested by Section 4.1 for keeping track of
the sequence numbers from a given sender. It implements the
accounting practice required for the generation of Loss RLE Report
Blocks.
This algorithm keeps track of 16 bit sequence numbers by translating
them into a 32 bit sequence number space. The first packet received
from a source is considered to have arrived roughly in the middle of
that space. Each packet that follows is placed either ahead of or
behind the prior one in this 32 bit space, depending upon which
choice would place it closer (or, in the event of a tie, which choice
would not require a rollover in the 16 bit sequence number).
// The reference sequence number is an extended sequence number
// that serves as the basis for determining whether a new 16 bit
// sequence number comes earlier or later in the 32 bit sequence
// space.
u_int32 _src_ref_seq;
bool _uninitialized_src_ref_seq;
// Place seq into a 32-bit sequence number space based upon a
// heuristic for its most likely location.
u_int32 extend_seq(const u_int16 seq) {
u_int32 extended_seq, seq_a, seq_b, diff_a, diff_b;
if(_uninitialized_src_ref_seq) {
// This is the first sequence number received. Place
// it in the middle of the extended sequence number
// space.
_src_ref_seq = seq | 0x80000000u;
_uninitialized_src_ref_seq = false;
extended_seq = _src_ref_seq;
}
else {
// Prior sequence numbers have been received.
// Propose two candidates for the extended sequence
// number: seq_a is without wraparound, seq_b with
// wraparound.
seq_a = seq | (_src_ref_seq & 0xFFFF0000u);
if(_src_ref_seq < seq_a) {
seq_b = seq_a - 0x00010000u;
diff_a = seq_a - _src_ref_seq;
diff_b = _src_ref_seq - seq_b;
}
else {
seq_b = seq_a + 0x00010000u;
diff_a = _src_ref_seq - seq_a;
diff_b = seq_b - _src_ref_seq;
}
// Choose the closer candidate. If they are equally
// close, the choice is somewhat arbitrary: we choose
// the candidate for which no rollover is necessary.
if(diff_a < diff_b) {
extended_seq = seq_a;
}
else {
extended_seq = seq_b;
}
// Set the reference sequence number to be this most
// recently-received sequence number.
_src_ref_seq = extended_seq;
}
// Return our best guess for a 32-bit sequence number that
// corresponds to the 16-bit number we were given.
return extended_seq;
}
A.2. Example Burst Packet Loss Calculation.
This is an algorithm for measuring the burst characteristics for the
VoIP Metrics Report Block (Section 4.7). The algorithm, which has
been verified against a working implementation for correctness, is
reproduced from ETSI TS 101 329-5 [3]. The algorithm, as described
here, takes precedence over any change that might eventually be made
to the algorithm in future ETSI documents.
This algorithm is event driven and hence extremely computationally
efficient.
Given the following definition of states:
state 1 = received a packet during a gap
state 2 = received a packet during a burst
state 3 = lost a packet during a burst
state 4 = lost an isolated packet during a gap
The "c" variables below correspond to state transition counts, i.e.,
c14 is the transition from state 1 to state 4. It is possible to
infer one of a pair of state transition counts to an accuracy of 1
which is generally sufficient for this application.
"pkt" is the count of packets received since the last packet was
declared lost or discarded, and "lost" is the number of packets lost
within the current burst. "packet_lost" and "packet_discarded" are
Boolean variables that indicate if the event that resulted in this
function being invoked was a lost or discarded packet.
if(packet_lost) {
loss_count++;
}
if(packet_discarded) {
discard_count++;
}
if(!packet_lost && !packet_discarded) {
pkt++;
}
else {
if(pkt >= gmin) {
if(lost == 1) {
c14++;
}
else {
c13++;
}
lost = 1;
c11 += pkt;
}
else {
lost++;
if(pkt == 0) {
c33++;
}
else {
c23++;
c22 += (pkt - 1);
}
}
pkt = 0;
}
At each reporting interval the burst and gap metrics can be
calculated as follows.
// Calculate additional transition counts.
c31 = c13;
c32 = c23;
ctotal = c11 + c14 + c13 + c22 + c23 + c31 + c32 + c33;
// Calculate burst and densities.
p32 = c32 / (c31 + c32 + c33);
if((c22 + c23) < 1) {
p23 = 1;
}
else {
p23 = 1 - c22/(c22 + c23);
}
burst_density = 256 * p23 / (p23 + p32);
gap_density = 256 * c14 / (c11 + c14);
// Calculate burst and gap durations in ms
m = frameDuration_in_ms * framesPerRTPPkt;
gap_length = (c11 + c14 + c13) * m / c13;
burst_length = ctotal * m / c13 - lgap;