accuracy in reporting on observed events over interpretation of those
events whenever possible. Interpretation should be left to those who
observe the report blocks. Following this approach implies that
accounting for Loss RLE Report Blocks will differ from the accounting
for the generation of the SR and RR packets described in the RTP
specification [9] in the following two areas: per-sender accounting
and per-packet accounting.
In its per-sender accounting, an RTP session participant SHOULD NOT
make the receipt of a threshold minimum number of RTP packets a
condition for reporting upon the sender of those packets. This
accounting technique differs from the technique described in Section
6.2.1 and Appendix A.1 of the RTP specification that allows a
threshold to determine whether a sender is considered valid.
In its per-packet accounting, an RTP session participant SHOULD treat
all sequence numbers as valid. This accounting technique differs
from the technique described in Appendix A.1 of the RTP specification
that suggests ruling a sequence number valid or invalid on the basis
of its contiguity with the sequence numbers of previously received
packets.
Sender validity and sequence number validity are interpretations of
the raw data. Such interpretations are justified in the interest,
for example, of excluding the stray old packet from an unrelated
session from having an effect upon the calculation of the RTCP
transmission interval. The presence of stray packets might, on the
other hand, be of interest to a network monitoring application.
One accounting interpretation that is still necessary is for a
participant to decide whether the 16 bit sequence number has rolled
over. Under ordinary circumstances this is not a difficult task.
For example, if packet number 65,535 (the highest possible sequence
number) is followed shortly by packet number 0, it is reasonable to
assume that there has been a rollover. However, it is possible that
the packet is an earlier one (from 65,535 packets earlier). It is
also possible that the sequence numbers have rolled over multiple
times, either forward or backward. The interpretation becomes more
difficult when there are large gaps between the sequence numbers,
even accounting for rollover, and when there are long intervals
between received packets.
The per-packet accounting technique mandated here is for a
participant to keep track of the sequence number of the packet most
recently received from a sender. For the next packet that arrives
from that sender, the sequence number MUST be judged to fall no more
than 32,768 packets ahead or behind the most recent one, whichever
choice places it closer. In the event that both choices are equally
distant (only possible when the distance is 32,768), the choice MUST
be the one that does not require a rollover. Appendix A.1 presents
an algorithm that implements this technique.
Each block reports on a single RTP data packet source, identified by
its SSRC. The receiver that is supplying the report is identified in
the header of the RTCP packet.
Choice of beginning and ending RTP packet sequence numbers for the
trace is left to the application. These values are reported in the
block. The last sequence number in the trace MAY differ from the
sequence number reported on in any accompanying SR or RR report.
Note that because of sequence number wraparound, the ending sequence
number MAY be less than the beginning sequence number. A Loss RLE
Report Block MUST NOT be used to report upon a range of 65,534 or
greater in the sequence number space, as there is no means of
identifying multiple wraparounds.
The trace described by a Loss RLE report consists of a sequence of
Boolean values, one for each sequence number of the trace. A value
of one represents a packet receipt, meaning that one or more packets
having that sequence number have been received since the most recent
wraparound of sequence numbers (or since the beginning of the RTP
session if no wraparound has been judged to have occurred). A value
of zero represents a packet loss, meaning that there has been no
packet receipt for that sequence number as of the time of the report.
If a packet with a given sequence number is received after a report
of a loss for that sequence number, a later Loss RLE report MAY
report a packet receipt for that sequence number.
The encoding itself consists of a series of 16 bit units called
chunks that describe sequences of packet receipts or losses in the
trace. Each chunk either specifies a run length or a bit vector, or
is a null chunk. A run length describes between 1 and 16,383 events
that are all the same (either all receipts or all losses). A bit
vector describes 15 events that may be mixed receipts and losses. A
null chunk describes no events, and is used to round out the block to
a 32 bit word boundary.
The mapping from a sequence of lost and received packets into a
sequence of chunks is not necessarily unique. For example, the
following trace covers 45 packets, of which the 22nd and 24th have
been lost and the others received:
1111 1111 1111 1111 1111 1010 1111 1111 1111 1111 1111 1
One way to encode this would be:
bit vector 1111 1111 1111 111
bit vector 1111 1101 0111 111
bit vector 1111 1111 1111 111
null chunk
Another way to encode this would be:
run of 21 receipts
bit vector 0101 1111 1111 111
run of 9 receipts
null chunk
The choice of encoding is left to the application. As part of this
freedom of choice, applications MAY terminate a series of run length
and bit vector chunks with a bit vector chunk that runs beyond the
sequence number space described by the report block. For example, if
the 44th packet in the same sequence was lost:
1111 1111 1111 1111 1111 1010 1111 1111 1111 1111 1110 1
This could be encoded as:
run of 21 receipts
bit vector 0101 1111 1111 111
bit vector 1111 1110 1000 000
null chunk
In this example, the last five bits of the second bit vector describe
a part of the sequence number space that extends beyond the last
sequence number in the trace. These bits have been set to zero.
All bits in a bit vector chunk that describe a part of the sequence
number space that extends beyond the last sequence number in the
trace MUST be set to zero, and MUST be ignored by the receiver.
A null packet MUST appear at the end of a Loss RLE Report Block if
the number of run length plus bit vector chunks is odd. The null
chunk MUST NOT appear in any other context.
Caution should be used in sending Loss RLE Report Blocks because,
even with the compression provided by run length encoding, they can
easily consume bandwidth out of proportion with normal RTCP packets.
The block type includes a mechanism, called thinning, that allows an
application to limit report sizes.
A thinning value, T, selects a subset of packets within the sequence
number space: those with sequence numbers that are multiples of 2^T.
Packet reception and loss reports apply only to those packets. T can
vary between 0 and 15. If T is zero, then every packet in the
sequence number space is reported upon. If T is fifteen, then one in
every 32,768 packets is reported upon.
Suppose that the trace just described begins at sequence number
13,821. The last sequence number in the trace is 13,865. If the
trace were to be thinned with a thinning value of T=2, then the
following sequence numbers would be reported upon: 13,824, 13,828,
13,832, 13,836, 13,840, 13,844, 13,848, 13,852, 13,856, 13,860,
13,864. The thinned trace would be as follows:
1 1 1 1 1 0 1 1 1 1 0
This could be encoded as follows:
bit vector 1111 1011 1100 000
null chunk
The last four bits in the bit vector, representing sequence numbers
13,868, 13,872, 13,876, and 13,880, extend beyond the trace and are
thus set to zero and are ignored by the receiver. With thinning, the
loss of the 22nd packet goes unreported because its sequence number,
13,842, is not a multiple of four. Packet receipts for all sequence
numbers that are not multiples of four also go unreported. However,
in this example thinning has permitted the Loss RLE Report Block to
be shortened by one 32 bit word.
Choice of the thinning value is left to the application.
The Loss RLE Report Block has the following format:
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=1 | rsvd. | T | block length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| begin_seq | end_seq |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| chunk 1 | chunk 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| chunk n-1 | chunk n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
block type (BT): 8 bits
A Loss RLE Report Block is identified by the constant 1.
rsvd.: 4 bits
This field is reserved for future definition. In the absence
of such definition, the bits in this field MUST be set to zero
and MUST be ignored by the receiver.
thinning (T): 4 bits
The amount of thinning performed on the sequence number space.
Only those packets with sequence numbers 0 mod 2^T are reported
on by this block. A value of 0 indicates that there is no
thinning, and all packets are reported on. The maximum
thinning is one packet in every 32,768 (amounting to two
packets within each 16-bit sequence space).
block length: 16 bits
Defined in Section 3.
SSRC of source: 32 bits
The SSRC of the RTP data packet source being reported upon by
this report block.
begin_seq: 16 bits
The first sequence number that this block reports on.
end_seq: 16 bits
The last sequence number that this block reports on plus one.
chunk i: 16 bits
There are three chunk types: run length, bit vector, and
terminating null, defined in the following sections. If the
chunk is all zeroes, then it is a terminating null chunk.
Otherwise, the left most bit of the chunk determines its type:
0 for run length and 1 for bit vector.
4.1.1. Run Length Chunk
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C|R| run length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
chunk type (C): 1 bit
A zero identifies this as a run length chunk.
run type (R): 1 bit
Zero indicates a run of 0s. One indicates a run of 1s.
run length: 14 bits
A value between 1 and 16,383. The value MUST not be zero for a
run length chunk (zeroes in both the run type and run length
fields would make the chunk a terminating null chunk). Run
lengths of 15 or less MAY be described with a run length chunk
despite the fact that they could also be described as part of a
bit vector chunk.
4.1.2. Bit Vector Chunk
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C| bit vector |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
chunk type (C): 1 bit
A one identifies this as a bit vector chunk.
bit vector: 15 bits
The vector is read from left to right, in order of increasing
sequence number (with the appropriate allowance for
wraparound).
4.1.3. Terminating Null Chunk
This chunk is all zeroes.
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.2. Duplicate RLE Report Block
This block type permits per-sequence-number reports on duplicates in
a source’s RTP packet stream. Such information can be used for
network diagnosis, and provide an alternative to packet losses as a
basis for multicast tree topology inference.
The Duplicate RLE Report Block format is identical to the Loss RLE
Report Block format. Only the interpretation is different, in that
the information concerns packet duplicates rather than packet losses.
The trace to be encoded in this case also consists of zeros and ones,
but a zero here indicates the presence of duplicate packets for a
given sequence number, whereas a one indicates that no duplicates
were received.
The existence of a duplicate for a given sequence number is
determined over the entire reporting period. For example, if packet
number 12,593 arrives, followed by other packets with other sequence
numbers, the arrival later in the reporting period of another packet
numbered 12,593 counts as a duplicate for that sequence number. The
duplicate does not need to follow immediately upon the first packet
of that number. Care must be taken that a report does not cover a
range of 65,534 or greater in the sequence number space.
No distinction is made between the existence of a single duplicate
packet and multiple duplicate packets for a given sequence number.
Note also that since there is no duplicate for a lost packet, a loss
is encoded as a one in a Duplicate RLE Report Block.
The Duplicate RLE Report Block has the following format:
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=2 | rsvd. | T | block length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| begin_seq | end_seq |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| chunk 1 | chunk 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| chunk n-1 | chunk n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
block type (BT): 8 bits
A Duplicate RLE Report Block is identified by the constant 2.
rsvd.: 4 bits
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.
thinning (T): 4 bits
As defined in Section 4.1.
block length: 16 bits
Defined in Section 3.
SSRC of source: 32 bits
As defined in Section 4.1.
begin_seq: 16 bits
As defined in Section 4.1.
end_seq: 16 bits
As defined in Section 4.1.
chunk i: 16 bits
As defined in Section 4.1.
4.3. Packet Receipt Times Report Block
This block type permits per-sequence-number reports on packet receipt
times for a given source’s RTP packet stream. Such information can
be used for MINC inference of the topology of the multicast tree used
to distribute the source’s RTP packets, and of the delays along the
links within that tree. It can also be used to measure partial path
characteristics and to model distributions for packet jitter.
Packet receipt times are expressed in the same units as in the RTP
timestamps of data packets. This is so that, for each packet, one
can establish both the send time and the receipt time in comparable
terms. Note, however, that as an RTP sender ordinarily initializes
its time to a value chosen at random, there can be no expectation
that reported send and receipt times will differ by an amount equal
to the one-way delay between sender and receiver. The reported times
can nonetheless be useful for the purposes mentioned above.
At least one packet MUST have been received for each sequence number
reported upon in this block. If this block type is used to report
receipt times for a series of sequence numbers that includes lost
packets, several blocks are required. If duplicate packets have been
received for a given sequence number, and those packets differ in
their receipt times, any time other than the earliest MUST NOT be
reported. This is to ensure consistency among reports.
Times reported in RTP timestamp format consume more bits than loss or
duplicate information, and do not lend themselves to run length
encoding. The use of thinning is encouraged to limit the size of
Packet Receipt Times Report Blocks.
The Packet Receipt Times Report Block has the following format:
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=3 | rsvd. | T | block length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| begin_seq | end_seq |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receipt time of packet begin_seq |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receipt time of packet (begin_seq + 1) mod 65536 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receipt time of packet (end_seq - 1) mod 65536 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
block type (BT): 8 bits
A Packet Receipt Times Report Block is identified by the
constant 3.
rsvd.: 4 bits
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.
thinning (T): 4 bits
As defined in Section 4.1.
block length: 16 bits
Defined in Section 3.
SSRC of source: 32 bits
As defined in Section 4.1.
begin_seq: 16 bits
As defined in Section 4.1.
end_seq: 16 bits
As defined in Section 4.1.
Packet i receipt time: 32 bits
The receipt time of the packet with sequence number i at the
receiver. The modular arithmetic shown in the packet format
diagram is to allow for sequence number rollover. It is
preferable for the time value to be established at the link
layer interface, or in any case as close as possible to the
wire arrival time. Units and format are the same as for the
timestamp in RTP data packets. As opposed to RTP data packet
timestamps, in which nominal values may be used instead of
system clock values in order to convey information useful for
periodic playout, the receipt times should reflect the actual
time as closely as possible. For a session, if the RTP
timestamp is chosen at random, the first receipt time value
SHOULD also be chosen at random, and subsequent timestamps
offset from this value. On the other hand, if the RTP
timestamp is meant to reflect the reference time at the sender,
then the receipt time SHOULD be as close as possible to the
reference time at the receiver.
4.4. Receiver Reference Time Report Block
This block extends RTCP’s timestamp reporting so that non-senders may
also send timestamps. It recapitulates the NTP timestamp fields from
the RTCP Sender Report [9, Sec. 6.3.1]. A non-sender may estimate
its round trip time (RTT) to other participants, as proposed in [18],
by sending this report block and receiving DLRR Report Blocks (see
next section) in reply.
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=4 | reserved | block length = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NTP timestamp, most significant word |