Internet DRAFT - draft-friedman-avt-rtcp-report-extns
draft-friedman-avt-rtcp-report-extns
Internet Engineering Task Force Audio/Video Transport Working Group
Internet Draft Timur Friedman, UMass Amherst
13 July 2000 Ramon Caceres, AT&T Labs
Expires 13 January 2001 Kevin Almeroth, UCSB
Kamil Sarac, UCSB
RTCP Reporting Extensions
draft-friedman-avt-rtcp-report-extns-01.txt
Status of this Memo
This document is an Internet Draft and is in full conformance with
all provisions of section 10 of RFC2026. Internet Drafts are
working documents of the Internet Engineering Task Force (IETF), its
areas, and its working groups. Note that other groups may also
distribute working documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six
months. Internet Drafts may be updated, replaced, or made obsolete
by other documents at any time. It is not appropriate to use
Internet Drafts as reference material or to cite them other than as a
"working draft" or "work in progress."
The list of current Internet Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) The Internet Society (2000). All Rights Reserved.
Abstract
This document defines a format for extensions to the RTCP SR (sender
report) and RR (receiver report) packets that are defined in the RTP
specification. Within their "reception report blocks", SR and RR
packets are limited to reporting six specified statistics on any
given data source. This document describes how other information can
be reported in "extended report blocks" that are stacked at the end
of an SR or RR packet. Some specific block formats are provided
here. For other formats that may be defined as the need arises, this
document specifies a simple framework that they must adhere to.
Friedman, Caceres, Almeroth, and Sarac [Page 1]
draft-friedman-avt-rtcp-report-extns-01.txt 13 July 2000
1. Introduction
This document defines extended report blocks for RTCP, the control
portion of RTP [5].
These blocks convey information over and above that which is already
contained in the reception report blocks of RTCP's SR or RR packets.
For example, while a reception report block has an average loss rate
field, an application might opt to use an extended report block that
details exactly which packets were received and which were lost.
The framework for these blocks is minimal: just a type field and a
length field are required. Purpose being to maintain flexibility and
to keep overhead low. Some specific block formats are provided here,
and others may be defined as the need arises.
1.1 Terminology
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 BCP 14 [2] and
indicate requirement levels for compliant RTP implementations.
2. Extended Report Block Framework
The RTP specification provides for profile-specific extensions to
RTCP's SR and RR packets. This document defines a basic framework
for those extensions, and so constitutes a reporting profile for RTP.
Extended report blocks MUST be stacked, one after the other, at the
end of an SR or RR packet, in the portion reserved for profile-
specific extensions. An individual block's length MUST be a multiple
of 4 octets. The SR or RR header's length field MUST describe the
total length of the packet, including these extended report blocks.
Each block has block type and length fields that facilitate parsing.
A receiving application can demultiplex the blocks based upon their
type, and can use the length information to locate each successive
block, even in the presence of block types it does not recognize. No
other fields are required.
An extended report block has the following format:
Friedman, Caceres, Almeroth, and Sarac [Page 2]
draft-friedman-avt-rtcp-report-extns-01.txt 13 July 2000
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 | type-specific | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: type-specific data :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
block type (BT): 8 bits
Identifies the specific block format.
type-specific: 8 bits
The use of these bits is defined by the particular block type.
length: 16 bits
The length of this report block in 32-bit words minus one, including
the header.
type-specific data: variable length
This MUST be a multiple of 32 bits long. It MAY be zero bits long.
3. Specific Extended Report Blocks
This section defines five extended report blocks: an experimental
block type and block types for losses, duplicates, timestamps, and
detailed statistics. Other block types MAY be defined in the future.
Any such definition MUST include block type numbers assigned by the
Internet Assigned Numbers Authority [4].
3.1 Experimental Block
This type MUST be used for extended report block types that have not
been standardized. In addition to the standard type and length
fields, it includes a 32 bit name field that serves to distinguish
one experimental block type from another. It is otherwise freely
open to definition.
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=0 | app-specific | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| name (ASCII) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: application-specific data :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Friedman, Caceres, Almeroth, and Sarac [Page 3]
draft-friedman-avt-rtcp-report-extns-01.txt 13 July 2000
block type (BT): 8 bits
Block type 0 identifies this as an experimental block.
app-specific: 8 bits
The use of these bits is defined by the application that uses this
block.
length: 16 bits
The length of this report block in 32-bit words minus one, including
the header.
name: 4 octets
A name chosen by the person definining the experimental block to be
unique with respect to other experimental blocks the application
might receive.
application-specific data: variable length.
This MUST be a multiple of 32 bits long. It MAY be zero bits long.
3.2 Loss RLE Block
With this block type, a boolean trace of lost and received packets
can be conveyed in compressed form using run length encoding.
Caution SHOULD be used in sending such blocks because, even with
compression, they can easily consume bandwidth out of proportion with
normal RTCP packets.
Each block reports on a single source, identified by its SSRC. The
receiver that is supplying the report is identified in the header of
the RTCP packet.
The beginning and ending sequence numbers for the trace are specified
in the block, the ending sequence number being the last sequence
number in the trace plus one. The last sequence number in the trace
MAY or may not be the sequence number reported on in an SR or RR
report block, depending on the needs of the application.
The encoding itself consists of a series of 16 bit chunks. Each
chunk either specifies a run length or a bit vector, or, if the trace
otherwise encodes into an odd number of chunks, MUST be a terminating
null chunk 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 unique and is left to the application. A
run length chunk can describe runs of between 1 and 16,383 packet
losses or receipts whereas a bit vector chunk can describe a sequence
of 15 packet losses and receipts. It is RECOMMENDED that the
description of run lengths of 14 or shorter be subsumed into bit
Friedman, Caceres, Almeroth, and Sarac [Page 4]
draft-friedman-avt-rtcp-report-extns-01.txt 13 July 2000
vector chunks, for purposes of brevity.
A bit vector chunk MAY purport to contain information on packets at
or beyond the ending sequence number. Any such purported information
MUST be ignored.
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 | unused | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| begin_seq |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| end_seq |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| chunk 1 | chunk 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| chunk n-1 | chunk n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
block type (BT): 8 bits
Contains the constant 1 to identify this as a run-length encoding
block with 16 bit chunks.
unused: 8 bits
This field is not used.
length: 16 bits
The length of this report block in 32-bit words minus one, including
the header.
begin_seq: 32 bits
The first sequence number that this block reports on.
end_seq: 32 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. If the chunk is all zeroes then it is a terminating null.
Otherwise, the leftmost bit of the chunk determines its type: 0 for
run length and 1 for bit vector.
Friedman, Caceres, Almeroth, and Sarac [Page 5]
draft-friedman-avt-rtcp-report-extns-01.txt 13 July 2000
3.2.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 runlength chunk.
run type (R): 1 bit
Zero indicates a run of losses. One indicates a run of received
packets.
run length: 14 bits
A value between 1 and 16,383. I.e. MUST not be zero (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.
3.2.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
In the bit vector, as in the run length chunk, a zero indicates a
loss and a one indicates a received packet.
3.2.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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Friedman, Caceres, Almeroth, and Sarac [Page 6]
draft-friedman-avt-rtcp-report-extns-01.txt 13 July 2000
3.3 Duplicate RLE Block
This block is identical in format to the Loss RLE Block type but
carries information about individual or runs of duplicate packets. A
zero indicates the presence of duplicate packets for a given sequence
number, whereas a one indicates that no duplicates were received.
Note that a packet loss is encoded as a one in this case.
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 | unused | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| begin_seq |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| end_seq |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| chunk 1 | chunk 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| chunk n-1 | chunk n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
block type (BT): 8 bits
Contains the constant 2 to identify this as a run-length encoding
block with 16 bit chunks for duplicates.
unused: 8 bits
This field is not used.
length: 16 bits
The length of this report block in 32-bit words minus one, including
the header.
begin_seq: 32 bits
The first sequence number that this block reports on.
end_seq: 32 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. All zeroes indicates a terminating null. Otherwise, the
Friedman, Caceres, Almeroth, and Sarac [Page 7]
draft-friedman-avt-rtcp-report-extns-01.txt 13 July 2000
leftmost bit of the chunk determines its type: 0 for run length and 1
for bit vector. See the descriptions of these block types in the
section on the Loss RLE Block, above, for details.
3.4 Timestamp Report Block
This block carries RTCP-style timestamps for each packet in the range
of packet sequence numbers. A similar caution, but more emphatic, is
made for timestamp report blocks as was made for Loss RLE Block
packets. For each packet in the sequence number range, a 32 bit
value MUST be recorded and sent. This could easily consume
significant bandwidth. Care SHOULD be taken in the size of the
sequence space over which to monitor timestamps.
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 | unused | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| begin_seq |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| end_seq |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP timestamp (pkt n) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
block type (BT): 8 bits
Contains the constant 3 to identify this as a block of packet
timestamps.
unused: 8 bits
This field is not used.
length: 16 bits
The length of this report block in 32-bit words minus one, including
the header.
begin_seq: 32 bits
The first sequence number that this block reports on.
end_seq: 32 bits
The last sequence number that this block reports on plus one.
Friedman, Caceres, Almeroth, and Sarac [Page 8]
draft-friedman-avt-rtcp-report-extns-01.txt 13 July 2000
RTP timestamp: 32 bits
Corresponds to the same units as the RTP timestamp in RTP data
packets. Measured upon packet arrival. Can be used to measure
partial path characteristics and to model distributions for packet
jitter.
3.5 Statistics Summary Block
This block reports detailed statistics above and beyond the
information carried in the standard RTCP packet format. Information
is recorded about lost packets, duplicate packets, jitter
measurements, and TTL values. The packet contents are dependent upon
a bit vector carried in the first part of the header. Not all values
need to be carried in each packet. Header fields for values not
carried are not included in the packet.
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 |L|D|J|T| unused| length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| begin_seq |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| end_seq |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| lost_packets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| dup_packets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| min_jitter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| max_jitter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| avg_jitter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| dev_jitter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| min_ttl | max_ttl | avg_ttl | dev_ttl |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
block type (BT): 8 bits
Contains the constant 4 to identify this as a statistics summary
report block.
Friedman, Caceres, Almeroth, and Sarac [Page 9]
draft-friedman-avt-rtcp-report-extns-01.txt 13 July 2000
content bits (L,D,J,T): 4 bits
Bit set to 1 if packet contains (L)oss, (D)uplicate, (J)itter, and/or
(T)TL report.
unused: 4 bits
This field is not used.
length: 16 bits
The length of this report block in 32-bit words minus one, including
the header.
begin_seq: 32 bits
The first sequence number that this block reports on.
end_seq: 32 bits
The last sequence number that this block reports on plus one.
lost_packets: 32 bits
Number of lost packets in the above sequence number interval.
dup_packets: 32 bits
Number of duplicate packets in the above sequence number interval.
min_jitter: 32 bits
The minimum relative transit time between two packets in the above
sequence number interval. All jitter values are measured as the
difference between a packet's RTP timestamp and the reporter's clock
at the time of arrival, measured in the same units.
max_jitter: 32 bits
The maximum relative transit time between two packets in the above
sequence number interval.
avg_jitter: 32 bits
The average relative transit time between each two packet series in
the above sequence number interval.
dev_jitter: 32 bits
The standard deviation of the relative transit time between each two
packet series in the above sequence number interval.
min_ttl: 8 bits
The minimum TTL value of data packets in sequence number range.
max_ttl: 8 bits
The maximum TTL value of data packets in sequence number range.
Friedman, Caceres, Almeroth, and Sarac [Page 10]
draft-friedman-avt-rtcp-report-extns-01.txt 13 July 2000
avg_ttl: 8 bits
The average TTL value of data packets in sequence number range.
dev_ttl: 8 bits
The standard deviation of TTL values of data packets in sequence
number range.
3.5 Receiver Timestamp 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 [5, Sec. 6.3.1]. A non-sender
may estimate its RTT to other participants, as proposed in [6], 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=5 | unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NTP timestamp, most significant word |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NTP timestamp, least significant word |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
block type (BT): 8 bits
Contains the constant 5 to identify this as a receiver timestamp
report block.
unused: 24 bits
This field is not used.
NTP timestamp: 64 bits
Indicates the wallclock time when this block was sent so that
it may be used in combination with timestamps returned in
DLRR report blocks from other receivers to measure round-trip
propagation to those receivers. Receivers should expect that the
measurement accuracy of the timestamp may be limited to far less
than the resolution of the NTP timestamp. The measurement
uncertainty of the timestamp is not indicated as it may not be
known. A report block sender that can keep track of elapsed time but
has no notion of wallclock time may use the elapsed time since joining
the session instead. This is assumed to be less than 68 years,
so the high bit will be zero. It is permissible to use the
sampling clock to estimate elapsed wallclock time. A report sender
that has no notion of wallclock or elapsed time may set the NTP
timestamp to zero.
Friedman, Caceres, Almeroth, and Sarac [Page 11]
draft-friedman-avt-rtcp-report-extns-01.txt 13 July 2000
3.6 DLRR Report Block
This block extends RTCP's DLSR mechanism [5, Sec. 6.3.1] so that
non-senders may also calculate round trip times, as proposed in [6].
It is termed DLRR for Delay since Last Receiver Report, and may be
sent in response to a Receiver Timestamp report block (see previous
section) from a receiver to allow that receiver to calculate its
round trip time to the respondant. The report consists of one or
more 3 word sub-blocks: one sub-block per receiver report.
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=6 | unused | length |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| SSRC_1 (SSRC of first receiver) | sub-
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block
| last RR (LRR) | 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| delay since last RR (DLRR) |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| SSRC_2 (SSRC of second receiver) | sub-
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block
: ... : 2
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
block type (BT): 8 bits
Contains the constant 6 to identify this as a block of DLRRs.
unused: 8 bits
This field is not used.
length: 16 bits
The length of this report block in 32-bit words minus one, including
the header. The number of sub-blocks is simply length / 3.
last RR timestamp (LRR): 32 bits
The middle 32 bits out of 64 in the NTP timestamp (as
explained in the previous section) received as part of
a Receiver Timestamp report block from participant SSRC_n. If no
such block has been received, the field is set to zero.
delay since last RR (DLRR): 32 bits
The delay, expressed in units of 1/65536 seconds, between
receiving the last Receiver Timestamp report block from
participant SSRC_n and sending this DLRR report block. If no
Receiver Timestamp report block has been received yet from SSRC_n,
the DLRR field is set to zero (or the DLRR is omitted entirely).
Friedman, Caceres, Almeroth, and Sarac [Page 12]
draft-friedman-avt-rtcp-report-extns-01.txt 13 July 2000
Let SSRC_r denote the receiver issuing this DLRR report
block. Participant SSRC_n can compute the round-trip
propagation delay to SSRC_r by recording the time A when
this Receiver Timestamp report block is received. It calculates
the total round-trip time A-LSR using the last SR timestamp
(LSR) field, and then subtracting this field to leave the
round-trip propagation delay as (A- LSR - DLSR). This is
illustrated in [5, Fig. 2].
4. Acknowledgements
We thank the following people: Colin Perkins, Steve Casner, and
Henning Schulzrinne for their considered guidance; Sue Moon for
helping foster our collaboration; and Mounir Benzaid for drawing
our attention to the reporting needs of MLDA.
5. Intellectual Property
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP 11 [3]. Copies
of claims of rights made available for publication and any assurances
of licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
6. References
[1] S. Bradner, "The Internet Standards Process -- Revision 3," BCP
9, RFC 2026, IETF, October 1996.
[2] S. Bradner, "Key words for use in RFCs to indicate requirement
levels," BCP 14, RFC 2119, IETF, March 1997.
[3] R. Hovey and S. Bradner, "The Organizations Involved in the IETF
Standards Process," BCP 11, RFC 2028, IETF, October 1996.
Friedman, Caceres, Almeroth, and Sarac [Page 13]
draft-friedman-avt-rtcp-report-extns-01.txt 13 July 2000
[4] J. Reynolds and J. Postel, "Assigned Numbers," STD 2, RFC 1700,
IETF, October 1994.
[5] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: A
transport protocol for real-time applications," RFC 1889, IETF,
February 1996.
[6] D. Sisalem and A. Wolisz, "MLDA: A TCP-friendly Congestion
Control Framework for Heterogeneous Multicast Environments",
Eighth International Workshop on Quality of Service (IWQoS 2000),
5-7 June 2000, Pittsburgh.
7. Full Copyright Statement
Copyright (C) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Friedman, Caceres, Almeroth, and Sarac [Page 14]
draft-friedman-avt-rtcp-report-extns-01.txt 13 July 2000
8. Authors' Addresses
Timur Friedman <friedman@cs.umass.edu>
Computer Science Department
UMass Amherst
Amherst, MA 01003, USA
Ramon Caceres <ramon@research.att.com>
AT&T Labs-Research
180 Park Avenue, Building 103
Florham Park, NJ 07932, USA
Kevin Almeroth <almeroth@cs.ucsb.edu>
Department of Computer Science
University of California
Santa Barbara, CA 93106, USA
Kamil Sarac <ksarac@cs.uscb.edu>
Department of Computer Science
University of California
Santa Barbara, CA 93106, USA
This draft expires 13 January 2001.
Friedman, Caceres, Almeroth, and Sarac [Page 15]
