An empty RR packet (RC = 0) is put at the head of a compound RTCP
packet when there is no data transmission or reception to report.
6.3.3 Extending the sender and receiver reports
A profile should define profile- or application-specific extensions
to the sender report and receiver if there is additional information
that should be reported regularly about the sender or receivers. This
method should be used in preference to defining another RTCP packet
type because it requires less overhead:
o fewer octets in the packet (no RTCP header or SSRC field);
o simpler and faster parsing because applications running under
that profile would be programmed to always expect the extension
fields in the directly accessible location after the reception
reports.
If additional sender information is required, it should be included
first in the extension for sender reports, but would not be present
in receiver reports. If information about receivers is to be
included, that data may be structured as an array of blocks parallel
to the existing array of reception report blocks; that is, the number
of blocks would be indicated by the RC field.
6.3.4 Analyzing sender and receiver reports
It is expected that reception quality feedback will be useful not
only for the sender but also for other receivers and third-party
monitors. The sender may modify its transmissions based on the
feedback; receivers can determine whether problems are local,
regional or global; network managers may use profile-independent
monitors that receive only the RTCP packets and not the corresponding
RTP data packets to evaluate the performance of their networks for
multicast distribution.
Cumulative counts are used in both the sender information and
receiver report blocks so that differences may be calculated between
any two reports to make measurements over both short and long time
periods, and to provide resilience against the loss of a report. The
difference between the last two reports received can be used to
estimate the recent quality of the distribution. The NTP timestamp is
Schulzrinne, et al Standards Track [Page 29]
RFC 1889 RTP January 1996
included so that rates may be calculated from these differences over
the interval between two reports. Since that timestamp is independent
of the clock rate for the data encoding, it is possible to implement
encoding- and profile-independent quality monitors.
An example calculation is the packet loss rate over the interval
between two reception reports. The difference in the cumulative
number of packets lost gives the number lost during that interval.
The difference in the extended last sequence numbers received gives
the number of packets expected during the interval. The ratio of
these two is the packet loss fraction over the interval. This ratio
should equal the fraction lost field if the two reports are
consecutive, but otherwise not. The loss rate per second can be
obtained by dividing the loss fraction by the difference in NTP
timestamps, expressed in seconds. The number of packets received is
the number of packets expected minus the number lost. The number of
packets expected may also be used to judge the statistical validity
of any loss estimates. For example, 1 out of 5 packets lost has a
lower significance than 200 out of 1000.
